工程师觉得自己要失业？多 Agent 真正卡在软件工程
本文依据 Anthropic 平台负责人 Katelyn Lesse 在 2026 年 10 月 26 日发的 X 长文整理，并加上我自己的判断。
原文标题是 The new set of problems for engineers to solve。
她的核心判断很硬：模型再强，也解不开多 Agent 系统的硬问题，要靠软件工程。
很多工程师正经历身份危机。
有人抑郁，有人兴奋得不行。
Katelyn 的看法是，这恰恰是做工程最好玩的一段窗口。
AI 想兑现那些夸张结果，离不开工程师把底层问题先解掉。
这是存在级的事，也是乐趣所在。
我读完这篇，觉得她把工程师焦虑的出口，钉回了可动手的问题域。
多 Agent 已经走到哪一步了？
Agent 起初只是人机对话，人在环里，一步一步点。
模型能跑更久、啃更难的题之后，系统开始往云上搬。
再往后，模型协作变强，有人做出基础多 Agent 结构。
比如一个编排器拉起若干子 Agent。
又比如给 Agent 分工，不只执行，还负责评分、建议，甚至做梦。
现在更狠的一档出现了。
有人开始用上千个持久运行的 Agent，去做严肃研究、发现和硬件设计。
规模一上来，工程问题就不再是边角料。
Katelyn 把它们收成四块。
基础设施是一块。
身份与授权是一块。
安全与隔离是一块。
监控与熔断是一块。
下面按这四块掰开讲。
为什么 K8s 扛不住 Agent 负载？
软件业这些年几乎都建在 Kubernetes 上。
K8s 擅长无状态副本，也擅长稳定编号的有状态 Pod 集合。
Agent 是另一类东西。
它本质是隔离、有状态、单实例负载。
两段工作之间，它可以空转任意久。
大量时间花在等工具、等推理，也花在等别的 Agent 或人。
有的任务要启动快，有的要省算力，有的要疯掉级别的规模。
旧调度模型对不上这种波形。
所以行业里已经有人在推新 runtime。
AI 基建公司在推新文件系统和沙箱产品。
Google 团队也在做 Agent Substrate 这类新 runtime。
这块还空着大片未解空间。
我自己的判断是，谁先把「空转可挂起、唤醒可秒级、状态可搬家」做成默认能力，谁就握着下一层平台入口。
提示词再花，也救不了调度错配。
我们过去习惯的服务画像，是请求进来、处理完、立刻腾出资源。
Agent 更像一个长期工位，人走开了，工位还在，工具还摊着。
用副本扩缩容的老办法硬套，要么烧钱空转，要么唤醒太慢，把长程任务打断。
身份好借，授权为什么更难？
认证这块，微服务世界已经交过学费。
workload identity、短时证书，比静态密钥靠谱得多。
这些积木可以直接搬到 Agent 上，用来回答「是哪个 Agent 动了手」。
难的是授权。
你到底允许一个 Agent 做什么？
很多 Agent 代表人类工作，借用人类身份和凭证去碰各种系统。
这里已经有坑：日志里看见的是人，实际动手的是 Agent。
更深一层是 OBO，也就是 on-behalf-of 同意问题。
多 Agent 系统能跑好几周。
人怎么对「它接下来还能干什么」给出有意义的批准？
平台上的工具调用自动批准能救急，但高规模下需要更深的权限分层。
还有 Agent 自己的身份。
这块更空白。
Agent 跟 Agent 协作时，一方凭什么相信另一方递过来的请求？
所以身份系统要从「认出你是谁」，推进到「同意你在多长时间内、对哪些资源、以什么半径行动」。
没有这层，协作规模越大，事故半径越大。
我们常见的产品形态，还停留在「给你一个 API Key，爱怎么调怎么调」。
放进上千 Agent 的网格里，这等于把金库钥匙挂在公共走廊。
同意必须可撤销，范围必须可收窄，时间必须可过期。
否则所谓多智能体，只是多把无人看管的钥匙。
被攻破的 Agent 会传染同伴吗？
过去几个月，尤其最近几周，漏洞冒出来的速度，已经快过行业打补丁的速度。
很多洞落在内核、浏览器、运行时这些底座，也落在常用库上。
现在再想象一下：上千个持久 Agent 跑在这些底座上，一边写不可信代码，一边读不可信内容。
未打补丁的洞，在这个场景里危险得多。
多 Agent 还多了一层拧法。
一个被攻破的 Agent，可以把注入指令传给同伴。
那些指令还能写进共享记忆，被后来的 Agent 误信。
爆炸半径一下子变得很具体。
第一个 Agent 失守时，整张网有多少暴露面？
所以隔离不是锦上添花。
Agent 做动作时，应该待在强隔离的沙箱里。
Katelyn 另有一篇 sandbox 长文，讲得更落地。
核心架构选择是把「脑子」和「手」拆开。
harness、会话状态、凭证放在你信任的持久侧。
沙箱只负责执行。
沙箱要出网，走出口代理，由代理按目的地注入凭证。
这样杀开关不在被杀对象内部，密钥也不跟不可信代码睡一张床。
隔离层级上，她更倾向 microVM 一类边界，由 CPU 虚拟化硬切。
普通共享内核的容器，不该当安全边界用。
沙箱还要默认拒绝出网，白名单尽量窄，用完即毁。
这些听起来像运维细节。
放到上千 Agent 的持久网格里，它们就是产品能不能上生产的门槛。
我见过太多演示，默认把 Agent 和密钥塞进同一个盒子，浏览器与文件系统也跟着挤进去。
演示好看，生产不敢开。
脑子和手拆开之后，安全属性变成结构问题，而不是靠红队运气。
如何判断执着和恶意？
监控与熔断是第四块，也是最容易被产品经理低估的一块。
系统往正方向走，要能看见；往歪了走，要能一把掐死。
跨 Agent 需要不可篡改的 OpenTelemetry trace。
任何一个 Agent，都不该改自己的 trace，也不该改同伴的。
还要有真正的 kill switch。
监控一触发，整系统同时停，凭证一并切断。
难的是判定。
善意的执着，外表很像恶意。
比如反复去碰不在白名单里的域名。
你很难说清，它是在死磕解题，还是在试探边界。
所以熔断规则不能只靠「看起来怪」。
要有可解释的策略层：允许域、重试上限、时间窗，以及人工升级路径。
否则要么误杀好任务，要么放过真事故。
我们如果只盯模型回答漂不漂亮，会把真正的风险漏在执行层。
trace 不可篡改，是事后审计的底线。
kill switch 在盒子外，是事中止血的底线。
两样缺一，多 Agent 就只适合内部 demo。
这跟「工程师要失业」有什么关系？
回到开篇那句身份危机。
很多人焦虑的是，模型会写代码了，自己的技能还值不值钱。
Katelyn 的回答很直接。
你的知识和判断，可能就是这些开放问题能不能被啃下来的差值。
模型会继续变强。
多 Agent 也会继续变强。
但力量能不能解锁，世界敢不敢把治病、发现和硬件设计交给它，取决于工程师有没有把基建与授权、隔离与熔断做出来。
我同意这个判断，而且愿意再往前推半步。
过去一年，市场上最吵的是提示词、人格、工作流模板。
真正能长期卖出去的，是可隔离、可授权，并且可熔断的工程能力。
MangoFund 做技能商店和一人产品相关内容时，我们也越来越清楚这一点。
卖一段会说话的提示词，门槛低，也容易被下一版模型抹平。
卖一套能管住 Agent 手脚的工程件，才跟生产系统同频。
当然，不是每个工程师都要立刻改行做 Agent runtime。
你可以先选一块深挖，形成自己的看法。
这块问题域还很空，新解法进场成本相对低。
前面讲到的身份危机，其实是错把「写业务代码的熟练度」当成了全部身价。
熟练度会被模型压缩。
对隔离边界、授权半径、熔断策略的判断，短期内更难被压缩。
你可以收藏的下一步清单
如果你也在经历身份危机，或者正在搭多 Agent，可以按这张清单自检。
- 你的 Agent 是无状态副本思维，还是单实例有状态负载？调度模型对不对得上空转与等待。
- 日志里分得清「人动手」和「Agent 代劳」吗？短时证书有没有替代静态密钥。
- OBO 同意有没有时间窗和范围？跑几周的任务，人怎么持续批准。
- Agent 互信有没有显式策略？别默认「能连上就能信」。
- 脑子和手拆开了没有？凭证是否还和不可信代码关在同一间沙箱。
- 隔离边界是共享内核容器，还是 microVM / 用户态内核一类更强边界。
- 出网默认拒绝了吗？白名单是否按主机和方法收紧。
- OTel trace 跨 Agent 打通了吗？Agent 能不能改自己的或同伴的 trace。
- kill switch 能不能同时停系统并切断凭证？开关是否在被杀对象之外。
- 执着与恶意的判别规则写清楚了没有？重试上限、允许域、人工升级路径有没有落库。
十项里你卡在哪一项，那一项就是你接下来最该学的工程课。
模型不会替你交这份作业。
原文：Katelyn Lesse / The new set of problems for engineers to solve
相关沙箱文：Secure agents: architecture and sandboxing