Optiver用Agent重塑研发流程，效率提升显著

Golden paths aren't found, they're engineered. —— Optiver

当谈论 Agentic SDLC 时，研发流程应该被怎样重新设计？顺着 Optiver 给出的答案，也顺便聊一聊我们在落地 Spec-Driven 时的一些感悟。

Optiver 给出的命题

2026 年 6 月，Optiver 发布了一篇技术博客《Engineering the Agentic SDLC》。这家以交易闻名的公司，抛出了一个命题——传统 SDLC 默认“人在驾驶”，而 Agentic SDLC 假设 Agent 承担大部分执行工作，人负责引导与精修，这就需要 围绕 Agent 重新设计整个生命周期。

他们把这个思路凝练成一个三层模型：

• • 最上层是工作流，也就是我们熟悉的开发、评审、测试、上线、运维这些环节；
• • 中间一层是 Agent 的原语，讲的是 context 与 harness，即 Agent 的能力究竟从哪儿来；
• • 最底层是共享底座，度量、执行、编排、治理，这些东西让上面两层真正立得住。

为了验证这套想法，他们特意选了一个约束严苛、可重复、出错代价极大的真实任务——接入一个新交易所。

这项任务需要编写一套会话管理组件，处理登录、心跳以及与交易栈的通信。他们给出的效率数据相当亮眼：上市时间缩短 75%，工程投入减少 85%，将近九成的产出直接达到可评审的质量水平。

他们说，大多数失败来自周边工作流的缺口，而非模型本身。一个通用的 coding agent 只能走到一半——它读不懂组件、驱动不了测试工具、判断不出自己哪里出错，于是就用本不该通过评审的“方案”去填补空白。顺着这一观察，他们总结了四条经验：

• • 最佳实践是被工程化出来的：要降低不确定性，就必须用工程化方法找到最佳实践，没有运气成分。每一步要么是顺理成章的下一步，要么被显式文档化为下一步。
• • 上下文决定产出：AGENTS.md 并不是唯一的上下文，要想稳定地做出确定性工作，必须提供围绕完整问题陈述的上下文，而非零散片段。
• • 验证降低不确定性：缺乏验证会让错误、缺陷和糟糕的设计悄悄溜过去，还会放大 Agent 独立工作时犯的错。
• • 工具必须对 Agent 友好：大量工具是为人类构建的，对 Agent 并不好用。需要为人与 Agent 双向设计。

我们团队同样在落地基于智能体的软件研发流程，这篇博客的内容让我们很有共鸣。因为在金融技术领域，我们面临的正是同样约束严苛、出错代价高昂的工程现实。

我们的尝试

dev-kit 是我们团队从去年底开始自研的一套 Agentic SDLC 工具集。它以 Claude Code 的插件体系为运行底座，落地 Spec-Driven 研发模式。到目前为止，已推广至全部研发部门的多个项目中，代码采纳率在九成以上。

自去年底起，大模型的智能能力越过了某个奇点，处理长链路任务的成功率明显提升。早期代码补全的开发方式，便自然而然跃迁到覆盖研发全流程的智能体工程。于是，开发者从流程中的“执行者”角色被一步步剥离出来。

但这个过程并不像代码补全一样，只将AI当做一种工具，而涉及到研发全链路的重构。

架构分层

dev-kit 的技术架构自上而下分为五层：

用户指令进来，Command 层接住并触发功能，phase-router 将任务分发给对应的专家 Agent，Agent 调用 Skill 去执行，结果再沉淀到数据存储层。

最早，我们的设计借鉴的是AWS的kiro，之后也大量参考了superpowers。superpowers是Claude Code 生态中一套以“技能渐进式披露”著称的插件框架，主张把能力做成按需加载的 skill，而不是把所有知识塞进系统提示词。

