https://x.com/i/article/2110998085463945216

【X 长文】用 Claude Managed Agents 和 Vercel 搭高性能 agent / Katelyn Lesse（Anthropic）

Katelyn Lesse 是 Anthropic 的平台工程负责人。她在 Vercel Ship 2026 的分享我觉得内容不错，把现场拍照整理成长文分享给大家。Katelyn 虚构了一家只在美国卖货的电商，11 月初 COO 在 Slack 上给 agent 布置任务，要在三周后的黑五之前进入 24 个新国家。工程只是其中一块，周围还有法务（各国的条款）、财务（定价、税务、汇率）、品牌营销、客服和物流。她用这个任务说明 agent 现在应该能接住什么量级的活，后面讲的架构、多智能体策略和安全，都回到这个例子上。

产品定位

Claude Managed Agents 是 Anthropic 用来构建 agent 的一组 API。Messages API 是无状态的，只负责产出 token。随着模型能跑得更久、接更大的任务，越来越多人把 agent 放到云端长时间运行，Managed Agents 就是为这种用法做的托管层。

架构：从"沙箱里跑 Claude Code"到"脑手分离"

最初的做法很直接：每来一个 API 请求就启动一个沙箱，在里面跑 Claude Code。这样有三个问题。第一是可靠性，沙箱一挂 agent 就跟着挂。第二是延迟，每次都要冷启动沙箱和 Claude Code，等很久才开始出 token。第三也是最重要的安全问题，凭证和 agent 自己选择执行的不可信代码放在同一个沙箱里，agent 可以拿着凭证在互联网上做你不想让它做的事。

所以公开发布前他们重新设计，把 agent 的"大脑"和"手"拆开：harness 跑在持久化服务器上，只在需要执行工作时临时拉起沙箱。三个问题一起解决了。沙箱当"牲口"而不是"宠物"，挂了就挂了，agent 的状态和存储都在服务器上。延迟只比 Messages API 多几毫秒。不可信代码和凭证、模型访问在物理上隔开。

与 Vercel 的三层对接

底层的"手"可以直接用 Vercel Sandbox，它自带的防火墙可以当代理，在请求出站那一刻再注入凭证。中间层的"脑"是 Managed Agents 本身，包括模型、harness 和各组件之间的连接。最上层是"前门"，用 Vercel 的 Chat SDK 做交互界面，也可以用 Next.js 把 agent 嵌进自己的应用。

Katelyn 讲了沙箱调度的一个细节：agent 要干活时先把任务放进队列，Managed Agents 向一个 Vercel Function 发 webhook，这个函数启动沙箱，再回头从队列里取任务。整条链路只有从沙箱到 Managed Agents 的出站 HTTPS，没有入站连接，安全面很干净。

多智能体策略："tokens should have jobs"

她认为架构不是最有意思的部分，怎么把 agent 做强才是。Anthropic 现在最关注的是用多智能体策略榨出模型的最高智能，核心说法是"tokens should have jobs"：同样的预算，与其全部用来不停执行，不如分一部分 token 去做执行之外的事。她举了三种分工。第一种是顾问（advising），小模型负责执行，碰到难题（比如某国的税务）再去问大模型。第二种是评分（grading），开工前先写好评分标准，执行 agent 干活，评分 agent 检查，不达标就让它重做。第三种是做梦（dreaming），单个 agent 平时会自己写记忆，做梦则是回顾全部历史动作，归纳出新的记忆写回去。放到 24 国的例子里，就是先用三分之一的会话做好两三个国家，把经验沉淀成记忆，再去做剩下的国家。

7 月他们用 Claude Opus 4.8 在一批复杂金融任务上做了实验，预算不变，比较各策略拿到满分的运行占比。结论是除了纯执行，其他策略效果都更好，差距还不小：纯执行只有 21% 的运行拿到满分，评分 39%，顾问 44%，做梦 71%。

Dynamic Workflows：让 Claude 自己定策略

