淘宝主播Agent为什么需要Harness

1. 操作即时生效代价极大：Agent 一旦下发指令所以观众可见，错误无法撤回。且主播在镜头前要讲解、要互动、要看数据，没余力去核验 Agent 的动作，意味着 Agent 行为边界必须由工程兜底，而不是纯靠人工。
2. 上下文污染：一场直播里播前准备、中控、商品操作指令交替出现，单轮对话可能同时涉及选品、组货、排序、控场，上下文极易污染和漂移。
3. 失忆问题：一场直播动辄数小时，跨设备切换是常态，会话中断后必须能续上，不能让 Agent"失忆"。

主播Agent设计思路

Harness基础定义

淘宝团队给出的Harness的六层结构如下：

1. Loop：最简单的React循环, 其他层都是这个循环的叠加
2. Tool：工具注册提供具体执行能力
3. Context：上下文管理保留并传递核心信息
4. State：持久化状态管理保证长任务不断、可恢复
5. Hook：拦截Hook在固定节点触发强约束
6. Eval：可观测评测体系看是否真的有用

任何一个 Agent 项目，都可以拿这六层对照，看自己缺了哪一块。

主播Agent的Harness设计

核心思想一句话：业务方专注写 Skill，框架层兜住所有其他脏活。

第一，框架层与业务层的责任划清。 主播业务变化极快，如果每个新需求都要动框架，迭代根本跟不上。所以把"会变的"和"不变的"做彻底拆分：框架提供执行循环、上下文治理、安全防护、状态持久化、审计观测这些"不变的工程能力"；业务方只需以 Skill 形式声明"我这个技能能干什么、风险等级多高、参数怎么校验"，剩下全部由框架兜底。这就是核心思想

第二，多层安全防护。 直播场景容错率极低，任何单一防护层都可能被绕过，所以不能把宝押在某一道关卡上，而是建立了从 Prompt 边界到执行审计的五层纵深防御。

第三，长任务要"可恢复、可观测、可干预"。 三层 Checkpoint 机制保证任意时刻中断都能续上，用 DAG 替代 ReAct 的单步决策，让复合指令能被拆解、编排和故障恢复。

信息源分开存储

主播 Agent 三类核心资产分别存在三个独立的基础设施上：记忆存 Hologres，技能存 GitLab，会话存 MySQL，逻辑上Agent只会感知到一个统一接口，但底层会根据三类资产各自读写特征分别选择后端。

1. 长期记忆存Holo数仓：每条记忆片段段包含原文（支持全文检索）、向量（支持语义检索）、以及JSONB格式元数据（主播ID、平台、信任分等支持精确过滤）通过数仓的原生向量索引可以做混合检索，Agent既能按语义找记忆片段，又能按主播 ID等精确过滤"
2. 技能存GitLab：Skill适合像代码一样版本管理，上线前Code Review、灰度发布；
3. 会话存MySQL：因为会话对一致性和查询耗时要求最高，会话状态信息以user_id + session_id + state_key 复合索引按需查表加载。一个state_key对应一类状态（会话基础信息、原始消息、运行时消息、压缩事件等）

上下文工程

直播特点是话题多，如果放任直播交流内容无限增长，很快就会上下文膨胀、注意力漂移，有以下处理手段

分层压缩而不是无脑截断

直播会话采用了多层压缩策略：

1. 常规情况Token超出压缩阈值走3层压缩：压缩历史工具调用+历史对话消息做摘要 +压缩当前轮次消息；
2. 对话超过N 轮时分段：多轮对话压缩为结构化摘要，并打上场景标签（直播准备/直播中/直播后等），支持按场景检索。既控制体积，又能回查。

Reducer模式更新状态而不是直接追加

传统做法是把每轮工具调用的完整JSON结果，用户消息直接追加到聊天历史里，让模型自己从一长串历史中推断当前任务进行状态，易判断出错同时上下文易膨胀。

淘宝团队做法是借鉴前端状态管理的 Reducer 思想做职责分离：模型只负责决策，Reducer 函数负责状态变更（纯函数保证确定性）

