量化研究智能体的上下文工程：证明层级与数据存储

确定智能体可信任的内容

想象一下为WorldQuant BRAIN量化竞赛构建的由人工智能驱动的研究环境。在任何专业智能体、生命周期检查或自主循环出现之前，首先存在一个更基础的设计问题：系统应将哪些陈述视为真实？原始数据以四种彼此差异极大的形式呈现。

第一类是平台与赛事提供的官方文档，其中详细说明了表达式语言的运作方式、可用的运算符和数据集，以及合法的模拟设置。第二类是相关方法论。马科斯·洛佩斯·德普拉多所著的三本书为分析回测统计结果、策略风险、多重检验、投资组合结构及假设检验提供了工具，而伊戈尔·图尔钦斯基的《寻找阿尔法》则以实用的方式介绍了理念构建、交易频率、相关性、过拟合、偏差及策略的持久性等问题。第三类则是关于经济异常现象、市场参与者及信息流动的论文与深度研究笔记，这些内容可以被整理成一张图表，将公理、理论、异常现象、机制及实施方式相互关联起来。 第四类是项目运行过程中产生的各种内容：模拟结果、每日盈亏曲线、投资组合相关性、抗风险统计指标、平台检测数据、实验历史记录、操作事件、构建失败情况以及从中总结出的经验教训。

这些内容虽都属于上下文信息，但其真实度各不相同，且没有任何一种能够完美适配单一的提示词、单一的文档格式或单一的数据库。因此，在这种场景下进行上下文设计时，不能仅从令牌预算的角度入手，而应首先设计不同的证明层级，再构建能够保障各层级完整性的数据系统。

左侧是最初的天真设计，其中规则、书籍、论文以及系统自身的结果都被压缩到一个提示词中，且彼此权重相同。右侧则让每种主张都保持各自的层级：规则构成壁垒，信念提出检验方法，观察结果则对信念进行修正，而壁垒内的任何内容都无法修改这些规则。

三种证据层级

“证明”具有实际意义。对于任何主张，都要弄清楚需要什么证据、谁负责提供这些证据，以及什么情况可以推翻该主张。这三个层面可以解答这些问题。

L1依据平台官方资料及比赛规则，记录平台所定义的游戏内容。当智能体需要了解有哪些设置存在、操作员执行了什么操作、候选者必须通过哪些检查，或是比赛如何计算得分时，都会查询这一层数据。本地副本可能会过时，但任何实验都无法改变既定规则。

L2记录系统实际观测到的内容。模拟输出、每日盈亏数据、当前投资组合、平台检测结果、操作事件以及最新的排行榜状态都属于这一层。每项数据都会标注其被观测的时间。重新运行不会覆盖任何现有数据，只会生成新的观测结果，因此历史记录不会在事后被整理。

L3层收录了系统当前认为有用的内容。书籍、论文、经济理论、技术规范、知识图谱中的信息、记录下来的经验以及经过筛选的反证都位于这一层。这些内容为后续行动提供指引，同时也可能被推翻。

各层之间的顺序并非固定不变，L1并不总是优于L2，L2也并非总是强于L3。每个层级负责回答不同类型的问题。当不同来源之间存在事实争议时，最有力的直接证据会占据上风，因此官方规则比智能体提示中的释义更具优先性，而经过权衡后的回应则比某本书所引导的预期更有说服力。然而，对于“下一步该尝试什么”这一问题，规则和量化标准却无法给出答案，这时就需要L3层来做出合理的判断。

该图表追踪了三种投资思路。关于收益发布后股价走势的思路并未因其被证伪而放弃，反而找出了出问题的模型，于是围绕分析师的修正意见重新构建该思路，并提交了两个版本。另一种基于同行组合的思路最初仅基于毫无依据的猜测，却依然获得了通过。而关于股息发放时机的思路在所有十种模型中均失败，这一教训使得相关判断范围缩小到仅考虑股息发放日期。绿色方块表示已通过平台验证，红色方块表示未通过，灰色方块表示暂无相关验证记录，带环的方块则表示已提交。

