# Orkestra：大规模编排 AI 智能体

Canonical source: https://maguyva.ai/zh-hans/blog/orkestra-agent-orchestration

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-06 · Author: Maguyva Team

> 一个编排器，把工作分派给各具专长和记忆的专家 AI 智能体。Orkestra 如何在生产环境中协调 46 个智能体和 466 项技能。

> *本文中的数字反映的是发布时（2026 年 1 月）的系统状态。如需查看最新数据，请参阅我们的 [团队页面](/zh-hans/team)。*

当我们开始用 Claude Code 构建东西时，我们撞上了一个每个使用 AI 编码助手的团队迟早都会遇到的问题：一个智能体，没办法把所有事情都做好。

你可以用提示词把一个智能体变成数据库专家，或者安全审计员，或者前端工程师。但一旦你要求它同时身兼这三者，质量就会打折扣。上下文被稀释，指令彼此冲突，智能体就变成了一个万事通，却样样平庸。

所以我们打造了 Orkestra。

## 什么是 Orkestra?

Orkestra 是一套面向 Claude Code 及同类 AI 编码工具的智能体编排系统。它在一个编排器之下，协调多个各有专长的专家智能体，由编排器把工作分派给合适的专家。

可以把它想象成一家面向 AI 智能体的人才中介机构：编排器接到一个任务，判断该由哪个专家来处理，再带着合适的上下文进行委派。工作完成后，结果会流回编排器，进行汇总整合。

这些数字很能说明问题：

| 组成部分 | 数量 |
|-----------|-------|
| 专家智能体 | 46 |
| 可复用技能 | 466 |
| 身份原型 | 27 |
| 思维模式 | 11 |
| 沟通风格 | 10 |
| 知识领域 | 21 |

## 角色系统：智能体的“龙与地下城”

Orkestra 背后的核心洞见是：智能体的行为，是由三种可组合的基本要素涌现出来的：

**身份（Identity）** 定义了智能体*是什么*。架构师设计系统结构，调试者把故障追溯到根本原因，守护者确保合规并维护安全边界。我们有 27 种可以混搭的身份原型。

**思维模式（Mindset）** 定义了智能体*如何思考*。分析型思维把断言建立在证据之上，并量化不确定性；怀疑型思维质疑假设、主动寻找反证；探索型思维拥抱模糊性，尝试多种路径。

**风格（Style）** 定义了智能体*如何沟通*。技术型风格会给出精确数值、引用具体文件；简洁型风格砍掉冗言、直接给出答案；圆融型风格在坦诚与得体之间取得平衡。

一个智能体会把这些要素组合起来：

```yaml
# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise
```

这样的组合，创造出了一个能设计系统（architect）、能跨领域串联知识（knowledge-architect）、能设定战略方向（strategist）、以证据和数据为思考依据（analytical）、并且沟通不带废话（concise）的智能体。

真正的威力在于组合爆炸：27 种身份 × 11 种思维模式 × 10 种风格，能产生近 3,000 种可能的智能体人格。但你只需要定义那些对你的工作真正重要的组合。

## 技能：可复用的能力模块

技能（Skill）是智能体可以调用的知识和工作流。它们遵循一套按作用域分层的体系：

| 层级 | 名称 | 作用域 | 示例 |
|------|------|-------|---------|
| K0 | 基础（Foundations） | 通用方法论 | 测试先行原则、基于证据的任务完成 |
| K1 | 身份（Identities） | 基于角色的工作流 | CLI 界面标准、性能优化手册 |
| K2 | 领域（Domains） | 特定领域的知识 | 数据库迁移模式、身份验证校验 |
| K3 | 技术栈（Stacks） | 特定技术相关 | Cloudflare 部署、Supabase 运维 |
| K4 | 项目（Project） | 仅限本代码库 | 特定于项目的工作流与约定 |

技能是懒加载的。智能体在启动时只会看到技能的名称和描述，完整的技能内容只有在被触发时才会加载。这让上下文保持精简，同时让数百项技能依然可被发现。

每项技能都包含：
- 明确的触发条件（“在迁移数据库 Schema 时使用”）
- 一步步的操作指引
- 该工作流允许使用的工具
- 成功标准与失败恢复路径

我们注册表中的 466 项技能，覆盖的范围从 Git worktree 隔离，到 Web 研究工作流，再到部署健康度验证，应有尽有。

## 为什么编排很重要

单智能体架构很快就会碰壁：

**上下文稀释。** 20 万 Token 的上下文窗口听起来很大，但一旦你把数据库 Schema、API 文档、测试 fixture 和领域知识都塞进去，它就没那么大了。专家智能体可以只处理有针对性的上下文。

**指令冲突。** 让一个智能体既“要全面又要快”，又“要什么都验证、但又别过度设计”，会产生相互牵制的要求。专家智能体通过明确的作用域来协调这些要求。

