CJ Avilla 与 Harrison Stall：协调和约束多智能体工作流

CJ Avilla 首先对比一个人能掌握的小项目与大型工程所需的协调。他用早期 Unix 和 IBM 的 OS/360 作历史例子。

他回顾 Fred Brooks 从大型 OS/360 项目中总结的组织经验，包括让小型专家团队保持概念上的一致性。

Avilla 接着介绍 Linux 贡献规模的增长，以及让每项修改都直接交给一个人的困难。他把由此产生的瓶颈比作一个人管理许多编码智能体。

他描述的模式是由可信维护者组成网络，先审查工作，再把特殊情况向上汇报。这一类比引出了多个智能体如何组织工作的问题。

Avilla 和 Harrison Stall 介绍自己是 Anthropic 技术团队成员。工作坊结合概览、演示和实践练习。

Stall 介绍 Claude Managed Agents 中的 Flows：主智能体可以通过 API 规划和协调多智能体工作流。本文产品细节反映的是工作坊录制时的情况。

讲者将动态选择工作流形态与手工连接每个智能体及依赖关系作比较。他们把并行工作和结果汇总描述为系统可以针对合适任务选择的模式。

他们认为，在复杂任务中，单个智能体或单一协调者可能受到限制。这是采用多智能体结构的动机，并不保证增加智能体总能改善结果。

Stall 列出定制编排的挑战：恢复失败的容器、协调众多工作者，以及查看整张工作图的状态。即使尚未判断输出质量，基础设施管理也可能很困难。

Managed Agents 被描述为存储智能体资源并管理会话生命周期的 API。配置可以包含工具、技能和 MCP 服务器，事件日志记录活动。

早期多智能体方案要求用户定义子智能体名单并管理其线程。Flows 的目标是让主智能体随任务进展规划阶段并选择工作者。

一个阶段可能把工作分发到隔离上下文，再把结果交给下一阶段。讲者把工作单元描述为可分别验证，但验证质量仍由应用负责。

平台提供事件流、会话预算和中断机制，帮助操作人员观察支出，并停止或调整正在运行的工作流。

讲者区分交互式 Claude Code 工作流与 API 接口：后者可以集成进应用、定时任务或 webhook 驱动流程。

Stall 在控制台演示股票观察名单扫描模板。他为智能体配置环境并给出一组股票代码进行研究；这只是工作流演示，并非投资建议。

会话展示主智能体和多个并行线程。Stall 查看先前运行，展示工作者如何创建以及进度如何在界面中显示。

Avilla 解释，团队可以先在控制台制作原型，再把 flow 集成到产品或定时任务中。应用可以在指定时间或通过其他界面触发扫描。

示例在配置中启用多智能体，并要求运行工作流。用户也可以配置专门子智能体，提供自定义技能、工具或 MCP 服务器。

观察名单示例把每个股票代码交给隔离的扫描上下文，再把结果交给独立审查阶段。隔离可以减少任务间干扰，但不能证明每条事实都正确。

讲者说，他们的示例中 flow 找到了更多细节，但成本也高于单智能体运行。他们建议用有代表性的评估集衡量实际任务的质量和费用。

团队可以为不同阶段分配不同模型或工作者数量，例如先做低成本扫描，再进行更深入的审查。合适分配取决于实测表现。

讲者建议先给出清晰目标，让系统提出 flow，再逐步完善。宽松提示是一种实验，不能替代明确约束或评估。

问答中，他们解释本地或云端的 Claude Code 会话可以调用独立的 Managed Agents API 来创建资源和启动工作。两者是不同的执行环境。

技能等单独资源可以提供给 API，但讲者说演讲时还不能把整个生成的 flow 作为插件分发。他们建议保留其文本配置。

自定义工具可以把工作交给其他环境，例如本地计算机，再返回结果。集成方负责实现和控制外部行动。

被问及成本优化时，Stall 建议检查执行记录中的多余工作，并按预期标准比较修改。智能体提出的改进仍需要独立评估。

Avilla 介绍名为 Dreaming 的记忆处理过程，可以利用先前会话更新记忆库。他们把它作为从重复运行中学习的一种方式，而非效果保证。

控制台可以可视化正在运行的拓扑，API 也提供单独线程事件。开发者可以自行构建界面来显示交接、工具调用和输出。

演讲时，模型不会获知自己的剩余预算。预算作为保护限制，到达上限后会话可以暂停，由操作人员决定是否增加额度。

讲者说子智能体有独立上下文线程，但共享文件系统。共享文件系统可以用来沟通；演讲时 API 并没有直接命令强制一个工作者向另一个发送消息。

他们讨论利用过去运行和评估迭代提示词。定时部署不会因为被定时就自动自我改进；团队需要自行设计这一过程。

被问及科学研究时，讲者推测更多测试时计算可能有助于解决难题。他们没有证明演示工作流解决了任何特定的未解科学问题。

Avilla 说，当时的配置允许一个 flow 使用最多 1,000 个智能体。他的操作系统实验已经运行数天，在工作坊期间仍未完成。

