← 最新论文
💻 computer science

Human oversight of agentic systems in practice: Examining the oversight work, challenges, and heuristics of developers using software agents

通过对17位资深开发者的访谈,本文从实证角度刻画了在与自主软件智能体协作时所涉及的主动型与响应型监督工作、相关挑战以及开发者所采用的实践启发式方法,从而弥合了理论框架与现实实践之间的鸿沟。

原作者: Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu

发布于 2026-06-05
📖 1 分钟阅读☕ 轻松阅读

原作者: Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu

原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

想象一下,你雇佣了一个速度极快、极其聪明但又有点混乱的机器人助手来帮你盖房子。这个机器人可以砌砖、刷墙,甚至能自主设计水管系统。但问题在于,它有时会忘记检查墙壁是否承重,有时会试图用地板漆去刷天花板,偶尔还会决定把门安在窗户本该在的位置。

这篇论文探讨的是人类开发人员(即“建筑师”和“工头”)在现实世界中究竟是如何管理这些机器人助手(称为“软件智能体/agents”)的。研究人员采访了 17 位每天都在使用这些工具的资深开发人员,以查明:他们究竟在做些什么来约束这些机器人,以及当事情出错时,他们是如何处理的?

以下是他们的研究结果,使用了简单的类比进行说明:

1. 旧观点 vs. 新现实

旧观点: 大多数人认为监督机器人就像是在大门口当保安。你等着机器人完成工作,然后走上前看一眼成品,说:“嗯,这看起来不对,修一下。”这被称为反应式(reactive)监督。

新现实: 研究人员发现,开发人员实际上在做更多的事情。他们扮演着副驾驶和安全工程师的角色,甚至在机器人开始移动之前就开始行动了。他们意识到,等到最后才检查风险太大了。相反,他们通过四种不同的方式来管理机器人:

  • 设定规则(事前控制 / A Priori Control): 在机器人开始工作之前,开发人员会设置严格的“围栏”。他们可能会说:“你可以使用这些工具,但绝对不允许删除这个文件夹里的文件,”或者“始终遵循这个特定的风格指南。”这就像是在把狗带进公园之前,先给它套上牵引绳并发出“坐下”的指令。
  • 共同规划(协同规划 / Co-Planning): 开发人员不再只是简单地说“盖一栋房子”,而是会和机器人坐下来讨论:“好,我们把任务拆解一下。首先,我们打地基;然后,我们搭建框架;如果遇到岩石,就停下来问我。”他们共同编写一份详细的步骤地图,这样机器人就不会迷路或自作主张制定疯狂的计划。
  • 实时监控(实时监控 / Real-Time Monitoring): 有时,开发人员会盯着机器人干活。然而,研究发现这种情况很少见。为什么呢?因为机器人的速度太快,且任务拆分得非常细小,开发人员通常会让它们运行完再检查结果。这就像盯着微波炉看一样;你不会一直盯着它,而是在“叮”的一声响后去检查。
  • 最终检查(事后审查 / Post Hoc Review): 这是每个人都预料到的部分。一旦机器人完成了工作,人类就会检查成果。但由于机器人可能做了成千上万个微小的改动,这就像是在试图从一本由别人写的 500 页书中找出一个错别字一样,既困难又累人。

2. “足够好”的捷径(启发式方法 / Heuristics)

论文中最大的惊喜是,开发人员并不追求完美。他们太忙了,而且机器人也太复杂了。相反,他们使用心理捷径(启发式方法)来高效地完成工作。可以将这些视为避免职业倦怠的“经验法则”:

  • “计划即真相”捷径: 开发人员通常假设,如果机器人的计划看起来很好,那么生成的代码也一定没问题。他们会检查机器人的待办事项清单,而不是阅读每一行代码。这就像是因为厨师的食谱看起来很完美,你就信任他,而不需要品尝每一口汤。
  • “测试通过,一切正常”捷径: 如果机器人的代码通过了所有自动化测试,开发人员就认为代码是正确的。他们不再去查看实际的代码内容。这就像汽车修理工说:“如果引擎灯没亮且通过了排放测试,我就不需要再拆开引擎盖检查了。”
  • “快速扫视”捷径: 开发人员不会阅读全部内容,而是通过“扫视”来观察变化。他们寻找明显的红旗信号,比如一个名字不合理的函数。这就像老师快速浏览一叠试卷,看看学生是否写了一些东西,而不是逐字逐句地评分。
  • “信任专家”捷径: 如果开发人员不熟悉某项特定技术(比如一种新的编程语言),他们就会直接信任机器人。他们会想:“我不懂 Go 语言,但机器人说它能行,那我就相信它。”这就像包工头信任专业的水管工处理管道,而不需要亲自去核查水管规范。

3. 重大挑战

即便有了这些捷径,开发人员仍面临着棘手的问题:

  • “黑盒”问题: 有时机器人会做出一些奇怪的行为,而开发人员无法弄清楚为什么。机器人可能会说:“我这样做是因为原因 X”,但开发人员知道那是谎言。这就像 GPS 让你绕路,却拒绝解释原因一样。
  • “陌生人的代码”问题: 阅读不是由自己编写的代码要困难得多。开发人员觉得这就像在读别人的手写体;理解起来需要花费两倍的时间。
  • “毁灭循环”问题: 如果开发人员发现一个错误并要求机器人修复,机器人可能会在修复过程中搞砸其他东西。现在,开发人员必须重新检查整个系统。这就像修好了一处水管漏水,却不小心弄爆了第二根水管。

4. 这对未来意味着什么

论文总结道,软件开发人员的角色正在发生变化。他们正从匠人(亲手砌好每一块砖)转变为管理者(雇佣、指导并检查他人的工作)。

研究人员建议,我们用来构建这些机器人的工具也需要改变,以便更好地辅助人类进行这种“管理”工作。例如,工具不应仅仅展示一整面代码墙,而应该展示一张清晰的地图,显示机器人的意图与其实际行为之间的差异,从而减轻“检查”阶段的痛苦。

简而言之: 人类不仅仅是在等待机器人犯错;他们正在设定规则、规划旅程,并利用聪明的捷径来确保机器人步入正轨。但目前,工具的设计还不足以让这种“管理”工作变得轻松,因此人类在维持系统安全方面依然承担着大量的重任。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →