自进化 Agent 实现的 4 个层面

如果 AI 能像人一样,随着时间,经验,反馈不断学习,会发生什么?

我们现在常用的 Agent,不管是豆包,还是编程用的 Cursor,本质是还是一次性对话工程,你问一句,它答一句,或者执行完一堆任务,任务结束后不会成长。

如果能成长呢?这将会是不一样的世界。

这也是今年硅谷比较热门的方向。

为什么是这个方向:

  1. 人性,人天生懒惰,公司逐利
  2. 成本,自动化的 Agent 比 Chat AI 消耗的成本高出数个数量级,而自己进化的 Agent 所消耗的 token 又比一般的自动化的 agent 要高出多个数量级
  3. 上下文更长、模型更大、工具更多,这些路线都还有效,但边际收益已经没有前几年那么夸张。当其它维度进入瓶颈的时候,时间永远是可以考虑的重要维度

自我进化不是「长期记忆」,而是 Agent 依据自身交互情况、任务反馈或环境信号,对上下文、记忆、技能、工作流甚至模型参数进行持续更新。这些更新会直接干预未来的任务执行。

通过不断调整大模型和 harness 的边界,在静态世界里不断进化,模型能够能够越来越熟悉环境工具记忆等

任何演进路径都必须压在评估、版本、回滚、权限与供应链治理的基础之上。

自我进化用一句来讲,大概是这样:

真实任务里的经验,怎么变成下一次任务可复用、可验证、可治理的能力。

拆解一下,可以分为四层或者说四种可实现路径:

  1. 上下文进化:将执行经验、用户偏好或环境约束写回本地记忆文件、会话索引或技能目录,在下一次任务触发时通过检索提取并拼接入上下文。
  2. 技能进化:把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号,自动修改技能代码,在测试集中跑通后覆盖老版本,失败则触发版本回滚。
  3. 群体智能进化:多个 Agent、多台机器、多个用户的本地经验接入云端共享层。系统在服务端完成轨迹去重、冲突合并、安全脱敏与质量验证,最后将提纯后的技能或记忆分发回所有终端。
  4. 策略进化:将真实的交互轨迹与成败反馈收集起来,直接修改 Agent 的核心调度代码、工作流拓扑,甚至转化为强化学习(RL)的标量奖励来更新大模型的底层参数。

从工程落地的角度来说,上下文闭环和技能闭环是不错的起始点,也是能快速落地,快速带来结果的点。

这两层改动的基本都是文本资产,容易审计,且故障可控,回滚成本低。如果实现群体闭环或策略闭环,就会多出很多数据脱敏,权限控制等等问题。

上下文进化

上下文进化是指让 Agent 在自己的主循环里,将执行经验、用户偏好或环境约束写进以后还能用到的上下文资产。

典型的上下文资产包括:

  • 跨会话记忆
  • 会话检索
  • 用户画像
  • 项目级上下文
  • 技能目录的动态装载
  • 失败后的反思记录

优点:轻、快、容易落地。

缺点:如果底层模型本身不够强,光靠上下文很难突破上限;如果没有治理,错误经验会稳定污染后续行为。

以 Hermes Agent 为例,它将持久记忆(MEMORY.md / USER.md)、跨会话检索(SQLite + FTS5)和技能创建塞进同一个对话主循环。

工程实现上,Hermes 走的是一条贴紧主循环的轻量闭环。用户下发任务,Agent 经由消息网关调用终端工具。执行反馈与用户纠正产生分叉,一部分写入策展记忆,一部分沉淀为 Skills。当新任务到来,系统通过 session_search 将历史记忆与技能一并汇入下一轮上下文。

上下文进化解决的问题是Agent 的「金鱼记忆」与重复试错成本。在早期开发中,大模型每次新建会话都会丢失之前的上下文。昨天刚通过多轮对话教会它如何绕过内网的 SSL 证书校验,今天遇到同样的报错,它依然会从零开始盲目重试。上下文进化通过持久化存储(如 SQLite 配合 FTS5 全文检索),让 Agent 在行动前先查阅历史成功路径,直接跳过无效的探索阶段。

适用于单兵作战的个人助手、轻量级代码副驾、日常办公辅助。只要底层大模型的推理能力在线,且任务经验不需要跨团队、跨设备共享,这是投入产出比最高的一层。它不需要复杂的评测沙箱,几百行代码就能让单体 Agent 的可用性产生质变。

技能进化

上下文闭环再往前一步,就是把经验沉淀成可复用技能。

当经验开始重复出现,必须将其从松散的记忆层提升到结构化的技能层。把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号,自动修改技能代码,在测试集中跑通后覆盖老版本,失败则触发版本回滚。

在 Agent Skills 生态里,SKILL.md 充当了 Agent 的程序性记忆,定义了触发时机、执行脚本、环境约束和异常处理逻辑。

SKILL.md 这一类开放技能格式,是这波 Agent 工程里比较实用的中间层,它有如下的特点:

  • 比记忆更结构化
  • 比代码改动更轻
  • 比参数训练更便宜
  • 可迁移、可 diff、可版本化、可回滚

所以当我们发现某类经验开始重复出现,就不应该继续把它留在记忆层,而应该上升成技能资产。

Darwin Skill 把 SKILL.md 当作可评测、可回滚的资产。

Hermes Agent 的技能系统不是静态文档库,它允许 agent 自己创建、编辑、补丁、删文件、写附属文件。核心工具是 skill_manage。[skill_manager_tool.py]

Hermes Agent 的技能进化,并不完全依赖用户主动说「把这个存成技能」。

它有两层自动复盘机制。

第一层是 nudge。memory 按用户回合数触发,skills 按工具迭代次数触发。达到阈值以后,系统会在主任务完成后,后台 fork 一个 review agent,让它复查当前会话,看有没有东西值得落 memory 或 patch/create skill。[run_agent.py] run_agent.py#L2448-L2547 [run_agent.py] run_agent.py#L11586-L11612

