来源: Microsoft Open Source Blog
作者: Jason Robert
发布时间: 2026/5/15 00:00:00
原文链接: Conductor：多智能体AI工作流的确定性编排

---

多智能体AI系统正成为处理复杂任务的默认方式：

• 代码审查流水线。
• 先研究后综合的工作流。
• 先规划后执行的循环。

这些都不是单次提示就能解决的问题。它们需要多个专门的智能体按顺序、并行、有时甚至循环地协调工作。

大多数框架的做法是让编排器本身成为一个LLM——一个动态规划调用哪些智能体、以什么顺序、以及使用什么输入的智能体。当任务具有探索性时，这种方法有效。但对于具有已知结构的工作流（实际上，许多最有用的工作流确实具有已知结构），动态编排会增加成本、延迟和不可预测性，反而可能对你不利。

Conductor 是一个开源CLI（MIT许可证，Microsoft组织），它采用了一种不同的方法：你在YAML中定义多智能体工作流，智能体之间的路由是确定性的。Jinja2模板和表达式求值处理条件和分支。编排层消耗零token。结构在定义时固定——这正是关键所在。

当前多智能体工作流的问题

我们一直在构建多智能体工作流——代码审查流水线、设计文档生成、研究助手——并且每次都在编写相同的胶水代码：Python脚本拼接提示链、临时重试、步骤间手动状态管理，没有好的方法来对工作流本身进行版本控制。

我们研究了其他工具，例如Microsoft Agent Framework (MAF)，这是微软用于在代码中构建智能体的主要SDK，它涵盖了许多相同的基本功能。Conductor 为类似的模式提供了不同的界面：一个以YAML优先的CLI，适用于那些希望在不编写SDK代码的情况下组合智能体和工具的团队。声明式、可差异比较、并且像CI/CD流水线一样可读。

我们还希望分离多智能体系统中经常混在一起的不同关注点：

• 编排应该是确定性的且可检查的。而不是由LLM做出路由决策。
• 执行应该支持多个提供商和模型，这样你就可以在分类任务上使用廉价模型，在推理任务上使用强大模型。
• 智能体之间的上下文流应该是显式的。没有隐式的对话泄漏。
• 人工监督应该是一个内置的工作流步骤，而不是事后才添加的东西。

Conductor 就是结果：YAML工作流、隔离的智能体，以及一个在运行任何内容之前就能看到的路由图。

Conductor 的关键能力

YAML定义的工作流

每个Conductor工作流都是一个YAML文件，声明了智能体、它们的提示、模型、输入、输出和路由逻辑。工作流可以进行版本控制、差异比较和审查，就像你对待基础设施即代码或CI/CD流水线一样。

workflow:    name: design-review    entry_point: architect 

 agents:    - name: architect      model: claude-opus-4.6-1m      prompt: |        Create a design document for: {{ workflow.input.purpose }}      output:        file_path: { type: string }      routes:        - to: reviewer 

   - name: reviewer      model: claude-opus-4.7      prompt: |        Review the design at {{ architect.output.file_path }}      output:        score: { type: number }        approved: { type: boolean }      routes:        - to: $end          when: "{{ output.approved }}"        - to: architect 

确定性路由，零token开销

智能体之间的路由使用Jinja2模板和表达式求值。第一个匹配的条件获胜。一个工作流可以通过评估器-优化器循环循环数百次，而路由层不消耗任何token。这就是Conductor与动态编排的区别：工作流拓扑是声明的，而不是在运行时发现的。

每个智能体混合提供商和模型

Conductor 支持GitHub Copilot和Anthropic Claude作为提供商，并允许每个智能体覆盖模型设置。你可以在单个工作流中混合使用它们：使用claude-haiku-4.5进行分类，使用gpt-5.2进行带有MCP工具访问的研究，以及使用claude-opus-4.6-1m进行复杂推理。每个智能体都有自己的会话，没有共享的对话状态。

并行执行

静态并行组可以同时运行多个智能体，并具有可配置的失败模式（fail_fast、continue_on_error、all_or_nothing）。动态for each组以批处理并发方式并行处理可变长度数组。结果会被聚合，并通过模板表达式提供给下游智能体。

parallel: - name: researchers agents: [academic, web, technical] failure_mode: continue_on_error routes: -to:synthesizer

并非每个步骤都需要大语言模型（LLM）。脚本步骤直接运行 shell 命令，将 stdout、stderr 和退出码捕获到工作流上下文中。一个代码审查工作流可以在“实现”和“审查”步骤之间运行 pytest。路由可以根据退出码进行分支。无需模型调用，无需消耗 token。

人工门控（Human gates）

人工门控步骤会暂停执行，在富终端界面（Rich terminal UI）或 Web 仪表盘中呈现选项，并根据响应进行路由。审批工作流、审查检查点、交互式决策点：它们都是工作流图的一部分，定义方式与其他任何步骤相同。

Web 仪表盘

