告别 AI Demo 页面：构建支持淘内货品运营、可C端投放的会场 Agent Harness

方舟会场 Agent 的生成，我们期望至少有以下几个特点：

1. 内容实时策划：基于人群/场景/热点的互联网内容深度挖掘以及策划。

2. 淘天设计水准：沉淀淘系会场设计经验，生成高颜值的精修会场

3. 真实货品运营：可以在会场中对淘内商品进行圈选，以及进行投放

4. C端线上投放：生成符合生产环境要求的会场，可以投放淘内或端外。

下面是 Agent 产品的一些界面：

1. 内容与供给产出：策划 Skill 多轮挖掘人群/场景切口，核验类目与供给，产出《会场策划.md》与选品集 ID，交用户确认。

2. 设计与数据分别准备：版头与风格遵循视觉 Skill，保留视觉基准；数据阶段建立数据插槽、投放与召回关系。内容、视觉与真实供给最终在同一份 page.html 中装配。

3. 构建页面并交付：构建阶段把数据接到真实卡片生成 page.html，检查后保存版本，进入生码/审批/发布。

4. 主 Agent 贯穿链路：确认、委派、验收、二次编辑都由它承接；业务阶段不等于七个长期 Agent，独立子任务才适合并行。

Harness 的价值是把“会场怎么做”变成模型可理解、可操作、可检查的工作环境。常规的 Agent 架构图相信大家已经看腻了，可能翻来覆去就是那些 skill、tool、subAgent 之类的，基础的 agent 构建确实如此，而且成本已经很低了。

所以在方舟 AI 中，我们想着重表达的以下三类环境的构建：

1. 会场域认知环境：视觉认知解释会场的设计语言，数据认知解释供给归属，生码认知理解数据协议；核心通过 Skill 渐进式加载。

2. 业务 Agent 的工作环境：通用的 Agent 环境暂且不讲，在方舟 Agent 的执行过程中，如何建设工作区与操作环境？会场域认知知识怎么来？业务工具怎么来？如何通过 subAgent 降低耗时以及隔离上下文？上下文工程需要怎么优化？

3. Agent 的自迭代环境：我们希望设计阶段，在设计语言规范下能够最大程度的发挥视觉的创造力，在动态数据协议下最大程度的灵活调整货品，但是如何保障交付的确定性？以及如何监控观测运行过程，使其优化迭代我们的 Agent？

会场生成的第一步，是根据用户诉求进行会场的策划以及货品供给的生成，这块有单独的文章进行展开，这里不再赘述了。

▐  最重要的产物：承载丰富业务语义的html

• 一份 HTML，承载着三项约束

html只是底层的协议，让AI随便生成一张好看的html是比较容易的，但如果希望他可用、可运营、可投放，那还有很多事情和约束需要去做。

1. 视觉设计是软约束：visual-design 与风格 Skill 守住气质、视觉层级和关键特征，相框、字体、层叠、留白仍可组合——让模型把设计做好，而不是照模板填空。

2. 货品数据是认知约束：page-data 建立选品、Slot 与召回认知，字段协议规定内容如何进入页面；AI 要分清哪些内容随页面保留、哪些来自商品字段。

3. 生码是硬约束：page-build 与 Ark 协议规定 Section、卡片、字段的表达与装配边界；外观自由，节点归属、字段位置、动态组件输入必须明确。

• page.html：AI设计的冲突中心

同一棵 DOM 同时承载布局、供给、字段绑定与转码要求。这些关系可以对应，却不能强行合并成同一层级；局部修改可能改变另一环节赖以成立的前提。

• 在多维认知下进行二次编辑

同一张页面上的修改，可能改变呈现、货品供给，也可能改变某个坑位的数据投放。AI 先识别诉求与影响范围，再从 Skill 库的入口索引主动选择能力、按需加载正文，并沿规范补读参考文件。三个方向分别修改，混合诉求按依赖顺序处理，最终回到同一份页面校验。

▐  如何保证视觉达到淘天设计水准？

我们和设计师合作，设计师针对淘内的内容型会场产出了 30+ Design Skill，把会场设计语言变成 AI 可理解的 skill，情绪、材质、排版、组件结构、色彩角色和禁用规则。并根据实际策划和货品进行自适应调整和创作。

例如“海报拍立得”保留倾斜黑板、摆正面板和粗描边；LOOKBOOK 强调扁平、无投影和编辑式排版。

• 保证视觉风格的效果与遵循度

▐  AI 如何在 HTML 上运营真实商品？

我们会场的商品数据并不是 html 中的一个 div，底层是一套数据运营和在线链路渲染的逻辑，需要让 AI 理解链路 才能正确修改。

1. html的整体结构：

1. 通过 page-build 协议定位 Section、商品卡与字段节点；卡内标题/价格/图片是动态字段，楼层名可能是静态文案。

