conductor
用 YAML 定义多智能体协作路由,微软 Copilot 团队出品的确定性工作流编排 CLI
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
用 YAML 定义多智能体协作路由,微软 Copilot 团队出品的确定性工作流编排 CLI
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:你在写代码时,有好几个 AI 助手同时在后台协同工作——一个负责调研文献,一个负责架构设计,一个负责代码审查,还有一个专门负责把结果整理成文档。它们各司其职、互不干扰,最终把结果汇总到你面前。这就是 Conductor 想要解决的问题:让多个 AI 智能体像一支配合默契的乐队一样,按谱好的乐谱演奏,而不是每次临时拉起一支混乱的即兴乐队。
Conductor 是微软开源的一款 CLI 工具(MIT 许可证),由 GitHub Copilot 团队打造。它的核心定位是:用 YAML 文件定义多智能体工作流,实现确定性的编排路由。不同于大多数框架用 LLM 作为编排器(动态规划下一步做什么),Conductor 将路由逻辑在设计时就固定下来,运行时零 token 开销,零不确定性。
随着 GPT-4、Claude、Copilot 等大模型能力越来越强,单一 AI 助手已经能完成很多复杂任务。但在真实项目开发中,一个任务往往需要多轮不同视角的思考:需求分析 -> 架构设计 -> 编码实现 -> 自动化测试 -> 人工审核 -> 修复问题。传统的做法是反复把上下文喂给同一个 AI,让它自己决定下一步——这既费 token,又容易出现"在同一个思维陷阱里打转"的问题。
更好的思路是:把任务拆给多个专门化的 AI 智能体,每个智能体只做一件事,并用明确的规则定义它们之间的协作顺序。这就是工作流编排(Workflow Orchestration)的核心思想。
微软团队在内部实践中反复遇到同样的问题:每次启动新的多智能体项目,都要重新写一堆 Python 胶水代码,处理重试逻辑、管理状态、设计工作流版本。重复劳动不说,这些临时脚本还很难版本化管理。于是,他们决定把这些问题打包成一个通用工具,这就是 Conductor 的由来。
Conductor 的工作流以 YAML 文件为核心载体。以一个设计评审工作流为例:
workflow:
name: design-review
entry_point: architect
agents:
- name: architect
model: claude-opus-4.6-1m
prompt: |
为以下需求创建设计文档:{{ workflow.input.purpose }}
output:
file_path: { type: string }
routes:
- to: reviewer
- name: reviewer
model: claude-opus-4.7
prompt: |
审查设计文档:{{ architect.output.file_path }}
output:
score: { type: number }
approved: { type: boolean }
routes:
- to: $end
when: "{{ output.approved }}"
- to: architect # 评审不通过,回流到架构师
这个 YAML 清晰定义了:有哪些智能体(architect、reviewer)、各自使用什么模型、接收什么输入、输出什么结构化数据、以及路由条件是什么。路由逻辑完全基于 Jinja2 模板表达式,第一个匹配条件生效——没有 LLM 参与编排决策,token 只花在真正的业务任务上。
这种设计的精妙之处在于:工作流本身可以被版本控制、Code Review、Diff 比较。你可以在 Pull Request 里看到工作流的变更,就像看代码变更一样。这对于团队协作和质量把控意义重大。
Conductor 支持同时接入多个 AI 提供商:GitHub Copilot、Anthropic Claude(各类模型)、Claude Agent SDK,以及实验性的 NousResearch Hermes。用户可以在同一个工作流中,让 Haiku 做分类、Sonnet 做文案、Opus 做深度推理,各取所长。项目文档中有一个「multi-provider-research.yaml」示例,展示了在一个研究工作流中如何让不同模型负责不同阶段。
工作流支持静态并行组(多个智能体同时运行)和动态并行(for_each),即对数组中的每个元素并行启动子流程。失败模式可配置:fail_fast(一个失败全部停止)、continue_on_error(部分失败不影响整体)、all_or_nothing(全部成功才算成功)。这对于多源调研汇总类场景特别有用。
通过 sub_workflow 引用,可以把一个 YAML 工作流嵌套到另一个中,并使用 input_mapping 做参数映射。子工作流也可以用在 for_each 并行组中,实现动态扇出。这使得工作流可以像乐高积木一样复用。
工作流可以在任意节点暂停,等待人工确认后再继续。暂停时,终端会以 Rich 渲染格式显示上下文信息(Markdown 渲染、文件链接可点击),CLI 和 Web Dashboard 都支持该功能。这对于代码审核、敏感操作确认等场景非常实用。
除了 LLM 驱动的智能体,Conductor 还支持纯 Shell 脚本步骤。stdout、stderr、退出码都会被捕获并写入工作流上下文,后续路由条件可以基于脚本执行结果分支。这使得 CI/CD 流水线(如运行 pytest、linters)可以无缝集成进工作流。
运行 conductor run workflow.yaml --web,即可启动一个本地 Web Dashboard,实时展示工作流的 DAG 图(含动画边)、每个节点的详细状态(模型、token 消耗、耗时)、活动日志,以及人工确认按钮。背景模式 --web-bg 支持将 Dashboard 作为守护进程运行。

