Orkestra:大规模编排 AI 智能体

本文中的数字反映的是发布时(2026 年 1 月)的系统状态。如需查看最新数据,请参阅我们的 团队页面。

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

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

所以我们打造了 Orkestra。

什么是 Orkestra?

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

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

这些数字很能说明问题:

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

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

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

身份(Identity) 定义了智能体是什么。架构师设计系统结构,调试者把故障追溯到根本原因,守护者执行合规与安全边界。我们有 27 种可以混搭的身份原型。

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

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

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

# 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:

# 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——我们的代码智能平台——背后的整个智能体生态。想了解更多?欢迎联系我们的团队。