当 Agent 接手更多工作，人类还能有效监督吗？

使用 Coding Agent 时，你可能遇到过这样的情况：Agent 正在修改代码，突然弹出一条权限请求。你看了一眼，觉得没什么问题，就点击批准。过了一会儿，又弹出一条请求，你再次批准。

如果任务复杂点的话，这个确认操作会重复几十次。一开始，你还会仔细检查命令和操作对象，到了后面，只要没有明显异常，就顺手点了同意。

这种“无脑”确认的习惯很容易形成。毕竟一开始我们用 Agent 就是想减少重复作业，加上前几次检查都没发现什么问题，自然会逐渐放松对后续请求的警惕。因此，省下每步的检查确认时间，自动化带来的效率也会大大提升。

但这里存在一个值得思考的问题：当 Agent 能够独立完成越来越多的工作，我们是否还具备有效监督它的能力？

在论文「AI Agents Push Humans Out of the Loop」中来自 Hugging Face 的 Margaret Mitchell、Avijit Ghosh 与 Data & Society 的 Samir Passi 就提出了类似的担忧。

作者认为，当前 Agent 的发展越来越重视自主性、任务完成率和执行效率，却对人类能否持续有效地监督系统关注不足。不只如此，长期依赖 AI 还可能削弱监督所需要的专业技能和判断能力。

监督为何会失效

为了降低 Agent 的操作风险，Human-in-the-Loop（人在回路中）一直是一种重要的设计思路。

例如，在 Coding Agent 中，执行某些命令、修改敏感文件或访问外部资源时，系统会要求用户进行授权。对于可能产生重大影响的操作，我们也可以检查结果、提出相关的修改意见，甚至是中止任务。

从流程上看，我们始终保留着对 Agent 的控制权。但是要想监督机制发挥作用，有一个前提就是负责监督的人要有足够的信息、时间和能力去判断 Agent 的行为。

随着 Agent 能力的增强，它们能做的事情越来越多。相应的，我们要理解的内容也在逐步增加。除了最终结果，我们还要关心 Agent 采取了哪些步骤、为什么改变计划，以及这些操作可能产生什么影响。

即使系统会提供完整的执行记录，人类也未必有时间逐项阅读，更难保证始终理解其中的细节。

论文指出，频繁出现的权限请求会容易造成「审批疲劳」（Approval Fatigue）。当用户反复处理相似请求时，注意力可能会逐渐下降，“无脑”批准会变成一种习惯。

而且，即使我们认真地查看执行记录，也未必能发现所有问题。比如 Agent 在修改代码时使用了错误的工具参数，意外地修改了某个配置文件。虽然我们可以查看全部执行日志，但还得理解项目结构、相关操作的上下文和代码变更之间的关系，才能找到问题的根源。

也就是说，保留监督权限，只能保证人有机会干预过程；能否发现问题、作出正确的判断并及时介入，才证明监督是否有效。

当 Agent 的执行过程越来越复杂，仅靠增加确认按钮或展示更多日志，很难解决所有问题。

自动化悖论与能力退化

比审批疲劳更糟糕的是长期使用 Agent 会让人逐渐失去一些原本熟悉的技能。

论文提到了一个早在 1983 年就被提出的概念：自动化****悖论（Ironies of Automation）。简单来说，机器接手的工作越多，人亲自动手的机会就越少。时间久了，可能连原本熟悉的工作流程都变得生疏。可偏偏机器出问题的时候，还得靠人来收拾残局。

以 Coding 例，以前开发者需要自己阅读代码、设计方案、修改文件、运行测试。现在，这些工作都交给了 Agent，自己只用在最后环节检查一下结果便好。

虽然开发效率确实提高了，但问题也随之而来。如果一个开发者长期不参与具体的代码实现，等到 Agent 写出的代码出现问题时，他可能还得花不少时间去重新理解代码结构、调用关系，以及 Agent 当初为什么这么写。

论文引用的研究还发现，一些开发者会逐渐依赖更省事的判断方式。比如，看到 Agent 的执行计划没什么问题，就默认实际操作也符合预期；或者测试全部通过，就觉得代码应该没什么毛病。但计划写得好，不代表 Agent 一定会照着执行；测试通过，也可能只是没有测到出问题的地方。

到这里，也不必恐慌。毕竟不亲自写代码，不代表一定会失去工程判断力。有经验的开发者依然可以通过架构审查、测试设计等方式，发现 Agent 实现过程中的问题。只是如果连项目的具体情况都不熟悉，平时又主要依赖 Agent 的总结和测试结果，那么 Review 就很容易变成走流程。