图1:Conductor Web Dashboard 实时展示多智能体工作流的 DAG 执行图
从源码结构来看,Conductor 的核心模块分为以下几个部分:
| 模块 | 职责 |
|---|---|
engine/ | 工作流引擎核心:上下文管理(context.py)、路由决策(router.py)、事件日志(event_log.py)、限流熔断(limits.py)、断点续跑(checkpoint.py) |
executor/ | 执行器,运行单个智能体调用 |
providers/ | AI 提供商适配层:copilot、claude、claude_agent_sdk、hermes(实验性) |
cli/ | 命令行入口:app.py(Typer CLI)、run.py(执行命令)、validate.py(YAML 校验) |
gates/ | 条件判断门卫 |
config/ | 配置管理 |
依赖项方面,Conductor 使用 Typer 构建 CLI(优于 Click 的结构化体验),Pydantic 做数据建模,Rich 做终端美化输出,ruamel.yaml 解析 YAML(保留注释),Jinja2 做模板渲染,httpx 做 HTTP 客户端。整体技术栈现代、Pythonic。
安装方式极为简单,官方提供一键安装脚本:
# macOS / Linux
curl -sSfL https://aka.ms/conductor/install.sh | sh
# Windows PowerShell
irm https://aka.ms/conductor/install.ps1 | iex
安装脚本会自动检测并安装 uv(如果缺失),拉取最新 release,校验 SHA-256 完整性,并通过重命名切换的方式安全升级(Windows 下避免文件锁问题)。升级命令 conductor update 会提示最新版本和升级命令。
上手门槛方面,YAML 工作流定义需要一定学习成本,但文档非常完整(docs/workflow-syntax.md 覆盖了所有语法细节),示例工作流覆盖了主要场景。Python >= 3.12 是唯一环境依赖,无需 GPU。
路由表达能力有限:基于 Jinja2 条件的路由适合结构化分支,但对需要动态推理的复杂场景(如根据对话内容判断下一步)不如 LLM 编排灵活。
工具生态仍偏早期:虽有 MCP 支持,但可用的 MCP Server 数量与 LangChain 等框架相比还有差距。
YAML 复杂度:随着工作流规模增长,YAML 文件会变得冗长,虽然有 IDE 语法校验,但不如代码表达力强。
微软强绑定:默认 Copilot 优先,Claude 集成虽然完善,但部分功能(如 Claude Agent SDK provider)标记为 experimental。
Conductor 代表了 AI 工作流编排领域的一个重要趋势:从"LLM 做主厨"转向"LLM 做专家,规则做服务员"。确定性编排在代码审核、测试生成、文档流水线等场景有明确优势:可预测、可审计、可优化。
从增长角度看,GitHub Copilot 的装机量和 Claude 模型的普及,为这类工具提供了肥沃的土壤。Conductor 的 MIT 许可和 CLI-first 设计也降低了企业采纳门槛。
一句话总结:Conductor 是微软 Copilot 团队内部实践的结晶,用 YAML 替代胶水代码,让多智能体协作从"临时即兴"走向"谱曲演奏"。适合希望对 AI 工作流有精细控制权、追求确定性执行和版本化管理的开发团队。