13. 多智能体专家组：单个教练视角不够时，再拆专家

上一章练习参考答案

第一题，中断状态至少要保存 reviewId、tradeId、当前节点、已收集上下文、缺失字段、问题列表、用户身份和过期时间。

第二题，冲突时不要默默覆盖。应该进入人工确认，让用户选择或修正，并留下修正记录。

第三题，止损、止盈、方向、入场价这类风险字段缺失时必须中断；截图备注、K 线窗口缺失时可以降级复盘，但要说明上下文有限。

新问题：一个教练管太多视角

复盘越做越深，产品会想加更多视角：

“能不能让风险教练看仓位和 R 值？”

“能不能让心理教练看是不是情绪化追单？”

“能不能让数据教练看长期样本？”

如果所有视角都让一个 Agent 完成，它会变得很重：提示词很长，输出很散，调试困难。

所以第十三章引入多智能体专家组。

专家怎么拆

伴生工程的 experts 字段已经提前预留：

{
  "experts": ["PA 教练", "风险教练", "心理执行教练", "数据教练"]
}

你可以这样拆职责：

• PA 教练：看结构、突破、回踩、入场上下文。
• 风险教练：看止损、止盈、R 值、风险计划。
• 心理执行教练：看计划和实际动作是否一致。
• 数据教练：看长期样本里的重复问题。

每个专家只回答自己负责的部分。最后由主教练汇总成一份报告。

不要把多智能体做成多人闲聊

多智能体不是让几个模型互相聊天凑热闹。

工程上要限制它们：

• 输入一致：都看同一份交易事实。
• 输出结构固定：每个专家返回问题、证据、建议。
• 角色边界清楚：风险教练不评价行情方向。
• 汇总节点可控：最后报告不能把专家意见随意扩写成实盘建议。

本章和伴生工程的关系

现在伴生工程没有真的启动多个模型，但响应里已经体现专家组结构。你可以先把专家意见用代码生成，等接入 Spring AI Alibaba 时，再把每个专家替换成独立 Agent。

一个专家输出可以设计成：

public record ExpertFinding(
        String expert,
        String problem,
        List<String> evidence,
        String trainingAdvice
) {
}

这样后续不管专家来自本地代码、LLM、规则引擎，主流程都能统一处理。

这一章真正解决了什么

多智能体解决的是“复杂复盘视角拆分”。

只有当一个教练已经承担太多职责时，才需要拆专家。不要为了概念而拆。

练习题

1. 哪些复盘请求不需要多智能体？
2. 专家意见冲突时，主教练应该怎么处理？
3. 风险教练是否可以给出“下次仓位加大一点”的建议？