对于刚开始学习编程的人，这个问题可能更明显。以前遇到一个 Bug，得自己查资料、读报错、尝试修改，折腾半天才能解决。现在把问题丢给 Agent，可能几分钟就修好了。任务完成得更快，但原本能从排查问题中积累的经验，也可能少了一部分。

论文也引用了认知依赖、批判性思考和技能退化方面的研究。不过，长期使用 Agent 究竟会让人的能力发生多大变化，目前还没有足够的证据给出明确答案。

监督失效的反馈循环

论文还提出了一个值得关注的问题：人类监督质量的下降，可能反过来会影响 AI 系统的评价和优化。

目前，任务完成率、用户满意度、批准行为等指标，都是评价 AI 系统表现的参考指标。在某些训练或优化流程中，这些反馈还可能用来改进系统。

举个例子，两个用户正在检查 Agent 的执行方案。第一个用户认真看完后，发现方案有问题，于是拒绝批准方案执行，并要求 Agent 进行修改。第二个用户由于处理过大量的类似任务，没怎么看方案就点了批准，还顺手给了个好评。

如果系统主要看批准率和满意度，第二个用户的反馈反而可能让 Agent 得到更高的评价。但这里有个问题：系统怎么知道用户是真的认可方案，还是懒得仔细检查？

如果这些反馈继续被用于优化 Agent，问题就可能进一步放大。系统可能逐渐倾向于提供更容易让用户接受的方案，比如给出简短、自信的解释，让用户觉得没什么必要去做检查。

论文将这种风险与奖励机制中的漏洞联系起来。原先用来监督 Agent 的人类反馈，会因为我们没有认真审核，而无法反映 Agent 的真实表现。

当然，上述问题要成立有个前提是系统确实把用户的批准、评价等行为用于后续优化。如果这种反馈循环真的形成了，我们就需要留意后续结果。人类越来越依赖 Agent，对执行过程的了解越来越少；系统却可能因为持续收到正面反馈，认为自己的表现越来越好。

到最后，Agent 的各项指标可能都在改善，但人类发现错误、判断结果是否可靠的能力，却未必跟得上。

重新设计人类监督机制

解决上述问题，一个容易想到的办法是增加人工审核，让我们去检查更多的确认操作。

但这会加重我们的认知负担。对于已经出现审批疲劳的人类，增加确认次数未必真能改善监督效果。

论文提出，Agent 的设计需要更多地考虑人的注意力、判断能力和专业技能，并从产品设计和组织管理两个方面入手。

例如，对于低风险且经过明确授权的操作，可以让 Agent 在限定范围内自主执行；对于影响较大的决策，则提供必要的信息，让用户充分判断后再作决定。

对于复杂任务，也可以按任务阶段组织审查，让用户集中检查相关操作及其变化，减少零散权限请求带来的反复打断。

作者还提出了一个有些反直觉的建议：在重要决策中，有意识地保留一些思考环节。

例如，在看到 Agent 的建议前，先让用户形成自己的判断；在批准高风险操作时，引导用户检查关键假设和证据。

这些设计可能增加一些操作成本，但也能减少用户对 AI 建议的盲目接受。

在组织层面，论文建议通过定期独立完成任务、岗位轮换和专业技能训练，帮助员工保持对实际工作的熟悉程度。监督质量也可以通过审核行为、错误识别能力等指标来评估。

当然，这些方案也有代价。额外的审核会影响效率，行为监测还涉及隐私和管理问题。因此，监督机制仍需根据任务风险和实际场景进行调整。

论文希望强调的是，人类的监督能力应该在 Agent 的设计阶段就得到重视，而不是等系统开发完成后，再靠增加审批环节来弥补。

结语

Agent 的发展正在改变人类参与工作的方式。

过去，人们亲自执行任务，AI 提供建议和辅助。随着 Agent 自主能力的提升，越来越多的工作交给了系统，人类则更多地负责设定目标、检查结果和作出关键决策。

这种变化提高了工作效率，也对人的监督能力提出了更高的要求。我们希望 Agent 能独立完成更多任务，但当它出现问题时，仍然需要有人能够发现错误、判断原因，并在必要时接手处理。

这也引出了论文最值得思考的问题：当我们逐渐从任务执行者转向 Agent 的监督者，是否具备了与之匹配的能力？

未来评价 Agent，除了关注它能完成多少任务、效率有多高，或许还应该考虑人类能否理解和掌握它的执行过程。

毕竟，Agent 的能力在不断提升，人类的监督能力也需要跟得上。