Jump Trading：如何构建量化Multi-Agent系统

演讲来源：ICML 2026 Expo Talk
演讲者：Loren Puchalla Fiore，Jump Trading机器学习工程负责人；Lucas Baker，Jump Trading LLM研发负责人
原视频：https://icml.cc/virtual/2026/75722

Loren Puchalla Fiore与Lucas Baker分别是Jump Trading的机器学习工程负责人和LLM研发负责人。Jump是全球领先的自营交易机构之一，长期依靠数学、统计、机器学习和低延迟系统，在全球市场使用自有资金进行交易。随着LLM进入量化研究流程，团队开始进一步研究如何让模型承担更复杂的研究任务，并将多个Agent组织成可重复、可评估的研究系统。

这场演讲主要讨论Jump如何为Quant Research设计和评估Agent系统：什么任务适合Multi-Agent，怎样基于真实内部工作流建立Benchmark，如何比较不同模型和Harness，以及怎样把AutoResearch做成一个有明确输入、输出、权限、约束和Scorecard的可检查系统。团队强调从最小可工作的闭环开始，只有当性能、速度、成本或可靠性真正改善时才增加复杂度，再逐步扩大运行时间、并行度和计算资源。

TL;DR：Jump Trading的核心观点

1. 金融模型需要在预测能力、数据量和速度之间取舍。 短周期拥有更多观测，但留给模型的计算时间很少；周期拉长以后，可以使用更复杂的模型和更多上下文，独立样本却随之减少。上下文长度翻倍，如果仍要求样本彼此独立，可用数据就会减半。
2. 金融Agent做历史测试时，很容易出现“时间旅行”。 Frontier Model可能在训练阶段见过后来发生的新闻和事件，回测结果因此被高估。时点一致性（Point-in-time Correctness）要求系统明确每个历史时点能够获得的信息。Jump还会比较模型知识截止日前后的表现，以衡量Temporal Leakage的影响。
3. 系统设计从最简单的Baseline开始。 Jump先用一个模型、一个Harness和一条Agent Loop跑通任务，再分别测试Prompt、Context、工具、Subagent、模型和Token Budget。增加复杂度以后，如果质量、速度、成本或可审查性没有改善，就没有必要保留。
4. Multi-Agent只适合一部分任务。 顺序依赖很强的工作通常适合单Agent；工具调用可以使用去中心化的多Agent；结构清楚、能够并行拆解的问题适合Orchestrator–Worker。系统怎样分工，取决于任务结构。
5. 公开Benchmark无法覆盖Jump的真实研究环境。 私有数据、内部工具、时间泄漏和实际工作流都需要自行评估。Jump从研究员与内部Agent的真实对话中提取案例，记录工具调用、证据、Trace、Artifacts、延迟和成本，再比较不同模型与Harness。
6. AutoResearch需要提前规定系统的活动边界。 输入、输出、权限、约束、阈值和Scorecard都要明确。系统先在小范围内稳定运行，再增加运行时间、并行任务和计算资源。每次修改都保留轨迹并重新测试，避免错误不断累积。
7. 严格评估依赖长期积累的数据和基础设施。 Jump保存了十五年以上的详细市场数据和交易所原始网络包，并能回放历史数据、重建不同时间点的市场状态。Agent因此可以在接近实际交易环境的条件下接受时点一致性测试。

演讲精编

订单簿、速度与预测

Loren： 我是Loren，今天和同事Lucas一起分享我们在Multi-Agent系统、Benchmark和Eval上的一些经验。先用几分钟介绍交易和量化金融，以及它们为什么会成为有意思的AI与机器学习问题。

电子交易所最核心的数据结构是订单簿。图上左侧是买单，也就是愿意买入股票的人。目前最高买价是100.75美元。右侧是卖单，目前最低卖价是101美元。两边价格没有重合，所以还没有成交，买卖价差是25美分。

成交前的股票订单簿