一个数据库中可能同时包含测量值（L2）以及某人对该值的读取结果（L3），这意味着层级是关联于具体陈述的，而非其存储位置。因此，包含丰富信息的上下文记录比纯文本更为有用。它应当记录该陈述本身、其认知层级、来源、所有者、范围、观测或审核时间、不确定性、稳定标识符，以及任何可能用于修正该陈述的证据。对于会随时间变化的事实，使用时间线对有助于明确：某事在何时为真，以及系统在何时得知这一事实。那些响应延迟且事后补充历史数据的API会使得这种时间差变得重要。

上下文实际上就是一个小型数据平台

每个商店都是根据其行为来绘制的。账本以分层方式存储证据，且有一条贯穿所有层的链式结构；旧事件会逐渐淡出，该图表实际上是一对表格，在内存中则变为多图结构，而文件则按生命周期进行分组。稳定标识符将所有部分连接在一起。每日损益仍位于该项目规范所规定的位置上。

一旦有了验证层级，另一个事实便显而易见：上下文并非单一的语料库，而更像一个规模适中的数据平台。其中最大的一部分是研究日志，而在被检测的工作站上，它表现为一个事务型 SQLite 数据库。将其称为实验表其实低估了它的功能，因为它实际上是一个证据日志，存储着多类记录。一类是研究目标，包括相关机制、假设、预测以及实现方案的发展脉络；另一类是测量数据，用于存储平台的响应结果、样本内统计信息、各项检测指标、每日损益情况以及压力测试数据；第三类是解读内容，包含各种归因分析、经验总结以及特定范围内的反证；第四类则是管理信息，用于追踪候选决策、审批流程以及提交时的相关情况。 最后一种是可视化分析：投资组合变动值、相关性分析界面、模式缓存以及压力测试总结，所有这些都可以从标准输入数据中重新生成。

审计过程中发现了不一致之处。设计文档称每日损益数据已被存入Parquet文件，但数据库仍保存着每一行数据。设计文档属于观点（L3层级），而数据库记录属于观察结果（L2层级），在两者冲突时以观察结果为准。

接下来是操作事件存储，它以独立的 SQLite 数据库形式存在。这些事件会携带周期、批次、候选项、假设、代理及流程标识符，同时还包含带版本号的 JSON 数据内容。虽然很想将它们整合到账本中，但两者的数据保留需求不同。研究证据属于标准格式，必须长期保存；而调试输出、调度事件、队列状态变更以及临时干预措施的数量会迅速增加，这类数据可以被压缩或设定过期时间。将两者分开后，大量的可观测性数据就不会导致科学记录变得臃肿或无法使用。

还有知识图谱，它是一种事务型属性图，其结构设计得极为简单：包含节点表、边表以及针对各类数据特征的JSON属性，所有这些数据都会被加载到内存中的图结构中以便遍历。事务层避免了单个巨大YAML文件可能带来的数据损坏和并发问题，而内存存储形式则使得推理过程更加高效顺畅。

文件系统也属于数据系统的一种。存储库中保存着不可更改的平台文档、书籍、论文以及衍生报告，将所有这些内容加载到内存中是错误的做法，因为它们的生命周期各不相同。平台文档永远不会改变，而规格说明则是处于版本控制下的设计基准。报告则是需要记录输入数据并具备重新生成功能的衍生内容。内存文件则是指向可重复使用内容的简短、可读的指针。队列文件、缓存和日志属于临时性的操作状态，而模型二进制文件、损益导出结果以及大型快照这类数据，最好存储在对象存储中，而非 Git 中。

那些失败案例很能说明问题。有一只表现优异的阿尔法模型差点被淘汰，因为账本显示所有检测都通过，而实际有个脚本正在读取一个显示夏普值为0的运行文件。还有早期的一只获胜模型在六周后通过对账才获得了决策记录，此前它根本没有相关记录。针对“反贝塔”策略的判定仅存在于一个Markdown格式的存储文件中，因此账本本身根本无法阻止重新尝试。

