两年金融AI踩坑实录：一位创始人的血泪教训

在金融服务领域做AI Agent，每一个错误都可能让你万劫不复。一个错误的营收数字，一句被曲解的业绩指引，一个有问题的DCF假设，专业投资者会拿着你的输出做上百万美元的决策。错一次，信任就永远消失了。

过去两年，我在这个领域积累了足够多的伤疤，今天想把这些教训分享出来。

+ 沙箱环境绝对不是可选项

刚开始我觉得沙箱有点小题大做，不就是跑几个Python脚本吗，能出什么问题？

结果第一次LLM决定在我们服务器上执行“rm -rf /”来“清理临时文件”的时候，我彻底成了沙箱的信徒。

Agent需要执行多步骤操作。用户问一个DCF估值，这可不是一个API调用能搞定的事。Agent得研究公司、收集财务数据、在Excel里建模型、做敏感性分析、生成图表、迭代假设。几十个步骤，每一步都可能修改文件、安装软件包、运行脚本。

没有代码执行做不了这些。但在服务器上执行任意代码，这简直是疯了。现在每个用户都有自己隔离的环境，Agent在里面想怎么折腾都行。

+ 上下文才是真正的产品

Agent的能力上限取决于它能访问的上下文。真正的工作量根本不在提示词工程，而在于把来自几十个数据源的混乱金融数据，转化成模型真正能用的干净结构化上下文。

金融数据的异构程度令人发指。SEC文件是带嵌套表格的HTML，财报电话会是按发言人分段的文本，新闻稿是半结构化HTML，研究报告是带图表的PDF，市场数据在Snowflake里，还有各种另类数据。每个来源都有不同的模式、不同的更新频率、不同的质量水平。

Agent只需要一样东西：干净的、可推理的上下文。

所有内容最终都会变成三种格式：叙述性内容转成Markdown，结构化数据转成CSV和表格，用于搜索的元数据转成JSON。

+ SEC文件解析是一场对抗性游戏

这些文件压根不是为机器阅读设计的，是为法律合规设计的。表格跨多页还带重复的表头，脚注引用附录而附录又引用其他脚注，数字出现在正文、表格和附录里但有时候还不一致，XBRL标签经常是错的或不完整的。

财务期间的标准化尤其关键。“2024年第一季度”这个表述本身就是模糊的：可能是日历年的一月到三月，可能是苹果的财年第一季度，也就是2023年十月到十二月，还可能是微软的财年第一季度，也就是2023年七月到九月。我们维护着一万多家公司的财务日历数据库，每一个日期引用都要标准化成绝对日期范围。

+ 技能才是产品本身

没有人告诉你的真相是：模型不是产品，技能才是产品。

没有技能的情况下，模型在领域任务上表现得出奇地差。让一个前沿模型做DCF估值，它知道DCF是什么，能解释理论，但真正执行的时候？它会漏掉关键步骤，用错这个行业的折现率，忘了加回股权激励，跳过敏感性分析。输出看起来挺像那么回事，但在真正重要的地方有微妙的错误。

技能就是一个Markdown文件，告诉Agent如何完成某个具体任务。包含使用时机、操作步骤、行业指南等内容。

这太重要了。非工程师也能创建技能。我们的分析师在写技能，客户也在写技能。一个做过500个DCF估值的投资组合经理可以把他的方法论编码成技能，不用写一行Python。技能可读、可审计，出问题的时候你能读技能文件就理解Agent应该做什么。

+ 模型会吞噬你的脚手架

模型进步很快。每隔几个月，就有新模型让你一半的代码变得多余。我的预测是：两年内，我们大部分基础技能会变成一句话就能搞定。“生成一个20个标签页的DCF”。就这样，模型会知道这意味着什么。

但反过来说，当基础任务变成日用品，我们就会进入更复杂的领域。这个前沿在不断移动。

+ S3优先架构

用户数据存储在S3里作为YAML文件。S3是真实来源。Lambda函数把变化同步到PostgreSQL用于快速查询。

为什么？耐久性：S3有11个9的可用性，数据库没有。版本控制：S3版本管理免费给你审计追踪。简单性：YAML文件人类可读，用cat就能调试。成本：S3便宜，数据库存储不便宜。

用户记忆也存在这里。每个用户有一个Markdown文件，用户可以直接在UI里编辑。每次对话都会加载并注入为上下文。用户写上“我专注于小盘价值股”或者“总是和行业中位数比较”，Agent每次对话都能看到并据此调整。

+ 实时流式传输

金融行业的人没有耐心。他们不会盯着加载动画等30秒。所以我们建了实时流式传输。Agent工作的时候，用户能看到进展。

关键洞见是增量更新，而不是完整状态。不是发送“这是目前完整的响应”，而是发送“追加这50个字符”。

有时候Agent需要在工作流程中间获取用户输入：“你偏好哪种估值方法？”“应该用共识预期还是管理层指引？”我们建了一个工具让Agent可以暂停、呈现选项、等待用户输入。这把Agent从自主黑盒变成了协作工具。

+ 评估绝对不是可选项

“快速发布，以后修复”对大多数创业公司有效。对金融服务无效。

我们维护大约2000个测试用例，覆盖代码消歧、财务期间标准化、数值精度、对抗性溯源等类别。

通用NLP指标在金融领域不管用。一个响应可能语义相似但数字完全错误。每个技能都有配套的评估集。PR如果让评估分数下降超过5%就会被阻止，没有例外。

+ 最大的教训

最大的教训不是关于沙箱、技能或流式传输。而是：模型不是你的产品，围绕模型的体验才是你的产品。

任何人都可以调用Claude或GPT。API对所有人都一样。让你的产品与众不同的是其他所有东西：你能访问的数据，你构建的技能，你设计的用户体验，你工程化的可靠性，以及你对行业的了解程度。

模型会继续变好。太好了！这意味着更少的脚手架、更少的提示词工程、更少的复杂性。但这也意味着模型越来越像日用品。

你的护城河不是模型。你的护城河是你围绕它构建的一切。

x.com/nicbstme/status/2015174818497437834