林岚｜OC 开发者生态编辑

Pydantic 工程师在文章 The human in the loop is tired 中提出了一个正在被效率数据遮住的问题：编程 Agent 的确能制造更多代码和更多产出，但负责监督它们的人，正在承受持续检查、判断和纠错带来的疲劳。

一句话结论： “保留人工审核”不是一句安全咒语，如果一个人要同时盯着多个高速 Agent，人工本身就会成为最容易出错的环节。

过去我们理解的编程，是人写下一段代码，再等编译器或测试告诉你哪里错了。Agent 工作流不一样：人先描述目标，模型迅速改动十几个文件，然后递过来一大块看似完整的结果。工作没有消失，只是从“怎么写”变成了“它到底改了什么”。

这类监督很费神，因为错误往往不在最显眼的位置。代码可以通过测试，却误解业务边界；接口可以正常返回，却破坏权限模型；重构看起来更整洁，却让某个罕见路径丢失。人每次都要重新进入上下文，而 Agent 可以不知疲倦地继续生成下一轮修改。

更麻烦的是，产出速度会制造一种心理压力：模型几分钟写完，人却花半小时复核，审核者很容易觉得自己拖慢了进度。于是审查逐渐从逐项验证变成浏览，再从浏览变成“看上去没问题”。所谓人在回路中，最后可能只剩下一个批准按钮。

关键事实

• 编程 Agent 提高了代码生成速度，也增加了需要阅读和验证的变更量。
• 人类监督依赖持续注意力，而注意力会随并发任务、上下文切换和工作时间下降。
• 架构、边界条件和验收标准因此变得更重要，因为它们决定了机器产出是否容易被验证。

OC 判断

Agent 时代最稀缺的能力不只是写代码，而是把工作切成可验证的小块。一个任务如果没有清晰输入、边界和验收条件，模型越快，团队可能偏得越远。

这也意味着管理者不能只统计“生成了多少代码”或“完成了多少任务”。更应该统计返工、审查耗时、线上缺陷和人同时监督多少个 Agent。把一个人挂在十个自动流程后面，然后说系统具有人类把关，并不比没有把关可靠多少。

对个人开发者，一个实用办法是限制并发：先让一个 Agent 完成可测试的改动，验收后再开始下一项。让模型交付测试、变更说明和风险点，也比单纯交付几千行 diff 更有价值。

为什么重要

• 对开发者： 需要保护自己的注意力，避免把“同时跑更多 Agent”误当成生产力。
• 对团队： 验收标准、测试和小批量变更会比代码生成速度更决定最终质量。
• 对工具厂商： 下一阶段竞争点应是降低审查成本，而不只是提高生成量。

参考来源

• Pydantic：The human in the loop is tired