淘宝内容生态：GrowBrain - 淘宝Agentic内容成长引擎

淘宝每天有大量新发内容。一条内容在发布初期能否拿到合适的曝光机会，基本决定了它的成长上限：流量少了好内容还没验证就沉底，多了流量预算被低效消耗。“内容成长机制”就是在解这个流量分配决策问题。

在过去一年，我们已构建起一套覆盖内容孵化全链路的策略体系，实现了在多场域下的流量扶持。然而，面对供给多元化和运营精细化的双重挑战，这种基于人工规则、单点模型打分及分散规则协同的模式，三个瓶颈日益凸显：

• 多信号融合困难：判断一条内容值不值得推，要看内容质量、账号画像、同类历史表现、实时流量供需等十几路信号。规则写不完，单点模型的特征工程在新场景下迭代太慢，后期信号新增和维护难度极高

• 决策说不清楚：一条内容为什么拿到这么多PV？业务方需要可解释性归因，而传统打分模型只输出一个分数（what），解释不了"为什么"（why）

• 新场景接入慢：每接一个新场景或做一个新实验，要重新改规则、训模型，需求从提出到上线往往以周为单位

为此我们提出一个以 LLM Agent为决策大脑的全自动内容成长引擎 GrowBrain。该系统通过 Planning-Execute-Summarize （PES）三段式编排范式统一调度多个子 Agent 组成的能力矩阵（如"潜力评估、流量分配、漏斗诊断等"），服务内容成长全周期。让内容成长决策从“规则拍板+人工兜底”升级为 Agent 驱动的智能决策，同时保证生产链路要求的延迟、稳定性和可解释性。

核心贡献

• Agentic 范式落地：将 LLM Agent 作为冷启决策主链路的核心节点，而非外部调用工具插件，验证了 Agentic 范式在内容成长链路上的可行性

• 多 Pipeline 共享能力底座：同一能力矩阵同时服务工业生产调用、对话场景、产运平台等多场景，避免能力重复建设

• 小模型生产可靠性工程：沉淀小模型在生产链路的可靠性工程方法，经过SFT的小模型也可以稳定在线Serving

GrowBrain 的架构并非一步到位，而是在生产环境真实挑战的驱动下，经历了从框架选型、Demo 验证、到工业化改造的完整探索过程。

我们的核心诉求是：一个能在高并发场景下稳定运行的 Agent 框架，要求即插即用的大模型服务、完整的 Agent 执行能力（Tool / Skill / Memory）、Java 原生直接跑在容器里。经过调研，我们选择了集团内部原生支持的 xlangchain 框架。

xlangchain 是基于 Java 的 Agent 开发框架，灵感来自 Python 的 LangChain。

简单来说，xlangchain 做了下面四件事：

• 给Agent"一个大脑": 对接大语言模型，让它能理解问题、做推理、生成回答。xlangchain 封装了 Whale 平台的模型调用，你不需要自己处理模型协议，直接用就行。

• 给Agent"一双手": 定义各种"工具"（Tool），比如查日志、调接口、算分数。Agent 在思考过程中会自己决定什么时候该用哪个工具，用完之后继续推理。

• 给Agent"一份记忆": 让 Agent 记住之前聊过什么。这样你可以追问"刚才那个报错，还有别的 case 吗？"，它知道"刚才"指的是什么。

• 给Agent"一套工作流程": 你可以告诉 Agent 在什么场景下该怎么做（Skill），也可以把多个步骤串成一条链（Chain），甚至让 Agent 自己规划任务再逐个执行。

不用一次记住所有模块。只需要理解四个核心角色，其余的都是围绕它们展开的：

ReactAgent执行示意图

框架自带的ReactAgent，其开箱即用的 ReAct 循环模式（Thought → Action → Observation → …）在极简 Demo 下跑得不错，但当我们把它放到生产链路、尤其是小模型（4B 以下）场景时，暴露出两个核心问题。

Claude Code 是优秀的本地编码助手，但它不是我们要建的"服务"。理解它的局限，是理解服务端 Agent 架构设计的第一步。

如果你用过 Claude Code，会对它的工作模式很熟悉：你提一个问题/指令，它理解你的代码库，给出回答/执行指令，然后等待下一个问题/指令。这是一个"一问一答"的交互式会话，每个实例只为单个用户服务。

在这种模式下，有几个事情是不需要担心的：

• 上下文永远不会混乱：因为只有一个对话，Memory 不需要隔离

• 资源永远不会争抢：因为只有一个请求在跑，不需要排队、限流

