上线与交接

这个阶段为了什么，又会怎样失败

到了这一步，看起来最难的活已经干完了。智能体达到了阈值，评审已经签字，构建成果跑在客户自己的环境里（“在客户的环境里构建”）。这看上去像终点线。客户的业务恰恰是从这里开始改变，或者始终没有改变。

除了技术上的考验，上线还有两道考验。客户的人必须能在没有你的情况下运维这个系统，而且他们必须真的用它。两者各有各的失败方式，而在供应商离场的那一天，两者看上去都像成功。

只有那位工程师能操作它。Alpine Edge 把这句话原样列为“交接失败”的早期预警（Alpine Edge，2026 年 8 月；T4，一家咨询公司的做法）。注意它放在哪里：在一张需求挖掘期间就要处理的风险表里，对应的解法是“尽早指定客户方的负责人；提供运行手册；做一次事故演练”。交接要在第一周就规划，否则就会在最后失败。系统为什么能跑通，这份知识只存在于一个人的脑子和命令行历史里。当这个人轮换到下一个客户，第一次模型更新、第一个过期的凭据或第一条古怪的输入，都会变成一次故障。客户这才明白，自己买到的是一种依赖，而不是一种能力。

它被晾在那里，没人用。Tryolabs 称之为“一种常见模式”：三个月后，“工具被晾在那里没人用，而要出来解释原因的是你”。它的诊断是结构性的：“需求挖掘、构建和采用，最后由三个不同的人负责，而这三个人各自听命于三套不同的优先级”（Tryolabs，2026 年 6 月；T4，一家公司在描述自己所在的领域）。FDE 这个角色存在的意义，就是把这三件事归到同一个负责人名下。一个把采用当作别人的事的 FDE，等于又把三者拆开了。

人们低估的是信任需要多长时间。Jarvis 说，在摩根士丹利，“主要的技术障碍大概在六到八周内就解决了”，而在财务顾问信任它之前，后面还跟着“大概又四个月的试点、收集评测、迭代”（Altimeter 访谈，2025 年 11 月；T2）。这里要紧的是这段时间是怎么花的。ZenML 对这场演讲的总结说，“技术上的就绪并不足够”，团队“与财务顾问紧密合作，标注数据、核验输出”（ZenML LLMOps 数据库；T3，转述的是同一场演讲，不是第二个来源；它是对一家供应商讲述某一个客户的二手总结）。建立信任的时间是构建时间的两到三倍，而且花在用户身上，而不是花在模型上。

Jarvis 后来把这一点说成了普遍规律。据 TNW 报道，他在 HumanX 上把问题归结为部署，“大约 80% 的情况都是如此”。按 TNW 的概括，企业“还不知道如何推广 AI、如何治理它，也不知道如何证明自己可以信任它”（TNW，2026 年 9 月；T3，记者转述一位供应商高管的话，而他的团队卖的正是部署）。考虑到来源的利益，这个说法要打折扣；但方向依然成立。

所以论点是这样的。交接不是收尾时开的一次会；它是一场验收测试，由客户的运维人员在你不在场的情况下通过。采用不能靠盼望；它是一项交付物，要像阈值那样被定义、被测量。交付的最后几个月要围绕这两件事来规划，也要为它们留出预算：如果构建用了六周，就别把你的离场定在第八周。

合成案例：演练与迟来的认可

这一段里有三点撑起了整章。上线可以撤回。演练由将来拥有这个系统的人来做，供应商保持沉默。采用之所以推进，是因为用户看到自己的判断改变了系统，而不是因为有人叫他们去用。

分阶段上线，每一步都能撤回

上线不是一个事件，而是一串阶段，每一段都小到失败的代价很低：先影子模式，然后一个团队或一小部分流量，再逐步扩大，旧流程始终保留，拨一下开关就能切回。Alpine Edge 第四周的检查清单用一句话概括了这一点：“如果已就绪，就采用有限发布或影子发布，并配上测试过的回滚”（T4）。在每个阶段开始之前写好它的退出规则，条件要写得平淡、机械：已在真实流量上运行了约定的工作日数，没有触碰任何护栏，推翻率持平或下降，阈值负责人已经点头。因为一次会开得让人感觉良好就扩大的阶段，算不上一个阶段。

