Endava：在软件交付流程中引入智能体协作

把 Endava 与 OpenAI 的合作读成「又一个程序员用上了 AI」，会错过它真正的形状。公开材料里，Endava 把 ChatGPT Enterprise 铺给全公司一万一千多名员工，同时把 OpenAI 的 Codex models 一起纳入企业级 AI 平台。这一步本身只是工具采购——把一套强模型接到每个人的桌面。真正改变交付形态的是下一步：Endava 在交付流程里搭起一支由多个智能体组成的网络，每个智能体对开发旅程中的一段拥有所有权。

这支网络的分工是具体的。有的智能体把原始业务需求转成用户故事，有的承担样板逻辑与测试的编写，有的作为专门的审查者扫描 pull request 里的漏洞，项目经理则用 Codex 生成治理报告、汇总工程进展。这些环节过去分属需求分析师、开发、测试、评审与项目管理等不同职能，如今被拆成一段段可以被单个智能体直接拥有的工作。被改变的最小单位，是职能与职能之间的交接，而不是某一个写代码的人。

对软件交付与服务外包的从业者，这个信号值得单独记下。一个补全工具让每个开发者更快地敲出代码，改变的是个人产出的速度；把全员接上同一套企业 AI、又把交付拆成可被智能体拥有的环节，重新画的是「谁做哪一段、在哪里交棒」的那条线。前者是加法，后者动的是流程的骨架。二者常被混为一谈，因为它们用的是同一批模型;但它们改变的对象不在一个层级上。

对正在评估企业 AI 路线图的管理者，这里有两个决策必须分开摆。员工能不能用 AI 写代码，是工具采购决策，衡量的是许可证、合规与桌面接入;交付流程里哪些交接可以交给智能体直接拥有、哪些必须保留人工确认，是组织结构决策，衡量的是责任、可审计性与返工成本。后者对最终价值的影响往往更深,却更容易被一句「我们已经全员上了 AI」盖过去。

把权重摆正的办法，是承认工具只能加速既有流程，而交接的设计决定加速出来的效率能不能留住。如果全员用上了强模型，却没有重新安排交棒的位置,新增的速度会在原有的摩擦点——需求返工、跨团队等待、评审排队——被重新吃掉，净收益远小于账面。公开材料给出的是这套做法与方向,一个可以直接外推到自家生产率的数字并不在其中;把它当成「买了工具就能提效多少」的证据,是对这个案例的误读。

要看清价值落在哪里，先看 Endava 公开的一个具体例子。法律团队带着一个复杂问题找上工程：数千页合同要按一组特定标准审阅，把这个需求翻译成工程可执行的规格，通常要在法律与工程之间来回一两周。双方的语言不通——法律讲的是条款与义务，工程要的是可实现、可测试的规格,中间这层翻译既慢又容易失真。他们的做法是把一次两小时深度会议的记录喂进 Codex，生成一份可用的需求规格初稿，把原本一两周的反复修订收敛成两次一小时的会议。

这件事要说准，否则很容易被夸大。公开案例给出的是「可用初稿加人工核对」，而非「一键产出、无需修订」。它之所以省时,恰恰因为人还在,只是介入的形态从数周的异步往返，变成两次有初稿垫底的当面确认。真正被压掉的不是「读合同」这个动作，而是两个职能之间的翻译与等待——法律不必反复解释自己的意图,工程不必反复猜测条款的工程含义,一份初稿把双方拉到同一张桌子上。

把这条线放大，就是整支智能体网络在做的事。项目经理用 Codex 生成治理报告、汇总工程进展,省掉的是人工整理进度的往返;把原始需求变成用户故事的智能体,省掉的是需求分析师与开发之间的澄清;处理样板逻辑与测试的智能体,省掉的是开发在重复劳动上的排队。每个智能体对一段拥有所有权,意味着交付从「一个人从头跟到尾」,变成一串可以各自推进、在明确接口处交棒的环节。链条上的每个接口,原来都是一次人对人的等待。

这里要点破一个常被跳过的边界:跨职能翻译并非无损,而且它的失败方式很隐蔽。当输入文档超出模型的上下文窗口,模型通常不会报错说「我没读完」,而是用已经读到的部分,当成完整规格生成输出;领域边界上的术语歧义——同一个词在法律和工程里指的不是一回事——也会被用肯定的语气写成明确要求,而非标成待确认项。一个被静默截断或误读的需求,会以和正确需求一模一样的确定性流到下游。

