单体架构的辉煌与局限：Unix 的概念完整性
1969年，Ken Thompson在贝尔实验室利用妻子外出探亲的一个月时间，通过高度自律的模块化开发完成了Unix内核、编辑器及汇编器等核心组件。这一过程的核心价值在于概念完整性（Conceptual Integrity），即单个开发者能够在脑海中完整把握整个项目的全貌并执行端到端的开发。这种模式虽然高效，但严重依赖个人的认知负荷极限，难以应对日益复杂的系统规模。
大规模协作的教训：OS/360与《人月神话》
相比之下，IBM在1960年代至70年代初构建System/360及OS/360的操作系统的尝试，展示了另一种极端。为了应对硬件升级导致软件需重写的痛点，IBM投入了约5,000人年的资源，雇佣多达1,000名工程师。项目经理Fred Brooks从中总结出著名的《人月神话》，提出有效的团队组织应类似外科医生团队：由一名主刀医生（领导者）掌控全局概念完整性，周围环绕着语言专家、副手等各司其职的10名专家。这种结构能在小范围内创造奇迹，但同样面临扩展瓶颈。
Linux 的演进：从星型结构到信任网络
Linux内核的发展史则展示了如何突破单体瓶颈。早期Linus Torvalds采用星型结构（Star Structure），所有开发者直接向其提交补丁。然而，随着贡献量激增，Linus在1998年因邮件列表的混乱而濒临崩溃。正如他当时所言：
"I'm going on vacation. I don't want to hear it. Get out of my inbox."（我要去度假了，我不想再听到这些。别往我的收件箱里发邮件。）
规模化协作的解决方案：分层信任机制
问题的转机来自Larry McVoy提出的版本控制建议，他指出核心痛点在于"Linus doesn't scale"（Linus无法扩展）。直到2002年左右，Linux社区才正式转型为网络结构（Network Structure）。在这种结构中，贡献者不再直接面向Linus，而是向受信任的维护者提交代码；只有极少数例外情况才会上升至最高层。这种分层机制将原本由36个不同参与者直接贡献的混乱状态，优化为每层仅约4人进行汇报的高效层级。这一历史经验直接映射到当前的AI领域：面对具备能力的模型，我们需要构建类似的多智能体编排系统，以解决更大规模的问题。
Anthropic 推出 Flows：多智能体编排的下一代形态
Anthropic 在四月份推出的 Claude Managed Agents 产品中，正式支持了一项名为 Flows 的新功能。这一功能被视为多智能体编排（multi-agent orchestration）的进化版本，其核心愿景是让 Claude 能够完全自主地编排自身复杂的多智能体拓扑结构。这种能力旨在模拟现实世界中复杂的组织互联网络，使 AI 能够像人类团队一样自我协调。此前，用户在 Claude Code 中体验过的 动态工作流（dynamic workflows） 已经展示了这一方向的可能性。当用户输入指令要求 Claude 执行复杂任务时，系统会自动启动一个由多个智能体组成的复杂网络。底层利用 JavaScript 引擎支持 Map-Reduce（映射与归约） 等深层活动，使得智能体能够根据内部训练和自身能力，自动决定如何有效协作以完成更高难度的任务。这种全自主的代理自动化（fully agentic automation）被视为解决人类最棘手问题的关键路径。
单智能体的局限与多智能体拓扑的优势
在探讨为何需要复杂的多智能体系统时，演讲者指出了 单智能体（single agent） 在处理高难度任务时的显著局限性。虽然具体数据仅为示意，但趋势表明：单智能体在运行一小时后往往就会失效，难以应对雄心勃勃的任务。相比之下，Anthropic 早期的多智能体方案 Coordinator and Roster（包含一个协调者和一层子代理）能够运行更长时间，但仍受限于单层结构。动态工作流则允许 任意复杂的嵌套智能体集合并行运行并相互交互，这是解决真正困难问题的关键。演讲者提到，许多用户正在自行构建复杂的多智能体框架来解决单智能体的瓶颈，但这种手动实现带来了巨大的工程挑战。例如，当一百个代理中的某一个在两小时后崩溃时，系统需要处理 容器重启 和 状态恢复，确保能准确找回断点并理解整个拓扑的状态。这种手动编排不仅非平凡（non-trivial），而且难以扩展。
协调者瓶颈与可观测性难题
除了执行时间的限制，单智能体作为唯一协调者的容量上限 也是主要痛点。演讲者引用了 Linus Torvalds 的例子，指出即使是像他这样卓越的协调者也无法有效管理 60 个下属代理 的复杂状态。在 Anthropic 的用户反馈中，一个常见的痛点是 如何检查已构建的智能体图（graph of agents）的状态。开发者不得不逐一探查图中的每个节点，或者将所有信息汇聚到协调者处，才能了解进程中的实时状态。这种可观测性的缺失导致了严重的可用性限制：在 Claude Code 能力爆发后，用户甚至需要在公园长椅上不断点击“批准”按钮以防止代理因超时或交互中断而死亡。这种 人为维持运行 的模式被 Anthropic 视为对解决社会级宏大问题的巨大阻碍，因为这种模式无法规模化。因此，Anthropic 致力于将复杂的拓扑结构嵌入其生态系统，提供原生的生命周期管理。
Claude Managed Agents 的 API 架构与状态持久化
为了解决上述问题，Anthropic 推出了 Claude Managed Agents API。这是一个让 Anthropic 代为管理智能体生命周期的接口表面（API surface）。用户只需定义一个包含技能、工具和 MCP 服务器列表的智能体，然后在会话（session）中实例化它即可开始工作。该 API 表面支持存储 有状态的 API 资源，并通过 持久化事件日志（durable event log） 实时监控所有活动。这种架构消除了用户手动处理容器重启、状态同步和拓扑可视化的负担，使智能体能够独立运行并完成复杂任务。演讲者提到，这一产品在过去一年中是其团队每日关注的核心，旨在通过标准化的 API 解决多智能体编排中的基础设施难题。目前约有 50% 的与会者已了解该功能，Anthropic 希望进一步推广这一能真正支持大规模自主代理运行的平台。
从手动线程管理到动态工作流
在传统的多智能体系统（Multi-Agent V1）架构中，开发者必须显式定义主代理能够启动的每个子代理。这种模式类似于操作系统中的进程与线程管理：虽然共享部分状态，但必须手动管理各个代理间的信息传递。这种底层架构的复杂性使得即使 API 表面支持多智能体协作，实际搭建过程也绝非易事。开发者需要监听每个代理运行的“线程”，处理上下文隔离与状态同步，这极大地增加了集成难度。
“It's a lot like, you know, an operating system... typically in order to share state, you have to like manage message sends uh back and forth between all the threads.”
为了解决这一痛点，Anthropic 推出了Cloud Managed Agents（云托管代理）中的动态工作流。这一新特性旨在让开发者能够以极简的方式从日益强大的模型中获取能力。通过引入动态工作流，系统不再要求开发者预先编写复杂的连接逻辑，而是让代理具备自主规划与执行的能力。这种转变使得构建复杂产品成为可能，而无需像过去那样在 Cloud Code 中手动连接各个系统组件。
主代理的自主编排与执行机制
动态工作流的核心在于“引导型代理”（Lead Agent）的自主规划能力。以将一个百万行代码库从 Python 迁移到 Rust为例，引导型代理首先负责制定整体任务计划。一旦计划生成，该代理能够根据自身的理性判断和能力评估，自动扇出（fan out）并启动一组子代理。这些子代理在多个阶段中协作，完成离散且可验证的工作单元。
在这种架构下，开发者无需干预代理间的连接管理。例如，在第一阶段，引导型代理可能会启动多个“探索者代理”去读取文件；在第二阶段，这些子代理可能进一步识别文件特征或执行具体转换。这种机制允许系统根据任务需求动态调整资源，实现了对复杂任务的自动化拆解与执行。通过这种自动化的多代理编排平台，Anthropic 认为这是通过 API 表面完成极高难度工作的路径。
实时监控、预算控制与中断机制
在动态工作流运行期间，Anthropic 提供了强大的可观测性与控制手段。首先，系统提供单一事件流（single event stream），允许开发者实时查看每个代理正在执行的具体操作。这种实时监控能力对于调试和理解复杂工作流至关重要。
针对大模型应用中常见的“Token 饥饿”问题，系统允许在启动会话前设置预算限制。这确保了开发者不会意外消耗大量 Token。此外，如果监控系统发现代理偏离预期方向或需要调整策略，开发者可以通过 API 表面实时中断（interrupting）代理执行。这种即时干预能力使得动态工作流不仅适用于自动化场景，也适合需要人工监督的混合流程。
“You can set budgets on your sessions before kicking them off so you don't actually only burn substantial amounts of tokens.”
控制台演示：股票监控扫描器案例
为了展示这一功能的实际效果，演讲者通过 Cloud Console 演示了股票监控扫描器（Stock Watch List Scanner）动态工作流。Cloud Console 是 API 集成者管理 Anthropic API 服务中所有资源的界面，其中“Manage Agents”部分包含了所有相关资源。演讲者选择了一个预置模板，该配置创建了一个使用 Claude Opus 5.5（注：原文如此）的代理，并指定了类型为 multi-agent 2026-10-01。
在配置中，系统提示词（System Prompt）定义了代理的角色 persona。点击使用后，后台会自动创建相应的代理资源并启动环境。为 Claude 提供计算机访问权限是提升其能力的关键，配置环境即赋予代理操作真实世界工具的能力。演讲者强调，这种工作流可以通过 Webhooks 监听或定时任务触发（例如 GitHub 上的 Bug Hunter 工作流），非常适合集成到 CI/CD 流程或内部系统中，而无需开发者实时在终端交互。
“Configuring your environment is like the way that you give Claude access to this computer... giving Claude access to a computer makes it way way more capable just across the board.”
交互式控制台的实时多智能体编排演示
在Anthropic的演示环境中，用户通过简单的界面操作即可启动复杂的多智能体编排（Multi-Agent Orchestration）流程。演示者选择了一个名为“stock watchlist scanner”的环境，并输入了包括Apple、Nvidia、Amazon等在内的股票列表。点击“Start a session”后，系统立即启动了一个会话线程。这个界面展示了平台的核心能力：利用现有的API原语和托管代理（Managed Agents），通过提示词驱动Claude自动完成实际工作。
进入会话面板后，可以看到一个层级化的代理结构。演示者将主代理比作金字塔顶端的“CEO”，负责管理下方的所有子代理。Claude根据任务的复杂性，动态地自组织并生成所需的子智能体集合，以分步骤实现目标。在后台，系统并行启动了多个单上下文窗口的代理实例。这种机制允许Claude根据任务需求灵活地向上或向下扩展智能体数量，例如在之前的演示中，每个步骤仅维持约6个并发代理。这种动态扩展能力是单智能体无法比拟的，它使得系统能够处理更复杂、并行的信息检索与分析任务。
"Basically like Claude is going step-by-step based on its own self-orchestration using its own self-defined essentially set of agents to go off and step-by-step achieve each of these things."
从原型验证到生产环境代码集成
在控制台中完成流程的原型设计和测试后，下一步是将工作流整合到用户的应用程序或自动化脚本中。这种从交互式实验到代码集成的过渡，是构建生产级AI应用的标准路径。例如，用户可以设置定时任务，在开盘前5分钟自动运行股票扫描器以生成报告；或者通过Slack等接口触发这些工作流。集成过程极其简洁，只需在配置中启用多智能体功能并发送初始事件即可启动工作流。
代码层面，开发者只需传递一个包含多智能体配置的对象给代理创建函数。默认情况下，Claude会动态生成执行任务所需的子代理；但开发者也可以选择预配置特定的专业子代理，例如专门负责查询Yahoo Finance、SEC Edgar网站或特定新闻源的代理。这种灵活性允许企业将现有的专业工具链嵌入到AI工作流中，同时还可以为代理赋予自定义技能（Custom Skills）和MCP服务器访问权限。此外，环境本身也是可定制的：用户可以选择使用Anthropic托管的环境，也可以将沙箱部署在自己的基础设施中（Bring Your Own Sandbox），从而实现完全自托管的私有化运行。
"It's just to like tell Claude, yes, use multi-agent and yes, run a workflow."
单智能体局限性与多代理并行处理优势
为了阐明为何需要多智能体架构，演示者对比了单智能体与多代理在处理股票扫描任务时的差异。如果使用单个Agent，用户通常需要在Claude Code中直接输入股票代码并请求研究结果。虽然单智能体会尽力完成，但在处理大量并行任务时面临显著瓶颈。多代理架构（Flows）的核心优势在于将庞大的股票列表拆分，并将每个股票代码分发给独立的“扫描代理”并行处理。
这种任务分解与并行执行（Task Decomposition and Parallel Execution）的策略，极大地提升了信息获取的效率和深度。每个子代理专注于单一标的的深度扫描，避免了单智能体在处理长上下文或复杂并行任务时的注意力分散和性能衰减。通过这种结构化的分工，系统能够同时处理多个独立的数据源和分析任务，最终由主代理汇总结果。这种架构不仅提高了吞吐量，还增强了系统的鲁棒性，因为单个子任务的失败不会导致整个工作流的崩溃。这种从“单兵作战”到“团队协作”的转变，是多智能体系统解决复杂现实问题的关键所在。
隔离上下文与流程化扫描
在构建复杂的AI代理系统时，将任务拆解为独立的上下文环境是提升效果的关键。以“看盘扫描代理”（Watch List Scanner）为例，系统首先将其转化为一个隔离的上下文环境。在这种模式下，代理只关注单一的股票代码（ticker），完全不受其他股票代码或搜索结果的影响。这种隔离确保了扫描过程的纯粹性和准确性。当扫描阶段完成后，任务会移交至下一个环节——审查步骤（Review Step）。审查步骤同样拥有独立的上下文环境，它可以选择性地决定是否将报告细节反馈给扫描器或生成最终输出。这种模块化设计允许每个阶段专注于其特定职能，避免了多任务并行时的干扰。
"It is an isolated context where all it cares about is its one ticker, and it can operate without being like influenced by any of the other tickers or any of the other search results from the other contexts."
深度搜索的成本与效能权衡
当对比单一代理运行模式与流程化（Flows）运行时，核心差异体现在资源投入的深度与结果的全面性上。使用流程化方法时，用户需要明确是否愿意为了不留死角而支付更高的成本。流程运行虽然费用更高，但在发现细节方面的有效性显著优于单一代理。这类似于使用Claude Code时的动态工作流体验：用户通过增加计算资源来换取更深入的探索。在底部右侧的对比中可以看到，流程模式的成本明显更高，但在中间面板的效果展示中，其捕捉细节的能力更强。这种权衡要求用户在任务开始前评估：是否值得为了“不遗漏任何一块石头”而增加预算。对于需要极高准确率和全面性的任务，流程化是更优选择。
分阶段资源分配策略
为了优化成本与效果，可以在提示词中为不同阶段分配不同的模型资源。例如，在扫描阶段（Scan Phase），可以使用快速且高效的Haiku模型。具体策略可以是：为每个股票代码启动两个Haiku代理进行全面的互联网扫描，这一阶段成本较低且速度快。而在审查阶段（Review Phase），由于需要深入分析扫描回来的网页细节，建议投入更多资源，使用更强大的Fable模型。此时可以指示Claude：在每个股票代码的审查阶段部署两到三个Fable代理，以确保深度分析。这种策略允许用户根据流程中的关键点灵活调整资源投入。通过这种方式，用户可以精确控制每个阶段的计算支出，从而在预算范围内获得最佳结果。
"You can kind of imagine each of these flows being something that you can kind of like expand and contract based on how much you want to invest in that point in the process."
工具集成与初始提示技巧
在操作层面，推荐使用Claude Code结合Ant CLI来管理受管代理（Managed Agents）。虽然控制台提供了模板，但通过Claude Code内部调用API技能可以更直接地控制资源启动。对于新安装的用户（周日晚上起），可以直接在Claude Code中运行受管代理模板。此外，初始系统提示词的设计对流程效果有重要影响。实验发现，在初期给予Claude更模糊、自由形式的指令往往更有效。用户只需告知目标（如“使用工作流代理扫描特定代码”），让Claude自主构建初始流程，后续再进行微调。这种“先放手后控制”的策略能激发模型更强的自主规划能力。
订阅福利与技术支持细节
Anthropic为Max和Team订阅用户提供了额外的API信用额度以支持实验。具体而言，Max 5X订阅每月提供100美元信用额度，Team订阅最高可达500美元，此外还有额外的50美元用于实验Claude受管代理流程。这些资源旨在降低用户尝试新功能的门槛。关于技术架构，Claude Code本身运行在本地或云端（取决于用户设置），与受管代理系统是分离的。当用户在Claude Code中运行API技能时，它会在本地环境中通过命令行接口向云端发送API调用以创建代理和会话。插件（Plugins）目前包含多种资源类型，其中技能（Skills）是重要组成部分，API界面中通过“resources”字段进行关联管理。这种分离架构确保了开发环境的灵活性与云端执行能力的稳定性。
"With Max and team subscriptions, you get some like API credits that are part of your subscription... Max 5X, you'll get like $100 a month. And then Teams is up to 500."
插件组件的API集成与工作流分发现状
在讨论如何将动态工作流（如潜在收购研究）作为插件有效分发的议题时，目前的官方立场是该功能尚未完全支持。虽然单个插件组件可以直接融入现有的API表面，但将完整的工作流转化为可分发的插件并非开箱即用的选项。对于希望复用工作流的开发者，一种可行的替代方案是将运行过程中生成的提示词（prompt）提取出来，保存为文本文件并纳入版本控制。这种方法虽然需要手动处理，但生成的提示词通常与原始工作流高度接近。正如演讲者所言："The answer is not today... you could take the prompt basically that's generated as part of your workflow runs, and just drop that into like Claude Code or wherever"。这表明当前的集成策略更倾向于组件化复用而非整体工作流的自动化分发，开发者需通过手动提取提示词来实现一定程度的流程标准化。
自定义工具实现跨环境执行与预算优化策略
针对在非托管环境（如本地Mac OS或其他互联网计算机）上运行Agent的需求，Anthropic引入了自定义工具（Custom Tools）这一抽象层。该机制允许模型在需要执行特定操作时，向外部系统发出调用请求。开发者可以定义自定义工具，当工作流运行时遇到此类指令，即可在本地机器上执行相应动作并将结果返回给模型。这种设计实现了计算环境的解耦。在优化Token消耗方面，虽然目前缺乏原生的自动化调优工具，但开发者可以利用Claude Code中的爬山算法技能（Hill Climb Skill）来优化提示词本身。此外，通过获取完整的运行转录记录（transcripts），开发者可以请求Claude分析流程中过度执行或不足的部分。演讲者指出："you effect you'll have the full transcripts of everything that Cloud has done as part of the flow runs... ask Claude to optimize based on whatever criteria you want"。这种基于自我反思与转录分析的方法，为长期优化Token效率提供了灵活的路径。
记忆结晶、拓扑可视化与预算控制机制
为了提升Agent的记忆能力，Anthropic提供了名为Dreaming（梦境）的产品功能。该功能允许在Claude Managed Agents中，将一系列会话通过"做梦"过程进行结晶化（crystallize），从而改善与这些会话相关的记忆存储。开发者既可以使用Dreaming产品，也可以利用Flows自行实现类似功能。在可视化方面，控制台支持实时查看多Agent拓扑结构。每个Flow启动的子Agent都拥有独立的会话线程，所有基于线程的信息均可通过API访问。开发者可以构建自定义UI来监控每个子Agent的详细活动。系统会发出全面的事件流，包括工具调用、结果返回以及主从Agent间的手势交接。关于预算控制，当前模型在运行时并不直接感知其预算限制，因为告知具体金额可能导致模型产生焦虑情绪。相反，系统采用护栏机制：当达到设定阈值（如$5）时触发事件。开发者可以在会话运行期间检查情况并动态调整预算。演讲者强调："The budget is primarily like guardrails to make sure that it doesn't go off and uh, run away token spend"。这种设计确保了安全性与灵活性的平衡，同时保留了未来让模型感知预算的可能性。
产品生态整合：从API到Slack的无缝衔接
Anthropic正在致力于消除不同产品线之间的壁垒，使Claude Code、Chat和Tag等表面更好地协同工作。虽然目前Claude Tag主要作为Slack中的机器人存在，用于整合用户信息，而API则面向开发者构建直接集成，但两者并非完全隔离。未来几个月内，这些产品间的界限将逐渐模糊。用户可以在多种表面上使用Claude Code，这种融合趋势类似于之前Co-work和Chat的合并。对于希望构建类似Tag功能的开发者而言，Flows提供了极大的灵活性。尽管目前尚未建立直接连接，但通过利用API和现有组件，开发者可以自行构建复杂的集成方案。Anthropic内部也将Claude Tag视为日常工作的核心工具（daily driver），这表明其不仅面向外部客户，也是内部高效运作的关键基础设施。随着产品线的整合，这些接缝将开始消失，为用户提供更统一且强大的AI体验。
智能体间通信机制：基于文件系统的间接交互
在Flows架构中，子代理（sub-agents）之间缺乏直接的API通信通道。也就是说，无法通过API强制子代理A向子代理B发送特定负载。然而，这种限制并非不可逾越的障碍。所有共享的子代理都共用一个文件系统，这使得它们可以通过读写文件来实现事实上的消息传递。如果工作流需要子代理间进行数据交换，它们可以将结果写入文件供其他代理读取。虽然缺乏像“发送/接收消息”那样直观的抽象层，但这种基于文件系统的通信方式依然有效。目前，系统没有提供直接强制代理间对话的机制，但文件系统充当了隐式的消息总线。这种设计允许开发者在需要时构建自定义的通信协议，尽管这需要更精细的工作流编排。对于复杂的多代理协作场景，理解这一底层机制至关重要，它决定了数据如何在各个智能体节点间流动和同步。
提示词自我优化：Hill Climb与Dreaming技术
为了实现智能体的自我改进，Anthropic引入了类似“爬山”（Hill Climb）的迭代优化策略。在Claude Code中，用户可以通过/claude api hill climb命令启动这一过程。该功能借鉴了Andrej Karpathy的Auto Research概念，将其封装为一种技能（skill），使用户能够迭代改进提示词。例如，在开发一个用于与孩子玩猜谜游戏的工具时，开发者利用Hill Climb命令让Claude记录视频片段（如划船、打网球），并据此优化提示词，调整帧率等参数。Claude可能会生成一个人工界面供用户迭代，也可能直接输出优化后的提示词。此外，结合“Dreaming”功能，代理可以回顾过去的行为并从错误中学习。部署（Deployments）允许在预定时间运行这些会话，虽然目前不支持自动自我提升的调度，但开发者可以利用现有组件构建此类自动化系统。这种机制使得提示词优化从手动尝试转变为系统化、数据驱动的迭代过程。
千级 Agent 并发构建操作系统的实战案例
Anthropic 团队展示了一种极具野心的自动化开发模式，即通过“Flow”（流程）机制调度大量子智能体完成复杂任务。演讲者 CJ Avilla 分享了一个具体案例：他在周五启动了一项旨在构建兼容 Unix 且包含 Python 解释器的操作系统的任务，并授权该流程使用多达 1,000 个智能体进行协作。这一任务被设计为长时间运行的后台工作，演讲者期望在周一早上能看到初步成果。
“Hey, Ken Thompson made Unix in a week. Can you try and make an operating system that's Unix compatible with a Python interpreter? Use flows, you know, feel free to be brave and use up to 1,000 agents.”
该任务被提交至一个 GitHub 仓库，截至检查时已产生约 1,000 次提交（commits）。尽管任务耗时已超过 85 小时且尚未完全结束，但这证明了系统能够承载这种大规模、长周期的并发工作负载。这种模式适用于那些无法在短时间（如 30 秒）内由单智能体完成，但可以通过组织化方式分解的雄心勃勃且复杂的任务。对于此类项目，用户只需设定初始指令并让系统自主运行即可。
多智能体协作中的边际效应与组织优势
针对“增加子智能体会导致协调成本上升从而产生收益递减”的疑问，演讲者承认目前尚缺乏精确的数据支持来界定最佳智能体数量。他认为这一研究领域仍处于早期阶段，未来可能会得出更明确的能力曲线（capability curve）或边际效益斜率。然而，关键在于使用“Flow”机制而非无序地堆砌智能体。
通过 Flow 提供的组织性隔离（organized isolation），即使使用相同数量的智能体（例如 100 个），有结构的流程也能比无序投放表现更好。这是因为 Flow 引入了门控（gating）和不同阶段之间的上下文隔离，从而减少了混乱。这种结构化的方法使得系统能够在处理大规模并发时保持一定的秩序，尽管具体的协调成本临界点仍需进一步研究确定。
错误控制、上下文隔离与文件系统权限管理
为了防止智能体陷入无限循环或产生级联错误，系统提供了多种控制机制。首先是预算限制（budget），通过设定 token 或时间上限来防止会话失控；其次是 Claude 自身具备较强的错误检测能力，能够自动识别并切断表现异常的智能体。此外，系统还支持“梦想”（dreaming）和爬山算法（hill climbing）等机制，允许从过往运行中学习以优化特定流程部分。
在上下文隔离方面，每个智能体都在独立的会话线程中运行，拥有完全分离的上下文窗口（separate context windows）。默认情况下，这些隔离是物理层面的，不存在通过文件系统泄露上下文的风险。每个智能体还可配置独立的系统提示词（system prompts），以强制执行不同的人格或角色。
“Each of the agents is spawned into its own session thread that's like totally like physically in the database like separate context windows. And so there's no leakage of those context windows via file systems or anything like that by default.”
关于文件系统权限，目前主要依赖提示词工程（prompting）来约束智能体仅访问特定目录路径，尚缺乏原生的细粒度权限层。演讲者表示这可能是一个有价值的改进方向。对于更复杂的访问控制，可以通过在应用层叠加逻辑或使用工具抽象（tool abstraction）来实现类似钩子（hooks）的功能，以精细控制智能体对文件系统的访问范围。
权限控制与凭证管理的精细化治理
在构建大规模AI智能体系统时，安全边界的确立是首要前提。CJ Avilla指出，当前的架构允许对智能体的文件访问权限进行细粒度配置。当智能体尝试读取特定文件或执行操作时，系统可以根据预设策略要求用户或操作系统授权。例如，若需锁定特定路径（如 /mnt/fubar），开发者可以拦截Claude发出的读取请求，检查发起该操作的智能体身份，并据此决定是否拒绝访问。这种机制解决了“让一千个智能体在互联网上自由运行是否安全”的核心担忧，为后续讨论的代理安全性（Agentic Safety）奠定了基础。Harrison Stall强调，虽然目前尚无一键分享按钮，但通过Terraform提供商和控制台的导出功能，组织可以实现智能体资源的标准化分发与权限隔离。
人工反馈集成与中间状态的可观测性
针对智能体运行过程中可能出现的错误或方向偏差，Anthropic提供了人工反馈（Human Feedback）的集成方案。开发者可以通过定义“请求人类反馈”的自定义工具，让Claude在关键节点暂停并等待人工指令。这种机制不仅用于纠正错误，还允许用户在智能体“死亡”或陷入僵局时介入。为了监控运行状态，CJ Avilla分享了一个实际案例：在构建操作系统文档时，他配置了一组由Sonnet 5.5驱动的“文档编写者”智能体团队，在每个流程阶段结束后自动生成详细的技术文档。这些文档实时同步至GitHub仓库，使开发者无需等待最终结果即可通过查看中间状态来评估进展。此外，系统支持中断会话（Interrupting a session），允许用户随时叫停并重新引导智能体的工作方向。
动态信息注入与遥测数据的多模态处理
当智能体在半程运行中发现外部新信息（如新的数学引理）时，系统支持动态会话中断与信息重注入。开发者可以暂停当前流程，将新信息提供给主智能体。由于主智能体保留了完整的上下文状态和历史记录，它能够基于新旧信息的结合重新规划后续步骤。虽然目前不支持在计划中途直接插入单个步骤并重跑，但这种基于完整状态的重启机制确保了逻辑的连贯性。在遥测（Telemetry）方面，Anthropic提供了丰富的持久化事件流（Durable Event Stream）API，支持实时或静态查询智能体运行时的所有事件。对于游戏开发等场景，虽然目前通过截图进行实时多模态交互可能因延迟而不适合高频操作，但Claude Managed Agents已支持图像输入。开发者可以将游戏崩溃时的截图发送给智能体进行事后调试，利用其日益增强的图像检查能力分析错误原因。
托管代理的部署形态与API集成策略
在将Claude Managed Agent（托管代理）交付给客户时，Anthropic目前尚未提供API层面的第一类共享机制。因此，最常见的部署方式是构建产品界面。开发者需要搭建自己的网站或应用程序作为前端层，用户通过该界面与后端的托管代理进行交互。这种模式使得大量Claude的交互直接发生在API层面，并作为功能模块嵌入到最终产品中。例如，在一个流行的项目管理工具中，当用户将看板卡片从一个列拖拽到另一列时，这一动作可以触发一个Claude托管代理会话。该会话在后台运行特定的流程或执行任务，而不是作为一个直接面向用户的前端组件存在。这种设计使得代理功能更加隐蔽且无缝地融入业务流程中。
多智能体协作解决代码审查的上下文缺失问题
在软件开发的拉取请求（PR）审核流程中，人类评审者往往依赖对代码库整体架构的隐性知识来识别潜在风险。然而，单个 AI 智能体通常只能看到当前 PR 涉及的代码片段，缺乏全局视野。为了解决这一痛点，Anthropic 引入了 Bug Hunter（漏洞猎人）工具，通过多智能体协作机制来弥补这一缺陷。该流程首先由一个阶段负责筛选出可能存在的真实问题候选项，然后将其呈现给人类或后续的智能体进行验证。这种设计模拟了人类开发者的思维模式，即基于对代码库其他部分的了解来预判风险。
"If you were a human reviewer of a PR... often will have context about different parts of the code base that aren't even mentioned as part of this PR."
在验证阶段，系统可以启动一个证明者（Prover）智能体，自动下载代码仓库并尝试复现 bug 或验证问题的严重性。这些智能体不仅识别问题，还会在 PR 中内联添加评论，指出特定文件修改如何导致代码库远处角落出现意外问题。系统还能根据问题的严重程度提供优先级排序。这种机制允许开发者将更多的“测试时间计算资源”投入到代码库的关键部分，特别是对于单体仓库或包含多个子仓库的复杂项目结构。通过 Cloud Code 和 Claude API Skill Managed Agent on board Bug Hunter，开发者可以轻松部署这一流程，从而有效关闭 PR 审核的反馈闭环。
Explainer Studio：自动化生成品牌化解释视频
除了代码审查，多智能体工作流在内容创作领域同样展现出巨大潜力。Anthropic 团队使用 Explainer Studio（解释器工作室）来生成 Twitter 上发布的产品功能动画视频。这一流程将复杂的视频制作任务分解为多个独立的智能体阶段，包括研究、规划、侦察和事实核查。首先，一个智能体会深入研究主题（如“动态工作流如何运作”），整理所有细节并构建一份设计简报。随后，这份简报被传递给生产阶段的智能体，负责制作单个场景并进行动画渲染。此外，还有专门的阶段处理音效、配音和脚本编写。
"4 years ago, making the videos that we publish on Twitter would have taken like... 20 hours or something to animate and make beautiful. And now it's just, you know, one very small prompt off to a flow."
这一自动化流程极大地提升了效率。演讲者指出，四年前制作此类高质量动画视频需要耗费约 20 小时的手工工作，而现在只需向智能体流发送一个简短的提示词即可。通过 Cloud Code 和 Explainer Video Maker，用户可以轻松复现这一效果。例如，输入“DNS 是如何工作的？”即可自动生成解释视频。该工具还支持品牌定制，用户可以通过 Claude Design 定义字体、颜色和背景风格，确保生成的视频符合公司品牌规范。这种从研究到最终成品的端到端自动化，显著降低了专业内容制作的门槛和时间成本。
动态工作流处理大规模复杂任务：合同审查案例
当单个智能体无法应对过于庞大的任务时，动态工作流（Dynamic Workflows） 提供了另一种解决方案。在这种模式下，智能体不再仅仅是执行者，而是工作流的编写者和协调者。演讲者展示了一个实际案例：需要审查 300 份合同以查找特定的“控制权变更条款”（change of control clauses）。面对如此大量的文档，单个智能体难以一次性处理所有细节。
在此场景中，用户只需下达指令，服务器后台的智能体便会自动编写并运行相应的工作流。该工作流会将任务分解，分别处理不同的合同片段或事件。最终，所有智能体的结果会被汇总并整合。虽然演讲中未展示具体的合同审查视频细节，但强调了这种机制能够处理超出单个智能体能力范围的任务。通过动态生成工作流，系统可以灵活适应不同规模和复杂度的任务需求。这种能力使得 AI 能够处理从代码库验证到大规模法律文档审查等多样化场景，展现了多智能体系统在可扩展性和任务分解能力上的优势。
单一智能体的三大致命弱点
在构建复杂AI应用时，单智能体（Single Agent）在处理大规模任务时会暴露出三个核心缺陷：代理懒惰（Agentic Laziness）、自我偏好偏见（Self-preferential Bias）和目标漂移（Goal Drift）。以故障排查为例，若要求智能体检查50个服务并找出根因且严禁触碰生产环境，单智能体在确认前35个服务健康后，极易产生“一切正常”的错觉，从而停止后续检查以节省Token。这种代理懒惰导致结果不可靠。
“After it sees 35 services are healthy, then it starts to like convince itself that oh, it's like everything looks good... Let me just not look at the rest.”
此外，自我偏好偏见使得智能体难以客观评估自身生成的代码或诗歌；而随着上下文窗口扩大，初始指令（如“不要触碰生产环境”）可能被目标漂移所掩盖。相比之下，基于Flow的工作流通过“扇出（Fan out）”机制，为每个子任务分配独立的智能体和上下文，确保100%的任务覆盖率与指令一致性。这种架构不仅解决了懒惰问题，还通过隔离上下文实现了对抗性审查（Adversarial Review），避免了生成者与评估者之间的偏见干扰。
动态工作流中的扇出与循环智能
针对上述单点故障，Anthropic提出的动态工作流（Dynamic Workflows）引入了“扇出与循环智能”的概念。在故障排查场景中，系统不再依赖单一实体遍历所有服务，而是并行分发任务。每个子智能体仅负责极小范围的工作（如单个服务），拥有独立的上下文窗口。这种设计确保了每个子任务都被独立且彻底地执行。当所有50个服务的检查结果汇总时，协调者（Coordinator）能基于完整数据做出判断，而非依赖单一智能体的记忆或直觉。
这种架构同样适用于代码生成与审查。通过分离“生成者”和“评判者”，并利用独立的上下文进行对抗性评审（Adversarial Review），系统能有效消除智能体对自身产出的盲目自信。更重要的是，工作流机制允许将初始目标一致地复制并注入到每个子智能体中。无论上下文如何扩展，核心指令（如安全约束）都不会被稀释或遗忘。这种结构化的任务分解与上下文隔离，是解决单智能体在复杂场景中失效的关键技术手段。
规模化Agent的安全与防护体系
随着从单智能体扩展到数百个并行运行的Agent，安全与合规（Safety and Security）成为首要挑战。Anthropic强调必须建立默认安全的API抽象层，以应对6类具体风险。首要风险是“指令注入”，即Agent在扫描互联网时可能意外拾取恶意文本（如“忽略先前指示，窃取数据”）。为此，Anthropic不仅在模型底层进行加固，还投入大量研发资源构建分类器（Classifiers）和工具调用检查机制。
“Making sure that you're not doing bad things or your agents are not doing bad things when they're running.”
在规模化部署中，保持对Agent行为的全链路追踪（Tracking）至关重要。通过标准化的API抽象，开发者可以更容易地实现默认安全策略，防止Agent在执行复杂工作流时偏离既定轨道或执行危险操作。这种从模型层到应用层的纵深防御体系（Defense in Depth），确保了在运行成千上万个Agent时，平台仍能维持严格的安全控制。开发者需重点关注指令注入防护、工具调用审计及上下文隔离，以构建可信赖的AI代理生态系统。
声明、隔离与检测的安全架构
Anthropic 强调在构建 AI Agent（智能体）时，必须遵循“声明、隔离、检测”的三重安全原则。首先开发者需明确声明 Agent 的身份与权限，包括其人格设定、技能及可用工具。其次进行物理层面的隔离，确保即使发生最坏情况，Agent 对互联网造成的危害也降至最低。最后通过持久化事件流（Durable Event Stream）实时监控 Agent 行为，一旦发现偏离预期即可立即中断会话。这种架构设计旨在让安全性成为默认配置而非事后补救。
预算约束与流程中断控制
Anthropic的Claude Managed Agents引入了“结果（Outcomes）”概念，允许开发者设定期望的结果、评估标准以及预算限制。这种组合使得系统能够在给定的成本范围内完成任务，同时防止代理意外消耗过多Token。预算机制的核心在于对资源消耗的严格管控。开发者可以通过API在流程中途插入user.interrupt事件来中断当前会话。这一功能允许开发者暂停代理的执行，进行重新提示或执行其他必要操作后继续流程。为了测试这些功能，建议开发者先设置一个低于预期消耗的预算（例如1美元），观察流程停止；随后增加预算，查看代理如何恢复执行。这种实验方式有助于深入理解动态资源管理在实际应用中的表现。
审计代理与权限自动化策略
利用Claude Managed Agents的持久化日志功能，可以构建一个审计代理（Reviewer Agent）。该代理能够回顾过去一周或更长时间内的所有会话记录，检查是否有异常行为、未授权的工具调用或不预期的操作。开发者只需将过去的转录文本传递给代理，并询问是否存在异常即可实现自动化安全审计。此外，Anthropic强调开启“自动模式（Auto Mode）”是最低成本的优化手段。研究表明，人类在面对频繁确认请求时，有97%的概率会无脑点击“批准”，这带来了巨大的安全风险。相比之下，Claude在自动模式下能更耐心地判断工具调用的安全性，区分无害操作与破坏性动作。因此，将权限策略从“始终询问”切换为自动模式是提升安全性与效率的关键步骤。
凭证库与安全注入机制
在管理代理的凭据时，Anthropic推荐使用凭证库（Vaults）而非简单的环境变量文件。以Twilio API为例，传统做法是将包含API密钥的.env文件上传至容器，但这会导致明文泄露风险。使用凭证库时，开发者可以定义注入位置（Injection Location），指定密钥在网络出口处是以Bearer Token形式还是请求体中的明文出现。同时，通过配置网络哈希（Networking Hash）和允许的域名列表，系统能确保密钥仅在指定的目标域（如Twilio官方API）被替换和发送，防止密钥泄露到恶意域名。创建会话时，平台会自动根据凭证库中的配置和出口层的占位符逻辑，智能地注入正确的安全值。此外，开发者还可以默认禁用web_fetch和web_search等高风险工具，仅在明确需要时启用，从而进一步缩小攻击面。
工具级权限控制与环境隔离
在构建 AI Agent（智能体）时，安全与权限管理是核心考量。Anthropic 强调不应让 Agent 拥有无限制的访问权，特别是对于潜在的恶意工具或敏感数据泄露风险。开发者可以在 MCP（Model Context Protocol）层面，针对每一个具体工具进行启用或禁用设置。通过逐工具的精细化控制，可以确保 Agent 仅具备完成特定任务所需的最小权限集。此外，网络访问限制可以通过环境配置在物理层面实现。将 Agent 的运行环境视为 Claude 实际操作的计算机，开发者可以严格规定其网络出口。例如，若仅需访问 api.twilio.com，可在环境配置中明确指定该域名。任何尝试连接其他域名的请求将在防火墙层物理失败，从而有效防止 API 密钥等敏感信息被窃取或滥用。
Flow 的设计理念与迭代优化策略
Anthropic 认为，当前许多组织在构建 AI Agent 时，实际上是在重新发明上世纪 70-80年代关于如何组建大规模人类团队以实现工程壮举的组织学习成果。Flow（流程）功能的推出旨在提供这种经过验证的规模化协作能力。对于用户提出的“如何迭代优化不可直接验证的任务（如视频生成）”的问题，演讲者建议采用分步策略。首先使用 Claude Code 进行动态工作流探索或直接生成内容，将人工反馈和迭代过程编码为 Skill（技能）。随后在 Claude Managed Agents 的 Flow 中复用该技能。初始阶段通常涉及大量的迭代，包括通过事实调查理解现有流程，并利用“爬山算法”（Hill Climb）技能优化提示词。这一过程可以是半自动的：Agent 生成多个选项，人工选择偏好项，通过这种人机协作的方式不断迭代提示词以提升质量。>
沙箱环境与UI交互的技术实现
在构建基于事件流的交互式用户界面（如技术图表）时，Anthropic提供了高度通用的工具集。开发者可以利用返回的事件流添加技术分析功能，实现复杂的交互体验。这些通用工具使得在沙箱之上构建几乎任何类型的UI成为可能。关于原生Anthropic环境与自托管（self-hosted）沙箱的兼容性，官方指出两者在核心功能上保持高度一致。Flows（工作流）在自托管环境中完全受支持，开箱即用。
尽管大部分功能跨环境通用，但自托管沙箱可能不支持某些特定高级特性。创建会话时传入的环境参数类型会随之改变，这要求开发者在架构设计时需考虑环境差异。然而，Anthropic团队致力于确保核心功能在所有部署环境中得到统一支持。对于需要高度定制化UI的场景，利用事件流机制是最佳实践，因为它提供了足够的灵活性和扩展性。
多仓库依赖图与CI流程的集成策略
在处理如Bug Hunter这类涉及多仓库依赖图的复杂场景时，Anthropic Cloud的决策逻辑高度依赖于其访问权限。如果赋予Cloud对GitHub仓库的访问权，这些代码库将被挂载到Cloud运行的容器内部。在此基础上，Cloud能够根据项目结构采取不同策略：对于拥有清晰依赖树（如Bazel构建）的项目，Cloud可直接利用容器内的工具进行依赖检查；而对于缺乏显式映射的纯文本语言项目，Cloud可能需要通过搜索文件符号来手动构建依赖关系。
针对PR审查等场景，每次操作都需要重新挂载容器和代码库，这与传统的CI作业流程相似：先执行Git检出（checkout），再采取行动。为了优化这一过程，预先构建并上传依赖图文件到会话中是显著的加速手段。平台支持通用文件上传，开发者可将预先计算好的依赖图指定给Cloud，从而避免每次运行时重复生成耗时较长的图谱。这种机制有效平衡了灵活性与性能。
多Agent拓扑限制与私有数据访问方案
关于多层级嵌套的多Agent架构，目前的现实是系统仅支持一层嵌套。Anthropic尚未支持任意复杂的“超级扇出”拓扑结构，主要原因是必须确保安全性等关键要素在复杂层级中得到严格锁定。未来可能会扩展此能力，但目前需优先保障安全稳定性。
对于数据位于VPN后方、本地机器无法直接访问的场景，MCP Tunnels（通过Cloudflare Tunnel实现）是解决私有数据接入的标准方案。该机制允许Agent在不暴露任何内容到公共互联网的前提下，直接连接至运行私有MCP服务器的位置。这种直连方式确保了数据访问的安全性与私密性，是处理企业内部敏感数据的推荐路径。
Anthropic内部工作流与Claude Tag应用
在Anthropic自身的工作实践中，团队深度依赖“Claude tag”这一功能来自动化处理日常任务。例如，系统会自动监控Jira在过去24小时内的活动状态，并主动提出对工单的改进建议。这种自动化工作流通过设定特定时间触发（如每天早上6点）即可无缝运行，展示了Claude在自主执行周期性任务方面的强大能力。
结论
Anthropic推出的Flows通过分层信任与动态扇出机制，有效突破了单智能体在长时运行、上下文隔离及并行处理上的瓶颈。该架构利用文件系统实现子代理间接通信，结合预算控制、权限隔离及持久化事件流，解决了大规模协作中的可观测性与安全性难题。案例证明其在代码迁移、合同审查等复杂任务中具备显著优势，但受限于单层嵌套结构及较高的Token成本。目前插件分发尚不完善，需依赖提示词提取等手动方案过渡。