《Claude 托管代理把智能体基础设施拆成可组合服务》

导语

这篇 Claude Blog 不是在介绍一个单点 API，而是在解释 agentic application 从“模型会回答”走向“系统能长期执行任务”时，基础设施为什么会变成决定性瓶颈。作者的主线是：代理真正进入生产，需要运行环境、凭证、安全边界、会话记录、可观测性和可扩展架构，而 Claude Managed Agents 试图把这些非差异化但高风险的部分托管起来。

1. 智能体架构的演进：从单轮 API 到可执行任务的 harness

1.1 早期 API 的边界

• 2023 年 Claude 面向开发者开放时，接口契约很简单：输入 token，输出 completion，应用自己决定下一步。这适合总结文档、分类工单、改写文本这类单轮任务。
• 当用户希望 Claude 能查资料、采取行动、观察结果再决定下一步时，单轮模式就不够了。把模型变成 agent，意味着团队必须自己搭建循环：问模型、运行工具、回填结果、再重复。

1.2 Claude Code 和 Agent SDK 让 harness 产品化

• Claude Code 在 2025 年推出后，内部已经包含一套成熟 harness：工具执行、子代理、上下文管理、代码库交互和运行循环。开发者自然希望把这套能力迁移到自己的领域代理里。
• Claude Agent SDK 的意义在于，团队可以基于 Claude Code 同一套 machinery 构建代理，而不是维护自制 loop。作者强调，对很多团队来说，代理从这里开始变得实际可用。
• 这一节的骨架不是“又发布了一个 SDK”，而是 agentic surfaces 的演进：API 只提供模型能力，Claude Code 把工具循环产品化，Agent SDK 再把这套循环抽出来给应用开发者复用。

2. 生产环境真正难的是基础设施，而不只是提示词

2.1 六类生产问题会反复拖慢团队

• 作者列出的障碍包括：hosting and scaling、session management、filesystem management、execution isolation、credentials 和 observability。它们分别对应“代理在哪里跑”“长任务如何续跑”“产物写在哪里”“错误代码的爆炸半径多大”“凭证如何不泄漏”“出事后能否复盘每一步”。
• 这些问题并不直接构成产品差异化，却决定代理能不能被信任地放进生产。团队常常把大量周期烧在安全、状态、权限和 harness 调优上。

2.2 同容器架构把脑和手绑在一起

• 很多 agent harness 会和文件系统、执行环境放在同一个容器里。这样会带来启动延迟，也会让代理生成的代码离凭证太近。
• 容器死亡时，运行也会随之死亡；如果一个代理跑了很久，团队还需要额外机制来重建上下文和执行轨迹。

3. Managed Agents 的核心设计：把 brain 和 hands 解耦

3.1 会话日志连接推理与执行

• Managed Agents 让调用 Claude 的 harness 与执行代码的 sandbox 分离，中间由 session 连接。session 是 append-only log，记录每次模型调用、工具调用和结果。
• 这种架构让 Claude 可以在容器启动前先开始推理，让 sandbox 远离凭证，也让整次运行可以从事件日志中重建。作者把这称为 decoupling the brain from the hands：脑负责推理，手在隔离环境中执行。

3.2 三个核心资源：agents、environments、sessions

• agent 是配置：模型、prompt、工具和 guardrails。environment 是执行环境：sandbox container、网络规则和预装包，可以由 Anthropic 托管，也可以在用户控制的基础设施中运行。
• session 是一次运行：把一个 agent 和一个 environment 配对，拥有独立 sandbox，并在服务端保留事件历史、sandbox 状态和输出。这样长任务可以暂停、恢复，也可以事后逐步追踪。

4. 为什么使用托管服务：安全、低延迟、持久会话和边界控制

4.1 凭证不进入 sandbox

• 如果所有东西都在一个容器里，prompt injection 可能诱导模型读取自己的环境变量并泄漏 token。Managed Agents 使用 Vaults，把 MCP、CLI、GitHub 等凭证放在独立 vault，通过代理按需取用和解密。
• 文章特别强调 envelope encryption 和 signed request token，这说明安全设计不是“相信模型不乱做”，而是把秘密从执行环境中物理拆出去。

4.2 延迟和会话可靠性来自同一套事件架构

• 因为 Claude 可以在环境并行启动时先输出，所以无需等待容器完全启动。文章给出测试数字：time-to-first-token 中位数约降低 60%，最慢场景 p95 降低超过 90%。
• session 不是一次 request/response，而是持续事件流。它带来实时更新、恢复运行、历史保留、checkpoint、timeline 调试、Memory 和 Dreaming。Dreaming 会定期读 session 和 memory store，提炼模式与用户偏好，让代理从重复错误中学习。

4.3 Anthropic 托管与自托管 sandbox 可以共存

• 默认模式下，编排和工具执行都可以放在 Anthropic-managed cloud containers，换来更快上线和弹性扩展。
• 对边界要求更高的团队可以使用 self-hosted sandboxes，让代码、文件系统和网络出口留在自己的 VPC；MCP tunnels 则允许 Claude 连接用户私有网络中的 MCP servers。

5. 真实采用场景：托管基础设施把团队带回领域差异化

5.1 生产案例说明托管代理已进入真实工作流

• Notion 用 Managed Agents 支撑 Custom Agents，让团队从任务板分配工作给 Claude，由它读取文档、会议记录和连接数据，再把代码、deck、site 返回 workspace。文章提到早期 prototype 把约 12 小时工作压到 20 分钟。
• Rakuten 在产品、销售、营销、财务中上线 specialist agents；Sentry 把 Seer debugging agent 和会写 patch、开 PR 的 Claude agent 配对；Asana 和 Atlassian 也把代理放进项目和 Jira 流程。

5.2 新模型到来时，不应重写底层架构

• 作者用 context anxiety 举例：Claude Sonnet 4.5 接近上下文上限时会急着收尾，团队为此加入 context resets；到 Claude Opus 4.5 时这个行为消失，旧修复反而成了开销。
• 作者最终的判断是：harness 必须随模型一起演进，而多数组织不应把资源耗在维护这层基础设施上。团队真正应该投入的是 context management、domain expertise 和面向用户的体验。

思想框架

文章先从“好提示词不够”切入，说明 agent 进入生产时需要运行、凭证、状态、安全和可观测性。随后回顾 Claude API、Claude Code、Agent SDK 的演进，指出 harness 虽然降低了 agent 开发门槛，但部署和扩展仍是难点。接着作者提出 Managed Agents 的核心架构：把推理 harness 与执行 sandbox 解耦，用 session 日志连接二者。后半部分围绕安全、延迟、持久会话、自托管边界和真实客户案例展开，最终落到一个工程判断：生产级 agent 的基础设施应被托管和持续调优，团队差异化能力应回到上下文、领域知识和产品体验。