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

上次看到Basis 联合创始人 Mitchell Troyanovsky 参与的博客，关注他们公司和 Braintrust 在2026 年 7 月 29 日联合推出的开放标准项目：Agent Behavior / Behavior Specs，开放标准及其示例、Judge Prompt 和工具链。

原地址：https://www.agentbehavior.dev/。

核心结论。Behavior Spec 不是另一份更长的 Prompt，也不是要求人工逐步盯住 Agent。它把“什么样的过程行为算合格”写成独立、可版本化、可审阅的标准，并据此检查一条完整 Agent 轨迹。

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

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

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

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

• Spec（规格）：定义组织希望 Agent 如何行为；

• Rubric（评分准则）：定义审阅者应如何判断该行为是否达标。

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

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

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

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

两者都可能随项目保存在仓库中，也都会影响 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 时，才选择性地将相关规范转化为运行时约束。

不是所有动作都值得写成 Spec。Agent behavior 规范给出六项直接筛选标准。

最实用的筛选公式是：如果一项行为频繁出现、影响重大、体现 Agent 的产品选择，且不写清就容易产生分歧或难以调试，它应优先进入 Behavior Spec。写入前还应检查：是否能说明何时适用、期望行为与失败模式，以及审阅者能否在轨迹中找到评估证据。

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

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

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

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

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

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

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

• 低价值操作习惯，例如固定先打开哪个页面或某个临时点击顺序；

• 只针对一次事故、没有复用价值的临时补丁；

• 没有触发条件、要求所有任务一律执行的动作；

• 无法从轨迹取证、只能依赖模糊主观感受的表述；

• 价值很低但会显著拖慢任务的检查；

• 已有廉价确定性验证方式的细节，例如 Excel 是否存在 #REF! 错误。

对于最后一类问题，应优先使用传统程序校验；Behavior 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 是推荐维度；可按需要合并、改名、调整顺序或省略明显重复的部分。

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

官方给了4个BEHAVIOR.md案例，我分析了一些，大家可以一起看下写法

四个 Spec 的写法差异：

四个 Spec 虽然领域不同，但都具备五个共同元素：

1. 写清楚何时适用，而不是要求所有任务一律执行；

2. 写明 Agent 在判断前必须看什么证据；

3. 写明预期行为，而非只写最终输出；

4. 明确不确定、缺失或失败时如何恢复；

5. 明确哪些“看似完成任务、实则不可接受”的行为属于失败。

Spec 在同一项目中有两种角色：

Behavior Spec 主要是标准层资产；它默认在执行后用于审阅、评估和调试。

但在高风险领域，团队可以将其中相关规范选择性转化为运行时 Prompt、硬校验、权限门禁或人工确认，从而在执行过程中预防错误。

核心关系：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 的行为。