• 状态永远不会污染：为没有并发，不需要考虑线程安全

这就是 Claude Code 作为"类客户端"程序天然享受的红利。它不需要考虑高并发，因为它的服务对象只有一个：你自己。

但如果我们想把 Agent 能力开放成一个服务端，同时让成百上千个请求同时接入、每天处理上万次请求，情况就完全不同了。

2.2.1 从"能跑起来"到"能扛住流量"

服务端 Agent 的核心挑战

当我们把 Agent 从本地搬到服务端，从"单用户交互"变成"多租户服务"，有两个根本性的问题立刻浮现出来：

1. 状态管理是最棘手的。在单机上，一个 session 的内存管理很简单。但到了分布式环境，用户的第 N 次请求可能路由到任何一台机器，那台机器需要能立即接续对话，这就涉及到 session 的路由、上下文的持久化和快速恢复。

2. LLM 调用的吞吐瓶颈。大模型推理本身就是计算密集型的，API 调用有速率限制。高并发下需要设计合理的排队机制、降级策略，以及可能的模型路由：简单问题用快模型，复杂问题用强模型。

我们的实践路径

在淘宝Agentic内容成长引擎的落地过程中，我们完整经历了这个演进过程：

Claude Code 式的单用户交互    ↓ReactAgent 开箱即用的 Demo 验证    ↓小模型下的幻觉 + 执行不可控问题    ↓演进到 Planning + Execute + Summarize 架构    ↓发现高并发下的状态污染问题    ↓最终沉淀为 uni_agent 的无状态服务设计

每一步都不是"理论上更好"的选择，而是生产环境的真实教训逼出来的。

2.2.2 核心问题一：ReactAgent + 小模型 = 幻觉失控

我们的场景：用户请求"请帮我分析下内容A的潜力分"，系统中注册了 content_potential_tool（调用潜力预估服务接口获取内容潜力分）。

预期的 ReactAgent 流程：第一次 LLM 调用 → LLM 返回 function_call 要求调用 content_potential_tool → 框架执行工具拿到真实潜力分 → 第二次 LLM 调用 → 基于真实数据返回最终结果。

实际问题：当我们使用 Qwen3-0.6B 小模型时，ReactAgent 频繁翻车。

小模型在 ReAct 循环的第一次 LLM 调用中，没有返回 function_call，而是直接输出了格式正确但数据全假的回答："潜力分 75 分，中等潜力，建议优化标题"。content_potential_tool 根本没有被调用过。

我们在 Prompt 里加了强制指令"必须先调用工具获取数据"，但小模型仍然有概率忽略。高并发场景下，即使 5% 的幻觉率，每天上万次请求就意味着几百次假数据。

理想流程 vs 实际翻车对比图

根因：在 ReactAgent 模式下，LLM 同时承担了"决策调度"和"内容生成"两个职责。 小模型容易被输出 Schema 的格式"带偏"：它一看到最终输出应该长什么样，就直接照着格式编一个，跳过了中间的 Tool 调用。

结论：ReactAgent 不适用于小模型 + 高并发的工业落地场景。

解法：既然问题出在"LLM 职责过重"，我们把职责拆开，采用 Planning + Execute + Summarize（PES） 的三阶段架构。

同样是"分析内容 A 的潜力分"，PES架构的执行方式：

PES执行示意图

在此，我们需要强调一下ReAct和PES模式的核心差异：

• ReactAgent：LLM 既是"大脑"也是"调度器"，每一步都要问 LLM"接下来干什么"。小模型容易在中间步骤犯错，LLM 要同时理解工具列表 + 当前状态 + 决策下一步，prompt 负担重，多轮循环增加不确定性和延迟。

• Planning + Execute + Summarize（PES）：把"规划"和"执行"解耦。Planning 阶段 LLM 只拆任务，不关心工具怎么调；Execute 阶段框架按拓扑顺序执行，Tool 调用是确定性的；Summary 阶段 LLM 只做总结。

技术选型演进示意图

2.2.3 核心问题二：ReactAgent 的有状态设计 = 高并发隐患

ReactAgent 的第二个致命问题出在并发场景。

从 xlangchain 源码看，ReactAgent → AgentExecutor → Chain 整条链路是一个单例链。Memory 挂在 Chain 上，Tools 注册在 AgentExecutor 里，Skills 写死在 Prompt 模板里，这些全部在构造阶段绑定到一个 Agent 实例上。

在线上服务容器里，AgentService.execute() 被多个请求线程并发调用时：

