开场与议程：从理论到实战的完整路径

本次研讨会由Anthropic技术团队成员Priyanka和Gabe Semach主持，旨在帮助开发者构建并部署首个Claude Managed Agent。Priyanka拥有两年多的Anthropic工作经验，过去12个月专注于构建Agentic基础设施。会议议程分为两个主要部分：首先是回顾Managed Agent的演进故事，分享在扩展过程中遇到的陷阱与经验教训；其次是Hands-on实战环节。在第一阶段，参与者将使用Cloud平台控制台构建一个简单的Agent，全程无需编写代码，仅通过提示词（Prompt）即可测试首个Agent。随后Gabe将演示如何使用Claude Code或首选的代码智能体编写代码，构建更复杂的金融Agent。整个两小时的环节强调互动性，鼓励观众在实战部分举手提问。

Agent的核心定义与Harness的关键作用

Priyanka首先阐述了Agent的基本工作原理，指出Agent本质上是一个在循环中调用工具的模型。在这个闭环中，模型负责决策并执行下一步动作，持续调用工具直到任务完成。为了支撑这一循环，需要构建一个名为Harness（测试框架/包裹层）的组件。Harnes通常是一层围绕模型的封装，它帮助模型在循环中进行工具调用以获取任务结果。Harnes的关键作用在于填补模型的局限性假设。例如，Priyanka指出Sonnet 45模型存在所谓的“上下文焦虑”（context anxiety），当接近上下文窗口限制时，它会急于快速结束任务。因此，针对Sonnet 45构建Harnes时需要加入上下文重置（context reset）机制来克服这一缺陷。然而，在Opus 45模型中并未出现此限制，因此无需该机制。构建良好的Harnes至关重要，因为它需要封装针对不同模型的特定假设，并随着新模型发布而持续更新。

沙箱环境与“宠物vs牲畜”的基础设施隐喻

除了Harnes，Agent还需要访问沙箱（Sandbox）或计算机环境来执行其编写的代码。以Claude Code为例，它在本地运行并访问文件，但在生产环境中部署Agent时，必须确保其编写的代码在容器内隔离执行。由于Agent生成的代码可能包含错误或不安全内容，沙箱必须具有有限的爆炸半径（blast radius）。最佳实践是将每个任务执行在独立的容器中，以防止不同任务的代码相互干扰或扩大安全风险。

Priyanka接着介绍了Anthropic在去年12月推出的首个Managed Agent架构，该架构将所有组件——包括会话日志、Harnes以及沙箱执行环境——全部封装在单个容器内。这种设计的优势在于没有服务边界，所有操作均为本地调用，文件编辑类似于简单的系统调用（syscalls），易于调试和修改。然而，这种架构导致了严重的运维问题：团队将其视为“宠物”（Pet）而非“牲畜”（Cattle）。在基础设施术语中，“宠物”指代那些被命名、精心照料且一旦生病就必须手动修复的实体，因为失去它代价高昂；而“牲畜”则是可互换、可丢弃的资源。Priyanka解释道，如果单个数据库分片宕机导致产品不可用，那是“宠物”模式；而拥有主从复制集时，主机宕机可立即切换副本，则是“牲畜”模式。初始架构将所有状态绑定在单一容器中，使其成为难以替换的“宠物”，一旦容器故障或需要更新，整个服务即告中断。这种架构在早期获取用户反馈后被发现存在扩展性瓶颈，促使团队进行了重大的架构转型。

早期架构痛点与解耦核心思想

在早期的托管代理（Managed Agents）开发中，调试和调查面临巨大挑战。由于所有进程都在容器内运行且客户数据驻留其中，开发者难以排查问题；例如丢包或容器死亡的表现相似，必须通过 WebSocket 流式连接进入容器才能调试。此外，若需连接客户 VPC 中的 MCP（Model Context Protocol），往往需要网络对等互联或让客户运行特定的测试工具，这种架构存在诸多无法克服的难题。为了解决这些问题，Anthropic 决定将代理的核心逻辑与环境执行解耦大脑与双手。这一设计将系统划分为三个独立接口：左侧是记录所有会话历史的追加式事件日志（Session Log）；中间是代理循环与云端控制逻辑的大脑（Harness/Cloud）；右侧则是按需分配、用完即弃的沙箱及工具调用的双手（Hands/Sandboxes）。这种设计使得每个组件都成为可互换的“牲畜”，当沙箱崩溃时，云端可以像调用普通工具失败一样处理错误并重新生成实例。

安全性增强与上下文策略灵活性