Conductor 包含一个 Web 仪表盘，可实时可视化执行过程。交互式有向无环图（DAG）显示工作流拓扑，并通过动画边展示执行流向。每个节点都可点击，显示智能体（agent）的提示词、模型、token 用量、成本、活动流和输出。人工门控可直接在浏览器中操作。后台模式（--web-bg）会启动仪表盘，打印 URL，并将控制权交回终端。

上下文控制

三种上下文模式控制每个智能体能看到的内容：accumulate（所有先前输出）、last_only（仅上一步骤）和 explicit（仅指定的依赖项）。默认是累积模式，但对于较大的工作流，显式模式能显著减少 token 消耗。仔细考虑每个智能体能看到什么，其重要性远超我们的预期。

插件与工作流注册表

插件遵循 Agent Skills 开放标准，打包了可复用的技能和智能体可使用的 MCP 服务器配置。可以从 Git 仓库或本地路径引用它们。工作流注册表让团队可以共享和版本化管理工作流：只需配置一次注册表，然后通过短名称运行工作流。

安全限制

最大迭代次数限制和挂钟超时（wall-clock timeout）可防止失控执行。试运行模式（dry-run）会预览执行计划，而不调用任何模型。conductor validate 可在任何内容运行之前捕获模式错误、缺失引用和不可达的智能体。

Conductor 不会取代你的编辑器、CI 系统或智能体框架。它是一个 CLI 工具，读取 YAML、调用模型并生成结构化输出。它可以接入你已有的工具：

• MCP 服务器为智能体提供工具访问权限：网络搜索、文档查询、代码分析，任何拥有 Model Context Protocol 服务器的功能。
• Shell 命令可直接作为工作流步骤运行，因此你的脚本、linter、测试套件和构建工具无需修改即可参与。
• 通过 JSON 模式生成结构化输出，使得下游工具和脚本可以程序化地消费结果。
• 仓库中附带了一个 Claude 技能。将你的编码智能体指向它，它就能为你构建工作流。

我们学到了什么

1. 确定性是一种特性

最常见的质疑是：“动态编排怎么办？”问得好。如果你的任务需要根据发现的内容自我重构，那就让 LLM 决定下一步做什么。但我们经常使用的工作流（审查循环、研究流水线、先计划后实现）具有已知的结构。我们更倾向于可预测性、成本控制和可审计性，而不是重新规划的灵活性。条件路由和回环模式覆盖的范围比你想象的要广。

2. 智能体隔离物有所值

每个智能体拥有自己的会话、系统提示词、模型、提供商和温度参数。没有共享对话的干扰。这看起来像是开销，直到你调试一个工作流，其中第 4 步莫名其妙地受到第 2 步输出的影响。显式的上下文流使得多智能体系统变得易于处理。

3. 事件优于日志

引擎使用发布/订阅（pub/sub）事件系统处理所有输出。终端渲染器、Web 仪表盘以及任何未来的消费者都独立订阅。前期工作比直接打印到 stdout 要多，但它将执行引擎与展示层解耦，这种好处会持续显现。添加 Web 仪表盘时，工作流引擎无需任何改动。

4. YAML 是合适的抽象层级

我们考虑过 Python API、JSON 模式和可视化构建器。YAML 恰到好处：可读、结构化、可在拉取请求（PR）中 diff，并且对于任何写过 GitHub Actions 工作流或 Kubernetes 清单的人来说都很熟悉。

开源且立即可用

采用 MIT 许可，从第一天起就开源开发。

• pytest 测试套件覆盖引擎、CLI、配置验证、提供商和集成场景。
• 使用 Ruff 进行 lint 和格式化，使用 ty 进行类型检查，两者均在 CI 中强制执行。
• 支持 macOS、Linux 和 Windows。
• 一行安装命令（curl | sh 和 irm | iex），附带 SHA-256 校验和验证。
• 通过 conductor update 进行自我更新。

欢迎贡献：提供商集成、工作流示例、插件、文档、错误报告。

如何立即开始使用 Conductor

安装：

# macOS / Linux
curl -sSfL https://aka.ms/conductor/install.sh | sh

Windows (PowerShell)

irm https://aka.ms/conductor/install.ps1 | iex

运行你的第一个工作流：

conductor run workflow.yaml –input question=”What is Python?”

可视化工作流：

conductor run workflow.yaml –web –input topic=”AI in healthcare”

Conductor 需要 Python 3.12+，并且可与 GitHub Copilot 或 Anthropic Claude 配合使用。仓库 提供了文档、示例工作流以及入门指南。

多智能体工作流（Multi-agent workflows）正成为基础设施：可重复、可版本化、可在团队间共享。我们选择确定性编排（deterministic orchestration），因为对于最常构建的工作流而言，已知的结构正是其核心所在。

开始使用 Conductor

如果你正在用胶水代码（glue code）拼接智能体管道（agent pipelines），不妨看看 Conductor。

Conductor 在 MIT 许可下开源，地址为 github.com/microsoft/conductor。

Jason Robert 是微软 Azure Core CTO 办公室的首席软件工程师（Principal Software Engineer），他在 Azure 范围内从事 AI 驱动的工程转型（AI-driven engineering transformation）和系统架构现代化（systems-architecture modernization）工作。

查看该作者的更多文章