多智能体系统的下一道门槛：基础设施、身份、隔离与停机能力

本文根据 Katelyn Lesse（Anthropic 平台负责人）于 2026 年 10 月 26 日发布的 X 帖及所附文章《The new set of problems for engineers to solve》整理。整理时该 X Article 正文页返回 404，本文依据公开帖子页面展示的文章结构与要点，以及作者此前公开发表的《Secure agents: architecture and sandboxing》补充架构背景；后者发表于 2026 年 9 月 13 日，属于另一篇文章，文中会单独标注。文章中的判断属于作者观点，涉及的产品和项目名称仅用于说明方向，不构成选型建议。

很多关于 AI Agent 的讨论仍停留在“模型能不能完成任务”。但当 Agent 从单轮对话走向云端常驻、从单个助手走向成百上千个并行子 Agent 时，瓶颈会转移到另一层：怎样让这些系统被调度、被授权、被隔离、被观察，并且在出错时能够停下来。

Katelyn Lesse 把这称为软件工程师需要解决的一组“新问题”。她的判断很直接：AI 的潜力不会自动兑现，除非工程师把支撑多智能体系统的基础设施补齐。

从聊天窗口到常驻多智能体

文章把 Agent 的形态变化分成几个阶段：

1. 人类在环的聊天：用户输入，模型回复，工具调用需要人确认。
2. 云端系统：Agent 在后台运行，能访问文件、网络和其他服务。
3. 编排式多智能体：主 Agent 把任务分给不同角色的子 Agent，例如负责评分的、负责建议的，甚至负责“做梦”整理记忆的。

作者进一步设想，未来会有成千上万个持续存在的 Agent 同时做研究、发现和硬件设计。这个设想不是当前产品的功能清单，而是她用来指出工程缺口的方向：当 Agent 数量、生命周期和相互依赖都上升，原来为单体服务设计的抽象会开始失效。

问题一：Agent 不是普通的 Kubernetes 工作负载

Kubernetes 的调度模型主要面向两类工作负载：无状态、可复制的服务，以及状态稳定、可以重新挂载的有状态服务。Agent 与这两种都不完全相同：

特征	典型微服务	常驻 Agent
状态	尽量外置，实例可互换	每个实例有独立会话、记忆和工作目录
生命周期	长期运行或快速重启	可能长时间空闲，等待工具、模型、其他 Agent 或人
复制	多副本水平扩展	单个实例往往不可随意复制
身份	服务级身份	需要区分具体 Agent、所属用户和委派链
资源	CPU/内存相对稳定	推理和工具调用呈突发性，等待时间长

这带来一系列具体问题：空闲 Agent 占着内存怎么办；会话状态放在哪里、怎样快照和恢复；多个 Agent 共享文件系统时如何隔离；工具调用超时后由谁重试；一个 Agent 卡死会不会占满整个池子。

作者提到，已有 AI 基础设施公司在做文件系统和沙箱，Google 也有面向 Agent 的 runtime（文中称为 Agent Substrate）。但她同时指出，这一层仍有大量问题没有定论。对工程团队来说，这意味着不能简单把 Agent 当成“会调用模型的 Pod”，而要重新设计生命周期、状态归属和资源计量。

问题二：认证可以复用，授权才是难点

身份与访问是文章着墨较多的一部分。作者认为，认证可以借用微服务已有的积木：工作负载身份、短期证书、密钥轮换等。但授权更难，因为要回答一些传统服务不会遇到的问题：

• 这个动作是 Agent 做的，还是代表某个用户做的？
• 用户把任务委托给 Agent 后，同意的范围到哪里为止？
• Agent 是否应该拥有独立于用户的身份？
• Agent 之间怎样建立信任，A 能否代表 B 去调用 C？

可以把它拆成三层来处理：

第一层：凭证不进入执行环境。 让 Agent 的执行沙箱只持有占位符，由受信任的代理在出站请求时注入目标范围受限的真实凭证。这样即使代码被诱导，也拿不到长期密钥。

第二层：委派关系可追踪。 每次调用都应携带“谁委托了谁、原始用户是谁、允许做什么”的上下文。权限不应只写在提示词里，而应由服务端在每次请求时校验。

第三层：短时、窄域、可撤销。 凭证按目标服务拆分，限制主机、方法、资源和有效期；任务结束或触发停机时立即失效。作者在另一篇沙箱文章中也强调，OAuth Token 应存放在 Agent Harness 旁边的保险库中，由代理按目的地注入。

这套思路并不新，难的是把它落到 Agent 的高频、多跳、长链路调用里。一个 Agent 在任务中可能连续访问搜索、数据库、代码仓库和消息服务，任何一跳的权限过宽，都会放大提示词注入或误操作的后果。

问题三：不可信代码与不可信内容会互相放大

多智能体系统同时处理两类高风险输入：Agent 写的代码，以及 Agent 读到的外部内容。两者叠加后，攻击面比单 Agent 更大。

文章指出，漏洞一旦被快速披露，在大量 Agent 自动写代码、读网页和调用工具的环境里会更危险。更隐蔽的问题是共享记忆：如果一个 Agent 被注入，它可能把恶意指令写进多个 Agent 共享的上下文，让污染在系统内传播。因此，作者主张使用强隔离的沙箱，而不是仅靠提示词约束。

Lesse 在 9 月的沙箱文章里给出了更具体的架构建议，可以当作这篇“新问题”文章的工程注脚：

