"AgentX: Towards Agent-Driven Self-Iteration of Industrial Recommender Systems" 论文笔记

快手发布的一篇技术报告 AgentX，提出了一个可以自我迭代的 MAS 把工业推荐的 idea-to-launch 闭环整体自动化，推荐领域的 Loop Engineering

背景

工业推荐系统的算法迭代长期依赖算法工程师的持续介入。一次完整的算法迭代通常需要经历数据分析、特征工程、模型开发、在线部署、A/B 测试和归因复盘等多个阶段，发布周期往往以周为单位。工程师的大量精力并非花在高价值的判断上，而是分散在数据拉取、配置修改、链路维护等重复性琐事中。传统解法无论是增加工程师人数还是建设更强的底层平台，本质上都是对人工开发流程的线性放大，无法改变 "推荐系统迭代高度依赖人力和个体经验" 的结构性瓶颈

随着 LLM 在代码理解、多步推理、错误诊断和工具调用等方面的持续进步，用 Agent 作为执行实体来驱动算法迭代开始变得切实可行。本工作的核心思想就是将推荐系统迭代的核心瓶颈从算法工程师的劳动转移到了Agent 系统的能力上。二者的本质区别在于：前者高度依赖个体经验，不可复制；后者是可重复、可复合的，每一次在线迭代的执行轨迹都能被记录、分析并反馈到 Agent 框架中，系统会随时间推移越来越强

当前 LLM-Driven MLE 方法主要分为三类逐步演进：

• 流水线自动化：把 LLM 嵌入预定义的 AutoML / 数据科学流水线，任务定义与解空间仍由人指定（CAAFE、DS-Agent、Data Interpreter、AutoML-Agent）

• 实验自动化：把 "可执行实现 + 实验轨迹" 当作自治搜索的对象，agent 反复改代码、跑实验、读指标日志并据经验反馈选择后续动作（IMPROVE、MLE-STAR、AIDE、R&D-Agent、AutoMind、MLEvolve）

• 研究自动化：进一步把决策空间从 "解决预定义任务" 扩展到 "formulate 并 validate 研究本身"（The AI Scientist、Agent Laboratory、AI Scientist-v2、Ai-researcher）

但从工业推荐的视角审视这些工作时，本文识别出三个结构性瓶颈：

• 缺乏真实在线反馈：现有系统的成功信号主要来自离线指标或人工评分，而非在线 A/B 结果。在线 A/B 是与真实价值最对齐、受噪声影响最小的奖励信号，但在现有研究中基本缺失

• 缺乏工业规模验证：现有工作验证的数据集、模型和流水线规模仍远落后于真实推荐系统（十亿级样本、多目标耦合、多业务线并行）。这些工程约束在小规模时可忽略，但在工业规模下却成为决定闭环能否成立的关键变量

• 缺乏持续进化机制：大多数 MLE Agent 系统在单次任务完成后不积累系统本身的参数、提示词和工作流，导致无法适应新任务和环境，反复掉入同样的坑

方法

在描述各 agent 之前，论文先抛出设计原则的核心问题：工业推荐里一个好的迭代闭环应该长什么样？ 经典 LLM agent 任务（数学、代码、sandbox ML benchmark）通常假设：环境暴露一个可验证的奖励、单条执行轨迹足以判定成功、优化目标在 agent 启动前就已固定。而工业推荐同时违背这三个假设：

• 奖励信号活在延迟的线上 A/B 反馈里，而非离线指标

• 单次部署在任何分数可得之前，要先经过 guardrail 与人工评审的把关

• 优化目标本身会随业务目标、流量结构、平台约束的演变而漂移

因此一个生产级推荐 agent 闭环必须是 closed-loop 而非 one-shot：要把模糊的业务意图转成有证据支撑的提案，把每个提案转成与代码仓库一致的代码，经安全灰度 + guardrail veto 验证变更，并把正负轨迹都回灌使闭环本身随时间改进

图2 | AgentX 整体框架。四个核心 Agent 形成闭环，共享数据层和监控平台。

