此地有怪兽：当代理承担工作时，你还需要知道什么？

# 此处有怪物：当智能体代你工作时，你还需要知道什么？ 来源：https://blog.adrq.dev/here-be-monsters-what-do-you-still-need-to-know-when-agents-do-the-work CI 挂了。这出乎意料。我已经把我的智能体工作流调到了一个程度——如果我的某个 agent 提交的分支上带着失败的测试，那我反而会感到惊讶。也许是 CI 抖动或者环境问题？等等，是 SonarQube 在报 `App.tsx` 的问题？我们是不是从 `npm` 引入了什么可疑的新依赖？都不是。SonarQube 标记的是这个文件的圈复杂度。好久没见到这个了。 果然。`App.tsx` 大约有 30 行代码，但其中 15 行实际上是 Codex 决定*每个组件各写成一整行*的完整组件。这本身还好，跑一遍 `prettier` 就搞定了。但这解释不了圈复杂度的问题。每一个都是相当复杂的组件，包含不少展示逻辑和业务逻辑。换作过去的我，会仔细重构，确保代码*可读*。另一方面，Codex 不在乎整个组件被写成一行，更重要的是，它也不在乎复杂度问题。它之前一直愉快而可靠地在那个文件上迭代了好几个功能。 CI 工具标记出了一个问题，也许正确，也许不正确。但这是一个真实的系统，所以我必须深入查看。格式化文件之后，我逐一检查了组件和逻辑。Codex 是否比典型开发者在覆盖边界情况方面做得更多，是否有一点过度设计了？是的，但一切都是*正确的*。我没有任何异议。所有的复杂度都是业务需求所要求的。于是我告诉 Codex 让 SonarQube 满意，它通过重构把代码拆分成了 10 个文件来做到这一点。CI 通过了；功能顺利上线。尽管这次事故很快解决了，你大概能想象它可能变得多糟。毕竟，这是我自己从未见过的代码。 这就是我们行业正在走向的方向：拥有一个软件系统，将越来越少地依赖你亲手写过它（或类似系统）；相反，最重要的是知道*刚好够多*的知识，能够在发现异常时及时察觉，并且愿意且有能力在需要时深入到底。 ## 潜水机器人与金块 想象你在一艘船上（你喜欢什么类型的船自己选），你的工作是从海底收集小金块。就在不久之前，如果你想装满一袋金子，你得跳进水里，游到海底，四处寻找，然后把袋子装满。如果你在清澈的浅水区，这轻而易举，但你能想象这很快会升级成困难得多的事情。所以随着浅水矿区逐渐枯竭，你和工程师同伴们建造了各种各样的机械设备和工具，从越来越深、越来越危险的水域中开采黄金。大部分时候效果不错，你和团队会精心组装、维护、轮换设备，并且不断潜入海底采矿作业现场维持运转。时不时你会听说某个采矿作业坍塌了，有时是由于巨大的水下压力，有时是因为事故，或者操作员的失误。挑战在于这是一个地质活动非常活跃的世界，所以海底不断变化，一些矿区枯竭了，新的矿区在其他地方冒出来。 不过好消息来了！过去几年里，越来越先进的潜水机器人被开发出来，它们能够独自下潜并建造一座采矿作业站。你只需要告诉它们在哪里建造，它们就会潜下去，只有浮上来时才向你汇报进展并交付金块。一切棒极了，你现在可以躺在船上放松，让潜水机器人干活，你唯一需要操心的就是船上能塞下多少金块。这是乐观派的阵营。 直到…… "等着你的潜水机器人潜得太深迷路吧。" "哈哈你的潜水机器人带回来的东西看起来像金子，其实是闪亮的章鱼粪便。" 随着潜水机器人的扩散，你看到越来越多的恐怖故事。潜水机器人迷路，忘记了自己本该建造什么。潜水机器人建造出如此复杂怪异的东西，以至于它们自己都难以维护，然后被下一代潜水机器人抛弃。所有的水下采矿作业从精心设计和工程建造的大教堂，变成了草率堆砌的豪宅，暗道密布、怪物潜伏。你越是与作业过程脱节，失败就越壮观。这是怀疑派的阵营。 ## 此处有怪物 软件工程行业（我怀疑很快许多其他行业也会如此）正在经历上述场景的一个版本。你可能已经知道自己更像乐观派还是怀疑派，即使你还不确定想加入哪个阵营。 传统的智慧是，要开发和维护一个非平凡的系统，你需要对它有一个恰当的工作模型。我想几乎没人会反对这一点。在软件工程中，你是通过直接与代码打交道来获得这个工作模型的。多年乃至数十年编写和阅读代码的实践，赋予了你理解所负责系统所需的知识和工具。每一次生产事故，每一个深夜调试，每一次成功发布。所有这些经历赋予了你拥有所负责系统的视角。在这篇文章的语境中，*拥有*意味着*出了问题时被呼叫的那个人*。 智能体（潜水机器人）正在颠覆这一切。潜水机器人的产出速度远超任何人能消化的速度，而且在过去复杂的系统中你可以假设代码至少曾经经过人类之手，但现在不再是这样了。如今，经验丰富的从业者可以管理一支潜水机器人舰队，以前所未有的规模创造软件。这些操作者懂得这门手艺，他们运用丰富的经验来管理和构建大型系统——这些系统在过去需要一个团队才能完成。但这暴露了我们行业面临的最大挑战：我们如何培养下一代工程师？ 在极端情况下，乐观派和怀疑派对此有着截然不同的答案。一方面，有权威的声音说，掌控这些系统的唯一方法是阅读潜水机器人产出的每一行代码。要能够手工编码。要能够解释每一段代码做什么以及它如何融入应用程序的上下文。另一方面，同样权威的声音说，甚至不要去看代码。把精力集中在弄清楚要构建什么上，忘掉*如何*构建。模型会搞定一切。我认为这两种观点都不对。 事实是，今天的资深工程师们学习的方式——即手工编码、无数小时的调试、生产事故——对于今天的初级工程师来说已不再是一条可行的路径。明确地说，不是经济上可行，也就是说，公司极不可能愿意资助初级工程师好几年让他们"学习手工编码"。那是痴人说梦。通常被提出的替代方案是"确保你理解 agent 写的每一行代码"的建议，或者"与资深工程师结对"，或者"执行仔细的代码审查"。同样，除了少数团队之外，这些都是痴人说梦。如果你觉得整个行业都会采纳这些做法，我有座桥要卖给你。找我。 为了找到一条在一定程度上实现精通的可行路径，我们需要审视拥有一套非平凡软件系统意味着什么。想想你心目中的典型架构师/技术负责人/CTO 以及他们的工作方式，你会发现要取得成功，他们需要在脑海中有一个系统的模型，一张水域地图。真正的问题是*细到什么粒度*？想象一个一百万行代码的历史遗留代码库，它由许多人多年来编写和扩展。CTO 甚至可能亲手写过其中一部分。现在想象出现了一个生产问题，而你是那个不走运的 SRE，凌晨两点还在排查，同时不断收到不同时区的人发来的愤怒短信。你需要什么样的系统地图？你需要一张高层级的、远距离的全局地图，你需要知道*刚好够多*——知道需要潜入哪里，*怪物藏身何处*，你需要能够跳进任何未知的代码库，弄清楚发生了什么，推送一个热修复，然后在事故报告中清晰地描述发生了什么。 请注意，这*不是*对整个系统的详尽知识。我们管理复杂系统的唯一方式是通过构建抽象。每一层让我们能再往上建一点，但无论你拥有什么地图，重要的是要记住抽象层层相套，没有人真正理解所有层。"我写了模块 X，对它了如指掌"和"我对系统的抽象有一个恰当的模型，能够潜入*任何模块*在它出问题时修复它"之间有天壤之别。手工编码给我们的是前者，但系统的拥有者——那个被呼叫的人——需要的是后者。 那么这张图景是如何构建起来的呢？如果一个人从未亲手挖过金块，又怎么能指望他潜入未知的水域去修复潜水机器人制造的烂摊子呢？ ## 基础、广度和即时深度 复杂系统中最隐蔽的一些故障是安静的故障。那种大部分时候能正常工作，但系统中总有什么*不对劲*。也许突然变慢了，或者错误率上升了，或者绝大多数时候完美运行但每第 19 次尝试就失败一次。还没到凌晨两点把你叫醒的程度，但足以让你感觉有什么不对劲。作为系统的拥有者，你需要理解系统的故障模式。作为整个行业，我们拥有教会人们如何检测和推理这些故障的工具：**基础**。好消息是我们几十年来一直在无意中把它们教给计算机专业的学生。我说的是数据结构与算法、网络、并发、分布式系统等等。这些也不必来自正规教育，这些都是你可以通过阅读自学的主题。 为了画一个简单的图景（如果你是资深工程师，请多担待），想象你派遣你的潜水机器人执行任务。你在浅水区，你把它送到水下 2 米处收集一些金块。它 4 秒后回来了，一切正常。接着你把它送到 4 米深处。这次它花了 16 秒。有点奇怪。下一次任务是水下 16 米，花了 256 秒。你明白了吧。显然有什么不对劲。在计算机科学中这叫做二次复杂度，而识别它最好的方式就是理解相关理论，*知道这样的东西存在*。 这就引出了"拥有"的第二个支柱：**广度**。我有幸合作过的大多数成功的工程师和技术领导者几乎能在任何话题上参与讨论，无论是否是技术话题。他们可能在某些领域是专家，但最令人印象深刻的是他们调用和编织来自不同学科的看似不相关的概念并用它们解决问题的能力。这就是水域的高层地图。这就是告诉你某些海域比其他海域更危险的东西。知识的广度使你能够说"我们在这里下潜"。明确地说，我不是说在每个想象得到的领域都要达到专家级别，而是刚好够多，知道出了问题时该查什么。它们是引导你海洋探索的浮标。 有人问我"我们如何教授广度？开一门包罗万象的概论课？"我当时没有好的答案。但仔细思考之后，我认为这不是一门可以教授的课程。你没有"万事通 101"可以上。我们最多能做的是鼓励人们阅读/探索/保持好奇。尽可能多地吸收信息。记住那些奇怪的事故，那些"糟糕"的时刻，思考它们如何与你的工作产生联系。随着你获得更多的经验，要有意识地将日常工作经历与你的工作联系起来。我已经记不清有多少次，多年前在一个随机项目中学到的那一点点知识在关键时刻救了场。这种经验和广度会复利累积，但必须持续维护。 "拥有"的最后一个支柱是我所说的*即时深度*。这是潜入任何问题并*搞清楚*它的能力和意愿。即使你在未知的水域。即使你必须进入笼子和鲨鱼共游一会儿。即使你必须召集你的团队，登上大型正规潜艇，潜到巨型乌贼出没的深处去弄清楚系统出了什么问题。这是为了完成工作而学习一切所需之物的意愿。这也是一种谦逊，知道何时某次下潜超出了你的能力范围，你需要寻求帮助。不是每次下潜都能独自完成；也不是每次下潜都值得去做。 几个月前，在开发我的智能体编排器时，我的智能体和子智能体遇到了稳定性和生命周期的 bug。我知道我想让它们做什么，但建造这东西的潜水机器人做得相当草率，所有的 bug 同时爆发了。当我坐在屏幕前，看着我的智能体在一小时内第 N 次崩溃，在多次让潜水机器人自己收拾残局的尝试失败之后，我想起了多年前读过的一本 Kubernetes 书（是的，我是个书呆子），"电平触发状态机"这个词突然浮现在眼前。于是我进行了一次下潜，比原计划更深，甚至追溯到了"电平触发"在电子工程中的起源。我带着我的潜水机器人一起，从头重新设计了核心架构。从那以后一直稳如磐石。这次成功的重写之所以可能，主要是因为我恰好记起了多年前读到的某些东西，并且愿意潜下去学习完成工作所需的一切。 所以你从一张海洋（系统）的高层地图开始，理解到底部都是层层抽象。而且由于所有这些抽象都会*泄漏*（https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/），作为系统拥有者，你的职责就是知道在哪里下潜以及下潜多深。这不再是通才与专才之争，甚至也不是传说中的 T 型人才。 四种技能形状：专才（一条深竖线）、通才（一条宽而浅的横线）、T 型（一条宽横线加一条深竖线）、以及拥有者（一条宽横线，加上许多不同深度的窄小下潜，最深的那条以橙色标出，末端是一艘小潜水艇 新的构建方式需要的是一个能够潜入未知深处的通才，一个"压力下的快速学习者"——不是简历注水的那种。你真的需要能够在与海怪搏斗的同时快速学习。多年来我面试过很多人，当人们在简历上写"快速学习者"时，我喜欢请他们讲讲自己不得不学习的某次经历……