Memory 污染：多个线程通过同一个 this.memory 读写。线程一刚把内容A的工具调用结果存入memory，线程二加载时就会读到这条脏数据：BaseMemory 没有请求级隔离。

Skills 注意力稀释：Skills 在 initReactAgent 时被编译成 System Prompt 文本，无论用户问什么，所有 Skills 指令全量灌入每个请求，既浪费 token，又增加小模型的注意力负担。

结论：ReactAgent 的设计假设是"单次请求、单用户交互"，核心对象是有状态的、构造时绑定的。放到高并发生产环境，这个假设被彻底打破。

解法：基于上述两个核心问题，我们确定了架构演进的三个方向：三个“拆”。

• 把状态从 Agent 里拆出来：引入 AgentContext 请求级容器，Agent 本身变为无状态执行引擎。每个请求进来时创建独立的 AgentContext，自动从请求中提取 requestId（请求唯一标识）和 sessionId（会话标识），所有请求级状态装在这个对象里，不同请求之间零干扰。

• 把 Memory 从 Agent 级拆到请求级：实现 MemoryManager 三级隔离：请求级（requestId，用完即释放）、会话级（sessionId/contentId，跨请求保持多轮上下文）、共享级（跨 Agent 共享知识配置）。后端使用Redis KV 持久化存储，显式管理生命周期。

• 把 Skills/Tools 从构造时拆到运行时：通过 SkillRegistry + ComponentRegistry 全局注册中心实现动态加载。新增 Tool 或 Skill 只需注册到 Registry，不需要重建 Agent 实例，支持线上不停机热更新。同时通过预先指定 Skills + Tool 组合生成专业子 Agent能力矩阵，曝光给 Planning LLM 用于任务规划，显著减少小模型的注意力稀释。

这三个"拆"让 Agent 从一个"有状态的大而全的对象"变成了"无状态的执行引擎"：状态跟着请求走，能力按需加载，Memory 用完即释放。这正是后续 GrowBrain PES 三段式架构的工程基础。

系统能力概览图

我们搭建了 GrowBrain：一个以 LLM Agent 为决策中枢的自动化成长引擎。该系统作为核心决策模块深度嵌入当前内容成长链路，直接参与"这条内容要不要流量扶持、给多少 PV、为什么"的最终决策。

为了让GrowBrain稳定可靠地服务于线上每次冷启决策，系统有几个核心设计：

1. Plan-Execute-Summarize （PES）三段式编排。 我们早期试过ReAct模式，边想边做边观察，该架构在极简Demo下跑得不错，但放到生产链路尤其是小模型（4B以下）上发现几个问题：

1. 大量噪声引入：为了在线稳定性，我们在LLM请求时往往会注入大量指导性prompt防止LLM在推理时跑偏，但实践时发现这些prompt在小模型推理阶段会成为LLM的噪声，LLM无法聚焦在关键信息上

2. 小模型幻觉问题：实践发现小模型下，即使在prompt中强调决策数据需要有依据，在ReAct模式下有较高概率会不调用工具（tool/mcp）而直接杜撰数据/结果

3. 循环轮数不可控：同一输入也可能走出不同工具调用路径，没法做灰度对比和线上回放
   

综合上述缺点，我们考虑采用PES三段式这种更为稳定的Agent架构，把"想"和"做"在时序上分开：Planning 先把计划定好，Execute 严格按计划走，Summarize 收口结果并写回系统。使用该架构，执行阶段数量固定，每步任务明确，延迟可估、整体行为可控、并且每次请求决策全链路可回放。

2. Agent 矩阵分工，按任务匹配计算范式。 实践阶段，我们不用一个大模型端到端解决所有问题，而是拆成多个职责专一的子 Agent：

1. 潜力预估Agent 负责分析新内容获流潜力

2. 流量分配Agent 负责流量投资决策（给不给、给多少、什么时候停）

3. 流量诊断Agent 负责回溯分发日志，在推理链中完成获流诊断归因
   

子 Agent 各管各的，出问题能精确定位到环节和模型版本。

3. 双 Pipeline 物理隔离，能力底座共享。 

1. 一条 SystemPipeline 服务线上中控：批量高并发、规则驱动编排、严格 schema 输出，关心吞吐和 SLA

2. 一条 ChatPipeline 服务产运和算法同学的对话需求：自然语言输入、LLM 动态编排执行图、多轮上下文

两条 Pipeline 共享同一套 Agent 矩阵和底层能力（Memory、Prompt 管理、Trace、AB 框架），能力新增一次，两条线同时受益。

