构建AI金融智能体的经验教训

在金融服务领域构建AI智能体，我花了两年时间积累了大量经验。这篇文章将系统性地分享这些教训，涵盖从沙箱到监控的方方面面。

金融服务的严苛性

这个领域不容许任何错误。数字至关重要——错误的收入数字、曲解的业务指引、不准确的DCF假设，都可能导致专业投资者做出百万美元级别的错误决策。用户是金融界最聪明、时间最紧迫的人群，他们能瞬间识别出纰漏。这迫使我对每一个细节都近乎偏执：每个数字都要复核，每个假设都要验证，每个模型都要经过压力测试。这种对错误的恐惧，反而成了我们最好的品质。

在LLM的应用历程中，我们早期做出了一些大胆的基础设施选择，事后证明是正确的。例如，当Claude Code推出以文件系统为先的智能体化方法时，我们立即采纳——这并非显而易见的决定，而是对架构的一次大规模重构。当时整个行业（包括Fintool自己）都在构建复杂的RAG管道，使用向量数据库和嵌入。在反思信息检索的未来后，我写了“RAG讣告”，Fintool全面转向智能体搜索，甚至退役了宝贵的嵌入管道。人们曾认为我们疯了，但如今许多初创公司都在采纳这些最佳实践。

沙箱不是可选项

2023年刚启动Fintool时，我曾以为沙箱是多余的。“只是运行Python脚本而已”，我这样告诉自己。结果证明一切皆有可能出错——当LLM第一次试图在服务器上执行rm -rf /（为了“清理临时文件”）时，我成了沙箱的坚定信徒。

智能体需要执行多步操作：专业投资者要求DCF估值，这不是单次API调用。智能体需要研究公司、收集财务数据、在Excel中建立模型、运行敏感性分析、生成复杂图表、迭代假设。这涉及几十个步骤，每个步骤都可能修改文件、安装包、运行脚本。没有代码执行就不可能实现，但在服务器上执行任意代码是疯狂的。每个聊天应用都需要沙箱。

如今，每个用户都有自己的隔离环境。智能体可以在其中为所欲为——删除所有文件、安装奇怪的包——这是用户的沙箱，尽情享受。架构包含三个挂载点：/private（读写，用户个人文件）、/shared（只读，组织文件）、/public（只读，全局资源）。关键在于凭证：我们使用AWS ABAC（基于属性的访问控制）生成限定于特定S3前缀的短期凭证，用户A物理上无法访问用户B的数据。我们还实现了沙箱预热——用户开始输入时，后台即启动沙箱，等用户按下回车时沙箱已就绪。

上下文即产品

智能体的好坏取决于它能访问的上下文。真正的工作不是提示工程，而是将来自数十个来源的混乱金融数据转化为清晰、结构化的上下文，供模型使用。这需要工程团队具备深厚的领域知识。

金融数据以各种格式呈现：SEC文件（HTML嵌套表格）、财报电话会议记录（说话者分割文本）、新闻稿、研究报告（PDF）、市场数据（数据库）、新闻、另类数据（卫星图像、网页流量）、券商研究、基金文件等。每个来源都有不同的模式、更新频率和质量水平。智能体需要的只有一件东西：可推理的干净上下文。

我们将其统一为三种格式：叙述性内容用Markdown、结构化数据用CSV/表格、可搜索性用JSON元数据。分块策略至关重要：10-K文件按监管结构（第1、1A、7、8项...）分块；财报电话会议按说话者轮次分块；新闻稿通常为一个块；新闻文章按段落分块。分块策略决定智能体能检索到什么上下文——糟糕的分块导致糟糕的回答。表格是特殊领域：LLM擅长推理Markdown表格，但不擅长处理HTML标签或原始CSV转储。因此标准化层将所有表格转换为干净Markdown表格。元数据使检索成为可能：当用户问“苹果在上次财报电话会议上关于服务收入说了什么？”时，系统需要解析股票代码、过滤文件类型、进行时间筛选、定位章节。这正是为什么每个文档都有meta.json——没有结构化元数据，检索就等同于在草垛里找针。任何人都可以调用LLM API，但不是每个人都有能力将数十年的金融数据标准化为可搜索、分块、带元数据的Markdown。数据层才是智能体真正工作的基础。

解析难题

标准化金融数据占据了80%的工作量。SEC文件具有对抗性：它们不是为机器阅读设计的，而是为法律合规设计的。表格跨越多页，页眉重复；脚注交叉引用其他脚注；数字出现在文本、表格和附件中（有时不一致）；XBRL标签常用错或不完整；不同申报人格式迥异。我们尝试过现成的PDF/HTML解析器，它们在代理声明中的多列布局、MD&A部分的嵌套表格（表格中的表格）、水印和页眉侵入内容、扫描附件以及Unicode问题上纷纷失败。

Fintool解析管道包括：原始文件 → 文档结构检测 → 表格提取（保留单元格关系） → 实体提取（公司、人物、日期、金额） → 交叉引用解析 → 财政周期标准化 → 质量评分。表格提取本身值得专题讨论：金融表格含义密集——合并标题单元格、脚注标记、负数括号、混合单位、前期重述。我们对每个提取的表格进行评分：单元格边界准确性、表头检测、数字解析、单位推断。低于90%置信度的表格被标记为人工审查。财政周期标准化至关重要：“Q1 2024”存在歧义——可能是日历Q1（2024年1-3月）、苹果的财政Q1（2023年10-12月）或微软的财政Q1（2023年7-9月）。我们维护了一个包含10000多家公司的财政日历数据库，每个日期引用都标准化为绝对日期范围。这对用户不可见，但对正确性必不可少。

技能至上与模型迭代

技能是产品核心。基于Markdown的技能——例如通过ReadFile、WriteFile和Bash工具实现的文件系统操作——使智能体能够执行复杂金融工作流。这些技能设计为独立于模型，以便随着模型的改进而演进。我们的架构旨在适应未来：当前模型可能擅长某些任务，但下一代模型会更好。因此，我们按“技能”而非按“模型能力”来构建产品。

S3优先架构

用户数据存储在S3中，而非数据库。S3在文件存储上远优于数据库：它提供无限扩展性、强一致性（针对新对象）、强大的访问控制（ABAC），并且与沙箱环境无缝集成。每个用户的工作目录都直接映射到S3前缀，使文件操作既简单又安全。

Temporal与实时流

Temporal管理长期运行的任务。当用户启动一个复杂的分析时（例如，筛选1000支股票），Temporal确保任务可靠执行，支持暂停、恢复和取消——并且取消处理是干净利落的，不会留下僵尸进程。实时流通过delta更新实现：智能体逐步生成结果，用户界面逐步展示，而非等全部完成才显示。这创造了流畅的交互体验。

评估与监控

评估不是可选项。我们构建了领域特定的评估框架：例如，检查DCF模型中的计算是否正确、表格数据与原文是否一致、法律免责声明是否被意外删除。这些评估在用户发现之前捕捉错误。生产监控则依赖于日志、指标和告警系统。我们追踪每个工具调用的延迟、成功/失败率，以及用户反馈（例如，用户是否删除了智能体的输出？）。这使我们能快速迭代改进。

总之，构建金融AI智能体是一个系统工程，涉及数据管道、基础设施、用户体验和风险评估的深度结合。分享这些经验教训，希望能帮助更多同行少走弯路。