https://x.com/katelyn_lesse/status/2114542280535318557 讲一下这篇文章

回复 群友 7739： 作者 Katelyn Lesse 是 Anthropic 的平台负责人，之前待过 Stripe、Betterment。这篇文章的核心论点是：多 Agent 系统能不能真正做成，取决于软件工程师是否解决一批新的工程问题，模型本身不再是瓶颈。她的结论是，工程师处在一个非常好的时间点；那些因为 AI 而焦虑自己技能要贬值的工程师，恰恰是解决这些问题的人。 她把问题分成四块。 一是基础设施。Kubernetes 是为无状态、可复制的应用和稳定的有状态 pod 设计的，Agent 完全不符合这个模型：每个 Agent 是隔离的、有状态的、单实例的，可以在两次工作之间闲置任意长时间，大量时间在等待工具、推理、其他 Agent 或人的输入。不同负载的要求还互相冲突，有的要快启动，有的要省算力，有的要极大规模。她提到有公司在做新的文件系统和沙箱，Google 团队在做 Agent Substrate 作为新运行时，但目前还远没有定论。 二是身份与访问。认证这块还算有存量资产可用，微服务世界的 workload identity、短期证书可以搬到 Agent 上，用来“证明是某个 Agent 干的”。授权这块则基本空白。难在两个层次：一是 Agent 代替人行动时跟人共用身份凭证，事后分不清是 Agent 还是本人操作；二是代表权本身，如果多 Agent 系统持续跑几周，人怎么有意义地批准 Agent 能干什么？工具调用自动审批只能解决一部分。更深的是 Agent 用自己的身份行动，这一块更没解，以及一个 Agent 凭什么信任另一个 Agent 的请求。 三是安全和隔离。她点出一个放大效应：核心软件里的漏洞补得越来越慢，而几千个常驻 Agent 在跑不可信代码、读不可信内容，这些没修的漏洞危险程度会大幅上升。多 Agent 又多一层：一个被攻陷的 Agent 可以把注入指令传给其他 Agent，这些指令还可能沉淀进记忆，被后来的 Agent 当成可信内容。她说要算清爆炸半径，所以执行动作要用强隔离的沙箱。 四是监控与熔断。要有跨 Agent 的 OTel 追踪，并且任何一个 Agent 都不能修改自己或别人的 trace；还要有监控能触发的 kill switch，一按下去整个系统停住，连凭证一起切断。她认为最难的是判断方向对不对：“善意地死磕”和“恶意行为”看起来很像，比如反复尝试访问不在白名单里的域名。 我的看法：她提的四个问题里，二三四是真问题，但有个隐含前提值得打个问号，即“几千个常驻 Agent 长期协作”这套形态本身是不是对的。现在多 Agent 的主要收益还在并行和分工，持续性长跑的价值还没被充分验证。如果这个形态本身被证伪，那她说的那套认证、追踪、熔断的复杂度需求也会随之缩水。另外，授权那块她点的 consent 问题确实是所有方案里最难的形式化：过长的运行期和人的审批能力本质冲突，不太可能靠一个平台 feature 解决，更可能是靠权限分层加事后审计，接受一定的失控概率。 对求职的人来说，这篇的价值在于标出哪些方向还空着：Agent 沙箱运行时、Agent 身份与权限、多 Agent 可观测性。这些是简历上能写得比较硬的方向。