4. 决策可解释性白盒化。 Agent 天然输出思考链和决策理由，"为什么给这个数"是决策过程本身的附属产物，不再需要额外挂一个解释模块。

5. 新场景快速接入。 新实验不需要从头搭链路。通过配置层组合已有子 Agent、调整策略超参和 Prompt 模板就能上线，系统每个阶段支持独立替换和AB，迭代周期从周级缩短到天级。

在线效果：成长链路流量投资ROI+8.67%

System模式下GrowBrain系统运行概览图

上游数据接入层生产/内容获流后触发请求 → 任务编排层（根据内容所处扶持阶段，编排不同的子Agent能力） → 确定性Agent 能力矩阵执行（潜力预估Agent / 流量分配Agent / 流量诊断Agent/...）→ LLM模型服务层（支持开源/自训LLM部署） → 下游执行（触发推荐冷启链路、内容状态回写、AB 数据落表、请求日志落盘）→ 后验回流（曝光/CTR/互动反哺特征与下一轮训练）。

在过去一年，我们通过 LLM 丰富的世界知识从样本构建的角度增强潜力预估模型预估效果，并统一了全场域潜力分预估模型，获得了不错的收益。今年我们探索使用 LLM 直接进行潜力分预估，即将潜力预估形式化为：给定内容i及打分任务描述o，模型输出该内容在任务o下的潜力分s(i,o) \in \mathbb{R}。模型如图所示：

潜力预估大模型框架

多模态 Embedding 经 MLP 映射后与 Token Embedding 拼接，经 LLM Backbone 生成表征 F(i,o)。Value Head 取潜力分对应 token 输出潜力分。右侧 Block 展示潜力分判别训练流程。

相比较于小模型，潜力预估LLM核心优势：

• 参数规模带来世界知识，突破数据闭环：传统小模型仅能从历史交互数据中拟合共现模式，对零曝光内容完全无法判别，陷入"强者恒强"的反馈闭环。LLM在预训练阶段已内化大量世界知识，能以接近人类认知的方式理解内容语义：即使从未被曝光过的内容，也可基于标题、类目、创作者画像做出合理的潜力判断

• 统一多模态语义空间：传统模型将各类特征视为独立统计信号，缺乏跨信号的语义关联。LLM Backbone 将文本元数据、创作者效率、图片/视频特征映射到统一的语义空间中进行联合推理，实现多维信号的深层交叉理解，而非简单的特征拼接

• 多场域统一建模：LLM 的自然语言输入格式天然适配不同场域的特征差异，一个模型即可覆盖多个场域的潜力预估，无需为每个场域单独构建特征工程和训练独立模型

• 端到端直出 + 多任务扩展：Value Head 一次前向传播直接输出分数，无需自回归生成，推理延迟极低。多任务头可同时输出 IPV、次均时长、互动率等多维度潜力分，单模型替代多个独立模型

采用CoT Distillation策略，让轻量级模型具备领域知识生成内容差异化投放策略。为了构建高质量的训练数据集，我们引入了反向推理的中间步骤，让大模型（数据分析师）首先学习规则定义的冷启分配策略，通过 CoT 推理进行纠错和增强， 并以此为指导小模型（策略官）进行正向推理输出最终的冷启决策（是否冷启 + 扶持流量）和 创作者反馈（核心亮点/主要问题 + 平台建议/改进建议）。完整流程如下图所示：

CoT Distillation 流程图

• 第一阶段（反向推理）：解读现有 Gating 准入规则和 Allocation 查表逻辑，输出决策诊断报告，定位规则系统的设计局限

• 第二阶段（正向推理）：综合内容画像、规则决策和诊断报告，按 4 步决策框架（致命缺陷审查 → 数据提取校准 → 战略假设诊断 → 行动策略匹配）生成差异化目标PV和创作者反馈理由

• 第三阶段（CoT Distillation）：去除完整思考过程，仅保留 target_pv + reason 构建训练数据，LoRA 微调轻量级生产模型

关键特性：策略框架全部内嵌于 prompt，主控Agent可根据大盘流量、业务诉求通过修改 prompt 指令实时调整策略（类目扶持、质量管控等），响应速度从天级降至秒级，无需代码变更

相比规则迭代，流量分配Agent的核心优势：

• 多维信号交叉推理，而非组合爆炸的规则枚举：规则系统每增加一个决策维度（质量分、创作者互动率、商品效率……），规则数呈指数膨胀且维护成本不收敛。LLM 通过自然语言推理天然处理多维信号交叉，不需要逐条枚举，使目标PV能感知内容质量：高质量内容获得更多流量，低质量内容被合理控制

