前几天转了一个贴图，引起了好多朋友的共鸣：
技术人员很伤心
然后看到 Katelyn Lesse 的这篇长文，谈了工程师接下来要解决的难题，以下是全文翻译，你是否认同？
很多软件工程师正在经历一场身份危机，恐怕没有比这更贴切的说法了。这份工作已经变了很多。有人很沮丧，有人却觉得从没这么开心过。我看到了一件很具体的事，让我对未来一两年的工程工作格外兴奋：AI 有能力创造惊人的成果，但如果软件工程师不把一些问题解决掉，这些成果就无法实现。这可是关乎存亡的大事，说实话，也很有意思。所以，现在是一个当软件工程师的绝佳时机。
多 Agent 系统正在带来这些问题
最初，Agent 只是一些需要人参与其中的简单聊天系统。后来，模型越来越擅长在更难的问题上持续工作，Agent 系统也开始迁移到云端。与此同时，模型的协作能力也在提升，人们搭起了初步的多 Agent 系统。比如，由一个编排器为某项任务启动几个子 Agent；或者让 Agent 承担执行之外的工作，像评分、提建议，甚至“做梦”，以此改善结果。
现在，已经有人在构建真正了不起的多 Agent 系统，去解决世界上最难、最重要的问题，比如严肃的科学研究、探索发现和硬件设计。想象一下，成千上万个 Agent 为了这些目标持续工作。这也带来了一批新的软件工程问题，而我们已经看到它们开始出现。
基础设施需要演进，以应对突发性更强的负载。我们需要完善的身份认证和授权机制，识别 Agent，让它们协作，允许它们做该做的事，阻止它们做不该做的事。面对不可信的代码和内容，安全与恰当的隔离至关重要。我们还需要监控，以及在系统开始偏离方向时让它立即停下来的能力。
模型会继续变强，这类多 Agent 系统也会变得非常强大。但软件工程师必须解决这些问题，我们才能真正释放这种力量，让人们敢于信任它，用它治愈疾病、创造好的结果，而不是造成坏的结果。
要解决哪些问题
基础设施需要演进
软件行业一直在 Kubernetes 之上构建系统，而 Kubernetes 是为无状态的多副本应用，或由编号稳定的有状态 Pod 组成的集合设计的。Agent 完全不同。本质上，它们是彼此隔离、有状态的单实例负载。两次工作之间，它们可能闲置任意长的时间，也会花大量时间等待工具、模型推理、其他 Agent，或人的输入。有些负载需要快速启动，有些需要避免浪费算力，还有些需要极大的规模。一批出色的工程师正在全力解决这些问题：例如，AI 基础设施公司在开发新的文件系统和沙箱服务，Google 团队则在打造名为 Agent Substrate 的新运行时。还有太多事情需要摸索。
身份与访问
Agent 的身份认证还有问题要解决：怎样识别究竟是哪个 Agent 执行了一项操作？好在这个领域可以借助微服务世界已经构建、并经过长期打磨的基础组件，比如用短期证书而不是静态密钥来确认工作负载身份。人们正开始把这些思路用到 Agent 上。
Agent 的授权则还有更多悬而未决的问题：你究竟允许一个 Agent 做什么？许多 Agent 代表某个人工作，使用这个人的身份和凭据访问各类系统、执行操作。这里已经有一个问题：怎样识别出执行操作的是 Agent，而不是本人？但这种“代表用户执行”的模式，也就是 on-behalf-of（OBO），还存在更深层的问题，例如用户同意。如果一个多 Agent 系统要连续工作几周，用户该怎样对自己的 Agent 能做什么给出真正有效的批准？Agent 平台提供的工具调用自动批准等功能有所帮助，但要在大规模场景下把这件事做好，还需要更深入的权限机制。还有一类 Agent 使用自己的身份工作，这方面的问题解决得更少。把它放进 Agent 协作的场景里，又会产生新的疑问：一个 Agent 该如何信任另一个向它提出请求的 Agent？
安全与隔离
过去几个月，尤其是最近几周，漏洞暴露的速度已经超过了行业修补的速度，其中很多出现在大量系统依赖的关键基础软件中。再想想，成千上万个持续运行的 Agent 正在这些基础软件之上编写不可信的代码、读取不可信的内容。在这样的环境里，尚未修补的漏洞会危险得多。软件工程师最重要的工作之一，就是发挥创造力，想办法加固这些软件，包括内核、浏览器、运行时和常用库。
多 Agent 系统又让问题复杂了一层。一个被攻破的 Agent，可能把注入的指令传给与它协作的其他 Agent；这些指令还可能进入记忆，让未来的 Agent 无意中信任它们。影响范围不再是抽象问题：第一个 Agent 被攻破时，整个多 Agent 系统中究竟有多少部分会面临风险？这时，隔离就变得很重要。Agent 应该在具有强隔离能力的沙箱执行环境中采取行动。我在另一篇文章里谈过这个问题，链接见文末。
监控与停止
最后，我们需要工具来确保这些多 Agent 系统朝着有益的方向工作；一旦不是，就能发现并叫停它们。我们需要跨 Agent 的 OTel 链路追踪，还要确保任何 Agent 都无法修改自己或其他 Agent 的追踪记录。我们需要能由监控触发的紧急停止开关，真正一次性停掉整个系统，并撤销它的凭据。真正困难的其实是：怎样知道系统正在朝错误的方向发展？出于善意、坚持解决问题的行为，可能与恶意行为非常相似。比如，反复尝试访问一个不在允许名单中的域名。
软件工程师应该感到兴奋
这段话写给那些因为觉得自己的知识和技能将不再重要，而陷入身份危机的工程师：这些问题能否得到解决，多 Agent 系统能否解决世界上最难的问题，你和你的技能可能就是关键。你完全可以，也应该深入这些领域，学习新东西，形成自己的看法。这个领域还有大量问题，正等着新的解决方案。这是一个令人无比兴奋的时刻，正适合把你的本事用起来。
参考链接
-
原文：https://x.com/katelyn_lesse/status/2114542280535318557 -
Katelyn Lesse 关于安全 Agent 架构与沙箱的文章：https://www.katelynlesse.com/blog/secure-agents-architecture-and-sandboxing