AgentX 沿单一闭环分解为四个阶段，其中前三个共同把一个想法从 intent 带到验证过的线上结果，第四个把产生的轨迹回灌以精炼闭环本身。围绕这一闭环，一个共享的 Data Layer（包含当前实践经验的知识库 + 实验报告等 Agent 数据管理记录）持久化每一件 artifact，Monitoring Platform 通过 dashboard / metrics / tracing / alerts / audit / visualization 持续观测系统健康

注意没有明确注明是人工执行的功能默认都是使用 subagent 进行实现

Brainstorm Agent

作为 AgentX 闭环的入口，其职责是将模糊的优化意图转化为少量、可执行且有证据支撑的实验方案。核心挑战是歧义问题（Ambiguity Problem）：输入是故意不明确的（如"提升用户时长"），而输出必须是操作上精确的。如果 Agent 探索太自由，会捏造信号或假设不可用的特征；如果太保守，只会返回熟悉策略的局部变体

对每个任务，agent 先把用户请求归一化为一个 intake boundary（接收边界），记录：primary objective、allowed business scope、forbidden changes、known guardrails、candidate output requirements、unresolved questions。目的不是逼用户预先指定一切，而是让不确定性显式化：已知字段约束搜索，未知字段则变成保守默认或具名的后续探针（follow-up probe），防止歧义被静默传给 Developing Agent

图3 | Brainstorm Agent 工作流。历史实验记忆和系统知识被组织为 Experiment KB 和 System KB。Brainstorm Agent 澄清任务、产出候选想法、经评审和边界检查验证、将已接受想法物化供下游执行。

Brainstorm Agent 的工作流如下：

1. Question Module 将用户模糊的意图（如 "提升时长"）转化为显式的任务边界，明确优化目标、业务范围、禁止项、已知约束和待确认问题，让不确定性显式化

2. Produce Module 在两个耦合控制下产生 Idea 候选：

   • 有界方案探索（Bounded Proposal Exploration）

     边界固定后，agent 会按批次生成方案，批结构之所以重要，是因为生产想法不仅在机制上不同，也在成熟度上不同。因此每个候选被标记为以下三类状态之一：

     • Ready-To-Implement：有具体目标、明确的实施位置、合理的优化路径和足够证据

     • Probe-First：有前景但需要先进行数据、源码或预演检查

     • Moonshot-Backlog：保留长期方向，等待未来基础设施或模型能力成熟后启用

     批循环还是残差式（residual）的：每轮之后，被拒方向、历史重复、违反约束、已覆盖机制都被写入一个 avoid set；有前景但不完整的方向转成显式探针。下一轮于是搜索剩余空间，而非复述同样的想法。在这个意义上，Brainstorm Agent 不只是从 LLM 采样建议，而是在生产约束下收缩可行机会空间

   • 证据加权方案生成（Evidence-Weighted Proposal Generation）

     如果把所有检索到的上下文当作同等权威，头脑风暴就不可靠。不同候选需要不同种类的证据：novelty-oriented 想法要对照历史 launch review 以避免重复已知失败；code-path-sensitive 想法要对照架构与源码 scope 知识以避免不可能的交接；metric-diagnosis 想法要 grounded 在数据分析而非直觉。因此 agent 把知识表示为候选特定的证据混合，而非固定检索结果从四个证据源检索信息，并赋予不同权重：

     • Experiment KB（实验知识库）：存历史 launch review、业务定义、过往实验结论与教训；不仅记"想法成败"还记"结果背后的上下文"（目标场景、受影响用户群、指标变动、上线决策、事后诊断）。当候选依赖 novelty / 历史经验 / 业务语义时权重更高，用于惩罚重复方向、避开被证伪的假设、复用成功教训

     • System KB（系统知识库）：存推荐系统内部的结构化知识（模型架构、DSL 行为、流水线边界、配置语义、源码 scope），目的是降低 code-path-sensitive 想法的幻觉。它构建为结构化领域 wiki（三层：schema 层定义字段与关系、wiki 层存结构化 Markdown 条目、raw-source 层把每条目链回原始代码/配置/文档），经 ingest–query–lint 生命周期维护。对 feasibility-sensitive 候选权重更高，把架构与实现约束转成显式证据

     • Data Analysis（数据分析）：为依赖观测数据模式（而非直觉）的候选提供经验证据，可访问历史分析报告、指标定义、SQL 计划、离线统计与即时 SQL 查询。在 metric diagnosis、segment 行为、分布漂移等场景权重更高，把头脑风暴从直觉驱动转成 data-aware 假设形成

     • Model Research（模型研究）：为依赖近期论文 / 学术发现的候选提供外部研究证据。它把论文转成可执行的提案知识：每篇论文被分解为 typed claims（按 problem / assumption / method / finding / limitation 角色与证据强度标注）、architecture components、inter-paper relations（extend / contradict / parallel / apply）。生产 baseline 用同一 schema 表示，连同特征契约与训练约束（流式增量训练、无 epoch、禁止 backbone freezing/early stopping 等硬约束），使 paper-derived 想法是被对照真实系统而非抽象评测

     然后使用一个加权机制让同一候选格式支持不同推理思路，用 \(\alpha_k(q, c)\) 反映来源 k 对当前问题与候选的相关性与可靠性，每个来源产出证据分 \(e_k(c) \in [0, 1]\)，加权证据项为 \(E(c \mid q) = \sum_{k \in K} \alpha_k(q, c) e_k(c)\)。最终候选分把证据项与目标对齐、业务有效性、实现可行性、交接完整性、风险结合

