Agent 这两年很热，但真正把 Agent 放到生产环境里跑过的人，大多会很快冷静下来。模型能推理、能调用工具、能写计划，这些都很重要，但一旦它开始操作真实业务系统，问题就不再是“模型聪不聪明”，而是“出了错谁兜底”。
淘宝直播里的主播 Agent，是一个很典型、也很苛刻的场景。它不是帮个人整理文件、写脚本、查资料，而是在直播间这种高频、实时、公开、强业务后果的环境里辅助主播做决策和操作。切错商品、发错券、改错价，都不是日志里重跑一次就能解决的事情。
这也是 Harness Engineering 变得重要的原因。模型本身是概率系统，会漂移、会误解、会偶发失控。真正让 Agent 从 Demo 走向线上产品的，往往是模型外面那层工程骨架：上下文怎么组织，工具怎么约束，状态怎么恢复，风险怎么审批，行为怎么审计，质量怎么评估。
一、主播 Agent 为什么需要 Harness
很多公开的 Agent 实践，验证场景更接近个人助手：单用户、本机运行、任务失败了看日志、调 Prompt、再跑一次。这个形态下，Harness 可以做得轻一些，甚至一个本地 Workspace 加一组工具协议就能撑起不少能力。
直播间不是这个约束条件。
淘宝主播 Agent 面临的压力主要来自四个方向。
第一，操作即时生效，而且面向公众。Agent 一旦下发指令，结果会直接作用到直播间。错误操作很难撤回，成本也可能是真金白银。
第二，主播注意力极度稀缺。主播在镜头前要讲品、互动、看数据、控节奏，不可能逐条核验 Agent 的动作。如果每一步都需要人工确认，Agent 的价值会被抵消；如果完全放开，又不安全。
第三，多话题高频交织。一场直播里，播前准备、中控指令、商品操作、用户互动、数据分析会混在一起。单轮对话可能同时涉及选品、组货、排序、控场，上下文很容易被污染。
第四，任务长程、可中断、必须恢复。直播动辄数小时，跨设备、跨端切换很常见。会话中断后，Agent 不能“失忆”，更不能把已经执行过的步骤再执行一遍。
这些约束决定了，主播 Agent 的关键不只是“让模型回答得更好”，而是给它修一套河道和护栏。模型像水流，负责在边界内自主推进；工程师要做的是河道、闸门、护栏和水位监测。
在这个语境下，Harness 可以抽象成六个职责：
| 模块 | 核心职责 | 主要对抗的问题 |
|---|---|---|
| Execution Loop | 驱动 Agent 的思考、行动、观察主循环 | 死循环、无限重试、跑飞 |
| Tool Registry | 定义工具能力、边界、参数和错误反馈 | 能力边界模糊、参数非法 |
| Context Manager | 维护上下文质量与体积 | 上下文膨胀、注意力漂移 |
| State Store | 持久化运行状态，支持中断恢复 | 长任务丢状态、不可回放 |
| Lifecycle Hooks | 在关键时机插入强规则 | 模型不可控、强约束难落地 |
| Evaluation Interface | 提供可观测、可分析的评估体系 | 质量不可量化、问题不可追溯 |
这套划分的价值在于，它把 Agent 工程从 Prompt 技巧和 if-else 堆叠，拉回到系统架构。一个 Agent 项目做得稳不稳，基本可以沿着这六个维度逐项检查。
二、框架兜底，业务写 Skill
主播业务变化非常快。今天要加播前规划，明天要改排品策略，后天又要支持新的中控动作。如果每个业务变化都要修改 Agent 框架，工程复杂度会很快失控。
淘宝主播 Agent 的一个关键取舍，是把框架层和业务层拆干净。
业务方以 Skill 的形式声明能力：这个技能能做什么、风险等级多高、参数 Schema 是什么、校验规则是什么。框架层负责执行循环、上下文治理、安全防护、状态持久化、审计观测这些相对稳定的工程能力。
这个拆分看起来朴素，但在生产环境里很关键。很多团队做 Agent 卡住，不是模型能力不够，而是业务逻辑、安全规则、状态管理、工具调用全部搅在一起。早期跑得很快，后期每加一个能力都像拆炸弹。
更合理的方式是：业务能力可以快速变化，但 Harness 的骨架要稳定。
可以把主播 Agent 的分层理解成这样：
这里有三个工程原则。
一是安全做纵深防御，而不是押宝单点。Prompt、Schema、审批、工具验证、审计，每一层拦不同类型的风险。
二是长程任务必须可恢复、可观测、可干预。直播不是短任务，不能只靠内存状态和聊天历史撑着。
三是业务层只关心 Skill 表达，框架层负责脏活。这个边界一旦模糊，Agent 系统会很快变成不可维护的复杂体。
三、统一工作区背后的物理分治
不少 Harness Framework 喜欢用一个文件系统 Workspace 作为 Agent 的事实来源。在单机个人助手里，这个设计很优雅：文件天然可读写、可回放、可审计。
但主播 Agent 要服务大量主播，要多副本水平扩容，要支持高并发实时读写。单一文件系统的假设不太成立。
淘宝主播 Agent 的做法是：逻辑上仍然向 Agent 暴露统一工作区，物理上按资产类型拆到不同基础设施。
| 资产类型 | 物理存储 | 选型理由 | 读写特征 |
|---|---|---|---|
| 会话信息 | MySQL | 强一致、点查高效，适合按 session_id/live_id 加载 | 在线频繁读写 |
| 记忆 | Hologres | 支持向量、全文、标量混合检索 | 在线高频检索、异步写入 |
| Skill | GitLab | 适合代码化维护、版本管理、Code Review、灰度发布 | 离线维护、发布加载 |
这个设计有一个很现实的工程判断：不要指望一种存储解决所有问题。
会话状态对一致性和点查性能要求高，适合放 MySQL。记忆系统需要语义检索、关键词检索、标量过滤一起工作，更适合 Hologres 这类支持混合检索的系统。Skill 本质是代码资产，放 GitLab 更自然，能走版本管理、预检、Review 和灰度。
长期记忆的数据模型也不是简单的一段文本。每条记忆片段包含原文、向量和 JSONB 元数据。原文支持全文检索，向量支持语义召回，元数据负责主播 ID、场次、来源、信任分、使用次数等过滤条件。
真正值得注意的是抽象层。框架对 Agent 暴露的是“加载上下文、读写记忆、调用技能、持久化状态”这些语义接口，而不是 Holo、MySQL、GitLab 的具体实现。底层存储未来可以演进，但业务代码不用被反复冲击。
这就是典型的工程 trade-off： 统一文件系统的抽象更简单，但不适合大规模在线服务；多存储分治会增加框架复杂度，却能让每类资产跑在合适的基础设施上。主播 Agent 这种场景，后者更值得。
四、上下文工程是第一道硬仗
上下文是 Agent 决策的输入地基。地基不干净，后面工具调用、计划生成、安全判断都会被带偏。
直播场景的上下文有两个天然问题：一是长，二是乱。聊天记录、商品数据、历史场次、主播偏好、实时指标、工具返回值都可能进入上下文。如果无脑追加，很快会遇到 Token 膨胀、延迟升高、成本失控，以及更隐蔽的注意力漂移。
主播 Agent 的上下文治理主要靠三件事。
分层压缩，而不是粗暴截断
简单截断聊天历史很危险。很多关键约束可能出现在很早之前，比如“这个品牌今天不能上”“某款商品粉丝反馈不好”。截断后，模型看不到这些信息，就可能做出错误决策。
更稳妥的方式是分层压缩：保留近期细节，把中期对话压缩成结构化摘要，把长期信息沉淀到记忆系统。压缩不是为了省 Token 而省 Token，而是保证模型每一轮都看到“当前最该看的东西”。
Reducer 管状态，而不是让模型读流水账
传统 Agent 常见做法，是把工具调用结果完整追加到消息历史里，让 LLM 自己从一堆 JSON 中读懂当前状态。这个方式在简单任务里能跑，但直播间会很快出问题。
工具结果可能很长，历史状态和最新状态混在一起，模型还要自己判断哪条是最终值。一旦商品价格、库存、排序频繁变化，聊天历史会变成一个噪声池。
淘宝主播 Agent 借鉴前端状态管理里的 Reducer 思想：LLM 负责决策，Reducer 负责确定性状态变更。
这样每轮对话前，模型看到的是最新的结构化 State 快照，比如当前商品、价格、库存、场次目标、已执行计划，而不是一长串历史 JSON。
这类设计看似不“智能”，但很可靠。生产环境里，越是关键状态，越不应该交给模型从自然语言历史里自己推断。
大上下文卸载
完整商品列表、历史数据、大文件这类内容，不需要长期塞在 Context Window 里。更合理的方式是卸载到外部存储，只在上下文里保留路径 ID、摘要和预览。
模型需要详细数据时，再通过工具按需读取。这样既控制 Token，又避免大块低价值内容干扰推理。
五、工具调用要有边界、有幂等、有恢复
Agent 一旦可以调用工具，就进入了真实业务系统。这里最怕三件事：越权调用、参数错误、重复执行。
主播 Agent 在 Tool Registry 层做了几类约束。
第一，每个 Skill 注册时声明能力边界。框架在调用前检查请求是否落在能力域内。新 Skill 上线前也要经过预检平台，验证它的声明、Schema 和风险规则。
第二，所有工具签名和决策输出都通过 JSON Schema 约束。模型输出必须先过结构校验，不能把非法参数直接送进业务系统。
第三，所有有副作用的写操作都必须幂等。改价、切品、发券这类动作，要携带幂等键。框架执行前做去重校验，即使网络重试或 Agent 重新规划，也不能发生“双切品”“双改价”。
第四，工具错误必须结构化返回。模糊报错字符串对 Agent 没什么帮助，框架也很难恢复。更好的方式是错误码分类：
| 错误码 | 类别 | 框架行为 |
|---|---|---|
| 3xxx | 业务异常，如越界、权限不足 | 解析 AI 友好错误，尝试换策略 |
| 4xxx | 参数异常，如类型错误、缺失字段 | 自动修复参数后重试 1 次 |
| 5xxx | 系统异常，如超时、服务不可用 | 最多重试 3 次，指数退避 |
| 9xxx | 不可恢复异常 | 不重试，通过 Hook 通知主播 |
这里有个容易被忽视的点：自动修复不是无限重试。生产环境里，无限重试和死循环本质上是事故放大器。每类异常都要有明确的重试预算和退出路径。
六、Hook 把强规则插进推理循环
Lifecycle Hooks 是 Harness 里很实用的一层。它不需要改写模型的推理过程，而是在关键节点做拦截、注入、记录。
比如：
- 调用工具前，检查权限、风险等级、幂等键；
- 工具执行后，校验返回结果是否可信；
- 回复主播前，检查是否引用了未经验证的商品信息；
- 状态变更时，写入审计日志和 Checkpoint；
- 异常发生时，触发降级策略或人工确认。
Hook 的价值在于把安全、审计、观测这些横切能力从业务 Skill 里抽出来。业务方写 Skill 时不需要每次都手搓防护逻辑，框架会在统一位置执行强规则。
这也是 Harness 和普通 Agent 框架的一个分水岭：前者会承认模型不可完全控制，所以用工程机制兜底；后者容易把所有规则都塞进 Prompt，最后变成一份越来越长、越来越脆的系统提示词。
七、五层安全防护扛住直播风险
直播操作的安全不能靠单点。淘宝主播 Agent 采用的是纵深防御，从 Prompt 边界到执行审计分成五层。
第一层是 Prompt 边界硬编码。系统提示词里声明能力边界和禁区，配合 Skill 能力声明和上线预检，先在意图层面收窄风险。
第二层是 Schema 强约束。结构上不合法的参数，不允许进入工具执行。
第三层是 Approval 审批分层。这里是安全和体验的核心平衡点。直播操作不能步步确认，也不能全部放开，所以按风险等级分流。
| 风险等级 | 触发条件 | 审批方 | 策略 |
|---|---|---|---|
| auto | 查询、话术建议等无副作用操作 | 系统 | 直接放行 |
| soft-gate | 有副作用但在安全阈值内 | Skill 规则 | 会话中提示，立即执行 |
| hard-gate | 品类操作、批量操作等高风险动作 | 主播 | 阻塞等待二次确认 |
| block | 触发平台红线 | 框架 | 直接拒绝并告警 |
第四层是工具执行验证。业务系统在真正落地时继续做规则校验，并返回结构化错误码。
第五层是执行审计。所有工具调用的生命周期都被记录，用于实时告警、事后复盘、模型优化和争议处理。
这个设计的关键不是“安全层数多”，而是每层职责不同。Prompt 管意图边界，Schema 管结构合法性，审批管业务风险，工具验证管落地规则，审计管可追溯。混在一起做，通常会又复杂又不可靠。
八、沙箱把不可信执行隔离开
只要 Agent 能执行 Shell、运行脚本、调用第三方 Skill，就必须把输入当作不可信。很多本地 Agent Demo 在可信开发环境里跑没问题，但一旦做成服务，把任意输入直接丢宿主机执行就是严重攻击面。
主播 Agent 对代码类执行统一套沙箱：
- 容器以非特权用户运行；
- 根文件系统只读；
- CPU、进程数做配额限制；
- 默认禁止出站网络，只按 allowlist 放行；
- 系统调用走白名单；
- 不向沙箱注入宿主机环境变量；
- 工具 timeout 有硬上限，Agent 只能缩小不能放大；
- stdout、stderr 设置大小上限，超出截断；
- 执行代码、输出、user_id、session_id 全量写审计日志。
这里的原则很清楚：模型生成的代码、用户上传的脚本、第三方 Skill，都不能因为“看起来合理”就获得宿主机信任。沙箱不是锦上添花，而是 Agent 工具生态的基础边界。
九、PlanEngine 从单步 ReAct 走向 DAG
ReAct 模式适合很多探索型任务：思考一步，调用一个工具，观察结果，再继续。但主播场景里，用户指令经常是复合任务。
比如：
帮我生成一份开播提案，然后创建直播间，把最近一场有商品的历史场次同步过来，给前 3 个商品生成讲解手卡，最后开启智能标题。
这类任务包含直播提案、场次创建、商品同步、手卡生成、配置开启等多个子任务，而且有依赖关系。如果用单步 ReAct，很容易局部最优、来回试探、重复调用工具。
淘宝主播 Agent 用 LLM 驱动的 PlanEngine，把复杂任务规划成 DAG。
DAG 规划带来几个直接收益。
第一，可恢复。系统在三类时机写 Checkpoint：每轮对话结束、每个子任务完成、整体计划变更。中断后可以按状态归一恢复，而不是从头再跑。
第二，可观测。Plan、SubTask、Tool Call 三级状态都可追踪，每个子任务有独立 TraceID。主播和运营能看到 Agent 执行到哪一步，而不是只看到一个转圈状态。
第三，可并行。没有依赖关系的子任务可以并行调度，降低端到端耗时。
第四，可局部重规划。某个子任务失败时，只对受影响的后续节点 Replan，不需要把整个计划推倒重来。
第五，降低上下文漂移。计划进度独立外挂，不占用对话上下文；复杂任务可以拆给 SubAgent，隔离上下文；计划快照先持久化，再做上下文压缩。
从测试结果看，在播前规划、直播策略、商品操作等平均 7 步的复杂任务上，PlanEngine 相比原生 ReAct 有明显提升：
| 对比项 | PlanEngine | ReAct |
|---|---|---|
| 执行成功率 | 0.847 | 0.737 |
| 子任务覆盖率 | 0.976 | 0.883 |
| 工具执行冗余率 | 0.587 | 0.727 |
| 迭代轮次 | 5.440 | 8.020 |
这个结果不意外。ReAct 强在灵活探索，DAG 强在复杂任务编排。直播场景更需要后者，尤其是任务有明确依赖和副作用时。
十、评测让 Agent 质量可追踪
Agent 系统最怕“感觉还行”。在生产环境里，感觉不能定位问题，也不能指导迭代。
主播 Agent 的评测体系分成离线和在线两部分。
离线评测主要覆盖播前、播中、播后典型场景，并加入对抗样本，比如极端改价、违规诱导、模糊指令、边界权限等。这类样本的目的不是刷高平均分，而是验证安全防护有没有真实生效。
在线评测关注实时指标：
- 操作成功率：工具调用成功数 / 总调用数；
- 审批通过率：soft-gate、hard-gate 的通过情况；
- 主播干预率：主播主动纠正 Agent 行为的频率；
- 端到端延迟：从指令发出到操作完成的全链路耗时；
- 会话满意度：每场直播结束后的主播主观评分。
Trace 也很关键。接入 Langfuse 这类可视化追踪系统后，可以把一次 Agent 行为拆成 Prompt、规划、工具调用、Hook、审批、状态写入等链路节点。线上问题定位会从“模型又抽风了”变成“哪个节点输入错了、校验漏了、工具慢了、还是规划偏了”。
十一、记忆系统要能对账，而不是只会记住
如果前面的 Harness 解决的是“能干活、不出事”，记忆系统解决的是“越用越懂主播”。
但主播 Agent 的记忆不能简单套通用记忆框架。因为直播间里，记忆会直接影响操作建议。记错偏好、误判商品、过度相信历史经验，都可能带来业务风险。
主播记忆和通用记忆的差异大致如下：
| 维度 | 通用记忆系统 | 主播场景 |
|---|---|---|
| 短期记忆 | 多层压缩 | 多层压缩 会话场景摘要 直播信息结构化 |
| 时间粒度 | 对话轮次、按需触发 | 直播场次、事件驱动 |
| 记忆分层 | 画像、经验、通用方法 | 主播画像、领域划分、事实决策路径 |
| 遗忘机制 | 时间衰减、矛盾覆盖 | 多因子衰减，结合场景、新鲜度、可信度 |
主播 Agent 的长期记忆按信任来源分成三层：
| 层级 | 性质 | 典型内容 |
|---|---|---|
| L1 会话记忆 | 主播主观声明 | 偏好、约束、反馈 |
| L2 事实记忆 | 客观可查事实 | SKU、价格、库存、风控词、转化数据 |
| L3 行为记忆 | 客观但需聚合归纳 | 切品节奏、主推时长、粉丝价格带响应 |
这个分层很重要，因为主播“说的”和“做的”可能不一致。
主播可能说“开场先上引流款”，但最近几场实际都先上了氛围款，而且效果不错。通用记忆系统很容易简单覆盖，或者保留冲突不处理。主播 Agent 更稳妥的做法是记忆对账。
| 对账结果 | 示例 | 系统行为 |
|---|---|---|
| 一致 | 主播说主推讲 10 分钟，近几场也基本如此 | 提升该规则 confidence |
| 矛盾 | 主播说开场上引流款，实际多次上氛围款 | 记录 gap，不覆盖 L1 |
| 矛盾累积 | gap 达到阈值 | 主动询问是否更新偏好 |
这个策略背后的工程取舍很值得参考：矛盾时不粗暴覆盖，而是累积证据，到阈值后让主播确认。它尊重主播主观意图，也允许系统基于客观事实进化。
十二、信任度是可以工程化的
主播 Agent 的记忆演化依赖 Decision Trace Log。每次关键建议都会记录：
| 字段 | 写入时机 | 含义 |
|---|---|---|
| decision_point | 建议展示时 | 选品、排序、时长、切品等决策点 |
| question | 建议展示时 | 主播问了什么 |
| agent_output | 建议展示时 | Agent 给出的建议和来源 |
| trust_at_moment | 建议展示时 | 当时 trust 值 |
| anchor_action | 主播操作时 | accept / reject / modify |
| anchor_alternative | 主播操作时 | 主播替代方案 |
| lift | 播后归因时 | 增量效果 |
| trust_delta | 播后归因时 | 信任变化 |
然后通过播后归因更新 trust_score：
| 事件 | trust 变化 | 设计意图 |
|---|---|---|
| 主播采纳且效果好 | 0.05 | 建立正循环 |
| 主播采纳但效果差 | -0.10 | 给错建议要更重惩罚 |
| 主播拒绝但事后 Agent 对 | 0.03 | 慢慢建立信任 |
| 主播拒绝且主播判断对 | -0.05 | 修正 Agent 判断 |
trust_score 反过来影响 Agent 的输出形态：
| trust 区间 | 输出方式 |
|---|---|
| ≥ 0.7 | 直接给建议、反例、替代方案和把握度 |
| 0.4 ~ 0.7 | 给证据和弱建议 |
| < 0.4 | 只给数据，不给方向性建议 |
这套机制把“主播信不信 Agent”从模糊感觉变成了可度量、可解释、可演化的工程量。它也提醒我们，Agent 记忆不是越多越好，关键是记忆来源、可信度、冲突处理和输出策略要闭环。
遗忘机制同样不能只靠时间衰减。主播场景会综合考虑场景相关性、信息新鲜度、时间、可信度、采纳次数、召回次数等因素。低价值、过期、长期未被使用的记忆要清理，否则记忆库会腐坏，最终反过来污染上下文。
淘宝主播 Agent 的 Harness 实践，核心其实一直围绕一个问题展开：模型能力不确定，怎么把它工程化成一个在高风险场景里可用、可控、可演化的系统。
答案不在某个更长的 Prompt，也不在单次模型升级，而在模型外面的系统骨架。
Execution Loop 控制节奏，Tool Registry 收住能力边界，Context Manager 保证输入质量，State Store 支持恢复，Lifecycle Hooks 落地强规则，Evaluation Interface 让质量可追踪。再叠加分层审批、沙箱执行、DAG 规划、记忆对账和信任度演化，Agent 才有机会从“能演示”走到“敢上线”。
模型会继续变强，这是确定的。但越往真实业务走，Harness 的价值越明显。因为生产环境真正需要的，不只是一个聪明的模型，而是一套能在约束条件下持续稳定运行的工程系统。