随后有人以101美元买入350股。这里说“有人”，一方面因为这是为演讲虚构的例子，另一方面因为电子交易所通常是匿名的，股票订单簿不会告诉你下单者是谁。这笔交易改变了市场：最低卖价变成101.25美元，挂单数量是210股，价差从25美分扩大到50美分。

350股成交后的订单簿变化

量化研究会用数学和AI来描述订单簿状态、成交和相关信号，估计价格接下来怎样变化，再决定交易什么、以什么价格交易、交易多少。你可以抢先处理信息，也可以提高判断的准确性。Jump两件事都做，不过速度和模型复杂度之间存在取舍，后面我会回到这个问题。

Jump是一家自营交易公司。我们没有外部投资者，使用自己的资金交易。如果多年以后赚到了钱，公司就有更多资本进入更多市场。Jump于1999年在芝加哥成立。当时用来争取速度优势的工具可能只是一副耳机，因为无线电波比声音传播得快。老照片里还能看到CRT显示器。

现在Jump在全球有十多个办公室，以电子方式交易不同资产和不同时间周期。工程团队负责共址服务器、定制网络、FPGA、ASIC和其他基础设施；研究团队使用大数据、GPU和超级计算机建立预测模型。

快与聪明之间的取舍

Loren： 假设巴黎和柏林的两个市场最初都报100美元。巴黎发生一笔交易后，中间价变成105美元。两个地点相隔很远，信息传输需要时间，所以柏林仍然报100美元。如果你最先把巴黎的信息带到柏林，就可能在那里交易。

这里省略了一个很有意思的问题：为什么要相信巴黎的105美元，而不相信柏林的100美元？柏林的价格可能仍然正确，交易机会也可能在巴黎。怎样建立两个市场之间的关系，会决定你是否看到信息在交易所之间来回反射。

模型也不需要百分之百正确。假设你面对一枚正面概率为51%的硬币。只掷100次时，模拟路径大约一半赚钱、一半亏钱，结果并不好看。若能在控制风险、不让自己中途破产的前提下重复10,000次，所有模拟路径最后都可能转为正值。量化交易可以依靠很小的预测优势，只要市场提供足够多的机会让它重复兑现。

金融模型在速度与智能之间的取舍

较短的预测周期提供大量观测，简单信号也可能有效，但系统只能使用很低的延迟预算。较长周期允许模型读取丰富上下文，也能运行更大的模型，可用的独立样本随之减少。上下文长度翻倍以后，若仍要求样本彼此独立，数据量会立刻减半。这一点与很多AI和机器学习问题不同。

Point-in-time与“时间旅行”

Loren： 幻灯片上有红色和绿色两条回测曲线。虚线左侧，两条曲线看起来都很合理；虚线以后，绿色曲线出现了明显拐点。虚线标记的是模型训练数据的知识截止日期。模型在回测期的前半段已经见过部分未来信息，所以回测表现很好；走到训练截止日期以后，这种优势消失，表现随即变差。

金融Agent回测中的时间旅行问题

“时间旅行”是默认失败方式。模型知道未来发生过什么，而回测Eval没有正确处理这一点，于是研究人员被绿色曲线骗了。生产环境应使用红色模型，它正确处理了Point-in-time信息。

金融研究必须明确每个时点可以知道哪些信息。预测目标也不限于价格。系统还要决定交易量、交易时间，并判断一笔交易是否需要后续交易来管理风险。我们也希望尽早发现坏交易，最好在亏完钱以前发现。

市场中的海量重复决策

输入数据包含多种模态。交易所会发来订单和成交信息；公司自己也有内部状态，包括发出的订单和已经完成的交易；新闻、基本面和外部事件也会进入分析。

从单模型、单Harness开始

Loren： 为了判断Agent是否有用，我们先建立一个简单Baseline：一个模型，一个Harness，一条Agent循环。Agent接收任务，做出判断，也可以调用工具。

从最简单的Agent Baseline开始