3. Validation & Materialization Module 候选生成后有一个准入步骤。validator 检查主目标对齐、业务语义、用户约束、模型分数语义、实现可行性、历史重叠、A/B 参数可行性、成熟度一致性。评审产生轮级（round-level）与候选级（candidate-level）决策，只有 ready 候选且通过 validation 才能进入人工审批门；probe-first 想法留作显式取证任务；backlog 想法留在执行队列之外；materialize 模块把已接受候选转成结构化提案 artifact，交付下游做验证、编码、上线与事后诊断

Developing Agent

Developing Agent 将批准的方案转化为可验证的代码工件，沿两条并行轨道运行：

• 在线策略轨道（Online Strategy Track）：针对特征级或策略级方案的生产代码变更

• 离线模型轨道（Offline Model Track）：针对模型架构方案的训练实验

一个结论只有当四个条件同时成立才被视为可信：(1) 实现被验证匹配策略声明的因果机制与预期可观测量；(2) 一个隔离的专家 agent 面板对策略达成超多数一致；(3) 指标由原始训练日志确定性提取而非 LLM 解读；(4) 任何 AUC 增益都有验证过的因果链归因支撑

两条轨道都会面临各种不同的失败问题，并且很多都会静默的污染知识库、影响线上流量（没有显式失败信号）。因此 Developing Agent 不是通用代码生成器，而是一个面向验证的实现系统

