跳到主要内容

训练、评测与系统工程 — 从演示到生产

这一章讲三件事: 为什么「能不能完成一次演示」和「能不能长期稳定完成任务」之间隔着一整个工程闭环; 评测这件事在智能体身上为什么突然变难——成功率会撒谎、环境会漂移、连尺子本身都需要被评测; 以及发布和运营的规矩——门槛清单、影子运行、双层闭环、回归集、SLO、变更门禁。

它在全书链条里的位置:第 13 章给了长任务的三根骨架,这一章给它们装上仪表盘和刹车—— 把一个会行动的原型,变成能被持续观察、持续改进、在真实任务里稳住边界的工程对象。 第 01 章埋的那句「三类评测的判断会在第 14 章展开一次」,在本章兑现。

顶层全景:从演示到生产的工程闭环​

   轨迹数据与人工修正 ──► 训练与筛选 ──► 评测集与难例 ──► 影子运行与灰度
                                                      │
        ┌─────────────────────────────────────────────┘
        ▼
   线上日志与事故复盘 ──► 回到训练(数据闭环)
   全程三道护栏:权限门禁 · 回滚开关 · SLO 约束

图说: 这张图是原书的图 13.1:智能体上线不是交付的终点, 真实轨迹、难例、事故复盘要不断送回训练与评测体系——护栏约束每一次能力更新别把旧能力撞坏1。

1. 从演示到上线,中间隔着一整个闭环​

智能体一旦进入真实环境,问题立刻从「能不能完成一次演示」变成「能不能长期稳定地完成任务」。 录屏里漂亮完成的智能体,进入真实世界可能在边角场景频繁失败、在长运行中暴露状态污染、 成本失控和难以调试2。书里给了一个贯穿全章的例子——一个办公流程智能体, 帮员工整理会议资料、填报销单、更新客户记录。演示阶段,在预设流程里跑通就够吸引人; 上线阶段,团队必须继续追问:成功轨迹能不能沉淀为训练数据、失败轨迹能不能被复盘、 评测集是否覆盖高风险场景、日志能不能回放、写权限如何分级、灰度发布和回滚开关是否已经准备好3。 本组拆解沿用这个报销智能体作为全章的演示主角。

2. 轨迹:训练、评测、排障、复盘的共同语言​

第 13 章从「学习」的角度讲过轨迹,这里补上它的工程意义:它是训练、评测、排障和复盘之间的共同语言。 任务失败后,只留最终输出,团队只能猜;留下完整轨迹,就能回看目标是否被误解、工具是否选错、 状态是否被污染、哪一步本该请求人工确认4。

一条高质量轨迹至少包含七个字段:任务目标、环境状态、工具调用、工具返回、模型决策、 人工接管点、最终结果;成功轨迹提供可模仿路径,失败轨迹暴露边界和难例5。 书里把报销那条轨迹的字段串得非常具体:用户说「上周去上海开会一次」→ 日程系统返回会议在 5 月 12–14 日 → 差旅服务取出高铁票和酒店发票 → 按部门规则归类成「研发出差/跨城市」→ 生成草稿 → 员工二次确认时改正了多报的一晚酒店 → 提交并记录审批人。 如果只留最后那张表单,下次它仍会在「会议名记错」(接口换了字段名)或「发票项分类错」 (部门改了报销细则)上重复犯错;留下轨迹,才知道哪一步出了问题6。 被人工标注过的轨迹还能进训练集,教模型「遇到这类口头描述先查日程再碰差旅服务」——这就是数据闭环的起点7。

3. 环境反馈与延迟归因​

传统训练的监督信号来自静态语料和人写的参考答案;智能体训练多了一个信号源:环境本身—— 动作有没有把网页推进到下一页、命令有没有真的生成目标文件,「环境用结果告诉你成没成」, 而不只看「人告诉你对不对」8。

但环境反馈有两个坑,书里都点了名9:

  • 噪声与稀疏:任务最后失败,可能是开头误解目标,也可能是中间一次小操作失误—— 成败未必能立刻归因到具体某步;
  • 延迟反馈链:真实企业流程里,提交是即时反馈,员工二次确认要几分钟到几小时, 审批要一天,月度对账要一个月。训练不能只靠瞬时奖励,还要能把延迟反馈正确归因回当时的具体动作。

一种稳健的做法是把「系统当时的预期反馈」和「后来实际收到的反馈」同时记进轨迹; 两者出现差异时,就是一个高价值的训练样本——要么预期模型偏了,要么环境出现了新情况。 这样训练信号不再是「成功/失败」两个标签,而是带时间维度的「在哪一步开始与现实不一致」10。

训练路径也要现实:不从自由探索开始,而是先用高质量轨迹做模仿学习打底, 再用规则检查器或环境结果筛选排序,最后才在受控环境(浏览器沙箱、模拟账户、可回滚文件系统)里探索—— 因为智能体学的是带副作用的动作,受控环境既是训练设施,也是安全前提11。

4. 成功率之外:轨迹质量​

智能体评测和大模型评测最大的不同:它测的不是「会不会回答」,而是「能不能完成」。 任务成功率自然是最直观的指标(衡量做得好不好的量化刻度),但只看它不够——两个都完成的系统,轨迹质量可能差得很远: 一个路径清晰、调用少、状态稳;另一个反复试错、误操作一堆,只是侥幸到达终点12。

轨迹质量这一层盯的是:计划是否合理、动作顺序是否有效、证据链是否清楚、是否频繁走回头路、 有没有不必要的高风险动作。盯轨迹质量的额外好处是逼着系统把「它为什么这么做」一步步摊开, 事后才能复查到底哪一步开始走偏——这种过程可解释性,侥幸成功的系统给不出来13。

benchmark 的意义也相应变了:不在排榜,而在识别系统薄弱环节—— 网页导航强不代表代码修复强,短任务稳定不代表长任务不失控。 书里列出的基准各有能力切面:WebArena(真实网页操作)、Mind2Web(可泛化操作策略)、 OSWorld(操作系统与桌面)、SWE-bench(真实仓库修 issue——书里特意提醒它与 SWE-agent 是配对而非同一件工作)、 GAIA(通用助手多步任务)14。还有一条工程铁律:智能体评测比普通模型评测更需要回归测试—— 接入新工具、换模型、改提示都可能引入新问题;没有回归体系,优化很容易陷入 「修好一个问题、带出两个新问题」的循环15。

5. 任务画像与覆盖率:均值会撒谎​

评测更难的原因还有一条:团队面对的不是单一任务,而是一整片任务分布—— 在时长、风险、工具依赖、可回滚性上完全不同。粗暴压成一个平均成功率,关键的退化会被掩盖16。

所以要给任务画像:按稳定维度分层——需要多少步、依赖多少外部工具、是否涉及写权限、 失败是否可逆、是否必须人工确认、有没有长尾环境变化。分完层,某个版本「低风险短任务提升、 高风险长链任务退化」就再也无法靠平均分藏身17。