有两样东西让一个阶段可以撤回。上线之前，两样都要坚持。

一次发布包含所有会改变行为的东西。智能体的行为不只取决于代码。Sierra 把每次智能体发布描述为“一个快照，不仅包含底层的源代码和提示词”，还包含“模型版本依赖，以及智能体可用的全部知识的不可变快照”。因此，“不可变的智能体发布让 Sierra 的客户在必要时能够即时回滚智能体的行为”（Sierra，2024 年 6 月；T4，供应商描述自己的平台）。你不需要 Sierra 的平台也能照搬这个思路。给提示词做版本管理，锁定模型版本而不是使用浮动别名，给所有规则或参考数据做快照，然后把它们一起部署。本 wiki 关于发布、版本管理与锁定的页面讲了具体做法，包括一个意外：当提供商挪动了一个别名时，即使没有人部署任何东西，行为也可能改变。

关掉必须意味着“回到老办法”，而不是“坏掉了”。只有当拉下开关之后发生的事安全且已知时，紧急停止开关才有用。对于只提建议的智能体，这很容易：建议停止，工作照旧走旧队列。凡是会执行动作的智能体，都要事先决定开关拉下时，进行中的工作怎么处理。把答案写进运行手册，并确保将来拉开关的人知道该通知谁。合成案例的演练发现的正是这个缺口：开关管用，但没有人知道谁该去通知理赔员。

Sierra 的测试“可以在开发期间以及每次智能体发布之前并行运行”。照搬这一点：评测那一章的回归套件，会成为你离开之后客户每次发布的关口，也是你要交出去的主要东西之一。

采用是一项交付物

一个达到了阈值、却没有改变任何人工作的系统，就没有兑现这次交付当初卖出去时承诺的结果。如果采用是交付物的一部分，它就需要阈值当初需要的那些东西：一个定义、一个基线、一位负责人和一个日期。

在别人替你定义之前先定义它。NHS 联邦数据平台展示了采用没有共识定义时会发生什么。The Register 报道，截至 2024 年底，“英格兰 215 家医院信托中，只有不到四分之一（45 家）在实际使用”该平台。它同时报道，“已有 72 家作为分阶段推广的一部分上线”，以及“超过 120 家 NHS 信托已签约使用 FDP”（The Register，2025 年 5 月；T3，记者转述 NHS 的数字）。已签约、已上线、在实际使用，是同一个项目的三个不同数字，争论的每一方都可以挑对自己有利的那个。同一篇报道说，有 880 万英镑付给了毕马威，用于采用支持：这衡量的是买方有多重视这个问题，而不是这笔钱有没有起作用。

对 FDE 的交付来说，要把采用的定义写在阈值旁边、写进交接文档，并用用户的行为来表述：展示了多少建议、接受了多少、推翻了多少，以及符合条件的工作中有多大比例走了新路径。从上线第一天就开始测量，这样才有基线。给它指定一位客户方的负责人，通常就是阈值的那位负责人。

然后把这些数字拆开来看，因为三种失败形态需要不同的解法。被无视（展示了，既没接受也没推翻）通常意味着建议出现的地方或时机不对；去和用户坐在一起，修的是工作流程，而不是模型。被推翻意味着他们看过了，并且不同意；这是评测问题，而那些推翻就是它的数据。不看就接受（接受率接近百分之百，复核时间接近零）是最危险的一种，因为你向模型风险部门承诺的人工把关，已经悄无声息地停了。要像盯着低使用率一样盯着它。

推翻就是信号。用户早在回答问卷之前，就已经在用纠正投票了。一位把案件移到另一个队列的理赔员，免费产出了一条标注样本。本 wiki 关于生产环境反馈信号的页面认为，系统产生的最密集的质量信号是修改，而不是点赞。由此引出两件事。把推翻导入评测集和回归套件，让反复出现的推翻变成修复。然后让用户看到这件事发生了：看到自己的纠正被采纳的人，会开始把系统当作自己的。

培训是构建的一部分。Palantir 把培训和使用广度写进了其部署中那位不写代码的搭档的职责（见下框）。证明这样做有效的证据很薄。Palantir 被引用最多的成果，是其首席营收官在一次财报电话会上转述的一位沃尔格林高管的话：Foundry 和 AIP 让“4,000 家门店在八个月内实现了端到端的工作流程”（Palantir 2025 年第一季度电话会记录；T2，供应商转述客户的话）。它衡量的是推广铺得多远，而不是谁在用、改变了什么。应把它看作一家供应商拿覆盖广度做头条，而不是采用的证据。