1. 在线策略轨

   • 生产代码可靠性问题

     agent 必须保留提案意图、留在允许变更边界内、只用仓库原语、通过本地与集成检查、留下一个能安全上线的可评审改动。核心困难是这些要求会交互：一个 patch 可能逻辑上对齐提案却用了幻觉属性；可能编译却漏了必需的流水线注册；可能正确实现策略却在没有 default-off guard 的情况下激活它。主要失败模式因此不是通用编程错误，而是仓库特定的可靠性失败：属性幻觉（在 user/context/item 特征 schema 里发明字段）、DSL 误用（猜测 ranking DSL 算子名或参数契约）、harness-pattern 违规（改动放错队列、注册不完整、绕过必需安全模式）。此外，每一次额外的纠错循环与每一次人工介入都降低自动化可靠性，因为 AgentX 的目标是用最少人工救援闭合 idea-to-launch 闭环

   • 基于仓库的代码生成

     Developing Agent 用两类仓库知识 grounding 实现：(1) 一个项目特定知识库，记录变更模式、注册约定、feature-switch 规则、被接受 patch 的样例；(2) 一个 case toolbox：一组确定性工具与 checker，强制 agent 在使用事实前先验证。最重要的 grounding 规则是特征属性必须在使用前被查询。schema query 工具为 user/context/item 各域返回可用字段，agent 被要求在读属性前调用相应工具，让字段名成为被验证的事实而非语言模型的猜测。ranking DSL 调用由编译器 backed 的 checker 验证算子名、参数类型、调用契约；C++ 惯用法与项目特定语法糖由轻量静态 linter 在 patch 进入更重的 build 前捕获

   • 验证原生的实现循环

     每个编码任务遵循分阶段循环：agent 先把已批准提案抽象成实现计划（哪些文件会变、需要哪些信号、哪个流水线阶段拥有逻辑、哪个 feature switch 守护行为、提交前要过哪些检查），再实现原子子需求、装配 patch、跑确定性验证。失败以反馈，而非宽泛的重新生成 prompt。

     两个验证层尤为重要：accuracy loop 把实现与计划比对并把额外修复迭代计为质量成本（理想轨迹是首次实现已匹配规约）；dryrun pipeline 编译并集成检查分支（干净轨迹只过一次 Dryrun，反复 Dryrun 失败说明 agent 在把远程基础设施当 debug 工具用而非产出本地自律 patch）。两层都进入下面的质量分

   • 质量打分

     编码质量被度量为一个加权可靠性分，一共 8 个失败观测维度，按照对生产可靠性的重要程度分配不同的权重（这里 8 个维度和各自的权重省略，可以去原论文查看）

2. 离线模型轨

   模型架构提案的开发方式不同于在线生产改动，目标不是安全可部署的 patch，而是一个可信的离线训练实验。核心原则是：LLM 只允许在判断上出错；每一个客观事实都由确定性代码产出

   • 单轮循环

     

     • policy：不止声明改什么，还声明所主张的因果机制与一组预期可观测量（expected observables）。每个都精确命名，使 code agent 能把它接进 tf.print 或 tf.summary，并描述健康 vs 病态行为长什么样（例："gate activation > 0.5 after step 1000 表示 live gate；≈ 0 表示 collapse"）。这迫使本轮预先承诺如何被证伪，而非事后解读结果

     • code & verify：在指定文件边界内实现 policy。verify 检查两件事：结果 git diff 在语义上匹配 policy 方向；每个声明的 observable 名出现在 diff 中。任一检查失败则 code agent 重写（最多三次），耗尽预算则干净地让本轮失败，而非带着未验证代码继续

     • expert agents：并发独立评估 policy，只读 policy 文本与各自私有知识库，与历史及彼此意见物理隔离。专家共识由 Python 计票（超多数 ≥⌈2N/3⌉），从不由 LLM 计

     • exec：纯 Python 状态机，无 LLM 参与，通过提交、轮询、评估、指标提取（正则从原始训练日志拉 AUC）流转。此处排除 LLM 是刻意的：指标提取是有正确答案的模式匹配问题，幻觉 AUC 数字传进知识库的代价很高

   • 可证伪根因

     这里裁决 policy 声明里面的每一环，再通过 Python 确定性折叠：所有链 verified → 归因状态 CLEAR；任一 broken 或 unclear → UNCLEAR

   • 鲁棒执行

     生产训练环境里许多失败与提案本身无关：GPU OOM、集群作业 stall、基础设施连接超时。若一律对待（总重试或不重试），系统要么在根本损坏的配置上浪费算力，要么被瞬时噪声杀死。因此 agent 对每个失败会先区分确定性错误（如 NaN 梯度，直接放弃）和瞬时故障（如集群超时，重试一次）

Evaluation Agent

Evaluation Agent 关闭 AgentX 生产闭环：它决定 Developing Agent 物化的代码改动应被保留、回滚、还是作为负面教训回灌下一轮。其角色不只是报 A/B 数字，而是把噪声、延迟、部分可观测的线上流量转成系统其余部分可据以行动的可信奖励信号，并转成塑造未来迭代的可复用约束

