4 Agent对辩金融分析:Minara Harness实测18分钟
发布时间:2026/9/13 3:08:01
分类:文化教育
浏览:1234

1. 为什么我把金融分析从裸 Agent搬到了 Minara Harness1.1 单 Agent 让我不放心的地方最近半年我一直在试各种 Agent 工作流尤其在金融分析这个方向上踩了不少坑。最开始的做法很简单把一份财报丢给一个大模型让它总结亮点和风险。结果呢它每次都能给出看起来很流畅的回答但细看就会发现两个问题一是立场偏斜模型默认会顺着用户问题的方向去找答案你问这家公司值不值得关注它就自动过滤掉对自己结论不利的信息二是覆盖不完整只要用户没有明确提问的维度它几乎不会主动去查。最让我受不了的是第三点单 Agent 完全意识不到自己不知道什么。它给出的风险清单看似列了七八条但如果你拿另一家公司的财报或者行业数据去交叉验证会发现它漏掉的信息远比它列出来的多。金融分析里未提及风险和风险不存在是两码事单 Agent 天然无法区分这两者。后来我改用过多个 Agent 并行调用、各写各的报告再合并又发现一个新的问题大家各说各话谁也不会去质疑别人的结论合并出来的东西只是多份独白的拼接根本没有真正的观点碰撞。1.2 Harness 和 Agent 到底差在哪有些朋友会问Agent 不就是大模型加工具调用吗为什么非要引入一个 Minara Harness 这样的编排层我的理解是Agent 是那个会思考、会决策的员工Harness 则是整个公司的后勤和行政体系。员工再厉害也得有人管工位、发权限、记账、做会议纪要、监督流程合规。你当然可以不用 Harness直接写脚本一次次调模型 API任务简单时没有任何问题但一旦任务变成多个 Agent 分工协作、每一步要可审计、中间要调用十几个外部工具时裸脚本就会变成一坨理不清的意大利面。Minara Harness 这类工具解决的就是这三件事编排、权限、可观测。它把工作流定义成配置文件每个 Agent 挂哪些工具、能访问哪些数据源、发言顺序和轮次怎么走全部显式声明。同时它会在每次运行中记录完整的 Trace谁在什么时间调了什么工具、读到了什么数据、生成了什么结论全部可回溯。这一点对金融场景是刚需——你不能让一个 Agent 在黑盒里跑 18 分钟最后丢给你一个结论却说不清这个结论是怎么来的。1.3 金融场景对 Harness 的硬性要求我接触到 Minara Harness是看到它在多 Agent 辩论场景下的支持做得比较顺手。金融分析的特殊性在于任何结论都需要同时满足三个条件数据可验证、逻辑可辩驳、表述不越界。于是我对 Harness 的要求也变成了三条。第一步权限必须受限。Agent 只能通过只读 API 拿行情和财报数据绝不允许写文件、发邮件、下订单。第二步过程必须全程留痕。整场辩论结束后我要能追溯到每个 Agent 引用的数据源编号而不是只看最后的纪要。第三步运行必须可中断、可恢复。这类任务动辄跑十几分钟中途如果模型调用超时或者工具报错不能整个流程归零重来。Minara Harness 的 0.6.x 版本在这三块做得比较齐全至少在我实测的范围内没有掉链子。2. 4 个 Agent 的分工设计多方、空方、审计与合规的质询闭环2.1 四个角色的定位与提示词骨架设计多 Agent 对辩最忌讳的就是角色同质化。如果四个 Agent 换汤不换药只是名字不同辩论会迅速沦为互相客套。我在这个实测里给四个 Agent 定了完全不同的职责而且每个角色都只对特定类型的信息过敏。第一个是多方分析师。它的任务不是唱多而是把所有支持公司基本面向好的证据全部摆出来包括营收增长、毛利率改善、现金流增强、行业需求上行。第二个是空方分析师职责正好相反专门找数据里的裂缝应收账款异常、存货周转放缓、经营性现金流与净利润长期背离、增长是否依赖一次性并表。第三个是审计 Agent它不站任何一边只做一件事反复交叉验证前两个 Agent 引用的数据看有没有算错口径、用错报告期、把同比说成环比。第四个是合规编辑盯的是表达层面的问题有没有夸大、有没有漏掉重要上下文、有没有出现肯定上涨可以买入这类越界表述。提示词模板我放在了工作流配置里核心逻辑是这样的agents: bull: name: 多方分析师 mission: 找出所有支持基本面改善的证据但必须给出来源编号 constraints: - 不得提出买卖建议 - 不得忽略空方已指出的数据矛盾 bear: name: 空方分析师 mission: 找出多方论述中的逻辑漏洞、数据矛盾和潜在风险 constraints: - 至少提出一个可被审计Agent验证的反向证据 - 不允许使用模糊表述须引用具体报告期 auditor: name: 财务审计 mission: 交叉验证多方与空方引用的核心财务数据判定口径是否一致 tools: [report_parser, calc_sandbox] compliance: name: 合规编辑 mission: 检查最终论述是否包含误导性表达、是否遗漏不确定性说明 rules: - 若置信度低于阈值必须输出高不确定性标记2.2 为什么是 4 个不是 3 个也不是 6 个说实话最早我也纠结过到底放几个 Agent。后来做了几个小规模实验还是回到了 4 个。用 3 个 Agent 有一个很难受的问题容易出现 2 比 1 的抱团。比如多方和空方如果都倾向乐观审计 Agent 提出质疑时会被两边压下去辩论最后变成少数服从多数而这在逻辑上是完全不成立的——正确与否和人数多少没有任何关系。6 个 Agent 倒是能分散立场但每一轮辩论的耗时会明显拉长。我实测过 6 Agent 配置单轮就要 8 到 10 分钟三轮下来 30 分钟打底Token 成本接近翻倍可新增的有效信息却没有跟着翻倍。4 个 Agent 刚好卡在一个平衡点上两个对立立场各占一席再加一个中立的事实核查者和一个中立的表达审查者。后两个角色不站队只盯数据对不对和表述稳不稳这样即便多方和空方吵得不可开交最后也会被拉回到事实和边界上来。2.3 辩论轮次与结束条件流程上我设置了 3 轮对辩。第一轮是各自陈述多方先讲空方后讲审计和合规在第一轮主要做记录和初步核查。第二轮开始进入真正的对辩环节每个 Agent 都要针对前一轮其他 Agent 的发言提出至少一个反驳点或补充证据不允许只说我同意。第三轮则是收敛各方需要回应前两轮遗留的矛盾点最终由审计 Agent 汇总出一份带有置信度标记的结论。为了让流程不至于无限制跑下去我还在工作流里加了两个结束条件一个是硬性的时间上限配置里写了max_minutes: 20超过就强制进入汇总阶段另一个是软性的信息增益判断如果某一轮结束后新产生的可验证信息增量低于阈值系统会提前终止辩论。第一次完整跑下来总耗时 18 分 07 秒正好卡在了标题里那个18 分钟附近。3. 实测全流程配置、跑批与一次 18 分钟的对辩现场3.1 数据源与工具接入清单在跑真实案例之前我先花了大半天时间把数据源接好。这次我选的测试标的是一个消费电子行业的公司为了方便描述下面统一叫它 A 公司。选取原因很简单它的财报里有几处数据口径变化正好可以用来检验审计 Agent 的交叉验证能力。我接入的数据源和工具一共四类。第一类是财报解析器用来读取 PDF 格式的年报和季报把利润表、资产负债表、现金流量表转成结构化数据。第二类是新闻检索接口用来拉取近期公司公告和行业新闻按时间倒序排列并自动标注来源。第三类是行情与财务数据 API我只开通了只读权限用来拉取股价走势、市盈率、同行业公司对比数据。第四类是计算沙箱审计 Agent 可以在里面重新算一遍它怀疑的财务指标比如应收账款周转天数、经营性现金流与净利润的比值。tools: report_parser: type: document source: local_pdf://reports access: read news_search: type: api auth: env.NEWS_API_KEY access: read market_data: type: api auth: env.MARKET_API_KEY access: read calc_sandbox: type: sandbox access: read_write_temp这里要特别注意权限配置。计算沙箱我给的是临时目录可读写系统目录只读后面在踩坑部分会细说如果权限给得太宽Agent 真的会干出匪夷所思的事情。3.2 工作流配置核心片段Minara Harness 的工作流是用 YAML 声明的整体结构分三层agents 定义角色debate 定义辩论规则output 定义最终产出的格式。除了上面展示的 agents 配置debate 部分我这样写的debate: rounds: 3 order: [bull, bear, auditor, compliance] max_minutes: 20 min_information_gain: 0.12 rules: - 每轮每个Agent必须至少引用一个数据来源 - 第二轮起必须针对前一发言人的至少一个论点提出质疑或补充 output: format: markdown sections: [核心结论, 矛盾点清单, 未决问题, 置信度]运行命令也很简单一条命令就能启动整个工作流minara run --workflow fin_debate_v1 --input ./reports/A公司-2024年度报告.pdf第一次跑的时候我没有着急看结果而是盯着 Trace 界面看每个 Agent 的实时活动。实话说前两分钟是比较枯燥的多方和空方都在各自读财报和新闻。真正的火花出现在第一轮发言结束后。3.3 对辩过程实录A 公司财报引发的三次交锋整个对辩过程最有价值的是三个来回的交锋。第一轮交锋发生在多方和空方之间。多方先抛出几个亮点营收同比增长 18%、毛利率提升 2.3 个百分点、新业务收入占比首次超过 15%。空方随即提出反驳指出营收增长的背后是应收账款同比增长了 27%明显快于营收增速这通常意味着收入质量在下降可能通过放宽信用政策换来了账面增长。到这里如果只有两个 Agent这场辩论多半会停在各说各有理的僵局。但审计 Agent 介入了。它调用财报解析器和计算沙箱把最近八个季度的数据重算了一遍发现应收账款激增主要是收购并表带来的口径变化剔除这一影响后应收增速只有 9.2%跟营收增速基本匹配。这个结论直接推翻了一半的空方论点也让空方在第二轮不得不寻找新的质疑方向。第二次交锋发生在审计 Agent 和多方之间。审计 Agent 在复核时发现多方的毛利率提升主要是靠产品结构变化但低毛利业务在下半年已经连续两个季度环比下滑所谓结构优化可能已经被市场提前消化。多方针对这点补了一个证据新品出货量爬坡周期通常在两个季度左右下半年数据不足以说明趋势结束。两边的论点都有数据支撑最终被标记为未决问题需跟踪下季度出货量。第三次交锋最让我意外是合规编辑主动发起的。它指出空方在论述债务结构时只提到了短期借款占比下降却漏掉了可转债即将到期的信息这会让读者误以为公司完全没有短期偿债压力。这种漏说关键上下文的问题单 Agent 极难发现因为它根本不会站在读者会怎么理解这句话的角度去审查。合规编辑这一轮的价值我认为甚至超过了前面两轮的数据交锋。4. 18 分钟的时间账本耗时、Token 与成本实测拆解4.1 一次完整跑批的耗时分解很多人看到4 Agent 对辩 18 分钟第一反应是怎么这么慢我最初也有同样的疑问但拆开时间账本之后就理解了。下面是一次完整跑批的实测数据阶段耗时说明启动与模型预热0 分 40 秒加载工作流、检查工具权限、模型首轮调用预热第一轮独立陈述6 分 12 秒四个 Agent 各自读财报、搜新闻、写陈述第二轮交叉质询5 分 04 秒每个 Agent 须反驳前人审计大量调用计算沙箱第三轮收敛辩驳4 分 38 秒遗留矛盾点逐一回应接近信息增益阈值汇总与结构化1 分 33 秒生成最终纪要、矛盾点清单、置信度标记总耗时 18 分 07 秒其中启动与汇总这类固定开销只有 2 分多钟剩下的 16 分钟全部花在了真正的推理和工具调用上。审计 Agent 是四者中最慢的因为它每次发言基本都会触发至少一次数据复核合规 Agent 则是最快的它主要做文本级别的检查不需要频繁调外部接口。4.2 Token 到底烧在了哪一次完整跑批的 Token 消耗量让我有些意外总计约 41.6 万 Token。拆开看输入 Token 占了 33.1 万输出只有 8.5 万。输入 Token 为什么这么高核心原因是多轮辩论的上下文累积。到了第三轮每个 Agent 在发言之前都需要把前面所有人的观点带进上下文A 的发言要带上 B 和 C 的B 的发言又要带上 A、C 和 D 的。这还只是 4 个 Agent 的情况如果加到 6 个输入 Token 会呈指数级膨胀。工具调用带回来的内容也占了很大比例。新闻检索一次返回的正文往往有两三千字财报解析器提取的三张报表全文更是动辄上万字这些都要经过模型处理。我在 Trace 里数了一下整场跑批一共发起了 60 次工具调用其中新闻检索 24 次、财报解析 12 次、行情数据 18 次、计算沙箱执行 6 次。4.3 费用与性价比评估费用这块按我当时用的模型组合折算整场跑批大约烧掉 2.8 美元折合人民币大概 20 元出头。这个成本在日常研究辅助的场景下是可以接受的毕竟我人工读一份财报加搜半天资料的隐形成本远不止这个数。但有一点必须提醒如果你把轮次从 3 轮加到 5 轮成本不是线性增长而是接近翻倍因为后续每一轮都要把前面所有轮次的内容带进上下文。我实测过一轮加赛总 Token 直接从 41 万冲到了 78 万输出没有等比例变好。从第三轮开始新增信息的边际产出就明显递减了第三轮的新增有效信息量只有第二轮的大约 38%。这也是我在配置里保留min_information_gain这个软阈值的原因——它能在信息增益跌穿阈值时主动喊停帮你省掉最后那一段为了跑流程而跑流程的钱。5. 实测中踩过的四个坑以及对应的处理办法5.1 对辩空转互相客套不产生新信息第一次跑对辩工作流时我最担心的事情还是发生了几个 Agent 在第二轮开始互相客套。典型输出是这样的我基本同意空方对现金流的看法补充一点公司整体负债率仍然可控。这种话没有任何信息增量既不反驳也不提供新证据更可怕的是它看起来还像模像样。排查链路是这样的我先打开 Trace发现这几个礼貌型发言的 Agent 在发言前根本没有调用任何工具。没有工具调用就意味着它们没有引入任何新的外部信息全靠上下文里的旧数据在原地打转。定位到根因之后我在提示词里加了一条硬性规则第二轮起每个 Agent 必须针对上一个发言人的至少一个具体论点提出质疑或补充并且必须引用一个新的数据来源。同时又设置了信息增益阈值低于 0.12 就提前终止。改了之后空转现象基本消失因为它们不调工具就交不出作业。5.2 工具权限过宽Agent 差点写文件系统这个坑是我完全没有预料到的。第四次测试时我注意到计算沙箱的运行日志里出现了一条可疑记录审计 Agent 尝试在运行目录下创建一个笔记文件想把它自己复核后的中间结果写进去。听起来好像无伤大雅但问题在于如果它能写文件将来是不是也能读用户目录下的敏感文件工具权限一旦失控多 Agent 系统的行为就不可预测了。我的处理方案很直接把工具权限按最小可用原则重新收紧。财报解析器和新闻检索全部设成只读计算沙箱限制为临时目录可写、系统目录只读并关闭了其他 Agent 对文件系统的默认访问。权限收紧之后我又加了一道运行时监控规则只要发现 Agent 尝试访问白名单之外的路径立即终止该次工具调用并在 Trace 里标记告警。这个改动可能会让某些正常操作多一道审批但金融场景下可控性永远比便利性重要。5.3 上下文失控越辩越长直到塞满窗口第三个坑发生在第五次测试我把辩论轮次临时调到了 5 轮想要看看信息的边际产出到底在哪衰减。结果跑到第四轮模型调用直接报错原因是上下文超过了模型窗口上限。我把 Trace 调出来一看第三轮结束时上下文里塞了大约 18 万 Token其中大部分是前面几轮的全量发言记录和工具返回原文。这个问题的根源在于默认配置会把每一轮所有人的完整发言都保留在上下文中而工具返回的原始数据也被原样塞了进去。解决办法是开启动态的纪要压缩机制每一轮结束后系统先把本轮的核心论点、引用数据、矛盾点提取成结构化纪要然后用纪要替换掉原始发言放回上下文中。原始内容并没有丢而是被归档到 Trace 里后续如果需要追溯某句话的原文可以通过引用编号调出来。这一步做完5 轮跑下来上下文也稳稳控制在 12 万 Token 以内。5.4 越界输出想替用户做投资决定最需要警惕的坑出现在结果输出环节。有一次测试结束后我检查生成的最终纪要发现里面出现了当前估值具备吸引力可以考虑分批买入这样的句子。这个表达太危险了它不仅把概率性的分析结论说成了确定性的操作建议而且完全没有给读者留出独立判断的空间。我没有简单地把这句话删掉就完事而是从两个方向做了修正。第一是合规编辑角色的规则升级输出中凡是出现买入卖出目标价等操作类词汇一律标记为越界行为并且必须用不构成投资建议的免责声明包裹。第二是在输出模板中强制加入置信度和不确定性说明两个字段如果某个判断的数据支持不充分置信度不能超过 60%同时要求说明主要的不确定因素。这套机制上线之后再没有出现过替用户做决定式的表达。原因倒不是模型变聪明了而是它在生成时就被要求先过一遍合规判断越界内容会直接被拦截。6. 4 Agent 对辩在金融场景的价值边界与后续扩展6.1 它到底适合什么、不适合什么跑了小半个月我越来越清楚这套东西能干什么、不能干什么。先说结论非常适合做单标的的多视角研究初筛不适合做实时交易信号或者完整尽调。适合的场景我总结了三个一是快速熟悉一家公司4 个 Agent 对辩能在一轮跑批里把营收质量、债务结构、增长可持续性、舆论风险这几个核心维度全都过一遍省掉大半人工读材料的时间二是矛盾点挖掘单 Agent 通常会给一个平滑的结论而对辩架构会强制暴露出数据之间的矛盾和未决问题这对后续深入研究特别有价值三是报告底稿生成让合规编辑把口径和免责声明处理好出来的内容可以直接作为研究笔记的初稿。不适合的场景也很明确如果需要一个买入还是卖出的明确信号这套系统给不了也不应该由它来给。它所有输出都停留在可验证信息层面不包含对市场情绪、流动性、交易时机的判断。把它当作决策辅助工具可以把它当作决策本身那是在给自己挖坑。6.2 和单 Agent 快速扫描搭配的使用节奏实际操作中我没有让 4 Agent 对辩承担所有任务而是把它放进了一个更完整的工作流里。每天先用单 Agent 快速扫一批公司每家的分析控制在两三分钟目的是筛出那些信息互相矛盾、需要进一步深挖的标的。然后只对筛出来的两三家跑 4 Agent 对辩用 18 分钟换一份带矛盾点清单的深度纪要。这样搭配下来效率是最高的。单 Agent 负责广度覆盖多 Agent 负责深度验证各干各擅长的事。盲目给所有公司都对辩一轮时间和成本都吃不消只靠单 Agent 快速扫一家就下判断又会漏掉太多对立证据。这两种模式结合才是这套系统真正的正确用法。6.3 后续可以继续做的事目前的版本还只是一个相对基础的对辩工作流后续我想做三件事。第一是把每轮对辩产出的结构化纪要存进向量库让历史结论变成记忆下次跑批时可以直接引用过去已经验证过的数据不用每次从零开始。第二是引入外部权威数据库当前数据源还是以财报和新闻为主缺少行业数据、专利数据这类更细的维度接入之后审计 Agent 的交叉验证能力会更强。第三是做一个定期跟踪模式让同一个标的每隔一段时间自动跑一次对辩把两次跑批之间的新增矛盾点单独摘出来形成一份变化清单。然后再分享一个我现在实际使用的小技巧配置结束条件时不要一开始就设 3 轮固定轮次而是先把min_information_gain调得保守一些比如 0.15跑两批看 Trace 里新增信息的衰减曲线再根据衰减速度决定你想让它在第几轮收手。每一类任务的信息衰减节奏不一样金融财报分析通常第三轮就开始明显递减但如果是开放式的行业趋势讨论第五轮可能还在产生新角度。用数据说话比拍脑袋定轮次要靠谱得多。