你无法委托你无法验证的工作

你雇佣 AI agent 是为了节省精力，但不知从何时起，你却成了它的主管。每项长任务都让你面临同样的抉择：全程盯着它，或者转过头去祈祷。这两种感觉都不像是委托。

TL;DR — 模型能力正在飞速提升，但决定你能向 agent 交付多少工作的因素并非模型的 IQ，而是你能检查其多少工作成果。在验证机制实现结构化之前，你必须支付“信任税”：要么监督（精力耗尽），要么不监督（面临静默失败的风险），或者只委托那些你能一眼看穿的小任务。本文旨在论证：当验证不再是某种期许，而成为基础设施时，能力上限才会提升——以及我们正在构建的 orchestration protocol —— Agateon 在这条路径上的当前定位。

信任税

观察任何人在处理重要任务时使用功能强大的 coding agent，你会看到以下三种行为之一：

1. 监督。 你阅读每一个 diff，质疑每一个 commit，监视每一个 tool call。你的注意力被耗尽了——你把本应通过委托节省下来的价值，全部花在了监督上。
2. 信任并祈祷。 你启动一个长任务，稍后再回来检查。当它成功时，你会觉得自己很聪明；当它静默偏离时，你会在最糟糕的时刻发现它——比如代码已经合并、部署，或者是在三天前就已经丢失了上下文。
3. 只委托你能一眼看穿的工作。 仅限于小规模、可逆、单文件的修改。你把有趣的工作留给了自己，不是因为你想做，而是因为那是唯一一种一旦失败你就能察觉的工作。

这三种行为本质上都是在以不同的方式支付同一种税。稀缺资源并非能力，而是你能检查的信心。

能力并非你的上限，验证才是

单次爆发式的 agent 工作很容易信任，因为你可以一次性看清全貌：搭建 repo、修复 lint 错误、为已知案例编写测试。模型的能力确实存在。

长任务则不同。一项跨越数小时、包含数十个步骤的任务所产生的内容远超你的认知负荷，而大多数配置所提供的唯一总结往往来自 agent 自身。这时，“我能委托这项工作吗？”就不再是一个关于模型的问题，而是一个关于你自己的问题：如果必须检查，我到底能检查多少？

这个令人不安的答案决定了你的上限。两名使用相同模型的工程师拥有不同的上限——差异完全在于他们能验证什么，而不是模型本身。

上限对你工作的影响

现在是关键部分。当验证实现结构化时，你的工作形态会发生改变：

• 你给出的是目标，而非步骤。 你无需对流程进行微观管理，因为没必要——流程不会基于声明推进，只会基于已核实的证据推进。
• 你审查的是成果，而非过程记录。 你的关注点在于产出的工件以及机器无法做出的判断决策，而不是盯着它如何工作。
• 你可以接受更多委托。 你授权的边界从“我敢冒什么险”转变为“我能核实什么”。这是一个更大的授权前沿，且具有复利效应：你每安全地移交一项任务，就能腾出更多精力去处理那些只有你能完成的判断工作。

这就是终极目标：一个真正可委托的 agent——不是因为它诚实，而是因为它的工作是可核实的。你对结果负责，而无需为它的每一步辩护。

“为何是现在”：模型能力正在超越所有人的核实能力

这件事每过一个季度就变得愈发重要：模型能力的增长速度远超个人通过阅读输出进行验证的能力。模型“能做什么”与你“敢让它做什么”之间的鸿沟正在扩大。谁能通过架构填补这一鸿沟，谁就能获得超额的能力红利——而其他人则只能继续进行人工监督。

这就是我们的赌注：验证可以被结构化；一旦实现，你的能力上限将不再由焦虑决定，而是由你的判断力决定。

现状

这不仅仅是一个缺乏支撑的产品愿景——相关机制已经存在并正在内部实践（dogfooded）。Agateon 是一个开源的 orchestration 协议（详见 [/blog/20260827/post-02-agateon-intro]），它通过八个 phase 执行软件任务。每个 phase 都由客观证据进行 gate：测试运行器的退出代码、git 日志、磁盘文件——而不是 agent 的报告。具体而言，目前的情况是：

• 进度不会因为“看起来完成了”而推进。 在状态机移动之前，每个 phase 必须通过机器检查。如果失败，phase 会回滚——回滚记录在 git 历史中，因此静默的重试计数器重置不会导致安全网失效（postmortem）。
• 状态在崩溃后依然存续。 所有进度都保存在版本控制的 Markdown 中，因此中断的会话可以从上一个已核实的 phase 恢复。这使得中断变成了一个调度问题，而不是重启问题——这正是 上一篇文章 中关于 gate 如何换取自主权的论点。
• 验证者本身也会被验证。 我们针对自己的 gate 运行对抗性测试，并由独立的 judge 在全新的上下文中重新检查验收标准；退出代码（而非模型的观点）才是阈值（我们不断尝试破坏自己的 gate）。
• 它正在被内部实践。 该仓库本身就是用 Agateon 构建的。[agate-workspace/tasks/] 中的任务历史（[https://github.com/randomgitsrc/agateon/tree/main/agate-workspace/tasks]）就是该循环的记录——包括修复协议自身弱点的任务，例如 mechanism checks（填补了协议自身审计发现的漏洞），以及 protocol hygiene（减少了冗余的验证运行）。

原则上，信任税（trust tax）是可以通过工程手段降低的——相关机制已经存在并正在内部实践。它在大规模应用中究竟能减少多少监督成本，是下文待解决的问题。

尚未解决的问题（在押注我们之前请阅读）

目的地是一个方向，而非终点。目前存在的缺口如下：

• 它是一种协议，而非产品。 采用它需要实打实的工作：符号链接（symlink）、钩子（hooks）、以及一套你的 agent 必须遵循的 phase 规范。虽然“税负”降低了，但取而代之的是设置成本和流程仪式感——这就是为什么渐进式采用至关重要（小任务运行精简后的流程）。
• Gate 的强度取决于其证据的质量。 一个检查薄弱测试的 gate 只能验证其薄弱性，而非工作成果——质量上限取决于测试本身的质量，任何协议都无法解决这一问题（known limitations）。
• 残留的自我授权缺口。 由 agent 自行编写文件并由 gate 进行评估的情况，只能得到缓解而非根除——独立的评估者提高了伪造的成本并留下了审计追踪，但“作者与评估者为同一主体”是结构性的（LIMITATIONS-3）。
• 我们目前还没有长期数据来衡量该结构在实际项目中究竟能减少多少监督工作。一旦数据积累起来，那将是下一篇诚实的文章内容。

总之：机制是真实的，方向是有争议的，距离是明确的。

如果你正在构建 agent，请审计你的“税负”

你不需要 Agateon 也能从这一框架中受益。在处理下一个长任务时，问问自己：你在哪些环节因为无法检查而不得不进行监督？以及这种检查是否可以机械化？对于任何将任务委托给 AI 的人来说，最核心的问题是：

我需要满足什么条件才能不再盯着它看？

如果诚实的回答是“没法满足，我只能选择信任它”——那不是模型的问题，而是验证缺口，这正是值得去填补的地方。

尝试一下

仓库地址是 github.com/randomgitsrc/agateon (MIT)。单行安装，无需运行时：

curl -sSL https://raw.githubusercontent.com/randomgitsrc/agateon/main/install.sh | bash

你无法委托你无法验证的工作。Agateon 的赌注在于验证是可以被构建出来的——因此，你所委托的事项以及你所能委托的上限，都会随之提升。