多智能体系统的下一道门槛：基础设施、身份、隔离与停机能力
本文根据 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 的形态变化分成几个阶段：
- 人类在环的聊天：用户输入，模型回复，工具调用需要人确认。
- 云端系统：Agent 在后台运行，能访问文件、网络和其他服务。
- 编排式多智能体：主 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 系统，可以按下面的顺序推进：
- 先做隔离。 把执行环境从开发机移进按需创建、任务结束即销毁的沙箱；先阻断默认出站，再逐项放行。
- 再收紧凭证。 把长期 API Key 移出代码和沙箱，改为短时、窄域、可撤销的凭证，并记录每次注入。
- 补齐身份链。 明确每次动作是 Agent 自身身份还是代表用户，保存委派范围和同意记录。
- 建立可观测性。 统一 trace ID，把工具调用、网络请求和状态变更写到外部存储。
- 最后做全局停机。 在真正需要之前演练一次：能否在几分钟内停掉所有 Agent 并撤销凭证。
- 再做规模化。 只有在隔离、授权和停机都可验证之后，才值得把 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 等仅作为技术背景或作者举例，具体能力和适用性应以各自官方文档为准。