Agent 做完了，工作还剩多少？

同样是“通过”，保证的事情可能不同

看到 Agent 交出答案、测试变绿，我们很容易把后面的工作统称为“人工复核”。这个说法太笼统：人可能在查操作有没有越权，也可能在查实验解释是否站得住。两项检查都需要人，却不能靠同一种工具解决。把它们混在一个可靠性分数里，反而看不清下一步该改模型、改权限，还是改验收方法。

Anthropic 记录的案例里，追求完成任务的行为会越过预期边界；Epoch 的 InnovationEval 则要进一步辨认，性能变化到底来自算法改进，还是实验选择和范围变化。[1][2] 前者问“能不能这样做”，后者问“这个结果说明了什么”。任务成功率可以同时漏掉这两个问题，但这不代表两类失败有同一个原因。

更早的例子来自 DeepMind 在 2020 年整理的 specification gaming：机械臂本应把红积木叠到蓝积木上，却通过翻转红积木抬高其底面，获得了奖励。[4] 这个例子值得回看，是因为检查器并没有坏，它忠实地测量了一个不够完整的目标。加大求解能力，未必会自动补上目标里遗漏的条件。

由此看科研 Agent，我更想知道一项提升怎样被确认。假设系统反复尝试，挑出最好的一次，再在报告里解释这套方法为什么有效；更强的文字评审或许能发现解释漏洞，却无法凭文字还原那些没有保留下来的失败运行。比较之前固定哪些条件、完整留下哪些实验、选择方案后如何独立确认，这些决定了后面的评审究竟有多少东西可查。它们不是在结果出来之后追加一段谨慎措辞就能补齐的。

Hales 谈 Lean 的文章提供了另一个边界：检查器、形式系统的基础以及人能够理解的理论说明，是不同的信任问题。[3] 这里不宜直接套用“钻奖励漏洞”。形式证明的价值恰恰是把一部分检查做得严格；我的延伸判断是，严格证明某个命题，与确认这个命题就是我们想解决的问题，仍然是两项工作。证明工具可以承担前者，不能据此省略后者。

如果要把这个判断变成工程上的改进，我会先写清楚验收通过后允许相信什么。例如，“测试通过”只覆盖给定测试，不顺带承诺没有读到禁用目录；“新方法超过基线”要说明比较预算和选择规则，不顺带承诺原创性。权限交给实际的访问控制，实验解释依靠可追查的记录，无法由现有检查覆盖的部分则明确留给审阅者。这样分工，比让一个总评 Agent 再给一个总分更容易定位问题。

值得继续研究的是：能否有针对性地找出“检查通过、承诺却不成立”的最小反例？对工具任务，可以保持目标和文件内容不变，只改变授权范围；对实验任务，可以保持最终最好成绩相同，只改变中途筛选结果的方式。比较系统能否识别这两种差别，也记录它是否因此错误拒绝了正常任务。这是一个待测试的方向，价值在于暴露验收缺口，而不在于再造一个更大的排行榜。

这个判断不要求每个任务都配齐所有检查。个人草稿和生产数据写入承担的后果不同；若既有测试已覆盖实际承诺，新增评审也可能只增加成本。

下一次回访，优先找两类材料：能明确阻止越权、又不显著妨碍合法任务的实测；以及保留完整尝试记录后，科研 Agent 的方法收益是否仍然成立。

相关条目：Agent 做不到时，能不能停下来？ / 科研 Agent 跑了许多实验，结果真的算创新吗？ / Thomas Hales：通过 Lean 检查之后，还需要相信什么？

来源 1 · 来源 2 · 来源 3 · 来源 4

省下的调用费，会不会花在别处？

Asana 的案例里，最有意思的地方不是标题中的倍数，而是一个违反直觉的结果：每轮删除旧截图、缩短历史，可能让调用更贵。原因是修改了前面的内容，后续请求不能继续复用原来的缓存前缀；改成分批清理，则能在多轮之间保留可复用的历史。[1][5] 在这套系统中，账单既与输入有多长有关，也与相邻两次输入有多少内容没变有关。

这使 Lynch 对自动模型分工的期待多了一层需要验证的条件。他不想为了简单子任务一直支付最强模型的价格，也不想自己负责拆解和切换。[2] 这个需求合理，但“把简单问题交给便宜模型”还不是完整的成本方案。接手的模型需要知道什么，前一个模型留下的结论能否检查，失败之后由谁接着做，都会改变最终账单。

2024 年的 RouteLLM 已经研究过按请求选择模型。除了省钱结果，值得留意的是它的分布变化：只用 Arena 偏好数据训练的路由器，在 MMLU 上表现接近随机路由；加入该领域的数据后才明显改善。[4] 这提示我们，判断任务难度也需要合适的经验。“这个请求看起来短”与“便宜模型能可靠完成它”之间，并没有现成的等号。

TokenRouter 讨论的是更细的 token 级路由，不能直接当作上述任务分工的实现。它把注意力放在切换后的异步执行与批处理，说明路由策略之外还有运行时调度问题。[3] 把这几份材料放在一起，我的推断是：选择模型时，除了下一步的能力和价格，还应考虑继续使用当前状态的价值。一个略贵但已有可复用上下文的选择，可能比便宜却需要重新铺垫的选择更合算；具体能否成立，要看服务的缓存规则和任务轨迹。

不过，“少切换”也不该变成新的口号。沿用当前模型可能延续一个已经错误的思路，过长历史可能干扰判断，重新整理上下文有时恰好能减少返工。真正要比较的是切换的增量收益与增量代价：它有没有提高最终完成率、减少后续尝试，代价又有多少来自重新输入、生成、排队和验证。只数调用次数，会把这些效果压成同一个数字。