第二层是 guidance。系统提示里直接写明:

  • 复杂任务、踩坑任务、发现可复用流程,要考虑存技能
  • 技能用着发现过时或不完整,要立刻 patch

它已经把「技能进化」从人工运营动作,拉进了 agent 自己的工作流。系统不再等人整理文档,而是把复盘变成运行时行为。

但这种触发还是偏软。nudge 只是提醒,review agent 还是模型自己判断。只靠提示词和后台复盘,技能库后面大概率会出现三类问题:

  • 有价值流程没被沉淀
  • 沉淀下来的技能版本缺少来源和上下文
  • 技能被 patch 多次以后,质量开始飘

技能进化解决的问题是纯文本记忆的非结构化缺陷。当任务复杂度上升,大模型在处理几万字的自然语言排错记录时极易丢失细节,甚至产生幻觉。复杂的业务需要确定的执行路径。人工维护这些包含几十个步骤的 SOP(标准作业程序)脚本成本极高,且极易因外部 API 的微小变动而全盘失效。技能进化将脆弱的静态脚本转化为能够依据报错信息自我修复的动态资产。

其适用于垂直领域的自动化流水线、运维巡检、复杂数据清洗。当业务要求 Agent 严格遵循既定流程操作,且操作环境(如第三方接口、依赖库版本)会频繁发生变化时,技能进化是维持系统长期稳定运行的唯一解。

群体智能进化

当你有多个 Agent、多台机器、多个用户时,单机技能闭环就不够了。

因为最大浪费会变成另一件事:
同一个坑被不同实例反复踩。

这时候我们就需要一个共享层,把个人经验抽出来,变成全体可复用资产。

这就是群体闭环要解决的问题。

它的收益大,但治理也复杂。因为共享意味着:

  • 权限问题
  • 隐私问题
  • 脱敏问题
  • 质量门控问题

等等

Ultron 将散落在各次会话里的经验蒸馏成群体知识,提供 Memory Hub、Skill Hub 和 Harness Hub。

Memory Hub 实现了 HOT / WARM / COLD 分层存储。系统根据命中次数进行再平衡,引入时间指数热度衰减公式 hotness = exp(-α × days)。未经衰减处理的记忆库是一场灾难,Agent 会频繁召回半年前已经废弃的内部 API 规范。

数据入库前,系统通过 Presidio 进行中英 PII(个人身份信息)检测与脱敏。这是企业级落地的底线。一旦某个 Agent 将包含真实客户手机号的排错日志写入群体记忆,整个系统的合规风险将彻底失控。

Skill Hub 负责将进入 HOT 层的记忆结晶为多步工作流技能。Harness Hub 则将人设、记忆、技能打包为蓝图,支持一键导入。这种设计抹平了多实例部署的知识水位差。

其主要解决的问题是规模化部署下的经验孤岛。如果团队里有 50 个开发人员,每个人的 Agent 都在本地独立摸索公司内部 CI/CD 系统的某一个奇葩报错,相当于团队为同一个坑支付了 50 遍大模型的 API 账单。群体智能进化打破了实例之间的物理隔离,让一个 Agent 踩过的坑成为全团队的免疫抗体,抹平多实例部署的知识水位差。

其适用场景于企业级 Agent 矩阵、跨部门研发协同、大型内部工具链。团队规模越大,这层进化的网络效应越明显。前提是必须在共享层前置严苛的 PII(个人身份信息)脱敏与恶意 Prompt 注入拦截机制,防止单一终端的脏数据污染全局技能库。

策略进化

再往下走,就是最重的一层:让系统直接改策略本身。

这里的策略可能是:

  • 代码
  • 工作流拓扑
  • 模型参数
  • 策略网络
  • 推理路径分配

这层能力上限很高,也很危险。因为一旦我们把真实用户反馈接进训练或策略更新链路,很多以前可以拖着不管的问题会立刻变成硬约束:

  • 数据许可
  • 脱敏
  • 训练延迟
  • 奖励劫持
  • 评测作弊
  • 安全回滚
  • 服务与训练解耦

将真实的交互轨迹与成败反馈收集起来,直接修改 Agent 的核心调度代码、工作流拓扑,甚至转化为强化学习(RL)的标量奖励来更新大模型的底层参数。

其主要解决的问题是基座模型能力天花板的绝对限制。无论是追加记忆还是改写技能,本质上都在做外挂。当遇到模型根本无法理解的深层逻辑或极度复杂的推理链条时,外挂方案会全线崩溃。策略进化直接向底层动刀,利用在线交互产生的真实反馈信号(如代码是否编译通过、测试用例是否全绿)来微调模型权重或重构 Agent 的执行逻辑。

主要适用场景是拥有充足算力预算的 AI 基础设施团队、需要将开源模型逼出闭源模型效果的核心业务。这一层工程风险极大。任务必须具备极度清晰、可自动化判别的反馈信号(如数学定理证明、代码生成)。如果反馈信号存在噪声,模型会迅速在错误的梯度中崩溃,产生严重的奖励作弊(Reward Hacking)现象。

核心工程挑战

上面讲了四层进化,但是要落地自进化系统,必须跨越四道工程天堑。

评估器比生成器更重要。没有评估器的自动修改,只是在自动制造生产事故。Darwin Skill 的棘轮、Ultron 的升级门控、OpenClaw-RL 的 PRM,都在解决同一个问题:证明改动没有让系统变坏。评估器的算力消耗通常是生成器的三倍以上。

可回滚是自进化的基础设施。技能层的优势在于天然支持版本化。参数层的更新回滚成本极高。工程实践的逻辑是:能在记忆层解决的异常,绝不改写技能;能在技能层修补的逻辑,绝不修改代码;能在代码层绕过的缺陷,绝不在线更新权重。

