Behavior Spec 完整解读：用行为规范监督长程 Agent

从逐步监督转向行为监督的必然性

早期过程监督的典型对象是短数学题：一题只有几个展示步骤，人可以逐项判断推理是否正确。如下图的 PRM800K 时代，约 7.5 万个解答配有约 80 万条人工逐步标签；此时的监督单位是“单步推理”。

今天的 Agent 工作则完全不同。一项一小时任务可能包含多轮模型推理、检索、读文件、运行脚本、浏览网页、编辑表格、规划与子 Agent 协作。其推理和工具调用量比短题大多个数量级，不可能为每一步都配上密集人工标注。

因此，文章提出的新监督单位是跨完整轨迹的关键行为。例如，不是逐项打分“每次检索是否正确”，而是检查：“当任务形成税务结论时，Agent 是否真的用一手来源核验？”这项行为可能横跨多次检索、阅读、判断与最终交付。

Behavior Spec 的本质与结构

Behavior Spec 是围绕一项重要行为编写的、自包含的 Markdown 规范。它同时是：

• Spec（规格）：定义组织希望 Agent 如何行为；
• Rubric（评分准则）：定义审阅者应如何判断该行为是否达标。

它的焦点不是“这次答案像不像正确答案”，而是三个问题：该行为在这次任务中是否适用；若适用，Agent 是否执行；轨迹中有哪些证据能证明它执行或未执行。

规范通常会写清意图、适用条件、预期行为、可接受证据和失败模式。例如，税务研究规范可以要求关键结论优先使用法规、官方指南等一手材料；如果来源冲突或不足，应显式标注不确定性，而不能把猜测写成事实。

true / false / NA 三值判定机制

Behavior Spec 的判定不是简单的“好”或“坏”，而是三值：

NA 是必要设计。它避免了把规范变成“无论什么任务都必须执行所有动作”的僵化检查表。例如，PPT 视觉渲染检查适用于重要正式交付，但未必适用于一个只需几十秒的草稿任务。

BEHAVIOR.md 与 AGENTS.md 的分工边界

两者都可能随项目保存在仓库中，也都会影响 Agent 的表现，但服务于不同问题。最简洁的区分是：AGENTS.md 告诉 Agent 如何行动；BEHAVIOR.md 定义什么算好行为。

例如，AGENTS.md 可以规定项目目录、允许调用的工具、交付格式和执行顺序；BEHAVIOR.md 则规定：凡是会影响业务结论的关键事实，必须核验权威来源、保留口径和时间范围；证据冲突时不得把推测写成事实。前者解决“下一步怎样做”，后者解决“这条完整轨迹是否以可信方式完成”。

BEHAVIOR.md 也不等于系统 Prompt、工具文档、Eval 或 Trace。

• 系统 Prompt 是运行时指令；
• 工具文档说明可执行的操作与约束；
• Eval 测试行为是否发生；
• Trace 记录 Agent 实际做了什么。

Behavior Spec 位于这些资产之上，作为它们共同对齐的行为标准：它可以指导 Prompt、工具和 Eval 的设计，但不应变成具体工具的使用手册或评分器实现代码。

默认情况下，行为规范主要在审阅轨迹、设计或更新 Eval、审计 Prompt 与工具、调试行为回归、生成行为文档时被加载；不应把全部 Spec 都塞进运行时 Prompt。只有在有意构建“行为受控”的 Agent 时，才选择性地将相关规范转化为运行时约束。

六类值得优先规范的关键行为

证据来源与核验。适用于税务、财务、法务、研究、医疗、风控等。关键结论应回到法规、官方资料、原始系统或原始文件核验；涉及金额、日期、指标和适用范围时，应保留可追溯来源。文章的税务例子强调：即使模型连续答对，也不能仅凭 Wikipedia、博客或模型记忆；专业服务需要一手来源的证据链。

