一次推荐核心服务的发布，横跨十几个部署组、数千个 Pod，平均持续 10 多个小时，还要等次日真实流量验证效果。小红书技术团队把发布知识、操作步骤和异常处置沉淀成近 20 万字的 SKILL，交给 AI 执行。结果一次模型幻觉导致参数漏传，本应灰度发布的版本被直接推到了全部部署组。
这件事的教训不是"模型不够聪明"。知识完备不等于执行可靠，跨会话状态延续、故障恢复和动态变化，仍然需要模型之外的系统来兜底。
发布难在环节之间
发布不是一个瞬时动作。变更进入主干前，要经过代码评审、构建、自测和效果差异验证；版本确定后，要在部分部署组灰度、检测并依次放量；灰度完成后，还要等真实流量积累足够样本，确认推荐效果没有异常，才能推向全部部署组。
构建、测试、发布和检测早已各自自动化。难点出现在环节之间：
- 上一个平台产生结果后，谁来确认事实、检查条件并启动下一步
- 等待几个小时后，谁来恢复任务
- 计划发生变化时，谁来判断哪些动作已经失效
这类任务同时具备 Long-Running 和 Long-Horizon 两个特征。验证依赖真实时间，任务必须跨越会话、进程重启和执行实例切换持续存在；环节前后强依赖，前一步的真实结果决定下一步是否成立。
发布环境也不会保持静止。平台可能超时，指标可能波动，线上可能出现事故，发布范围也可能临时调整。一次错误动作已经作用于真实流量，后续回滚无法抹去此前的影响；一次接口调用成功，也不代表动作按预期生效。
SKILL 能传递知识，不能承载执行责任
团队最初用脚本封装固定动作，再把完整的发布知识整理成 SKILL，供 AI 执行时读取。随着覆盖范围扩大，新的步骤、条件和禁令不断加入，最终形成近 20 万字的操作手册。
模型已经能够理解发布流程并调用平台，但约束没有因此变得可靠。一次模型幻觉导致参数漏传，让本应灰度发布的版本直接在全部部署组推全。
这次问题暴露了提示词方案的边界：SKILL 可以描述"必须灰度"，却不能强制每次平台调用都携带正确范围；上下文可以记录对话，却不能成为跨昼夜任务的权威状态；模型可以生成计划，却无法保证计划在环境变化后仍然成立；工具可以返回调用结果，却不能证明生产环境中的实际效果。
继续补充提示词，只会增加模型需要理解的知识，不会产生持久化、并发控制、幂等、恢复和效果查证。发布知识可以写进 SKILL，执行责任必须交给模型之外的 Harness。
Harness 如何保障跨昼夜执行
团队构建的 Harness 位于 AI 与生产环境之间，负责长程任务的运行与控制。它将一次发布表示为可持久、可计算、可恢复的任务，并把必须稳定成立的约束放入确定性执行路径。
系统包含四个核心实体：
- 流程模板：定义发布步骤、前置条件、通过条件、时间条件、动作参数约束和授权边界
- 任务：保存一次发布的参数、进度、平台结果、未完成动作与已确认决定
- 引擎：依据模板和任务当前状态推导下一步，执行动作并写回结果
- 提案：AI 根据现场生成的调整方案，列明变更内容、影响步骤和可能触发的外部动作
AI 读取任务与外部证据，处理日志、指标、变更内容和自然语言意图，完成异常研判与方案生成。它不直接组装生产平台调用。引擎只依据模板和任务中已确认的状态发出动作。模型负责处理无法预先穷举的信息，确定性路径负责控制发布范围、步骤顺序和通过条件。
对跨昼夜发布来说，会话可以作为交互入口，不能作为状态来源。团队将目标、参数、步骤进展、平台结果、未完成动作和已确认决定写入独立任务，使其成为流程的权威状态。
任务发起时，使用的流程模板版本和参数会作为执行基线固定下来。运行期间即使模板发生变化，也不会影响已经开始的任务。每完成一步，新状态立即持久化；会话结束、进程崩溃或执行实例切换后，接续者只需读取当前任务，从已经确认的位置继续。
流程推进、平台回调和临时调整可能并发写入任务。多路更新通过基于版本号的乐观锁（CAS）协调。发生竞争时，执行方读取最新版本重新判断，旧结果不能覆盖新进展。任务保存的是已经发生的事实，而不是某个 AI 对历史过程的记忆。
流程模板以声明式方式定义步骤、依赖、通过条件、时间条件和动作约束。引擎以类似 Kubernetes Reconciliation Loop 的方式推进任务。每次调度时，它都会读取任务当前状态，与模板定义的目标比较，计算此刻可以执行的步骤。条件满足就登记动作；条件不满足就保留现场，并记录下一次检查时间。
定时起发、分组放量和次日效果观察都通过时间条件表达。等待期间不需要持续占用会话或线程。检查时间到达后，引擎重新读取任务与平台状态，再决定是否继续。因此，中断恢复不依赖历史回放。进程重启或实例更换后，引擎从当前事实重新计算：已确认完成的步骤不会重新执行，尚未满足的条件不会被跳过。
仅仅保存任务状态，还不足以保证外部动作可靠。发布平台可能已经创建发布单，执行进程却在结果写回前退出。恢复后重新调用可能造成重复发布，直接假定成功又可能跳过未完成的动作。每个外部动作发出前，引擎先通过 Transactional Outbox 将动作及其稳定标识写入任务，再由执行实例认领并调用平台。中断后的接续沿用同一标识；结果不明确时，动作保持未确认，引擎回到平台查证。
系统采用 at-least-once 加效果查证，不承诺 exactly-once。稳定标识、平台幂等能力和事实查询共同处理重复调用与未知结果。后续步骤只依据已经写回任务的平台事实判断。一次 API 调用返回成功，不会直接成为继续放量的依据。
固定主路径可以由模板和引擎推进，但发布中的异常与临时调整无法全部预先穷举。例如，流水线失败是否与本次变更相关，指标异常是否需要继续观察，或者"今晚只发布部分部署组"应如何作用于正在运行的任务，都需要结合现场理解。AI 读取任务进展、平台结果、相关变更和检测结论，形成研判与候选处置。
对于需要改变任务的操作，系统采用"先计划、后应用"的两段式方式：AI 先生成提案，列出将被修改的事实、受影响的步骤和可能产生的外部动作；提案确认后写入任务，引擎再根据新状态计算后续步骤。如果确认期间任务状态已经变化，原提案不会直接应用，而是基于最新现场重新预演。应用后，已经失效的旧动作不再执行，未完成的步骤重新排期。
一类判断能否由 AI 自主完成，取决于四项准入条件：可观测，输入、平台效果和异常都有可查询证据；可停止或回退，存在明确的停止或回退动作，处置时效可接受；影响范围可控，动作范围有确定上限，并受任务基线约束；判断可靠，经过离线评测、影子运行或线上结果验证。四项条件同时满足，并取得明确授权后，这类判断才进入自主执行范围。条件不满足时，引擎停在影响最小的位置，AI 整理证据和候选方案，由相应责任人作出决定。
一次发布如何跨越昼夜
白天，变更与质量证据进入任务。AI 跟进 MR 的评审状态，开展自动审查，汇集编译打包、自测和效果差异验证结果，并辅助分析流水线失败。任务持续记录已经满足和仍然缺失的条件。
到达定时时间，系统固定执行基线。引擎从通过构建和质量验证的主干版本中确定制品，固定模板与参数，检查发布限制后启动任务。发布范围和步骤约束来自任务基线。
夜间，引擎持续推进。各部署组按照模板依次放量和检测。平台结果写回任务；观察条件尚未满足时，引擎记录下一次检查时间并结束本次执行。到期后，新的执行实例从任务当前状态继续。
遇到异常，系统先确认事实。平台超时时，引擎先查询动作是否生效；指标不通过时，后续步骤暂停，AI 汇集相关变更、指标和日志，生成候选处置。流程调整通过提案进入任务。
次日，效果验证决定是否推全。推荐效果完成新旧对照后，引擎依据平台结果和模板条件判断是否继续。全部部署完成后，任务中的执行轨迹、验证结果、异常和决策汇总为发布报告。
代码仓库、构建系统、质量平台、发布平台、检测平台和 IM 仍然各司其职。Harness 负责连接这些系统，使每个结果成为下一步的输入，每段等待都有恢复时机，每个动作都有可查证的效果。
从执行结果中扩大自主范围
当前生产运行观察中，每次发布平均仍需要约 2 次人工介入。次数不是唯一指标，更重要的是介入原因：缺少事实、工具能力不足、流程约束不完整、模型判断尚未验证，或者决策涉及业务风险取舍。
团队通过两个闭环处理这些问题。执行闭环面向当前任务：观察状态、推进步骤、检查结果，并在异常或中断后恢复。治理闭环面向后续任务：记录问题的原因、判断依据、处置动作和最终结果，用于修正模板、补充工具并建设模型评测。
流程缺口和配置问题进入模板与规则；缺少观测能力的问题推动平台补充事实接口；反复出现的异常被转化为评测样本。适合 AI 处理的判断先经过离线评测和影子运行，再用线上结果验证。满足准入条件并获得授权后，才纳入后续任务的自主执行范围。Agentic 程度并非来自设计，而是来自实际验证。
迈向自主交付
这次发布实践带来了三点认识。长程执行：任务状态必须独立于会话存在，Harness 持有进度、等待和未完成动作，使流程能够跨越时间与执行实例持续推进。决策与执行分离：确定路径由引擎执行，现场理解与异常研判由 AI 完成；需要改变流程时，通过提案与确认写入任务。持续演进：运行结果不仅用于验证本次执行，也用于检查模板、评价标准和授权边界是否合理。
当前系统能够在既定流程和授权边界内持续推进，超出边界的决策进入受控确认。下一阶段，反复出现且结果可验证的判断，将通过治理闭环转化为系统能力。运行证据也会反过来修正目标、停止条件、评价标准和风险边界。
沿着这一方向，发布系统将在三个维度继续演进。横向复制：强化通用执行能力与业务流程配置，扩展到更多业务。纵向贯通：前接需求与代码生成，后接线上巡检与归因，连接从变更意图到线上结果的交付过程。自主演进：逐步扩大经过验证并明确授权的自主决策范围。自主交付扩大的，是系统能够依据证据独立完成的决策范围。目标、风险边界与授权仍由明确的责任主体定义。
大模型让系统能够理解模糊意图、处理非结构化证据，并在无法穷举的现场中形成方案。但这些能力要进入生产环境，必须经过可靠的执行机制。Harness 所保障的，不是模型永远正确，而是模型出错、进程中断或环境变化时，任务仍能停在可判断、可恢复的位置，并依据真实结果继续执行。这正是 Agentic 发布从"能够调用工具"走向"能够可靠完成任务"的关键。
热门跟贴