新的Harness、模型或系统配置必须改善指标，才能证明额外复杂度有价值。有了Baseline以后，我们固定任务，改变Harness或Agent配置；也可以更换模型，比较Frontier Model、便宜的Open-weight Model、不同供应商或经过专门Fine-tuning的模型。

工具同样可以改变。我们可以增加查询内部数据的工具，或者让Agent调用交易模拟器做回测；也可以预先放入更多上下文，改变工作流和预算。假如系统花费10美元Token，只找到一笔预期收益为1美元的交易，这套系统会让公司破产。

不同Agent运行之间可以改变的变量

任务大致分为三类。第一类面向整个公司，例如理解内部代码库、超级计算系统和其中的特殊约束。第二类是市场分析，例如理解财务、Earnings Report或Sell-side Report。第三类是组件任务，例如检索正确数据、选择正确工具和进行事实核查。

这些变量组合成一个高维空间，一场演讲不可能全部展开。这里主要讨论Market Analyst任务。

评价结果时，我们会看预测质量，也会检查Agent有没有通过未来信息作弊，并计算Multi-Agent体配置的运行成本。

怎样建立Point-in-time Eval

Loren： 公开Benchmark可以帮助我们理解不同模型的优缺点，但它们缺少几项与量化研究密切相关的条件：Temporal Leakage、Point-in-time正确性、私有工作流、市场数据和内部数据集。

公开Benchmark与量化研究任务的差异

Jump因此建立了一套Point-in-time Agent Eval。我们先从研究员、Quant和工程师与内部聊天机器人的真实对话中寻找案例。来回讨论的对话最有用：Agent查询了一些数据，人类在下一轮指出它漏掉另一份数据，或者算错了数学。我们为这些对话标注所用数据和提问时间，再让语言模型把整条Trace转换成Eval Case。

理想的Agent可以一次找到全部正确数据，完成正确的工具调用，也不会做多余工作，因此不再需要人类在后续轮次纠正它。

建立Benchmark Case之后，我们让不同Agent和重复样本运行这些任务，保存Cases、Runs、Results、生成的Artifacts、完整对话、能够取得的推理Trace，以及不同模型之间的比较。事后分析时，其中任何一项都可能帮助我们找到问题。

Eval数据模型与运行记录

时点一致性评估流程

SpaceX IPO案例

Loren： 用SpaceX IPO做一个具体例子。用户问：“SpaceX预计在6月12日IPO，你预测上市首日的收盘价是多少？”

SpaceX IPO的种子问题

Eval先冻结允许使用的Point-in-time Evidence。问题的提问日期设为6月5日，也就是上市前一周。回答必须给出证据、不确定性和支持材料。

Agent调用了新闻、预测市场、公司元数据和S-1等工具，也运行Python脚本分析来源中的数字。答案中的内容至少标出日期，有时还要标出具体时间。系统还会记录新闻来自哪里、使用了什么市场数据，并核实证据确实存在，排除模型幻觉。

SpaceX IPO案例的证据与答案

模型与Harness的比较

Loren： 固定Harness后，可以比较不同模型。结果符合预期：版本更高的模型表现更好，例如4.8好于4.7。选出表现最好的模型以后，再开始迭代Harness。

我们把Baseline与两个定制方案比较，暂且称为Harness 1和Harness 2。端到端结果令人沮丧：两个定制方案与Baseline基本相同，只是噪声更大。

我们保存的指标不限于端到端分数，也包括Trace Analysis，例如Agent是否查询了正确数据、是否调用了正确工具。Harness 2在Trace指标上明显好于Baseline，Harness 1则更差。两个Harness做的事情存在一定正交性，所以我们又把它们组合起来。

组合Harness的评估结果

组合后的Trace分数仍高于Baseline，虽然略低于Harness 2。再看端到端结果，组合方案终于超过了Baseline。

较新的Frontier Model通常是端到端任务的合适默认选择，但它不会在每一个环节都占优。面对定义清楚的窄任务，小模型、专门模型或定制Harness可能表现更好。很多工作流由一系列窄步骤组成，因此组件层仍有大量改进空间。