书里用报销智能体算了一笔非常具体的账:把同一周几百条任务按「是否走审批链、金额量级、 是否跨部门、是否改旧表」分箱——80% 的任务集中在「走审批链、金额 500–5000、单部门、不改旧表」, 成功率 95%,很漂亮;但跨币种或修改旧表那 5% 的任务,成功率可能跌到 50% 以下,恰恰是事故最容易发生的地方。 覆盖率体系的关键,就看这些低频高风险切片有没有被持续保留在回归集里—— 它们才是「均值漂亮」与「实际可上线」之间的差距来源18。

画像和覆盖率还会反过来帮组织决策:清楚知道哪些层级稳定、哪些脆弱, 才能决定哪些能力先上线、哪些继续影子运行、哪些只配「建议模式」而不许自动执行19。

6. 评测污染、环境漂移与三层评测集​

智能体评测也会被「做熟」:一套任务公开后,模型、提示和工具链围着它反复调参, 分数上涨未必等于真实能力上涨。更麻烦的是环境本身在漂移——网页布局改版、接口字段升级、 企业流程多出一个审批步骤,昨天的稳定轨迹今天就失效20。

所以评测集最好分三层21:

层装什么防什么
稳定回归集旧任务旧案例旧能力退化
滚动更新集新环境、新工具、新任务形态与真实世界脱节
高风险难例集越权、误删、重复提交、状态污染的事故轨迹事故级错误悄悄复发

书里连维护节奏都给了:回归集按季度滚动(Q1、Q2、Q3 分开存,每季补入当季业务变化), 难例集单独保存历史真实事故的轨迹,每次发布前都跑22。

补充(不在书里,依据我们的前沿框架书架):评测的「尺子」在开源框架里已经是一条显式流水线—— 打分器把每条输出判成分数,归并器把多次重复按样本合成,最后聚合成带误差棒的指标; 「评判器要被校准」在这里是结构化现实而不是口号。 依据: shelf=ai-frontier-reference/inspect-ai#05-scorer-metrics.md @d8fc8fcbde743726443fadb8e8ad010f0a2fd38d 事实=Scorer→ScoreReducer→Metric 三级归并,最终产出 accuracy/stderr 这类可对比数字。

7. 评判器校准:尺子本身要被评测​

智能体评测还有一层最容易被忽视的前提:我们用来判断「做得好不好」的尺子,本身是否可靠。 轨迹好不好、工具选得对不对、失败是否及时止损,都没法靠一句「答案对错」判定; 于是评测体系里隐含着另一套系统——评判器(人工标注员、规则脚本、模型裁判,或其组合)。 评判器不稳定,再精细的成功率曲线也建立在摇晃的地基上23。

所以成熟团队特别重视标注协议:什么叫「成功完成」、什么叫「完成但过程不可接受」、 什么叫「结果失败但策略合理」,边界要在评测前写清楚。书里举的那对例子很传神: 有的轨迹最后碰巧成功,却越了权;有的轨迹没完成任务,却在证据不足时主动停下请人确认—— 后者在很多场景比硬着头皮做错更值得鼓励;标注协议不写清,不同评审者就会把直觉带进评分, 数据表面整齐,含义不断漂移24。

模型裁判提高了吞吐,也带来了新偏差:可能偏爱语言流畅的轨迹而忽视关键约束, 可能对某类失败过宽或过苛。所以裁判不能被当成「客观真理」,要和人工复核、规则检查一起用; 更稳的做法是分层评判:能规则化的由程序判,策略与风险边界交给人,分歧大的进仲裁池25。 标注一致性本身就是工程指标——不同标注员的一致率、裁判与人工的偏差集中在哪类任务, 都该被持续跟踪。书里由此给出一个组织层面的判断:系统难以改进,很多时候不在模型碰到天花板, 而在团队没形成稳定的「好坏判断」26。

办公智能体把这层演绎到极致:「这次报销算不算成功」按「表单提交了」「员工没改字段」 「审批一次通过」三种口径判定,成功率能差出 10–20 个百分点。成熟做法是三层一起跑: 机器可验证的(字段齐全、金额一致)规则脚本判;员工体验(要不要二次修改)埋点统计; 组织合规(审批是否通过、是否被财务退回)人工抽样——既保吞吐,又在大分歧样本上有人工仲裁27。

8. 日志、失败分类与修复队列​

日志在上线后的身份变了:不再是调试的附属品,而是系统能否被信任的基础设施—— 一次工具调用为什么发生、参数是什么、返回了什么、模型如何解读、下一步做了什么,都要可回放。 没有记录,团队只能听系统事后讲故事28。轨迹回放还有一个妙用: 把同一批历史任务交给新版本重跑,比较决策差异——比只看最终成功率信息量大得多, 而且直接复用了线上真实出现过的边角输入(空字符串还是 null、字段名拼错一个字母、 时延踩到超时阈值),这些没人能事先设计出来29。

书里开头那场事故值得完整读一遍:周一早上,员工反映「报销单被自动提交给了去年的部门主管」。 没日志只能猜;有日志,十分钟定位到——审批人服务接口在上周末改了一个字段名, 智能体读到空值后落回了缓存里的旧主管。事故进入失败队列,优先级按影响面、是否伴随写动作、 会不会在其他工具上重演来排30。

修复队列按三件事排序:出现频率、业务后果、修复杠杆。书里把报销智能体的失败队列拆得像一份真实工单板: 「审批接口字段漂移」频次高、修复杠杆大,排最优先;「金额归类错」要看错的是规则还是模型,分流处理; 「旧表单跨字段引用错」频次低但单次后果重;「员工大量改字段」频次高单次轻但累计成本高。 这种排序帮团队避开两个陷阱:只盯最近炸的那类(忘掉高频低伤的慢性病), 或只盯单次后果最重的那类(其实长尾且修复杠杆低)31。

9. 数据闭环与版本演进:回灌必须筛选​

持续改进绕不开数据闭环:上线后最有价值的数据来自真实任务的成功轨迹、失败轨迹、人工接管点和返工记录 ——比离线示例脏、碎、难整理,但最贴近真实短板32。

但闭环不等于「把线上所有轨迹拿去继续训练」:真实数据混着偶然成功、误导性路径和噪声, 不加筛选地回灌,模型会学到错误习惯,甚至把本该拦下的行为也吸收进去。 数据闭环真正重要的是筛选机制而非数量:哪些进高质量训练集、哪些只配当失败案例、 哪些必须标为高风险异常33。人工纠错在这里不可替代,而且人类的价值不在重写最优解, 而在指出关键分岔点——这里为什么该停、那里为什么该换工具;这样的反馈告诉系统的不是结果标签, 而是行动边界34。

版本演进也随之升级:每次升级连着轨迹数据更新、工具定义变化、提示模板调整、规则检查器强化—— 成熟团队真正维护的,与其说是模型版本号,不如说是整套智能体运行栈的版本历史; 这样线上波动时才知道是哪一层改动带来的收益或回退,而不是把所有改动当成一个新版本整体回滚35。 书里连「回灌比例」都给了参照:一周几千条轨迹里值得回灌的往往只有几百条; 员工改字段的轨迹很有价值,但必须先标清原因是模型猜错还是员工改主意, 否则会把随机偏好当成纠错信号训进去;最有价值的通常是事故复盘里的反例—— 审批人填错那条轨迹,标注后同时进训练集(教它空值要停)和难例集(发布前必须识别)36。