2. data-ark-index="0" 只是组内位置，不代表固定商品；固定主推回到选品与投放规则，改字号留在展示层。

2. 会场数据的核心业务供给：

1. 通过skill让AI清楚楼层、商品区、数据插槽、选品集、商品 等实体模型之间的关系。

2. 从 data-ark-slot 找到 page-data.json 映射，关联真实 Slot、投放与选品集；selection-dataset 说明 ID、类目、价格带如何变成候选。

• 一句货品运营诉求，AI 怎样推导出数据方案？

举一个例子，用户提问 “第一个坑位固定主推 A，紧接两位只放修护类，其余继续个性化，布局不动”

这个对话中，没提选品集与数据，但AI需要了解页面样式、商品坑排版、货品圈选范围、推荐方式与编辑修改的边界。

1. 定位现状：“第一坑”是位置不是商品 ID，在楼层商品区中理解动态商品数据渲染逻辑。

2. 用 Skill 建立准绳：selection-dataset 说清有效选品条件；page-data 说数据插槽的共享规则、独立商品区运营要独立投放单元。

3. 落实为数据方案：A 用商品 ID 条件建独立选品集与 pin Slot；修护区建 repair Slot；其余保留原 recommend。

4. 先核验供给再执行：候选不足要暴露，不能写静态卡片掩盖。

5. 落到卡片并验收：主推位绑 pin/0，修护区绑 repair/0、1，其余继续引用原组；检查四个要求同时成立。

通过方舟Agent搭建的会场，可以和普通方舟会场一样，支持发布并投放手淘或端外，甚至也支持直接添加现有的天马模块。

会场前期设计产出的html只是一份承载了业务语义（视觉设计和货品数据）的协议HTML，实际生产环境的会场页面还有很多事情要做，比如性能要求、埋点、各种屏幕适配等等，这部分也有单独的文章展开。

这部分是通用的AI Agent Harness建设的内容，内外网已经有很多最佳实践，这里就不过多赘述了，只选取几点实际落地比较有印象的点展开讨论。

▐  实际业务中理解上下文与cache

我们根据我们实际的上下文进行了一轮分析，根据其重要性排序

• P0：核心约束和执行事实，比如系统提示词、用户目标等

• P1：已加载的关键Skill，比如设计风格、页面协议

• P2：当前判断所需的信息结果，比如当前html、当前截图

• P3：已过时、可重取的信息结果，比如read工具结果、早期截图、会场信息等

对于重要性很高的上下文 比如Skill 要注意在全量压缩的时候进行显示的恢复。

对于重要性很低的上下文（比如read工具结果、截图工具结果等）在合适的时机将其清除，合适的时机 比如 缓存冷却的时候。

• prompt cache 在实际业务中并不简单

在没有实际做agent业务项目之前，我对prompt cache的理解基本只在两点：保持前缀一致、默认缓存5min。

但实际上这两点，在agent loop、多agent架构的场景下 其实衍生出了很多种情况，每种情况的场景和解决优化的思路也各不相同。

上下文工程和 cache 命中率其实是一种权衡，我们既不能完全忽略 prompt cache（真的很省钱），但也不能一味的追求 cache 命中率，上下文中塞入过多无用的信息。当缓存冷却时（超过 5min），将一些不重要的信息清理 是一个很好的方案。

比如从上下文的埋点分析来看，read 工具占比还是非常高的。

在实践过程中，记录 llm trace 是极其重要的。我们做了那么多上下文的处理，如果连每次请求给 llm 的输入都不清楚，那就白做了。

在我们的观测工作台，我们详细记录了每次 llm request 的输入输出，也辅助我们看到 llm 如何决策。

同时，我们也详细记录了每次 trace 的上下文组成，一些占用比较大的上下文块、工具输出等，辅助针对上下文进行下钻分析。

为了支撑上述 AI 的会场域认知，我们有大量的 skill 体系，这些 skill 相互配合，提供了大量会场知识认知，也提供了流程、协议、约束、产物等。一个好的 skill 需要说清楚表达的认知，也要有明确约束和验收条件。

内容为谁服务、商品从哪里来、设计保留什么、线上怎样渲染，以及结果凭什么过关。

下面按知识领域展开；一个请求可以同时调用多个领域，同一份 Skill 也可以兼具认知、流程、协议和验收规则。

• 内容认知：把主题落到消费者问题与商品承接。

• 视觉认知：知道核心的设计语言，以及什么该保留、什么可以变。

• 供给认知：区分需求、选品规则和实际投放。

• 渲染认知：静态文案如何渲染，动态商品数据如何渲染

• 验收认知：判断问题是什么，以及应该回哪里改。