实际上这里存在一个多类型的上下文系统，尽管几乎所有功能仍运行在同一台笔记本电脑上。SQLite负责处理事务，图结构用于管理各种关系，Parquet则是处理大型时间序列数据的预定格式，Markdown用于存储可供人们查阅的知识，而临时文件则负责协调本地进程。

此处展示了一个去除了名称的真实机制。左侧显示了它在知识图谱中的起源，右侧则列出了所有用于验证它的假设、实验及候选方案。有些缺陷在各种实现中都会出现，而另一些则仅限于特定实现。这两部分除了接合处的ID外毫无共同之处，而这个唯一的标识符就足以将它们整合为一个紧凑的上下文数据包。

机制充当了这两个存储系统之间的桥梁。在图中，机制以经济理念的形式呈现，并标注其来源；而在账本中，则作为每个应用了该机制的假设和候选方案的标签出现。为了便于导航，可以将经验总结数据映射回图节点，但这些只是镜像，真正的数值仍存储在实验数据库中。因此，一个完善的上下文数据包是通过跨系统整合而成的——它包含一个小范围的图结构、来源的溯源信息、当前的实证汇总数据、近期的失败案例以及相关的平台限制条件。该模型无需使用完整的图结构或所有的损益记录行，关键在于能够找到通往当前决策的最短证据路径。

当图表与账本共享机制ID时，就可以一起查看完整的分支结构：理论、实验、所有候选方案，以及与账本对应的图表节点上的总结。回购授权的构想直接源自1995年的一篇论文，但它从未被纳入股份回购分支，因此其任何结果都无法从图表中获取。

有几种数据契约值得制定得更严格些。跨存储系统传输的对象应明确标注JSON模式版本；任何衍生指标都应注明生成它的代码版本、源代码快照以及方法版本。每个实验都应配有用于复现的结果清单，列明代码提交信息、环境配置摘要、平台设置，以及假设和实现ID。此外，对数据一致性的验证应与其他数据质量问题一样进行测试，而非视为无关紧要的常规操作。

总结设计理念：图表是上下文，账本也是上下文，二者之间的关联同样属于上下文。这一关联需要与模型代码相同的工程级重视程度。

这与系统集成工程的结合点

不会将整个存储数据一次性传递出去。每个存储单元都会为类型化的数据包贡献一小部分内容，各专业人员只能获取其所需的部分。处理结果会按类型返回到对应的处理单元，规则永远不会被直接写入，同时有两个循环以不同的速度为下一个数据包补充数据。

这标志着上下文工程与工具工程之间的分界。上下文管理负责处理L1至L3层级：它保存来源数据、测量结果、先验信息、来源追溯信息、时间戳、范围以及稳定标识符。L4层级即代理工具，负责决定检索哪些证据、在阶段边界允许传递多少信息、由哪位专家处理这些信息，以及哪些结论是有效的。其下方是源代码（L5）、本地基础设施（L6）和分布式基础设施（L7）。这些层级能够完美地执行错误判断，但它们无权决定输入内容属于规则、观察结果还是信念。

早期的版本模糊了这种区分。最初的指令文件逐渐发展成一个包含627行的维基页面，其中汇集了比赛规则、实时状态、操作方法以及前一天的学习内容。后来该文件被简化为一个小型的路由器，信息通过四条路径传递给智能体。有一层简短的模块会一直保持加载状态，启动数据包则携带最新的学习内容与警告信息。只有当任务涉及特定区域时，该区域的规则才会被加载，而具备相应记忆功能的专用角色也仅在需要时被调取。

一条请求，多路径追踪