10. 状态对象与检查点​

聊天系统可以把上下文藏在对话历史里,智能体不行。它一旦操作文件、网页、数据库, 状态就必须对象化:当前目标是什么、已完成哪些步骤、哪些工具调用已生效、哪些待确认、 哪些外部资源被锁定——都要能被系统和人类同时读懂。状态不清楚时,失败恢复常常变成第二次事故的起点37。

检查点为此而设:长任务推进到关键节点时,记录一份可恢复快照——当前工作区、关键变量、 已执行副作用、待办列表、回滚方式。中断后从检查点继续;走偏后退回稳定状态; 人工接管时,人也能快速看懂「现在停在哪里」38。

书里把报销场景的状态对象写到了字段级,值得整段当模板抄走39: 当前任务=张三 5 月上海差旅报销;已完成=查日程、查差旅记录、初步归类; 待执行=填表、员工二次确认、提交审批;已生效副作用=拉取了哪几张发票文件、读取了哪些档案字段; 锁定资源=审批服务里一个未提交的报销草稿 ID;待确认动作=某一行是否归「研发出差/跨城市」。 检查点放在填表完成、进入二次确认之前——员工离开几小时,系统不催;重开时从快照恢复,不重查日程; 审批服务超时,回到检查点而不重置整个任务。重复填一遍表是糟糕体验,反复触发审批服务则可能直接变成事故40。

11. 部署成本要分层​

上线后工程关注点再次变化:除了「能不能做」,还要看「做一次多少钱」「高峰撑不撑得住」 「失败率可不可控」「升级会不会把旧任务做坏」。智能体的成本账比问答服务多出环境交互和长运行时间41。

书里把报销智能体的成本拆到账目级:端到端一张报销 = LLM 推断(读对话、决策、生成表单、自检约 5–15K 词元)

  • 工具调用(日程、差旅、审批各一两次)+ 可能的发票 OCR + 偶尔的影子复核。分层策略: 简单标准报销走轻量模型加规则模板,平均成本压到几分钱; 跨币种、大额或跨部门的复杂报销升级强模型加一道人工确认,单次成本涨 5–10 倍,但出错代价成比例下降42。 两端都是死路:全走强模型,系统再准也烧不起;全走最轻,事故率高到员工不敢用。 能长期跑下去的部署,是按风险层级自动选成本档位——让 90% 的低风险报销几乎不花钱,剩下 10% 舍得花43。

12. 发布判据:门槛清单守「均值漂亮」和「长尾不爆」​

一个反复出现的现实问题:离线评测不错,不自动等于线上变好——离线集干净可控, 真实环境里全是脏输入、灰色任务、突发中断和组织摩擦;甚至可能因为策略更激进, 把少量关键失败放大得更明显44。所以发布决策不能建立在单一离线分数上,要同时看: 离线成功率与轨迹质量、影子运行的误操作、人工接管率、单位成本、高风险场景的失败模式有没有恶化45。

书里给出了一份可以直接抄走的门槛清单(数字为书内示例口径)46:

  • 离线回归集任务成功率不退化超过 1 个百分点;
  • 难例集中事故级错误(发错审批人、金额错归、重复提交)零次;
  • 影子运行下与员工实际操作的字段差异率不上升超过 2 个百分点;
  • 员工二次确认时的接管率不超过 15%;
  • 单位任务平均成本不上升超过 20%;
  • 高风险动作(改主管、修改大额、跨部门转嫁)的频率不显著增加——任一项不达标就阻止发布。

清单的价值在它能拦下一个典型陷阱:某次升级整体成功率涨了 2 个百分点,事故级错误却从 0 涨到 5—— 只看均值会让它通过,只看清单才能拦下。发布判据要让「均值漂亮」和「长尾不爆」都成为通行的必要条件47。

13. 仿真、影子运行与分级放量​

从实验室到线上,最危险的跳跃是直接接触真实副作用。稳妥路径分四阶: 离线回放历史任务 → 仿真/沙箱环境 → 影子运行(看它会怎么做,但暂时不让它真做—— 系统给建议,由旧系统或人执行,团队比较差异)→ 小流量放量48。

分级放量还应和分级授权绑定:低风险读操作早开放,写操作、外发、支付、删改晚开放, 配合回滚、熔断和人工确认——上线是一组逐步扩大行动半径的工程决策,不是按一下开关49。

书里把四阶段落到了日程上,时间感很真实50: 第一阶段离线回放去年的真实报销,重点复现已知边角案例;第二阶段进沙箱,连镜像审批服务、写测试库, 真能填表但提交不进真审批;第三阶段影子运行,每天对着员工实际报销生成自己的版本但不提交,每周差异采样复核; 第四阶段灰度 20–50 名志愿员工,盯接管率和高风险动作;最后才全公司。 分级授权同步:前三阶段只读写测试库,灰度允许 2000 元以下自动提交,全量后跨币种/大于 5000 元/跨部门仍留人工确认。 整条路 2–3 个月,代价是部署速度——对一个直接影响员工报销和公司财务的系统,这点代价划算51。

14. 双层闭环:研发管改进,运营管活着​

很多团队一开始把智能体当研发对象,重点全在模型、提示和 benchmark;系统进入真实业务后, 另一层很快浮现:运营。智能体要被开发,同样要被值守、被监控、被限流、被升级、被回退、被解释52。 那些「不够学术」的问题迅速变得关键:夜间告警怎么处理、长任务卡多久算故障、哪些失败自动重试、 哪些必须人工接管——一个模型很强但运营很弱的智能体,仍然撑不起严肃场景53。

于是形成双层闭环:上层研发闭环,失败案例进数据集、评测集扩充、训练迭代; 下层运营闭环,线上监控发现异常、告警触发人工处理、按流量和风险动态限权降级。 只有两层一起转,智能体才能从「不断改进的原型」变成「可被组织持续依赖的系统」54。 团队构成也随之变化:从模型研究者和应用工程师,扩展到懂运行时、风险控制、日志分析、发布策略的人—— 问题不再只是「模型聪不聪明」,而是「整个组织有没有能力把它长期养稳」55。 书里连两个闭环的交接界面都写了:运营在监控里看到「审批接口字段漂移」告警上升,转事故工单给研发; 研发评估是升级工具适配层还是重新微调;新版本过完发布门禁,再回运营手里灰度放量—— 组织没设计好这条交接路径时,事故就卡在「谁该出手」上,而不是卡在模型能力上56。

15. 环境版本与可复现性:世界也在换版本​

一个经常要到线上出问题后才被认真对待的事实:智能体依赖的环境本身在不断变化—— 网页布局会改、按钮文案会换、接口参数会调整。很多「模型突然变差」, 真正原因不在权重发生了什么神秘变化,而在智能体面对的外部世界悄悄换了形状57。

