Multi-Agent 架构踩坑

V1：7 个 Agent 的"完美"设计

一开始我的设计是这样的——7 个专业 Agent，各司其职：

• 基本面分析师 — 看财报、PE、ROE
• 技术分析师 — 看 K 线、均线、MACD
• 风控专家 — 评估风险、仓位建议
• 资金流向分析师 — 看主力资金
• 行业研究员 — 分析行业趋势
• 宏观分析师 — 看利率、政策
• 首席策略师 — 综合所有分析出结论

听起来很专业对吧？每个 Agent 有独立的 system prompt、工具白名单和迭代参数。问题是什么？

# V1 — 场景团队模板（回测场景）
BACKTEST_TEAM = {
    "strategy_designer": {
        "system_prompt": "你是策略设计师...",
        "tools": ["backtest_run", "strategy_validate"],
        "max_iterations": 3,
    },
    "backtest_engineer": {
        "system_prompt": "你是回测工程师...",
        "tools": ["backtest_run", "data_fetch"],
        "max_iterations": 5,
    },
    "risk_assessor": {
        "system_prompt": "你是风险评估师...",
        "tools": ["risk_calculate", "position_size"],
        "max_iterations": 2,
    },
    "chief_strategist": {
        "system_prompt": "你是首席策略师...",
        "tools": ["synthesize"],
        "max_iterations": 1,
    },
}

出了什么问题

问题一：意图解析链路太长

用户问"贵州茅台怎么样"，7 个 Agent 都想发言。意图解析器要把这个问题拆成 7 个子任务，每个子任务再路由到对应 Agent。链路越长，错误放大越严重——第 2 个 Agent 理解错了，后面全错。

问题二：Token 爆炸

7 个 Agent 的 system prompt 加起来就 4000+ token，还没算工具描述和上下文。一次对话轻松超过 8000 token，成本扛不住。

问题三：结论矛盾

基本面说"PE 偏高建议观望"，技术面说"突破关键阻力位建议买入"，首席策略师合不出来。真实场景中这种矛盾太常见了。

V2：3 个核心 Agent + 工具调用

砍掉行业研究员、宏观分析师、资金流向分析师，把他们的能力变成工具而不是 Agent。最终架构：

• 数据获取 Agent — 调工具查数据（行情、财报、资金流、行业数据都是工具）
• 分析 Agent — 根据数据出分析（基本面+技术面+风控一体）
• 策略 Agent — 综合出建议（只在需要时调用）

# V2 — 3 核心 Agent + 工具调用
class ExecutionMode(Enum):
    DIRECT_LLM = "direct_llm"       # 简单问答，直接 LLM
    TOOL_CALLING = "tool_calling"   # 需要调工具
    SUBAGENT_ASYNC = "subagent"     # 委托子 Agent
    EXPERT_INVOKE = "expert"        # 调专家
    SKILL_INVOKE = "skill"          # 调技能
    CODE_GENERATION = "code_gen"    # 生成代码
    PLAN_ONLY = "plan"              # 只规划不执行
    DEBATE = "debate"               # 多 Agent 辩论

关键变化：原来需要 7 个 Agent 协作的场景，现在 1 个 Agent + 多次工具调用就能搞定。意图解析只需要判断"这个问题需要调什么工具"，不需要判断"这个问题该路由给哪个 Agent"。这套架构在 FinBuddy 中已经稳定运行，也是我做 AI SaaS 开发时最核心的设计决策。

教训

1. Agent 不是人 — 不要按人的分工方式设计 Agent。人需要分工是因为认知有限，Agent 不需要。一个 Agent 调 10 个工具比 10 个 Agent 各调 1 个工具简单得多。
2. 工具 > Agent — 能用工具解决的不要开 Agent。工具是确定性的，Agent 是不确定性的。不确定性越少越好。
3. 少即是多 — 第一版 7 个 Agent 的设计虽然有问题，但至少让我知道了问题在哪。如果一直在纸上设计，永远发现不了 token 爆炸和结论矛盾的问题。这跟价值投资里的"少即是多"一个道理——5只看懂的股票比20只看不懂的强，3个核心Agent比7个Agent稳定。