图6 | Evaluation Agent 架构，串联 OpenAPI 安全部署、在线 A/B 执行和 Guardrail 否决判定。

一个策略可能改善内部分数却损害长期用户体验，或在小切片上看似有前景却破坏 guardrail 指标。AgentX 因此把线上 A/B 反馈作为系统迭代的权威奖励信号。这造成第二个可靠性问题：agent 必须安全地上线实验、不污染其他实验、读噪声线上指标、施加严格上线标准、把负结果转成可复用记忆

• 安全部署和流量分配：实验产生奖励前必须安全进入流量。工业推荐通常把请求路由经多个业务域、分层、world、桶区间和分流因子等。不尊重此拓扑而上线自动生成策略，会引发参数冲突、跨实验污染、不一致的用户分配

  上线调度工作：Deployment 层把每个实验映射到正确业务域与 world，选合适 split factor，分配互斥流量桶。对 account-bound 实验按 user ID 路由；对 device-side 体验改动用 device ID；对混合人群用 UID-first 策略。当桶分配欠定时，agent 做实验前 balance check，选基线失配最小的流量组。安全控制在上线前施加：参数改动必须过工程白名单（agent 不能改未授权的调度或 serving 控制）；配置上线走 canary 路径，API 提交改动后系统先观测一个最小灰度窗口再升全量；监控检测到不稳定则在实验变成大规模线上风险前halt）

• 带 Guardrail 否决的 A/B 评判：

  这里会把指标提取与决策逻辑分离，决策策略刻意保守，guardrail 设计遵循三原则以控制 false negative：

  • Guardrail 按业务域定制：每个业务域（消费、直播、电商、广告）有自己的核心指标与否决阈值；一个域的实验不受全系统所有 guardrail 的并集约束，主要对其所在域的 guardrail 指标 + 一小组跨域稳定性指标负责

  • 复合经济交换指标：将多个业务目标聚合为统一摘要，单一指标负向不自动触发否决

  • 阈值作为注意力信号而非绝对阻断：触发 Guardrail 时策略升级给人审而非自动丢弃

  分析阶段的输出因此不是单一数字，而是一个结构化裁决：KEEP / EXTEND / DISCARD，连同 primary effect、guardrail status、统计方法、观测窗口、caveats。这个结构化裁决就是后续阶段消费的奖励记录

• 负结果资产化：每次失败实验记录根因（显著性不足、Guardrail 恶化、流量错配、实施缺陷或业务上下文不匹配），并按链路阶段、业务目标、用户/内容段和策略杠杆索引。未来的 Brainstorm Agent 可检索这些资产以避免重蹈覆辙

Harness Evolution

生产实验分析只捕获了反馈循环的一侧。虽然 Evaluation Agent 成功诊断了在线结果、记录了失败方向，但它不解释为什么上游 Agent 未能捕捉到正确的约束、错过了业务因果链、产生了不完整的手交或生成了违反仓库约定的代码。AgentX 因此引入第二层优化：执行轨迹 -> Agent 框架的自我改进。优化目标不是推荐策略本身，而是控制每个 subagent 如何推理、提问、验证、交接、从失败恢复的 Harness

论文在严格受限意义上使用 harness 一词。完整运行 harness 含顶层编排、记忆、工具接口、跨 agent 协议、subagent 指令；但当前生产安全版本一次只更新一个 subagent 级的 harness 规约。进化运行期间，基础模型、工具接口、顶层编排、其他 subagent 保持固定，只编辑目标 subagent 的指令、验证规则、输出契约、工具使用纪律。这一设计确保更新完全可检视，并让 old-vs-new replay 有意义：任何分数变化都能被隔离到一处局部 harness 编辑，而非席卷式系统重写