所以环境也要版本化:评测集不只记任务描述,还要记当时的页面快照、工具版本、接口模式; 轨迹数据带环境元信息,否则同一条成功路径在下一个版本里无法复现。可复现性因此成了成熟度的隐性指标—— 失败案例不能稳定重放,就分不清偶发噪声还是结构问题;成功案例不能稳定复现,就沉淀不成训练样本58。 书里预判:环境兼容性测试很可能会像今天的软件回归测试一样,成为每次发布前的固定环节59。 企业内尤其如此:审批服务每月小升级、差旅服务季度大升级;运维维护一份「环境清单」 (接口字段 schema、典型返回样例、已知边角案例、与上一版的差异),每条线上轨迹附带运行时环境版本, 事故复盘能精确到「这条轨迹用的是审批服务 v2.3,该版本的『代理审批人』字段曾返回空值」60。 没有这套机制,一句「审批服务昨天 11 点升级了一下」就可能让今天上午的所有报销都填错,且找不到根因。

16. 回归集、SLO 与变更门禁​

系统频繁迭代后,那个最现实的问题浮上来:每次升级,靠什么保证没把原本能做好的事情做坏? 模型换了、提示改了、工具定义变了、环境接口升级了——单看每项都合理, 只要其中一项和旧行为耦合,就可能在某类任务上意外退化。所以成熟团队都要回归集: 关键任务、典型失败案例、高风险边界样本,每次变更后重跑61。

但只有回归集不够,还要有服务水平目标(SLO,Service Level Objective——用一组长期指标描述系统应该维持的服务水平): 任务成功率、人工接管率、平均完成时长、单位成本、异常重试比例、高风险动作误触发率。 它的意义是把「看起来更聪明了」翻译成「系统层面有没有真的更稳、更省、更可控」; 没有这层指标,版本升级很容易只在演示任务上更强,在整体运行中更脆62。

变更门禁再把两者接进发布流程:新版本不能因为离线样例好看就上线,要过固定回归、影子比较、 小流量灰度和风险样本验证;新增写权限工具、修改检查点策略、调整人工接管阈值这类高风险变更, 还要更严格的审批。书里连 SLO 的双口径都给了:「连续 7 天达标」防慢性漂移,「单日不破底线」防尖刺事故; 门禁按改动类型分级——提示小改直接灰度,模型权重升级走完整四阶段,新增写权限要安全评审, 调接管阈值要业务方同意。这些门禁看似拖慢节奏,换来的是可持续的迭代速度, 因为团队不必一次次在上线后用事故教育自己63。收束句值得记下: 成熟的智能体工程在每次加新能力时都会问一句:旧能力还能不能稳住64。

17. 值班、事故响应与复盘知识库​

智能体上线后的事故形态是新的:无限循环、异常重试、工具调用雪崩、状态污染、越权动作、成本飙升、 接管率突增、外部环境漂移——它们不像传统故障那样表现为「服务挂了」, 更像系统仍在运行,却以错误方式运行。值班体系要能快速冻结会话、保留现场、切断高风险权限、 把问题归到明确类型65。

复盘的目标不该停在一份事故报告上:每次事故都应沉淀成可复用资产—— 一条新的门禁规则、一个新的高风险样本、一个新的监控指标、一段值班手册、一个需要重写的工具接口。 事故报告读完就归档;这五类资产会在下一次发布前被回归集跑到、被门禁拦到、被告警盯到。 书里的总结句是全章最好的结尾之一:长期运行的智能体,靠的是把教训写进规则的能力, 而不是靠某个人还记得去年踩过的坑66。

书里连值班的一天都写了:每天一名工程师 on-call,盯告警趋势(审批接口异常、成本激增、接管率突增三类单独着色)、 逐条抽看高风险动作日志、每天随机抽几条接管轨迹判断是模型(算法)问题还是员工偏好; 事故响应有预演过的 runbook(值班手册)——审批接口漂移告警触发后自动降级只读,运营发出通知(告知全员)让员工当天只填表不自动提交, 研发并行排查,修复后再灰度恢复67。

至此,智能体从研究原型变成了工程对象:有训练数据,有评测尺度,能上线也能回退,能持续改进, 也能在事故后留下可学习的痕迹。下一章,行动闭环从软件世界推向物理世界—— 当智能体要驱动机械臂和真实传感器时,训练、评测和安全边界都会进一步变得具体。

主走查:一张差旅报销单的完整工程闭环​

这条走查贯穿本章。 输入不变:员工一句「上周去上海开会,帮我报了」。 这次看的不是智能体怎么填表,而是整个系统怎么围绕这张表单转起来。 凡书里给出的数注明;凡我编的标明演示。

① 轨迹记什么。(§2) 这次任务的轨迹七字段齐全:目标(报销上海差旅)、环境状态(日程/差旅/审批三个服务的返回)、 工具调用顺序、模型决策(归类「研发出差/跨城市」的依据)、人工接管点(员工二次确认)、 最终结果(审批通过)。六个字段少了任何一个,后面所有环节都断了证据链。

② 环境反馈的时差。(§3) 提交那一刻系统记录预期:「审批将一次通过」。三天后实际反馈:主管退回,理由是酒店超标。 预期与实际的差异本身就是一条高价值训练样本——归因不是「任务失败」,而是「分类环节没查差标」, 带时间维度的信号,比成功/失败标签值钱得多。

③ 三层评判器给三个答案。(§7) 同一单按三个口径判定:规则脚本判「表单完整、金额一致——成功」; 产品埋点判「员工改了 1 个字段——体验瑕疵」; 人工抽样判「审批退回一次——合规预警」。三个数字都不错,单看哪个都会骗人;三个一起看才是真相。

④ 一次事故的回放。(§8) 某周一,多位员工的报销单被提交给了「去年的主管」。轨迹回放十分钟定位: 审批人服务周末改了字段名,接口返回空值,智能体落回缓存旧主管。 修复上线后,把那几条历史轨迹用新版本重跑——新版本在空值处停下来请求确认,事故修复成立。 这条事故轨迹随后同时进入两个集合:训练集(教它空值要停)和难例集(发布前必跑)。

⑤ 分层部署算成本。(§11) 这张普通报销走轻量模型加规则模板,成本约 3 分钱(书内口径的量级,具体数为演示); 同一天另一张跨币种报销升级强模型加人工确认,成本约 3 角(演示设定,倍数取书里的 5–10 倍区间下沿)。 90% 的简单单几乎不花钱,10% 的复杂单舍得花——按风险自动选档。

⑥ 发布前过门槛清单。(§12 §13) 新版本上线前:回归集成功率退化 0.3 个百分点(阈值 1)——过;难例集事故级错误 0 次——过; 影子运行字段差异率 +0.8 个百分点(阈值 2)——过;灰度 30 名志愿员工,接管率 12%(阈值 15)——过(以上判定数为演示设定,阈值来自书里的清单)。 四阶段走完 9 周(演示设定,书里说全程约 2–3 个月),分级授权同步:2000 元以下才允许自动提交。

⑦ 上线之后的日常。(§14–§17) 周三灰度到 10%,周四监控发现「跨部门协作报销」成功率降 8 个百分点(书里的例子), 周五回退并把失败轨迹加入未来评测集;复盘产出五类资产——新门禁规则(接口返回空值必须停下请确认)、 新难例、新监控指标(空值返回率告警)、runbook 补充、给上游团队的接口命名稳定性建议。 下个月同类事故的处置时间,从半天缩短到半小时——这就是「把教训写进规则」的复利。

