开场
我叫 Nayan，是 Optiver 的 AI 工程负责人。今天我想谈谈我们如何在盈亏直接攸关的情况下扩大 AI 的应用。那这到底意味着什么呢？
做市商的工作
先介绍一下背景，说说我们在 Optiver 做什么。我们是一家做市商，也是一家交易公司，用自己的资金交易，没有客户。从技术角度说，我们处理大量数据、构建模型，再据此做决策。这些决策必须以很高的性能运行：我们每天完成一千多万笔交易，为一百多万种金融工具定价，每天处理数拍字节的数据。
我们也是一家全球化程度很高的公司，在世界各地有十多个办公地点。这些特点会带来一些影响，接下来我会谈到。
反馈以小时计，而非季度
先看传统科技公司通常如何衡量收入：实施一项改动、向用户推出，用户使用几天、几周，然后收集参与度指标；再过几个月、几个季度，甚至几年，才看收入、客户终身价值等。我以前在 Apple 工作过，所以了解这种做法。
但在 Optiver，我们把改动部署给交易员和量化研究员后，几个小时内就能看到它对盈亏的影响。事实上，我们每天一开始基本会把资产负债表归零，到当天结束时再看赚了多少钱。这会影响我们如何决策、如何扩大 AI 应用，以及如何构建系统。
首先，反馈循环要直接得多：做出决策后，当天结束前就能开始看到影响。当然，我们交易的一些金融工具周期更长，长期还有更多价值有待发现；不过，某项举措的影响很快就会显现。另一方面，如果错失机会，机会成本可能很高。比如市场上发生特殊事件，假设 SpaceX 的 AI 业务 IPO，而我们错过了，那可能代价不小。
所以我们必须快速决策，并且高效、有效地衡量结果，也要倾向于采取行动。这意味着可做决策的价值上限和重要性都非常高。像 Spotify 这样的面向用户的服务，本质上是在争夺客户有限的注意力；而在交易中，交易越多，赚的钱也越多。因此，两者的经济逻辑有些不同。
平台原则
为了实现这些目标、按这种方式扩展和运营，我们围绕几项核心原则搭建了自己的 AI 平台。第一是快速行动，这一点前面已经说过。快速行动也需要模块化。AI 世界里每天都有新模型、新产品、新范式：以前做循环，现在做智能体群，再做图结构，等等。我们得能接纳这些变化。如果某种范式有价值，就把它衡量清楚；如果确实有效，就引进来。引进之后，我们就能开始获得更多价值。
要理解效果，我们必须在每一层都建立衡量能力。交易当然意味着大量回测；新模型发布时，外部基准能告诉我们它表现如何，但我们还得知道它在内部基准上的表现，因为我们的基准数据分布与外部可用的数据不同。
交易员很聪明，也很有主动性，所以我们希望平台具备很强的自助能力。不过，完全自助也可能变得混乱，因此还需要提供好的默认设置。我们采用的一种工作方式是嵌入式协作：AI 工程团队规模相当可观，我们会派团队成员和交易员坐在一起，了解他们如何交易，教他们 AI 如何创造更多价值，再把学到的东西带回平台。
大家都听过 OpenAI、Hugging Face 等公司的故事。随着我们越来越多地使用 AI，也必须确保安全。可以想象，如果智能体失控并在我们的技术栈里乱做事情，后果可能相当严重。不过我想强调，公司里的每个人都在使用 AI。每个人用法不同，但从根本上说，我们是一家非常“AI 原生”的公司。
当然，我们身处高度监管的行业，也非常重视知识产权，所以所有工作都在本地完成。我们有自己的本地 GPU 和本地基础设施等。真正需要向外部服务发起请求的，基本只有第三方模型推理；在这类情形下，我们会和相关公司签订零数据留存等协议。
AI 平台技术栈
这张图展示了我们的 AI 平台，信息很多，可能让人一时眼花。我不指望大家现在就全部看懂；想拍张照片、之后拿我开玩笑也随意。最后我会再放一次这张幻灯片。
我想强调的是，每一层技术栈都必须有人负责。底层既有第三方供应商提供的模型，也有我们自托管的模型和开源模型。推理网关负责在不同模型之间路由；我们可以衡量每种模型的开销、设置预算，稍后会具体讲。这也带来韧性：某个供应商宕机时，我们可以切换到别家。毕竟我们一旦停摆，基本就赚不到钱。
接下来是自己的智能体平台，智能体会注册技能、插件、工具等能力。每个使用智能体的团队都可以带入自己的知识和记忆系统。智能体网关像一套统一的台账，让公司里的所有智能体汇集、沟通和协同；它还能以类似的身份管理方式编排人和智能体。这也连接到大家听过的智能体群等概念。
最后，对我这个也做产品的人来说，很重要的一点是为用户提供合适的交互界面，让他们能使用智能体。平台再好，如果没人愿意用、喜欢用，或者知道怎么用，也就没有意义。
所以我们搭建了自己的网页界面，让大家访问各自的会话等内容。还有一个叫 Agent Workbench 的工具，本质上用于管理角色设定：各团队可以建立自己使用智能体的配置并分享。公司里每个人也都能使用个人助理。之后我还会回到这张图；有问题的话，活动结束后可以聊。
新一代前沿模型当天上线
那么，我们怎样落实这些原则？其中一条是：如果一款新的前沿模型公开可用，我们希望当天就能把它用到生产流程中，因为只要它确实有价值，这样做的价值就很大。但它到底有没有价值？我们要在内部黄金测试集上做基准评测。
这就要求我们有成熟的评估框架。我们会和关键的交易团队合作，收集他们的基准数据并接入系统。每当有新模型，我们就立即用这些新基准测试它，拿到指标后与公司同事分享，让大家判断它对我们的用例是否真的有价值。
除此之外，每出现一种新模型，通常还要把它接入网关，准备好相应 API 和接口，设置成本管理；新模型往往还需要更新 harness（运行框架），我们也负责管理这些更新和交付。
模型上线也意味着要承担相应责任。我们是一家全球公司，需要全天候支持。团队会在不同地区轮值，确保高可用。我想现场可能就有今天正在值班的同事。还有，跑完基准测试之后，我们也要让公司里的人知道：我们评估了这个模型、它的表现如何、怎么使用，以及我们的建议，并保持沟通渠道畅通。
不绑定模型与运行框架
另一点是，由于我们可以在不同模型之间灵活选择，只要某个模型能创造价值，我们就想把它接进来。我们也需要应对模型在不同地区或云供应商处的可用性差异。另外，一些工作负载必须运行在完全隔离的本地 DMZ 区域；这么做有成本方面的原因，也有隔离方面的原因。
因此，我们希望不绑定某个模型或 harness。第三方供应商模型和本地模型都经过我们的推理网关。我们会记录所有内容，每一次与模型的交互都会进入日志，并自动送入评估系统。
我们支持多种 harness，并在上面搭了一层 meta-harness，让各团队配置自己的使用体验，同时能在不同 harness 之间迁移。团队可以在这层定义自己的 harness 配置，并接入团队知识库。知识会随着时间自动积累；我们查看调用轨迹，再从中提取额外知识。
通过 meta-harness，团队可以在我们的平台上部署和管理智能体，也可以通过我前面提到的网页门户、IDE 界面来使用。我看到有些人在拍照，我稍等一下。
控制 AI 开支
这类图大家可能很熟悉。它大致展示了我们的 AI 开支变化，没有标具体数字。我们用 AI 做得越来越多。到了十二月，Claude Code 带来了一波增长。顺便说一下，这里的拐点正好是我加入公司的时候，所以我也不知道是不是和我有关。接着，夏季几款重要前沿模型发布后，开支明显飙升；后来我们在流程里加入一些优化，又把开支控制住了。
花得越多，我们能创造的价值也越多。我们有信心继续获得回报，但要确保钱花得明智。我们发现，自己有很多 MCP、知识库和信息；在一个全新会话里，有时默认上下文就达到 20 万 token，有时还更多。这太离谱了，因为大家把各种材料一股脑全塞进去了。这就是完全自助模式的问题之一：使用者也必须有投入和责任。
于是我们做了一系列改进：加入 MCP 工具搜索；让智能体可以不直接调用 MCP，而是使用一个封装多个 MCP 的 CLI，这样效率高得多。我们还研究缓存特性，例如缓存何时失效、参数应该设多久、是否要采用不同设置或动态设置。之后我们与各个团队合作，进一步优化他们的 harness。比如把一部分内容放进知识库，而不是堆进一个庞大的系统提示词。
这些改进的好处是，节省会随着 token 成本上升而放大：token 越贵，省下的钱越多。重点是，光把模型摆出来供人使用还不够。我还没谈模型路由、子智能体优化等工作；即使只看单次会话，也几乎总有尚未挖掘的价值，我们会非常积极地围绕这一点持续优化。
我们在图上这个时间点发布了优化方案，但实际还需要逐步推广。我们的技术栈在不同全球区域的发布方式有些特别。其他确实帮我们省钱的做法是：向大家公开各自花了多少，提供更多可见性和提醒，并让他们有权自行管理。结果大家做得相当不错。我们建了一个系统，让团队自行设置提醒和限额；许多团队都为自己设定了合理限额。
另一个办法是探索开源模型。有些开源模型的 token 成本很有竞争力，能和前沿模型相比。当然它们不一定适合所有用例，但我们找到了一些可以用它们替代、而且性价比不错的场景，也已在公司内部提供这些模型。使用的人越来越多。
还有模型路由。我们在探索不同方案，动态地把提示词发给更便宜的模型；或者先由更前沿的模型制定计划，再把具体执行拆分给较小的模型。最后，我认为知识库被低估了。它们非常重要，也能帮助控制开支：如果知识库做得好，只检索恰当数量的上下文，就能减少需要取回的内容。
长话短说，我们仍在大量使用 token、持续投入；关键在于从同样数量的 token 中获得更高的投资回报。
让工具贴合用户的工作方式
最后我想谈谈如何贴近用户的实际需求。几个月前，公司里很多人使用不同的 harness，各自搞出各种定制配置，把东西接到自己的开发机器上；有人还自己搭了些临时网页界面。于是我们想：既然这么多人都在做这些事，为什么不干脆做一个好用的版本，开放给公司所有人？我们后来确实这么做了。
在网页门户里，我们做了一个会话管理系统，可以开聊天窗口、查看各类产物。其他 harness 公司也有类似产品，但我们觉得自建方案更适合公司的基础设施，而且可以按自己想要的速度迭代。
现在，公司里不同的交易员也开始为这个系统贡献代码。他们发现某种能力对自己的工作流有价值，就提交一个拉取请求，我们把它更新进去。现在已经有协作文档编辑等功能。
我们还在把它发展成“智能体多人协作”模式：我可以把自己的会话放在里面，建立房间，把我的智能体、你的智能体以及其他已部署的智能体放在一起。这样大家能在同一个地方协作，效率更高。现在也有 Slack 客户端，所以在外出时也能使用。
我们的用户主动性很强。如果我们不做，他们就会自己动手做，所以我们干脆给他们造了个更好的版本。
这就是我们整体的做法：打造一个高度模块化的平台，并持续迭代。到目前为止，我们做得挺顺利。今天的演讲就到这里；如果大家对这些内容或其他方面有问题，我们可以聊。今晚还有交流活动，欢迎来我们的展位登记，会很好玩，还有很棒的奖品。
问答
是的，我们确实探索了不少不同方案。就我个人而言，现有方案没有一个让我满意，各有取舍。如果你问一些前沿实验室，他们的知识库怎么做，答案就是用很大的 Markdown 文件、分层 Markdown 文件等。这些办法在某些地方确实行得通，但向量搜索也有自己的优缺点。我们采用混合方案，方便探索不同选项。我个人希望我们多花些时间研究图数据库之类的东西，可能更有价值。我每天在 Twitter 上都能看到处理记忆和知识的新方法。这是我们还想投入更多时间解决的问题；我对现在的方案并不满意。
问得好：和 Codex 相比，手工构建方案能带来什么价值？有几个原因。一个不太令人兴奋的答案是，我们的东西都在自己的基础设施里，很多工具无法按我们希望的方式运行。直到最近，Codex 才开始支持在自己的基础设施上运行托管智能体等功能；他们现在开始提供这类能力，我们也一直在和他们合作。这是我们当初自己动手的原因之一。
第二，许多提供这类方案的地方也会试图让你绑定他们的模型，或者绑定其余整套解决方案。一旦走上这条路，如果基础设施过度依赖某个供应商，我们的速度就只能跟着对方走。我们以前用过的一家推理网关供应商就让我们遇到过这种情况：某项新功能出来，我们需要它，对方却说：“好，我们去和市场团队沟通，把你们排进路线图。”但等到那时，我们需要的其实是更快地行动。这也是一个原因。
最后，在其中一些领域，我们一直走在前面。和一些前沿实验室交流时，他们会请我们讲讲如何实现托管智能体能力等做法，不是我想自夸，但我们对自己的工程能力和路线图相当有信心。因此，这种方案也适合我们。当然，我不认为它对所有人都行得通；只是我们的情况有一组独特条件，让我们可以这么做。
好。能谈谈你的……
我想先确认一下自己是否理解了你的问题。你是问，我们把其余这些东西整合进评估和记忆时，有哪些最佳实践？
对。我们一开始做的是记录所有内容，就像前面说过的，每次工具调用、输入、输出等全部记录，算是全面日志记录，然后把这些送进评估系统。
我们发现的挑战——我会说这是一个尚未解决的问题——是如何评估工具调用。比如我们在 Slack 里运行一个支持机器人智能体，想评估它。如果把它换成另一个模型来运行会怎样？这个支持机器人用了一堆工具，而这些工具依赖运行当时的世界状态。要复现这一点就挺困难，这是很典型的问题。
我们一直在研究一些办法，例如……
问答（续）
……比如，能不能把这些工具所处的世界状态保存成快照？这要看具体系统。对于交易回测数据库很容易，可以直接定位到某个时间点；但 Slack 这样的系统就未必能还原评估当时的状态。也许能重放 Slack 的历史状态，但其他系统可能做不到。因此我们会对工具调用进行时间点还原的可信度评估并记录。重新评估时，会通过 MCP 代理尽量调用对应快照，但这并不完美。除了把所有东西都记录下来，我还不知道有什么完美办法。
好，那我们再来一个问题？
这是个我们确实碰到过好几次的经典问题。有个团队做了一个能帮他们编程和分析的智能体，范围限定在他们自己的代码仓库。接着就会想：如果我们和另一个团队合作，把他们那套东西也接进来会怎样？复杂度马上爆炸：现在智能体要检出多个权限配置各不相同的仓库，等等。这就是一个典型问题。
我们最初考虑的办法是：干脆做一个新智能体，把这些功能合并起来。但很多时候这会带来大量技术债，效果也很差。我认为我们现在的做法是给每个智能体做版本管理。如果只是在小幅增量上改动，就可以给智能体推送新版本、增加能力。
但往后，我们更希望大家利用智能体网关：与其让一个智能体身兼十种任务，不如让每个智能体专注于自己擅长的任务。这样更容易衡量，也更容易管理生命周期；其他智能体可以轻松与它协作，仿佛由它自己来处理。我们的架构允许智能体通过统一台账互相调用、启动彼此等。
这能让我们更有效地扩展这些功能，而不是把一个智能体不断塞得臃肿、什么都做。问题会变成多智能体编排，但我认为，保持可衡量性非常重要。把智能体做得太庞大，可能出现某些功能变好、另一些变差的情况，而且很难灵活调整。