向高管汇报

上线前后，发起人就不再读工程进展了。评测那一章讲过带着坏消息去开的那一次会。上线阶段需要的是一份简短、定期的汇报，在大戏落幕之后仍能留住发起人的注意力，因为剩下的决定都归他们来做。这是经验之谈，不是数据。

以他们的数字开头，并配上最先动起来的那个数字。发起人的 KPI 通常是滞后指标：周期时间、单件成本、收入。它变化缓慢，而且同时受很多因素影响。这次交付自己的指标，比如首次处理时间，会最先变化，也更明确地归功于你。每次都把两者并排报告，对照同一个第 1 周基线。只报领先指标，等于要他们相信一个他们不向任何人汇报的指标；只报滞后指标，第一个坏月份就记在你头上。

按路径拆分滞后指标。在同样的几周里，把符合条件的工作分成两组展示 KPI：建议被接受的一组，和建议被无视或推翻的一组。这不是对照实验；理赔员接受的案件可能本来就更容易，汇报里要用一句话说明这一点。但要向发起人说明到底是系统在推动他们的数字，还是一个清闲的月份替你推动了它，这仍是最诚实的办法。

给他们一句能向上级转述的话。替发起人起草那句可以向上汇报的话，用他们 KPI 的单位，附上限定条件：什么变了，覆盖了多大比例的工作，是怎么测的。一个只能自己写这句话的高管会往大了说，而那个被夸大的版本，就会成为别人拿来考核你的数字。

报告采用时带上它的定义。写“被接受的建议占符合条件的理赔案件的比例”，而不是“采用率”，并且每份汇报里的定义都保持一字不差。

以摆在他们面前的决定收尾。到了这个阶段，决定都很具体：扩大上线范围、为运行手册需要的运维人力拨款、签署交接，或者启动“暂不做”清单上的下一项。Alpine Edge 的说法如出一辙：“交接应当让客户能够决定是扩大、调整还是停止这个项目”（T4）。一页纸，一张图，交接之前每两周一次，之后每月一次；更多的细节属于阈值负责人的评审会。

交接演练

要知道客户能不能运维这个系统，唯一的办法就是看着他们做。Alpine Edge 给出的测试很具体：让“未来的运维人员部署应用，按照文档排查一个失败的任务，并演练恢复”，然后“在工程师离开之前补上缺口，或者明确需要什么样的支持来覆盖它们”（T4）。它第 4 周的检查清单还加了一条：“指定运营负责人，并提供运行手册。”把演练当作验收测试来做，而不是培训课，并事先以书面形式商定通过条件。一个可行的条件是：每个场景都只凭运行手册完成发现、控制和恢复，用时在服务负责人可以接受的范围内，FDE 没有任何介入。

1. 运维人员来操作。你离开之后会被呼叫的那些人，用他们自己的账号和凭据完成每一步。如果他们需要你来解锁什么，演练就已经找到了一个缺口。
2. FDE 保持沉默。每当你解释了什么，就把你说的话记下来；那句话就是运行手册里缺的。沉默让人不自在，而这正是要点。
3. 故意把它弄坏。事先准备至少三种故障：系统调用的某个依赖宕机、一条它处理不了的输入，以及一个必须回滚的坏版本。本 wiki 关于智能体事故响应的页面列出了值得演练的故障类别，包括在你手忙脚乱时还在继续执行动作的智能体。
4. 记下缺口，补上，然后再演一次。什么都没发现的演练，大概是太容易了。发现了缺口却没有复演的演练，不算通过。
5. 按他们的方式算成本。Alpine Edge 建议：“按每个成功任务计算成本，而不是按每个 token。”财务会问运维人员这个系统花多少钱；交给他们的应该是每件分拣理赔的成本，而不是每月的 token 数。

第一次演练要早到足以补上它发现的问题并再演一次：在你离开前几周，而不是几天。如果复演没通过，要么你的离场日期往后挪，要么把这个缺口以书面形式写进支持期。

有计划地离开

