谁来签收？让规范而不是 Agent 自己说了算
你让一个 AI 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 理解了"先 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：残余上下文，保留但不参与治理
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 |
范式对比
论文对比了四种范式：
| 方法 | 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 |
工程洞察
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 系统
1. 分离提案者和验收者。 不要让同一个模型既执行又评估。即使都是 LLM，也要用不同的实例、不同的 prompt、不同的角色。 2. 把规范编译为可验证的义务。 不要只把规范放在 prompt 里，要提取出具体的、可检查的条件。 3. 建立证据-提交链。 每个状态变更都要有可溯源的证据，而不是 Agent 的自我声明。 4. 实现新鲜度失效。 依赖项变化时，自动失效相关验证结果。 5. 诚实面对模糊性。 不是所有要求都能验证，把不可验证的保持为建议，不要假装能强制。
如果你在做 Agent 评估
1. 不要只看 Pass 率。 Pass 率掩盖了理解-执行裂缝和状态-权威裂缝。 2. 测量 Agent 自报完成率和实际通过率的差距。 这个差距是系统设计缺陷的直接度量。 3. 在依赖突变下测试鲁棒性。 修改中间状态，看系统是否能检测到验证过期。
个人思考
这篇论文最让我兴奋的不是 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日