共享经验需要严苛治理。群体智能闭环的引入,意味着污染风险的全局放大。一个包含 rm -rf / 的错误技能一旦进入共享库,会摧毁整个团队的开发环境。权限分层、PII 脱敏、候选验证和版本审计,是系统上线的强制前置条件。

技能供应链安全无法事后补救。Agent Skills 已经演变为跨生态的能力封装格式。它包含脚本、远程依赖和执行指令。技能市场必须审查其是否读取敏感路径、是否执行危险命令、是否下载未知来源的 Shell 脚本。沙箱隔离和系统调用拦截必须做在宿主的最底层。

当前可落地执行的路线,不要一步到位堆砌在线 RL。可分阶段实施:

第一阶段,夯实上下文治理。让 Agent 具备最基本的成长能力:记录偏好、总结失败、检索历史。重点是让项目上下文和工具状态形成稳定机制,控制上下文窗口的 Token 消耗。

第二阶段,跑通技能资产沉淀。当排错经验重复出现,将其提取为 SKILL.md。引入类似 Darwin Skill 的测试集与评估机制。这是当前投入产出比最高的一步,能够立竿见影地降低 API 调用成本。

第三阶段,建设跨端群体智能。部署共享存储与演化服务,实现多终端经验的去重、验证与分发。在这个阶段,投入 50% 的研发精力解决隐私脱敏与权限审计问题。

第四阶段,谨慎切入参数与工作流修改。只有当你的 PRM 准确率达到生产可用级别,沙箱隔离足够坚固,版本回滚延迟降到秒级时,才去触碰在线强化学习。

自进化 Agent 的核心壁垒,从来不是模型本身有多聪明,而是底层的评估、沙箱、治理和安全机制有多扎实。

以上。

AI Coding 时代如何有效度量研发效能

在 AI Coding 时代,当我们说提升效能 50%,从老板的角度,那应该要干掉 50% 的人。

但又不能真这么干,这是一个简单的财务逻辑,也是一种本能的反应。

但研发又不是完全标准化的流水线。AI 在各环节都有提速,但对于需求理解的一致性,线上兜底,发布治理这些环节没法完全同步提速。

人是可以砍,但最终系统脆弱性、技术债务和交付风险一起放大。

以 AWS 为例,公众知道的类似线上故障发生不止两次了。

并且在一些大的公司,也出现了开发人员不知道自己写的是什么的情况,对于大公司一套巨大的工程体系,如果是一个完全的黑盒,没有人知道里面发生了什么,出现大的问题只是迟早的事情。

聊远了点,回到今天的主题,如何有效的度量研发效能。

当我们用上 AI Coding 之后,在上面所说的整体提效的逻辑中,我们需要细化这个效能的度量逻辑。

同样规模的团队,能不能交付更多有效价值,能不能把交付周期压短,能不能在不明显增加事故和历史债务的前提下,把过去做不到的事情做起来。

从指标的逻辑来看,DevOps 里那套大家已经很熟的「四个指标」——部署频率、交付周期、变更失败率、平均恢复时间依然是很能打的一组指标。尤其是 TTM,也就是从需求进入系统到真正产生用户价值的时间,还是王牌指标。

AI 时代,研发效能的核心指标体系要刷新,但不能推倒重来。

整个度量的逻辑不仅仅在于指标,同时也在于到底把指标绑在什么对象上,怎么解释,怎么防止它们被 AI 放大之后失真。

度量谁

一个问题,AI 产出要不要单独度量?

建议是:可以记录,不要单独考核。

因为 AI 没有责任主体。它不会背 SLA,不会参加事故复盘,也不会在需求失败时承担后果。

如果我们把「AI 生成代码占比」或者「AI 采纳率」当核心 KPI,很快就会把团队带进一个很熟悉的坑:为了优化指标而优化行为,最后牺牲真实交付质量。

研发效能度量一定要有清晰主体。这个主体通常有三层:

  • 工程师个体
  • 团队
  • 价值流或产品线

在 AI 时代,我更建议把主分析单位放在团队和价值流,但个体数据也需要通晒,人与人还是需要比较,并且人的实际使用情况也需要观测和度量。

说到个体度量,可能会有人觉得开始卷了,回到了粗暴管理

我觉得个体数据要看,并且要公开到一定程度。否则团队里谁在真正把 AI 用进生产,谁还停留在传统写法,谁能稳定地产出高质量变更,谁在用 AI 快速制造垃圾代码,管理层根本看不见,辅导也无从下手。问题从来不在于能不能比较,问题在于拿什么比较,以及比较之后准备用它干什么。

可以把「个体可观测」和「个体直接考核」分开。前者要做细,后者要克制。个体层的数据主要解决三类问题:第一,识别使用差异。第二,识别能力短板。第三,识别风险人群。比如有的人 AI 使用频率很高,但交付周期没有改善,返工率还在上升,这通常不是工具问题,是任务拆解、约束描述、结果校验出了问题。还有一种人,表面上 AI 使用不多,但需求稳定、事故极少、关键模块掌控力强,这类人往往承担了大量隐性复杂度,单纯看「人均产出量」会被严重低估。

所以个体层该看的,不是「生成了多少」,而是「借助 AI 之后,个人交付行为发生了什么变化」。可以重点盯几组数据:需求从领取到合并的中位时长、PR 平均大小、评审往返次数、回退率、线上问题关联率、测试补充情况、跨模块变更占比、AI 建议采纳后的修改幅度。这里面真正有价值的,不是某个数字本身,而是前后变化和人与人之间的分布差异。一个人 AI 采纳率高,不说明他强;采纳率高、评审一次过、上线后稳定,这才说明工具真的转化成了产能。反过来,另一个人采纳率也高,但 PR 越来越大、review 来回打架、上线后热修频繁,这种数据就已经在报警了。

