小红书推荐系统的 Agentic 发布：跨昼夜任务 Harness 实践

随着 Agent 逐步具备理解上下文、调用工具和持续执行复杂任务的能力，推荐系统研发开始探索新的工程范式。小红书技术 REDtech 推出《Agent 驱动的推荐系统工程实践》专栏！

本专栏聚焦小红书推荐系统对 Agentic 研发新范式的探索，覆盖需求理解、代码开发、变更风险分析、效果与质量评测、发布执行、线上观测和问题诊断等真实场景。围绕上下文组织、工具体系、长程任务 Harness、安全边界与反馈机制，我们将通过一系列生产实践，呈现 Agentic 系统如何贯穿研发、质量保障与稳定性治理，推动推荐研发流程持续演进。

小红书推荐核心服务的一次发布横跨十几个部署组、数千个 Pod，平均持续 10 多个小时，并需等待次日真实流量验证。为让 Agent 执行这套流程，我们将发布知识、操作步骤和异常处置沉淀为近 20 万字的 SKILL。但知识完备并不等于执行可靠：跨会话状态延续、故障恢复和动态变化仍需系统保障。为此，我们构建长程任务 Harness，以任务保存状态、模板固化约束、引擎推进并核验结果，支撑 Agent 可靠完成跨昼夜发布。

出品团队

01

一次跨昼夜发布，难在哪里

发布不是一个瞬时动作，变更进入主干前，要经过代码评审、构建、自测和效果差异验证；版本确定后，要在部分部署组灰度、检测并依次放量；灰度完成后，还要等待真实流量积累足够样本，确认推荐效果没有异常，才能推向全部部署组。

构建、测试、发布和检测早已各自自动化。难点出现在环节之间：上一个平台产生结果后，谁来确认事实、检查条件并启动下一步；等待几个小时后，谁来恢复任务；计划发生变化时，谁来判断哪些动作已经失效。

这类任务同时具备 Long-Running 和 Long-Horizon 两个特征。

• Long-Running：验证依赖真实时间，任务必须跨越会话、进程重启和执行实例切换持续存在。
• Long-Horizon：环节前后强依赖，前一步的真实结果决定下一步是否成立。

发布环境也不会保持静止。平台可能超时，指标可能波动，线上可能出现事故，发布范围也可能临时调整。一次错误动作已经作用于真实流量，后续回滚无法抹去此前的影响；一次接口调用成功，也不代表动作按预期生效。

因此，可靠完成一次发布至少要求系统做到五件事：

1. 始终保存任务的当前状态。
2. 每次推进都依据最新事实。
3. 发布范围、步骤和通过条件不能被模型输出绕过。
4. 外部动作必须查证实际效果。
5. 中断和未知状态必须能够安全恢复。

这五项要求无法由一次模型会话单独承担。

02

SKILL 能传递知识，不能承载执行责任

我们最初用脚本封装固定动作，再把完整的发布知识整理成 SKILL，供 Agent 执行时读取。随着覆盖范围扩大，新的步骤、条件和禁令不断加入，最终形成近 20 万字的操作手册。

模型已经能够理解发布流程并调用平台，但约束没有因此变得可靠。一次模型幻觉导致参数漏传，让本应灰度发布的版本直接在全部部署组推全。

这次问题暴露了提示词方案的边界：

• SKILL 可以描述“必须灰度”，却不能强制每次平台调用都携带正确范围。
• 上下文可以记录对话，却不能成为跨昼夜任务的权威状态。
• 模型可以生成计划，却无法保证计划在环境变化后仍然成立。
• 工具可以返回调用结果，却不能证明生产环境中的实际效果。
• 模型可以确认自己的判断，却不能替代独立的授权和风险约束。

继续补充提示词，只会增加模型需要理解的知识，不会产生持久化、并发控制、幂等、恢复和效果查证。发布知识可以写进 SKILL，执行责任必须交给模型之外的 Harness。

03

Harness 如何保障跨昼夜执行

3.1｜总体架构：连接 Agent 与生产环境

我们构建的 Harness 位于 Agent 与生产环境之间，负责长程任务的运行与控制。它将一次发布表示为可持久、可计算、可恢复的任务，并把必须稳定成立的约束放入确定性执行路径。

系统包含四个核心实体：

• 流程模板：定义发布步骤、前置条件、通过条件、时间条件、动作参数约束和授权边界。
• 任务：保存一次发布的参数、进度、平台结果、未完成动作与已确认决定。
• 引擎：依据模板和任务当前状态推导下一步，执行动作并写回结果。
• 提案：Agent 根据现场生成的调整方案，列明变更内容、影响步骤和可能触发的外部动作。