此论文引入 Semantic-Gradient-based Prompt Optimization（SGPO）：一个离线 harness 进化方法，把累积执行轨迹转成局部 subagent prompt 更新，仅经 paired replay 准入。简言之，SGPO 把对轨迹失败的自然语言诊断当作语义梯度，在 AgentX 其余部分固定的前提下修订单个 subagent 规约

SGPO-I

图7 | SGPO-I 框架进化流程。从积累轨迹采样 → 语义梯度生成 → 候选框架编辑 → 配对回放门控采纳。

SGPO-I 用会话轨迹作为证据源。设 \(h_{t,i}\) 为目标 subagent \(i\) 在进化轮 \(t\) 的当前 harness 规约。每轮从累积的线上轨迹池采一小批与 subagent \(i\) 相关的轨迹。评估器不逐字读完整会话，而是从初始用户 query 与后续用户输入抽取紧凑 rubric（这些字段通常含显式任务约束与交互中揭示的隐式约束）

• 采样与损失计算：从积累的轨迹池中采样与目标子 Agent 相关的轨迹，Evaluator Agent 生成自然语言损失报告并提炼为语义梯度

• 梯度更新：Refinement Agent 将梯度转化为局部 harness 编辑，产出候选修订 harness（精炼限于目标 subagent 的指令、验证规则、输出契约、工具使用纪律）

• 配对回放：候选 harness 生成后，SGPO 立即在同一组 replay task 上评估新旧 harness。replay task 集由同一轨迹池生成（LLM 把用户 query 与后续输入重写为独立用户任务，保留业务域、目标、guardrails、允许变更类型、预期 artifact、已知约束，去掉对早先对话上下文的依赖），仅当 ΔScore>0 时才将候选框架采纳到生产环境。被拒 patch、评估分、失败解释作为 refine experience 留待后续轮次

SGPO-I 应用于想法生成阶段（即 Brainstorm Agent 的各个 subagent），此处失败常表现为模糊目标、缺证据 grounding、重复方向、下游 validation/coding agent 无法直接消费的 artifact 等

SGPO-II

作为 SGPO-I 的扩展，SGPO-II 把证据源从对话轨迹换成源自历史已合并请求（merged requests, MR）的编码 replay case。这是必要的，因为 developing-agent 失败是长程且仓库特定的：生成 patch 可能满足表面需求却违反 ownership 边界、feature-flag 纪律、local helper 约定、rollback 预期、确定性验证规则。MR 历史因此充当编码轨迹池。replay 前 SGPO-II 过滤该池以去除噪声 / 陈旧 / trivial / 大块改动：包括 bulk reformat、revert、依赖 bump、<10 行改动的 patch、>5000 行重写、生成文件为主的改动、以及原始 diff 上下文在当前代码库已不存在的 MR。保留的是 human-approved、仓库上下文仍存活的代码改动

• 证据源从对话轨迹变为历史合并请求（MR）

• 评估维度改为：语义正确性（40%）、需求覆盖（25%）、文件覆盖（20%）、默认安全（10%）、代码风格一致性（5%）

SGPO-II 从清洗后的池采 replay case，把每个保留 MR 转成 requirement-only task（类比 SGPO-I 的用户任务）。落地 patch 对 Developing Agent 隐藏，只在 agent 产出实现后供评估器作参考。case 以 batch size 5 合成，每个 case 在从 MR base commit 初始化的干净分支上尝试。评估器只在加权聚合分 ≥4.0 且 Semantic Correctness ≥4 时通过 case。replay 失败时评估器把失败概括为语义梯度并传给 Harness Refine Agent（类比 SGPO-I），后者把梯度转成 Developing Agent harness 规约的局部更新

模型研究探索管道的进化

除了 Agent 推理方式的进化，第二条进化轴是系统探索什么。AgentX 对论文知识库执行三阶段穷举探索：

1. Phase 1（复现与筛选）：每篇论文生成一个复现方案，结果按对生产 baseline 的平均 ΔAUC 排序，Top K=16 进入 Phase 2