被问及收益递减时，Stall 说自己没有可靠的量化答案。协调成本和质量应通过测量获得，而不能从智能体数量推断。

预算可以限制失控支出，讲者还表示协调者可能发现部分行为异常的工作者。任何一种机制都不能证明所有循环或级联错误都已防止。

对于根据外部变化决定是否执行，Stall 建议在应用层进行检测。他说，如果单个智能体很快就能完成简单任务，大型 flow 未必合适。

每个子智能体有独立的上下文线程，也可以有自己的系统提示词。但独立上下文窗口不等于文件系统访问控制。

被问及共享文件系统的目录隔离时，Stall 说所述方案当时没有内置的逐目录权限层。仅靠提示词不是安全边界；工具权限检查是一种可能的补充控制。

对于 flow 运行中的人工反馈，讲者建议使用请求输入的自定义工具。操作人员也可以中断会话并提供新信息，而不必丢弃全部既有工作。

Avilla 说，他的长时间实验会在阶段结束后编写文档，让中间进展可供检查。输出文件和仓库提交也可以成为审查材料。

讲者说，演讲时用户可以中断并带着新信息重新启动 flow，但不能在现有计划中插入单一步骤后直接重放后续步骤。

他们讨论用事件流构建产品界面和遥测。示例支持图像输入，但他们提醒这可能不适合实时游戏交互。

对于分享智能体定义，讲者提到导出和基础设施即代码，同时说明所述 API 当时没有一键分享机制。

被问及应使用多少并行度时，他们建议采用较低默认值并进行评估。不能仅因为上限允许，就让简单任务使用一千个智能体。

Avilla 建议逐步向子智能体提供相关文档，例如用索引指向每个工作者需要的文件。这可以减少不必要的上下文，但不应把凭据放进这些文件。

Bug Hunter 示例把代码切片交给独立阅读者，汇总候选问题，再进行后续审查与复现。报告旨在帮助人工审查，不保证修改没有错误。

验证者可以检查仓库并尝试复现候选错误，包括与修改文件之外代码的交互。之后可以连同支持性背景报告发现。

Explainer Studio 示例使用研究、规划、事实核查和制作阶段生成动画解释视频。讲者介绍自己将其用于视频，并有配音和音效等额外工作。

讲者列出三种常见失败模式：没有检查全部项目就停下、偏爱自己的输出，以及偏离原始目标。分离范围和审查阶段是提出的缓解方法，不是保证。

在故障示例中，单个智能体可能检查了一些正常服务后提前停止。给每个服务分配有限检查可以让覆盖情况更容易核实，但仍须确保检查实际执行并验证。

独立审查者可能减少自我偏好，把原始目标和约束传给每个阶段可能减少偏离。两种做法都取决于实现和评估。

Stall 转向规模化安全：不可信网页内容可能包含提示注入，暴露的凭据可能被滥用，敏感数据也可能通过获准工具或网络外传。

他把操作方的工作分成声明权限、限制智能体能接触的范围，以及发现异常行为。事件流有助于调查，但必须实际配置监控并采取行动。

讲者描述将推理和会话状态与执行行动的沙箱分开。在他们的设计中，占位凭据只在出口代理处、针对配置的目的地替换成真实值。

预算和中断是两种不同控制：前者限制支出，后者让操作人员停止会话并调整方向。预算不能替代行动权限控制。

他们建议审查持久事件记录，发现意外工具使用。他们还讨论自动权限检查与审批疲劳；自动分类器会出错，不能替代与风险相适应的策略。

凭据库示例限制凭据注入的位置。幻灯片指出一个重要限制：外部服务返回的 token 仍可能进入沙箱，因此响应中的秘密信息需要单独考虑。

他们建议尽量缩小工具集并限制网络目的地。MCP 服务器提供的工具可能变化，因此权限应按集成所需粒度检查。

最后问答中，Avilla 建议对视频等主观产物通过人工反馈迭代，再把流程整理为可复用形式并评估。人的偏好仍是循环的一部分。

他们再次区分交互式的一次性工作流与应用或定时任务通过 API 集成的 flow。选择取决于预期交互和部署方式。

事件流可以驱动显示消息和工具调用的自定义界面。讲者把它描述为通用集成接口，而不是正确性的保证。

被问及多个仓库时，他们说智能体可以检查挂载的代码和已有依赖信息。提供已知依赖图可能节省工作，但输出仍需要审查。

一位讲者澄清重要限制：演讲时所述 flow 只支持一层嵌套，并非任意层嵌套。此前对复杂层级的宽泛描述应结合这一澄清理解。

对于私有网络后的资源，讲者讨论把 MCP tunnel 作为一种可能的集成路径。访问和网络规则仍需根据组织环境设计。

工作坊以剩余问答结束，并提醒针对预期任务测试控制措施和工作流。这些例子展示可能的编排模式，并不能证明更多智能体总会产生更好结果。