做 open-multi-agent 之前，我调研了 TS 生态里做多 Agent 的几乎所有方案。分成 3 条路，说说各自的取舍。
背景：为什么 TS 多 Agent 编排是个问题
Python 生态有 CrewAI（40K+ stars）、LangGraph、AutoGen，选择多且成熟。TypeScript 这边呢？
直到 2025 年底，TS 开发者想做多 Agent 基本只有两个选择：自己从零搭，或者用 Python 框架跨语言调用。两个都不好。2026 年选择多了，但每条路的代价不一样。
路 1：平台型（Dify / Coze）
可视化拖拽编排，低代码。
适合：不需要代码级控制的业务团队，快速验证场景。
不适合：需要深度定制、和自有后端集成、对延迟和成本敏感的场景。
核心取舍：上手快，但天花板低。 一旦需求超出平台预设的能力，改造成本比从零写更高。
路 2：通用框架 + 自建编排（LangChain.js / Vercel AI SDK）
框架提供 LLM 调用、tool use、streaming 等基础能力，多 Agent 编排你自己搭。
LangGraph JS：图编排模型，手动定义节点和边。表达力强，但心智负担重——你要自己画状态机。
Vercel AI SDK：单 Agent + tool use 做得很好。多 Agent 没有原生支持，要自己在 tool 里套 tool 实现 Agent 间协作。
核心取舍：灵活，但编排层全靠自己。 如果你的多 Agent 逻辑简单（2-3 个 Agent 串行），这条路够用。一旦涉及并行、依赖、动态拆任务，自建的编排层会越来越重。
路 3：专用多 Agent 编排框架（Mastra / open-multi-agent）
框架内置多 Agent 协作机制（Coordinator、Task DAG、Agent 间通信）。
Mastra：TS 全栈框架，刚拿了 250/月起。功能全，但越来越重。
open-multi-agent（我做的）：只做编排这一件事。3 个依赖（anthropic + openai + zod），Goal→Result 一行调用，Coordinator 自动拆任务为 DAG 并行执行。轻，但没有云平台、没有 Dashboard、没有内置可观测性——这些要自己补。
核心取舍：编排开箱即用，但各有代价。 Mastra 的代价是重量和成本，OMA 的代价是周边能力缺失。
没有"正确答案"
选哪条路取决于 3 件事：
- 编排复杂度：2 个 Agent 串行 → 路 2 够用；5 个 Agent 并行依赖 → 路 3 更合理
- 控制要求：能接受低代码 → 路 1；必须 code-first → 路 2 或 3
- 团队技术栈：纯 TS 前后端 → 路 2 或 3；混合语言 → 路 1 可能反而省事
走过这些路的同行，有几个问题想请教：
- 自建编排的，现在还维护得动吗？有没有到某个阶段发现越搭越重，后悔没直接用框架？
- 上了生产的，多 Agent 之间的协作怎么调试？有什么顺手的工具，还是 console.log 硬看？
- 工具链里你自己造了但最后悔的是哪个环节？ 如果重来一遍你会直接买什么？
