多智能体不是终点，而是起点：OpenVitamin 的 Agent Orchestration 的工程实现

我们在实际的 AI 应用不断演进的过程中，“多智能体”几乎成为一个必然话题。

很多系统开始引入：

• 多个 Agent 分工执行任务
• Agent 之间相互对话
• 不同 Agent 处理不同领域问题

在实际工程实践中，我逐渐意识到一个问题： 多智能体本身并不能解决复杂性问题。

甚至在很多情况下，“多智能体”会引入更多不确定性。于是我开始重新思考：

这也是 OpenVitamin(github.com/fengzhizi71…) 在设计 Agent 系统时的核心出发点。

一、为什么单 Agent 很快会失控

在最初的 AI 应用设计中，我们通常从单 Agent 开始：

• 一个 Prompt
• 一组工具
• 一段对话上下文

这种模式在简单任务中非常有效，但随着任务复杂度增加，很快会遇到瓶颈：

1. Prompt 复杂度爆炸

所有逻辑都堆在一个 Prompt 里：决策、工具选择、错误处理等等，很难维护。

2. 能力耦合严重

一个 Agent 同时负责：

• 代码生成
• 文件操作
• 测试执行
• 错误修复

导致系统难以扩展。

3. 行为不可预测

随着工具和上下文增加：

• 决策路径不可控
• Debug 成本极高

最终会出现一个典型现象：

二、多智能体的三种常见形态

在开发实践中，我总结了多智能体常见的三种模式：

1️⃣ 并行型（Parallel Agents）

多个 Agent 同时执行任务，然后汇总结果。

例如：

• 多个模型同时回答问题
• 多个 Agent 分别分析不同数据源

优点：简单 缺点：不能解决复杂任务编排问题

2️⃣ 协作型（Collaborative Agents）

Agent 之间互相对话：

• A 提问
• B 回答
• 再循环

优点：灵活 缺点：

• 不可控
• 成本高
• 难调试
• 难复现

3️⃣ 调度型（Orchestrated Agents）

这是 OpenVitamin 当前采用的模式：

• 主 Agent 负责决策
• 子 Agent 负责执行
• 有明确的调用关系

它的本质是：

三、OpenVitamin 的多智能体设计（当前阶段）

当前的 OpenVitamin 的多智能体能力，可以总结为两点：

1. Agent Routing（自动选择智能体）

在 Chat 场景中，系统会自动选择最合适的 Agent。整体流程如下：

这个机制解决的问题是：

2. Agent Delegation（主 Agent 调用子 Agent）

在复杂任务中，一个 Agent 不再独立完成所有事情，而是可以调用其他 Agent。

例如一个编程场景：

在这个模型中：

• 主 Agent 负责任务拆解
• 多个子 Agent 负责具体执行

四、为什么我们没有采用“Agent 互相对话”

很多“多智能体系统”强调：Agent ↔ Agent 对话

但在工程实践中，这种方式也会有明显问题：

• 调用路径不可预测
• Token 成本不可控
• Debug 难度极高
• 执行结果不稳定

因此 OpenVitamin 选择了一条不同的路径：

五、统一执行模型：Agent 只是 Step 的一种类型

在 OpenVitamin 中，多智能体最终会落到统一执行模型：

关键点在于：

这会带来几个好处：

• 统一调度
• 统一追踪
• 统一治理

六、当前阶段 vs 未来演进

这篇文章介绍的是 OpenVitamin 的当前阶段设计。

当前能力

• Agent Routing（自动选择）
• Agent Delegation（主从调用）

OpenVitamin 当前阶段的 Agent Orchestration 架构图

下一阶段（正在设计）

OpenVitamin 将逐步演进到：

• 多 Agent 并行执行
• Event-driven Orchestration
• Agent Memory
• Agent Graph

最终目标是：

七、总结

多智能体的本质，从来不是“多个 Agent”。

而是：

OpenVitamin 当前的设计选择是：

• 用 Routing 解决选择问题
• 用 Delegation 解决协作问题
• 用统一执行模型解决复杂度问题

这只是第一步，多智能体不是终点，而是起点。

项目地址：github.com/fengzhizi71…

欢迎交流 / Star / PR