作者的判断与证据​

书里给出明确数字或可复算例子的地方:

  • 三种成功口径差 10–20 个百分点、80/5 的任务分箱与 95%/50% 的成功率对照、5–15K 词元的单次推断量、 成本 5–10 倍的分层差、门槛清单的全部阈值、2–3 个月的分级放量周期、灰度 10% 时跨部门成功率降 8 个百分点—— 这些都是书里明确给出的示例口径(书中以办公智能体为虚构案例,数字为示例设定,书里以「通常」「可以」等措辞标注)182742465163;
  • SWE-bench 与 SWE-agent 是配对而非同一件工作、各 benchmark 的能力切面,与公开文献一致14;
  • 事故案例(字段改名→空值→缓存旧主管)是书里构造的完整教学案例,机制与真实接口漂移事故同构30。

书里标成判断或立场的地方:

  • 「轨迹是四个环节的共同语言」「可观测性是训练数据、评测集和安全审计的共同来源」——作者的工程定性428;
  • 「评测天花板在评判器」「系统难改进常因团队没形成稳定的好坏判断」——作者的组织学判断26;
  • 「环境兼容性测试将成为发布前固定环节」——作者的预判,标明是趋势59;
  • 「智能体改进速度越快,线上波动反而可能越大(若无发布与回退机制)」——经验性警句45。

判断(我们的,不是书里的): 这一章真正的主角不是智能体,而是**「事故」的组织学**。 全章的每一件工程(轨迹、回归集、门槛清单、SLO、runbook、复盘五资产)都在做同一件事: 把「这次为什么错」从口头记忆变成可执行资产。据此我们给出一个选型判断: 评估任何团队「能不能养智能体」,别看它的模型评测分,看它有没有一张「失败分类 × 修复杠杆」的 活工单板和一份季度滚动的难例集——这两样存在,说明闭环在转;不存在,演示分数再高也会烂在线上。 如果错,会错在: 极强的模型可能让失败率低到「不修也行」,工单板和难例集沦为过度工程—— 但书里 13.5 节的环境漂移论证恰好堵住了这条路:失败不只来自模型,还来自世界换版本, 模型再强也要接住「审批服务改了个字段名」这种事。

边界与局限​

  • 对应关系: 本章对应原书第 13 章全文。原书的「办公流程智能体」贯穿案例被本组拆解完整保留——它是全章论证的骨架,不是装饰。
  • 没展开的: 各 benchmark(WebArena/OSWorld/GAIA 等)的内部构成在第 11 章和扩展阅读里点到为止;PPO 等训练算法的机制在第 13 章 §16 讲过,本章只谈训练数据与信号;多模态识别(发票 OCR)只作为成本项出现。
  • 数字的诚实声明: 书中的报销金额、成功率、成本、周期均为作者构造的示例设定(书里用「通常」「可以这样写」标注),不是某家企业的实测数据;引用时本组拆解全部注明「书内示例口径」。
  • 时效性: benchmark 格局截至成书;SLO/门禁的具体阈值(1 个百分点、15% 接管率等)是示例而非行业标准,落地时按业务重定。

可带走的​

  1. 跑通演示 ≠ 系统成熟——中间隔着可观察、可验证、可恢复、可运营四个词,每个词背后是一套工程。
  2. 轨迹是共同语言,日志上线后是信任基础设施;环境反馈是新的监督信号,延迟反馈要能归因回具体动作;轨迹要带环境版本号,用历史轨迹重放新版本比临时编用例更接近现实。
  3. 成功率会撒谎:给任务画像、按切片看覆盖率——均值漂亮掩盖低频高风险切片,而事故恰恰住在那里。
  4. 评测集分三层:回归集防退化、滚动集防脱节、难例集防事故复发;评判器本身要被评测——标注协议先写清,模型裁判不当真理用。
  5. 修复队列按频率×后果×杠杆排序——别只盯最近炸的那类,也别只盯最吓人的那类。
  6. 数据回灌必须筛选:一周几千条轨迹值得回灌的往往只有几百条;把随机偏好当纠错信号训进去比不训更糟。
  7. 状态要对象化,检查点放节点上:状态不清时,失败恢复就是第二次事故的起点。
  8. 成本按风险分层:90% 的低风险任务几乎不花钱,10% 的高风险任务舍得花——两端(全强/全轻)都是死路。
  9. 发布靠门槛清单不靠均值;上线是逐步扩大行动半径的工程决策(回放→沙箱→影子→灰度)——让「均值漂亮」和「长尾不爆」同时成为必要条件,授权跟着阶段一起放大。
  10. 研发闭环之外还有运营闭环;复盘要产出五类资产(门禁规则/难例/监控指标/runbook/接口修订)——长期运行的智能体,靠把教训写进规则,不靠有人记得去年的坑。

原文地图​

