跳转至

淘天方舟 AI 会场 Agent Harness：从一句话到可投放的线上会场

📊 Level ⭐⭐ | 19.2KB

核心命题

大淘宝技术（淘天集团-营销&交易技术团队，作者巷年）把"AI 一句话生成 HTML"推进到可淘内货品运营、可 C 端投放的生产级会场系统：一句话需求经策划、视觉设计、数据装配与页面构建的完整链路，产出承载视觉规范、商品供给与渲染协议的 HTML 产物，目标"想法即生成，生成即可投放"（淘内已有大量页面在投放上线）。它明确反驳了三类 Demo 级假设——AI 直接生成的 HTML 无法支撑淘内渲染体系（性能、埋点、商品数据动态渲染）、AI 会胡编商品数据（给了数据仍要回答个性化推荐/白底图 vs 场景图/定坑与利益点）、不加排版材质情绪的约束则视觉达不到淘天设计水准。

四特点与业务流程

四个特点：内容实时策划（人群/场景/热点挖掘）、淘天设计水准（沉淀淘系会场设计经验生成精修会场）、真实货品运营（淘内商品圈选与投放）、C 端线上投放（淘内或端外）。流程四步：①内容与供给产出——策划 Skill 多轮挖掘人群/场景切口、核验类目与供给，产出《会场策划.md》与选品集 ID 交用户确认；②设计与数据分别准备——版头与风格遵循视觉 Skill 并保留视觉基准，数据阶段建立数据插槽、投放与召回关系；③构建页面并交付——把数据接到真实卡片生成 page.html，检查后保存版本进入生码/审批/发布；④主 Agent 贯穿链路——确认、委派、验收、二次编辑都由它承接，并给出反直觉判断："业务阶段不等于七个长期 Agent，独立子任务才适合并行"。

三类环境的 Harness 构建

Harness 的价值被定义为"把'会场怎么做'变成模型可理解、可操作、可检查的工作环境"，方舟 AI 着力表达的是三类环境而非通用的 skill/tool/subAgent 架构图：

  1. 会场域认知环境：视觉认知解释会场的设计语言，数据认知解释供给归属，生码认知理解数据协议；核心通过 Skill 渐进式加载。
  2. 业务 Agent 的工作环境：工作区与操作环境如何建设、会场域认知知识怎么来、业务工具怎么来、如何用 SubAgent 降低耗时并隔离上下文、上下文工程如何优化。
  3. Agent 的自迭代环境：设计阶段在设计语言规范下最大化视觉创造力、在动态数据协议下灵活调整货品，同时保障交付确定性，并监控观测运行过程以反哺 Agent 迭代。

一份 HTML 承载三项约束

html 只是底层协议，可用、可运营、可投放还需要三类约束同时成立：视觉设计是软约束（visual-design 与风格 Skill 守住气质、视觉层级与关键特征，相框、字体、层叠、留白仍可组合——"让模型把设计做好，而不是照模板填空"）；货品数据是认知约束（page-data 建立选品、Slot 与召回认知，字段协议规定内容如何进入页面，AI 要分清哪些内容随页面保留、哪些来自商品字段）；生码是硬约束（page-build 与 Ark 协议规定 Section、卡片、字段的表达与装配边界——外观自由，但节点归属、字段位置、动态组件输入必须明确）。

page.html 是 AI 设计的冲突中心

同一棵 DOM 同时承载布局、供给、字段绑定与转码要求，这些关系可以对应却不能强行合并成同一层级，局部修改可能改变另一环节赖以成立的前提：①同一棵 DOM 被三种方式解释——视觉设计看 DOM 结构与盒模型、数据链路识别 Slot/组内位置/字段承载节点、转码链路提取楼层/组件/样式关系；②视觉分组 ≠ 供给分组（同楼层可混排不同 Slot，同 Slot 卡片可跨行异样式）；③加 wrapper 会改变布局前提（为 Slot 包一层容器，Grid/Flex 直接子项就变了，跨行跨列与位置选择器受影响；display: contents 同样改变 DOM 父子关系）；④因此供给写进属性、布局保留层级——协议把 data-ark-slot、data-ark-index 直接写在卡片 <a> 上，运行时按 a[data-ark-slot][data-ark-index] 定位并绑定字段（Render.ts），两种分组分别表达。