• 连续信号判断，而非阈值二元切分：规则用硬阈值切"块"，桶内零区分。LLM 对信号强弱做连续判断（“惜败区间”、“信号偏上/中等/达线”），具备双向纠偏能力：既能发现被阈值误杀的高价值内容，也能拦截被误放的劣质内容

• Prompt 驱动策略调整，维护成本低：规则系统响应业务变更需逐条审查修改、回归测试、开发上线（天级）。LLM 的策略框架内嵌于 prompt，业务方修改指令即可实时生效（秒级），且维护成本不随策略复杂度增长

生态算法经常收到问题反馈：为什么这个内容没有流量？为什么这个内容成为了爆款？因此在Agentic内容成长引擎中，我们从召回、粗排、精排、混排、曝光日志构建推荐全链路漏斗诊断数仓，用于内容全生命周期获流归因。

内容流量诊断分层数仓架构图

诊断 Agent 把结构化漏斗事实直接写进推理链，逐层归因。

四类诊断能力：

• 多维分位对比。基于推荐的全链路落盘日志，把每个内容每日的召回/精排/混排/返回/完播/CTR/互动/点赞 8 个核心指标，分别映射到「同类目×同生命周期 / 同类目 / 同生命周期桶 / 全平台」四套基准的 9 档离散分位（0/10/25/50/75/90/95/98/99），并附中文语义标签（极低/低/中下/中位/中上/头部 TOP10%~1%），避免单一全平台口径对长尾内容的不公平比较

• 7 天峰值衰减检测。通过划定近7天流量趋势时间窗口，输出峰值绝对值、峰值日期与 drop_ratio ∈ [0,1]，并区分「持续下降 / 今日下降 / 今日即峰值 / 历史峰值低位」四种状态，定位"是新内容流量没起来还是老内容流量在掉"

• 异常信号规则引擎。数据表内嵌多种异常判断：召回低、精排低、召回衰减 >50%、完播高但精排低（疑似冷启错杀）、漏斗多层级同步下跌、曝光互动率低。这些规则信号也会作为 Agent 推理的输入信号，避免 LLM 凭语义漏掉显性问题

• LLM 文本宽表。最后把数值统一文本化为LLM可读语言，LLM 看到的不是稀疏数字，而是可直接进入 CoT 的数据事实陈述

相比人工归因，流量诊断 Agent 的核心优势：

• 结构化输入，推理链白盒化。规则归因依赖产运/算法人肉分析日志反查瓶颈，定位"卡在哪一层"以日为单位；Agent 拿到的是相近的对齐口径的漏斗数据、四个维度的分位与异常信号，归因结论天然带数据支撑，问题分析直接定位到「层级 + 分位 + 异常」节点。

• 规则信号兜底 + LLM 语义分析。数据异常前置到数据处理阶段，LLM 只在规则之上做基于事实的CoT推理并生成改进建议，既保留小模型可解释性，又避免幻觉漏判明确问题。

• 诊断口径与策略口径同源。诊断侧的漏斗进入率/分位/峰值，与 3.3 流量分配 Agent 的决策输入完全同源，"诊断结论"可直接回流到下一轮投放决策，形成"投放→诊断→反馈"闭环。

GrowBrain 的核心命题是将内容成长决策从"规则拍板 + 人工兜底"升级为 Agent 驱动的智能决策。我们以 LLM Agent 为决策中枢，通过 Plan-Execute-Summarize （PES）三段式编排范式统一调度潜力预估、流量分配、流量诊断三个子 Agent，在生产链路的延迟与稳定性约束下，实现了多维信号的交叉推理、策略的秒级调整和决策的白盒化归因。

三个核心贡献：一是验证了 Agentic 范式在内容成长主链路上的可行性，LLM Agent 不再是外挂工具，而是直接参与冷启决策的核心节点；二是构建了多 Pipeline 共享的能力底座，同一 Agent 矩阵同时服务线上中控、产运对话、平台调用等多条 Pipeline，能力新增一次、全线受益；三是沉淀了小模型生产可靠性工程方法，经过 CoT Distillation 和 SFT 微调的轻量级模型在大规模在线 Serving 中稳定运行。

面向未来，GrowBrain 将继续沿三个方向演进：扩展子 Agent 能力矩阵覆盖更多内容成长环节，将统一架构拓展到更多场域和场景，深化"投放→诊断→反馈"的数据闭环驱动策略持续迭代。