2. Phase 2（模块消融）：对 Top-K 论文中每个可消融模块枚举两种实现选择（原始 choice 与 LLM 推断的替代），构造只激活目标模块、把其余所有 top-K 增项回退为 baseline 等价的 bundle。一个模块只有产出正 ΔAUC 才被确认有效

3. Phase 3（跨论文组合）：将已验证模块跨论文组合，每 4 轮常规组合后插入一轮 "Challenger Round" 把 top effective 模块应用到排名 17–32 的论文，维持探索空间多样性

记忆引导剪枝：对 1312 篇论文及其模块做朴素穷举搜索计算上不可行，且会重访已被证无效的方向。系统通过持续更新两层剪枝决策避免。在 paper level，若某结果在生产设置中证伪了一篇论文的核心前提，该论文的所有模块被排除出 Phase 2/3；在 module level，Phase 2 里被确认无独立贡献的消融把该模块排除出 Phase 3 组合。aturation detection 提供全局停止判据，当 novelty-signature 重复率（对离散化架构字段的 SHA-1 hash）连续两轮超过 80%，循环终止而非生成结构冗余的实验

经验飞轮：探索循环把每个完成训练轮（成功或失败）转成结构化事件追加到 append-only event log，知识库是该 log 上的视图。教训组织为 anti_pattern（失败模式，各带 log 与 diff 正则以识别未来类似失败）与 playbook（成功配方，ΔAUC>0.001 时记录）。并非每个实验结果都可靠到能据以行动：单次成功可能是幸运超参交互、单次失败可能是瞬时环境问题。为从噪声中过滤信号，每个候选经验条目在被注入未来轮前要过两个门：threshold gate（要求至少两个独立 run 的证据）与 adversarial review gate（一个专门 agent 唯一任务是证伪声明的因果机制——存活的成为 confirmed，争议的成为 contested，被证伪的永久排除）

讨论

SGPO 把 agent 改进当作一个离线、可 replay 的系统优化问题，与在线实验分析互补：实验分析解释一个推荐策略是否有效，SGPO 解释当轨迹本身揭示反复弱点时 agent harness 该如何变。当前实现刻意保守：一次更新一个 subagent 规约、冻结其余运行 harness、仅经 paired replay 准入。这使更新路径比无约束自我编辑更慢，但对生产推荐 workflow 更安全

实验

论文围绕三个研究问题，用一次三周部署收集的单一证据体回答：三个 AgentX worker 在 Kuaishou App 的两个生产场景（主 feed 推荐 + 生活服务商业化）并发跑 idea-to-rollout 闭环。最终 374 个 ideas 有 10 个通过在线评估产出 Launch Review（主 feed 361 想法出 8 个、生活服务 13 想法出 2 个）

\[374 \xrightarrow{\text{idea pass } 28.34\%} 106 \xrightarrow{\text{code & launch } 94.3\%} 100 \xrightarrow{\text{positive eval. } 9.9\%} 10 \]

后面的具体结果就省略了，总之AgentX 通过把人工开发的串行 workflow 变成并行 pipeline 缩短 idea-to-rollout 周期，实现了 3.7× 单位人力实现业务价值

这里论文还进行进一步的探索，一个专家 agent 与 AgentX 在生活服务场景协同闭环。具体地，训练一个专用推荐决策 agent 作为该场景的专家 agent，它通过观察用户行为与画像做用户级诊断、评估当前曝光是否对齐用户更深层服务兴趣、产出用自然语言表达的控制决策。AgentX 随后推理每个诊断如何被解决、在生产是否可行，精炼为更稳健的方案并写出完整可部署执行计划（这里其实我有点疑惑，AgentX 在这里可以做到全自动化，因为提的需求就是提升某一任务的时长、XAUC 或者模型效率等简单的模糊输入，加了个专家 Agent 不就更好的全自动化了吗）

总结

搜广推的 Loop Engineering 后面一定会是各个大厂重点探索的方向，工业场景下搜广推复杂的数据和链路带来的强人工经验壁垒一直是该领域发展的痛点，现在 agent 全自动化了能提升效率的空间感觉会非常之大