为什么 Coding Agent 先跑通，金融 Agent 却更难？

先给判断

Coding Agent 领先，不是因为软件工程比金融简单，而是因为软件世界为 Agent 准备了更完整的反馈环境。

代码任务通常具有：

• 机器可读的状态；
• 可以直接执行的动作；
• 较快返回的测试和错误；
• 相对廉价的隔离与回滚；
• 可以审查的 diff 和版本历史。

金融研究缺少这些天然条件。公司价值、行业趋势和投资结果往往要经过数月甚至数年才显现，还受到大量外部变量影响。研究做错时，也很难像撤销一段代码那样恢复已经发生的决策。

因此，把 Coding Agent 的聊天框和工具调用搬到金融领域，不等于金融 Agent 已经成立。

Agent 需要的不只是知识

一个能够行动的 Agent，至少需要理解六件事：

1. 当前状态是什么；
2. 可以执行哪些动作；
3. 哪些动作需要权限；
4. 如何判断动作结果；
5. 失败后怎样恢复；
6. 何时停止并交给人。

软件仓库把许多状态写在文件、测试、日志和版本控制里。金融研究的关键状态却可能散落在 BP、财务表、访谈、政策、新闻和研究员经验中，而且不同来源对同一事实可能给出冲突答案。

状态不可见，Agent 就无法稳定行动；状态没有结构化保存，长任务也难以继续。

为什么测试对 Coding Agent 如此重要

SWE-bench 类任务不只要求模型生成代码，还要求它理解真实仓库、修改文件并通过测试。

测试为 Agent 提供了一个外部反馈信号：结果不是“看起来像正确代码”，而是能否在给定环境中运行。

这仍不代表测试等于真理。测试可能遗漏安全、性能和边界条件，任务也可能与真实长期维护存在差距。但相较开放世界知识工作，软件已经拥有高密度、低延迟、可重复的反馈。

金融领域必须主动建设类似结构，而不能等待一个天然存在的单元测试。

金融研究的 verifier 为什么更贵

投研任务中的“正确”常常分成多层：

• 事实是否准确；
• 来源是否有资格；
• 数字口径是否一致；
• 推导是否合理；
• 风险是否被充分覆盖；
• 最终判断是否适合当前机构和时点。

前几层可以通过工具和规则部分验证，后几层需要领域专家、组织偏好和责任判断。

更麻烦的是，投资结果不能简单反推研究质量。一个高质量判断可能因为外部冲击产生亏损，一个低质量判断也可能偶然获得收益。用短期回报作为唯一奖励，Agent 很容易学习错误捷径。

金融 Agent 需要自己建设六种基础设施

1. 可观察的研究状态

项目、材料、来源、主张、反方问题、人工修改和当前结论必须被持续保存，而不是只留在一次对话里。

2. 来源资格

搜索结果、公司自述、第三方数据和独立事实不能使用同一证据等级。

3. 可执行验证

数字复算、引用定位、时间口径、实体匹配和披露规则应尽可能交给确定性工具。

4. 检查点与版本

长任务需要保留中间状态、失败路径和历史报告，避免一次错误覆盖全部研究。

5. 权限与隔离

内部材料、客户数据和公开信息必须有明确边界；Agent 不能因为“有工具”就拥有无限行动权。

6. 人工升级

来源冲突、重大风险、价值判断和最终承诺必须进入人工审核。

为什么报告不是终点

如果系统只在最后生成一份 PDF，绝大部分过程仍然不可见：

• 为什么选择这些来源；
• 哪个数字被修改过；
• 哪条反方证据改变了结论；
• 哪些问题因为材料不足没有回答；
• 下一次研究如何继承这次经验。

Coding Agent 的价值不只在最后提交代码，也在可审查的修改过程。金融 Agent 同样需要让判断如何形成、如何改变成为产品的一部分。

如何评价金融 Agent

除了最终报告质量，还应观察：

• 是否能在明确材料边界内持续完成长任务；
• 是否能定位关键主张的原始来源；
• 是否区分事实、推导、判断和未知；
• 是否在冲突和高风险位置主动升级；
• 是否保留版本、修改与失败；
• 是否能用真实历史任务与人工基准比较；
• 是否降低审核负担，而不是把错误发现成本转移给用户。

研究起点与边界

本文由 Coding Agent 环境结构研究派生。最初研究问题来自一份非官方、自动整理的技术交流文字稿，但最终判断不依赖人物权威。Coding 领先说明反馈环境的重要性，不支持把软件 benchmark 直接外推为金融自治能力。