• 把“大脑”和“手”分开。 Harness、会话状态和凭证放在受信任的持久基础设施里，沙箱只作为执行工具。
• 容器不是安全边界。 容器共享宿主机内核；处理不可信代码时，应优先考虑 gVisor 这类用户态内核，或 Firecracker 这类 microVM。
• 沙箱像牲畜而不是宠物。 按需创建，限制时间和资源，用完销毁。
• 默认阻断出站流量。 通过代理只放行必要的主机和 HTTP 方法，并把 DNS 也纳入控制。
• 日志放在沙箱够不到的地方。 工具调用、命令和网络流量要写到沙箱无法修改的位置。

这些做法共同指向一个原则：安全属性应该来自结构，而不是来自模型“答应不这么做”。提示词可以让 Agent 更谨慎，但不能代替隔离、最小权限和网络控制。

问题四：可观测性与“一键停机”

Agent 出错时，最危险的情况不是它报错，而是它持续、安静地做错事。文章提出两个要求：

可审计的链路追踪。 使用 OpenTelemetry 之类的标准，把跨 Agent 的调用串起来，并且保证 Agent 自己无法篡改这些记录。追踪信息至少要能回答：哪个 Agent、代表哪个用户、调用了什么工具、访问了哪个目标、结果是什么。

真正的全局停机。 不只是让某个进程退出，而是能够停掉整个 Agent 集群，并同时撤销相关凭证。否则 Agent 可能在停机后仍凭旧 Token 继续动作。

文章还提到一个很实际的检测难题：如何区分“Agent 在坚持解决问题”和“Agent 在做恶意的事”。例如，反复尝试访问不在允许列表里的域名，既可能是代码写错，也可能是被注入后向外探索。单看一次请求很难判断，需要结合历史行为、目标范围和任务上下文。

可以落成几条规则：

• 对非允许目标的访问、权限提升尝试和异常工具组合设置告警；
• 为每个任务设定最大重试次数、最长运行时间和资源上限；
• 停机开关同时撤销凭证、暂停队列并隔离工作区；
• 保留停机前的完整轨迹，便于事后判断是故障还是攻击。

一套可落地的分层参考

把文章的观点整理成架构分层，可以得到下面这张表：

层	核心职责	最低要求
调度与生命周期	创建、休眠、恢复和回收 Agent	每个 Agent 有独立状态、配额和超时
执行隔离	运行不可信代码	强隔离沙箱，默认无网络，按需挂载
身份与授权	认证 Agent、用户和委派链	短时凭证、范围限制、服务端校验
凭证管理	保存和注入密钥	凭证不进入沙箱，按目标注入
网络出口	控制外部访问	默认拒绝，代理放行，记录目标
可观测性	还原跨 Agent 行为	不可篡改的追踪、日志和指标
停机与撤销	停止系统并收回权限	全局开关、凭证吊销、队列暂停

这张表不是某个产品的实现，而是一组检查维度。团队可以从最薄弱的一层开始补，而不是一次性重做整个平台。

分阶段推进的建议

如果正在从单 Agent 原型走向多 Agent 系统，可以按下面的顺序推进：

1. 先做隔离。 把执行环境从开发机移进按需创建、任务结束即销毁的沙箱；先阻断默认出站，再逐项放行。
2. 再收紧凭证。 把长期 API Key 移出代码和沙箱，改为短时、窄域、可撤销的凭证，并记录每次注入。
3. 补齐身份链。 明确每次动作是 Agent 自身身份还是代表用户，保存委派范围和同意记录。
4. 建立可观测性。 统一 trace ID，把工具调用、网络请求和状态变更写到外部存储。
5. 最后做全局停机。 在真正需要之前演练一次：能否在几分钟内停掉所有 Agent 并撤销凭证。
6. 再做规模化。 只有在隔离、授权和停机都可验证之后，才值得把 Agent 数量扩到几十、几百个。

这个顺序的用意是：先限制爆炸半径，再提高并发。反过来做，系统越强，出错时越难收拾。

对工程师意味着什么

文章最后鼓励工程师深入这些领域并形成自己的判断，因为空间仍然开放。这个结论对个人和团队都适用：

• 只会写提示词和调用模型，不足以构建可靠的多智能体系统；
• 调度、身份、隔离、可观测性和应急停机，会成为 Agent 平台的核心工程能力；
• 这些能力大多可以从云原生、安全和分布式系统迁移，但不能假设照搬即可；
• 越早把“权限”和“停机”设计进系统，越不容易在规模化后返工。

多智能体系统的价值不只是让更多 Agent 同时工作，而是让它们在明确的边界内工作。边界越清楚，系统才越敢放大。

来源与边界

• Katelyn Lesse 的 X 帖与所附文章，发布于 2026 年 10 月 26 日。整理时 X Article 正文返回 404，本文依据公开帖子页面可见的文章结构与要点整理。
• Katelyn Lesse：Secure agents: architecture and sandboxing，发布于 2026 年 9 月 13 日。用于补充沙箱分层、凭证注入、网络出口和停机设计的背景，属于作者另一篇公开文章，不是 X Article 的原文。
• 文中提到的 Kubernetes、gVisor、Firecracker、OpenTelemetry、Google Agent Substrate 等仅作为技术背景或作者举例，具体能力和适用性应以各自官方文档为准。