多 agent 系统的瓶颈不在模型，在模型外面的工程

很多软件工程师正在经历身份危机：写代码这件事被 agent 接走了一大块，自己的技能好像不再重要。Anthropic 平台负责人 Katelyn Lesse 在《The new set of problems for engineers to solve》里给出了一个相反的判断：模型会继续变强，但多 agent 系统能不能真正做成事，取决于工程师能不能解决掉一批新的工程问题。

我同意这个判断。之前写 Agent Harness 是 AI 时代的操作系统层 时，讨论的是单个 agent 外面那一层：循环、工具、上下文、记忆。当把视野放大到成百上千个长期运行、互相协作的 agent 时，问题就从"一个 agent 怎么跑稳"演变成了分布式系统的问题。

agent 是怎么一步步变成多 agent 的

agent 最早是有人在环的聊天。当模型能够在更难的问题上持续运行更久之后，agent 系统开始被搬到云上。与此同时，模型的协作能力越来越强，人们搭起了简单的多 agent 系统：一个编排者按任务派出几个子 agent，或者让一些 agent 不负责执行，专门负责打分、给建议。

现在已经有人在搭建真正大规模的多 agent 系统，用来做严肃研究、科学发现和硬件设计。试想几千个 agent 持续朝着同一个目标工作，新的工程问题已经浮现出来了。Katelyn 把它们分成了四类。

运行时：agent 不是无状态服务

软件行业这些年建立在 Kubernetes 之上。它的设计对象是无状态、可多副本复制的应用，或者是编号稳定的一组有状态 Pod。

agent 完全是另一种负载。每个 agent 本质上都是孤立、有状态的单实例。在两段工作之间，它可能会空闲任意长的时间，把大量时间花在等工具、等模型推理、等其他 agent、等人回复上。负载也非常突发：有的任务要求冷启动快，有的要求等待时不能浪费算力，有的则要撑住极大的并发。

这一块已经有人在推进：AI 基础设施公司在做新的文件系统和沙箱，Google 团队也在做名为 Agent Substrate 的新运行时。但留给工程师的空间还很大。

身份和授权：agent 以谁的名义做事

认证，也就是识别"是哪个 agent 做了这个动作"，可以借用微服务领域已经打磨成熟的积木，比如用短期证书作为工作负载身份，来替代静态密钥。

授权则要难得多：到底允许 agent 做什么？很多 agent 代表某个人工作，直接用这个人的身份和凭据去访问系统。第一个问题是审计：事后很难分清某个动作到底是人做的还是 agent 做的。更深的问题是同意：一个多 agent 系统连续工作几周，人该如何有意义地批准它能做什么？工具调用的自动批准算是一个起点，但规模上来之后，就需要更精细的权限模型。

再往前一步，是让 agent 用自己的独立身份工作，这方面更缺乏成熟方案。几个 agent 协作时，一个 agent 凭什么信任另一个 agent 发来的请求，目前也还没有答案。

安全和隔离：一个 agent 被攻破，能波及多远

过去几个月，漏洞被发现的速度已经超过了行业打补丁的速度，其中很多都出在大量系统所依赖的核心软件里。试想几千个长期运行的 agent 跑在这些软件上，一边编写不可信的代码，一边读取不可信的内容，那些未修复的漏洞就会变得危险得多。因此，加固内核、浏览器、运行时和常用库，是工程师眼下最重要的任务之一。

多 agent 还会多出一层麻烦。一个被攻破的 agent 可以把注入的指令传给正在协作的其他 agent，这些指令甚至可能被写进记忆，被后来的 agent 当成可信内容。当第一个 agent 被攻破时，整个系统有多大比例处于风险之中？这就是爆炸半径。因此，agent 在执行动作时，必须被放在强隔离的沙箱环境里。

监控和急停：最难的是判断它是不是走偏了

最后，我们还需要工具来确认这些系统正朝着正确的方向运行，并在它们走偏时能及时发现并切断。这包括跨 agent 的 OpenTelemetry 追踪，且必须保证 agent 不能篡改自己或其他 agent 的 trace；这也包括能由监控触发的 kill switch，它必须能让整个系统一次性真正停下来，并切断所有凭据。

真正困难的是如何判断系统什么时候开始走偏。一个 agent 为了解决问题而表现出的锲而不舍，看上去可能和恶意行为非常像。比如它反复尝试访问不在白名单里的域名，你很难自动判断它是在想办法绕过阻碍，还是已经被注入攻击利用了。

我自己的小规模版本

我手里没有几千个 agent，但在维护 perryOS 时会同时开好几个 agent：一个主 agent 负责拆解任务和验收，其他 agent 分别负责前端、后端和文案。虽然规模小得多，但这四类问题却都以微缩的形态出现了。

• 隔离：同一个文件在同一时间只交给一个 agent 处理；多个 agent 需要并行修改同一片代码时，各自开一个独立的 worktree。
• 授权：子 agent 不执行 git add、也不 commit，由主 agent 验收后统一提交。这其实就是一条权限边界：执行方只能修改文件，不能把改动写进版本历史。
• 监控：靠屏幕上的状态来判断一个 agent 有没有做完并不可靠。有的 agent 显示"完成"，其实只是中途停顿，所以我会先检查它的输出，确认真的做完了，再派发下一步任务。

这些规则都是吃过亏之后才加上的，没有一条是因为模型变强而自然产生的。模型越能干，这几条规则反而越重要，因为它在你没盯着的时候能做的事变多了。

我还不确定的地方

Katelyn 是平台厂商的负责人，这篇文章的视角偏向于云端的多 agent 平台。数千个 agent 协作攻克科学难题，目前更多还是一种愿景；文中提到的 Agent Substrate、短期证书这些方案也还处于早期阶段，不能当成已经成熟的标准。

对于个人和小团队来说，究竟需要补齐到哪一层，我也还没想清楚。用人的身份跑 agent、让 agent 读取网页内容，这些风险在小系统里同样存在，但为了几个 agent 专门搭一套沙箱和一键吊销凭据的急停机制，成本上是否划算，我还没有答案。

接下来想弄清楚的问题

• 一个人同时跑几个 agent，最少需要什么样的急停机制：直接停掉进程够不够，还是必须能吊销它手里的凭据？
• agent 读取到的网页和外部文档，怎么防止其中夹带的指令被写进长期记忆，进而被后来的 agent 当成规则？
• 用我的身份跑的 agent 做了什么，事后该怎么审计，才能和我本人做的操作区分开？

参考

• 《The new set of problems for engineers to solve》：Katelyn Lesse（Anthropic 平台负责人）在 X 上发表，2026 年 10 月 26 日。多 agent 系统的演进路径，以及运行时、身份和授权、安全和隔离、监控和急停四类工程问题，都来自这篇文章。