开发者一般不会在动手前先想清楚该用哪种多智能体策略，所以干脆交给 Claude 决定。Managed Agents 演讲前一周刚上线了 dynamic workflows：Claude 接到任务后先写一份确定性的计划，再分阶段调度大量 agent 去执行。她特意说明它和 Vercel Workflows 是互补的。Vercel Workflows 在更上一层，用代码把 agent 包起来，让系统更确定。Dynamic workflows 则是在不确定的那部分里，由 agent 自己编排自己的工作。

对"为什么不用一个超长上下文的单 agent"，她给了三个理由。一是"偷懒"：做到第 19 个国家时，即使提示写得再好，agent 也会因为上下文腐烂（context rot）开始不按预期行事。二是缺少客观评判：agent 自己评自己，多半觉得自己做得不错，需要另一个 agent 来打分。三是目标漂移：连续干了好几个小时，agent 会忘了最初要做什么。

她的主打数据来自一个找 bug 的实验：在一个大代码库里注入 70 个 bug。dynamic workflow 跑了三次，每次都找到 66 个；单 agent 跑三次，只找到 14 到 27 个。Claude 在 workflow 里会混用几种模式：扇出再汇总；对抗式验证，比如让第二个法务 agent 专门挑第一个的漏洞；循环直到达标。

回到 24 国的例子，Claude 自己写了一个七阶段计划（规划、研究、起草、审查、修复、出报告等），覆盖七个职能、24 个国家，最终用掉 81% 的会话预算。这种 workflow 单次运行最多可以调度 1000 个 agent，同时在执行的大约 64 个。她反复提醒这很吃 token，要设预算上限，留给最有野心的任务。

Agent 安全的四层

Anthropic 把 agent 安全分成四块。第一是模型对齐，训练 Claude 本身向善。第二是在线防护，token 流经 API 时实时跑分类器；Katelyn 坦白承认这正是做网络安全相关工作时 Claude 有时会误拒的原因，他们还在改进。第三是离线防护，针对最强的那一档模型，跨所有会话做自动审查，补上实时难以发现的问题。第四是 agent 基础设施，她说这是工程问题，责任由 Anthropic、Vercel 和每个构建 agent 的开发者共同承担。

基础设施层她讲得最细。首先还是脑手分离：沙箱这一层（演示图虚线以下）应当默认完全不可信。监控日志不能放在沙箱里，否则 Claude 可以写代码改自己的日志；kill switch 必须远离 agent 能执行代码的地方，免得它"把自己的急停开关关掉"。

其次是凭证永远不进沙箱：Claude 写的代码里只放占位用的假 token，请求经过 Vercel 沙箱防火墙时才换成真凭证，Vercel 称之为 credential brokering，开箱即用。她点明，把整个 agent 塞进沙箱的做法天然违反这些原则。

第三是沙箱隔离级别：从容器到独占主机，差别在隔离强度。他们推荐 Firecracker microVM，认为它在硬件级隔离和快速启动之间取得了最好的平衡；Vercel Sandbox 和 Anthropic 自己的沙箱都跑在 Firecracker 上。

第四是出站管控，默认拒绝：不需要上网就彻底锁死，需要的话只开白名单主机。

最后是监控和 kill switch，两家平台都内置，要真正用起来。

收尾

回到开头，24 国乘 7 个职能的方案做完了，等待审阅，COO 按一个按钮就能上线。

我的看法

这场分享的信息量比标题大。最值得记住的不是 66 对 14–27 这组数字（自家设计的实验，又没有公布总 token 成本，参考价值有限），而是两个结构性信号。一是 Anthropic 正从"卖 token"往"卖运行时"走：harness、记忆、多 agent 编排、预算控制都收进托管层，开发者自己写编排逻辑的空间在被平台吸收。这和"架构比模型重要"是同一个判断，只是这次由模型厂商自己来做这层架构。二是"脑手分离 + 凭证代理"很可能成为 agent 基础设施的事实标准，沙箱、出站代理和凭证托管这一层会冒出独立的投资机会。和同场 Rauch 的主题演讲对照着看，Vercel 想占的正是"手"和"前门"这两段。

配图 8 还透露了一点：做梦（71%）比顾问（44%）和评分（39%）领先一大截。比起实时多叫几个 agent，把过去会话的经验沉淀下来、让后面的工作做得更好，收益更大。所以 Anthropic 押注的持续学习，目前是靠离线整理记忆来实现的。