多维认知下的二次编辑

运营对会场的修改要按对象分类：改视觉与样式（整体换风格加载 visual-design + 选中 visual-style-*，先生成新视觉稿再按 page-build 构建；字号/静态文案等局部微调直接编辑当前 page.html）；改供给（如"修护区换成 200 元以内的商品"——由 page-data 定位受影响 Slot，需新建或替换选品集时先加载 selection-dataset 校验候选，再同步供给与召回）；改数据投放（如"左侧主推坑只投选品集 B、其他坑继续用 A"——按固坑规则拆出独立数据插槽，原插槽继续服务其余卡片）；改文案（楼层标题可直接改，商品卡内名称/价格/卖点要沿 data-ark-field 判断来源，动态值由运行时替换）。AI 先识别诉求与影响范围，再从 Skill 库入口索引主动选择能力、按需加载正文并补读参考文件，混合诉求按依赖顺序处理，最终回到同一份页面复核三类认知是否仍然一致。

视觉设计语言 Skill 化（30+ Design Skill）

与设计师合作产出 30+ Design Skill，把会场设计语言（情绪、材质、排版、组件结构、色彩角色、禁用规则）变成 AI 可理解的 skill（例："海报拍立得"保留倾斜黑板、摆正面板与粗描边；LOOKBOOK 强调扁平、无投影、编辑式排版）。保证遵循度的关键在于任务目标会漂移（设计追求表现力→数据阶段关注供给→页面构建关注协议），因此采取四步：①先让当前任务专注视觉（确认版头与风格后只加载 visual-design 与 visual-style-*，专注设计语言与稳定盒模型，不同时处理 Slot/召回/绑定，减少多规则争抢注意力）；②精确色值交给工具、视觉表达留给 AI（先用工程手段像素采样与统计返回底缘色、主色簇等稳定可复核色值，减少模型看图猜 hex 的偏差）；③把视觉成果保存成独立产物（designPageVisual 生成 {主题}-{风格}-visual.html，先定布局/配色/字体/装饰再进入数据与页面构建）；④数据装配遵守已有视觉结构。

规则要能熬过压缩：Skill 工具把加载的完整正文包装为带名称的 <skill-loaded> 消息并独立持久化——普通轮次微压缩不把这类规则消息当作普通 read 结果清理；历史重建或完整压缩后按加载记录与预算重新恢复正文，超长时保留截断与补读提示，避免压缩后"只剩一句风格摘要"。

真实货品运营：Slot、选品集与一句诉求的推导

商品数据不是 HTML 里的一个 div，底层是数据运营与在线链路渲染逻辑。AI 需通过 page-build 协议定位 Section、商品卡与字段节点（卡内标题/价格/图片是动态字段，楼层名可能是静态文案）；data-ark-index="0" 只是组内位置不代表固定商品，固定主推要回到选品与投放规则；从 data-ark-slot 找到 page-data.json 映射关联真实 Slot、投放与选品集，selection-dataset 说明 ID、类目、价格带如何变成候选。

对一句诉求"第一个坑位固定主推 A，紧接两位只放修护类，其余继续个性化，布局不动"的推导链是：①定位现状（"第一坑"是位置不是商品 ID）；②用 Skill 建立准绳（selection-dataset 说清有效选品条件，page-data 说清插槽共享规则与独立商品区需独立投放单元）；③落实为数据方案（A 用商品 ID 条件建独立选品集与 pin Slot；修护区建 repair Slot；其余保留原 recommend）；④先核验供给再执行——候选不足要暴露，"不能写静态卡片掩盖"；⑤落到卡片并验收（主推位绑 pin/0，修护区绑 repair/0、1，检查四个要求同时成立）。

上下文分层与 prompt cache 的真实复杂度

上下文按重要性四层：P0 核心约束与执行事实（系统提示词、用户目标）/ P1 已加载的关键 Skill（设计风格、页面协议）/ P2 当前判断所需信息结果（当前 html、当前截图）/ P3 已过时、可重取的信息结果（read 工具结果、早期截图）。高重要性上下文（如 Skill）在全量压缩时要显式恢复，低重要性上下文在合适时机（如缓存冷却）清除。