FDE 从第一周就计划着离开，而上线阶段就是检验这个计划的地方。Jarvis 把 OpenAI 的立场说得很直白：“从 OpenAI 这一侧来说，我们永远应该是临时的”（TNW；T3）。ZenML 对他演讲的总结把这个团队描述为“一支从零到一的团队，专注于攻克新颖、高价值的难题”，而不是“长期的服务交付”（T3，转述的是同一场演讲）。Tryolabs 从另一侧给出了检验标准：“要看的是我们走了以后它是否还在被使用”，以及“FDE 离开时，你的团队变得更有能力，而不是更依赖”（T4）。

客户方三位负责人，指名道姓。一个人负责服务（部署、告警、凭据）。一个人负责它的行为（阈值、评测集、是否上线一项变更的决定）。一个人负责采用（定义、评审、新用户的培训）。这几个角色可以是同一个人；但绝不能是供应商。

一份书面的支持期，带结束日期。“有任何问题就打给我们”不是交接；它是一份谁都没定过价、没有期限的服务合同。写清楚供应商会做什么、做多久、通过什么渠道，以及到期之后怎么办。

他们自己能执行的变更控制。你离开之后，系统还会变：新的模型版本、新的理赔类型、监管方新加的一条规则。交接文档必须写明谁可以批准一项变更、上线前要跑哪套测试，以及什么分数会拦下它。没有这些，你走后的第一次变更，就会由当时最着急的那个人来做。

说句老实话。本书找到的公开资料里，没有一份独立测量过 FDE 构建的系统的采用情况，也没有一份核查过 FDE 离开一年后系统是否还在运行、还在被使用。本章的做法依据的是从业者的叙述和一个有据可查的反例：NHS 联邦数据平台。它们是关于“什么能让交接持久”的最佳猜测，而它们终究只是猜测。

你学到的东西不会只留在这一个客户那里。其中可以再次奏效的部分，是下一章“反哺产品”的主题。

模板：交接文档与运行手册

一份文档，分为两半。上半部分是交接：系统做什么、谁负责什么、证明了什么。下半部分是运行手册：怎么部署、回滚、停止和修复。和运维人员一起写，而不是替他们写，并把演练当作对这份文档的检验。

HANDOFF DOCUMENT AND RUNBOOK                     version / date: ____

1. THE SYSTEM
   What it does:       ____________________________________________
   What it never does: ____________________________________________
   Authority:          propose only | act with approval | act
   Rules enforced outside the model: ______________________________

2. OWNERS (customer side, by name)
   Service (deploy, alerts, credentials):  ________________________
   Behaviour (threshold, eval set, changes): ______________________
   Adoption (definition, review, training): _______________________
   Vendor support: scope ________  channel ________  ends ________

3. WHAT WAS PROVED
   Threshold met:  metric ________  held-out set ________  date ____
   Adoption definition: ___________________________________________
   Adoption baseline (date): ______________________________________

4. RELEASES
   A release contains: code / prompts / pinned model version /
                       rules / reference data snapshot
   Deploy:    ____________________   Who may deploy: ______________
   Rollback:  ____________________   Last rehearsed: ______________
   Before every release: run ________ suite; block if ____________

5. HEALTH (what normal looks like)
   Signal              Normal              Alert when      Who
   _________________   _________________   _____________   _______
   _________________   _________________   _____________   _______

6. KNOWN FAILURES
   Symptom             First check         Fix / workaround
   _________________   _________________   ________________________
   _________________   _________________   ________________________

7. KILL SWITCH
   How to stop:      _______________________________________________
   What happens:     _______________________________________________
   Who to tell:      _______________________________________________

8. ADOPTION REVIEW
   Measures: shown / accepted / overridden / ignored / share of
             eligible work; accepted-without-review rate
   Overrides go to: ________   Reviewed by: ________  every ________

9. HANDOFF DRILL
   Date: ______  Operators: ________________  FDE silent: yes / no
   Pass condition: ________________________________________________
   Scenarios: _____________________________________________________
   Gaps found / closed: ___________________________________________
   Re-run date and result: ________________________________________

10. SIGN-OFF
   Service owner (we can run it):        __________   date: ______
   Behaviour owner (it is good enough):  __________   date: ______
   Sponsor (we accept the handoff):      __________   date: ______
   Vendor lead (we have handed over):    __________   date: ______

