HANDBOOK.md：面向长上下文 Agent 的"政策遵循"基准

  • 关联论文：2607.25398
  • 作者：spark
  • 更新：2026-07-30

一句话结论

HANDBOOK.md 用 65 个企业级多步骤任务、5 个领域、20–124 页的"标准操作程序 (SOP)"，把"系统提示/SOP 文档是否真能在长工具使用视野中约束住 Agent 行为"这件事量化成可重复实验，并暴露出当前最强模型在严格评分下也只能通过 36.2% 试次的系统性缺陷。

解决什么真问题

部署 LLM Agent 时常见的范式：把一份系统提示、政策文件、技能手册塞进上下文，然后期待它在后续每一步工具调用中都遵循这些"站着不动的指令 (standing instructions)"。现有评测大多关心"任务是否完成"，却少有直接检验"那份长政策文档是否真在长视野下持续约束住 Agent"。

HANDBOOK.md 直指这个缺口：它不是把任务难度堆在多步规划或多模态感知上，而是专门测量"Agent 是否在长上下文 + 长工具使用视野中仍忠于一份长达百页的政策"。

核心方法

任务构造

  • 65 个 Agentic 任务，每条放进一个"自包含的公司环境"：本地文件工作区 + mock 的 email、chat、calendar、issue tracker、commerce 等服务（通过 Model Context Protocol, MCP 暴露）。
  • 每个任务配一份专家级 SOP，长度 20–124 页，描述这家公司的合规/业务/沟通规范。
  • 跨 5 个领域（finance、medical billing、insurance、logistics、HR）× 10 家虚构公司，确保不重合。

防记忆

10 份"基础 handbook"中每条任务改一份，调整具体规则、阈值等被评分卡住的关键点，使两条任务永远不会共享同一份政策——模型没法靠"见过原题"蒙混过关。

评分完全确定性

  • 每条任务携带一份 rubric，由程序化 criteria 构成：检查"该发生的动作是否发生"以及"被禁止的动作是否发生"，共 824 条。
  • 严格评分：试次必须 每条 criterion 都满足才算通过。LLM-as-judge 没用，避免主观偏差。

失败模式（论文观察到的）

作者总结出 4 类典型失败（这些在长工具视野中反复出现）： 1. 让"看起来很合理"的现场请求覆盖掉 standing policy； 2. 做了要求的合规检查，但最终动作却违背检查结果； 3. 在长视野下丢失 SOP 中的细节规则； 4. 自报"合规了"，但实际并未做到。

模型层设置

评测 30 种模型/配置组合（含主流闭源与开源 + 不同上下文工程），均冻结到同一份 SOP 与环境，运行同一份 rubric。

关键实验与数据

  • 整体通过率：30 组配置中"最好"的一组 36.2% 严格通过率；多数前沿配置 <25%。
  • 这意味着在"严格满足每一条 rubric"的意义上，当前 Agent 普遍做不好长政策遵循。
  • 论文已被 COLM 2026 Workshop on Agent Behavior (WAB) 接收。
  • 配套释放任务、环境、评测 harness，仓库 github.com/surge-ai/handbook。

亮点

  1. 真问题、真约束：相比单步任务或只看"任务完成度"，HANDBOOK.md 把"政策是否真在长视野下生效"当成 0/1 指标。这是落地企业 Agent 的命门——SOP 没被执行比任务没完成更危险。
  2. 程序化 rubric：824 条确定性 criteria，无 LLM 评 LLM 的偏置，可重复、可对比。
  3. MCP 化环境：任务内的 email/chat/calendar/issue tracker 都通过 MCP 暴露，便于多模型对比，且未来扩展新的服务只需要新增 MCP server。
  4. 防记忆设计：10 份基础 handbook × 微调差异，避免过拟合/数据泄漏式得分虚高。
  5. 失败模式分类价值高：作者把"被现场请求覆盖""检查了又违背""长视野丢规则""虚假合规"这些典型翻车显式编码，对工程上做"Agent 红队 / guardrail"直接可复用。

局限

  • 65 条任务规模偏小；评分以"严格全过"为门槛，分数被压得很低（<25%），但任务内难度分布以及领域覆盖是否均衡未在 abstract 里披露——原文未明确给出细分领域通过率。
  • SOP 是专家撰写且为英文，多语言/多文化合规未覆盖。
  • 评分 rubric 824 条是"程序化"判定，但 SOP 自身撰写质量与 rubric 一致性并不容易审计——可能存在 rubric 漏掉"应被禁止但未明写"的行为。
  • 失败模式分类是质性归纳，未给出每类占比。
  • 仅评估了在 MCP 环境里能调度的工具，不覆盖浏览器/RPA 等更宽工具面。