prompt cache 远不止"保持前缀一致 + 默认 5min"：同轮对话中消息只新增到末尾、不篡改历史，但上下文全量压缩会造成一次整体 miss，SubAgent 分继承上下文与空上下文启动（空上下文启动会重建 cache），且 subAgent 执行超过 5min 时主 Agent 也会发生一次 miss；跨轮对话中 5min 内快速追问的关键是消息恢复机制（压缩/微压缩下保持一致），5min 后必然 miss，可借机微压缩删除不重要的工具结果（如 read）。由此得出的反直觉结论：cache 命中率低可能与上下文工程无关——会话周期长、用户隔很久才继续、模型窗口只有 200k 经常触发全量压缩都会拉低命中率；上下文工程与 cache 命中率是权衡（缓存冷却时清理不重要信息是好方案，埋点显示 read 工具占比很高）。配套要求是记录 llm trace：观测工作台详细记录每次 llm request 的输入输出与上下文组成（占用较大的上下文块、工具输出），否则"做了那么多上下文处理，连每次请求给 llm 的输入都不清楚，那就白做了"。

Skill 供给与云端工作区

Skill 体系按五类认知供给会场知识：内容认知（主题落到消费者问题与商品承接）、视觉认知（知道核心设计语言以及什么该保留、什么可以变）、供给认知（区分需求、选品规则与实际投放）、渲染认知（静态文案如何渲染、动态商品数据如何渲染）、验收认知（判断问题是什么以及应该回哪里改）。"一个好的 skill 需要说清楚表达的认知，也要有明确约束和验收条件"——内容为谁服务、商品从哪里来、设计保留什么、线上怎样渲染、结果凭什么过关。

云端业务 Agent 的工作区拆成两部分：持续保存工作材料的 OSS 虚拟文件系统，以及按需调用的执行能力。关键工程约束：①文件语义保留、持久状态放到 OSS——AI 通过 ls/read/write/copy/edit 操作工作材料，底层按 SID 映射到 OSS 路径，写入先落 OSS 再登记产物清单，会话释放不删除产物，工作进度不依附于某个运行进程；②通过文件收敛认知范围——page-data.json 提供 slotKey/aldSlotId/datasetId/cardCode 等映射，底层投放-选品复杂模型关系由业务工具处理，AI 不必每轮重建整套后端对象关系。

多 Agent 设计：SubAgent 的收益与协作成本

收益直接（把大段探索放进独立上下文、专业规则更聚焦、互不依赖任务并行），但协作成本必须计入——多轮会场编辑尤其容易遇到三个问题：①交回了结果，没交齐依据（选品子 Agent 只回"已创建选品集"，主 Agent 不知道哪些商品因价格被排除、哪些因敏感肌限制被排除；用户放宽预算后前者可重查、后者仍要保留。只有结论没有条件与可回读证据，下一轮就容易把做过的判断再猜一遍）；②追问交给谁要先知道谁掌握足够依据（"预算放到 300 元，刚才被排除的那几款能加吗？"——主 Agent 需先定位原任务、找到排除依据，再决定自己处理、恢复之前的子 Agent 还是补齐输入发起新任务；"选品专家"这个名字不能替系统完成交接）；③上下文各自独立，修改仍汇入同一份会场（设计侧按新确认改了卡片结构、绑定侧仍基于旧节点修改，两份局部结果合起来可能错绑或覆盖；继承上下文、保留会话、共享工作区都不能代替当前版本核对、明确写入范围与统一验收）。

按什么边界拆 Agent（三视角，可组合、非互斥）：①按职责拆——集中专业能力（策划/设计/前端各自配置规则与工具），边界清楚便于维护，但"换风格但保留这批商品"这类需求横跨多个职责，仍需有人掌握完整修改范围，且角色配置不等于必须长期保留执行实例；②按流程拆——分开决策与执行（Planner 规划、Executor 执行），但若只是同一个 Agent 内切换阶段则属流程划分，"不能仅凭两个名称就称为多 Agent"；③按任务拆——把委派边界落在一次可验收的工作上，主 Agent 保持业务主循环，专业能力仍由 Skill 与工具供给。