更强的模型并非在所有任务上都更好

什么时候该用Multi-Agent？

Lucas： Loren已经介绍了量化金融背景和技术上下文，下面由我继续。

不同Harness设计适用于不同任务。大多数时候，你可以把Multi-Agent系统扔掉，除非手上有充分理由保留它。Claude、Codex和其他Harness已经把Subagent设成默认能力，仔细看会发现它们最常使用Orchestrator–Worker模式。

Multi-Agent系统还有很多结构：去中心化、中心化、彼此独立但协调提交的Fleet，以及混合模式。Google在关于Agent Scaling的文章里整理过这些结构。

Jump的经验是，去中心化Multi-Agent模式适合Tool Use；Orchestrator–Worker，也就是中心化模式，适合结构清楚且能够并行的推理。Subagent有明确角色和Persona时，系统通常更好用。任务具有很强的顺序依赖时，可以使用单Agent，后面也会谈到其中的例外。

不同任务对应的Agent Harness设计

研究社区重视新结果，常常低估简单方案。Multi-Agent系统在适合的场景很有用，多数任务用不到它。

先Prompt，再工具，最后才训练模型

Lucas： 我喜欢把解决任务所需的投入画成一条阶梯或瀑布。第一步是直接提问。每次发布更通用、更擅长长周期任务的新模型以后，直接提问通常能解决大部分问题。

遇到重要而又解决不了的案例，可以先增加Prompt和Context，也就是做Prompt Engineering；接着设计工具。第三、第四层有时会混在一起：重新设计Subagent结构、工具、可用模型，以及模型输出的融合方式。

完成这些工作以后，再考虑Post-training；随后才是更深的Post-training或Mid-training。如果这些仍然解决不了问题，你就成了DeepSeek，开始做Pretraining。

Agent系统的投入阶梯

在每一层都要回答同一个问题：你准备针对什么目标做专业化？答不出来时，专业化还为时过早。Knuth说过，过早优化是万恶之源；Agent系统里对应的是过早专业化。

Jump通常关心性能、延迟和成本。性能可以是智能程度、通用性，或者端到端任务和子任务上的Benchmark表现。延迟对高频和中频任务很重要，低频分析也可能因更快完成而受益。这里关心Time to Last Token：所有分析和整理工作结束、系统已经能够采取行动时，整条循环用了多久。

交易公司通常不太在意模型调用费，我们也不会为了节约本身去限制Token。不过这里存在Jevons Paradox：同一件事做得更便宜，就可以调用更多次。过去一个人只能针对一项资产提出一个问题；成本下降后，可以围绕同一主题提出所有问题，也可以把同一个问题用于所有资产。

Post-training适合什么任务

Lucas： 明确的流程适合训练专用Subagent，也适合投入高质量人工标注。这类任务不必只使用RLVR或粗粒度二元反馈。你可以收集人工标签，再用Agent辅助生成样本和担任Judge。

如果确实需要，也可以针对任务端到端训练整个Agent。不过，最快获得进展的结构通常是Frontier Orchestrator配合若干流程专用Subagent：一个负责市场分析，一个研究公司数据，一个制作图表。

只有当训练任务覆盖Foundation Model级别的广泛分布时，训练一个通用Agent才合理。否则Frontier Orchestrator加专用Subagent更合适。

适合与不适合Fine-tuning的目标

让窄任务重新快起来

Lucas： 我很不满意Agent花费的时间。去年我们上线第一条Data Agent Pipeline时，规定它必须在大约90秒内返回结果。当时用户习惯的是Chatbot或带RAG的Chatbot，任务范围明确，交互轮次也少。他们还没有耐心等待几分钟；结果迟迟不来时，他们会直接采用Chatbot给出的低质量答案。

现在的Agent更通用，也能在范围很宽的任务上运行更长时间。代价是，过去可以快速完成的窄任务变慢了。Claude和Codex可能花将近一分钟才弄清任务。