个体数据为什么要通晒?

团队协作里,很多能力本来就是相对的。谁的需求吞吐稳定,谁总能把复杂变更压在可控范围里,谁的变更老是把测试链路打爆,谁对 AI 的依赖已经超过了校验能力,这些不能永远藏在「一团和气」后面。通晒的价值是建立真实参照系。工程团队里最怕的一种状态,是大家都觉得自己做得差不多,实际上产出质量、稳定性、问题密度差了一倍以上。数据如果不拉平,组织就只剩印象管理。

当然,个体通晒有前提。第一,口径必须统一。第二,不能只晒单一指标。第三,必须配上下文。比如一个人长期负责遗留系统改造,变更失败率高一点、交付周期长一点,很正常;另一个人长期做边缘功能,吞吐高也不稀奇。脱离任务难度做横向比较,最后一定会逼着大家抢简单活。我的经验是,个体层至少要把任务类型、系统风险等级、需求大小这几个维度一起带上。不然表面上是在做精细化管理,实际上是在奖励投机。

团队层和价值流层还是主轴,因为真正的交付结果最终只能在这两层闭环。一个工程师再强,也没法单独决定发布窗口、联调效率、测试环境、跨团队依赖和灰度策略。AI 时代尤其如此。代码写快以后,瓶颈更容易从个体编码能力转移到团队协作和系统机制上。所以如果一个团队整体 TTM 没降、变更失败率在升、MTTR 也没有改善,那就算团队里有几个人个体数据很亮眼,也不能说明这个组织真的变快了。很多管理者容易被「明星工程师 + AI」的局部高产迷惑,这是很危险的。效能度量最终看的是系统,不是看谁在局部冲得猛。

价值流这一层更关键,因为它决定了管理层看到的是局部繁荣,还是真实效率。一个需求从业务提出到用户可用,中间穿过产品、研发、测试、运维、合规、数据、客服,任何一个环节卡住,前面所有 AI 提速都白搭。很多团队以为自己效能不差,问题出在开发不够快;把价值流拉直一看,开发可能只占整个周期的 20%。剩下 80% 都耗在等待、确认、返工和协调上。这个时候你还在研究个人 AI 采纳率有没有上去,说实话,方向已经偏了。

所以,三层都要度量,但角色不同。

  • 个体层,解决的是识别差异、暴露问题、推动辅导。
  • 团队层,解决的是交付责任和工程能力。
  • 价值流层,解决的是端到端效率和组织瓶颈。

如果非要再说得更落地一点,可以这样处理:

  • 个体层数据全量采集,有限通晒,谨慎用于绩效
  • 团队层数据作为正式经营指标,进入月度复盘
  • 价值流层数据进入管理层决策,用来推动跨部门改造

这里还有一个问题:AI 使用情况本身,确实会逐渐演化成个体能力差异的一部分。今天还可以说是工具习惯差异,再过一段时间,它会越来越接近工程生产方式差异。有人能用 AI 快速完成问题拆解、方案比选、代码生成、测试补全、文档整理,再自己完成严格校验;有人只是把 AI 当高级补全,甚至生成什么就提交什么。两者的产出质量和成长速度,一定会拉开。这个差异如果不观测,组织是在主动放弃识别新能力结构的机会。

还是那句话,观测不等于迷信,比较不等于唯排名论。个体层数据要服务于两件事:培养更强的人,提前发现风险。它不能把团队带回那种老派的、只会按数字压人的管理习惯。因为 AI 时代最不缺的,就是表面上很漂亮的数字。真正缺的,是能把这些数字放回具体工程语境里解释清楚的人。

量结果

我一直不太赞成把研发效能拆成「过程指标 vs 结果指标」两个完全对立的东西。工程里没这么清楚。很多大家嘴里的结果指标,实际上掺了很多过程含义。代码行数就是典型例子。

很多人说 LOC 已经过时,这话只说了一半。更准确一点:LOC 从来就不是好的一线效能指标,在 AI 时代更差。

原因有三个。

  • 生成成本塌了:过去一个人写 500 行和写 50 行,投入成本通常不同。现在 AI 补全、生成、重构、搬迁代码,几分钟就能吐出成百上千行。代码行数和人类投入的相关性被打穿了。
  • 噪音变大:AI 很容易生成「看起来很完整」的实现:参数校验、日志、适配层、重复样板、冗余抽象全都给你带上。LOC 涨得飞快,但业务价值未必增加。
  • 债务被掩盖:最麻烦的是第三点。AI 会让代码库存增长速度明显快于架构治理速度。表面上看,产出变高了;往后看,维护成本、理解成本、回归成本都在涨。LOC 会把这个问题盖住。

所以代码行数其实没有啥意义,只当成代码影响范围的辅助信号,别当产出指标。

那真正该量什么结果?

可以分三类。

交付结果

这是最基础的一层:

  • 需求交付数量
  • 需求交付周期
  • 按期上线率
  • 有效发布次数
  • 版本回退率

这里要提醒一下:上线需求数也很容易失真。
因为需求切得越碎,上线数越好看;但碎到一定程度,用户感知价值可能没有提升,反而多了协调成本。

所以需求数量一定要配合需求粒度标准化。最少要把需求分成几类:小修复、小功能、中型功能、跨系统项目、技术治理项。不同类型分开统计,不然一张表里什么都看不出来。

业务结果

如果团队做的是业务研发,最终还是得往用户影响上落。常见的:

  • 某类功能从提出到用户可用的时间
  • 用户覆盖范围
  • 功能使用率
  • 转化率变化
  • 关键漏斗改善
  • 客诉下降
  • 线上稳定性对收入的影响