具体行为是每轮对话前把最新的结构化状态序列化后注入，模型看到的是一份干净、确定的新状态快照（当前商品 SKU、当前价格、当前库存、本场直播目标）

大上下文卸载

体量很大但不必时刻使用的内容（如完整的商品列表、长篇的历史数据）直接存到对象存储、缓存；

读取时先从上下文拿到文件编号，在隔离沙箱运行筛选命令，提取所需文本，最终只返回精简摘要，不输出全部原始内容。

工具调用

直播场景最看重工具调用可靠性，一旦发生意外没有时间弥补就被观众看见，在三个方面做强化：

1. 能力边界声明：每个 Skill 注册时都要声明能力范围和限制，Agent 调用前会校验请求是否落在 Skill 的能力范围内；新 Skill 上线前还要通过预检平台，验证是否满足其定位声明。从源头避免了"Agent 越权调用本不该碰的工具"。
2. Schema 强约束 + 幂等设计：所有工具签名(名字、入参、出参)和结果输出都通过 JSON Schema 约束，在结构层面杜绝非法参数。更关键的是幂等性：任何写操作（改价、切品、发券）都必须携带幂等键（UUID）框架层缓存幂等键在执行前校验是否重复，即使网络重试或 Agent 重新规划导致同一个指令发了两次，也绝不会出现"双切品""双改价"这种灾难性后果。
3. 结构化错误码 + 自动修复：工具执行返回的不是一个模糊的报错字符串，而是一套结构化错误码体系，框架根据错误码采取不同的恢复策略：

Hook

Hook是 Harness 里执行"强规则"的关键。在循环的关键时机施加确定性的编码约束。

主播 Agent 在执行循环的几个关键时机挂了 Hook：

• PreReasoning：注入上下文。把最新结构化State、当前场景的预加载会话记忆注入 system prompt，并根据用户query按需加载长期记忆。
• PreToolCall：安全拦截。校验能力边界、检查幂等键、判断风险等级是否要审批（详见五层防护）。
• PostToolCall：状态更新。拉触发 Reducer 更新 State。
• PostReasoning：幻觉检测。验证模型输出是否与直播间真实商品一致，是否正确调用了工具（而不是凭空编造商品信息）。
• OnSessionEnd/直播结束：记忆回写。提炼本次对话 / 本场直播 的场景事件写入记忆文件，触发后台记忆轨迹整合。

Hook 机制的妙处在于，它把"安全""可观测""持续演化"这些切面关注点，从业务逻辑里抽出来，统一收敛到框架管理。业务方写 Skill 时完全不用操心这些，框架会在正确的时机自动触发。

五层安全防护

从 Prompt 到执行审计的五层防护，每一层拦住不同风险，前一层漏掉的后一层兜底。

第一层：Prompt 边界硬编码

在系统提示词里硬编码 Agent 的能力边界与行为禁区。配合 Skill 定位声明（每个 Skill 注册时声明能力范围）和 Skill 预校验（上线前通过预检平台）；
 

第二层：Schema 强约束

即工具调用章节讲的强类型约束 + 幂等性设计，在结构层面杜绝非法参数和重复执行。

第三层：Approval 审批分层。

这是平衡"安全"与"自动化"的核心机制。直播操作不能每一步都让主播确认，也不能全部放行（风险太高），按操作风险做分层审批。平台级红线由框架层定义，Skill 级风险由业务方声明（比如调价范围、商品排序间隔），Skill 需提供对应的校验规则：

第四层：工具执行验证层

由业务方控制，工具执行时做业务规则校验，返回前面讲的结构化错误码，配合框架的自动修复机制。

第五层：执行审计记录

所有工具调用的完整链路都记录下来，服务于四个用途：实时监控（循环执行、调用超时、调用失败等异常操作告警）、事后复盘（按时间线回放完整操作序列）、模型优化（积累高质量工具调用数据集）、争议处理（提供不可篡改的操作证据链）。

异常处理与降级

模型一定会出错，关键是出错时 Harness 能不能优雅兜底。针对 Agent 推理层面的几类典型异常，设计了对应的检测与降级策略：
 

LLM驱动的规划引擎

主播的指令经常是复合的，比如