这解释了为什么需求翻译类的智能体,比样板逻辑类的需要更高的审查级别。样板逻辑写错了,编译器或测试大概率会当场拦下,错误是自暴露的;一份需求规格写偏了,它会一路正确地被实现、被测试、被交付,直到验收阶段客户说「这不是我要的」才暴露,而此时返工的成本已经翻了几番。同样是智能体产出,离「机器可验证」越远的那一段,人工确认的必要性越高。评估一个交付智能体,先问它的错误会不会自暴露,再问它接管了多长的等待。

这个案例最容易被漏掉的管理含义,是它改变了值得优化的对象。在很多交付场景里,真正积累时间与成本的,是围绕敲代码的那一圈交接:需求澄清、跨职能翻译、评审、返工,而非敲代码这个动作本身。这些环节难以被传统开发工具优化——一个更快的 IDE、一套更好的脚手架,加速的是键盘前的那段,却碰不到「等另一个团队回话」的那几天。合同那个例子里被压掉的一两周,正落在这类环节上。

智能体最先吃下的恰恰是这类摩擦。它把「等另一个团队」变成「调用另一个智能体」:等待从一个需要排期、需要协调日历的人际过程,变成一个可以随时发起、几分钟返回初稿的调用。它做的是把流程里最长的那些空档抽掉,而非把某个人变快。对一条交付链来说,抽掉空档带来的总时长收益,往往大于把每个人的敲代码速度提高一截。

这要求管理者换一套评估维度。如果只盯着「代码补全速度」或「每个开发每天多写多少行」,很可能会给一个只优化了链条上最短一段的工具打高分,而对真正压缩了跨职能等待的能力视而不见。正确的问法是:这个智能体能消掉哪些等待、能替代哪些交棒、能把哪段异步往返变成一次同步确认。合同规格从数周往返变成两次会议,值钱的正是「往返」这个字,而非「规格」。

但这个次序不是普适定律,得给它标出成立的条件。它成立,前提是交付链里确实存在大量跨职能的澄清与等待;在需求高度明确、流程高度成熟、交接已经很薄的团队里,最大的杠杆可能就回到执行速度本身,智能体先吃哪一段的答案会不同。一个可以观察的反证信号是:如果一个团队引入智能体后,总交付周期几乎没动,而个人产出指标却明显上升,那多半说明它的瓶颈从来不在交接上,这套「先优化等待」的判断在这里就不适用。

务实的落法,是先画出自己交付链上的等待地图,再决定智能体往哪投。把每一次跨职能交棒、每一段异步等待、每一轮评审返工标出来,量一量各自吃掉多少日历时间;然后把智能体优先接到最长、最频繁、最容易自动生成初稿的那几段接口上。这张地图本身就是决策依据——它决定了同一批模型,在你的组织里能兑现多少效率。没有这张图,采购来的速度会被随机地撒在链条各处,恰好避开最粗的那根瓶颈。

给智能体「所有权」是这套做法最锋利、也最需要被治理的一步。一个扫描 PR 漏洞的审查智能体、一个把需求翻译成规格的智能体,一旦产出被下游直接采用,错误就会离开某个人的草稿,进入真实的代码与交付物。所有权意味着它的输出默认被信任、被继续往下用,而非先经过一双人眼。这一步把效率和风险同时放大:省掉的人工确认越多,一次误判溜到下游的概率也越大。

正因如此,所有权应当是一个分层,而非一个开关。可逆、可观察、出错代价低的交付段,适合让智能体直接拥有:样板逻辑写错了测试会拦、初稿用户故事有误后续澄清能补、进展与治理报告失真了下一份就能纠正。这些环节即便出错,也停在低代价、可回滚的范围里,不值得为它们保留一道人工闸门。把这类工作交出去,换来的时间是净收益。

另一端是出错代价高、且错误不自暴露的交付段,只能让智能体做助手、由人签字确认:安全审查的最终判断、对外承诺的合同解读。这些产出一旦错了,代价可能是一个安全漏洞进了生产、或一份被误读的合同义务被写进交付物,而且往往要到很晚才暴露。这一档的正确形态是智能体给建议、人做决定并署名,自动化省下的是人查找与起草的时间,而非人拍板的责任。