我们可以重新抽取这些子任务，像RAG一样把它们接入主系统，同时让一个智能Agent在子任务内部执行动态流程。这样既能降低延迟，也能提高正确率。

Goblin Mode的任务与时间范围

Goblin Subagent与Baseline的结果对比

图上的时间预算指最终答案所用时间，包含主系统和Subagent的完整运行时间。加入这类Subagent后，Codex有中等幅度改善，Claude的改善更大。图中较低的曲线可以看作竞争对手使用的系统：你们在相同时间内答对、对方答错时，你们赚钱，对方没有收益，甚至亏钱。这个差距可能很有价值。

几个月前GPT出现过一个Goblin事件，所以我们把这张图称为Goblin。Codex的提升较小，也许是因为它经过Post-training后不喜欢Goblin。当然，这只是个玩笑。

Multi-Agent越复杂，不代表泛化越好

Lucas： Multi-Agent系统和Harness能学到多少？我们又该多信任它？

如果让一群Agent研究一个开放问题，大多数Agent都能交回听起来合理的结果。接下来要处理怎样合并这些结果、每项结果是否有效，以及多重假设检验。

这是演讲里唯一的数学。系统从验证集获得的信息量，也就是过拟合差距，受到传递Token数的约束。约束来自可能消息的组合空间，与系统内部结构的复杂程度无关：

不要把这个上界直接用于实践，它相当于一个力度极强的Bonferroni校正。一个复杂Multi-Agent系统和一个会调用工具的单Agent，只要传递的信息量相同，理论约束就在同一个量级。上界取决于能够传递的消息空间，系统内部结构不进入这个约束。

多智能体通信量与泛化能力

AutoResearch与“造盒子”

Lucas： 过去几年，Agent先从Chatbot发展到带工具的Chatbot，再到由工具构成的DAG，随后出现可靠的单Agent、Multi-Agent系统、Fleet和初步的自我改进。

继续发展下去，我们的很多工作会变成“造盒子”。这里说的是灰盒：你能在一定程度上检查它，也能引导里面的Agent团队。盒子对应一个定义清楚的流程，外部规定输入、输出、阈值与约束，例如禁止Reward Hacking，只允许修改指定文件。我们还要定义Scorecard使用哪些指标。

AutoResearch灰盒系统

系统能力可以沿三个维度增加。第一个是运行时间。Karpathy最初的AutoResearch Agent会通宵运行，我们可以问它八小时能完成什么。第二个是并行度，像AlphaEvolve一样沿不同方向启动大量并行研究，再合并结果，以减少Wall-clock Time。第三个是单项任务的资源：一个信号运行一小时能有多可靠，两小时怎样；使用2张、4张、16张或1,000张GPU又会怎样。

这些曲线最终都会接近上限。Agent可能耗尽想法，也可能缺少产生新方向并正确组合它们所需的多样性。理想情况下，延长运行时间、增加并行研究和增加单项计算可以共同提高结果。

从最小闭环开始

Lucas： 建盒子时，应从一个能够端到端工作的封闭系统开始，并保持快速迭代。单个任务若要用四天算力，交给人可能更省事。先测量单个信号的可靠性，把它做到足够快，再调整小系统的稳健性，之后才扩展。

理想的盒子应当简单、稳健、安全、快速；在能力相同的条件下尽量小，并且保持模块化和可扩展。这些都是软件工程的基本要求。

从最小闭环开始构建AutoResearch

AutoResearch更需要维护流程本身的完整性。系统必须从一个可工作的状态走到下一个可工作的状态。若把一个坏状态当作起点，后续状态也会出错。让错误修改不断累积以后，第一次错误之后的全部修改都失去效力。

可操控性和可观察性也更重要。无法检查运行Trace时，你既不能信任结果，也不能解释或调试它。

研究修改可以像Git历史一样管理。每次变化都做成一块小而完整的积木：范围清楚、经过测试、尽量稳健。系统稳定以后可以增加Token，但起点不该是Token Max。