下面是按合成案例填好的版本。区间和描述代替了真实文档会写上的测得数值。

HANDOFF DOCUMENT AND RUNBOOK: auto FNOL triage   version n / months 5-6

1. THE SYSTEM
   What it does:       suggests a queue for each incoming auto FNOL
                       claim, shown in the adjuster's queue view
   What it never does: writes to the claims system; acts on a claim
   Authority:          propose only
   Rules enforced outside the model: litigation-flagged claims never
                       go to the fast queue; listed claim types always
                       go to a human queue

2. OWNERS (customer side, by name)
   Service (deploy, alerts, credentials):  platform ops team lead
   Behaviour (threshold, eval set, changes): claims director
   Adoption (definition, review, training): claims director
   Vendor support: scope: defects     channel: ticket
                   ends: agreed date, a few months after handoff

3. WHAT WAS PROVED
   Threshold met:  routing accuracy >= senior adjusters; same-day
                   first action; zero litigation-flag breaches on
                   the held-out set (claims operations owns it)
   Adoption definition: accepted suggestions / eligible auto claims
   Adoption baseline (date): measured from first rollout stage

4. RELEASES
   A release contains: code / prompts / pinned model version /
                       routing rules / reference data snapshot
   Deploy:    pipeline in the insurer's private cloud, through
              the weekly change board
   Who may deploy: platform ops, after behaviour owner approves
   Rollback:  redeploy previous release   Last rehearsed: drill 2
   Before every release: run regression suite; block if below
                         threshold or any guardrail failure

5. HEALTH (what normal looks like)
   Signal              Normal              Alert when      Who
   queue lag           minutes             above agreed    ops
   unreadable docs     a small share       share jumps     ops
   fallback to human   rare                any sustained   ops
   override rate       falling slowly      rises for days  director

6. KNOWN FAILURES
   Symptom             First check         Fix / workaround
   no suggestions      model endpoint      claims fall to human
                                           queue; restore endpoint
   parser errors       new scan format     route to human queue
   odd routing burst   last release        roll back, then triage

7. KILL SWITCH
   How to stop:      feature flag in the queue view config
   What happens:     claims flow through the old manual queue
   Who to tell:      claims director, then team leads by message

8. ADOPTION REVIEW
   Measures: shown / accepted / overridden / ignored / share of
             eligible work; accepted-without-review rate
   Overrides go to: eval set    Reviewed by: claims director
                                every: two weeks, then monthly

9. HANDOFF DRILL
   Date: month 4-5 Operators: platform ops   FDE silent: yes
   Pass condition: each scenario detected, contained and recovered
                   from this document, no FDE help
   Scenarios: endpoint refuses (fallback + alert); unreadable scan
              batch; bad release rolled back
   Gaps found / closed: missing ops credential (granted); nobody
                        to tell adjusters on kill (now section 7)
   Re-run date and result: weeks later; passed, no FDE help

10. SIGN-OFF
   Service owner (we can run it):        platform ops lead
   Behaviour owner (it is good enough):  claims director
   Sponsor (we accept the handoff):      COO
   Vendor lead (we have handed over):    FDE lead

填好的版本里有两处容易被忽略。推翻率是一个健康信号，而不只是一个采用指标：它突然上升，往往是输入已经变了的第一个迹象。还有，供应商的支持期有结束日期。没有结束日期，不管标题写的是什么，这份文档描述的都是一种依赖。

失败信号

这些信号大多出现在上线前后的几周里，那时还来得及在你离开之前补救。

进入下一阶段

当每一项都打上勾，这次交付就算交接完成了：

• 上线分阶段进行，每次发布都打包了所有会改变行为的东西，回滚已经演练过。
• 紧急停止开关会把工作送回旧流程，运行手册写明了使用它时该通知谁。
• 客户的运维人员在没有 FDE 帮助的情况下通过了交接演练，演练发现的每个缺口都已补上，或已由书面的支持条款覆盖。
• 服务、行为和采用三位负责人都在客户方指定到人，且没有一位是供应商。
• 采用有书面定义、有基线，并有一项由客户自己执行的评审。
• 发起人已经收到一份汇报，它把他们的 KPI 和领先指标并排呈现，并以一个决定收尾。
• 供应商支持期有范围和结束日期，并随交接文档一起签字。