高风险决策的升级与复核。适用于信贷、退款、合同、定价、招聘和对外承诺。金额超过阈值、出现非标准条款、关键证据冲突或置信度不足时，应升级人工，而不是由 Agent 静默决定。

成本敏感行为。这是规范页面提供的示例：对可能产生显著费用、额度消耗或基础设施成本的操作，Agent 应估算成本与替代方案，判断是否存在实质性权衡；跨过有意义的阈值前，应向用户说明成本并征求确认。若成本未知，应继续核查、请求确认或明确标注不确定性。它定义的是“成本敏感型 Agent”这一产品行为，而不是某个计费工具的操作说明。

交付前的可用性与完整性检查。文章给出的例子是：生成 PPT 后，交付前应渲染为图片检查版式；修复后还要重新渲染验证。对应到业务中，Excel 应检查公式错误和关键数字一致性，报告应检查引用、图表和正文数字，外发邮件应检查收件人、附件、金额、日期和敏感信息。

关键上下文与任务交接。长程 Agent 在委派子 Agent、切换工具或恢复任务时，应带上必要目标、约束、历史决策和未解决问题。值得规范的不是每一次调用，而是是否避免了因上下文残缺而重复劳动、作出矛盾判断或依据失效信息继续执行。

失败恢复与纠错。工具失败、输入缺失或发现矛盾时，Agent 应识别原因、采用允许的替代路径、记录阻塞并必要时请求补充；修改交付物后，应重新执行相关验证，而不是假定修复成功。

专业人员重视但难以写成硬规则的判断。例如是否删掉关键工作表、是否遗漏重大例外、是否区分事实与推断、是否对异常给出合理解释。这类标准往往难以用 if/else 或传统单元测试表达，正是 Judge Agent 结合 Behavior Spec 的适用范围。

Judge Agent 如何基于 Spec 审阅轨迹

Judge Agent 不只看最终文件，而是查看任务目标、Agent 轨迹、工具调用、产物、来源和必要上下文。它要回答的不是“结果是否好看”，而是“在这个任务条件下，这项行为是否被触发；若被触发，是否有足够证据证明正确执行”。

说明：true / false / NA 是一种很适合轨迹审阅的三值输出：已做到、应做未做、此次不适用。但它是 Judge 或 Eval 的评分约定，不是 BEHAVIOR.md 格式本身强制要求的字段；格式强制的是目录、文件名和 frontmatter，正文则保持自由表达。

这不意味着 Judge 是绝对正确的。长轨迹审阅本身有成本，也会出现误判。对一小时任务，不能简单地把整条原始轨迹、每个子 Agent 的所有调用都交给最强模型审阅。实际系统需要先对轨迹加结构化记录、检索与该 Spec 相关的片段、对高风险任务或抽样任务使用较强 Judge，并持续校准 Judge 与人工专家的一致性。

非代码业务的落地实施路径

1. 选一个具体高价值工作流。例如财务分析、市场研究、合同初审或售后退款，不要一开始覆盖全公司。
2. 回看失败案例。找出那些“答案看似能用，但过程仍不可接受”的问题。
3. 先写 3 至 5 个关键行为。优先覆盖一手来源核验、异常升级、关键交付前检查、事实与推断区分等。
4. 为每个行为写清触发条件与证据。确保能给出 true、false、NA，而非停留在“要认真”“要专业”。
5. 把标准转化为执行实现。更新 AGENTS.md、系统 Prompt、工具权限、模板和工作流。
6. 用真实轨迹审阅并迭代。将 false 的原因归因到运行时说明、知识、工具、上下文或流程，而不是只把它记为“模型失败”。

规范文件的结构与质量要求

规范的标准目录如下。一个 Spec 可以描述一项行为，也可以把属于同一 Agent、产品界面或行为领域、应当一起发现和审阅的多个相关行为放进同一个文件；若行为需要独立负责人、独立复用或独立评测，则应拆成独立 Spec。

