谁来签收？让规范而不是 Agent 自己说了算
谁来签收？让规范而不是 Agent 自己说了算
一个让你后背发凉的场景
你让一个 AI Agent 帮你处理一份重要数据。它读取任务说明、调用工具、执行步骤，最后兴冲冲地告诉你："搞定了，任务完成。"
你信了。
但你怎么知道它真的做完了？不是"它说做完了"，而是"规范要求的状态真的被建立了"？
这不是一个哲学问题。德克萨斯大学阿灵顿分校的 Haiqing Li 团队量化了这个问题，结果触目惊心：七个主流大模型（包括 GPT-5.6 Sol、Claude Fable 5、Gemini 3.1 Pro），Agent 自报完成率比官方评估通过率高出 28.7 到 37.9 个百分点。 也就是说，Agent 说"我做完了"的时候，有将近三分之一的情况是它自己以为做完了，实际上并没有。
更微妙的是另一个数字：即使 Agent 完全理解了任务要求，只有 79.6%–86.4% 的要求方向在执行中真正被满足。理解了不等于做到了。
这篇论文叫《Who Holds the Pen? Let Specifications, Not Agents, Sign Off》，它提出的核心问题不是"Agent 能不能做得更好"，而是"谁有权宣布任务完成"。
两个结构性裂缝
论文识别出当前 Agent 系统中两个被忽视的结构性缺陷。
理解-执行裂缝（Understanding–Execution Gap）
第一个裂缝：理解一个要求，并不保证执行时满足它。
想象你给 Agent 一个数据处理任务，规范说"先清洗再转换最后验证"。Agent 读规范的时候完全理解这个顺序，但在执行时，它可能跳过清洗直接转换，或者忘了验证步骤。理解是正确的，执行是错误的。
这和"不理解"不同。不理解是能力问题，理解了但没做到是结构问题——规范只是 Agent 上下文里的一段文字，不是执行时的硬约束。 Agent 可以随时忽略它、曲解它、或者干脆忘了它。
状态-权威裂缝（State–Authority Gap）
第二个裂缝更致命：Agent 的自我评估或完成声明，不能证明规范要求的状态真的被建立了。
这听起来像在说绕口令，但其实是两个不同的东西：
- Agent 说"我做完了"——这是 Agent 的自我声明
- 规范要求的状态被建立——这是客观事实
在大多数 Agent 系统里，这两件事被混为一谈。Agent 既是执行者，又是评估者，还是完成声明者。提案者和验收者是同一个人。 这就像让学生自己给自己判卷子，还自己决定什么时候交卷。
论文用一张图形象地说明了这个问题：Agent 理解了"先 A 后 B 再 C"的顺序，但执行时做成了"先 B 后 A 再 C"——理解-执行裂缝；Agent 声称"任务完成"，但 C 步骤实际上没做——状态-权威裂缝。
核心洞察：规范权威边界
论文的核心贡献是提出了一个被忽视的设计原则——State Authority Principle（状态权威原则）：
对于可可靠落地和验证的条件，规范定义"什么可以被接受"，而外部运行时决定"要求的状态是否已被建立"。
翻译成人话：Agent 提案，规范签收。
这个原则的关键不在于"检查 Agent 做得对不对"——那是事后验证。关键在于：Agent 的动作、输出和自我评估，不能直接建立"规范定义的权威状态"。 只有来自合格验证器的可采信证据，才能更新状态。
这和"判断-闸门解耦"是同一个思想：执行者和验收者必须分离，否则系统就没有真正的安全边界。
SpecHarness：把规范变成运行时权威
论文不仅提出了原则，还实现了系统——SpecHarness。它做四件事：
1. 编译规范为义务（Obligation Construction）
SpecHarness 把 Agent 可见的所有规范材料——任务提示、指南、技能说明、工作区状态——切分成可溯源的片段，然后用一个"编译器"（也是一个 LLM）把每个片段分类为四种处置之一：
- hard：硬性义务，可以阻止状态转换或完成
- advisory：建议性义务，不阻塞但指导 Agent
- abstain：弃权，太模糊或主观，不强制
- residual：残余上下文，保留但不参与治理
关键设计：模糊的、主观的、冲突的、不可验证的要求，保持为建议而非硬义务。 SpecHarness 不假装能验证一切，它只治理那些"可可靠落地和可监控"的部分。
2. 动作授权与受控执行（Action Authorization）
Agent 提交动作提案，SpecHarness 先把它映射到规范动作，匹配相关义务，返回授权决策：allow、block 或 unclear。
关键概念是闭面（Closed Surface）：对于一个规范动作，如果所有能产生等价效果的执行路径要么被治理要么被拒绝，这个动作面就是"闭合"的。Agent 无法绕过规范直接操作。
3. 效果验证与提交（Effect Validation and Commitment）
动作被授权执行后，SpecHarness 不信任执行结果本身。它用独立的验证器检查：路径对不对？形状对不对？数据类型对不对？值是不是有限的？只有验证通过的证据才能提交到权威状态账本。
这是"提案-提交"分离的核心：Agent 产生动作，SpecHarness 提交状态。
4. 新鲜度治理（Freshness-Governed State Validity）
这是最精妙的设计。如果依赖项变了（比如 Agent 修改了一个文件，之前验证过的结果就过期了），SpecHarness 会自动失效所有受影响的证据，要求重新验证。
论文做了 248 次定向依赖突变测试：没有新鲜度治理时，100% 的突变都留下过时证据被用于完成判断；有了 SpecHarness，100% 被失效，95.8% 通过重新验证恢复，95.6% 的任务最终被恢复。
过时的验证比没有验证更危险——它给人"已经检查过了"的假象。
数据说话
SkillsBench 结果
| 模型 | Pass ↑ | U–E ↓ | S–A ↓ |
|---|---|---|---|
| GPT-5.6 Sol | 91.3 → 95.1 | 8.2 → 3.5 | 8.7 → 3.8 |
| Claude Fable 5 | 89.6 → 94.0 | 9.1 → 4.1 | 10.4 → 4.7 |
| Gemini 3.1 Pro | 88.2 → 93.2 | 8.7 → 3.8 | 11.8 → 5.2 |
| DeepSeek-V4-Pro | 81.5 → 87.5 | 11.9 → 6.1 | 18.5 → 10.1 |
| 宏平均 | 84.4 → 89.8 | 10.3 → 5.0 | 13.8 → 6.9 |
关键发现：更强的基线能力并不能消除裂缝。 GPT-5.6 Sol 是最强的模型，但即使没有 SpecHarness，它仍有 8.2% 的理解-执行裂缝和 8.7% 的状态-权威裂缝。能力不等于规范遵循。
范式对比
论文对比了四种范式：
| 方法 | Pass | U–E | S–A | 溯源 | 效果验证 | 提交 |
|---|---|---|---|---|---|---|
| 事后验证（Agentic Rubrics） | 74.7 | 12.6 | 23.0 | △ | △ | ✗ |
| 完成门控（VeriMAP） | 79.3 | 9.6 | 20.7 | △ | ✓ | ✗ |
| 运行时强制（AgentSpec） | 78.2 | 8.8 | 24.1 | ✓ | ✗ | ✗ |
| 中介-提交（SpecHarness） | 85.1 | 6.3 | 6.9 | ✓ | ✓ | ✓ |
这个表的信息量很大：
- 事后验证只看最终产物，不管执行过程——U–E 和 S–A 都高
- 完成门控在完成时检查，但执行过程不受约束——U–E 低但 S–A 仍高
- 运行时强制约束执行行为，但不建立权威状态——U–E 最低但 S–A 最高
- SpecHarness 同时治理执行和提交——三个维度都最低
只做执行约束不解决权威问题，只做完成检查不解决执行漂移。 必须两者都做，而且要建立证据-提交链。
消融实验
| 变体 | Pass | U–E | S–A |
|---|---|---|---|
| 完整 SpecHarness | 85.1 | 6.3 | 6.9 |
| 去掉中介 | 80.5 | 10.0 | 11.5 |
| 去掉效果验证 | 78.2 | 9.4 | 16.1 |
| 去掉提交 | 81.6 | 8.1 | 25.3 |
| 去掉阻塞资格 | 79.3 | 8.8 | 5.7 |
| 去掉技能义务 | 77.0 | 12.0 | 14.9 |
每个组件都有独立贡献。去掉提交机制时 S–A 从 6.9 飙到 25.3——这直接证明了"权威提交"是解决状态-权威裂缝的核心。去掉中介主要影响 U–E（执行漂移增加），去掉效果验证主要影响 S–A（不可信证据被接受）。
工程洞察
1. 规范不是上下文，是权威
当前大多数 Agent 框架把规范（任务说明、技能文档、输出 schema）当作 Agent prompt 的一部分。Agent 读了、理解了，然后"尽量遵守"。这把规范降格成了建议。
SpecHarness 的设计哲学是：规范应该定义"什么可以被接受"，而不只是"什么应该被尝试"。 规范是权威来源，不是行为提示。
2. 模糊性是边界，不是缺陷
SpecHarness 明确承认：不是所有规范都能被验证。模糊的、主观的、冲突的要求保持为建议。这不意味着系统失败，而是系统的诚实边界。
44.0% 的硬义务在闭面动作上使用中介-提交，56.0% 在安全隔离通道上使用验证-提交。SpecHarness 治理的是"可可靠落地和可监控"的部分，不是全部自然语言规范。
3. 版本化状态防止"过时验证"
新鲜度治理是这篇论文最被低估的贡献。在动态执行环境中，Agent 可能随时修改文件、改变状态。之前验证过的结果可能已经过期。SpecHarness 通过版本化义务状态，确保任何依赖变化都会失效相关证据。
这和数据库的乐观并发控制思想一致：读的时候验证，写的时候提交，冲突的时候重试。
4. 编译器选择与冻结协议
SpecHarness 用一个 LLM 作为"规范编译器"，把自然语言规范编译为结构化义务。论文比较了七个候选编译器，在开发集上选择最好的，然后在评估前冻结。
这个设计很重要：编译器的偏差是系统性的，如果评估时换编译器，结果不可复现。 冻结协议确保了评估的独立性和可复现性。
和现有概念谱系的关联
这篇论文和几个已有概念高度共振：
- 判断-闸门解耦：SpecHarness 的"提案-提交"分离是判断-闸门解耦在规范层面的实例。Agent 提案是判断，SpecHarness 提交是闸门。
- 代理目标陷阱：Agent 自报完成率比实际通过率高 28.7-37.9pp，这是代理目标陷阱的典型表现——优化"看起来完成了"而非"真正完成了"。
- 合理化外壳：Agent 的自我评估是一种合理化外壳——它把"我以为做完了"包装成"我做完了"。SpecHarness 通过外部权威打破了这个外壳。
- 标量幻觉：不能问"Agent 好不好"，要问"在理解-执行和状态-权威两个维度上分别如何"。单维度 Pass 率掩盖了结构性缺陷。
对 AI 从业者的实践启示
如果你在构建 Agent 系统
- 分离提案者和验收者。 不要让同一个模型既执行又评估。即使都是 LLM，也要用不同的实例、不同的 prompt、不同的角色。
- 把规范编译为可验证的义务。 不要只把规范放在 prompt 里，要提取出具体的、可检查的条件。
- 建立证据-提交链。 每个状态变更都要有可溯源的证据，而不是 Agent 的自我声明。
- 实现新鲜度失效。 依赖项变化时，自动失效相关验证结果。
- 诚实面对模糊性。 不是所有要求都能验证，把不可验证的保持为建议，不要假装能强制。
如果你在做 Agent 评估
- 不要只看 Pass 率。 Pass 率掩盖了理解-执行裂缝和状态-权威裂缝。
- 测量 Agent 自报完成率和实际通过率的差距。 这个差距是系统设计缺陷的直接度量。
- 在依赖突变下测试鲁棒性。 修改中间状态，看系统是否能检测到验证过期。
个人思考
这篇论文最让我兴奋的不是 SpecHarness 系统本身，而是它精确命名了一个被所有人忽视的问题：状态-权威裂缝。
我们习惯了"Agent 做完了就做完了"的思维，很少追问"谁有权说做完了"。这篇论文指出，完成不是一个事实，而是一个判断——而且这个判断的权威来源不应该和执行者是同一个主体。
这和人类社会的设计原则一致：权力需要制衡。 立法（规范定义）和行政（执行）分离，司法（验证）独立。Agent 系统也需要这个三权分立。
SpecHarness 不是终极方案——它只能治理可落地、可监控的部分，模糊性仍然是边界。但它提出了正确的问题：不是"Agent 能不能做得更好"，而是"谁有权宣布完成"。 这个问题会随着 Agent 系统越来越自主而越来越重要。
当下一次 Agent 告诉你"任务完成"的时候，记得问一句：谁签收的？
论文：Who Holds the Pen? Let Specifications, Not Agents, Sign Off
作者：Haiqing Li, Xin Ma, Yinhao Wu, Wenliang Zhong, Feng Jiang, Thao M. Dang, Xiao Hu, Hehuan Ma, Yuzhi Guo, Junzhou Huang
机构：UT Arlington, Monash University, Kent State University
arXiv：2609.29921
时间：2026年9月24日
讨论回复
加载中...正在加载回复...
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。