关键讯息，D1时间送达！
企业网D1net
AI编程的真正竞争，早已不是谁生成的代码更多、消耗的Token更多，而是谁能更快、更稳定地将创意转化为生产力。面对AI带来的验证成本与交付风险，企业不该押注一个包揽全流程的超级智能体，而应借鉴微服务架构，让多个职责清晰、彼此独立的微型智能体协同工作，并依托现有权威数据系统，实现风险隔离、灵活迭代与成本优化。一家零售企业的实践证明：从创意到生产的时间缩短至原来的五分之一，团队没有裁员，还能承接更多项目。衡量AI价值的真正标准，从来不是代码产量，而是交付速度与稳定性。
今年的大部分时间，我都在飞机上度过。我去了七个国家，与客户进行了超过一百场交流，其中大多数客户团队早已越过了试点阶段。
我一直反复思考一个问题：一月份的交流与七月份的交流之间，究竟发生了什么变化？
一月和二月，随着智能体编程的采用率不断攀升，人们开始炫耀AI生成的代码行数。他们并非羞于启齿，而是满怀自豪，甚至专门制作幻灯片展示这些数字。到了夏天，再也没人炫耀这个了。真正有意思的是，什么取代了它，以及这件事如何改变了我对优秀智能体架构究竟应该是什么样子的看法。
一个经不起现实检验的指标
任何写过软件的人都知道，用代码行数衡量价值是一种糟糕的替代指标。Dijkstra主张关注的是花费了多少代码行，而不是产出了多少代码行。Gates曾将用代码行数衡量编程进度，比作用飞机的重量衡量航空业的进步。自2014年起，DORA的贡献在于，它将交付绩效定义为吞吐量和稳定性，而不是产出数量，并在此后的十年里持续检验这一衡量方式。
因此，代码行数炫耀风潮的回归，并不是因为人们忘记了这种指标的缺陷，而是因为AI让产出数量重新变得令人瞩目，而当时人们手头又没有其他现成的指标。
此后，整个行业逐渐意识到了这个问题。今年春天，DORA开始讨论一种名为“Tokenmaxxing”的做法，即根据开发者消耗的Token总量来给他们排名，并将其与代码行数、提交次数归入同一类不合理的衡量指标。
真正值得追问的是：那些已经摆脱这种思维的团队，转而采用了什么指标？他们又在构建什么，以推动这一指标不断改善？
真正取代它的是什么？
先从数据说起，因为数据能够解释背后的架构选择。
CircleCI发布的《2026年软件交付现状报告》分析了超过2800万个CI/CD工作流。报告发现，对于处于中位水平的团队，特性分支的吞吐量提高了15%，而主分支的吞吐量却下降了7%，主分支才是代码真正进入生产环境的地方，也就是说，编写代码的环节变得更加活跃，但真正交付软件的环节反而有所放缓。
DORA对近5000名技术从业者开展的调查，从人的角度得出了相同结论：AI采用率越高，软件交付吞吐量和软件交付不稳定性往往都会上升。速度更快了，但也更不稳定了。
DORA将其中的机制称为“验证税”：打字环节节省下来的工作量，并没有真正消失，而是转移到了下游的代码审查和验证环节，同时，AI还会诱使团队放弃小批量变更，转而采用规模更大、风险更高的变更。
今年春天，DORA发布的投资回报率报告进一步揭示了这种成本的变化轨迹：一条J形曲线，意味着投入回报出现之前，往往会先经历一段下滑期。
关键不在于代码产出量，而在于一个企业能够以多快的速度将代码部署到生产环境，以及代码上线之后能否保持可靠。
那么，组织究竟应该如何利用AI实现这一目标？
面对更快、更可靠的软件发布，错误的解决方案是什么？
人们的本能反应是打造一个超级智能体，让一个智能体端到端负责整个软件开发生命周期：读取工单、编写代码、创建拉取请求、运行测试，然后发布软件。我不止一次看到过这类方案的演示，效果确实非常出色。
但这种做法也会把所有故障模式集中到一个地方，这个智能体必须掌握几乎所有上下文信息才能开展工作，而一旦出现问题，人类也很难找到一个熟悉的切入点来排查和处理。
既然超级智能体不是正确答案，那么什么才是？
团队实际上正在构建什么？
我在实际项目中反复发现的模式，恰恰与超级智能体相反：使用多个小型智能体，每个智能体都围绕一个已经存在的权威数据记录系统开展工作。
具体来看，整个链条如下：
• 从Jira工单到GitHub Issue。由一个智能体负责。它读取业务需求，并将其转化为足够具体、能够指导工程团队开展工作的技术问题。仅此而已，这就是它的全部职责。
• 从GitHub Issue到点数估算和迭代规划。由另一个独立于第一个智能体的智能体负责。它进行工作量估算、任务分组和执行顺序安排。
• 编写代码。再由另一个智能体负责。这才是大多数人脑海中所谓的“AI”，但它只是五个智能体中的一个。
• 合并拉取请求。由另一个智能体负责，包括审查、冲突解决和合并规范的执行。
• 系统测试。再由另一个智能体负责。
这里最重要的词是“独立”。
这不是一个大脑带着五个子程序，而是五个彼此独立的智能体，它们恰好会处理相邻环节中的相关记录。每个智能体的职责范围都足够狭窄，可以用一句话清楚地描述。
如果你觉得这种模式似曾相识，那是理所当然的，因为它在理念上大量借鉴了微服务架构。
为什么要采用这种方式？
保留现有的权威数据记录系统
这是整个模式中最被低估的理念。
大多数关于智能体的讨论，都默认企业需要构建一个全新的操作界面，或者一个用于观察智能体工作的控制台。实际上，正确的做法恰恰相反：把智能体放在员工已经熟悉和使用的界面背后。
参与流程的人类员工不需要接受额外培训，不需要使用新的仪表板，也不需要改变自己查看工作进展的习惯，Jira本来就是他们查看这些信息的地方。
人类参与的监督机制之所以失效，较少是因为人们拒绝监督，更多是因为监督工作被转移到了一个他们平时根本不会去查看的地方。
限制故障影响范围
一个职责仅限于迭代规划的智能体，不可能直接发布有问题的代码，它可能会把某个用户故事归错类别，但你可以在每日站会上发现这个问题。
从DORA的角度来看，这意味着你在变更发生的阶段就着手控制变更失败风险，而不是等到整个流水线的末端才衡量结果。到了那时，你可能已经无法判断究竟是哪个步骤出了问题。
独立设计、独立发布
我曾在惠普见证面向服务的架构演变为微服务架构，后来又在思科经历了类似的过程。让这场成本不菲的转型物有所值的关键，并不在于架构有多优雅，而在于你可以修改其中一个部分，而不必重新协调整个系统。
这里也是同样的道理，你可以更换编程智能体使用的模型，而不必动测试智能体;可以分别对它们进行版本管理，也可以淘汰那些无法证明自身价值的智能体。
此外，还有第四项优势，它会与前面几项优势相互叠加。
每个微型智能体所需的上下文信息，只是超级智能体所需上下文的一小部分。
上个月，我曾指出，一个很少有人真正利用的杠杆，是降低单次处理的成本。关键在于选择合适的20万Token上下文窗口，而不是把错误的100万Token上下文窗口塞进系统。
缩小职责范围，可以从架构层面实现这一目标，而不是仅仅依赖参数调优，其结果是成本更低、准确性更高，原因与前面所说的一样。
实际案例
其中一位客户是一家零售企业，在采用这种模式运行九个月后，他们将从创意产生到投入生产的时间缩短到了原来的五分之一。
这里必须准确理解这个指标，因为它经得起严格审视。
从创意到生产的时间范围，比DORA的变更前置时间更广。后者从代码提交时开始计时，而这家企业的计时起点，是业务相关人员提交需求的时刻。
我认为，对于智能体驱动的工作而言，采用更广的时间范围才是诚实的做法，因为这些智能体所完成的相当一部分工作，发生在任何代码提交之前，包括细化工单、估算工作量和安排任务顺序。
如果只从代码提交时开始计时，你就会漏掉智能体改变最大的一部分工作。
他们并没有提高代码行数这一指标，我怀疑他们现在可能都不知道这个数字是多少了，因为它已经变得毫无意义。
还有一点更重要：他们没有裁员。
他们正在利用新增的工作能力承接以前根本没有足够人手完成的项目。
今年二月，我曾提出，开发团队是生产力的倍增器，而不是成本中心。三月，我又以银行柜员为例指出，当自动化扩大了经济上可行的工作范围时，它往往会扩大就业，而不是压缩就业。
在我写下这些观点时，它们还只是理论，这是我第一次能够公开发布实地证据，来支持这两个观点。
常见质疑
“五个智能体的运维开销，难道不会比一个更大吗？”
会。这与微服务架构一直以来的权衡相同，也与小批量交付一直以来的权衡相同：每个单位需要更多流程和协调，但每个单位的风险更低。如果你以前做过这样的取舍，就应该知道自己是否认可最终结果。
“按阶段拆分智能体，难道不会重新制造我们原有的交接问题吗？”
康威定律同样适用于智能体，无论你是否有意设计，智能体的拓扑结构都会映射团队的组织结构，因此应该主动围绕这一点进行设计，这是一个需要认真处理的约束，而不是一个等着让你措手不及的陷阱。
“权威数据记录系统属于遗留系统，智能体难道不应该部署在专门构建的新层中吗？”
权威数据记录系统的意义，并不在于数据存放在哪里，而在于人们已经习惯到哪里查看这些数据。
必须坦诚面对的局限
微服务的类比有正反两面，我宁愿主动说清楚，也不愿等别人来指出这一点。
微服务同样带来了分布式追踪难题、级联故障以及编排复杂性，整个行业花了很多年才逐步解决这些问题，微型智能体也会带来各自版本的同类问题。
跨五个智能体实现可观测性，确实比监控一个智能体更困难，而目前相关工具还不够成熟。
之所以仍然值得进行这种取舍，是因为它与微服务架构的价值来源相同：你可以单独理解、测试和替换某个部分，而不必把整个系统的所有细节都装进脑海里。
此外，保留现有的权威数据记录系统，也有助于缓解分布式追踪问题，因为整个流程并没有引入新的信息位置，而是继续使用那些多年来一直存在的系统。
真正的成绩单
炫耀代码行数，反映的是一个行业当时只能衡量AI显而易见地改变了什么，于是便把这一点当成了成绩。
那些已经超越这种思维的团队，不再追问自己的智能体能够产出多少，而是开始追问：每个智能体的职责范围究竟可以缩小到什么程度？
从创意到投入生产的时间缩短了五倍，没有裁员，积压的工作也终于有了可以逐步消化的空间。
自2015年以来，DORA的指标体系先后在2015年、2018年、2021年、2023年和2024年进行了修订。2024年，原来的四项关键指标扩展为五项。
但贯穿每一次修订、始终保留下来的，是它们背后的两个核心维度：吞吐量与稳定性。两者必须结合起来衡量，因为任何一项单独使用，都可能给你一个具有误导性的答案。
这才是真正的成绩单。
它从来都不应该是Token数量，也不应该是代码行数。
关于企业网D1net(www.d1net.com)
企业网(D1net.com)-企业 IT 第 1 门户。面向 IT 行业高端甲方人群(CIO 首席信息官)最精准专业的媒体，面向约六万政企 CIO、信息中心主任、科技部总经理等 IT 主管，提供资讯、营销、活动、项目合作推介等服务。拥有专业注册会员(IT 从业者)约 188万人，主要读者为政企用户及其信息主管、软硬件厂商等，服务过的企业级厂商逾五百家，国内toB的头部IT厂商基本都是D1net的客户。
同时，企业网D1net也运营着国内最大的CIO(首席信息官)专家智库和智力输出变现及社交平台-信众智，也是国内最大的科技高管社交平台。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。
如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1net投稿。
投稿邮箱：
editor@d1net.com
合作电话：
010-58221588（北京公司）
021-51701588（上海公司）
合作邮箱：
Sales@d1net.com
企业网D1net旗下信众智是CIO（首席信息官）的专家库和智力输出及资源分享平台，有六万多CIO专家，也是目前较大的CIO社交平台。
信众智对接CIO为CIO服务，提供数字化升级转型方面的咨询、培训、需求对接等落地实战的服务。也是国内较早的toB共享经济平台。同时提供猎头，选型点评，IT部门业绩宣传等服务。
扫描 “二维码” 可以查看更多详情
