↓Skip to main content

Optiver 的 Agentic SDLC：围绕 AI Agent 重新设计开发流程

·1 min

本文是对 Optiver 技术博客 Engineering the Agentic SDLC（2026-06-23）的阅读整理与延伸思考。Optiver 是全球顶级做市商，这篇文章记录了他们把 AI Agent 纳入交易系统开发流程的实验，压力测试场景是 HFT 工程里最"脏"的活之一：接入新交易所。

核心命题 #

不要把 Agent 塞进为人类设计的开发流程（SDLC）里去加速旧流程，而是从零开始围绕 Agent 重新设计开发生命周期。新前提是：Agent 承担大部分工作，人类负责引导和把关。由此几乎一切都要变——规格说明、工具链、代码评审、可观测性、甚至代码组织方式。

Optiver 的判断很清醒：具体工具未必长久，但底层约束比工具本身更耐久。

他们把这套体系拆成三层：

  1. SDLC 工作流：开发、评审、测试、发布、运维。
  2. Agent 原语：上下文（context）、执行环境（harness）。
  3. 共享底座：度量、执行、编排、治理。

压力测试：接入新交易所 #

测试场景选得很有代表性——交易所连接。每个交易所都需要一个会话管理组件（登录、心跳、与内部系统通信），工作重复但细节因场所而异，小的协议差异出错代价很高，而且每接一个新交易所都要重来一遍。

结果：上线时间缩短 75%，工程人力投入减少 85%，约 90% 的产出达到"可直接送审"质量。

早期尝试很粗糙：通用编码 Agent 只能做到一半——不理解组件、无法可靠驱动测试工具、看不到系统内部关键部分、无法判断自己的代码错了，于是用各种"变通方案"填坑，这些代码根本过不了评审。他们的关键发现是：大多数失败源于外围工作流的缺口，而不是模型本身。

四条核心经验 #

1. 黄金路径是工程出来的 #

想要端到端可用的 Agent 流水线，必须通过工程手段压低方差，不能靠运气。每一步要么是显而易见的下一步，要么被明确文档化为下一步——不能指望 Agent 自己悟出来。他们为此做了三件事：重写组件、去掉会变成运行时错误的静默默认值；收紧规格、让操作顺序无歧义；构建编排框架，让 Agent 分阶段推进、阶段之间设验证门、每阶段只注入当前相关的上下文。

2. 上下文决定结果 #

AGENTS.md 不是上下文的全部。Agent 需要三类上下文，缺任何一类都会产生不同的失败模式：

  • 系统上下文：组件做什么、约束是什么。
  • 领域上下文：外部环境实际如何表现——从真实流量中捕获。
  • 方法上下文：这类问题怎么解、怎么测、什么算好。

领域上下文最有意思：交易所文档只告诉你有哪些报文，不告诉你发出去之后会发生什么。让 Agent 能探测线上系统、捕获真实流量的工具，把 Agent 锚定在现实上，而不是锚定在推断上。做过交易所对接的人对这句话应该都有生理反应——文档和真实行为之间的 gap 才是工作量的大头。

3. 反压（Backpressure）降低方差 #

Agent 会在没成功的时候告诉你它成功了。解法是把"是否成功"的判定权从它手里拿走：用真实捕获流量构建应用测试；支持在非生产环境跑端到端场景、拿到干净的通过/失败信号；编排框架用代码验证每阶段交付物。

最终形态：Agent 在创造性部分（协议理解、实现、边界情况）自由发挥，在确定性部分（编译过没有、测试过没有、场景跑通没有）被严格约束。缺少反压，错误、bug 和坏设计会随着 Agent 独立工作不断复利放大。

4. 工具必须对 Agent 友好 #

大量内部工具默认"人坐在终端前"：交互式日志查看器、按 checkout 的配置、手工预约主机——对 Agent 全都不好使。他们开始重建工具，让 Agent 用简单的非交互命令驱动一切，并把 “Claude 不需要帮助就能用这个工具"作为硬性要求。副产品：对 Agent 好的工具（标准化配置、更少交互提示、pass/fail 场景命令）对人也更好。

下一步方向 #

  • 泛化模式：编排框架本来就按通用设计，推广到其他长周期、结构化的工程问题。
  • 投资底座：更好的评测（对比迭代效果）、隔离执行环境（更安全的实验）、治理（身份、审计、策略）——在不失控的前提下扩大自治。
  • 把人放进正确的环节：目标不是去掉人的判断，而是通过设计（而非偶然）把人的判断放到正确位置——架构评审、风险决策、全新领域。

我的延伸思考 #

这篇文章最值得反复读的是结语的那个判断：交易所连接项目暴露的约束与"代码生成"本身关系不大，结果质量高度依赖上下文、工具和验证，改进这三者与改进模型本身同等重要。Agent 只是系统的一部分，大量进展来自让外围工作流变得可测试、可验证。

从中可以提炼出两点对交易系统工程的启示：

  • 护城河在工程和验证体系，不在模型。模型能力是所有人共享的，而对交易所接入这类反复发生、出错代价高的工作，围绕它构建的上下文、工具和验证门是私有资产，收益按复利计算。
  • 判定权要留在确定性系统和人手里。Agent 会在没成功时宣称成功，所以"是否成功"必须由真实数据构建的测试和干净的 pass/fail 信号说了算；AI 只在创造环节自由，人则通过设计被放在架构评审和风险决策的位置上。

对个人开发者的启示也一样：与其反复换模型、调提示词，不如把力气花在让自己的工作流可验证——真实数据构建的测试、干净的 pass/fail 信号、以及"不需要帮助就能被 Agent 使用"的工具。