用 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 能力越强，能干的事越多，需要我们搞懂的东西也就越多。除了最后的结果，你还得关心它走了哪些步骤、为什么改计划、这些操作可能带来什么影响。
就算系统把完整执行记录都给你，你也未必有时间逐条看，更不敢说自己每条都看明白了。
论文里提到，权限请求来得太频繁，会催生 "审批疲劳"（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 的能力一直在涨，人的监督能力，也得跟着涨才行。