夹在两端之间的,是带人工复核推进的中间档:PR 安全扫描的结果、合同需求的规格初稿。它们的产出有实际分量,但错误可以在一道不太昂贵的复核里被拦住。这一档的关键设计,是把「谁产出」和「谁有权拍板采用」明确分开——智能体产出,一个指定的人负责在采用点上确认。分层的意义就在这里:它让每一段交付的信任级别,和它出错时的代价对上号,而非笼统地要么全信、要么全不信。

和把智能体接进任何真实系统一样,关键在于组织能否解释、限制并复盘它完成的过程,而不只是它能不能完成一段工作——尤其当这段工作直接影响代码安全或合同义务时。一支智能体网络真正的治理资产是这张分层表,而非模型本身有多强:它写清了每一段交付的信任边界。少了它,网络会在第一次把一个理解偏差直接写进交付物、又没人负责拦截时,把之前攒下的效率一次性还回去。

安全审查这一段值得单独拆,因为它最能说明「为什么带审查地拥有、却不能完全交出判断权」有技术上的硬理由,而不只是一句谨慎的口号。一个扫描 PR 的安全审查智能体,读到的主要是这次改动的 diff。它在这个范围内很擅长发现模式化的问题:硬编码的密钥、常见的注入写法、明显危险的 API 调用——这些都是可以在有限上下文里、按模式匹配就能识别的东西,让智能体直接拥有这类扫描,收益明确。

问题在于,不是所有漏洞都住在 diff 的范围里。一类真正危险的漏洞是架构级的:一个函数本身看起来完全正常,危险来自它被谁调用、在什么信任边界上被调用、和别处的哪段状态叠加。要看见这类问题,需要跨文件理解调用关系、数据流与信任边界,而这超出了一个只读本次 diff 的审查智能体的可见范围。它根本没看到,而非判断错了——被改动的那几行在局部完全合规,危险藏在它与整个系统的交互里。

这就是安全审查只能「带审查地拥有」的技术原因,而非管理层的保守。把最终判断权完全交给一个可见范围受限于 diff 的智能体,等于系统性地对一整类漏洞失明,而且是最难在测试里暴露、代价最高的那一类。正确的用法是让它拥有模式化扫描这一段——快、全、不知疲倦地筛掉低级问题,同时把架构级判断留在能看到全局的人手里。它压缩的是人的工作量,而非人的判断范围。

这条边界还给采用者一个可迁移的判断法则:一个交付智能体的可信度,取决于它的可见范围能不能覆盖它被要求负责的错误类型。可见范围只有 diff,就不该为跨文件的架构安全负最终责任;只读到会议记录的一部分,就不该为整份合同的义务解读署名。给智能体划所有权之前,先划清它到底能看到多少——它看不到的地方,正是它会用完整的确定性给出错误答案的地方。

一个值得警惕的反例是:随着模型上下文窗口变大,团队容易过早地把可见范围的假设放宽,以为「窗口够大就等于看全了」。窗口大能装下更多文件,但装进去不等于建立起正确的调用关系与信任边界理解;可见范围是能力问题,不只是容量问题。一个可观察的危险信号,是安全审查智能体的通过率很高、漏报却集中在跨模块交互上——这说明它的所有权级别被提得超过了它的可见范围,该往回收一档。

把分层落到可操作,需要为每一类交付智能体明确标出四件事,而不是停在「我们对它有治理」这种笼统承诺上。第一件是所有权级别:它属于直接拥有、带审查拥有、还是仅做助手。这一栏决定了它的产出默认被信任到什么程度,也决定了在它和下游之间要不要保留一道人工闸门。没有这一栏,同一个网络里高风险和低风险的产出会被同等对待。

第二件是产出在谁手里被采用。一份规格初稿、一个扫描结果,总要在某个具体的点上被某个具体的人或系统接过去、继续往下用。把这个采用点标出来,才知道人工确认应该插在哪里、由谁来插。很多治理失效的根源,是没人清楚复核到底该发生在哪一步,而非缺少复核本身,结果产出在无人把关的接口处直接流走。采用点是分层能不能真正生效的物理位置。