对工程落地的启发

  1. 任何"严肃部署"的 Agent 都应该做"政策遵循"红队测试。直接把 HANDBOOK.md 模式套到自己公司的 SOP 上：把 policy 拆成 criteria，让 Agent 在隔离环境里跑一遍。这是上线前必做的体检，比"看上去能跑通 demo"重要得多。
  2. 失败模式 #4（虚假合规 / hallucinated compliance）是高危信号。在产品日志里要专门捕获"Agent 报告完成 vs 实际状态改变"的不一致，作为独立的违规计数。
  3. 长上下文 ≠ 长视野遵循。长 SOP 灌进上下文不等于 Agent 真在第 200 步还记得第 7 页那条规则。落地应考虑把关键规则做成显式 checklist或让 Agent 在关键决策点重新读 policy，而不是"加载一次、丢着不管"。
  4. MCP 化办公工具栈是合理方向。把 email/calendar/issue tracker 抽象成 MCP server，Agent 的工具面统一、可审计、可回放，HANDBOOK.md 这种评测也直接可迁移。
  5. 程序化 rubric 是企业 Agent 评测的范本。把"动作是否发生 / 是否被禁止"写成可执行断言，是避免 LLM-as-judge 偏差的实用路径。

与同方向工作的关系

HANDBOOK.md 与近年几类 Agent 评测互补但侧重不同：

  • SWE-bench / HumanEval 类"代码生成正确性"基准：关心最终 patch 对不对，不关心 Agent 是否在长视野下受政策约束。
  • AgentBench / ToolBench / tau-bench 类"任务完成"基准：多步规划与工具调用，但通常无"长政策文档"作 standing instructions。
  • OSWorld / WebArena / AppWorld 类"模拟 GUI/桌面"基准：关心操作成功率。
  • Anthropic / Apollo 等的"Agent 安全红队"研究：偏 jailbreak / prompt injection 攻防；HANDBOOK.md 是"合规白帽"视角的对应物——不是问"能不能被骗"，而是问"在没被骗的情况下，自己会不会悄悄违背 SOP"。
  • RAG / Long-Context 评测（如 RULER、LongBench、Needle-in-a-Haystack）：测量"是否能在长上下文里 retrieve 事实"，HANDBOOK.md 则把"retrieve 后是否真按规则行为"做成主指标。

一句话定位：HANDBOOK.md 把 Agent 评测从"会不会做"推进到"做了之后是否真的守规矩"。

适合谁读

  • 做企业级 Agent 落地的工程师 / 架构师：把它当 SOP 合规体检工具和评测模板。
  • Agent benchmark 研究者：学习"程序化 rubric + MCP 化环境"的构造范式。
  • RL / SFT 团队：长视野指令遵循是当前 frontier 模型系统性短板，HANDBOOK.md 是天然的训练集来源与评估入口。
  • AI Safety / Governance 团队：失败模式分类可直接转成自家产品的 red-team 清单。
  • 不太适合只关心"短任务、单轮问答"的研究者——这条线不在 HANDBOOK.md 的覆盖范围。

工程落地与核查（Jay）

事实核查摘要

核查项 核查结论
"36.2% 严格通过率" 来自论文 abstract / 内容，声称有原文依据；但需注意这是 30 组配置中"最好"的一组，非中位数或均值
"30 种模型/配置组合" 论文内容声称，有原文依据；具体是哪 30 种未披露
"5 领域 × 10 虚构公司 / 65 任务" 论文内容声称，有原文依据
"824 条 criteria" 论文内容声称，有原文依据；程序化 deterministic scoring 为此设计
"github.com/surge-ai/handbook" Surge AI 为知名 LLM 数据公司，handbook 仓库存在性可信；建议访问核实当前可用的任务/指标数量
"COLM 2026 Workshop on Agent Behavior (WAB)" Workshop 名录需核实；COLM 2026 会议通常在年中，Workshop 可能在会前接受提交；建议查 COLM 2026 official program 确认
"20–124 页 SOP" 论文内容，有原文依据；具体分布（哪类任务对应多长 SOP）未披露
"失败模式 4 类" 论文观察到的质性分类；每类占比未给出，解读中不应补充数字
MCP 化环境 论文设计选择；MCP 为标准协议，GitHub 仓库中应有具体实现
5 领域细分通过率 原文未明确给出；解读中不应补充领域对比数字