AutoResearch也是软件工程

真实系统需要Scorecard

Lucas： 这是一个经过匿名处理的真实Scorecard。最初介绍AutoResearch时，任务通常只有一个指标，例如优化Kernel，或者尽快把Transformer的Bits per Byte降到最低。真实系统通常有多个指标、阈值、约束和取舍，需要在Pareto Frontier上寻找平衡。具体怎样平衡，可以由人决定，也可以交给Agent。

真实AutoResearch系统的Scorecard

图中展示了一系列AutoResearch修改。很多修改改善了目标指标，却伤害了多数其他指标。只有在各项指标上接近最佳平衡的方案，才能通过最终Review。

实际工作里常见的场景是：AutoResearch把目标指标做得很好，你把结果拿给Quant，对方说整项分析无效。只要能把正确的Scorecard写清楚，Agent已经有能力在多个指标之间取舍。Scorecard必须能明确表达、能够计算，也要方便查看。

程序员的四种美德

Lucas： Larry Wall在1991年提出程序员的三种美德：懒惰、急躁和傲慢。

懒惰，是因为你希望长期投入尽可能少的力气。我会把工程师定义为：现在投入不合比例的巨大努力，只为以后省下一点力气。急躁，是希望系统尽快完成，希望算法有效率，不愿无谓等待。傲慢，是你把成果交给别人时，要求它可以工作，也能适应对方的需要。

我想增加第四种美德：正当的愤怒。系统能力增长时，我们不该接受体验退化。处理器越来越快，计算机的输入延迟却越来越慢。右图来自2017年，当时一次键盘输入已经要等待约200毫秒。Agent也不该等60秒才给出第一个有用输出。

程序员的四种美德

从工程转向引导Agent

Lucas： 工程师逐渐从亲自写代码转向引导Agent，工程也会越来越像哲学。下面几条定律可以作为起点。

Gall定律说，一个能够工作的复杂系统，总是从一个能够工作的简单系统演化而来。这也是我们从最小工作循环构建Multi-Agent系统的依据。

Hyrum定律说，只要用户足够多，每个可以观察到的行为都会有人依赖。XKCD里有人按空格键给电脑加热，现实中也有许多类似用法。你建立一项功能以后，很难把它收回。软件、研究工具和量化Scorecard都一样：系统可以继续沿依赖关系向上生长，却未必还能回到原处。

Amdahl定律与AutoResearch尤其相关。优化一个环节带来的整体加速，取决于该环节占总流程的比例。如果一个流程占总时间的50%，即使把它加速到无限快，整体最多加速两倍。

Amara定律说，人们会高估技术的短期影响，同时低估其长期影响。Agent进入真实系统后也会出现这种情况。模型进步的速度超过我们学习怎样使用它们的速度，这也叫Capability Overhang。

系统的前几个版本往往只带来有限改善，因为它还没有很好地接入现有流程，甚至没有得到解决问题所需的全部信息和配置。完成这些整合以后，效果可能很强。

引导Agent的四条工程定律

The Bitter Lesson：Scaling也要从简单任务开始

Lucas： 量化金融研究可以先把问题做得更像游戏。DeepMind从围棋开始，后来走到蛋白质折叠。围棋比国际象棋复杂，但它仍然具有一些方便条件：规则封闭、完美信息、没有骰子带来的随机性。研究人员逐步去掉这些方便条件，抽象游戏规则和搜索算法，最后让系统推广到非游戏领域。

量化金融也可以先做最基本的Backtest，甚至先允许Agent看到未来信息，检查它能否找到正确答案。它如果能做到，就减少一部分未来信息再试；仍然能够找到答案，就换到其他资产。

The Bitter Lesson认为，计算和数据规模最终会胜过人工技巧。不过，Scaling仍需要一个简单、可工作流程作为起点。先解决短、容易、可靠和稳健的任务，再逐步扩大范围。