dev-kit 落地了五个阶段：需求管理、方案设计、开发实施、测试，以及经验沉淀。这里的划分依据看似围绕角色，本质上仍是围绕任务的“上下文”。而在这些阶段之间，定义了明确的交付物，作为上下游任务交接的接口。

当然，借鉴只是起点。在落地过程中，最大工作量还在于将整套流程和企业自身研发场景的适配过程，包括企业特有的知识库、项目/架构/编码规范原则、环境与工具的调用等等。

四点感悟

在落地 dev-kit 的过程中，我们也有四点感悟，其中前两点与 Optiver 不谋而合。

感悟一：质量的关键是上下文

在 Agentic SDLC 里，质量的天花板是由上下文决定的。所谓上下文工程，核心关注的对象其实是信息。

信息可以按生命周期的长短分成两类。一类是长周期信息——架构原则、编码规范、需求基线，变动缓慢却决定产出的上下限，必须以企业、部门、项目三级分层管理好。这是组织投入最大、也最有价值的部分。

另一类是短周期信息，也就是任务级上下文，需要在工程落地时认真设计：针对任务特点，动态、渐进地注入结构化信息，讲究“不多不少、正正好”，这正是渐进式披露真正发挥作用的地方。

与其干等更强的模型，不如把长周期知识沉淀扎实、把短周期的注入做精细。

感悟二：在不确定性中寻找可控边界

第二个感悟是关于如何与一个概率系统共处：开发者要转向“引导概率模型”，学会在不确定性中找到可控的边界，并用 eval 做“动态行为评估”。

传统软件的规则是断言某个输出等于期望值，是对单个输出做精确判断；而 Agent 跑十次可能出十个结果，“正确”往往是一种统计性质而非一个固定字符串。于是规则退化为对一组输出的分布做判断。在这个新世界里，eval 是观测分布的传感器，可控边界就是 eval 定义的阈值。

可以把这套评估想象成一座五层金字塔，每层以不同的置信度和成本进行判定：

设计的核心原则是：越往下的层，代价越低。能下沉一层判定的，绝不放在更高层去做。

感悟三：人放在流程的什么位置

传统 SDLC 里，人是驾驶者，亲自写代码、测试、上线。Agentic SDLC 把人从执行链路中抽离出来，人的角色并没有消失，而是被推到 Agent 做不了的五件事上：意图的源头、高价值的判断、问责与信任、未言明的现实接地，以及脚手架的建造。

串起来看，人的边际价值正在从“生产的中间”（写代码），向“生产的两端”（上游意图 + 下游判断）和“元层”（建造脚手架）迁移，中间的执行层正在被掏空，这是质的变化。

在流程设计中，核心要考虑的就是“把人放在哪儿”。意图、规划、执行、评审、运维异常，到底选哪几个节点放人、用什么机制、同步还是异步、怎样防止人因惰性而失效。

感悟四：通过复利工程优化迭代

最后一个感悟是复利工程。在 dev-kit 目前的运行中，每当 Agent 产出一个 bad case，我们会由人来诊断问题出在哪里，再将修正后的知识写回知识库，或者把对应 skill 收紧、补强，避免同一个坑踩两次。

今天这条反馈链还是手动的，成本不低，也依赖人的判断。下一阶段的探索是 Loop Engineering——把这条反馈环本身也作为一等公民去工程化：让 bad case 被自动捕获、归因到正确的知识层，甚至让系统自提一条修正的 skill，再交由 eval 去验证这条回流是否真正抬高了通过率。

结语

Agentic SDLC 不是把 Agent 生硬地嵌入现有流程，而是用“驾驭工程”的方式对研发过程做彻底重塑，并以工程化手段探寻最佳实践。

每家公司的实际情况不同，适合自己的最佳实践路径也不尽相同。在智能化时代，需要去不断探索出属于自己的那条。

点击关注，共同进步

引用链接

[1] https://www.optiver.com/insights/technology-blog/engineering-the-agentic-sdlc

Golden paths aren't found, they're engineered.

查看原文 →