主题原书节原文位置
演示不等于成熟13 引言text/14-ch13.txt:11(搜“实世界后可能会在边角场景”) · text/14-ch13.txt:13(搜“变成“稳定可用””)
贯穿案例上线追问13 引言text/14-ch13.txt:412(搜“高风险场景”) · text/14-ch13.txt:18(搜“灰度发布和回滚开关”)
工程闭环图13 引言text/14-ch13.txt:22(搜“权限门禁、回滚开关和”)
轨迹是共同语言13.1.1text/14-ch13.txt:46(搜“共同语言”) · text/14-ch13.txt:49(搜“本该”)
七字段13.1.1text/14-ch13.txt:52(搜“人工接管点和最终结果”) · text/14-ch13.txt:54(搜“什么情况下会失败”)
报销轨迹字段13.1.1text/14-ch13.txt:58(搜“5 月 12–14 日”) · text/14-ch13.txt:59(搜“研发出差/跨城市”) · text/14-ch13.txt:64(搜“会议名记错”)
数据闭环起点13.1.1text/14-ch13.txt:69(搜“先查日程，再去碰差旅服务”) · text/14-ch13.txt:70(搜“数据闭环的起点”)
环境反馈13.1.2text/14-ch13.txt:76(搜“环境用结果告诉你成没成”) · text/14-ch13.txt:83(搜“噪声大、反馈稀疏”)
延迟反馈归因13.1.2text/14-ch13.txt:100(搜“批可能要一天、对账可能要一个月”) · text/14-ch13.txt:101(搜“归因回当时的具体动作”) · text/14-ch13.txt:108(搜“在哪一步开始与现实不一致”)
受控环境13.1.2text/14-ch13.txt:89(搜“模仿学习”) · text/14-ch13.txt:92(搜“不把真实世界当成试验场”) · text/14-ch13.txt:95(搜“安全前提”)
成功率之外13.2.1text/14-ch13.txt:3(搜““能不能完成””) · text/14-ch13.txt:127(搜“只看成功率也不够”) · text/14-ch12.txt 不适用
轨迹质量13.2.1text/14-ch13.txt:128(搜“轨迹质量就成为第二层重要指标”) · text/14-ch13.txt:131(搜“侥幸成功的系统给不出来的”)
benchmark 切面13.2.1text/14-ch13.txt:119(搜“掉链子”) · text/14-ch13.txt:138(搜“OSWorld”) · text/14-ch13.txt:140(搜“配对而非同一件”) · text/14-ch13.txt:145(搜“系统能力”)
回归测试13.2.1text/14-ch13.txt:148(搜“任务回放集和失败案例集”) · text/14-ch13.txt:149(搜“带出两个新问题”)
任务画像13.2.2text/14-ch13.txt:159(搜“一整片任务分布”) · text/14-ch13.txt:164(搜“任务画像”) · text/14-ch13.txt:169(搜“平均分提高了”)
覆盖率13.2.2text/14-ch13.txt:173(搜“覆盖率因此真正”) · text/14-ch13.txt:178(搜“任务世界”)
80/5 分箱13.2.2text/14-ch13.txt:183(搜“500–5000”) · text/14-ch13.txt:186(搜“50% 以下”) · text/14-ch13.txt:187(搜“低频高风险切片”)
评测污染与漂移13.2.3text/14-ch13.txt:191(搜“做熟”) · text/14-ch13.txt:195(搜“今天失效”)
三层评测集13.2.3text/14-ch13.txt:196(搜“稳定回归集”) · text/14-ch13.txt:197(搜“高风险难例集”) · text/14-ch13.txt:202(搜“滚动版本”)
评判器也要评测13.2.4text/14-ch13.txt:209(搜“尺子，本身是否可靠”) · text/14-ch13.txt:213(搜“摇晃的地基”)
标注协议13.2.4text/14-ch13.txt:214(搜“标注协议”) · text/14-ch13.txt:217(搜“主动停下并请求人工确认”) · text/14-ch13.txt:221(搜“不断漂移”)
模型裁判与分层评判13.2.4text/14-ch13.txt:222(搜“模型裁判”) · text/14-ch13.txt:224(搜“客观真理”) · text/14-ch13.txt:226(搜“仲裁池”)
一致性即指标13.2.4text/14-ch13.txt:228(搜“标注一致性本身也应成为工程指标”) · text/14-ch13.txt:231(搜““好坏判断””)
三层口径13.2.4text/14-ch13.txt:255(搜“差出 10–20 个百分点”) · text/14-ch13.txt:256(搜“规则脚本判定”) · text/14-ch13.txt:259(搜“人工仲裁”)
报销事故13.3text/14-ch13.txt:115(搜“去年的部门主管”) · text/14-ch13.txt:267(搜“落回了缓存里的旧主管”) · text/14-ch13.txt:270(搜““玄学””)
日志即信任13.3.1text/14-ch13.txt:273(搜“日志让失败可回放”) · text/14-ch13.txt:67(搜“事后”) · text/14-ch13.txt:280(搜“共同来源”)
轨迹重放13.3.1text/14-ch13.txt:281(搜“审批主管发错”) · text/14-ch13.txt:287(搜“超时阈值”)
修复队列13.3.2text/14-ch13.txt:291(搜“频率有多高、业务后果有多重”) · text/14-ch13.txt:298(搜“审批接口字段漂移”) · text/14-ch13.txt:309(搜“慢性病”)
数据闭环筛选13.3.3text/14-ch13.txt:312(搜“数据回灌必须筛选”) · text/14-ch13.txt:318(搜“错误习惯”) · text/14-ch13.txt:321(搜“高风险异常”)
人工纠错13.3.3text/14-ch13.txt:322(搜“不可替代”) · text/14-ch13.txt:325(搜“行动边界”)
运行栈版本史13.3.3text/14-ch13.txt:328(搜“版本历史”) · text/14-ch13.txt:337(搜“定位到具体改动层”)
回灌比例13.3.3text/14-ch13.txt:330(搜“几千条轨迹”) · text/14-ch13.txt:333(搜“随机偏好当成纠错信号”) · text/14-ch13.txt:334(搜“教模型接口返回空值时应该停下来”)
状态对象13.3.4text/14-ch13.txt:342(搜“状态就必须对象化”) · text/14-ch13.txt:346(搜“第二次事故的起点”)
检查点13.3.4text/14-ch13.txt:347(搜“可恢复快照”) · text/14-ch13.txt:349(搜“停在哪里”)
报销状态对象13.3.4text/14-ch13.txt:354(搜“未提交报销草稿”) · text/14-ch13.txt:356(搜“从头再查一遍日程”) · text/14-ch13.txt:358(搜“变成事故”)
成本分层13.4.1text/14-ch13.txt:380(搜“分层”) · text/14-ch13.txt:396(搜“5–15K token”) · text/14-ch13.txt:398(搜“几分钱”) · text/14-ch13.txt:399(搜“5–10 倍”) · text/14-ch13.txt:401(搜“成本档位”)
离线不等于线上13.4.2text/14-ch13.txt:406(搜“更干净、更可控”) · text/14-ch13.txt:409(搜“更明显”)
发布指标组13.4.2text/14-ch13.txt:411(搜“人工接管率是否”) · text/14-ch13.txt:413(搜“门槛条件”)
门槛清单13.4.2text/14-ch13.txt:422(搜“不退化超”) · text/14-ch13.txt:426(搜“15%”) · text/14-ch13.txt:427(搜“跨部门转嫁”) · text/14-ch13.txt:429(搜“0 涨到 5”) · text/14-ch13.txt:430(搜““均值漂亮”和“长尾不爆””)
影子运行13.4.3text/14-ch13.txt:434(搜“影子运行”) · text/14-ch13.txt:435(搜“暂时不让它真的做”)
分级授权13.4.3text/14-ch13.txt:438(搜“分级授权绑定”) · text/14-ch13.txt:440(搜“行动半径的工程决策”)
四阶段13.4.3text/14-ch13.txt:442(搜“镜像版的审批服务”) · text/14-ch13.txt:444(搜“20–50 名志愿员工”) · text/14-ch13.txt:446(搜“2000 元以下”) · text/14-ch13.txt:447(搜“2–3 个月”) · text/14-ch13.txt:449(搜“代价划算”)
双层闭环13.5.1text/14-ch13.txt:465(搜“被值守、被监控、被限流”) · text/14-ch13.txt:471(搜“难以支撑严肃场景”) · text/14-ch13.txt:457(搜“双层闭环”) · text/14-ch13.txt:475(搜“持续依赖的系统”) · text/14-ch13.txt:480(搜“长期养稳”) · text/14-ch13.txt:488(搜““谁该出手””)
环境版本13.5.2text/14-ch13.txt:496(搜“悄悄换了形状”) · text/14-ch13.txt:498(搜“环境元信息”) · text/14-ch13.txt:505(搜“环境镜像”) · text/14-ch13.txt:509(搜“成为每次发布前的固”)
环境清单13.5.2text/14-ch13.txt:513(搜““环境清单””) · text/14-ch13.txt:516(搜“v2.3”) · text/14-ch13.txt:519(搜“都填错”)
回归集与 SLO13.5.3text/14-ch13.txt:525(搜“回归集”) · text/14-ch13.txt:530(搜“更稳、更省、更可控”) · text/14-ch13.txt:533(搜“变更门禁”) · text/14-ch13.txt:537(搜“用事故教育自己”) · text/14-ch13.txt:540(搜“旧能力还能不能稳住”)
SLO 双口径与分级门禁13.5.3text/14-ch13.txt:545(搜“几角钱以内”) · text/14-ch13.txt:545(搜“连续 7 天达标”) · text/14-ch13.txt:547(搜“完整 4 阶段验证”) · text/14-ch13.txt:549(搜“比团队为门禁等几天大”)
新事故形态13.5.4text/14-ch13.txt:554(搜“成本飙升”) · text/14-ch13.txt:555(搜“以错误方式运行”)
复盘五资产13.5.4text/14-ch13.txt:558(搜“可复用资产”) · text/14-ch13.txt:562(搜“去年踩过的坑”)
值班 runbook13.5.4text/14-ch13.txt:564(搜“接管轨迹采样”) · text/14-ch13.txt:568(搜“空值返回率告警”) · text/14-ch13.txt:570(搜“处置时间会明显缩短”)

