多会话编排与自动化调度机制
在演示的开场部分，演讲者展示了如何通过主代理（Main Agent）进行复杂的任务拆解与多会话编排。以分析Google和Microsoft为例，主代理首先评估自身信息储备，随后生成定制化工具并启动独立的分析会话。这种架构允许每个子代理拥有独立的结果定义（outcome definition），从而实现基于记忆存储的相互学习与自我监督。这种多代理协作模式不仅处理单一任务，还能通过编排器（orchestrator）协调多个会话并行工作。
针对重复性工作的需求，Anthropic引入了“部署（Deployments）”概念。这是基于API和SDK构建的核心功能，允许用户将代理定义、运行时间表以及初始消息组合在一起。例如，用户可以设定一个“研究桌每周备忘录”的代理，指定其在每月1号下午1点自动运行。部署功能支持传入记忆存储、GitHub仓库或文件等资源，确保代理在每次运行时都能访问最新的外部知识。虽然目前主要通过控制台触发，但官方鼓励开发者通过API构建自定义UI和工作流。
"Deployments is everything is API based... you can build custom UIs and custom workflows."
“梦境”功能：代理的自我优化与迭代
演示的亮点之一是名为“Dreaming（做梦）”的功能预览，旨在实现代理系统的自我改进与自动化优化。该功能允许用户选择特定的记忆存储、模型以及自定义指令，然后让系统对过去30天的会话记录进行流式分析。在这个过程中，“梦境”代理会启动多个子代理，逐一审查历史会话的转录文本。
其核心逻辑在于评估记忆存储是否编码了所有必要信息，识别导致问题的会话错误，并判断某些问题是否反复出现。基于这些分析，系统能够自动更新记忆存储中的技能定义或代理提示词。在演示案例中，“梦境”功能发现现有技能存在编写漏洞，并自动扩展了相关知识库。这一机制不仅优化记忆存储，未来还将直接改进代理提示词和子代理指令，形成闭环的自我进化系统。
"It found that the skill that we created actually had a few gaps... and it updated the memory store."
可观测性、持久性与长期运行支持
在问答环节，针对代理的可观测性问题，演讲者澄清了Anthropic的默认行为。系统提供全量的事件可观测性（full observability），用户可以在控制台中实时查看所有发生的事件。虽然默认展示的是经过处理的转录视图（transcript view），但通过调试接口，开发者可以获取每个会话中发生的每一个底层事件。这意味着用户可以精确追踪模型调用的开始与结束时间，从而计算延迟指标（latency metrics）。对于希望集成自有监控栈的用户，由于所有交互均基于API，开发者可以轻松地构建连接器以导出至OpenTelemetry（OTEL）等外部系统。
关于代理的长期运行能力，Anthropic确认其后台会自动执行记忆压缩（compaction）操作。目前已有用户在生产环境中运行长达10小时的会话，且系统支持代理在数月甚至更长的时间内持续执行每日任务而不会导致持久化存储无限膨胀。对于需要多代理委托（如Agent A委派给B和C）的场景，目前主要通过API层面的编排实现，而非内置的特定委托功能。
"We are running compaction for you so that you can run these for days. We've seen 10-hour sessions in production..."
拓扑结构与人类控制欲的博弈
在构建子代理（sub-agents）时，Anthropic 发现人类用户倾向于对 Claude 的行为施加约束。然而，随着模型智能的提升，团队正致力于移除这些“护栏”，让 Claude 自主决定最佳执行路径。目前的测试表明，固定使用三个子代理的拓扑结构并非最优解。相反，如果让 Claude 自行决定其内部架构和协作方式，它往往能实现更好的性能表现。尽管目前 UI 尚不支持复杂的基于图的工作流可视化编辑，但未来的方向是减少人工干预。
“随着 Claude 变得更强智，我们会不断移除那些护栏，让它自由发挥（let it cook），去做它认为最好的事情。”
这种设计理念反映了从“强约束”向“高自主性”的转变。虽然当前可能需要人工指定子代理的数量和连接方式，但长期来看，模型自主生成的拓扑结构优于预设的固定模板。这要求开发者在评估 Agent 性能时，不仅要关注结果，还要观察其内部决策过程的合理性。
复杂组织的管理与部署机制
对于管理多个 Agent 的复杂企业环境，Anthropic 目前提供的核心隔离原语是工作区（Workspaces）。用户可以将不同的客户或团队划分到独立的工作区中，从而实现权限隔离和资源分段。工作区内包含一组 Agent，特定用户组只能访问指定工作区内的所有 Agent。尽管目前细粒度的权限控制仍有缺口，但这仍是当前实现多租户隔离的主要手段。
在部署层面，Deployment 并非指代码快照，而是用于调度特定 Agent 会话的机制。例如，可以设置“研究 Desk Agent”每季度自动运行一次 NVIDIA 调研任务。关键在于记忆（Memory）的持久化与挂载。记忆存储是一个独立实体，开发者可以决定将哪个 Memory Store 附加到具体的 Session 上。这种设计使得状态可以在不同会话间共享和延续，确保了 Agent 在长期运行中的上下文一致性。
Harness、Evals 与技能演进的权衡
关于“Harness”的定义，Anthropic 指出业界存在分歧。在 CMA（Claude Managed Agents）语境下，Harness 主要指工具循环执行、上下文管理及会话状态控制。而多数开发者眼中的 Harness，是指协调多个 Agent 和 Session 以完成更大任务的拓扑结构。Anthropic 提供的是单个会话作为基本工作单元（Unit of Work）的抽象，允许开发者在此基础上构建更复杂的编排逻辑。
为了验证 Agent 表现，官方推荐运行Evals（评估）。通过定义精确的结果标准（Rubric）和最大迭代次数，可以引导 Agent 达到预期目标。此外，“Dreaming”功能允许 Agent 回顾过去一段时间（如 30 天）的会话记录，分析任务模式并生成更优化的 Memory Store。这一过程通常结合 Evals 进行自动化筛选，以确定最佳的方向。
“厚技能”与“薄 Harness”的未来趋势
针对开发者在“Skills（技能）”与“Agents（智能体/Harnessing）”之间的选择困惑，Anthropic 提出了“厚技能、薄 Harness”（Thick Skills, Thin Harness）的概念，并指出这一界限正在模糊。随着 Claude 能力的增强，模型对额外指令和复杂编排的依赖逐渐减少。Skills 目前提供了足够的信息让模型完成任务，但未来这种抽象可能会变薄。
“随着 Claude 变得更聪明，我们希望给予它的帮助边界开始融化并消失。你今天需要的东西，明天可能就不再需要了。”
这意味着，多 Agent 协作（Multi-agent）在当前阶段可能比单纯依赖复杂 Skill 更有效，但随着模型进化，简单的 Prompting 加上少量的结构化输入可能就足以应对复杂任务。开发者无需过度担忧工具链的快速迭代，因为核心趋势是模型自主性的提升将降低对复杂外部编排的依赖。建议通过持续的 Evals 来验证不同配置下的实际效果，而非盲目追随架构潮流。
Dreaming 功能评估与实验性质
在讨论 "Dreaming"（梦境）这一新功能时，演讲者强调其核心价值在于通过评估体系来验证是否带来了显著的性能提升。目前已有客户反馈，在运行 Dreaming 并配合新的记忆服务器后，评估指标获得了显著改善。然而，这种提升并非绝对，因为 Dreaming 目前仍处于 Research Preview（研究预览）阶段，本质上是一个大型实验性项目。用户需要建立自己的评估集来确认效果，因为单一会话的结果可能存在偏差：例如九个会话可能显示错误结果，而一个会话显示正确，若仅依赖单一路径可能会错失洞察。
"Make sure that dreaming is providing you with better outcomes and we've seen customers were able to get be get a significant improvement on their evals by running Dreaming and then using the new memory server but again everything kind of ties back to eval."
因此，评估（Eval）是连接 Dreaming 功能与用户信任的关键桥梁。只有通过与特定场景绑定的评估测试，才能确定该功能在特定工作流中是否真正有效。这种基于数据的验证方式有助于用户理解模型在不同路径下的表现，从而决定是否全面采纳该技术。
架构渊源与 Cloud Code 的关系
针对观众关于该功能是否基于 Claude Code 构建的提问，团队澄清了两者之间的关系。虽然 Claude Managed Agents 并非直接基于 Claude Code 构建，但其设计灵感确实来源于 Cloud Code。Cloud Code 作为一个终端工具，在编码任务上表现优异且开箱即用；而 Managed Agents 旨在成为一个 API 产品和基础设施，以支持更广泛的非编码任务和规模化应用。团队指出，Cloud Code 提供了很好的灵活性参考，但 Managed Agents 需要解决更多关于可靠性、可扩展性和上下文管理的挑战。
"We took the cloud code harness as an inspiration. We found that it was very well attuned for coding tasks... So we have slightly different uh you know value uh props um and so it's not just clocked out in a box though ideally it performs as well if not better and all sorts of tasks."
目前，Managed Agents 仅支持 Anthropic 自家的模型，尚未开放对非 Anthropic 模型的兼容。团队表示，虽然目前无法像 Cloud Code 那样灵活切换模型，但未来的 API 设计将允许用户带入自己的上下文、信息和能力。这种差异化定位使得 Managed Agents 更适合需要高度定制和大规模部署的企业级场景，而非简单的终端辅助工具。
多租户架构与 Bedrock 集成策略
在讨论多租户（Multi-tenancy）和权限控制时，团队明确建议不要使用用户自己的 API Key（Bring Your Own Key）。这是因为如果直接使用终端用户的密钥，Anthropic 将失去可观测性（Observability），无法监控代理的运行状态和性能。相反，团队推荐使用 Workspace（工作区）作为多租户的基本单元。用户可以选择将所有客户数据放入单一工作区并在应用层维护映射，或者为每个客户创建独立的工作区。后者虽然隔离性更好，但管理复杂度较高，需要重新配置代理。
"We have seen that the best model for multi-tenency is not bring your own key because you lose observability... So we encourage you to model things with workspaces as a tenency primitive."
关于权限控制，目前 Anthropic 层面尚未提供细粒度的 RBAC（基于角色的访问控制），工作区内所有成员均可访问所有内容。团队承认这是当前的短板，并表示正在改进权限体系以更好地支持为其他客户构建代理的场景。此外，针对 Bedrock 用户，目前该功能不直接通过 Bedrock Console 管理，而是需要通过 AWS Cloud Platform 的控制台进行配置和 API Key 的生成。计费模式基于 Token 使用量，Cloud Console 本身免费。
扩展性与资源管理疑问
最后，针对用户关心的横向扩展（Scaling）问题，团队指出 Managed Agents 是完全托管的服务。与 Kubernetes 中需要手动配置 HPA（水平Pod自动伸缩）或设置超时参数不同，用户无需定义任何底层扩展参数。只要通过 API 调用创建会话即可，系统会自动处理背后的资源分配和速率限制（Rate Limits）。用户不需要担心像 "运行 10,000 个 Pod" 这样的基础设施细节，因为所有的扩展逻辑都由 Anthropic 在后台管理。这种设计旨在降低开发者的运维负担，使其专注于业务逻辑而非基础设施配置。
"You don't need to because we're managing it all for you're just making API calls that's all."
尽管没有显式的扩展参数，但系统仍存在隐性的速率限制。对于大规模应用场景，用户只需确保 API 调用符合规范即可。这种简化的扩展模型使得开发者能够快速构建大规模代理应用，而无需深入理解底层的容器编排或资源调度机制。
生产环境下的规模化部署策略
在讨论如何将内部演示转化为面向客户的产品时，开发者关注点在于如何处理敏感数据（如占星师案例中的用户信息）以及实现规模化部署。官方确认，Claude Managed Agents 目前已在生产环境中大规模运行。具体的落地案例包括 Notion 的外部代理功能，以及 Atlassian Jira 的集成方案。对于希望构建自有 UI 和产品的团队，官方建议采用 API 优先 的架构模式：开发者负责构建面向最终用户的产品界面和交互逻辑，而将代理的管理、状态维护和执行调度完全通过 API 与 Anthropic 后端对接。这种分离架构允许开发者利用官方提供的 MCP（Model Context Protocol）通道或自定义服务器来连接 Claude，从而实现从内部测试到外部客户分发的平滑过渡。官方强调，“everything is through the API”，即所有核心代理管理功能均通过接口暴露，开发者只需专注于上层应用逻辑。
Sonnet 5 模型支持与 Cloud Code 技能集成
针对开发者关心的最新模型支持问题，官方明确回应 Claude Sonnet 5（Sunet five）已完全支持在 Claude Managed Agents 中使用。开发者可以立即通过 API 调用该模型进行实验和部署。在工具链方面，对于熟悉 Cloud Code（原 Claude Code）的技术团队，Anthropic 提供了专门的 Managed Agent Skill。这一技能允许开发者使用自然语言指令，在 Cloud Code 环境中引导构建代理。这为那些已经具备一定工程能力但希望简化流程的团队提供了低门槛的入口。官方指出，如果开发者在 Cloud Code 中已经建立了与 API 交互的技能或工作流，迁移到 Managed Agents 将非常顺畅。这种设计旨在降低技术门槛，同时保留对底层 API 的完全控制能力。
Cloud Code 与 Managed Agents 的定位差异及企业私有化展望
关于工具选型，官方澄清了 Cloud Code（主要用于个人代理构建）与 Managed Agents（面向团队、组织或最终客户的产品级代理） 的核心区别。对于个人开发者，Cloud Code 依然是极佳的选择；而对于需要构建可复用、可扩展的产品级代理的场景，Managed Agents 是更合适的方案。在自然语言引导方面，“the console quick start is probably like the part of my demo where you're literally just like telling Claude the agent that you're trying to build should make that pretty easy for even non-technical users”。针对企业客户对数据隐私和合规性的强烈需求，特别是希望将代理运行在内部环境（On-prem）以隔离敏感数据的场景，官方表示这确实是“customer ask from a bunch of enterprise customers”。目前 Anthropic 正在认真考虑并评估企业级私有化部署方案，但截至目前尚未发布具体的 On-prem 解决方案。对于现有通过安全代理访问 Anthropic 模型的企业，官方建议先利用现有的 API 集成能力进行探索。
结论
Anthropic Claude Managed Agents 定位为完全托管的企业级 API 基础设施，通过工作区实现多租户隔离与记忆持久化。其核心优势在于“厚技能、薄编排”的设计哲学，允许模型自主优化拓扑结构并降低对复杂外部控制的依赖；“梦境”功能结合评估体系，能自动迭代记忆存储以提升长期任务表现。尽管目前缺乏细粒度权限控制且仅支持 Anthropic 模型，但其全量可观测性与自动化扩展能力显著降低了运维负担。该方案适用于需规模化部署、重视数据隔离及长期上下文一致性的企业场景，而非简单的终端辅助工具。