第18章 从可运行实验走向可运营系统

把边界写成团队契约

企业接入 Agent 工具的难点，常常不是缺少某个库，而是多个团队各自假设别人已经负责授权。身份团队负责登录，网关团队负责路由，Agent 团队负责生成参数，业务团队以为请求已经可信。最终没有人承担“当前主体能否操作当前对象”的完整责任。

建议为每个敏感工具写一页契约：工具目的、主体来源、执行者、目标受众、租户来源、对象查询条件、动作范围、审批规则、撤权窗口、幂等语义、审计字段和故障行为。契约要由身份、平台、业务与产品共同确认。它不是合规清单，而是开发和事故处理时能直接使用的事实表。

一个工具若无法清楚表达对象和副作用，通常还不适合让 Agent 自动执行。可以先提供只读查询、生成待办或产生待审批计划。随着身份与业务边界完善，再开放小范围可撤销写入和敏感操作。自动化程度应由证据决定，而不是由演示中模型表现流畅决定。

生产替换次序

第一步用成熟身份平台替换教学登录与服务密钥，并完成真实用户流程的协议测试。第二步把主体、成员关系和授权版本接到权威目录或业务授权库。第三步用数据库事务替换内存对象、审批与审计，增加多实例并发和崩溃恢复。第四步引入真实审批人认证、展示内容固定与职责分离。第五步接支付、工单等真实系统时实现渠道幂等和对账。

每一步保持攻击回归。更换 JWT 库不能丢掉 audience 检查，更换网关不能丢掉服务端对象授权，增加缓存不能悄悄扩大撤权窗口，优化审批存储不能失去一次性消费。生产化不是把实验代码放到更大的机器上，而是用成熟组件替换简化部分，同时保留已经定义的行为契约。

失败案例是团队把实验中的公开开发密钥搬进 Kubernetes Secret，认为“现在已经是生产机密”。存储位置变了，凭据本身仍然公开。另一个案例是把监听改成 0.0.0.0，却保留无 TLS 的密码入口。迁移时应重新生成所有材料、关闭教学端点、按环境配置受众与 issuer，并审阅网络与身份信任根。

运营与事故响应

上线前至少演练用户撤权、服务密钥泄漏、签名键泄漏、审批撤回、身份平台故障与重复执行。每项演练需要操作步骤、最大传播时间、观察指标和恢复条件。系统应能暂停敏感工具而保留必要只读能力，并通过受控配置完成，而不是临时修改提示词希望模型自觉停止。

事故调查应从业务事实开始：发生了什么副作用，涉及哪些对象，责任主体与 actor 是谁，审批覆盖哪组参数，执行时版本是什么。然后检查凭据、策略、代理输入和依赖状态。模型对话可以提供背景，但不能替代业务提交、审批和外部流水。

最终上线判断要结合风险与限制。一个内部只读订单助手与一个自动大额退款 Agent，所需控制明显不同。不要因为本书实验覆盖很多拒绝样本，就把它当成所有行业的统一上线标准。它提供的是一组可运行的边界和推理方法，真实系统还要对自己的对象、流程与损失负责。

最后一次运行与练习

先执行 go test -race -v ./lab，再在隔离 Keycloak 环境运行真实身份测试，最后构建并验证所有阅读格式。下载实验包后在新目录解压，执行同样命令，确认文档没有依赖作者机器上的私有文件。这是交付质量的一部分：读者应能够复现结论，而不是只相信作者截图。

练习：选择一个你准备上线的工具，为它写一个最小发布范围和明确的停止条件。例如只读 Acme 订单，服务身份映射固定，不支持退款；或者允许单笔小额退款但要求真人审批。写出扩大范围前必须新增的实验，并指定每项事实由哪个服务负责。能够说清这些内容，才意味着团队真正掌握了 Agent 的执行边界。

给第一个工具设定清楚的成功标准

可以用一张订单读取工具开始：只接受固定身份来源，服务账户映射到明确租户，不返回支付敏感字段，身份依赖不可用时失败，审计可关联到真实主体与执行器。它的成功标准是合法读取可用、跨租户读取失败、错误受众失败、撤权窗口有实测结果，而不是模型能流畅回答多少种提问。

当加入退款时，再增加金额与货币规则、审批展示、摘要绑定、一次性消费、幂等恢复和外部对账。每增加一种副作用，就补充相应事实来源与失败实验。把这些增量写入发布说明，业务负责人才能理解能力扩大伴随了哪些控制，而非只看到工具数量增加。

最终，工具接入平台应让安全路径成为日常开发路径。新工具模板默认包含身份上下文、固定目标、对象授权钩子、审批契约与审计字段，评审者可以在少量代码中看到关键决定。这样既减少重复劳动，也让团队在规模扩大时仍然能够解释每一次 Agent 行动的责任边界。

还应为停止自动化保留受控入口。当发现异常退款或身份映射错误时，运营人员应能暂停特定工具、租户或执行器，同时保存已提交状态和审计。暂停操作需要独立权限和记录，恢复也要明确条件。一个只能通过修改模型提示来停机的系统，很难在事故压力下保持确定行为。这个控制面与业务授权同样值得在上线前演练。