Footnotes​

  1. 出处:「13 引言」图 13.1 段(text/14-ch13.txt:22,搜“权限门禁、回滚开关和”)与第 23 段(text/14-ch13.txt:23,搜“SLO 则像护栏”)。 ↩

  2. 出处:第 11 段(text/14-ch13.txt:11,搜“实世界后可能会在边角场景”)。 ↩

  3. 出处:第 412 段(text/14-ch13.txt:412,搜“高风险场景”)与第 18 段(text/14-ch13.txt:18,搜“灰度发布和回滚开关”)。 ↩

  4. 出处:「13.1.1」第 46 段(text/14-ch13.txt:46,搜“共同语言”)。 ↩ ↩2

  5. 出处:第 51 段(text/14-ch13.txt:51,搜“还要收集过程”)与第 52 段(text/14-ch13.txt:52,搜“人工接管点和最终结果”)。 ↩

  6. 出处:第 58 段(text/14-ch13.txt:58,搜“5 月 12–14 日”)、第 59 段(text/14-ch13.txt:59,搜“研发出差/跨城市”)、第 64 段(text/14-ch13.txt:64,搜“会议名记错”)。 ↩

  7. 出处:第 70 段(text/14-ch13.txt:70,搜“数据闭环的起点”)。 ↩

  8. 出处:「13.1.2」第 76 段(text/14-ch13.txt:76,搜“环境用结果告诉你成没成”)。 ↩

  9. 出处:第 83 段(text/14-ch13.txt:83,搜“噪声大、反馈稀疏”)与第 100 段(text/14-ch13.txt:100,搜“批可能要一天、对账可能要一个月”)。 ↩

  10. 出处:第 102 段(text/14-ch13.txt:102,搜“当时的预期反馈”)与第 108 段(text/14-ch13.txt:108,搜“在哪一步开始与现实不一致”)。 ↩

  11. 出处:第 89 段(text/14-ch13.txt:89,搜“模仿学习”)、第 92 段(text/14-ch13.txt:92,搜“不把真实世界当成试验场”)、第 95 段(text/14-ch13.txt:95,搜“安全前提”)。 ↩

  12. 出处:「13.2.1」第 127 段(text/14-ch13.txt:127,搜“只看成功率也不够”)。 ↩

  13. 出处:第 128 段(text/14-ch13.txt:128,搜“轨迹质量就成为第二层重要指标”)与第 131 段(text/14-ch13.txt:131,搜“侥幸成功的系统给不出来的”)。 ↩

  14. 出处:第 137 段(text/14-ch13.txt:137,搜“WebArena”)、第 138 段(text/14-ch13.txt:138,搜“OSWorld”)、第 140 段(text/14-ch13.txt:140,搜“配对而非同一件”)、第 145 段(text/14-ch13.txt:145,搜“系统能力”)。 ↩ ↩2

  15. 出处:第 148 段(text/14-ch13.txt:148,搜“任务回放集和失败案例集”)与第 149 段(text/14-ch13.txt:149,搜“带出两个新问题”)。 ↩

  16. 出处:「13.2.2」第 159 段(text/14-ch13.txt:159,搜“一整片任务分布”)。 ↩

  17. 出处:第 164 段(text/14-ch13.txt:164,搜“任务画像”)与第 169 段(text/14-ch13.txt:169,搜“平均分提高了”)。 ↩

  18. 出处:第 183 段(text/14-ch13.txt:183,搜“500–5000”)、第 186 段(text/14-ch13.txt:186,搜“50% 以下”)、第 187 段(text/14-ch13.txt:187,搜“低频高风险切片”)。 ↩ ↩2

  19. 出处:第 175 段(text/14-ch13.txt:175,搜“反过来帮助组织决策”)与第 178 段(text/14-ch13.txt:178,搜“任务世界”)。 ↩

  20. 出处:「13.2.3」第 191 段(text/14-ch13.txt:191,搜“做熟”)与第 195 段(text/14-ch13.txt:195,搜“今天失效”)。 ↩

  21. 出处:第 196 段(text/14-ch13.txt:196,搜“稳定回归集”)与第 197 段(text/14-ch13.txt:197,搜“高风险难例集”)。 ↩

  22. 出处:第 202 段(text/14-ch13.txt:202,搜“滚动版本”)与第 205 段(text/14-ch13.txt:205,搜“偷偷复发”)。 ↩

  23. 出处:「13.2.4」第 209 段(text/14-ch13.txt:209,搜“尺子，本身是否可靠”)与第 213 段(text/14-ch13.txt:213,搜“摇晃的地基”)。 ↩

  24. 出处:第 214 段(text/14-ch13.txt:214,搜“标注协议”)、第 217 段(text/14-ch13.txt:217,搜“主动停下并请求人工确认”)、第 221 段(text/14-ch13.txt:221,搜“不断漂移”)。 ↩

  25. 出处:第 222 段(text/14-ch13.txt:222,搜“模型裁判”)、第 224 段(text/14-ch13.txt:224,搜“客观真理”)、第 226 段(text/14-ch13.txt:226,搜“仲裁池”)。 ↩

  26. 出处:第 228 段(text/14-ch13.txt:228,搜“标注一致性本身也应成为工程指标”)与第 231 段(text/14-ch13.txt:231,搜““好坏判断””)。 ↩ ↩2

  27. 出处:第 255 段(text/14-ch13.txt:255,搜“差出 10–20 个百分点”)、第 256 段(text/14-ch13.txt:256,搜“规则脚本判定”)、第 259 段(text/14-ch13.txt:259,搜“人工仲裁”)。 ↩ ↩2

  28. 出处:「13.3.1」第 273 段(text/14-ch13.txt:273,搜“日志让失败可回放”)与第 280 段(text/14-ch13.txt:280,搜“共同来源”)。 ↩ ↩2

  29. 出处:第 281 段(text/14-ch13.txt:281,搜“审批主管发错”)与第 286 段(text/14-ch13.txt:286,搜“没人能事先设计出来的细节”)。 ↩

  30. 出处:「13.3」引言第 115 段(text/14-ch13.txt:115,搜“去年的部门主管”)与第 267 段(text/14-ch13.txt:267,搜“落回了缓存里的旧主管”)。 ↩ ↩2

  31. 出处:「13.3.2」第 291 段(text/14-ch13.txt:291,搜“频率有多高、业务后果有多重”)、第 298 段(text/14-ch13.txt:298,搜“审批接口字段漂移”)、第 309 段(text/14-ch13.txt:309,搜“慢性病”)。 ↩

  32. 出处:「13.3.3」第 312 段(text/14-ch13.txt:312,搜“数据回灌必须筛选”)。 ↩

  33. 出处:第 318 段(text/14-ch13.txt:318,搜“错误习惯”)与第 321 段(text/14-ch13.txt:321,搜“高风险异常”)。 ↩

  34. 出处:第 322 段(text/14-ch13.txt:322,搜“不可替代”)与第 325 段(text/14-ch13.txt:325,搜“行动边界”)。 ↩

  35. 出处:第 328 段(text/14-ch13.txt:328,搜“版本历史”)与第 337 段(text/14-ch13.txt:337,搜“定位到具体改动层”)。 ↩

  36. 出处:第 330 段(text/14-ch13.txt:330,搜“几千条轨迹”)、第 333 段(text/14-ch13.txt:333,搜“随机偏好当成纠错信号”)、第 334 段(text/14-ch13.txt:334,搜“教模型接口返回空值时应该停下来”)。 ↩

  37. 出处:「13.3.4」第 342 段(text/14-ch13.txt:342,搜“状态就必须对象化”)与第 346 段(text/14-ch13.txt:346,搜“第二次事故的起点”)。 ↩

  38. 出处:第 347 段(text/14-ch13.txt:347,搜“可恢复快照”)与第 349 段(text/14-ch13.txt:349,搜“停在哪里”)。 ↩

  39. 出处:第 354 段(text/14-ch13.txt:354,搜“未提交报销草稿”)与第 59 段(text/14-ch13.txt:59,搜““研发出差/跨城市””)。 ↩

  40. 出处:第 357 段(text/14-ch13.txt:357,搜“不必直接重置整个任务”)与第 358 段(text/14-ch13.txt:358,搜“变成事故”)。 ↩

  41. 出处:「13.4.1」第 377 段(text/14-ch13.txt:377,搜“推断成本”)。 ↩

  42. 出处:第 396 段(text/14-ch13.txt:396,搜“5–15K token”)、第 398 段(text/14-ch13.txt:398,搜“几分钱”)、第 399 段(text/14-ch13.txt:399,搜“5–10 倍”)。 ↩ ↩2

  43. 出处:第 401 段(text/14-ch13.txt:401,搜“成本档位”)。 ↩

  44. 出处:「13.4.2」第 406 段(text/14-ch13.txt:406,搜“更干净、更可控”)与第 409 段(text/14-ch13.txt:409,搜“更明显”)。 ↩

  45. 出处:第 411 段(text/14-ch13.txt:411,搜“人工接管率是否”)与「13.4.1」第 394 段(text/14-ch13.txt:394,搜“线上波动反而可能越大”)。 ↩ ↩2

  46. 出处:第 422 段(text/14-ch13.txt:422,搜“不退化超”)、第 426 段(text/14-ch13.txt:426,搜“15%”)、第 427 段(text/14-ch13.txt:427,搜“跨部门转嫁”)。 ↩ ↩2

  47. 出处:第 429 段(text/14-ch13.txt:429,搜“0 涨到 5”)与第 430 段(text/14-ch13.txt:430,搜““均值漂亮”和“长尾不爆””)。 ↩

  48. 出处:「13.4.3」第 434 段(text/14-ch13.txt:434,搜“影子运行”)与第 435 段(text/14-ch13.txt:435,搜“暂时不让它真的做”)。 ↩

  49. 出处:第 438 段(text/14-ch13.txt:438,搜“分级授权绑定”)与第 440 段(text/14-ch13.txt:440,搜“行动半径的工程决策”)。 ↩

  50. 出处:第 442 段(text/14-ch13.txt:442,搜“镜像版的审批服务”)、第 444 段(text/14-ch13.txt:444,搜“20–50 名志愿员工”)、第 446 段(text/14-ch13.txt:446,搜“2000 元以下”)。 ↩

  51. 出处:第 447 段(text/14-ch13.txt:447,搜“2–3 个月”)与第 449 段(text/14-ch13.txt:449,搜“代价划算”)。 ↩ ↩2

  52. 出处:「13.5.1」第 465 段(text/14-ch13.txt:465,搜“被值守、被监控、被限流”)。 ↩

  53. 出处:第 471 段(text/14-ch13.txt:471,搜“难以支撑严肃场景”)。 ↩

  54. 出处:第 457 段(text/14-ch13.txt:457,搜“双层闭环”)与第 475 段(text/14-ch13.txt:475,搜“持续依赖的系统”)。 ↩

  55. 出处:第 477 段(text/14-ch13.txt:477,搜“团队分工”)与第 480 段(text/14-ch13.txt:480,搜“长期养稳”)。 ↩

  56. 出处:第 487 段(text/14-ch13.txt:487,搜“灰度放量”)与第 488 段(text/14-ch13.txt:488,搜““谁该出手””)。 ↩

  57. 出处:「13.5.2」第 496 段(text/14-ch13.txt:496,搜“悄悄换了形状”)。 ↩

  58. 出处:第 498 段(text/14-ch13.txt:498,搜“环境元信息”)与第 506 段(text/14-ch13.txt:506,搜“持续改进的前提”)。 ↩

  59. 出处:第 509 段(text/14-ch13.txt:509,搜“成为每次发布前的固”)。 ↩ ↩2

  60. 出处:第 513 段(text/14-ch13.txt:513,搜““环境清单””)、第 516 段(text/14-ch13.txt:516,搜“v2.3”)、第 519 段(text/14-ch13.txt:519,搜“都填错”)。 ↩

  61. 出处:「13.5.3」第 525 段(text/14-ch13.txt:525,搜“回归集”)。 ↩

  62. 出处:第 530 段(text/14-ch13.txt:530,搜“更稳、更省、更可控”)与第 532 段(text/14-ch13.txt:532,搜“变得更脆”)。 ↩

  63. 出处:第 533 段(text/14-ch13.txt:533,搜“变更门禁”)、第 537 段(text/14-ch13.txt:537,搜“用事故教育自己”)、第 545 段(text/14-ch13.txt:545,搜“连续 7 天达标”)、第 547 段(text/14-ch13.txt:547,搜“完整 4 阶段验证”)。 ↩ ↩2

  64. 出处:第 540 段(text/14-ch13.txt:540,搜“旧能力还能不能稳住”)。 ↩

  65. 出处:「13.5.4」第 554 段(text/14-ch13.txt:554,搜“成本飙升”)与第 555 段(text/14-ch13.txt:555,搜“以错误方式运行”)。 ↩

  66. 出处:第 558 段(text/14-ch13.txt:558,搜“可复用资产”)与第 562 段(text/14-ch13.txt:562,搜“去年踩过的坑”)。 ↩

  67. 出处:第 564 段(text/14-ch13.txt:564,搜“接管轨迹采样”)、第 568 段(text/14-ch13.txt:568,搜“空值返回率告警”)、第 570 段(text/14-ch13.txt:570,搜“处置时间会明显缩短”)。 ↩