从封闭系统逐步扩大任务范围

基础设施让严谨评估成为可能

Lucas： Jump能够扩大研究规模，是因为数据和研究背后有完整系统支持。我们保存了十五年以上的详细市场数据，包括各交易所的原始网络包；也有定制网络，并了解各个重要交易所之间光速传播所造成的时间差。

这些数据让我们按历史时点重建市场，定位Loren前面提到的信息泄漏。

Jump的市场数据基础设施

我们也用相同方式向研究Agent提供数据。各数据中心以及交易所附近的共址地点都有独立研究系统，可以回放捕获的数据。研究人员能够模拟不同的数据接收状态，逼近策略设计时假设的系统和最终执行时的真实系统。

内部技术栈包括定制计算网格以及大量基础设施，并与研究库、网络和交易系统集成。Point-in-time精度可以下沉到Packet Capture层面。

向研究Agent提供市场数据

在数日内构建交易信号

Jump的Agent设计原则

Lucas： Harness要根据任务设计。先保持简单，确有需要时再增加复杂度。系统若包含多个角色，就要写清每个角色的职责，并用Eval支持设计选择。

Eval具有时间属性。你需要检查Point-in-time正确性、每项信息的来源、Artifacts的评分方式和Scorecard的维度。

Multi-Agent流程要有边界。系统可以传递什么信息，决定了主要风险；系统内部结构本身并不决定风险。

建立AutoResearch以后，要开始“造盒子”：先做小型、可操控的版本，再提高通用性；把多个盒子连起来，减少Amdahl定律造成的局部上限，随后再向更通用的系统发展。

Q&A：

观众： Frontier Model很可能已经见过互联网上的大量历史资料。使用历史数据回测时，怎样保证Point-in-time正确性？

Lucas： 在模型训练截止日期以前，我们不可能排除所有泄漏，因为模型可能见过互联网上的一切。不过，我们可以测量泄漏的相对影响。

最安全的做法是完全样本外测试。选择知识截止日期较早的旧模型，只评估截止日期以后的数据。

量化研究可能需要五年甚至十年的Backtest，此时无法把全部数据放到训练截止日期以后。你需要让系统对泄漏保持稳健，并比较截止日期前后的曲线形态是否一致。做到这一点很难，但有时可以通过系统设计实现；这样历史评估仍然能提供依据。

观众： 上下文太多会造成污染。你们怎样拆分数据和管理Agent系统的Context？

Lucas： Orchestrator–Worker很适合这个场景。最聪明的模型负责形成最终答案，Subagent负责调用大部分工具。Multi-Agent系统可以同时承担专业化和Context隔离两项工作。

Context Management可以分层完成。很多工具从MCP转向CLI，其中一个原因是MCP要在System Prompt阶段加载；CLI可以像Skill一样渐进披露，也可以先让Agent调用Help。

工具与Subagent都可以保持窄范围。信息回到父Agent时，只保留它进行高层判断所需的关键内容。

观众： 这套方法更像“特征加模型”的领域框架。你们怎样比较它与Pretrain Everything？

Lucas： 追求最通用能力时，Pretrain Everything是合适方向。Frontier Lab需要思考怎样吸收整个人类的智能。我们可以选择一个范围更可控的任务：把Jump能够建设的能力与外部世界已经建设的能力组合起来，为量化研究提供最好的Pareto Frontier。

这种领域系统更容易做Post-training，也必须适配专有数据、知识产权和其他壁垒。整个系统还要随着外部模型、Harness以及模型输出融合方法一起升级。外部能力不断累积时，我们不应该每次重新设计全部系统。

观众： OpenAI等模型可能更偏向美国股票。你们怎样看Alignment和模型对不同地区市场的偏差？

Loren： 这正是我们建立自有Eval Case的原因。刚才选SpaceX，是因为它最近发生，适合举例。实际案例会覆盖美国、欧洲和亚洲资产。最后也可能发现，不同市场和任务需要不同模型。