第三件是出错时由谁负责。智能体不能署名、不能被问责,它的产出一旦出错,责任必须落在一个具体的人或角色上——是采用它的人、还是配置它的团队。把这一栏空着,等于默认「机器做的,没人负责」,而这正是一个理解偏差能够无声地流进交付物、最后无人认领的温床。所有权可以下放给智能体,责任不能。

第四件是留下什么记录。哪份规格是哪次会议记录生成的、哪个扫描结果基于哪次 diff、谁在采用点上做了确认——这些记录是事后复盘的唯一凭据。当一个错误最终暴露,能不能快速定位它是在翻译环节被误读、还是在采用环节被漏检,取决于这条链路有没有留痕。可审计性是把「智能体出过一次错」变成「我们知道错在哪、下次能拦住」的前提,而非合规摆设。

这张四栏清单——所有权级别、采用点、责任人、记录——本身就是智能体网络的治理骨架。它把「能不能用智能体」这个已经过时的问题,换成「每一段交付的信任、采用、问责与留痕分别落在哪里」这个真正决定成败的问题。有了这张表,分层才不是纸面原则;少了它,一支能干活的网络会在第一次静默出错时,证明自己攒下的效率有多不牢靠。评估一家公司的智能体成熟度,看的是这张表填得有多满,而非它接了多少智能体。

这个案例真正可迁移的东西,和 Endava 用了哪个模型无关,重点在采用的顺序。智能体最先改变的,是项目治理、文档与交付节奏:治理报告自动生成、需求与评审被压缩、进展汇总不再靠人工整理。这些都是相对低风险、见效快、且不触动商业结构的环节——它们改的是内部怎么运转,不改公司怎么收钱、和客户怎么划边界。先动这一层,是合理的起手式。

这个顺序对应着后悔成本的高低,而非随口的排序。把低后悔的交接先交出去:样板逻辑、用户故事初稿、进展报告——可逆、可观察、出错代价小,适合直接拥有;PR 安全扫描结果、合同需求规格是中间档,带人工确认再采用;对外合同义务的解读、安全审查的最终判断属于高后悔,留在人手里签字。按「谁在为产出负责」把交付段从低后悔往高后悔排,本身就是一份采用路线图——它告诉你先交出哪一段、把哪一段捂到最后。

这套排法之所以是资产,是因为它同时决定了两件事:效率能拿多少,责任落在谁头上。把低后悔的段落尽早交给智能体,能最快兑现时间收益,而风险被限制在可回滚的范围里;把高后悔的段落留到治理成熟之后再谈,能避免一次昂贵的误判在还没有留痕与问责机制时就发生。顺序错了——比如一上来就让智能体拥有对外合同解读——是把最贵的风险放在了防护最薄的时候,而非一步更激进的选择。

再往后,采用的推进才会碰到更敏感的地方:报价与组织边界。这两样是公司对外的商业契约,而非内部流程,动它们的前提是内部治理与节奏已经被智能体重塑到足够稳。顺序在这里有一个不容易说出口的含义:治理层的改造可以安静完成,商业层的改造却会直接触到营收模型,因此它通常滞后,而且这个滞后本身会成为一道难关,而不只是一段过渡。

判断一家公司走到哪一步,可以看它把智能体推进到了哪一层。只改了治理报告和文档节奏,说明它还在低风险区收割确定的效率;开始重排交付段的所有权、并据此调整对客户的承诺方式,说明它已经踏进了要动商业结构的深水区。一个值得追踪的信号是:一家服务公司什么时候第一次在对外合同里,把「投多少人、多少周」的口径换成按交付结果计价——那一刻,它才真正把智能体从内部提效,推进到了重写自己商业模式的阶段。

采用顺序里藏着一个绕不过去的张力,一到商业层就浮出来。当一次两小时的会议能顶掉一两周的往返,一家按人时收钱的公司,正在削自己的营收——被压缩掉的,恰恰是可计费的工时。合同那个例子在提效栏里是一笔确定的效率收益,在营收栏里却是减项:同样一份规格,过去能开出一两周的人力账单,现在只对应两次会议。效率越高,账单越薄。这股压力来自自家提效直接作用在自家收入上,而非外部竞争。

