这个项目本质上干了一件事把A股个股分析从“问AI要一个结论”改成了“让AI做一场多空辩论再出裁决报告”。这套系统跑起来之后身边几个做投研的朋友都跑来问我要思路原因很简单——市面上能直接生成“看多/看空/中性”结论的AI工具不少但几乎没有能解释清楚这个结论到底是怎么推出来的。而这个系统会把每次判断拆成一份完整的辩论记录多空双方的论据、引用、反驳过程全部可见谁看了都能顺着逻辑再查一遍。为什么说它有价值因为A股的分析场景天然适合辩论。一只股票背后永远存在两种叙事有人看到增长有人看到风险传统AI的毛病是两头都想要、两头都说不透。给AI装上一个“必须互相对抗”的辩论机制反而逼着它把每一面都说到极致最后再由第三方做裁决。这个过程本质上不是让AI更聪明而是让它的结论更有可追溯性适合任何一个需要做研究对象复盘的投资者、分析师或AI开发者参考。1. 为什么A股需要“会辩论”的AI1.1 传统AI分析股票的死穴在哪先说个大模型直接分析个股时会犯的通病立场骑墙。你问一个没有角色的模型“XX股票能不能买”它会非常礼貌地给出三面结论——正面有亮点负面有风险最后建议你谨慎决策等于什么都没说。这不是模型不聪明而是任务目标本身没有约束。更麻烦的是大模型存在很强的顺杆爬倾向如果你的提问方式里带有乐观倾向它输出的结论也会莫名乐观如果换成悲观问法结论又会变保守。这在单次基本面研究里不是致命伤但放到投资决策链条里就是明显的不可靠信号。A股还有一层特殊性市场对信息的反应路径非常复杂。财报数字是硬约束但真正的股价驱动往往来自预期差、资金流向和情绪面。传统AI直接把新闻标题丢进模型里很容易被短期噪音带偏而如果将多方和空方分开建模再强制双方围绕同一份数据反复交锋就不容易被某一类叙事带节奏。更直白地说没有对抗机制的单模型输出本质上是模型在替你脑补逻辑而不是在验证逻辑。1.2 辩论机制到底解决什么问题我参考了学术界multi-agent debate的做法把它从论文场景搬到了A股投研场景。多轮辩论的本质是让两个目标函数不同的Agent互相攻击迫使每一方都必须回到事实层面来证明自己、推翻对方。这个机制带来的直接效果有四个。第一立场约束。多方只能从成长性、盈利质量、行业空间等角度构建论点空方只能从估值偏高、现金流恶化、竞争加剧等角度寻找破绽谁也不能骑墙。第二证据压力。在一次有效辩论里空方不会接受“公司很好”这种空话它会追问“净利润同比增长32%的数据出自哪份财报是否剔除了非经常性损益”多方必须给出具体来源才能站住脚。第三暴露盲区。绝大多数模型对“坏消息”不敏感因为训练语料里乐观表述占比更高。引入空方角色后系统会被强制挖掘利空因素把商誉减值、股东减持、应收账款激增这类问题全部摆上台面。第四可解释性。裁判最终给出的不是一句抽象结论而是一份带引用、带论证链条的裁决书拿着这份报告去做二次研究比对着大模型的一个分数靠谱得多。2. 整体架构与关键技术选型2.1 从单模型到多智能体协作整个系统可以拆成四个角色分别是多方Agent、空方Agent、裁判Agent以及一个负责拉取和检索数据的Context模块。多方和空方共享同一个知识库但检索与推理方向被刻意隔开目的就是避免双方带着同样的预设去翻资料。角色核心任务关键输出多方Agent从成长、盈利、趋势角度构建看多论证论点列表、证据引用、置信度空方Agent从估值、风险、现金流角度构建看空论证反论点、风险清单、证据引用裁判Agent综合双方辩论内容输出裁决结论方向判断、置信度、完整证据摘要Context模块检索财报、公告、行情、研报切片结构化上下文片段、引用ID这样的结构意味着单纯调用一个大模型的提示词工程只占一半另一半是数据如何在不同角色之间流动。我一开始犯过一个错误让多方和空方直接共享所有检索结果结果两边引用完全相同的段落辩论变成了复读机。后来把检索结果按“成长类指标”和“风险类指标”先做粗分再分别投喂给两方才真正形成信息差。2.2 技术栈与部署方案用的技术栈其实不花哨关键在于每个环节各司其职。基础框架是Python 3.11服务层用FastAPI对外提供HTTP接口工作流引擎用了LangGraph的思路管理Agent状态底层缓存用Redis。向量检索这块我试过Chroma和Milvus小规模验证阶段用Chroma就够了因为数据量不大Milvus更适合生产环境的数据规模。模型层我没有押注单一模型而是根据角色任务灵活调用。多方、空方建议用推理能力够用的国产开源模型裁判角色则用参数更大、指令遵循能力更强的模型因为裁决需要对双方论据做横向比较不是简单地打一个分。整个系统部署在一台带8GB显存的消费级显卡上就能跑一次完整辩论大约耗时20到50秒成本消耗取决于调用的模型单价实测平均每次辩论的token消耗在8千到1.5万之间。2.3 为什么选“辩论”而不是“投票”或“聚合”构建这套系统之前我认真考虑过另外两种方案多模型投票结果聚合以及多模型各自打分后取加权平均。这两者都有一个共同问题独立决策之间没有交互模型A说看多模型B说看空系统只能机械地数票无法解释为什么会出现分歧也无法判断哪个模型的理由更站得住脚。方案输出质量可解释性成本适用场景单模型直接输出低容易骑墙弱最低快速信息摘要多模型投票聚合中能消除随机误差弱中惯例判断多Agent辩论高强制对抗与证据校验强高深度投研辅助辩论方案把一个模糊的“判断问题”转化成了“论证问题”这是它最大的优势。裁判Agent不是在两个结论之间选边而是在两份论证过程之间做比较看谁的证据链更完整、谁的反驳更有效。这种输出来自对抗过程所以它天然比单模型输出的可复核性高一个量级。3. 核心功能拆解与实现细节3.1 多空双方的角色设定与提示词设计角色提示词是整个系统最重要的部分直接决定辩论质量。我给多方设定的系统提示词里会明确写你必须以成长型基本面分析师的视角出发专注于发现目标公司的增长潜力和竞争优势禁止表达模棱两可的观点必须引用财报、公告、宏观数据中的具体数字支撑论点。下面是一份可直接参考的多方提示词模板你是A股基本面研究中的多方分析师专注于识别上市公司被低估的证据。 你的任务 1. 从营收增速、净利润质量、现金流结构、行业空间等维度构建看多论证 2. 每个论点必须包含至少一个来自上下文中的具体数字或事实 3. 在回复对手方时指出对方逻辑中的漏洞或数据取舍问题 4. 严禁使用“需谨慎”“注意风险”等骑墙表述。 输出格式严格遵守 { stance: bullish, points: [ { claim: 核心观点, evidence: [证据原文片段], source: 财报/公告/新闻/研报, confidence: 0.0-1.0 } ] }空方提示词遵循同样的结构但视角完全相反要求它优先关注估值泡沫、营收质量下滑、股东减持、现金流恶化、行业竞争加剧等风险因素。裁判提示词则要求它先忽略双方阵营只根据证据质量给出裁决。这里有几个实操心得可以分享。第一必须强制结构化输出最好用JSON格式否则辩论到第二轮你会面对一大段无法解析的散文。第二每轮输出要限制token上限比如每个观点不超过100字否则模型会写小作文既浪费时间又难以提取核心信息。第三让双方记住自己“只能赢”可以大幅提升对抗强度。3.2 数据层怎么让AI“看懂”A股没有干净的数据辩论就是空中楼阁。我从数据源上分了四层财务报表数据、公告与研报、行情与资金数据、宏观与行业数据。财务报表主要抓营收、净利润、毛利率、经营性现金流、资产负债率等指标公告和研报需要解析PDF与文本内容行情数据包含历史价格、成交量和资金流向行业数据用来辅助判断景气度。处理流程上我先把PDF财报解析成结构化表格再转换成有利于向量检索的文本切片。这里最关键的坑是数值切片必须独立成段。如果像处理普通文章一样把一大段财报描述切成长文本块嵌入向量时数值信息会被稀释AI检索到的可能是“净利润同比增长”这个模糊概念而不是具体的32.6%。所以我专门抽取财务指标表把每个指标名称、数值、报告期组成一段独立文本再入库。检索时我会让Context模块先按股票代码拉取最新财报和最近三个月的公告再按“成长类关键词”和“风险类关键词”分别检索最后拼接成两份差异化上下文。分化后的数据一个是偏正面的素材包一个是偏负面的素材包多空双方拿到的原始素材不完全相同辩论才有真正的信息差。3.3 辩论流程引擎与裁决机制辩论流程用状态机来管理状态依次是等待多方首论、等待空方反驳、等待多方回应、判断是否收敛、进入裁决。我实测下来三轮交锋是质量与成本的平衡点。两轮辩论往往不够充分很多冲突点刚展开就被截断四轮以上边际收益很差且容易出现双方开始重复观点的情况。每一轮辩论记录都会存入上下文并带上一个回合编号方便裁判定位。裁决模块会从四个维度给分事实性即引用内容是否真实存在且与上下文一致逻辑强度即推导链条是否完整相关性即论点是否直指投资决策核心风险覆盖即空方是否系统性地识别了主要利空因素。最终的评审规则是综合分超过60且事实性得分不低于70才允许输出看多或看空判断否则一律降级为中性。这个规则救了我很多次因为模型偶尔会引用出错误数据如果不能通过事实性校验宁可输出没有观点也不能输出错误观点。3.4 与用户的交互方式交互层我做了两套入口。第一套是Web页面用户输入股票代码或公司名称点击就开始分析页面会实时展示辩论进展像看直播一样看到多方发言、空方反驳最后生成一份裁决报告。第二套是开放API对接外部系统一次POST请求传入股票代码返回结构化的辩论结果。裁决报告的结构分为五块核心结论、辩论时间线、事实证据链、风险提示、争议焦点。核心结论是一句话判断辩论时间线是双方交锋的完整记录事实证据链是报告引用的所有来源列表风险提示是空方识别出的主要风险争议焦点则是裁判认为双方分歧最深的关键问题。整体输出是可读性很强的Markdown文档方便二次转发或导入其他分析工具。4. 实操过程从0到1搭建一个A股辩论AI4.1 数据准备与特征工程写代码之前先花时间把数据清理干净。我以“某白酒龙头企业”作为测试标的说一说流程。先调用公开财经数据接口抓取最近五个报告期的财务摘要包括营业收入、净利润、扣非净利润、经营现金流、销售毛利率、应收账款周转天数等核心指标同时抓取近一个月的公司公告标题和摘要。以下是一段简化版的取数代码用akshare这类开源财经数据接口实现import akshare as ak def fetch_financials(symbol: str): # 获取主要财务指标实际字段名可能随接口版本变化 df ak.stock_financial_abstract(symbolsymbol) latest df.iloc[-1] return { revenue_yoy: latest.get(营业收入同比增长率), net_profit_yoy: latest.get(净利润同比增长率), gross_margin: latest.get(销售毛利率), ocf: latest.get(经营活动现金流量净额), roe: latest.get(净资产收益率), }特征工程这一步不需要做得太复杂关键是产出可供Agent引用的结构化指标。我会在每条数据后面加上报告期标签比如“2024年三季报”这样AI在辩论时能精确说出“根据2024年三季报数据净利润同比增速为15.2%”而不是含糊地说“最近业绩不错”。4.2 模型选型与调用模型选型上我遵循“角色分级”原则。多方和空方Agent使用推理能力中等、成本较低的模型因为它们只需要基于给定素材构建论点裁判Agent则使用更强的模型因为它要做归因分析和横向比较。实测下来同一个模型家族内裁判用大一号的参数版本最终裁决的稳定性会明显提升。调用层面的关键是缓存和重试。多空辩论是一次高延迟操作模型接口偶尔会超时所以每次调用都必须设置合理的超时时间和指数退避重试。同时我用Redis缓存最热门标的的辩论结果缓存时间为两小时避免同一只股票被反复分析导致资源浪费。4.3 辩论循环的实现核心的实现逻辑可以简化成一段伪代码用异步方式编排多轮辩论async def run_debate(symbol: str, rounds: int 3): # 1. 拉取并切分数据上下文 bull_data, bear_data retrieve_context(symbol) # 2. 多方首论 debate [] bull_open await bull_agent.declare(bull_data) debate.append(bull_open) # 3. 多轮交锋 for turn in range(rounds): bear_reply await bear_agent.rebuttal(debate, bear_data) bull_reply await bull_agent.respond(bear_reply, bull_data) debate.append(bear_reply) debate.append(bull_reply) # 4. 如果双方论点不再新增提前收敛 if not has_new_argument(debate[-2], debate[-1]): break # 5. 裁判裁决 verdict await judge_agent.decide(debate) return {debate: debate, verdict: verdict}这段代码看起来简单实际的坑在Agent状态管理。每个Agent内部必须保留自己的历史发言记录避免在回应对方时把自己前面的论点忘记了。另外生成回应的prompt里要把“你上一轮的发言”和“对方最新的发言”一起拼接否则第二轮开始就会出现各说各话的情况。4.4 结果输出与可视化辩论结束后我会把结论渲染成一份带编号的报告。报告正文包含五部分其中“争议焦点”部分最有用因为它是裁判从双方辩论中提取出的核心分歧点比如“市场争议的焦点在于高端产品提价能力是否可持续多方认为提价空间仍在空方认为增速已近天花板”。这种聚焦信息比单纯看多空结论更能引发深入思考。可视化方面每一轮辩论可以用时间线展示论点按发言顺序排列证据引用则用高亮链接指向具体数据来源。系统还会生成一个雷达图从事实性、逻辑强度、相关性、风险覆盖度四个维度画给读者看让人一眼看出这次判断是靠硬核数据支撑还是靠逻辑演绎支撑。5. 常见问题与排查技巧实录5.1 模型幻觉与事实性校验实际运行中遇到最多的就是模型幻觉。有一次空方Agent在辩论里言之凿凿地说“该企业2023年营收同比下降18%”但我核对上下文里的财报数字发现根本没有这个数完全是从训练语料里编出来的。这类错误对投研场景是致命的。解决的思路分三层。第一层是做引用ID强制对齐要求Agent在输出每个论点时必须附带引用来源的片段ID如果这个ID在上下文中不存在直接判定该论点无效。第二层是后处理数值校验用规则把所有与财务指标相关的数字提取出来跟结构化数据逐项比对不一致的自动打上存疑标签。第三层是建一个证据命中率指标统计每一轮辩论中被校验通过的论据占比用这个指标持续评估系统质量。5.2 辩论论点同质化第二个困扰是两边的论点越来越像尤其是在多轮辩论后期空方会引述多方提到的“营收增速”来反驳多方又会围绕同一指标辩解最后变成对同一个数字的口水战。原因是双方共享了太多基准数值自然会在同一指标上纠缠。我后来加入了指标分组机制不让他们完全共享同一个数据池多方优先引用成长性相关的指标比如营收增速、行业渗透率、在建产能空方优先引用风险相关的指标比如商誉占比、应收账款周转天数、质押比例。只有到最终裁决阶段裁判才会获取全部上下文。这个改动让多空双方真正形成了差异化论证。5.3 实时性与成本之间的平衡辩论机制的实时性天然偏慢因为一次完整分析可能要调用七八次大模型再加上检索耗时很难做到秒级响应。为了照顾体验我做了两个优化一是高频标的预计算把热度最高的几十只股票在开盘前就提前跑完用户访问时直接读缓存二是轻量模型初筛对明显缺乏数据支撑的提问直接返回提示不进入完整辩论流程。成本方面一次完整辩论在8千到1.5万token区间如果全部使用商用大模型接口每天跑几百个标的也是一笔不小的开销。所以我用开源模型部署了多方和空方Agent只在裁判环节调用更贵的商用模型实测总成本能压缩一半以上。核心思路很朴素能用小模型完成的高频动作绝不上大模型大模型只留给最关键的一次判断。5.4 合规与风险控制必须把风控放在所有设计前面。系统产出的所有报告都会在顶部强制标注“内容由AI生成仅供研究参考不构成任何投资建议”同时屏蔽所有涉及具体投资建议的指令例如“快买”“清仓”这类词语会被后处理过滤掉。个股预测类表达也被限制系统只输出“看多/看空/中性”的概率语义描述不输出目标价或精准收益预测。数据来源我也做了合规审查只使用公开可获取的财报、公告和新闻不抓取任何付费数据源的泄露内容。这套系统定位是投研辅助工具不是荐股软件所以在架构上就尽量不设置任何可能被解读为“荐股”的功能。保持边界清晰能省掉很多后续麻烦。我个人在实际操作中的体会是决定这套系统上限的不是模型智商而是数据加工和角色约束。所谓“会辩论的AI”底层逻辑其实很朴素让双方都极端一点再让裁判理性一点。如果你也想搭一套类似的东西建议先别急着接复杂的行情接口就选一只你熟悉的股票把财报数据整理成结构化文本两个Agent加一个裁判半天就能跑通第一版。等你觉得辩论的效果真的能帮你看清一个标的了再去堆数据源和优化成本也不迟。