.agents/behaviors/
└── behavior-name/
    ├── BEHAVIOR.md
    ├── references/
    # 可选：设计依据、示例轨迹、背景资料、领域上下文
    └── ...            # 可选附加文件

BEHAVIOR.md 是规范文件名，必须包含 YAML frontmatter 和 Markdown 正文。

目录名是稳定标识，必须与 frontmatter 中的 name 一致。

name 必填，最长 64 字符，只能由小写字母、数字和连字符组成，且不能以连字符开头或结尾；

description 必填、非空，最长 1024 字符，应说明范围和适用情形。

license 与 metadata 为可选字段。

正文没有强制章节顺序，但一份高质量 Spec 应清楚说明：反复出现的行为、何时适用、希望发生的行为、不希望发生的行为或失败模式，并提供让审阅者能在真实轨迹中评估的上下文。Intent、Evidence、Decision、Execution、Recovery、Failure modes 是推荐维度；可按需要合并、改名、调整顺序或省略明显重复的部分。

可直接改写的 Spec 模板

---
name: verify-primary-source-for-material-claims
description: 对影响业务结论的关键事实，使用并核验权威一手来源。
---
## Intent
避免基于过时、二手或不可追溯信息形成关键结论。
## Applies when
任务包含会影响决策、金额、合规判断或对外承诺的关键事实。
## Expected behavior
1. 定位权威一手来源或内部系统原始记录。
2. 核验关键数字、日期、定义与适用范围。
3. 在交付物中保留来源或可追溯路径。
4. 若来源冲突或不足，明确标记不确定性并升级处理。
## Evidence
- 原始文件、系统查询记录或权威链接。
- 关键结论与来源之间的对应关系。
- 对缺失或冲突信息的说明。
## Failure modes
- 仅依赖搜索摘要、博客或模型记忆。
- 将推测写成事实。
- 来源冲突时未声明或未升级。

Behavior Spec 与 Agent 评估器的关系

核心关系：Behavior Spec 不是新的评估器，而是评估器应依据的“行为标准”或“验收合同”。Spec 定义什么行为算好、何时适用、哪些失败不可接受；评估器读取输出或轨迹、收集证据、给出分数或判定。

Behavior Spec：定义期望行为与失败模式
        ↓
Evaluator / Judge / Rule Checker：检查输出或执行轨迹
        ↓
分数、true / false / NA、失败原因、告警
        ↓
改进 AGENTS.md、Prompt、工具、知识或工作流

行业中的 Agent 评估器通常包括：确定性检查器（格式、字段、计算、工具调用）、输出型 LLM Judge（结果是否正确或有用）、轨迹型 Judge（过程、检索、工具和协作）、安全/策略检查器（权限、敏感信息、金额阈值），以及人工抽检。Behavior Spec 尤其适合为轨迹型 Judge 和策略型检查提供清晰、可复用的判定依据。

两者必须配合，而不能互相替代。没有 Spec，LLM Judge 容易退化为“这看起来是否专业”的模糊打分；没有评估器，Spec 只是写在仓库中的原则，无法证明系统是否实际遵守。生产系统通常应同时做结果评估与行为评估：前者检查答案是否正确、有用、完整，后者检查过程是否可信、合规、可追溯和可恢复。

例如，对“重大成本操作必须先说明成本并征求确认”的 Spec，评估器应检查 Agent 是否识别成本、估算成本或替代方案、在跨过阈值前请求确认，而不只检查最终任务是否完成或总花费是否在预算内。这就是从结果评分转向过程监督的实际含义。

结语：显性化关键质量要求

Behavior Spec 的价值不在于给 Agent 加更多规则，而在于让组织把少量真正重要的质量要求显性化、可讨论化、可验证化。对非代码业务而言，最有效的起点通常不是构建复杂评测平台，而是回答一个朴素的问题：哪些事情即使结果碰巧正确，若过程没有做到，我们仍然不能接受？这些事情，就是最值得先写成 Behavior Spec 的行为。