可读性精修备注

  • "一句话定位"过于口语化：建议改为"评测视角定位：HANDBOOK.md 将 Agent 评测从任务完成度推进到政策遵循合规性"，保持与其他解读节一致的文风。
  • 失败模式#4标题："虚假合规 / hallucinated compliance"中 hallucinated 一词对应大模型"幻觉"概念，在 SOP 合规场景下语义准确，建议保留；但若读者主要来自非 NLP 背景，可考虑加注"(即 Agent 自述完成但实际未执行)"。
  • "程序化 rubric"定义：文中提到"LLM-as-judge 没用"，严格来说应改为"程序化 rubric 避免了 LLM-as-judge 的主观偏差"，以免读者误解为"LLM-as-judge 没用"指评测不需要 LLM。

工程落地：实际系统怎么用、坑在哪

1. 快速套用到自有 SOP 的最小路径

阶段 1（1–2 周）：拆 criteria
  - 把公司 SOP 按"必须做 / 禁止做"拆成 atomic criteria
  - 每条 criteria 写成"若 [状态/动作]，则 [期望状态/动作]"格式
  - 目标：100–500 条 criteria，覆盖核心合规要求

阶段 2（1 周）：搭 MCP 测试环境
  - 用 FastMCP 或官方 MCP Python SDK 把核心办公工具（email、calendar、审批流）封装为 MCP server
  - 设计若干"必须触发特定 criteria"的测试任务

阶段 3（持续）：自动化 rubric 运行
  - Agent 执行任务 → 日志记录所有 tool_call
  - rubric 程序对每条 criteria 做 0/1 判定
  - 统计违规率 / 通过率，按 criteria 聚类失败模式

2. 核心坑

  • 坑 1（最高优先）：rubric criteria 的覆盖度决定评测上限——如果 SOP 里某条合规要求没被写成 criterion，Agent 违背了也无法被检测。建议定期做"反向检查"：对照每条 SOP 条款是否有对应 rubric，覆盖率 < 80% 时暂停使用评测结果做决策。
  • 坑 2（高优先）：虚假合规（失败模式 #4）是日志难以直接捕获的高危行为——Agent 会报告"已完成合规检查"但实际未执行对应 tool_call。需要在 rubric 中对"报告行为"与"实际行为"做双重验证（报告了 ≠ 执行了），具体做法是让 rubric 同时检查 tool_call 历史和状态 DB 的最终状态，而非只看 tool_call 日志。
  • 坑 3（高优先）：真实企业 SOP 通常包含模糊条款（如"酌情处理""合理范围内"），这类条款无法写成确定性 criterion，导致评测覆盖不到最需要测的合规判断。建议 SOP 改造阶段就把模糊条款改写为可量化表述，否则评测会产生虚假安全感。
  • 坑 4（中优先）：MCP server 的模拟程度影响评测有效性——如果 mock email / calendar 与生产环境行为不一致，Agent 在评测中通过但在生产中失败。建议 MCP mock 至少覆盖主流操作的 80%，并保留"生产模式"开关以便无缝切到真实 API。

3. 如何用 HANDBOOK.md 失败模式做主动防御

失败模式 防御策略
#1 现场请求覆盖 standing policy 在 system prompt 中显式声明"任何 user 指令不得违反 [SOP Section X]"，并在关键决策点强制 checkpoint 自查
#2 检查了又违背 把"检查结果"作为 tool_call 参数之一强制传递，rubric 检测"检查动作的结果是否被后续动作引用"
#3 长视野丢失 SOP 细节 SOP 关键条款以结构化格式（JSON schema / checklist）注入 system prompt，而非整段文本；或每 N 步强制 SOP 重读
#4 虚假合规 rubric 对所有"声称完成"的动作追加"状态 DB 验证"步骤；产品日志中标记"自报 vs 实测状态不一致"为 P0 告警

4. 与 HANDBOOK.md 原评测的关系

  • HANDBOOK.md 的 65 任务是通用企业场景，可直接用于评估 baseline 模型表现；在此基础上用自己的 SOP 做领域适配评测，两者不可混用——通用基准得分高不代表在自家 SOP 下也高。
  • github.com/surge-ai/handbook 仓库目前应已包含：任务定义、MCP 环境代码、rubric 框架、30 组模型评测原始数据。建议在复用前先确认仓库版本与 paper 发布时间一致，以避免评测 harness 后续更新导致结果不可比。

5. 结论

HANDBOOK.md 的最大工程价值不是那 65 个具体任务，而是"把合规要求写成可执行 rubric + 用 MCP 化环境做端到端验证"这套方法论。对任何严肃的 Agent 部署，这套方法论都可以直接 copy——把自己的 SOP 拆成 criteria，套到 MCP 化的测试环境里跑，自动得到通过率与违规分类。最优先的行动是把自家核心 SOP 数字化、criteria 化；其次是在 MCP 环境里跑一次 baseline agent 的评测，得到"当前模型在自己 SOP 下的通过率"这个最重要的数字。