生产工程与上线评审

1. 从可演示到可运行：本周不增加新业务功能

执行型 Agent 已能完成合成任务，本周要回答的是：它能否在真实运行条件下被控制、定位故障和交接。生产工程不是最后补一页部署说明，而是把第 8 周的动作链放到身份、网络、并发、故障、成本和运维责任之中重新检查。

上线就绪至少看六个维度：功能是否符合契约；性能与可靠性是否满足工作节奏；安全与数据边界是否可执行；问题是否可观测；配置与升级是否可维护；每项有效任务的成本是否可接受。某一个维度的漂亮指标不能替代其他维度。

2. 输入和输出防护：区分内容判断与权限控制

输入防护应覆盖类型、长度、范围、格式和注入风险。用户文本、检索文档、工具返回和外部网页都可能包含指令式内容；它们不应自动获得修改系统规则或调用高权限工具的能力。最小权限、工具白名单、参数校验和授权检查仍由服务端负责。

输出防护检查是否包含不允许的数据、是否引用适用证据、是否宣称未发生的动作、是否超出专业或业务范围。可以使用模型辅助发现问题，但不能让模型自评“安全”成为唯一安全控制。对高风险动作，应该有程序可检查的前置条件和明确的人类责任。

参阅 OWASP Prompt Injection ↗了解威胁类别。这里的控制组合是教学设计，不能保证对所有攻击有效，需要持续测试和更新。

3. 日志、指标和 Trace 分别解决什么问题

日志记录离散事件，例如权限拒绝、连接器超时、确认过期；指标描述聚合运行情况，例如任务失败率、P95 延迟、未知动作数量和费用；Trace 将一次用户任务中的模型调用、工具调用和外部请求连接起来，用于定位哪一步出现问题。

每条关键动作至少关联任务 ID、租户、操作者引用、工具、参数摘要、策略版本、数据快照、动作 ID、状态和时间。审计记录关心谁在什么权限下批准和执行了什么，不能只保存模型生成的解释。模型的可见调用记录和输出摘要足够用于很多审查，不需要收集隐藏思维过程。

{
  "trace_id": "synthetic-trace-001",
  "task_id": "task-0042",
  "tenant_ref": "teaching-tenant",
  "actor_ref": "operator-a",
  "tool": "issue_coupon",
  "action_id": "action-007",
  "payload_digest": "digest-of-canonical-payload",
  "policy_version": "campaign-1",
  "confirmation_ref": "confirmation-003",
  "status": "unknown",
  "error_code": "DOWNSTREAM_TIMEOUT",
  "sensitive_payload_logged": false
}

这只是审计字段示例。生产日志还需不可随意修改的存储、访问控制、保留和检索策略。不要默认记录完整提示、手机号、原始文档或密钥。可参考 OpenTelemetry GenAI 语义约定 ↗，但应核对所用版本及稳定性，避免把课程字段当成规范的全部要求。

4. 可靠性：超时、重试、并发与熔断

分别设置整项任务、模型调用和工具调用的时间预算。多个环节各自默认重试三次，叠加后可能放大外部请求和成本。重试应考虑错误类型、剩余预算、幂等性和下游限流；权限拒绝和参数错误通常不应靠重试解决。

为模型循环设置最大步数、工具次数、费用和任务截止时间。达到限制时返回明确未完成状态，并保留已完成与待处理部分。不要在未知状态下继续发起同类写动作。外部服务持续失败时，可暂停相关动作，保留只读能力或转人工，而不是让每个用户反复撞到同一个故障。

并发预算和幂等记录应放在有事务语义的持久化存储中。进程内锁能保护同一进程，但无法协调多副本。先画出同时两个请求到达时的状态变化，再设计唯一键、状态机和事务边界。系统声称“可回滚”时，应逐一说明代码、配置、数据和外部副作用分别如何处理。

5. 灰度、停用与回退

灰度不是把流量百分比从 1 改到 100 的动画。先定义范围：哪些租户、哪些用户、哪些工具、哪些数据条件可以使用新版本。模型、提示、工具、规则与数据契约共同组成一个发布单元，避免只记模型版本却忘记活动规则已经变化。

停止条件应结合实际风险设定。本课不给适用于所有企业的统一失败率。准备独立动作停用开关，确保在模型仍能回答时也能禁止写操作；保留回查能力，以免停用后无法核对正在执行的任务。

回退演练必须在上线前做一次：切回旧配置、冻结新动作、处理在途请求、核对下游状态、报告用户影响。回退成功的标准是恢复受控状态，不是服务进程重新变绿。