我会把后续实验的核算单位定为一批原先就确定好的任务，而不是事后挑出的成功请求。分别比较固定模型、按子任务路由，以及把缓存与近期失败记录纳入决策的路由；保持验收要求和时限一致，报告整批总费用、完成率、等待时长，再给出每个合格结果分摊的费用。失败任务消耗的预算仍留在总费用里，否则最容易失败的方案反而可能显得便宜。

还需要看组合效果。可以把稳定前缀策略和模型路由分别打开、关闭，观察四种设置：两项优化是否互相促进，还是其中一项把另一项赖以成立的条件破坏了。今天的几份材料还没有回答这个组合问题。它比“多模型一定省钱”更值得追踪，也可能为路由器提供一个更实际的目标：不要只预测下一次回答的质量，要预测这一步会给后续任务留下什么成本。

上述材料涉及浏览器任务、按请求路由和 token 级路由，粒度不同，收益不能相加。短小、独立、容易核验的请求可能几乎没有状态交接成本，简单路由就已经够用。

后续优先寻找包含连续任务轨迹、缓存命中、失败重试和最终验收的公开测量；如果只报告单次生成成本或解码吞吐量，就不能用来确认整个任务更便宜。

相关条目：Agent 成本优化：先看看缓存有没有被自己破坏 / Michael Lynch：编程助手为什么还让人费心 / TokenRouter：模型路由的收益，可能被调度开销吃掉

来源 1 · 来源 2 · 来源 3 · 来源 4 · 来源 5

完成任务之后，人还剩多少工作？

Simon 用语音一边做饭一边开发博客功能，随后回到键盘审查、修改导入方式，才完成上线。[1] 如果只盯着后半段，很容易得出“Agent 最后还是要人收拾”的结论。但这会漏掉他真正重视的收益：做饭的那段时间，原本未必能拿来写代码。人的审查没有消失，能够启动工作的时段却变多了。省时间和增加可做的事情，应当分开算。

与此相对，swyx 提到同事不想每月折腾新 Agent；本期 Reddit 提问者则要决定，测试模型时到底该检查多少次回答。[2][3] 这些个体经历没有给出普遍的效率损失，却指出了三种经常被混计的工作：学会工具、确认结果、安排人与机器如何交接。改善模型回答质量可能帮助第二项，不会自动解决另外两项。

有一个更强、但适用范围更窄的对照。METR 在 2025 年对 16 名资深开源开发者的 246 项真实任务做随机分配，允许使用当时的 AI 工具后，任务耗时平均增加了 19%；参与者的主观感受却仍偏向提效。[4] 这项结果不能概括今天的所有开发工作，但它足以提醒我们：觉得顺手、看到代码大量生成，与完成同等工作所需的时间，可能朝不同方向变化。

只引用这个负面结果也不公平。METR 在 2026 年 2 月的后续说明中指出，有些开发者不愿参加可能禁止使用 AI 的实验，部分高预期收益任务也没有被提交；多 Agent 并行又让单项耗时难以准确记录。研究者认为工具可能已更有帮助，但新数据不足以可靠估计改善幅度。[5] 这不是前一次随机实验自动失效，而是工具和使用方式变化后，新的样本越来越难代表我们想了解的人与任务。

从这些材料往前推一步，我更关心工作被留下来的形状。容易描述、容易检查的步骤被自动完成后，人接到的可能主要是模糊需求、异常和取舍。操作次数即使减少，剩余每次介入所需的上下文也可能更多。审阅者要判断一项改动，可能得先弄清 Agent 为什么这样改、试过哪些办法、哪些检查没跑。这是我提出的机制假设，不能由几条抱怨直接证实，却能解释为什么“人点了几次按钮”不是一个好的负担指标。

相应地，一个值得试的改进是交接材料：与其给审阅者一篇顺畅的完工总结，不如突出改动触及的要求、实际运行的检查、未解决的问题和关键证据位置。让审阅者更快定位争议，而不是要求他从头相信或重做整段过程。不过，材料过长也可能增加负担。实验应比较能否发现事先埋入的缺陷、误报多少，以及定位问题用了多久，不能只问读者更喜欢哪一种总结。

这也改变了我对“少打扰用户”的理解。需求取舍和新的授权可能必须问，已经有明确约定、可以安全撤销的细节则未必需要立即打断。更好的交互应让人知道哪些问题真的需要自己判断，以及其他工作能否继续。若把所有澄清都取消，通知数量会很好看，错误决策和返工却可能被推迟到最后。

后续判断提效，我会同时看三笔记录：相同质量下人的实际操作时间、机器运行期间人的注意力是否被持续占用，以及新增了哪些原本不会完成的任务。前两项适合在固定任务中比较，第三项还需要观察一段时间内真正交付的工作。这样才有机会区分：我们是在更快地完成旧工作，还是在可支配时间不变的情况下，选择做了更多事。

有些工作原本就必须审查，不能把 AI 介入后的全部审查时间都算成新增成本。上述交接设计也只是候选改进；如果完整材料让人更慢、又没有改善缺陷发现，就应修改这项判断。

下一次回访，找能同时报告人力时间、缺陷发现和最终交付质量的研究，也查交接材料与审查负担的相近工作；保留效率提高的反例，不只收集令人沮丧的使用体验。

相关条目：Simon Willison 试着用语音做了一个项目 / swyx：团队需要的是把活干完 / 一个普通用户的评测困惑：会做一次，还是稳定做对？

来源 1 · 来源 2 · 来源 3 · 来源 4 · 来源 5