很多技术管理者不敢碰业务指标,怕研发背锅。我反而觉得该看,但不要简单归因。业务结果可以做关联分析,不要粗暴做责任归因。比如某个推荐功能两周上线了,但实验效果一般,这不等于研发效能差。研发效能差,应该体现在 TTM 过长、试验成本过高、回滚困难、迭代慢,而不是实验结论本身不好。

工程结果

如果团队做的是平台、基建、中间件、工具链,不能硬套 GMV、转化率这种业务指标。这个场景下我更看这些:

  • 接入团队数
  • 接入周期
  • 平台能力调用成功率
  • 构建时长变化
  • 测试时长变化
  • 故障发现提前量
  • 资源成本变化
  • 事故数和事故影响面
  • 研发人均可支撑服务数

基建团队最吃亏的一点,是价值释放往往滞后,而且分散在别人的效率提升里。如果你只盯上线需求数,这类团队会被系统性低估。

TTM 还是核心指标

如果只能保留一个指标,我还是会选 TTM。

这里说的 TTM,不是立项到上线的日历时间,而是价值从进入研发系统到到达用户手里的有效时间。很多公司嘴上讲敏捷,实际上量的是开发开始到提测结束,这根本不是 TTM。

为什么 TTM 在 AI 时代更重要?

因为 AI 最直接改变的,就是局部生产速度。代码写快了,单测补得快了,文档初稿也快了。问题是,这些加速会不会真的传导到业务价值交付,完全不确定。

我见过最典型的一种情况:

  • 开发编码时间下降 40%
  • PR 数量上涨 2 倍
  • 评审负担上涨 60%
  • 测试回归时长上涨 35%
  • 发布前冻结窗口变长
  • 最终需求上线周期几乎没变

如果你只看编码侧的数据,会得出一个完全错误的结论:AI 大幅提升了效能。
如果你看 TTM,问题一下就暴露了:加速发生在局部,瓶颈转移到了下游。

所以 TTM 的价值就在这里。它不关心你用了什么先进工具,它只看最终有没有把价值更快交出去。

TTM 怎么拆

TTM 不能只看一个总时长,否则只能看热闹。要拆段看:

  • 需求澄清耗时
  • 方案设计耗时
  • 开发耗时
  • 评审耗时
  • 测试耗时
  • 等待发布耗时
  • 灰度验证耗时

拆完之后,你才知道 AI 真正帮到了哪一段,堵在了哪一段。

另外,在 AI 时代,这种拆段是否合理,是否可以合并不同阶段或角色,让一些信息的流转内化为个人的思考逻辑,实现端到端的 AI 化。

比如,产品经理直接从需求到前端代码的实现。

看分布,不看均值

TTM 最忌讳只看平均值。平均值非常会骗人。正确看法至少要有:

  • P50
  • P75
  • P90
  • 超过阈值的长尾需求占比

因为 AI 往往会优先优化简单需求。这样 P50 可能很好看,P90 反而更差。原因也简单,简单需求被快速吞掉之后,系统里剩下的都是复杂需求、遗留系统改造、跨域联动项目,长尾会更长。

如果你只看均值,会误判整个系统在变快。

四个指标

DevOps 四指标在今天依然能打,但口径需要有一些升级。

部署频率

部署频率比 LOC 强太多。因为它至少是靠近真实交付动作的。代码写了多少行没人关心,真正有意义的是你有没有把变更安全地推到生产环境。

但部署频率也不能裸看。

高频不等于高效

AI 上来之后,一个常见变化就是团队更愿意切小 PR,发小版本。这个方向本身没问题,小批量交付通常更安全。问题在于,有些团队把一个正常需求拆成大量低价值、低独立性的碎发布,频率上去了,用户价值没上去,测试和发布成本反而更高。

所以我一般会同时看三个维度:

  • 单位时间部署次数
  • 每次部署的有效变更量
  • 每次部署的独立可验证价值

没有后两项约束,部署频率很容易变成表演数据。

适用场景不同

业务团队和基建团队的部署频率口径也不能完全一样。

业务团队可以看:

  • 每周或每日生产发布次数
  • 灰度发布次数
  • 从功能完成到触达用户的次数

基建团队更适合看:

  • 核心服务变更发布频率
  • 非工作时段紧急发布占比
  • 配置变更自动化发布比例
  • 平台工具链版本迭代频率

基建团队很多时候更强调稳定和兼容,追求极端高频未必合理。比如数据库、中间件、网关这类系统,频率太高反而可能说明变更管理有问题。

交付周期

交付周期本质上是 TTM 在工程流水线里的展开版。通常从代码提交到生产运行,也有人从需求进入开发开始统计。具体口径可以按团队定,但必须固定。

AI 时代交付周期最容易出现两个假象。

  • 提交变快了,交付没变快: 这是前面说的局部提速问题。AI 让提交更快,但后续验证没跟上,周期不会实质下降。
  • PR 变多了,周期看起来更短:如果团队把一个需求拆成多个极小 PR,每个 PR 周期都很短,报表会很好看。但从需求视角看,整体仍然很慢。所以我建议同时维护两套口径:一个是 PR 级交付周期,另一个是需求级交付周期。PR 级用于观察工程流水线摩擦,需求级用于看真实业务交付。只看其中一个,都会失真。

变更失败率

这个指标在 AI 时代的重要性实际上上升了。

因为生成式编码提高了变更速度,也提高了「错误以正确形式出现」的概率。以前很多错误是写不出来,现在是能很快写出一个逻辑闭环、风格统一、还能过部分测试的错误实现。它更隐蔽,也更容易通过表面检查。

可以把变更失败率定义得更工程化一点,至少包含这些事件:

  • 发布后触发回滚
  • 发布后引发 Sev 事故
  • 发布后触发热点修复
  • 发布后造成核心指标异常
  • 发布后引起客户可感知故障

