一家以交易闻名的高频交易公司，思考的不是「怎么用 AI 辅助写代码」，而是——如果 Agent 承担大部分开发工作，整个 SDLC 得重写吗？
2026 年 6 月，Optiver 发布了一篇技术博客《Engineering the Agentic SDLC》。这家总部位于阿姆斯特丹的顶级做市商，给出了一个出人意料的答案：几乎一切都得变。 规格、工具、审查、可观测性，甚至代码的组织方式——没有一个能逃过重新设计。
━━━ ━━━ ━━━
一个思想实验：连接新交易所
Optiver 选择了一个足够复杂、又足够有边界的场景来检验自己的假设：连接一个新交易所。
对交易公司来说，接入新交易所是一块「标准硬骨头」——需求清晰、约束明确、但细节繁多。交易所的文档会告诉你「存在哪些消息类型」，但不会告诉你「实际发过去会怎样」。
如果把这个任务交给 AI Agent，会发生什么？
Optiver 的结论是：能行，但需要围绕 Agent 重新设计整个流程。
━━━ ━━━ ━━━
三层架构：重新理解 Agentic SDLC
Optiver 用一个三分层框架来组织自己的 Agentic SDLC：
┌─────────────────────────────────────────┐ │ SDLC Workflows │ │ Dev → Review → Test → Rollout → Ops │ ├─────────────────────────────────────────┤ │ Agent Primitives │ │ Context Harness │ ├─────────────────────────────────────────┤ │ Shared Substrate │ │ Measurement Execution Orchestration │ │ Governance │ └─────────────────────────────────────────┘
第一层：SDLC 工作流
不再是传统的「人来写→人来审→人来测」，而是要重新定义每一个环节中人和 Agent 的分工：
- 开发：Agent 负责绝大部分编码，人提供引导和审核标准
- 审查：从逐行审阅变成架构和设计决策的评审
- 测试：测试本身变成 Agent 的反馈回路
- 部署与运维：尽可能通过「金路径」自动化
第二层：Agent 基元
这是最核心的两个概念：
Context（上下文）
Agent 需要三种上下文才能做出靠谱的决策：
- 系统上下文：这个组件干什么的？有什么约束？
- 领域上下文：外部环境实际表现如何？（从真实流量中捕获）
- 方法上下文：我们通常怎么解决这类问题？怎么测试？什么算「好」？
Optiver 发现，缺失任意一种上下文，都会产生不同的失效模式。其中领域上下文最有趣——交易所的官方文档只告诉你「可以发什么消息」，但不会告诉你「实际发出去会收到什么样的回复」。这种「口头知识」必须被显式编码到 Agent 的上下文中。
Harness（测试架/约束框架）
因为 Agent 写代码的速度远超人类审查的速度，传统的「写完让人审」流程完全不可行。Optiver 的解决方案是「Harness-first」：
- 每段 Agent 生成的代码都要通过一个机器可验证的测试框架
- 这个框架包含应用级测试和端到端验证
- 如果测试不通过，代码不被合并——不需要等人来审
*Harness 是唯一可扩展的质量保证方式。*
第三层：共享基础层
- Measurement：从编码速度到 Agent 生成代码的质量，一切可度量
- Execution：安全的、隔离的执行环境
- Orchestration：引导 Agent 分阶段执行，每个阶段带验证门控
- Governance：安全边界、审计追踪、人类在环的决策点
━━━ ━━━ ━━━
「金路径」：消除运气成分
Optiver 强调了另一个核心概念：Golden Paths（金路径）。
*\"金路径是被设计出来的。每一步要么是显然的，要么已经被显式文档化。不应该有运气的成分。\"*
在金路径模式下，Agent 的行为被高度引导——不是通过「提示词调优」，而是通过结构化的工作流和明确的验证门控。每一个步骤都提供足够的上下文信息和工具接口，让 Agent 的路径收敛到正确的方向上，而不是在广袤的可能性中随机搜索。
━━━ ━━━ ━━━
这与传统 AI 辅助开发有何不同？
最核心的区别在于默认假设：
| 维度 | 传统 AI 辅助 | Agentic SDLC |
|---|---|---|
| 谁在驾驶 | 人类（AI 偶尔协助） | Agent（人类引导与精修） |
| 规格 | 大致方向即可 | 需要更紧致的规格 |
| 工具接口 | GUI/IDE 插件 | 程序化接口 |
| 失败检测 | 人工 review 发现 | 自动化发现 |
| 审查重点 | 逐行审阅 | 架构与设计决策 |
| 可观测性 | 人的调试工具 | 同时是 Agent 的反馈回路 |
| 工具设计 | 为人类交互设计 | 为非交互式调用设计 |
━━━ ━━━ ━━━
更深层的挑战
Optiver 也坦诚地指出了这套思路面临的核心挑战：
「验证债」（Verification Debt）
Agent 生成代码的速度远超人类代码审查的速度。如果生成的代码没有被充分验证，债就会越积越多，最终无法偿还。Harness 机制是应对验证债的核心手段——保险丝，而不是防火墙。
「反压力」（Backpressure）
这个词很有意思。Optiver 认为，在 Agent 驱动的开发中，不能只靠「前置约束」来保证质量。还需要反压力机制——验证逻辑要能反过来约束 Agent 的行为边界。具体来说就是：让应用测试和端到端场景去否决 Agent 的输出，形成质量闭环。
Agent 生成代码的复杂性
如果 Agent 总是在已有代码基础上「追加」修改，代码结构会逐渐退化。这迫使团队重新思考代码的组织方式——让代码更容易被机器理解和修改，而不是更容易被人类阅读。
━━━ ━━━ ━━━
对行业的启示
Optiver 的这篇文章之所以值得认真对待，不只是因为提出了一个漂亮的框架，而是因为它来自一家有极强工程文化的交易公司。
高频交易行业对代码质量的要求近乎苛刻——任何 bug 都可能造成真金白银的损失。一个能让交易公司认真投入的 Agent 开发范式，意味着这个方向已经跨过「实验室玩具」的阶段。
Optiver 明确表示，他们正在：
- 把这个编排框架推广到其他结构化工程问题
- 投资更好的评估环境和隔离执行环境
- 确保人类始终保留在关键回路中——架构评审、风险评估和全新领域的判断
━━━ ━━━ ━━━
译者按
读过不少关于 AI Agent 开发的文章，但 Optiver 这篇给我的感觉不太一样。它不是在说「怎么调 prompt 让 Agent 写出更好的代码」，而是在思考一个更根本的问题：如果 Agent 写得比人快、比人多，我们的开发流程应该长什么样？
答案不是「让 Agent 更快地走我们的流程」，而是为 Agent 重新设计一个流程。
这个区别，是 Agentic SDLC 和「加个 AI 插件的传统 SDLC」之间最本质的差异。
*原文：Engineering the Agentic SDLC，Optiver Engineering Blog，June 23, 2026*
━━━ ━━━ ━━━
*本文完。欢迎关注 LeisureLinux，获取更多深度技术解读。*
AWS Kiro 深度解析：亚马逊的 Agentic IDE 如何重新定义软件开发？
核心架构冲突：Agentic AI 对传统安全栈的"降维打击"
拒绝玄学：Anthropic 官方 Agent 工程实战路径全解析
智能体 Agent 架构的"寒冬"还是"转正"？——从 Linux 哲学看 Agentic AI 的范式转移