Agent 读取任务与外部证据，处理日志、指标、变更内容和自然语言意图，完成异常研判与方案生成。它不直接组装生产平台调用。引擎只依据模板和任务中已确认的状态发出动作。

模型负责处理无法预先穷举的信息，确定性路径负责控制发布范围、步骤顺序和通过条件。

3.2｜任务：在会话之外保存现场

对跨昼夜发布来说，会话可以作为交互入口，不能作为状态来源。我们将目标、参数、步骤进展、平台结果、未完成动作和已确认决定写入独立任务，使其成为流程的权威状态。

任务发起时，使用的流程模板版本和参数会作为执行基线固定下来。运行期间即使模板发生变化，也不会影响已经开始的任务。每完成一步，新状态立即持久化；会话结束、进程崩溃或执行实例切换后，接续者只需读取当前任务，从已经确认的位置继续。

流程推进、平台回调和临时调整可能并发写入任务。多路更新通过基于版本号的乐观锁（CAS）协调。发生竞争时，执行方读取最新版本重新判断，旧结果不能覆盖新进展。

任务保存的是已经发生的事实，而不是某个 Agent 对历史过程的记忆。引擎、Agent、进度页面和发布报告由此基于同一份现场工作。

一次发版任务的完成页面。图中耗时和人工介入次数仅对应本次任务。

3.3｜模板与引擎：根据当前状态持续推进

流程模板以声明式方式定义步骤、依赖、通过条件、时间条件和动作约束。

引擎以类似 Kubernetes Reconciliation Loop 的方式推进任务。每次调度（Tick），它都会读取任务当前状态，与模板定义的目标比较，计算此刻可以执行的步骤。条件满足就登记动作；条件不满足就保留现场，并记录下一次检查时间。

定时起发、分组放量和次日效果观察都通过时间条件表达。等待期间不需要持续占用会话或线程。检查时间到达后，引擎重新读取任务与平台状态，再决定是否继续。

因此，中断恢复不依赖历史回放。进程重启或实例更换后，引擎从当前事实重新计算：已确认完成的步骤不会重新执行，尚未满足的条件不会被跳过。

3.4｜外部动作：以实际效果为准

仅仅保存任务状态，还不足以保证外部动作可靠。

发布平台可能已经创建发布单，执行进程却在结果写回前退出。恢复后重新调用可能造成重复发布，直接假定成功又可能跳过未完成的动作。

每个外部动作发出前，引擎先通过 Transactional Outbox 将动作及其稳定标识写入任务，再由执行实例认领并调用平台。中断后的接续沿用同一标识；结果不明确时，动作保持未确认，引擎回到平台查证。

系统采用 at-least-once 加效果查证，不承诺 exactly-once。稳定标识、平台幂等能力和事实查询共同处理重复调用与未知结果。

后续步骤只依据已经写回任务的平台事实判断。一次 API 调用返回成功，不会直接成为继续放量的依据。

3.5｜提案：让 Agent 在约束内处理变化

固定主路径可以由模板和引擎推进，但发布中的异常与临时调整无法全部预先穷举。例如，流水线失败是否与本次变更相关，指标异常是否需要继续观察，或者“今晚只发布部分部署组”应如何作用于正在运行的任务，都需要结合现场理解。

Agent 读取任务进展、平台结果、相关变更和检测结论，形成研判与候选处置。

对于需要改变任务的操作，系统采用“先计划、后应用”（plan and apply）的两段式方式：Agent 先生成提案，列出将被修改的事实、受影响的步骤和可能产生的外部动作；提案确认后写入任务，引擎再根据新状态计算后续步骤。

如果确认期间任务状态已经变化，原提案不会直接应用，而是基于最新现场重新预演。应用后，已经失效的旧动作不再执行，未完成的步骤重新排期。

一类判断能否由 Agent 自主完成，取决于四项准入条件：

• 可观测：输入、平台效果和异常都有可查询证据。
• 可停止或回退：存在明确的停止或回退动作，处置时效可接受。
• 影响范围可控：动作范围有确定上限，并受任务基线约束。
• 判断可靠：经过离线评测、影子运行或线上结果验证。

四项条件同时满足，并取得明确授权后，这类判断才进入自主执行范围。条件不满足时，引擎停在影响最小的位置，Agent 整理证据和候选方案，由相应责任人作出决定。

04

一次发布如何跨越昼夜

