https://x.com/katelyn_lesse/status/2114542280535318557看看这篇文章

回复 Erfan 我看完了。文章来自 Katelyn Lesse，她是 Anthropic 的，平时讲 Agent 基础设施和沙箱那类话题。她的核心观点是：很多工程师因为觉得技能没用、职位消失而焦虑，但作者认为接下来一两年最要紧的一批工程问题，恰恰只有软件工程师才解得开；AI 想真正创造它号称能做到的成果，前提就是工程师先把底下的问题解决掉。理由是多 agent 系统正在变成现实：成千上万个 agent 持续研究、发现、设计硬件，这带来的全是一堆新工程难题。 她把这堆难题分成四个： 一是基础设施。K8s 当初是为无状态副本、或者固定编号的有状态 pod 设计的，跟 agent 完全不像。agent 本质上是有状态、单实例、隔离的工作负载，还会长时间空闲，主要是在等工具返回、等模型推理、等别的 agent、等人输入。有的场景要秒级冷启动，有的要省算力，有的要极限规模，现在这些都没有标准答案，Google 在做 Agent Substrate 这类新 runtime。 二是身份和权限。认证这块还算有现成基础（短时证书、workload identity 这类微服务世界磨过的东西可以搬）。授权就基本空白了：agent 替人干活、用人的身份去动各种系统，第一层问题是怎么区分“这是 agent 干的，不是本人干的”；第二层更深，是多 agent 系统跑上几周，人怎么有意义地批准它能做什么，光有“工具调用自动通过”这种开关撑不住；再往上是 agent 用自己身份干活，以及 agent 之间怎么互相信任——“你凭什么信任另一个 agent 交给你的活儿”。 三是安全和隔离。她提到近几周漏洞出现的速度超过行业修补速度，很多还在核心软件里。想象一下成千上万持久 agent 跑在这层核心上、写不可信代码、读不可信内容，那些没打的补丁危害会被放大好几倍，所以内核、浏览器、runtime、常用库的加固是重点。多 agent 还多一层：一个 agent 被污染，它可以把注入的指令传给同伴，这些指令还可能存进 memory 里被后来的 agent 当真，爆炸半径会扩散。 四是监控和急停。要跨 agent 的 OTel tracing，且 agent 不能改自己的或别人的 trace；要有监控能触发的 kill switch，一次性停掉整个系统并吊销凭证。她说最难的不是做开关，是判断“系统走错方向了”这件事本身——善意的执着和恶意行为长得很像，比如反复去试一个不在白名单里的域名。 我自己的看法：这篇文章的重点在“分工”上，即哪些活会变得更有价值，而非又一篇 AI 取代论。她列的四条有个共同点：全都是“信任”的技术化——你信不信这个 agent 代表的是那个人，信不信它没被污染，信不信它没跑偏。这跟模型能力关系不大，模型再强也不会自动长出一套授权模型和爆炸半径控制，这部分只能靠工程补。对做 ca 和 pa 的人来说，这其实是个机会窗口：这些问题的答案现在还没定下来，谁先形成可用的做法，谁就能定下标准。 顺带说一句，她文里“隔离、沙箱执行”那段跟群里的 cu、bu 讨论挺连得上——沙箱不只是防模型乱来，更是防“一个被污染的 agent 顺着协作链条把整个系统带下去”。