淘宝主播 Agent 的 Harness 工程实战(原文摘要)

一句话总结

把 Harness 从”个人助手形态”推到”淘宝直播”这个操作不可撤回 + 注意力稀缺 + 多话题高频交织 + 长程可中断的极端压力测试场,落地为”业务方写 Skill / 框架层兜底脏活“的工程化骨架。

5 条核心观点

  1. Harness 六元组 = (E, T, C, S, L, V):Execution Loop / Tool Registry / Context Manager / State Store / Lifecycle Hooks / Evaluation Interface。把零散 Prompt 技巧升级成有明确分工的系统架构,任何 Agent 项目都可拿这六个维度自查缺哪一块。
  2. 业务/框架分层 + 五层纵深防御:业务方以 Skill 形式声明能力与风险,框架层兜住执行循环/上下文/安全/状态/观测。”纵深防御”不是单点:Prompt 边界 → Schema 强约束 → Approval 审批分层 → 工具执行验证 → 执行审计记录。
  3. 逻辑统一、物理分治:逻辑上向 Agent 暴露统一”工作区”抽象;物理上三类资产分开存——MySQL 存会话(强一致+点查)/ Hologres 存记忆(向量+全文+标量三路召回)/ GitLab 存 Skill(版本管理+Code Review+灰度发布)。
  4. Reducer 上下文 + 结构化错误码 + 生命周期 Hook:LLM 只决策(产生 Action),Reducer 维护状态(纯函数),每轮 system-hint 注入干净快照;错误码分 3xxx/4xxx/5xxx/9xxx 决定自动重试还是 Hook 通知;Hook 在 PreReasoning / PreToolCall / PostToolCall / PostReasoning / SessionEnd 5 个关键时机拦截。
  5. 记忆对账 + 信任度自进化:L1 会话记忆(主播声明)/ L2 事实记忆(实时数据)/ L3 行为记忆(离线聚合)。”主播说的”和”主播做的”矛盾时不粗暴覆盖 L1,而是累积证据 ≥ 3 次后 Agent 主动和主播确认;trust_score 决定输出形态(≥0.7 给 recommend,0.4-0.7 给 evidence+弱参考,<0.4 只给 evidence)。

关键参数/数字

项 数字/范围 用途
Harness 六元组 (E, T, C, S, L, V) 系统架构形式化
沙箱资源配额 CPU ≤ 50%,进程 ≤ 64 防止资源耗尽攻击
沙箱 stdout/stderr 上限 64KB 防止海量输出污染上下文
工具 timeout Agent 只能缩小不能放大 防止 Agent 长期占死沙箱
结构化错误码 5xxx 重试 最多 3 次,指数退避 系统异常处理
PlanEngine vs ReAct 成功率 0.847 vs 0.737 DAG 规划价值
PlanEngine vs ReAct 子任务覆盖率 0.976 vs 0.883 DAG 全局规划价值
PlanEngine vs ReAct 工具执行冗余率 0.587 vs 0.727 DAG 减少重复工具调用
PlanEngine vs ReAct 迭代轮次 5.440 vs 8.020 DAG 提效
Approval 4 档 auto / soft-gate / hard-gate / block 风险分层审批
trust_score 增量表 +0.05 / -0.10 / +0.03 / -0.05 非对称信任度更新
矛盾累积阈值 ≥ 3 次 触发 Agent 主动确认
离线评测 极端改价/违规诱导/模糊指令对抗样本 验证五层防护

核心金句

  1. “模型会一代代变强,但包裹模型的这层 Harness 工程,才是把’能用的 Demo’变成’敢上线的产品’的真正壁垒。”(全文收尾)
  2. “模型再强,没有河道也会泛滥成灾;河道修好了,哪怕水流有波动,整体也是可控的。”(ATA”水流理论”)
  3. “主播’说的’和’做的’不一定一致。”(记忆对账的朴素起点)
  4. “矛盾时不粗暴覆盖,而是累积证据、达到阈值后由 Agent 主动和主播确认。”(记忆工程取舍)
  5. “业务方专注写 Skill,框架层兜住所有安全、状态、上下文与可观测的脏活。”(分层架构核心思想)

关联图谱

上游(基于 / 来自)

下游(应用于 / 验证于)

同级(横向 / 并列)

备注与限制