新的架构在安全性和资源管理上带来了显著改进。首先，凭证不再进入沙箱环境。在旧架构中，凭证实体存在于沙箱内容易受到提示注入攻击；新方案通过代理路由外部请求，在调用外部端点前由云端注入令牌。这意味着模型永远无法看到用户的凭证或令牌，从而彻底杜绝了通过提示注入诱导模型泄露、打印或写入凭据的风险。其次，由于会话日志是追加式的且永不丢弃，上下文压缩策略变得极其灵活。系统不再强制改变事件流，而是由压缩策略决定是将整个日志摘要放入上下文，还是仅保留最近 N 个事件。这种接口设计使得系统能够动态调整上下文策略，而无需担心数据丢失或结构僵化。

性能优化与可扩展性收益

架构解耦还带来了显著的性能提升和扩展优势。由于云端无需等待沙箱启动即可发起推理调用，首字延迟（Time to First Token, TTFT）降低了约 90%。云端仅在需要时生成沙箱，实现了更快速、响应更灵敏的用户体验。此外，“一个大脑连接多个双手”的设计极大地增强了灵活性。代理循环可以调用沙箱容器、客户 VPC 或 MCP 服务器，这些“双手”组件可以随意插拔和替换。正如演讲者所总结的：“Harnesses encode assumptions and assumptions can go stale”（代理封装了假设，而假设会过时）。通过设计能够超越这些假设的接口，Anthropic 确保了架构在更换压缩策略或完全替换代理逻辑时仍能保持稳定和可扩展性，为后续的开发和应用奠定了坚实基础。

构建环境基础与 Agent 初始化

搭建 Claude Managed Agents 的第一步是确保运行环境中已安装必要的依赖项，这通常涉及在容器或沙箱中完成基础配置。随后进入核心环节：创建 Agent 实例，开发者需要为智能体赋予一个特定的名称（例如示例中的 "joke teller"），并选择底层支撑的大语言模型。Anthropic 提供了多种模型选项供用户根据需求挑选，包括 Opus、Sonnet 或 Haiku。在确定模型后，必须为 Agent 编写系统提示词（System Prompt）以定义其行为模式。在演示案例中，设定该 Agent 扮演喜剧演员角色，指令要求它 "Find a fresh joke on the topic. Deliver it well."（寻找关于该主题的新鲜笑话并精彩演绎）。此外，工具集的配置至关重要。开发者需为 Agent 提供一套基础的工具包（Agent Tool Set），涵盖 Bash、Read/Write、Grep 等常用功能，这是绝大多数 Agent 执行任务所必需的底层能力支持。

会话生命周期与事件流机制

完成 Agent 定义后，下一步是创建 Session（会话）。Session 通过绑定特定的 Agent ID 和 Environment ID 来生成，它是执行具体任务的工作单元。当会话被 provisioned（配置就绪）时，其初始状态为 Idle（空闲），此时并未进行任何实际工作。只有当向会话发送事件后，交互才会启动。事件流（Event Stream） 是 Agent 与用户沟通的核心通道。左侧代表用户发送的事件，例如输入 "Tell me a joke about distributed systems"；右侧则是 Agent 返回的响应事件，如生成的笑话内容。这种双向流式传输机制确保了实时交互的可能性。自定义工具（Custom Tool） 是事件流中的一个高级特性，它允许开发者定义特定的处理逻辑。当 Agent 需要调用自定义功能时，会在事件流中推送一个 Custom Tool Use Event，开发者监听该事件并处理后，可通过返回结果来声明工具调用完成。其他关键状态包括 Session Error（会话出错）、Status Idle 以及用于终止任务的 Interrupt 事件。

平台控制台与后续学习资源

在理论讲解结束后，演示者引导观众访问 platform.claude.ai 控制台。用户可以在 "Manage Agent"（管理智能体）部分找到 Quick Start（快速入门）功能，这是一项引导式教程，帮助开发者构建第一个 Agent。演示者提到可以使用 API 额度进行体验，并安排工作人员 Travis 在现场协助解答疑问或处理技术问题。这部分内容标志着基础配置环节的结束，为后续深入探索多智能体协作（Multi-agent）和记忆机制等高级概念奠定了基础。演示者提及团队成员 Gabe 将在后续环节深入讲解这些复杂特性，确保参与者能够全面掌握 Anthropic Agent 生态的完整功能列表。

结论

Anthropic Managed Agents 通过解耦“大脑”（云端控制逻辑）与“双手”（沙箱执行环境），成功解决了早期单体架构在扩展性、安全性及运维效率上的瓶颈。新架构将组件转化为可互换的“牲畜”，实现了凭证隔离以杜绝提示注入风险，并利用追加式事件日志赋予上下文策略灵活性。性能方面，该设计使首字延迟降低约 90%，显著提升了用户响应速度。尽管早期版本存在“宠物式”运维痛点，但当前架构已具备支撑复杂金融 Agent 等场景的基础。然而，其优势高度依赖于精心设计的 Harness 以应对模型局限性（如上下文焦虑），且需持续更新以适应新模型假设，这构成了长期维护的关键挑战。