8.1 从 Demo 到产线：开发生命周期与部署形态
8.1 从 Demo 到产线：开发生命周期与部署形态
本节摘要：智能体的开发不是一条直线，而是一个"设计—原型—评测—部署"的循环，其中评测是循环得以收敛的枢纽。本节给出四阶段生命周期的操作要点，以及按决策主体划分的四种部署形态——内嵌助手、副驾驶、后台自治、智能体服务——并给出形态选择的判断依据。
演示日的成功最容易制造幻觉：一个流畅跑通的任务视频，让人以为产品只差"部署上去"。真实差距藏在三个演示永远不会遇到的东西里：并发（一百个人同时让它订会议室）、方差（十次执行两次跑偏）、责任（订错了谁买单）。生命周期与部署形态，就是管理这三个差距的框架。
图：开发生命周期——评测是把循环收敛起来的枢纽
四阶段各自的通关标准
设计阶段产出的是三份清单：能力清单（要用到前七章的哪些组件）、风险清单（哪些动作不可逆、哪些数据敏感）、介入点清单（人必须在哪些环节拍板）。设计阶段的常见欠账是风险清单——它不产出演示效果，却是 8.5 检查单的原料。
原型阶段的纪律是小而真：任务范围收窄到一个场景，工具接真实系统（mock 数据会掩盖观察清洗、权限、超时这些问题），用户找十个真的。原型期的核心产出不是能跑的代码，而是失败模式的第一手清单——它决定评测集长什么样。
评测阶段的通关线要提前谈定：成功率、动作违规率、p95 步数、单任务成本，四项指标的目标值写进发布标准。这里最容易发生的博弈是"差不多了先上线"——防线就是把目标值写进 8.5 的检查单，达标放行，不达标回炉，拒绝临场解释。
部署阶段的关键词是灰度：先内测用户后全量，先只读场景后写操作，先副驾驶后自治。每一次放开灰度范围，都是一次缩小的重新上线，检查单重新过一遍。
案例：一个订票智能体的两次形态修正
背景：团队为销售团队做了机票酒店预订智能体，初版按"后台自治"设计：收到差旅申请后自动完成预订。
操作：内测期事故频出——转机时间订得太短、特价票不可退改未提示、重复预订。第一次修正把它降级为副驾驶形态：智能体出两三个合规选项，销售自己点选确认。运行三个月后数据稳定，团队再把"确定无疑的部分"（按固定标准的常规往返）切回半自治：标准行程自动预订、非标行程走副驾驶。
结果：最终形态是副驾驶与自治的混合体，事故率降到底线以内，销售的人均订票耗时仍比全人工缩短大半。
解读：这个案例展示了形态选择的正确姿势——不是选一次，而是按风险分级拆开：确定性高、可回滚的部分给自治，模糊或有不可逆风险的部分留给人的判断。形态是光谱不是四选一。
变式：多模态输入（拍照识别发票、语音派单）与具身执行（控制实体设备）是形态光谱上正在延伸的两端——它们改变的是感知与执行的介质，本册的组件化方法论（契约、记忆、规划、护栏）原样适用，只是观察与动作的形态变了。
⚠️ 常见坑：把"上线"当成项目终点。智能体是会漂移的系统——上游数据变了、业务口径改了、模型服务升级了，都可能让原本达标的表现悄悄退化。上线只是把系统放进了一个持续评测、持续修护栏的循环里。
本节要点回顾
- 评测是生命周期枢纽：不达标回原型，达标才部署；线上轨迹回流评测集，循环永续。
- 形态按决策主体划分：内嵌、副驾驶、后台自治、智能体服务——人保留多少决策权是分界线。
- 形态是光谱：按风险分级拆开，确定部分自治、模糊部分副驾驶，混合是常态。
- 灰度即缩小的重新上线：每次放开范围都重过检查单，拒绝"差不多就全量"。
下一节进入最普适的场景：个人助理与自动化——权限、中断恢复这些看似琐碎的细节，恰恰决定这类产品能否被信任。
设计阶段的沟通工具：能力-风险对照表
设计阶段的产出常常是文档厚、共识薄。一份一页纸的"能力-风险对照表"比四十页的方案文档更能促成共识：左列列出智能体将拥有的每项能力（查订单、改订单、发邮件、退款），右列对应三栏——出错表现（发错邮件 vs 退错款）、可逆性（可撤回 vs 不可逆）、需要的把关（无 / 抽检 / 全审）。这张表的价值在于把抽象的风险讨论变成逐行的确认：业务方在每一行上签字，等于对"机器能自主做什么"完成了逐项授权。后续护栏（7.3）的介入点配置，直接从表的最后一栏导出；评测集（7.1）的用例分布，按出错代价加权。设计阶段的这张表，是全册工程纪律的第一个落点。
团队分工与技能画像
智能体项目的团队配置与传统后端有微妙差异。核心角色三个：场景工程师——懂业务口径，负责工具设计与契约撰写（本册 2.1、4.1 的活），这个角色往往被低估，却是决定系统"懂不懂业务"的关键；平台工程师——负责循环、记忆、检索这些基础设施（第 2、3、6 章）；评测与安全负责人——7、8 两章的活，从第一天就参与而不是上线前救火。三个角色可以由两三个人兼任，但职责不能缺位——特别是第三个，多数翻车项目复盘时都会发现：评测与安全的活，默认落在了"谁有空谁做"的真空里。
生命周期各阶段的常见卡点
四个阶段各有典型卡点，提前知道可以少走弯路。设计阶段卡在"需求方说不清验收标准"——解法是拿 8.1 的能力-风险对照表逐行对齐，让"大概要个助手"变成十行可确认的条目。原型阶段卡在工具接入——内部系统的接口文档残缺、测试环境受限，往往一个工具的联调就吃掉一周；解法是原型期只接两三个核心工具，其余用带标注的静态样例顶替，先把循环跑通。评测阶段卡在评测集从零写起——解法是回看原型期与内测期的轨迹，失败案例改写为用例的速度远快于凭空编写。部署阶段卡在灰度范围之争——业务方想快，工程方想稳；解法是把灰度档位与风险等级绑定（只读场景先放、写操作后放、外发动作最后），让节奏有据可依。四个卡点的共同解药是：每一阶段的产出物都为下一阶段的卡点预备材料——对照表喂护栏，轨迹喂评测，灰度档位喂部署节奏。
发布节奏：把大爆炸拆成小台阶
生命周期最后落到一个时间问题上：从"评测达标"到"全量上线"隔多久、走几步。参考节奏是三级灰度、每级一个观察期：内测级（十人以内的项目组自己人，跑一周，看的是崩溃与基本可用性）、种子级（一到两个真实业务团队，跑两周，看的是口径冲突与工具权限问题——这两类问题只有真实业务数据才能暴露）、扩量级（按团队或按流量比例逐周放开，每一档稳定后再进下一档）。三级走完通常六到八周，比"憋一个大版本直接全量"慢，但每次放开都踩在实测过的地面上。经验规律是：灰度期每提前一周，全量后的事故复盘就多一次——智能体系统的缺陷暴露天然需要真实流量，这个时间没有捷径可省。