第 23 章 · 上线前的那道门
老板先看这一句： 上线门禁不是工程师的官僚手续,是替企业拦住「效果好但会闯祸」的最后一道坝——权限没隔离、敏感信息裸奔、出错查不到、危险动作没人兜底、出事关不掉,任何一条爆了都是你的品牌和合规事故。你要问技术负责人一句:「上线前这五扇门,哪一项还没过?没过的,能不能为赶进度先上再补?」记住:凡说「先上了再说」的,补的那天往往就是出事那天——这道门不能为赶进度跳。
效果好,不等于能上线
有个项目,PoC 阶段所有指标都漂亮,业务方拍板要上线。工程师觉得「效果都达标了,部署一下就完事」,当天就把它接进了生产客服系统。
第三天出事了:一个客户问了句刁钻的话,AI 把另一个客户的订单信息答了出去——权限没隔离干净。更糟的是,团队想查「到底怎么泄的」,发现没有日志;想紧急关掉,发现没有开关,只能连夜把整个服务下线,客服瘫了半天。
效果达标,是「这东西有用」;能上线,是「这东西用起来不会闯祸」。这是两道完全不同的关。 前一道靠第 22 章的评估过,后一道,靠这一章要讲的上线门禁。
Agent 落地工程师戴上监控运维官这顶帽子,守的就是这道门。门禁的原则只有一条:逐项打勾,缺一项都不上线。 它不是官僚流程,是拦住「效果好但会闯祸」的东西冲进生产的最后一道拦河坝。完整清单见附录 F,这一章讲清最要命的五扇门。
五扇必须关好的门
上线门禁项目不少,但最容易出人命的是这五扇。
第一扇:权限——谁能看什么、做什么。 开头那个泄露事故,就是这扇门没关。必须确认:不同用户/租户之间数据隔离,AI 不会把 A 的信息答给 B;每个工具的调用权限最小化,该只读的绝不给写权限。
📎 技术深读:沙箱隔离、工具安全执行的工程实现,见 Harness Agent Book · 第 27 章;多租户数据隔离见 第 28 章。
第二扇:数据脱敏——敏感信息不裸奔。 凡是碰到个人敏感信息(PII)——手机号、身份证、账号——要么不落地,要么脱敏。这不只是技术要求,是法律红线。涉及客户 PII 或内部数据的场景,这扇门是重中之重。
第三扇:审计日志——出了事查得到。 「谁在什么时候让 AI 做了什么、AI 调了哪些工具、结果如何、有没有人审过」——全都要有日志。开头那个事故查不出原因,就是缺了这扇门。没有审计日志的 AI 系统,等于开着一辆没有行车记录仪的车上高速。
第四扇:人审机制——危险动作有人兜底。 第 3、7 章反复讲的人审门,到上线这一刻要落成真机制,不是写在文档里的口号。对外发送、涉及金额、删除数据——这些动作必须真的卡着人工确认,而且要有日志证明「确实有人点过头」。
第五扇:回滚方案——错了能立刻收手。 开头那个「只能连夜下线」的窘境,就是没有回滚设计。上线前必须写死:什么信号出现就回滚、回滚做什么动作、谁有权按、按了通知谁。理想的回滚不是「拔电」,而是「降级」——比如 AI 出问题就自动切回纯人工,业务不中断。
上线前先明确：AI 到底能做多深
同一个场景可以有不同自动化等级。不要笼统地说“交给 AI”，而要逐项确定 AI 的权限深度、人工确认点和异常升级方式。
| AI 角色 | 它可以做什么 | 适合场景 | 门禁重点 |
|---|---|---|---|
| 提示 | 发现异常并通知人 | 库存预警、差评聚类 | 漏报率、通知对象、升级时限 |
| 建议 | 提出方案，由人决定是否采用 | 广告调整、采购建议 | 依据可追溯、风险提示、审批记录 |
| 判断 | 在规则范围内分类或评分 | 询盘意向、工单路由 | 置信阈值、拒答区、人工复核 |
| 执行 | 调用系统产生真实业务动作 | 创建工单、更新低风险字段 | 最小权限、金额或外发人审、回滚 |
自动化程度不是越高越好。高风险、低频、难回滚的动作，宁可先停在“建议”；低风险、高频、规则稳定的动作，才逐步放开执行权限。
一张门禁评审表
上线前开一场门禁评审会(第 21 章的关口会),拿这张表逐项过,当场判「上」或「不上」。
| 门 | 检查项 | 通过? | 没过怎么办 |
|---|---|---|---|
| 权限 | 租户/用户数据隔离、工具最小权限 | ☐ | 补隔离,重测 |
| 脱敏 | PII 不落地或已脱敏 | ☐ | 加脱敏,法务确认 |
| 审计 | 全链路日志(谁/何时/做了什么/人审) | ☐ | 补日志字段 |
| 人审 | 高风险动作真卡人工确认 | ☐ | 落成机制,非文档 |
| 回滚 | 触发条件/动作/负责人/降级策略齐全 | ☐ | 写死回滚预案 |
第 12 章那个案例,门禁评审时就有两项没过——审计日志字段不全、回滚触发条件没写死——没过就是没过,补齐才上,绝不「先上了再说」。这张表最大的价值,是把「要不要上线」从一个拍脑袋的决定,变成一个有据可查、责任清晰的评审结论。它同时也是给采购和安全团队看的合规证明。
企业里还可以把门禁映射成治理责任：
| 治理项 | 本书对应动作 | 责任人 | 证据 |
|---|---|---|---|
| 风险识别 | 场景卡风险栏、高风险样本 | Agent 落地工程师 + AIBP + 安全 | 风险清单 |
| 风险度量 | Golden Dataset、类别级指标 | Agent 落地工程师 + AIBP | 跑分报告 |
| 风险控制 | 权限、人审、脱敏、输出校验 | 技术负责人 + 安全 | 配置和评审记录 |
| 风险恢复 | 回滚、降级、事故通知 | 运维负责人 | Runbook 和演练记录 |
| 治理责任 | RACI、上线签字 | Sponsor + AIBP | 门禁评审结论 |
还要特别关注几类 LLM 应用常见风险：
| 风险 | 在项目里的表现 | 门禁动作 |
|---|---|---|
| Prompt Injection | 用户输入诱导 AI 忽略规则或泄露系统提示 | 输入隔离、工具调用前校验 |
| Sensitive Information Disclosure | 把客户隐私、内部资料或 A 租户数据答给 B | 脱敏、租户隔离、输出检查 |
| Insecure Output Handling | AI 输出直接写库、发客户、触发外部动作 | 高风险动作人审 |
| Excessive Agency | 工具给太多、权限过大，AI 能做不该做的事 | 最小授权、工具白名单 |
| Model Denial of Service | 循环过长、调用暴涨、成本失控 | 步数上限、成本告警、超时 |
门禁不是一次性的
一个提醒:门禁不是「上线那天过一次就完」。上线后,权限会变、数据会增、新功能会加——每次重大变更,都要回过头再走一遍相关的门。把门禁清单当成一个常驻的检查表,而不是上线仪式上用一次的道具。这也是从「上线」平滑过渡到「运营」(第 21 章)的关键。
上线前最好做一次回滚演练。不要只在文档里写「必要时降级」，而是现场按一遍：谁有权限关、关掉后用户看到什么、人工流程怎么接上、通知发给谁、恢复上线要满足什么条件。演练过的回滚，才是能用的回滚。
📍 场景示例：老陈的客服 Agent 想「立刻上生产」，被两扇门拦下
客服 Agent 在试点环境把首次响应从 18–24h 压到 2h、一次解决率从 60% 拉到 85%，老陈很想马上接进生产客服系统。FDE 拦住他，逐项过门禁清单：发现审计日志字段不全（谁在何时审过无从查证）、回滚只写了「必要时降级」却没写触发条件。两扇门没过，补齐后才上线——避免了「先上再补」变成泄密或拔电事故。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 上线决策 | 效果达标就冲生产 | 五扇门逐项打勾 |
| 审计 / 回滚 | 字段不全、无触发条件 | 全链路日志 + 写死预案 |
| 风险后果 | 出事查不到、只能拔电 | 可查、可降级、不中断 |
老板决策点： 任何一项门没过就不批上线——凡说「先上了再说」的，补的那天往往就是出事那天。 ——对应 → L3 迈向 L4
常见坑
- 效果达标就直接上。 把「有用」当成「能上线」,权限/日志/回滚全没做,第一次意外就是事故。
- 人审只写在文档里。 说「高风险要人审」,却没落成真机制、没有确认日志,等于没有。
- 没有回滚,只能拔电。 出事只能整个下线,业务大面积中断。要设计降级而非硬关。
- 门禁走个形式。 明明有项没过,为了赶进度「先上再补」——补的那天往往就是出事那天。
- 上线后就不再看门禁。 把它当一次性仪式,后续变更不复查,旧门重新裂开。
本章产出
老板行动点： 把门禁评审当成你签字放行的硬关卡——要求每次上线前拿出逐项打勾的评审表和回滚预案,任何一项没过就不批上线;上线后重大变更也要复查,别让这道门只走一次形式。
往交付包里放一份「上线门禁评审表 + 回滚预案」:
用 附录 F 的清单,为你的项目逐项打勾,把没过的项列成待办;并写死一份回滚预案(触发条件/回滚动作/负责人/降级策略)。这份评审表,是你敢对业务方说「这东西可以真上线了」的底气,也是出事时能快速止损的依据。
成熟度自检
- [ ] 我能用门禁清单逐项评审,守住权限/脱敏/审计/人审/回滚五扇门(→ L3 迈向 L4)
- [ ] 我能写死可执行的回滚与降级预案,并在每次变更后复查门禁(→ 巩固 L4)