落地选择：主 Agent 持续负责用户对话与业务主循环，Skill 提供做事方法，Task 工具提供委派与并行执行能力，子 Agent 围绕一次明确任务工作、结束后交回结果。两个委托场景——输入输出说得清才交出去（互联网内容挖掘可交代主题/人群/研究问题并要求返回内容角度与证据；选品集创建可交代类目/价格带/筛选要求并要求返回 ID 与实际规则），独立任务通过并行加速（策划结构明确后，洁面、修护、防晒分别创建选品集，各自在局部上下文查询指标、预览样本后并行交回）。应对信息损失的机制是交接用"结论＋执行记录地址"：子任务结束后执行记录记到工作区、Task 返回结论并附上已归档执行记录的路径，结论进入主循环、过程保留为可重读依据，后续追问可读记录核对当前产物再决定自己调整或发起新任务。

自迭代环境：质检与观测

质检的一个前提与两个基本要求：前提是不能阻碍 AI 在视觉设计、商品运营上的创造力；要求是确定性高（保证交付确定）与检测速度快（耗时短才能成为基础工具，随处编辑后随处调用验证）。作者给出的设计哲学是"若为减少错误把生成限制成几套模板，设计的创造力也会一并消失"——把可验证的不确定性收进质检反馈，而不是收紧生成空间。三类确定性检查：①先判布局条件（掉坑检查先确认共同父容器，区分显式缺格与末行不满；卡宽一致性要求等宽轨道、无跨列）；②旋转看正确尺寸（倾斜卡片用变换前 offsetWidth 判断原始卡宽，避免把拍立得倾斜当成不齐）；③遮挡看实际绘制（3×3 采样 + elementsFromPoint 检查层叠，外部浮层可能是贴纸，作 warning 交截图复核）。边界原则：允许设计 ≠ 豁免重叠——商品卡超阈值重叠仍报 error；Bento、旋转、横向滚动等合法反例需持续回归，否则模型会被错误规则逼成同一版式。

观测的五层视角：状态里的消息还会经过 Skill、工具可见性、多模态与缓存处理，因此必须在 Provider 出口记录 SDK 最终发送的请求与实际收到的响应，才能确认规则是否加载、图片是否进入请求、字段是否可见、工具结果以什么形式进入模型上下文。观察可从 Session 下钻到用户 Turn，再看主/子 Agent 的请求与工具步骤（Turn 看用户诉求与执行结果、请求看模型实际输入输出、工具步骤看业务动作；Task 委派通过父子运行标识关联，ReAct 循环由请求与工具序列还原）。另建业务打标体系：对用户对话做 llm 打标并持续更新打标服务，从对话中分析数据。

未来规划与边界

会场域认知目前只跑通当前业务的核心知识，不同业务的数据投放与盘货诉求不同，需要二三方开放能力建设；工作环境方面会场设计对视觉与货品的调整常有几十甚至上百轮，长程高频任务中如何不丢上下文、同时保持视觉创造力与货品运营灵活度仍需探索；自迭代环境已初步建立 AI 观测工作台，但仍缺 Task 维度分析与 Turn 维度深度分析，以及更自动化地反哺核心 Agent 迭代。

与相关实体的关系

  • 与 淘天小游戏自迭代 Agent 同属淘天营销&交易技术团队的第一方 Agent 工程：小游戏是"生产-运营-迭代"全链路闭环、以 AB 实验与门禁为准绳；本文是单场景（会场生成）内把 Harness 拆成认知环境/工作环境/自迭代环境的深度实现，含 page.html 多链路解释与 prompt cache 工程细节。
  • 与 策略效果类 Agent 评测体系、Price360 知识库 Harness 互补：三者分别是"评测侧""知识侧""生成侧"，共同构成淘天团队对 Agent 工程化的完整拼图。
  • 与 Agent Harness 演化论 的六层演化路径呼应，本文可视为其中"完整 Harness"在电商会场生成这一垂直场景的生产级实例，并给出上下文分层 P0-P3 与 SubAgent 协作成本的量化反思。
  • 质检思路（确定性检查 vs 创造力的张力、合法反例回归）与 评测 Harness 设计 的评测哲学同源，但本文落在页面产物（DOM/布局/遮挡）的实时可复现检查上。

→ 原文存档