所以对 Endava 这类公司,真正的难题是「在自己的营收模型被自己改写的这几年里,靠什么撑过去」,而非「要不要用智能体」。旧的定价基础——按投入的人时计费——正被自己先拆掉,而新的定价基础(按结果、按可信交付计价)却未必同步长出来。这中间是一段收入模型悬空的过渡期:成本结构已经变了,计价方式还没跟上,利润率在这段真空里最脆弱。它是一道自我改造题,难点在于拆和建之间有时间差。

专业服务的历史反复显示,生产率工具的普及,和计费模式的重构之间,往往隔着数年。工具能不能转化成新的定价权,取决于两个条件,而非工具本身:客户能不能量出这份效率,以及手里有没有换约的筹码。如果客户看不见效率从哪来,他们没有理由接受一个更高的按结果报价;如果他们既看得见、又有替换供应商的筹码,他们更可能要求分享效率红利,把价格往下压。这两股力量决定了这几年是提价窗口还是降价压力。

这就要求把那句「智能体会重构服务业定价」的论断,从口号收紧成一个有条件的判断。它成立的触发条件,是效率变得可测量、且客户与供应商之间的议价权允许按结果重新签约;在这个条件满足之前,更可能出现的是价格被压、而非被重估。一个明确的反证信号是:若干年后,如果行业主流仍在按人时报价、头部服务商的利润率也没有被明显压缩,那说明这套「智能体重写定价」的判断在这个周期里并未兑现,得推倒重来。不给它标出这个可证伪的信号,它就只是一句迟早论。

对管理者,这段过渡期的正确做法是主动而非被动。等客户先量出效率、再来压价,是最坏的时点——那时议价权已经在对方手里。更稳的做法是在治理与节奏已被智能体重塑、效率能被自己清楚计量之后,主动把一部分交付从工时口径切到结果口径,用可信、可审计的交付去支撑新的报价。这件事做得早不早,直接决定了这家公司是在自我改造里掌握定价权,还是被别人的效率倒逼着降价。

把这个案例收束到一个问题:当交付的最小单位从「一个人跟完整个项目」,变成「一串可被智能体拥有、在接口处交棒的环节」,「一个项目要多少人、多少周」这张报价单还立得住吗。这是一道具体的商业题,而非修辞。报价单的每一行,原本都对应着一个人在一段时间里的投入;当其中一段段投入被智能体接管、被压缩成几次确认,这张单子的计价单位就和交付的真实结构脱了钩。

会迅速趋同的,是模型与工具。同一批强模型对所有服务商开放,搭一支智能体网络的技术门槛,会随着时间拉平——今天的领先,多半会成为明天的行业标配。真正难被复制、因而真正能被定价的,是另一样东西:一套把交付段按后悔成本分层、给每个智能体标清所有权与责任、并据此重排对客户承诺方式的组织能力。前者是可采购的,后者是要经历一段自我改造才能长出来的。

这套能力的稀缺性,来自它要求一家公司先拆掉自己赖以收钱的旧基础。谁都能买到模型,但敢在营收模型悬空的几年里,把计价口径从工时切到交付、并在这场自我改造中活下来的公司很少。这一步之所以是护城河,是因为它要求组织愿意先削自己的账单、再重建定价,而非因为技术有多难——大多数公司会本能地拖延这一步,而拖延本身就把先动者的领先固化了下来。

所以这个案例独有的定价题,落在「谁先敢把自己的收费从工时改成交付」上,而非「哪个模型更强」。它成立的条件前面已经标清:效率可测量、议价权允许重新签约;它可能被证伪的信号也标清了:若干年后行业仍普遍按人时报价、利润率未被压缩。在这两者之间,先把交付结构、治理骨架和计价口径对齐的公司,握着的是一份别人短期内抄不走的资产。

给建设者与出资人的落点因此很直接。评估一家 AI 时代的服务公司,别只数它接了多少智能体、用了多强的模型——这些很快会趋同、不构成区分度。要看的是三件对齐得如何:交付被拆成了可被智能体拥有的环节没有、每个环节的所有权与责任分层清不清楚、以及它敢不敢据此把对客户的报价从人时改成结果。三件都对齐的公司,才真正把智能体从一个提效工具,变成了一次重写自己商业模式、并且难以被复制的改造。