多智能体是当前 AI 工程的热门范式。但我在设计 AI 驱动的量化研究系统时选择了单 Agent + 状态机。不是因为多智能体太难，而是因为问题结构不匹配。

一个反直觉的选择

2024 年以来，多智能体（Multi-Agent）几乎成了 AI 系统架构的默认选项。CrewAI、AutoGen、MetaGPT——每个框架都在告诉你：把任务拆给多个 Agent，让它们协作，效果更好。

我在设计一套 AI 驱动的量化研究系统时，认真评估了这条路线，最终没有采用。选择了一个看起来"落后"的方案：单 Agent + 有限状态机。

这不是资源限制或技术能力的妥协。是分析了问题结构之后的主动选择。

问题的结构，不是表象

量化研究的工作流看起来有很多"角色"：有人负责生成策略、有人负责回测、有人负责评估、有人负责风控。自然而然会想到把每个角色映射成一个 Agent。

但这是用组织结构类比技术架构，犯了表象推导的错误。

真正需要分析的是三个结构性问题：

任务之间是并行的还是串行的？

量化研究的核心流程是严格串行的：训练模型 → 回测（依赖模型输出）→ 评估（依赖回测结果）→ 决策（依赖评估结论）。每一步的输入是上一步的输出，没有并行空间。多 Agent 的协调收益在串行流程里是零。

不同 Agent 需要不同的工具集吗？

多智能体的一个核心假设是每个 Agent 有专属工具，工具集之间不重叠。但在量化研究里，“生成策略”、“提交回测”、“查询指标”、“检查约束"全都指向同一套执行引擎 API。四个 Agent 用的是同一把锤子。拆开不增加能力，只增加通信开销。

评估需要主观辩论吗？

有些系统用多 Agent 实现红蓝对抗——一个提出方案，一个专门找漏洞。这在写作、设计等主观任务里有价值。但量化研究的评估是数值确定的：Sharpe Ratio 是 1.2 就是 1.2，IC 是 0.03 就是 0.03。不需要另一个 Agent 来"辩论"指标是否可信。反过拟合检验也是确定性的检查清单，不是主观判断。对抗机制在这里退化成了 if-else 逻辑。

三个条件全不满足。多智能体在这里增加复杂度，不增加价值。

我考虑过的方案

方案 A：多智能体协作

类似 CrewAI 的模式——定义研究员、回测员、评估员、风控员四个角色，让它们通过消息传递协作。

它在什么场景下是对的：任务天然并行（如同时搜索多个信息源）、工具集不可共享（如代码库 vs 生产环境权限隔离）、需要多视角辩论（如产品方案设计）。

它在我的场景下为什么不适用：串行流程没有并行收益；共享工具集拆分无意义；数值评估不需要辩论。额外代价是 Agent 间上下文传递的序列化开销和调试时跨 Agent 日志追踪的复杂度。

方案 B：单 Agent + 有限状态机

一个 Agent 驱动整个研究循环，状态机控制行为边界和状态转换：

INIT → GENERATE → EXECUTE → EVALUATE ──→ FINISH
                     ↑          │
                     └── ITERATE ┘

核心思路用一句话概括：把"多个 Agent 之间的协调协议"替换为"单个 Agent 内部的状态转换规则”。

状态机的每次转换是确定性的：EVALUATE 阶段的指标达标就转 FINISH，不达标就转 ITERATE 回到 GENERATE。不需要 Agent 之间"讨论"下一步该做什么。

关键判断点

做出这个选择的关键不是技术对比，而是认识到一个更底层的问题：多智能体框架解决的是"协调"问题，但我的系统根本没有"协调"问题。

我的系统有的是"编排"问题——一个确定性流程需要被自动化执行，中间穿插 LLM 的生成能力。这更接近工作流引擎（workflow engine）的问题域，不是多 Agent 协作的问题域。

这个认识来自一个类比：传统的 CI/CD pipeline 也有多个阶段（build → test → deploy），也可以映射成多个"Agent"。但没有人会用多智能体框架来做 CI/CD，因为大家直觉上知道那是个串行编排问题。量化研究的迭代流程在结构上和 CI/CD pipeline 是同构的。

实施效果

状态机方案运行了几个月，有几个可量化的对比点：

  • 上下文零丢失：单 Agent 天然共享全部研究历史，不需要跨 Agent 传递中间结果
  • 线性可追溯：每次状态转换都有完整记录（输入代码、输出指标、评估决策、决策原因），出问题直接按时间线回溯
  • 调试时间从"在多个 Agent 的日志里拼凑"变成"在单个状态序列里定位"

没有遇到过需要并行的场景。如果未来需要同时跑 10 个独立的因子研究，那是并发调度问题，用 asyncio.gather 就够了，不需要引入 Agent 间通信。

这个决策教会我什么

我从这次实践中提炼了一条判断原则：

选架构之前，先识别问题的结构类型。不是所有"看起来有多个角色"的系统都需要多智能体。

判断方法是三个问题：

  1. 任务间有并行空间吗？
  2. 工具集有隔离需求吗？
  3. 评估需要主观辩论吗？

三个都不满足，就不该用多智能体。即使只满足一个，也要评估引入的协调复杂度是否被收益覆盖。

这和微服务的演进路径一模一样。2015 年前后所有人都在拆微服务，直到很多团队发现自己的系统根本不需要拆——它们的问题是部署问题，不是服务边界问题。多智能体目前也在经历类似的膨胀期。热度会过去，问题结构分析不会过时。

系列第一篇。下一篇：MCP 的问题不在协议层，在语义层。