会场 Agent 的工作环境，要承接业务认知、页面产物和业务系统工具。我们把它拆成两部分：持续保存工作材料的 OSS 虚拟文件系统，以及按需调用的执行能力。工作区不仅存文件，还把复杂业务收敛成 AI 能阅读、能交接的任务材料。

1. 文件语义保留，持久状态放到 OSS。 AI 通过 ls/read/write/copy/edit 操作工作材料，底层按 SID 映射到 OSS 路径。写入先落 OSS，再登记产物清单。会话释放不删除这些产物，后续执行可以继续读取，工作进度不依附于某个运行进程。

1. 通过文件收敛认知范围，只保留必要业务语义。 AI 需要理解“修护区用哪套选品、主推卡绑定哪个数据插槽”。page-data.json 提供 slotKey / aldSlotId / datasetId / cardCode 等映射；底层投放-选品的复杂模型关系由业务工具处理。AI 仍要懂投放逻辑，但不用在每轮对话里重建整套后端对象关系。

同时，我们也可以在观测工作台观测工作区的产物。

• SubAgent的思考与优劣

SubAgent 的收益很直接：把大段探索放进独立上下文，让专业规则更聚焦，让互不依赖的任务并行。但会场业务会连续修改同一份页面，一轮任务做完之后，还要让下一轮对话沿着同一套用户确认和业务事实继续。先把几个容易混在一起的维度分开。

3. 如何应对信息损失：交接用“结论＋执行记录地址”，后续对话沿文件继续。

1. 子任务结束后，执行记录记到工作区，Task 返回结论，并附上已归档执行记录的路径；结论进入主循环，过程保留为可重读的依据。

2. 用户再问“这批修护商品为什么被选进来，价格再降一点”，主 Agent 可以读取记录、核对当前产物，再决定自己调整或发起新任务。结论进入主循环，过程保留为可重读的依据。

• 为什么重要？质检工具的三层设计

我们希望 AI 在设计阶段足够的灵活，包含了视觉效果的最大化、数据编辑的灵活性，但是在交付角度，质量必须过关。所以对质检工具提出了一个前提 两个基本要求：

• 一个前提：不能阻碍AI在视觉设计、商品运营上的创造力

• 两个基本要求：

  确定性高：这样保证交付的确定

  检测速度快：耗时短才能成为基础工具，随处编辑后随处调用验证。

若为减少错误把生成限制成几套模板，设计的创造里也会一并消失。我们希望模型尽量发挥 HTML/CSS 表达力，把可验证的不确定性收进质检反馈。

• 用确定性检测来判断不确定的难点

质检工具的实现并不如想象中的那么简单，本质上是 视觉设计的泛化性 与 确定性质量交付 二者之间的冲突。如果一味追求检测，追求确定性，会让 AI 失去创造力，下面举一个例子。

质检在实际的实践中，琐碎的问题比较多：

1. 先判布局条件：掉坑检查先确认共同父容器，区分显式缺格与末行不满；卡宽一致性要求等宽轨道、无跨列。

2. 旋转看正确尺寸：倾斜卡片用变换前 offsetWidth 判断原始卡宽，避免把拍立得倾斜当不齐。

3. 遮挡看实际绘制：3×3 采样 + elementsFromPoint 检查层叠；外部浮层可能是贴纸，作 warning 交截图复核。

允许设计 ≠ 豁免重叠：商品卡超阈值重叠仍报 error；Bento、旋转、横向滚动等合法反例需持续回归，否则模型会被错误规则逼成同一版式。

• 解构一个session的五层观测视角

状态里的消息还会经过 Skill、工具可见性、多模态与缓存处理。Provider 出口记录 SDK 最终发送的请求和实际收到的响应，才能确认规则是否加载、图片是否进入请求、字段是否可见、工具结果以什么形式进入模型上下文。

观察可以从 Session 下钻到用户 Turn，再看主/子 Agent 的请求与工具步骤：Turn 看用户诉求与执行结果，请求看模型实际输入输出，工具步骤看业务动作。Task 委派通过父子运行标识关联，ReAct 循环由请求和工具序列还原。

我们对用户的对话进行llm打标，并不断更新打标服务，从用户对话中分析数据。

• Agent的会场域认知：目前这块还只是跑通当前业务的核心知识，在已有的需求中，有越来越多的业务接入，不同业务的数据投放诉求不同、不同业务的盘货诉求也不同，这些也需要一定的二三方开放能力建设。

• Agent的工作环境：在实际的会场设计业务场景中，对视觉、对货品的调整非常多，有几十轮甚至上百轮，在如此高频的长程任务中，如何做到上下文不丢失，保持AI的视觉创造力、货品运营灵活度，是需要持续探索的。

• Agent的自迭代环境：目前已经初步建立起AI观测工作台，但依然缺少Task维度的分析、Turn维度的深度分析，以及更加自动化的反哺到核心Agent的迭代中，仍需要不停设计。