如果定义太窄,只算重大事故,这个指标会钝化。定义太宽,又会把正常试错算进去。团队需要自己定边界,但边界一旦定了就别频繁改。

AI 对失败率的影响机制

这里有几个常见来源:

  • 生成代码对边界条件覆盖不足
  • 引入不必要抽象,增加理解偏差
  • 与历史代码风格和隐式约束不一致
  • 测试代码同样由 AI 生成,出现「同源缺陷」
  • 变更面比工程师主观预期更大

我自己比较警惕第四点。很多团队现在喜欢让 AI 顺手补测试,看起来很完整。但如果实现和测试都建立在同一段错误理解上,测试通过并不能证明正确。

所以在高风险变更里,测试不能只依赖生成。关键路径一定要有人做反例设计。

平均恢复时间

很多团队对 MTTR 的重视程度不够,尤其是业务团队。实际上,AI 时代恢复能力的重要性在上升。

当代码生成速度变快,进入生产环境的变更更多、更碎、更频繁,系统面对故障的概率和复杂度都在变化。你不一定能把每次变更都做得完美,但你必须能快速止血。

MTTR 的价值在于衡量团队是否真正具备工程韧性。这个指标背后对应的是一整套能力:

  • 监控和告警是否有效
  • 变更是否可追踪
  • 是否支持快速回滚
  • 灰度和开关能力是否完善
  • 值班机制是否靠谱
  • 故障定位信息是否充分

很多团队前面三个指标都好看,MTTR 很差。这样的系统经不起规模化 AI 变更。因为一旦出事,恢复慢会把前面所有频率和周期优势全吃掉。

历史债务

AI Coding 真正会在一年后把团队拉开差距,这里的差距在于谁更早处理历史债务。

这个问题现在还没有被足够重视。但是实际中已经越来越严重了。

因为短期内 AI 会制造一种繁荣感:交付更快,PR 更多,需求吞吐上升。可如果代码库质量、模块边界、测试资产、文档一致性没有同步改善,债务会以更快速度积累。

AI 会怎样放大债务

几个很典型的模式。

  • 重复实现增多:工程师直接让 AI 在局部上下文里生成功能,很容易绕过现有抽象和公共能力。短期最省事,长期就是重复轮子到处长。
  • 中间层膨胀:AI 很擅长生成 adapter、wrapper、facade 这类看起来规整的中间层。问题是很多层根本没有必要,只是为了让局部代码更顺。半年后系统会变得非常厚,排障和重构都很痛苦。
  • 测试资产劣化:生成测试很快,真正有效的测试不快。团队如果只追求覆盖率,很快就会积累大量低价值测试:断言脆弱、依赖实现细节、执行慢、维护成本高。最后 CI 时间越来越长,大家开始跳过测试。
  • 文档与实现漂移更快:AI 可以快速生成设计说明、变更记录、接口文档初稿。但只要流程里没有强约束,这些文档过几周就过时。文档数量增加,不代表知识管理更好。
  • 债务怎么量:技术债务很难精确,但不代表不能量。至少看四组信号:

    • 重复代码比例或重复能力点数量
    • 关键模块复杂度变化
    • 测试执行时长与稳定性
    • 历史模块变更失败率和恢复时长

指标落地

说一堆指标,如果最后只是做一张月报,那基本没用。研发效能度量要落地,大概可以看三点:统一口径、自动采集、和决策绑定。

统一口径

很多团队最大的问题不是没数据,是每个人嘴里同一个词代表不同意思。

比如「交付周期」,有人从排期开始算,有人从开始开发算,有人从代码提交算。你拿这三种数据做横向比较,结论一定错。

所以第一件事就是给每个指标下工程定义:

  • 起点是什么
  • 终点是什么
  • 谁负责标记状态
  • 异常情况怎么处理
  • 统计周期是什么
  • 看均值还是分位数

这一步很枯燥,但躲不过去。没有口径统一,报表越华丽越危险。

自动采集

凡是靠人手填的效能数据,最后都会漂。

我建议优先从这些系统自动取数:

  • 需求系统
  • Git 仓库
  • CI/CD 平台
  • 测试平台
  • 线上监控与事故系统
  • 发布平台
  • 值班和告警系统

AI 时代还可以补一些辅助数据,比如:

  • AI 建议采纳率
  • AI 生成代码在最终提交中的占比
  • AI 相关变更的回退率
  • AI 生成测试的失败分布

但这些只建议做诊断维度,不建议直接进核心看板。

和决策绑定

指标如果不进入真实决策流程,就只会变成汇报材料。

可以把不同指标绑定到不同节奏:

周维度

团队看流水线摩擦:

  • PR 周期
  • 构建失败率
  • 测试时长
  • 发布次数
  • 热修次数

月维度

管理者看交付和稳定性:

  • TTM 分布
  • 部署频率
  • 变更失败率
  • MTTR
  • 技术债务信号

季度维度

看结构性问题:

  • 跨团队依赖导致的等待占比
  • 核心系统复杂度变化
  • 自动化覆盖关键路径的比例
  • 平台能力复用率
  • 人均支撑规模变化

只有当指标驱动了人力投入、架构治理、流程调整,度量才算产生价值。

常见误区

  • 误区一: 拿 AI 使用量替代研发效能。 比如:人均每天调用 AI 多少次,AI 生成了多少代码,采纳率多少,这些数据可以看工具渗透率,不能代表团队变快了,更不能代表交付变好了。高采纳率有时候只是因为团队在写更多样板代码。
  • 误区二:把效能问题当管理问题。 一看到周期长,就加日报、加审批、加同步会。这个思路在 AI 时代更危险,因为编码加速之后,组织摩擦会成为主要瓶颈。继续加管理动作,只会让非编码时间更长。效能最后还是要回到工程根上:架构边界、测试自动化、环境一致性、发布能力、可观测性、模块治理。
  • 误区三:把所有团队放在一套指标下排序。业务、基建、平台、安全、数据团队的工作性质差异很大。统一看板可以有,统一排名很容易把组织带偏。
  • 误区四:只看短期提速,不看长期维护成本。 AI 最容易制造的错觉就是这个月吞吐上涨了,于是大家默认效能提升。可如果未来三个月回归变慢、故障变多、重构困难,这个月的漂亮报表只是透支。
  • 误区五:只看平均值。平均值会把长尾、异常、结构性阻塞全部抹平。工程管理里,很多真正该解决的问题都藏在 P90 之后。