6. 基础设施与部署责任

托管、私有和混合方案都要说明网络、身份、密钥、存储、备份、升级和故障责任。私有环境还需要考虑硬件容量、驱动与模型服务兼容、模型分发、监控连通和运维值守。选型不要只比较模型单次价格。

建议制作一张依赖表：组件、版本、责任角色、恢复方式、数据状态、升级窗口、替代方案。核心依赖没有负责人时，即使技术可以运行，也不能认为已完成交接。部署参数和样例配置可以进入版本库，真实凭据只能进入适当的秘密管理系统。

本地模型与托管模型需要运行同一任务集，比较工具选择、结构化输出、长上下文、失败恢复、延迟和费用。不要因为都能生成中文，就假定二者可直接互换。

7. 成本工程：计算每项有效完成任务的成本

只看 token 单价会漏掉工具调用、检索、重试、人工复核、基础设施与失败补救。先按任务记录费用，再按用户、场景、租户和版本聚合。关键指标之一是“总成本 ÷ 有效完成任务数”，并定义有效完成的条件。

总成本 = 模型 + 工具/检索 + 基础设施分摊 + 人工复核 + 失败补救
单位有效任务成本 = 总成本 / 达到质量与执行条件的完成任务数

使用合成例子：1,000 次任务共花费 5,600 元，其中 850 次达到定义的完成条件，单位成本约 6.59 元。这个数字只示范计算方法，不是 AIelsen 报价或客户成本。分母为零时应报告不可计算，不能显示成本为零。

优化顺序应基于测量：删除不必要上下文；减少重复检索；改善工具返回格式；对有证据支持的任务使用更便宜模型；使用范围正确的缓存。模型路由必须经同一评估集比较，不能凭“这个问题看起来简单”就降低能力。

缓存键至少考虑租户、权限范围、数据时效、模型/提示/规则版本和任务参数。语义相似不代表业务等价，尤其涉及金额、日期、会员或产品版本时。执行动作不能因为问题相似就复用上次的确认或结果。

8. 人工介入、值守与交接

明确哪些情况系统自动完成，哪些需要确认，哪些必须由专业人员处理。人工介入不是一个按钮，而是一条有人接收、知道依据、能够采取动作并留下结果的工作路径。需要写明响应角色、处理时限、升级条件和用户通知方式；这些属于项目约定，不由本网站替团队承诺 SLA。

运行手册至少包含：常见错误码与排查顺序；动作未知的对账方法；停用开关；回退步骤；日志位置和访问申请；数据更新与模型升级；成本异常；安全事件处理；责任联系人用角色表示。交接时让接手者依据手册完成一次故障恢复，不让原作者在旁边口头补全所有缺失步骤。

9. 案例分析与上线评审演练

阅读 Tampa General Hospital 运营协同案例，观察资源信息怎样进入当班团队的协调工作。本周将方法迁移到合成设备维修：工单需要特定资质，人员具备资质但可用状态已经过期。系统应先重新确认资源，再分配任务；过期、无人接单和接口故障都有明确的人工恢复路径。

FDE 需要提交数据时效规则、接手状态机、人工覆盖记录与恢复 Runbook。评审时注入一次状态更新延迟，检查系统是否错误分派，以及告警究竟由谁接收。本演练限于设备运营，不涉及临床决策。

回到合成零售项目，评审者临时问：“动作服务刚超时，业务说券已经收到，现在重试安全吗？”优秀回答不是“我们有重试机制”，而是说明动作 ID、状态查询、幂等记录和人工对账如何共同决定下一步；如果证据不足，应明确暂不重试并说明验证路径。

10. 必做作业、思考与验收

必做：实现按租户/工具的灰度与写动作停用配置；扩展客户审计字段；加入输入/输出检查、超时与有限重试、任务预算；提交监控与告警设计；完成一次故障注入和回退演练；交付上线检查表与运行手册。

思考：质量提高但人工复核时间翻倍，是否应发布？如果减少复核会降低成本却削弱风险控制，你如何设计分级策略并验证，而不是直接删掉人工环节？

进阶：将进程内幂等记录改为持久化事务；模拟多副本竞争和重启恢复；或者把现有审计字段映射到所选可观测平台并记录未覆盖能力。

验收要求：至少能定位一条任务完整链路；关键安全失败阻断写入；未知动作可对账；重试和模型循环有上限；权限和缓存范围一致；回退不冒充撤销外部副作用；成本包含失败与人工；接手者可独立完成指定故障演练。只有部署截图，不满足本周要求。