白天，变更与质量证据进入任务。Agent 跟进 MR 的评审状态，开展自动审查，汇集编译打包、自测和效果差异验证结果，并辅助分析流水线失败。任务持续记录已经满足和仍然缺失的条件。

到达定时时间，系统固定执行基线。引擎从通过构建和质量验证的主干版本中确定制品，固定模板与参数，检查发布限制后启动任务。发布范围和步骤约束来自任务基线。

夜间，引擎持续推进。 各部署组按照模板依次放量和检测。平台结果写回任务；观察条件尚未满足时，引擎记录下一次检查时间并结束本次执行。到期后，新的执行实例从任务当前状态继续。

遇到异常，系统先确认事实。平台超时时，引擎先查询动作是否生效；指标不通过时，后续步骤暂停，Agent 汇集相关变更、指标和日志，生成候选处置。流程调整通过提案进入任务。

次日，效果验证决定是否推全。推荐效果完成新旧对照后，引擎依据平台结果和模板条件判断是否继续。全部部署完成后，任务中的执行轨迹、验证结果、异常和决策汇总为发布报告。

代码仓库、构建系统、质量平台、发布平台、检测平台和 IM 仍然各司其职。Harness 负责连接这些系统，使每个结果成为下一步的输入，每段等待都有恢复时机，每个动作都有可查证的效果。

05

从执行结果中扩大自主范围

当前生产运行观察中，每次发布平均仍需要约 2 次人工介入。次数不是唯一指标，更重要的是介入原因：缺少事实、工具能力不足、流程约束不完整、模型判断尚未验证，或者决策涉及业务风险取舍。

我们通过两个闭环处理这些问题：

• 执行闭环面向当前任务：观察状态、推进步骤、检查结果，并在异常或中断后恢复。
• 治理闭环面向后续任务：记录问题的原因、判断依据、处置动作和最终结果，用于修正模板、补充工具并建设模型评测。

流程缺口和配置问题进入模板与规则；缺少观测能力的问题推动平台补充事实接口；反复出现的异常被转化为评测样本。适合 Agent 处理的判断先经过离线评测和影子运行，再用线上结果验证。满足准入条件并获得授权后，才纳入后续任务的自主执行范围。

Agentic 程度并非来自设计，而是来自实际验证。

06

认知与展望：迈向自主交付

这次发布实践带来了三点认识：

• 长程执行：任务状态必须独立于会话存在。Harness 持有进度、等待和未完成动作，使流程能够跨越时间与执行实例持续推进。
• 决策与执行分离：确定路径由引擎执行，现场理解与异常研判由 Agent 完成；需要改变流程时，通过提案与确认写入任务。
• 持续演进：运行结果不仅用于验证本次执行，也用于检查模板、评价标准和授权边界是否合理。

当前系统能够在既定流程和授权边界内持续推进，超出边界的决策进入受控确认。下一阶段，反复出现且结果可验证的判断，将通过治理闭环转化为系统能力。运行证据也会反过来修正目标、停止条件、评价标准和风险边界。

沿着这一方向，发布系统将在三个维度继续演进：

• 横向复制：强化通用执行能力与业务流程配置，扩展到更多业务。
• 纵向贯通：前接需求与代码生成，后接线上巡检与归因，连接从变更意图到线上结果的交付过程。
• 自主演进：逐步扩大经过验证并明确授权的自主决策范围。

自主交付扩大的，是系统能够依据证据独立完成的决策范围。目标、风险边界与授权仍由明确的责任主体定义。

///

结语

大模型让系统能够理解模糊意图、处理非结构化证据，并在无法穷举的现场中形成方案。但这些能力要进入生产环境，必须经过可靠的执行机制。Harness 所保障的，不是模型永远正确，而是模型出错、进程中断或环境变化时，任务仍能停在可判断、可恢复的位置，并依据真实结果继续执行。

这正是 Agentic 发布从“能够调用工具”走向“能够可靠完成任务”的关键。

///

团队介绍

小红书引擎架构团队，负责小红书主站与海外业务在搜索、推荐、广告、电商等场景的引擎与架构研发，面向 AI-Native 探索下一代智能引擎架构范式与关键能力。

小红书质效研发部，肩负着以 AI 重构公司级下一代研发体系的使命。我们希望以 AI-Native 的方式重新设计研发基础设施，让需求理解、研发执行、质量验证和发布运维不再是彼此割裂的工具，而是一套能够持续感知、持续行动、持续验证并持续进化的智能生产系统。

本文作者@小红书技术REDtech。原文链接：https://mp.weixin.qq.com/s/GsVimos8OtvgzbIdm4ppow