多智能体数据分析系统：为什么我们选了 dspy
评测先行。多智能体系统最容易翻车的地方不是编排，是「你不知道它什么时候变差了」。
我们做了一个让运维人员用自然语言查询、分析、归因数据的系统。 选型阶段在 LangGraph 和 dspy 之间摇摆，最终选了后者。
决定性因素：评测
多智能体系统有一个非常隐蔽的性质：它会慢慢变差，而且没人知道是什么时候变的。
提示词改一版、模型版本升一次、工具返回格式调整一下——都有可能在某个你测不到的 query 上引入退化。等到用户投诉才发现，通常已经过去两周了。
dspy 的核心价值不是「编排」，而是它把优化目标变成了可度量的指标：
import dspy
class Analyze(dspy.Module):
def forward(self, question: str, schema: str) -> dspy.Prediction:
plan = self.planner(question=question, schema=schema)
query = self.query_writer(plan=plan.reasoning, schema=schema)
return self.executor(sql=query.sql)
# 有一份真实的历史问题集，就能跑回归
metric = dspy.ExampleBasedMetric(
examples=[
dspy.Example(
question="上周五晚高峰期的丢包主要来自哪些链路？",
schema="network_metrics",
reasoning="需要先筛出高丢包链路，再关联当时流量判断是否拥塞",
sql="SELECT ...",
).with_inputs("question", "schema")
]
)编排能力其实是最不重要的
这一点和大多数人的预期相反。
LangGraph 给你显式的状态机、循环、条件分支——这些在流程确定时是优点。 但数据分析这类任务，流程恰恰是不确定的：要查几张表、要几轮迭代、要不要回溯， 本身就要模型决策。用硬编码的状态机去套，等于替模型做了它最擅长的判断。
dspy 的选择是：流程尽量扁平，把复杂度藏在「模型能不能选对工具」里。
代价
诚实地讲，选 dspy 也付了代价：
- 学习曲线陡，
Signature的心智模型需要几天才能建立 - 调试链路长，出错时不好定位是提示词问题还是模型问题
- 生态比 LangGraph 小，遇到冷门场景要自己造
什么情况下我会选 LangGraph
如果流程是确定的、需要严格的审批节点、或者涉及不可逆的外部动作， 显式状态机的价值就压倒一切了。没有普适最优解，只有和任务形态的匹配问题。