我想开一场直播但不知道播什么，帮我先生成一个开播提案看看建议，
然后根据提案帮我创建直播间，把最近有商品的那场历史场次的商品同步过来，
给前3个商品分别生成讲解手卡，最后帮我开启智能标题

这一句话里包含直播提案、直播创建、选品、手卡生成等多个子任务，还带先后依赖关系。如果用传统 ReAct 一步步走，很容易顾此失彼、效率低下。

我们的做法是把 ReAct 单步线性决策升级为 DAG 全局规划。这套规划能力围绕五个目标建设：

1. 可恢复：三层 Checkpoint 机制： 一场直播随时可能因为网络、设备切换而中断，用三个粒度的 Checkpoint 保证状态不丢：每轮对话结束后持久化当前状态；每个子任务完成后写入 Checkpoint；整体计划变更时保存完整快照。
2. 可观测：三级状态可视化： 每个子任务有独立 TraceID，支持全链路追踪；实时监控Plan计划、SubTask、Tool Call，主播和运营都能看到 Agent 执行到哪一步了。
3. 提升执行效率：DAG 里无依赖关系的子任务可以并行调度；
4. 提升执行成功率：输出做固定规则 + 语义双重校验；失败子任务自动重试；尤其是增量 Replan：某个子任务失败时，只对后续节点重新规划而不是把整个计划推倒重来。
5. 避免注意力漂移：

1. 1. 执行进度外挂：步骤执行进度和上下文隔离维护，不占用窗口。
   2. SubAgent 上下文隔离：复杂任务拆到独立 SubAgent 执行，避免上下文污染。
   3. Plan 快照持久化：上下文压缩前先把当前 Plan 状态落盘，防止压缩时丢失关键信息；
   4. System-Hint 动态注入：任务状态通过一句简短提示实时注入，把模型注意拉回正轨。

直播场景记忆特殊设计

主播 Agent 的记忆体系不是简单套用通用记忆框架，而是被 Harness 工程的思想深度重塑过的——它和上下文管理（C）、状态存储（S）、Hook（Ｈ）、评估（Ｅ）这几个 Harness 模块紧密关联

和通用记忆系统区别

先用一张表把"主播场景记忆"和"通用记忆系统"的差异摆出来：

三层记忆模型

主播 Agent 记忆按"来源"分成三层，这是它区别于通用记忆架构最核心的设计：

L1 记录主播的主观诉求（短期会话级），L2 是客观数据，L3 是历史行为规律（长期记忆），L2和L3负责对 L1 进行客观信息补充。 冷启动阶段，Agent 基于 L2、L3 的历史数据给主播推荐方案；再基于交互反馈不断进化。

遗忘机制

遗忘机制也比通用的＂权重按时间衰减＂精细一些，采用多因子加权衰减：

• 场景相关性：常播的品类规则遗忘慢
• 信息新鲜度：偏好、话术模板等经验型记忆衰减速度慢；价格、平台规则等实时性强的衰减快。
• 时间：常规按时间衰减。
• 可信度因子：经过验证、使用频率高的记忆获得加成；证伪的记忆降权或删除；未验证的保持基础衰减

配合定时清理策略（如召回次数 ≤ 阈值），以及记忆冲突处理（如谁最后写入就信谁、给片段标注自定义优先级，或召回时把冲突给 Agent 主动确认），保证记忆库长期不失控、不腐坏。

评测体系

可追踪、离线 + 在线双渠道评测体系

trace分析：接入Langfuse可视化trace

离线评测：构建播前/播中/播后各场景的标注数据集；特别加入对抗样本，包含各种边界 Case（极端改价、违规诱导、模糊指令），专门用来验证前面五层防护到底有没有效。

在线评测：一块实时指标看板盯着几个核心指标：操作成功率（工具调用成功数/总调用数）、审批通过率（soft-gate/hard-gate 通过率，过低说明 Agent 决策质量下降）、主播人工干预率（反映自主决策的可靠度）、端到端延迟（指令发出到操作完成的全链路耗时）。

主播满意度评测：每场直播结束后主播给 Agent 表现打分（1–5 分），作为会话级的主观质量信号。

langfuse trace分析

评测平台

实时指标监控