先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
行为配置的发布与回滚
考察行为版本、回归门槛、影子流量与线上归因。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 行为配置的发布与回滚
先理解核心原理
先备概念：版本管理、灰度对照、外部副作用
Agent 行为由提示、模型、工具、数据和策略共同决定。发布需要能关联完整配置，回滚只能恢复未来执行条件，不能撤销已经发生的业务事实。
两句话也可能改变控制流
普通代码改变分支会影响行为，Prompt 改动也可能使模型多调用工具、错误拒绝或遗漏确认。只对文本做 diff 不能估计风险；把模型标识、消息模板、工具 schema、检索配置和权限策略一起版本化，给每次运行写入配置清单。
灰度比较需要同口径
按稳定用户或任务分组，让新旧版本面对可比较流量，检查任务终态、违规、副作用、延迟与费用。若新版本只接简单任务，总分提升没有说服力。离线反例先拦明显错误，灰度再检查真实分布。
回滚不是时间倒流
发出去的邮件、已经创建的退款不会因为 Prompt 恢复而消失。在途任务仍携带旧状态与版本，可能需要暂停写动作、保留旧 worker 或重新审批。以下发布方案是风险驱动建议，实际灰度比例与阈值需按业务选择，没有虚构线上发布结果。
用一个问题检查理解
Prompt 改了两句话，为什么也需要像代码一样做灰度与回滚？
Prompt、模型、工具定义、检索和权限策略共同决定行为，修改提示词也可能改变选工具、拒答和副作用。我会把这些配置作为可追溯版本，先跑固定回归集与风险测试，再按稳定分组灰度。写操作的影子测试不能实际双写。回滚要恢复完整行为配置，并保留已执行事实；线上异常需能关联到运行使用的具体版本。
实现与取舍
行为版本由多项配置组成
每个运行记录模型、Prompt、工具 Schema、检索索引、评分器和策略版本。只存一个应用 Git SHA 可能无法解释外部模型或动态配置变化。版本快照应可重建，但不能把秘密凭证直接写入日志。长期运行在途时，要明确配置锁定还是受控升级。
发布前验证
比较固定回归集、过去失败集、拒答和越权样本。除了成功率，还看多余工具调用、错误写动作、Token 和延迟。若新提示词让模型更积极，平均完成率提高可能同时增加错误操作，风险门槛不能被平均分抵消。评分器变更要与被评系统变更分开。
灰度和影子
用稳定用户或任务键分配流量，避免同一会话随机切版本。影子侧可以对只读检索或动作计划做比较，生产写工具必须禁用、模拟或指向隔离环境。设置最短观察期和最小样本，同时监测队列、失败类型及回执，发现严重违规立即停止新增动作。
回滚不是抹除历史
恢复旧行为配置只影响后续决策，不会取消已发出的邮件或发布。对在途任务按版本策略处理，对已发生副作用按业务补偿核对。保留事故样本和明确根因，把复现加入回归。面试者应能说明哪个指标触发暂停，谁能回滚，以及怎样证明回滚真正生效。
工程推演
- 场景
- 面试假设：加一句“主动完成任务”后，Agent 开始跳过必要澄清。
- 设计决策
- 将主动性变更放入含歧义和写动作的回归与灰度。
- 验证目标
- 错误自动操作触发暂停，并能定位具体配置版本。
- 适用边界
- 灰度门槛需结合任务量与风险，而不是固定百分比即可通用。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层模型供应商版本变化怎么追踪？
行为发布依赖供应商模型，也需解释可追溯范围。
参考解答
记录请求实际使用的模型标识、可得的响应元信息、配置摘要与时间，不把营销名称等同不可变权重。能固定具体版本时固定；无法固定时设供应商变更观察和行为回归，承认未公开实现无法精确追踪，不伪造版本号。
第 1 层影子流量调用发信工具怎么办？
真实流量对照涉及写工具，必须处理双写风险。
参考解答
影子执行必须拦截真实发信，用替身记录拟发送内容与参数，再离线比较。不能让两个版本都拿生产发信凭证。若需验证真实投递，在独立测试收件人与明确授权下做受控验证，影子结果不能宣称真实客户已收到。
第 1 层回滚后旧任务是否自动变安全？
回滚影响配置后，仍需处理携带旧状态的在途任务。
参考解答
不会。旧任务可能已有旧工具计划、过期审批或不同状态格式。按任务阶段与所用配置分类，暂停危险动作，重验权限和批准，再决定继续旧版、迁移或人工处理。已发生事实留账，不能重置任务冒充未执行。
沿着这个回答继续深入
第 2 层旧任务正等人工批准，新版删掉了对应工具，怎样恢复？
父问指出旧任务未自动安全，子问选审批等待中的工具变更。
参考解答
保留能解释旧状态的处理版本或执行显式迁移；验证原动作仍被业务支持。删除工具不应自动把旧批准映射到新动作。无法对应时暂停并向用户说明需要重新提案，保持旧记录和批准绑定，避免凭同名字段猜测意图。
沿着这个回答继续深入
第 3 层迁移后参数看似相同，可以复用旧批准吗？
父问需要显式迁移，再追问状态兼容是否等于批准兼容。
参考解答
只有规范化动作语义、目标、权限、资源版本和有效期全部仍满足原批准范围时才可考虑。若工具实现或默认值改变，表面参数相同也可能产生不同效果，应重新批准。迁移先保存可审计映射，不能把字段一致当行为等价。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
纯文本问答更新
改变的条件：无写工具，主要风险是错误回答与费用上升。
延伸问题：仍要保存完整配置吗？
推导与参考解答
需要保存足以解释行为的提示、模型、检索版本和结果证据，但可按风险简化门禁。固定问答回归与可比较灰度观察忠实性、拒答和费用；回滚后核对缓存是否仍返回新版本内容，避免配置恢复但答案未恢复。
保持不变的原理：发布结论必须可归因于实际执行配置。
跨天订单处理更新
改变的条件：任务持续数日并包含外部提交。
延伸问题：能直接替换所有 worker 吗？
推导与参考解答
先盘点在途状态和待审动作，给旧任务保持兼容执行或显式迁移，发布写网关仍重验权限与幂等。新任务可走新版本，旧任务不必强制立即迁移；灰度与回滚策略需包括队列和已执行效果。
保持不变的原理：配置回滚不能覆盖业务历史与恢复边界。
易错点
- Prompt 不算代码无需发布流程
- 影子写操作双执行
- 回滚只换模型名
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 把提示词改动作为行为变更，安排版本、回归与回滚。
- 中高级信号
- 提出稳定分组与无副作用影子评测。
- 资深信号
- 完整说明在途任务、风险门槛与行为配置归因。
动手验证 按需完成 · 建议 15 分钟
为提示词改动列出上线门槛、灰度信号和回滚后的任务处理。
展开验收要求与检查点
- 副作用风险独立设门槛
- 每次运行关联配置版本
- 在途任务不被静默换语义
重点检查
- Prompt 纳入完整行为版本
- 灰度指标覆盖副作用
- 回滚保留外部事实