conductor
microsoft/conductor加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下：你在写代码时，有好几个 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 工作流有精细控制权、追求确定性执行和版本化管理的开发团队。