利用 Ancho CLI 实现 Agent 资源的 CI/CD 自动化
在讨论如何将 Claude Managed Agents（即 Ancho）集成到持续集成和部署流程时，Anthropic 介绍了其内部使用的 Ancho CLI 工具。这是一个封装了 API 的命令行界面，旨在让用户能够通过类似 Terraform 的方式管理 Agent 资源。用户可以将长期运行的资源配置定义为 YAML 文件，并将其提交到代码库中。
"We have something called Ancho CLI, which is a CLI that basically wraps our API to make calls and allows you to do sort of Terraform-like things where you pass in YAML."
通过这种方式，团队可以在每次对资源进行更改时，利用 Ancho CLI 和 YAML 配置文件来更新 Anthropic 平台上的 Agent 状态。这种 基础设施即代码（IaC） 的模式不仅适用于外部用户，也是 Anthropic 内部构建持久化长期资源的标准做法。开发人员只需将配置文件检入代码库，即可实现 Agent 配置的版本控制和自动化部署。
消息发送机制与执行暂停逻辑
针对开发者关心的并发交互问题，官方澄清了模型在处理 自定义工具结果（Custom Tool Result） 时的行为机制。当 Claude 正在等待外部系统返回自定义工具的执行结果时，执行流程会被暂停。在此期间，如果用户尝试发送新的消息或触发其他操作，系统会直接返回 400 错误。
"We basically pause execution at that time... when it's doing a custom tool result, we're expecting you to send that so because of ordering purposes, we block the calls."
这一设计是为了确保 调用顺序的严格性，防止在关键等待阶段出现状态混乱。然而，如果模型处于其他工作状态（如正在思考或生成文本），系统允许用户 排队消息，以便在模型空闲时按序处理。这种机制平衡了实时交互的灵活性与工具调用的确定性。
评估体系（Evals）的最佳实践与数据质量
在讨论如何维持 Agent 的质量时，Anthropic 强调了 高质量评估数据集 的核心地位。作为托管服务提供方，他们在模型发布前会运行大量内部测试，利用云端并行能力（如同时启动 10,000 个会话）来快速迭代提示词和调整假设。对于用户构建的 Agent，官方建议不要盲目依赖自动化工具生成的评估脚本。
"I think the best advice we can give you is to get high quality data to evaluate over... garbage in, garbage out."
官方指出，许多初始评估方案虽然能达到 100% 的通过率，但这往往是因为测试用例定义模糊或过于简单，无法真实反映模型性能。因此，迭代优化数据质量 比追求表面分数更重要。建议开发者回顾历史会话记录，手动评分并构建更具代表性的测试集，以确保评估结果能准确指导 Agent 的性能调优。
多租户架构与资源权限控制边界
关于如何在组织内部共享 Agent、记忆存储（Memory Store）和 MCP 通道等资源，官方明确了 工作区（Workspace） 是资源隔离的基本单位。所有 API Key 和 Agent 资源都绑定在特定的工作区内，而非直接绑定到个人账号。
"They're bound to your workspace. So any API key within your workspace can have access to the resources that..."
权限管理由 组织管理员（Org Admin） 负责，他们通过创建工作区并分配成员访问权限来实现控制。目前平台 不支持细粒度的资源级共享（例如仅分享 Agent 的一部分功能或单独的记忆模块）。如果需要实现部分资源的隔离访问，开发者需要在应用层通过代码逻辑进行 自定义控制，以决定最终用户能使用哪些功能子集。这种设计简化了平台权限模型，但要求开发者在应用架构中自行处理复杂的共享逻辑。
代码审查自动化与持续验证流程
在构建用于代码审查的 Agent 时，Anthropic 团队展示了如何通过集成 Claude Managed Agents (CMA) 实现自动化工作流。具体做法是，当代码提交 Pull Request (PR) 时触发多个子 Agent 会话并行运行。这些子 Agent 评估代码变更内容并主动寻找潜在 Bug，从而显著降低人工审查的时间成本。内部实践表明，这种机制不仅减少了每 PR 的处理时间和 Bug 数量，还维持了高质量标准。然而，随着 AI 生成代码能力的提升，PR 频率呈指数级增长（从每天到每小时甚至每秒），如何跟上审查节奏仍是一个开放性问题，CMA 被视为解决方案的一部分。
为了形成闭环，团队采用迭代循环模式：Agent 审查并添加评论，直到任务完成。但仅靠静态分析不足以保证功能正确性，因此需要结合部署环节进行验证。自动部署允许使用自定义 Agent 在特定环境中测试代码。此外，Agent 可以在沙箱中运行应用程序进行自我验证（Self-validation），扮演 QA Agent 的角色。虽然目前尚不支持通过 UI 隧道直接让 Claude “游玩”浏览器，但未来可能提供视频反馈以辅助验证。这种“审查-部署-测试”的流水线是应对高频代码变更的关键策略。
多租户隔离与数据合规架构设计
对于企业级用户，真正的租户隔离（Tenant Isolation）是核心需求。Anthropic 明确表示目前不支持本地部署（On-prem），但在云端架构上提供了灵活的隔离方案。用户可以根据合规要求选择不同粒度的隔离级别：
- 按客户定义 Agent：为每个客户创建独立的 Agent，实现数据隔离。
- 按工作区（Workspace）划分：提供比 Agent 更严格的资源隔离。
- 按组织（Org）划分：实现最高级别的物理或逻辑隔离，满足最严格的法律合规要求。
"You can define an agent per customer... or you could do an org per customer. So it depends on how you want to set up your agents."
当需要为多个客户构建同一个 Agent 模板时，有两种主要策略： * 同步更新：将 Agent 定义存储在代码中，利用 CI/CD 工具自动将其同步到多个工作区或组织中。这种方式确保所有客户实例保持一致，任何更新通过代码仓库统一发布。 * 单工作区多映射：将所有客户数据放在单一工作区内，通过维护“客户 ID 到会话”的映射关系来区分用户。Anthropic 提供了元数据字段（Metadata field），允许在会话中嵌入客户 ID。然而，如果存在法律要求的数据隔离（Data Segregation）需求，即不同客户的数据绝对不能混合存储或共享资源，则必须采用独立工作区（Individual Workspaces）方案，因为资源是按工作区分配的。
自定义计算环境与沙箱扩展能力
针对需要更高算力（如 GPU）或更大内存的复杂 Agent 任务，Anthropic 提供的标准沙箱环境目前规格统一。若需自定义资源分配，用户应使用自托管沙箱（Self-hosted Sandboxes）。官方文档推荐集成第三方提供商，如 Modal、EB2 或 Daytona。Anthropic 提供了第一方集成指南和 Cookbook，帮助用户将 Agent Loop 挂载到这些外部提供商的实例上运行。
"If you care about different scale, you would use a different provider for that."
关于具体环境规格，官方文档中列出了标准沙箱的配置详情。对于需要 GPU 加速的场景（如大规模模拟或复杂推理），用户需依赖外部云服务商的算力支持。此外，在构建类似 Discord 的多玩家聊天 Agent 时，可以通过线程级映射（Per-thread mapping）实现。每个用户消息被注入为 user.message，Agent 能识别发送者身份（如 Gabe 或 Priyanka）。通过共享会话记忆，Agent 还能在不同用户间跨会话学习（Learn from each other），实现更智能的多人协作体验。
多租户隔离：基于 Slack Channel 的独立记忆体设计
在构建面向多个用户或团队的 Claude Managed Agents (CMA) 时，数据隔离与权限控制是核心考量。针对类似 Slack 的多频道场景，演讲者指出不应简单地镜像代理的所有回复，而应通过显式的工具调用（如 Slack Post Tool）让代理自主决定何时发布内容，以确保交互的明确性。在架构设计上，推荐采用“每个 Slack Channel 对应一个独立 Agent”的模式。这种设计确保了每个代理拥有独立的记忆体（Memory），且仅能访问当前频道内的消息数据，从而在逻辑上实现了严格的多租户隔离。这种基于通道维度的代理划分方式，不仅简化了权限管理，还有效防止了跨频道数据泄露的风险。演讲者强调，这种模式非常适合需要高度定制化且互不干扰的企业级应用场景。
长会话处理：Exit Criteria 与状态监控机制
针对开发者关心的超长运行时间（如数小时）的 Agent 构建问题，官方明确表示无需特殊的模块支持。实现长会话的最佳实践是利用“退出标准”（Exit Criteria）系统。演讲者演示了如何通过定义明确的评估指标，让 Claude 持续迭代执行任务（例如重建代码库），直到完全符合预设的 Rubric（评分标准）为止。系统会“无情地”持续运行直至达标，无需人工干预或特殊配置即可突破 6 小时限制。在状态监控方面，开发者可通过 Session Event Stream（会话事件流）或 Events API 实时追踪进度。此外，建议设计一个自定义工具如 update_status_for_human，让代理在取得阶段性进展时主动调用该工具推送状态更新。这种机制不仅解决了长任务的可观测性问题，还赋予了代理主动汇报进度的能力。
子代理架构：协调者模式与异步工具处理
为了解决主代理在处理自定义工具结果时可能出现的阻塞或消息丢失问题（如返回 400 错误），演讲者提出了“协调者-子代理”（Coordinator-Sub-agent）架构。在该模式中，主协调器 Agent 始终保持活跃以接收消息，而将耗时的自定义工具处理委托给专门的子代理。具体实现上，主 Agent 定义与子 Agent（如 Agent B）的通信规则，当需要执行自定义工具时，主代理将任务委派给子代理。子代理在其定义中声明并处理自定义工具，并在完成工作后通过会话 ID 将结果返回给主线程。值得注意的是，虽然技术上涉及不同的会话线程（Session Thread），但系统通过 ID 正确路由消息。主代理在委派期间处于空闲状态，而子代理独立工作，这种异步协作模式确保了主接口的响应性。演讲者指出，若需保持主代理始终“健谈”或快速响应，这种协调模式是极佳的选择。
结论
Anthropic Claude Managed Agents (Ancho) 通过 CLI、工作区隔离及协调者架构，构建了支持企业级多租户与 CI/CD 的自动化体系。其优势在于利用基础设施即代码实现资源版本控制，通过工作区层级满足严格的数据合规与租户隔离需求，并借助异步子代理机制解决工具调用阻塞问题。然而，平台目前不支持细粒度资源分享、本地部署及 UI 直接浏览器测试，复杂共享逻辑需应用层自定义。此外，评估有效性高度依赖高质量数据而非自动化工具，长会话则需显式定义退出标准。总体而言，该方案适用于对数据隔离和自动化流程有严格要求的场景，但开发者需自行处理部分架构复杂性与评估质量把控。