考虑这样一个问题：“接下来应该尝试什么？”该系统首先会生成一个预检数据包。从L1层获取相关的表达式、设定条件及评分约束；从L2层获取当前的成果集、最近的测量数据、已被覆盖的搜索空间范围以及尚未解决的结果；从L3层获取最相关的图结构分支、理论来源、范围限定因素、研究规范以及经验教训。

随后子代理开始发挥作用。假设专家会根据该数据包提出若干经济角度的分析，但不掩饰公式背后较为薄弱的推理逻辑。选定一个角度后，建模专家会基于已登记的假设构建彼此存在明显差异的实现方案。实验专家则会根据实现方案树和平台限制条件，记录需要测量的内容。

每个阶段都有其特定的目标。账本中的L2层接收原始平台结果及标准化后的测量数据。诸如任务启动、工具调用、重试操作以及协调通信等运营事件则存放在事件存储中。当某项结果能带来经验教训或可验证的错误信息时，会被归档到L3层。图表汇总数据是通过与账本比对得出的，不会被人工编辑；而大量的损益序列、图表以及拟合模型则会成为其他记录所引用的对象。

所提交的两个测试版本都基于已包含相关证据的数据包。其中一个方案此前已优化过投资组合，另一个方案则复用了之前已生成过无关联测试结果的构建方案。还有一个旨在改变评分的方案，虽然获得了数据包、机会图上未经测试的单元格以及可供参考的过往成功案例，但其18种构建方案最终全部失败了。

基础设施的分阶段建设

试图一次性处理所有内容是错误的。每条数据通道都在不同的阶段进行转换，只有当存在可测量的触发条件时才会打开相应的通道。右侧展示了值得信赖的单一写入路径（提交、待处理队列、导出器、投影器），而双重写入则会生成两种相互矛盾的结果。

当前的本地堆栈功能远超表面所见。对于单独工作的研究人员而言，SQLite是个绝佳的选择，它具备真正的事务处理功能、简单的备份方式、快速的本地查询速度，且几乎没有额外的操作开销。不过也存在着一些局限：几GB大小的数据库可能包含数千万行时间序列数据，多个工作进程可能会竞争本地写入权限，运行时事件不断增多，生成的工件和快照都绑定在同一台机器上，要在其他地方复现结果则需要处理大量隐藏状态。因此，分五阶段逐步发展才是合理的做法。

第0阶段的目标是让设计与现实相符：要么完成尚未完成的损益数据迁移，要么主动回滚该操作，随后实现自动审计，将文档与实际存储内容进行比对。第1阶段是将大量数据输出到外部，因此每日损益数据、图表、模型文件、大型报告以及数据库快照都会被存储到兼容S3的对象存储中，而损益数据则会拆分成压缩后的Parquet格式分区，并通过不可变的清单、校验和以及生命周期规则来加以管理。第2阶段仅在并发访问导致问题时才会迁移元数据。当远程工作者、多台机器或协作人员需要同时写入数据时，账本和事件存储会被放到托管版的PostgreSQL中，作为独立的数据库，或者至少是具有各自保留策略的独立模式。第3阶段会将MLOps作为辅助工具引入，而绝不会将其视为数据的唯一来源，因此Weights & Biases或MLflow可以起到辅助作用，而无需取代账本或数据图结构。 第四阶段将编排逻辑与状态分离：研究人员在包含不可变任务清单的容器中运行，而队列或工作流引擎则负责分配具有租约机制、重试功能和超时控制的幂等任务。第五阶段仅在工作负载需要时才提供更丰富的分析功能。湖仓表格式、专用图数据库或流处理平台或许最终能带来好处，但只有当某些特定查询开始造成性能问题时才会如此，比如对数十亿条数据的扫描、大量同时进行的图遍历、大型Parquet文件集的架构演变，或是低延迟的事件处理需求。

这种架构并未带来确切的性能提升，因为其效果从未被单独验证过。它的真正价值在于让系统能够坦诚地出现矛盾。有论文提出某种观点，模拟结果却与之不符，伪造数据会缩小可信度范围，但竞赛规则依然有效。