**专业深度。** 一个万事通智能体，对什么都只懂一点皮毛；而一个搭配了正确身份和技能的专家智能体，能够深入了解自己的领域。

Orkestra 实行的是扁平化编排：一个编排器协调多个专家，专家不能再衍生出子专家。这既避免了复杂度爆炸，又保留了并行工作的能力。

编排器可以调用的有效容量高达 220 万 Token：它自己的 20 万 Token 窗口，再加上 10 个并发子智能体、每个各 20 万 Token。那些足以耗尽单个智能体的工作，在这支舰队上却能从容运行。

## 渲染流水线

智能体的定义存放在 YAML 中，而 Claude Code 读取的是 Markdown。Orkestra 用一条确定性的渲染流水线，弥合了这道鸿沟：

```
YAML Registries → Jinja Templates → .claude/agents/*.md
```

运维人员编辑 YAML 源文件，运行 `orkestra sync`，渲染后的 Markdown 就会出现在 `.claude/agents/` 中，Claude Code 随即拾取这些变化。

这种分离服务于不同的受众：
- **YAML 源文件** 包含生命周期元数据、标签、校验规则，以及供工具使用的弃用提示
- **渲染后的 Markdown** 只包含模型真正需要的内容：描述、工具、技能和行为指引

这条流水线会把身份、思维模式、风格和技能，组合成一份连贯统一的提示词。一个 architect-analytical-concise 组合的智能体，得到的系统提示词，会和一个 debugger-skeptical-technical 组合的智能体截然不同，即便它们共享了一些底层技能。

## 领域知识：四文件模式

每个知识领域都遵循一套一致的结构：

```
domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes
```

这套结构是为智能体的上下文加载而设计的。一个处理身份验证工作的智能体，会加载 `authentication/patterns.md` 来获取指引，加载 `authentication/anti-patterns.md` 来避开已知的坑。这些文件的大小经过权衡，既足够聚焦、能派上用场，又足够全面、具备权威性。

我们维护着 21 个顶级领域，包括数据分析、身份验证、数据科学、基础设施、机器学习、性能和安全等等。每个领域都可以拥有子领域，以获得更细的粒度。

## 价值观：运行的底层系统

所有智能体共享同一套基础价值观，定义了它们该如何运作：

**简单优先。** 使用能奏效的最简单方案，只有在有充分理由时才增加复杂度。

**修复根本原因。** 绝不绕过故障去打补丁。如果一条流水线失败了，就去调试这条流水线；如果一个测试失败了，就去修复代码或者修复测试本身。

**基于证据。** 把每一个论断标记为“已验证”（附带基准数据）或“估计”（附带假设条件）。检测到某种模式，不等于确认了问题的存在。

**上下文经济学。** MCP 工具的开销只占上下文的 0.1%；每次文件读取的开销是 2%。先运用领域专业知识，再去探索代码。

这些价值观会通过渲染流水线，传播到每一个专家智能体身上。任何智能体都无法靠组合方式绕开它们。

## CLI：控制平面

Orkestra 内置了一个用于管理智能体生态的 CLI:

```bash
# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"
```

这个 CLI 是“有哪些智能体存在、它们各自拥有哪些技能、系统是否健康”这些信息的唯一可信来源。它会在同步之前先运行校验，尽早捕获问题。

## 关于开源的考量

我们打造 Orkestra，是为了解决自己的问题：在一个复杂的代码库中，大规模地协调 AI 智能体。但我们发现的这些模式，并不是我们这个领域独有的。

角色组合系统（身份 + 思维模式 + 风格），适用于任何需要定义智能体人格的团队。

技能分层体系（K0 到 K4），提供了一套按作用域组织可复用能力的思维模型。

渲染流水线模式（YAML 源文件 + 模板 + 生成产物），把工具层面和模型消费层面的关注点分离开来。

扁平化编排模型（一个协调者，多个专家），既避免了复杂度，又保留了并行能力。

Orkestra 是否会走向开源，取决于这些模式对其他用 Claude Code 构建产品的人是否有价值。如果你也正撞上我们描述的这些墙，这套架构或许能帮上忙。

## 我们学到了什么

打造 Orkestra 让我们明白：编排的重点，不在于让智能体变得更聪明，而在于让它们变得更专注。

一个拥有完美指令的单一智能体，依然会耗尽上下文。一个拥有全部技能的单一智能体，依然会搞不清该用哪一项。一个试图无所不能的单一智能体，只会在每个地方都产出平庸的结果。

四十个专家，每个都精通自己的领域，由一个懂得何时该委派的编排器来协调——这就是我们交付产品的方式。

数字本身不如架构重要。你可能需要五个智能体，也可能需要五十个。原则始终不变：组合胜过单打独斗的能力，专精胜过泛泛而谈，协作胜过个人英雄主义。

---

*Orkestra 驱动着 Maguyva——我们的代码智能平台——背后的整个智能体生态。想了解更多？欢迎联系我们的团队。*