最后

研发效能从来不是一个分数问题,它是一个约束系统问题。得回答下面的问题:

  • 价值有没有更快交出去
  • 变更是不是足够安全
  • 出问题能不能快速恢复
  • 现在的速度有没有透支未来

这四件事里,TTM 仍然是排第一的。因为业务不会为你写了多少代码买单,也不会为你调了多少次 AI 买单。业务只关心一件事:价值多久能到用户手里。

AI Coding 改变了工程生产函数。

但它没有改变研发效能的基本物理规律。局部速度不等于系统速度,生成能力不等于交付能力,短期吞吐不等于长期效率。

不要急着发明一套全新的效能宗教。先把工程里的主干指标守住,把主体放对,把业务团队和基建团队分开看,把技术债务纳入视野,再去观察 AI 到底在哪些环节真的创造了增益。

这样量出来的数据,才能指导决策。否则报表再热闹,也只是另一种噪音。

以上。

对最近 AI 落地工程实践的一些想法和思考

最近和小区某上市公司的 CFO 喝茶聊 AI,在过程中思维和实际场景的碰撞,记录如下:

穿透复杂的表象,当前 LLM 的底层运行逻辑其实非常单一:它本质上是一个自回归的序列生成器,根据已有的上下文,计算词表中每一个 token 出现的概率分布,然后从中采样出下一个 token。

但这里的「概率」绝非毫无逻辑的随机掷骰子。 这种概率分布,是模型在海量预训练数据中内化的语言规律、世界知识以及逻辑推理能力的数学投影。通过多层 Transformer 网络与注意力机制(Attention),模型在极高的维度上完成了对上下文语义的深度解析与特征关联,从而将符合人类逻辑、契合当前语境的 token 赋予极高的概率权重。它是在用统计学的方式,重现人类的逻辑推理过程。

然而,无论其内部的概率计算多么精密,从软件工程的宏观视角来看,我们本质上依然是在传统的确定性系统中,强行引入了一个基于概率采样的非确定性组件。

传统软件工程建立在严格的确定性之上。输入特定的参数,经过固定的业务逻辑,必然得到预期的输出。现在我们将核心逻辑交由概率模型处理,相同的输入在不同的时间点,可能会产生完全不同的输出路径。

幻觉无法被根除。它是自回归模型的内生特性,是概率采样的必然产物。我们在进行系统架构设计时,必须将幻觉视为系统的常态。试图通过修改 Prompt 来彻底消除幻觉,在工程上徒劳无功。我们需要在系统边界处建立起拦截机制,用确定性的规则去兜底概率模型的不确定性。

容错度决定落地

当前商业化落地最顺畅、ROI 最高的场景,全部集中在高容错度领域。写行业报告、生成营销文案、文生图、视频生成、游戏 NPC 对话。这类场景的核心特征在于缺乏绝对的客观标准。

在内容创作领域,模型偶尔的逻辑发散会被用户视为创造力。工程团队不需要在接口的绝对可用性和输出的绝对准确性上死磕,只需要保证底线的内容安全和合理的响应延迟。系统可用性达到 95% 就能让用户产生极强的获得感。

一旦进入低容错度场景,工程实现的复杂度会呈指数级上升。医疗诊断、工业控制、核心交易链路。在这些领域,0.1% 的幻觉率都会导致灾难性的业务后果。我们在评估一个 AI 项目是否立项时,首要考量指标就是业务场景的容错底线。容错度越低,外围需要的确定性校验代码就越厚重,最终会导致系统的维护成本远超 AI 带来的效率提升。

知识外挂 RAG

RAG 的出现是为了解决模型内部知识更新滞后和私有数据隔离的问题。其核心原理是将外部文档切片、向量化,在用户提问时检索相关切片,拼接到 Prompt 中作为上下文喂给大模型。

在实际的工程环境里,RAG 的核心瓶颈在检索链路。切片策略直接决定了召回质量。按固定 token 长度切分会破坏语义完整性,导致关键信息被腰斩。按标点符号或段落切分会导致切片长度方差过大,影响向量化模型的表达能力。我们在生产环境中通常需要针对不同格式的文档编写定制化的解析器,将 PDF 或 Word 还原为结构化的文档树,再基于文档树的层级进行语义切片。

单一的向量检索在面对专有名词和长尾词汇时表现极差。我们必须采用混合检索架构:稠密向量检索加上稀疏词表检索。向量检索负责语义泛化,处理同义词和模糊表达。词表检索负责精准匹配产品型号、人名和内部项目代号。混合检索引入了多路召回合并的问题,通常需要引入倒数秩融合算法来重排结果。系统复杂度和查询延迟会成倍增加。

数据清洗占据了 RAG 项目 80% 的研发精力。直接将企业内部的原始文档灌入向量数据库,最终的问答准确率通常不到 40%。文档中存在大量的废话、过期的流程规范以及相互冲突的条款。垃圾进,垃圾出。我们在构建知识库之前,必须通过脚本和人工介入,对语料进行严格的去重、降噪和结构化提取。

工具调用确定性

为了弥补概率模型的缺陷,我们需要引入确定性的工具。Function Calling 机制本质上是给 LLM 接上双手。模型负责理解自然语言意图并提取结构化参数,具体的业务逻辑交由传统的确定性脚本执行。

