1. 从会辩论的 AI这个标题说起它到底在解决什么问题第一次看到他给 A 股装了个会辩论的 AI这个标题我脑子里冒出来的第一个念头不是酷而是这人肯定被单一模型的胡说八道坑过。做过金融数据分析的人都知道A 股这个市场有个特别折磨人的特点同一份财报、同一条政策消息、同一个技术形态看多和看空的逻辑都能自圆其说。你问一个模型这只票能不能买它给你一段四平八稳的分析最后来一句投资有风险等于什么都没说。所以会辩论这三个字才是整个项目的灵魂。它不是让 AI 更聪明而是让 AI互相拆台。一个扮演多头一个扮演空头第三个当裁判把两边的论点摆到台面上对撞最后输出一个带分歧标注的结论。这套思路在业内叫Multi-Agent Debate多智能体辩论本质上是把单模型一次性推理换成多模型多轮对抗推理用对抗来逼出模型自己都没想到的盲区。这篇文章我想聊的不是怎么让 AI 预测涨跌——那是玄学谁信谁交学费。我想聊的是这套辩论式 Agent 系统的工程实现逻辑为什么单 Agent 不够用、辩论框架怎么搭、A 股数据怎么喂进去、MCP 和 CLI 这些工具链在中间扮演什么角色、以及我在复现类似系统时踩过的那些坑。适合有一定 Python 基础、对 Agent 开发感兴趣、或者想给自己的量化/投研流程加一层AI 交叉验证的读者。哪怕你完全不懂股票这套多智能体对抗的思路也能直接搬到法律、医疗、专利检索这些同样没有标准答案的领域。先说结论这套系统的价值不在于给出买卖信号而在于把决策依据结构化地摊开。它逼着你去看多空双方各自的证据链而不是接受一个黑箱结论。这一点比预测准确率重要得多。2. 为什么单个大模型在 A 股场景下必然翻车2.1 单模型推理的三个致命缺陷我拿真实场景给你演示一下。假设你直接问某个大模型结合最新财报分析一下某新能源龙头当前的投资价值。你会得到什么大概率是一段结构工整、语气客观、但信息密度极低的文字。它会把营收、毛利率、行业景气度都提一遍然后给出中长期看好短期注意波动这种万能答案。问题出在三个地方。第一是立场坍缩模型被训练成平衡、中立、不偏激所以它天然倾向于和稀泥不敢给出尖锐判断。第二是证据不可追溯它说的行业景气度回升到底来自哪份数据你不知道它也不会告诉你。第三是自我一致性陷阱模型一旦在开头定了调后面所有推理都会往这个调子上靠这叫anchoring bias锚定偏差人有的毛病它一样不少。2.2 辩论机制如何从结构上破解这些缺陷多智能体辩论的核心设计就是强制制造立场对立。系统里至少有三个角色角色职责关键约束多头 Agent只找看多证据构建买入逻辑必须引用具体数据源空头 Agent只找看空证据构建风险逻辑必须指出多头逻辑的漏洞裁判 Agent汇总双方论点标注分歧点不站队只做结构化归纳关键在于角色约束是硬编码进 System Prompt 的。多头 Agent 的提示词里明确写着你的任务是论证该标的的上涨逻辑禁止输出风险提示空头则反过来。这样一来模型没法再和稀泥它被逼着往一个方向深挖。然后进入多轮辩论。第一轮多头陈述空头反驳第二轮多头针对空头的反驳再回应空头继续攻击。通常跑 2 到 3 轮就够了再多会陷入循环。裁判在最后一轮介入输出一份多空论点对照表 核心分歧点 待验证信息。我实测下来辩论机制最大的收益不是结论更准而是暴露了单模型会忽略的风险点。比如某次分析中多头强调产能扩张带来增长空头直接指出扩张对应的资本开支会侵蚀自由现金流且行业已进入产能过剩周期——这个反驳角度单模型十有八九不会主动提。2.3 一个反直觉的经验辩论轮数不是越多越好新手容易犯的错是既然辩论有用那就多辩几轮。我试过跑到 5 轮结果两个 Agent 开始互相复读论点在第一轮就基本穷尽了后面全是换着说法重复。更糟的是轮数一多模型容易叛变——多头 Agent 被空头说服开始输出看空观点整个对抗结构就崩了。我的经验值是2 到 3 轮且每轮必须给 Agent 注入新信息比如第二轮补充一份研报摘要或资金流向数据否则就是空转。这个细节官方文档里不会写但实际跑起来差别巨大。3. 辩论式 Agent 的骨架角色、协议与裁判机制3.1 角色设计不只是多和空两个很多人以为辩论系统就是两个 Agent 对喷其实真正好用的框架至少需要四类角色。除了前面说的多头、空头、裁判我还加了一个数据核查 Agent。它的职责是在辩论过程中对双方引用的数据做真实性校验——比如多头说北向资金连续三周净流入核查 Agent 就去调数据接口验证如果对不上直接标记为存疑论据。这个设计来自一个惨痛教训。早期版本里模型会编造数据而且编得特别像真的什么某季度毛利率环比提升 2.3 个百分点你根本分不清是它算的还是它编的。加了核查 Agent 之后所有论据必须带数据来源核查不通过的直接从辩论中剔除。这一层是整个系统可信度的地基。3.2 辩论协议怎么让 Agent 有序对撞Agent 之间不能乱说话得有协议。我用的是结构化消息格式每条发言必须包含四个字段{ role: bull, round: 2, claim: 该标的当前估值处于历史 30% 分位具备安全边际, evidence: [数据源某估值数据库PE-TTM 历史分位, 计算口径近五年滚动], rebuttal_to: bear_round1_point2 }这个格式的好处是可追溯、可解析、可复现。裁判 Agent 拿到的是结构化的论点列表而不是一堆自然语言归纳起来准确率高得多。而且rebuttal_to字段强制空头必须针对多头的具体论点反驳不能自说自话。提示字段设计里evidence一定要强制要求哪怕模型编也要让它编出来源。因为一旦要求标注来源模型编造的概率会显著下降这是被反复验证过的行为特性。3.3 裁判机制如何避免裁判自己站队裁判 Agent 是最容易出问题的角色。我最初的版本里裁判经常在总结时偷偷加入自己的判断比如综合来看多头逻辑更具说服力——这就破坏了中立性。解决办法是给裁判的输出做模板约束。裁判不允许输出任何倾向性结论只能填一张固定表格维度多头论点空头论点分歧性质估值处于历史低位行业增速下滑低估值是陷阱事实分歧资金面北向持续流入流入集中在少数权重股口径分歧最后再输出一个待验证清单列出双方都无法证伪的关键假设。把判断权交还给人类这才是辩论系统该有的姿态。它不替你做决定它帮你把决策所需的信息整理清楚。4. 把 A 股数据接进来MCP 与 CLI 工具链的实战选型4.1 为什么用 MCP 而不是硬编码数据接口早期我是直接在代码里写死数据接口调用的requests.get(...)一把梭。问题是每加一个数据源就要改一次代码而且 Agent 完全不知道有哪些数据可用。后来换成MCPModel Context Protocol架构思路就顺了。MCP 的本质是把数据源和工具封装成标准化的 ServerAgent 通过协议去发现和调用。比如我封装了一个行情数据 MCP Server暴露get_price、get_financials、get_fund_flow几个工具。Agent 在辩论时如果需要资金流向数据它会自己去查这个 Server 有没有对应工具有就调用没有就换论据。这种动态发现能力是硬编码给不了的。配置上MCP Server 通常在一个配置文件里声明{ mcpServers: { astock-data: { command: python, args: [-m, astock_mcp_server], env: { DATA_API_KEY: your_key_here } } } }Agent 框架启动时会自动加载这些 Server把它们的工具注册进可用工具列表。这一步是整个系统活起来的关键——Agent 从只会聊天变成能动手查数据。4.2 CLI 工具在自动化流程里的位置辩论系统跑一次要调用几十次模型、查十几次数据手动触发不现实。这时候CLI 工具就派上用场了。我用 CLI 把整个流程包成一条命令debate-agent analyze --symbol 600XXX --rounds 3 --output report.mdCLI 的好处是可脚本化、可定时、可批量。我设了个定时任务每天收盘后自动跑一遍自选股列表生成辩论报告。第二天早上打开文件夹十几份多空对照表已经躺在那儿了。选型上我对比过几个方案。纯 Python 脚本最灵活但不好复用用现成的 Agent 框架比如带 CLI 的那些上手快但定制性差。最后我的选择是自己写一层薄薄的 CLI 封装底层调 Agent 框架的 API。这样既保留了框架的能力又能按自己的需求定制命令和输出格式。注意CLI 工具安装时经常遇到运行时依赖问题尤其是跨平台场景。我的建议是用虚拟环境隔离把 CLI 和它的依赖锁在一个 venv 里避免污染全局环境。这个坑我踩过不止一次。4.3 数据质量比模型选型更重要的事说句可能得罪人的话在 A 股 Agent 项目里数据质量的重要性远超模型选型。你用一个二流模型配一流数据出来的结论比一流模型配垃圾数据靠谱得多。我遇到过的数据坑包括财报数据口径不一致有的用合并报表有的用母公司报表、停牌期间数据缺失导致指标计算错误、除权除息没复权导致技术指标全乱。这些问题的解决方案不是靠模型智能修正而是在数据接入层做严格校验。我的做法是给每个数据字段加一个可信度标记核查 Agent 引用数据时会看这个标记低可信度的数据直接降权。5. 复现这套系统时我在哪些地方栽了跟头5.1 提示词里的角色漂移问题前面提到多头 Agent 会叛变这个现象比我想的严重。跑长对话时模型会逐渐忘记自己的角色设定尤其是当空头的论据特别有力时多头 Agent 会开始客观起来输出虽然看多但也要注意风险这种话。根因是上下文窗口里的角色信息被稀释了。对话越长开头的 System Prompt 权重越低。我的解法是每轮都重新注入角色约束不是只在开头说一次。具体做法是在每轮的用户消息里把角色定义再贴一遍虽然费 token但角色稳定性提升非常明显。另一个技巧是给角色加情绪。纯理性的角色容易被说服但如果你在提示词里写你是一位坚定看好该标的的资深多头你的职责是捍卫你的判断模型的立场会稳得多。这听起来有点玄学但实测有效。5.2 辩论陷入循环论证的排查过程有段时间我发现辩论报告质量突然下降两个 Agent 翻来覆去就那几个论点。排查了半天最后定位到数据接口返回了缓存数据——连续几天拿到的是同一份行情快照Agent 自然辩不出新东西。这个坑的排查链路是这样的先看报告发现论点重复 → 怀疑模型问题换模型测试没改善 → 检查输入数据发现数据时间戳异常 → 追到数据接口层发现缓存没失效 → 修复缓存策略。教训是Agent 系统出问题先查数据再查提示词最后才怀疑模型。这个排查顺序能帮你省下大量时间。很多人一上来就调提示词、换模型其实问题根本不在那儿。5.3 成本控制辩论系统的 token 消耗是单模型的 5 到 8 倍这个必须提前说清楚。一次三 Agent、三轮辩论的分析token 消耗大概是单模型单次问答的 5 到 8 倍。如果你跑全市场几千只股票账单会非常难看。我的控制策略有三条。第一是分层触发先用一个便宜的模型做初筛只对值得深挖的标的启动完整辩论流程。第二是缓存复用同一份财报数据在辩论中被多次引用缓存起来避免重复计算。第三是精简上下文每轮只传必要的论点历史不传完整对话记录。实测下来这三条能把成本压到原来的三分之一左右。做 Agent 项目成本意识要刻在骨子里不然跑着跑着就烧不起了。6. 从 A 股辩论延伸出去这套框架还能用在哪6.1 专利检索与侵权分析的天然适配我后来把这套辩论框架搬到了专利分析场景效果出奇地好。专利侵权判断本质上就是权利要求书的解释之争——原告方主张某种解释被告方主张另一种解释最后靠审查员或法官裁决。这跟多空辩论的结构几乎一模一样。具体做法是一个 Agent 扮演专利权人尽可能宽地解释权利要求另一个扮演被控侵权方尽可能窄地解释裁判 Agent 汇总双方解释的差异点标注出如果按宽解释则侵权成立按窄解释则不成立的关键条款。这种输出对专利律师的价值远大于一个简单的是否侵权结论。6.2 医疗诊断的第二意见场景医疗领域同样适用。一个 Agent 基于症状和检查数据给出诊断假设另一个专门找鉴别诊断——也就是那些症状相似但治疗方案完全不同的疾病。裁判汇总后输出最可能的诊断 必须排除的鉴别诊断 建议补充的检查。这套逻辑的核心还是用对抗逼出盲区而不是追求单一答案。6.3 通用 Agent 开发的学习路径建议如果你看完想自己动手我给一条务实的学习路线。第一步先把单 Agent 跑通理解工具调用Function Calling和 MCP 的基本机制。第二步实现两个 Agent 的简单对话不追求质量先跑通流程。第三步加入结构化消息格式和裁判角色。第四步接入真实数据源处理数据质量问题。第五步做 CLI 封装和成本优化。别一上来就追求完美框架。我见过太多人卡在选型阶段纠结用哪个 Agent 框架、哪个模型结果一行代码没写。先用最土的办法跑通再逐步优化这是我一贯的建议。7. 一些不写在文档里的实操心得聊几个零碎但特别有用的点。关于模型选择辩论系统里多头和空头可以用同一个模型但裁判最好换一个模型。同源模型容易有相同的偏见换个模型当裁判归纳出来的分歧点更客观。我一般用两个不同厂商的模型搭配。关于输出格式辩论报告一定要输出成 Markdown 或结构化 JSON别输出纯文本。因为你需要二次处理——比如把分歧点提取出来做提醒把待验证清单同步到自己的研究笔记里。格式化的输出让自动化成为可能。关于验证任何 Agent 给出的数据都要有独立的验证通道。我专门写了个小脚本把报告里所有引用的数字抽出来跟原始数据源对一遍。信任但要验证这句话在 Agent 系统里尤其重要。关于迭代这套系统我改了不下二十版。每一版都是发现一个问题、修一个问题。别指望一次设计到位Agent 系统的复杂度决定了它必须边跑边调。我的建议是先把日志打全每次辩论的完整消息流都存下来出问题时有据可查。最后分享一个我最近才想明白的点辩论系统的终极价值不是替代人做决策而是训练人的决策能力。你天天看多空双方怎么交锋慢慢自己就学会了从两个角度看问题。这个副产品可能比系统本身的输出更有价值。我现在看一份研报脑子里会自动跑一遍如果我是空头会怎么反驳这个思维习惯就是被这套系统逼出来的。