系列开始时，小林在培训前遇到投屏故障，我们用一张任务卡、一条执行循环和几项受控工具，逐步把她的求助从模糊描述推进到真实工单。演示代码能跑，并不等于企业服务台已经可用。真正上线后，员工会在不同时间、不同页面重复提问；知识文档会更新，模型接口会超时，工单系统会维护，服务进程也可能重启。部署工作要保证这些变化发生时，业务结果仍可核对、可恢复。本篇把前面各章收束成一个可部署的最小系统：明确进程和数据边界，检查配置与健康状态，安排灰度、回滚和运营值守。它不依赖某个 Agent 平台；实际 Web 框架、数据库和队列可按企业已有技术栈选择。这里给出的是工程交付路径，不宣称文中的示例已经连接任何真实企业系统。文章目录上线目标仍然是小林的那件事把演示代码拆成可运行的服务边界启动配置、身份与密钥发布前要做哪些验收灰度上线与失败降级上线后怎样判断服务真正可用总结上线目标仍然是小林的那件事部署前先回到业务验收。员工应能提交会议室问题、补齐关键字段、获得当前有效资料；自助失败后，界面展示待建单内容，员工确认后才执行写入；查询进度时只看到本人有权查看的真实状态。系统异常时能说明当前状态并转人工，不制造重复工单。用户看到的能力服务端需要具备的保障可验收的证据连续对话不丢任务持久化任务状态与事件关闭页面后可恢复同一阶段看到适用指引文档版本、适用范围和权限过滤回答能核对资料来源确认后创建故障单身份校验、内容冻结、幂等写入一次确认只对应一张真实工单查询后续进度本人可见查询与状态映射回答与工单系统一致发生故障仍可交接结果不明回查、失败分类、人工渠道不把未知说成成功如果其中任何一项还只能靠开发者手工改数据库或在日志里猜结果，就不应把试点称为可用服务。上线范围可以小，但每一条开放的业务路径都要完整。