工具调用的工程难点在于参数提取的稳定性。当注册的工具数量超过十个,或者参数结构嵌套层级过深时,模型的输出格式极易崩溃。我们在中间层必须加入严格的 Schema 校验机制。一旦校验失败,需要截断错误信息并触发重试。重试次数上限通常设定为 3 次,继续增加会耗尽上下文窗口并导致请求超时。

多轮工具调用会带来严重的延迟问题。模型每决定调用一次工具,都需要经历一次完整的网络请求和推理过程。如果一个复杂任务需要串行调用三个工具,用户的等待时间会轻易突破 10 秒。我们在架构设计时,需要尽可能将细粒度的 API 聚合成粗粒度的宏接口,减少模型与业务系统的交互频次

Agent 架构的脆弱性与状态管理

多智能体(Multi-Agent)架构在技术社区被过度神话。多个大模型相互协作、自主规划任务的 Demo 看起来非常惊艳。在真实的工业场景中,完全由 LLM 自主驱动的 Agent 链路极其脆弱。

误差会在多步推理中被迅速放大。假设单个 Agent 节点的输出准确率为 90%,一个包含五个节点的串行任务,最终的成功率会暴跌至 59%。任何一个节点的幻觉都会导致后续链路彻底跑偏。

我们在生产环境中构建复杂任务流时,坚决摒弃由 LLM 自主决定执行路径的黑盒模式。控制流必须由传统的有向无环图(DAG)或状态机来接管。LLM 仅仅作为状态机中的一个计算节点,负责处理非结构化数据的理解和生成。节点与节点之间的状态流转、条件判断、异常重试,全部由确定性的代码实现。这种设计牺牲了系统的灵活性,换取了业务系统必须具备的稳定性和可观测性。

非确定性系统的测试与监控

非确定性系统的测试与监控,是传统软件工程团队转型 AI 开发时遇到的最大痛点。传统的单元测试基于断言,期望输出是固定的字符串或数值。面对 LLM 每次都不一样的回答,基于精确匹配的 CI/CD 流水线会全线崩溃。

我们重构了整个测试评估体系。引入 LLM-as-a-Judge 机制,使用一个能力更强、参数规模更大的模型来评估业务模型的输出质量。评估维度被拆解为相关性、事实一致性、格式合规性等具体指标。在每次模型版本迭代或 Prompt 修改后,必须在包含上千个真实业务 Case 的黄金数据集上运行自动化评估。只有各项指标的波动在可控范围内,才能进行灰度发布。

在监控层面,传统的 APM 工具无法满足需求。我们需要采集每一个请求的 Prompt 模板版本、输入变量、输出结果、Token 消耗量以及推理延迟。这些数据是后续进行 Bad Case 分析和模型微调的唯一原料。针对 Token 消耗的监控直接与业务成本挂钩。我们会在网关层设置严格的并发限制和预算熔断机制,防止恶意请求或死循环调用导致账单失控。

两种范式的碰撞

AI First 与 AI 辅助是完全不同的架构逻辑。

AI 辅助是在现有系统中打补丁。主干流程依然是传统的表单和按钮,AI 作为一个侧边栏或悬浮窗存在,提供总结、翻译、润色功能。开发成本极低,对原有系统无侵入。用户在遇到问题时,可以选择性地向 AI 求助。

AI First 要求重构整个交互形态和底层流转逻辑。系统不再依赖预设的菜单树,由 LLM 充当中央路由。用户的自然语言输入直接驱动底层状态机流转。这要求所有内部 API 具备极高的自描述能力,业务逻辑必须高度解耦。我们在推进 AI First 架构时,面临的最大阻力通常来自老旧系统的技术债。历史遗留的紧耦合代码根本无法被封装成独立的工具供模型调用。

财务场景的拆解

财务场景是典型的低容错度、高确定性要求的领域。将概率模型直接应用于财务核心链路会引发严重的合规风险。可落地的切入点集中在外围的非结构化数据处理和信息流转环节。

发票与报销单据的信息抽取是一个高价值场景。传统 OCR 结合正则匹配在面对版式多变的票据时维护成本极高。引入大模型进行多模态信息抽取,将非结构化的图片或 PDF 转换为结构化的 JSON 数据。抽取后的数据必须经过传统规则引擎的二次校验,例如金额试算平衡验证、税号合规性检查。模型在这里承担的是「粗加工」角色,最终的业务落库动作依然由确定性代码把控。

财务制度问答可以大幅降低沟通成本。基于企业内部报销规范构建 RAG 系统。员工在提单前通过自然语言查询报销标准。这里的 RAG 必须严格限制模型的发散,Prompt 中需强制要求「仅根据检索到的内容回答,未提及的内容直接回复不知道」。为了防止模型编造财务政策,我们会在输出层增加一层文本相似度校验,确保模型的回答与检索到的原文保持高度一致。

财务分析报告初稿生成也是一个可行的方向。将结构化的财务报表数据通过代码转换为文本描述,作为上下文喂给模型,让其生成趋势分析和异常波动提示。模型在这里仅作为「翻译官」和「排版员」,不参与任何数值计算。所有的同比、环比计算必须在传统代码层完成,将计算结果以明确的数值形式提供给模型。让 LLM 去做算术题是工程上的反模式。

数据隐私在财务场景中是不可逾越的红线。公有云 API 无法满足审计要求。我们通常需要采用本地私有化部署的开源模型。7B 到 14B 参数规模的模型经过量化处理后,可以在单张消费级显卡上流畅运行。通过针对财务语料的微调,这些小模型在特定信息抽取任务上的表现可以持平甚至超越千亿参数的通用大模型。私有化部署带来了硬件采购和模型运维的额外成本,需要在项目初期进行严格的 ROI 测算。

以上