Agent 进入生产环境后，随着用户量增长，线上 badcase 也会持续增加。蚂蚁阿福上线后同样面临这一问题。从 badcase 的发现、归因和分派，到修复、验证和结果回流，各环节都需要工程师人工衔接。即使有 AI 辅助，处理能力仍不足以应对持续新增的问题。为此，我们分两个阶段推进：先用 Harness Engineering 解决“如何可靠修好 badcase”，再用 Loop Engineering 解决“如何持续修复 badcase”。

第一个问题是：如何减少人工参与，让 Agent 自主完成 badcase 的修复和验证？我们为 Agent 接入开发、部署和评测工具，通过执行约束保障长任务持续运行，再通过评测约束判断问题是否真正修好。在一次真实任务中，Agent 连续迭代 16 轮，改动最终经人工复核后上线。

当修复和验证能够稳定运行后，新的瓶颈随之出现：发现、归因、分派和结果回流仍依赖人工。如何把这些环节也交给 Agent，不再由工程师逐条发起 badcase 修复任务？我们将完整流程组织成两个相互衔接的循环（Loop）：内循环负责修复和验证，外循环负责发现、归因、分派和结果回流。两个循环衔接后，系统可以持续处理 badcase；异常改派和最终上线仍由人把关。

本次分享将结合真实案例，展示 badcase 如何入池、分派、修复和验证，并说明当前哪些环节仍需人工决策。

演讲提纲

1. 业务背景与 badcase 处理现状

• badcase 持续进入，工程师需要逐条分析、修改、部署和评测，现有处理能力难以覆盖不断新增的问题
• 一个 badcase 从发现、归因、分派到修复、验证和关闭，需要多名工程师在不同环节手工交接
• 两阶段改造思路：先让 Agent 自己完成修复和验证，再让 Agent 持续接收和处理新问题

2. Harness 设计与单 Agent 自主迭代

• 工具接入：把开发、部署、发起评测和获取结果变成 Agent 可以直接调用的工具
• 长任务运行：解决任务提前结束、重复空转和上下文不足等问题；主 Agent 负责目标管理，子 Agent 执行每轮分析和修改
• 避免只优化评测分数：隔离开发数据与验证数据，并在每轮修改后重新与当前基线对比
• 实践结果：Agent 连续迭代 16 轮，改动经人工复核后上线

3. Loop 架构与内外循环协作

• 修复效率提升后，问题发现、归因、分派和结果回收仍依赖人工，成为新的瓶颈
• 外循环 Agent 小队负责接收问题、分派任务，并根据处理结果决定后续流向；内循环 Agent 小队负责诊断、修改和验证
• 两组 Agent 共用 Harness 提供的工具、状态记录、执行约束和评测

4. Agent 小队任务处理与验证流程

• 接收与分派：先对一批 badcase 去重、归类和初步归因，再按问题归属创建任务
• 诊断与修改：根据证据定位问题所在层级，确认修改范围后，审查方案并实施修改
• 独立验证：验证者不参与修改，独立确认目标问题是否解决，并检查是否对其他问题造成影响
• 失败后改派：当前小队无法处理时，将判断结果和证据返回外循环，经人工确认后重新分派

5. 落地效果与实践经验

• 明确当前可由 Agent 处理的 badcase 类型，以及仍需人工介入的问题
• 工程师不再逐项执行重复操作，但仍负责制定约束、抽样复核、异常决策和最终确认
• 从自动化评测开始，先让一个边界清晰、结果可验证的小型 Harness 稳定运行，再通过定时任务驱动 Loop 持续处理问题

实践痛点

• 如何让 Agent 在长时间、多轮执行中保持稳定，避免早停
• 如何判断 Agent 是否真正解决了问题，而不是只提高了评测分数
• 如何保证多 Agent 之间的任务、状态和证据能够可靠交接，并划清自动执行与人工决策的边界

演讲亮点

• 以线上 badcase 处理为真实案例，复盘从 Harness 到 Loop 的两阶段演进：先用 Harness 支撑 Agent 稳定完成修复和验证，再由两支 Agent 小队共用这套 Harness，持续接收、分派和处理新问题
• 不只展示成功结果，也通过失败案例说明评测、独立验证和证据回流在闭环中为何缺一不可
• 不追求“全自动化”，而是明确 Agent 自动执行与人工决策、复核和最终责任之间的边界

听众收益

• 判断自己的场景处于哪个阶段：应先建设 Agent Harness，还是需要引入 Loop 处理持续问题
• 掌握一套判断 Agent 是否真正形成闭环的检查方法：能否持续执行、是否经过独立验证、失败后是否有明确的后续处理流程
• 获得一条明确的实施路径：从自动化评测和边界清晰、结果可验证的小型 Harness 开始，逐步扩大 Agent 的自主范围，同时保留人工决策与最终责任

电商导购并非简单的问答或商品检索，而是一个横跨导购决策、搜索推荐、营销优惠、商品信息、交易履约与售后服务等多个业务域的复杂 Agent 场景。我们基于Agent Loop范式构建生产级导购助手，通过统一 Tool 协议、动态上下文管理、任务规划与多域工具编排，让模型能够理解用户隐含需求，并在复杂链路中完成信息查询、商品筛选、优惠计算与服务决策。实践中重点解决了工具数量膨胀、跨域信息冲突、链路超时、错误传播及模型与 Harness 问题难以区分等挑战，并通过轨迹观测、评测回归和策略治理持续优化效果。实践表明，复杂业务 Agent 落地的关键，不只是模型能力，而是构建一套可编排、可观测、可评测、可持续迭代的 Harness 工程体系。

演讲提纲

1. 问题背景：复杂导购 Agent 为什么不能只靠一次性优化

• 电商导购不是简单问答，而是跨搜索推荐、商品信息、营销优惠、交易履约和售后服务等多个业务域的复杂决策过程。Agent 需要在动态上下文中完成意图理解、任务规划、工具选择和结果整合，任何一个环节发生偏差，都可能导致最终任务失败
• 固定 Workflow 难以覆盖开放式需求，而完全依赖模型自主决策，又容易出现工具误用、参数错误、重复调用和链路失控。因此，复杂业务 Agent 的核心问题逐渐从“如何把链路跑起来”，转向“如何基于真实线上反馈持续变好”

2. 基础建设：让每一次线上执行都可观测、可回放

• 围绕生产级 Agent Harness，建设统一的 Tool 协议、Context/Memory 管理、任务执行控制和全链路 Trajectory 体系
• 重点记录用户输入、上下文组装、规划过程、工具选择、调用参数、工具结果、异常重试和最终输出，并关联模型、Prompt、Tool、配置和知识版本，使线上问题能够被完整还原，为后续归因和优化提供可靠依据

3. 线上轨迹：从海量执行中识别真正的问题

• 将线上执行轨迹、用户反馈、工具异常和业务效果统一采集，结合规则、指标和模型判断发现潜在 Bad Case
• 不仅关注最终答案是否正确，还关注任务是否完成、工具调用是否合理、链路是否冗余、成本与时延是否异常，以及结果是否真正满足用户需求。通过一个典型导购案例，展示 Agent 如何在商品搜索、优惠查询、库存履约和售后判断过程中暴露问题

4. Bad Case 归因：判断问题到底出在哪里

建立面向 Agent 全链路的失败归因体系，将问题拆解为：

• 任务理解与规划错误
• Tool 选择或参数生成错误
• Context 组织与 Memory 召回错误
• 工具执行、超时与异常恢复问题
• 模型推理与约束遵循问题
• 多业务域协同和结果整合问题

结合轨迹回放、同类案例聚类、模型对比和局部重放，判断问题应该通过模型能力、Prompt、Tool、Context/Memory，还是 Runtime 机制进行修复，避免针对单个 Case 不断堆叠规则。

5. 策略变更：从失败原因生成可执行的优化方案

根据归因结果，将优化策略作用到不同层次：

• 调整 Prompt、任务拆解和执行策略
• 优化 Tool 描述、参数 Schema、动态注入和调用策略
• 调整 Context 组装、Token Budget 和 Memory 检索策略
• 增加参数校验、结果校验、重试、降级和人工接管机制
• 必要时调整模型选型、路由策略或进入训练优化

通过版本化管理记录每次策略变更，确保优化对象、适用范围和预期收益清晰可追踪。

6. 回归评测：证明优化不是只修复了一个 Case

• 将典型 Bad Case 和同类问题沉淀为场景化回归集，分别评估单点能力、执行轨迹、任务成功率及业务指标
• 采用新旧版本对照、同一 Case 多次运行和跨场景退化检查，综合评估任务成功率、工具调用准确率、执行步骤、时延和 Token 成本，防止策略只对少量样本有效，或在修复一个问题的同时引入新的退化

7. 灰度上线：让每次变更安全进入真实业务

• 通过小流量灰度、版本隔离和 Champion-Challenger 机制，将通过离线回归的策略逐步放入真实流量
• 持续观察任务成功率、用户反馈、业务转化、链路异常和资源成本；达到预期后逐步放量，出现异常则快速回滚，并将新的线上问题再次进入轨迹采集和归因流程
• 最终形成：线上轨迹 → Bad Case 归因 → 策略变更 → 回归评测 → 灰度上线 → 新轨迹回流

8. 实施效果与核心结论

• 通过这套闭环，导购 Agent 的问题定位从依赖人工排查转向轨迹驱动，效果优化从零散 Case 修复转向体系化迭代，链路稳定性、问题定位效率和版本迭代效率均得到明显提升。

实践痛点

• 在实践中，最大的痛点是复杂业务 Agent 很难同时做到高自主性、高稳定性和低成本。Tool 越多，模型可解决的问题越广，但工具选择、参数生成和跨域结果冲突的概率也会增加；对模型施加更多规则、校验和固定流程，可以提升可控性，却会限制其应对开放式需求的能力
• 其次，长链路任务往往需要多轮推理和多次工具调用，效果提升通常伴随着时延和计算成本上升。为了保证用户体验，必须在信息完整度、执行轮次和响应速度之间做取舍。过早终止可能导致结果不充分，而过度搜索和重试又容易造成无效消耗
• 自进化也并非完全自动化。线上 Badcase 的失败原因常常是模型、工具、数据、上下文和业务规则共同作用的结果，自动归因可能产生错误优化，甚至在修复某类问题时引入新的回归。因此，策略调整仍需要经过离线评测、人工审核和灰度验证

演讲亮点

• 复杂跨域 Tool 的生产级编排：区别于简单问答或单工具调用，本次实践覆盖搜索推荐、商品、营销、履约和售后等多个业务域，通过动态 Tool 注入、参数校验、结果压缩和执行治理，解决复杂链路中的工具选择、数据冲突与稳定性问题
• 基于执行轨迹的 Agent 自进化：区别于依赖人工分析 Badcase 和单点调整 ，我们将线上轨迹、评测结果与用户反馈统一采集，对规划、工具、上下文和模型问题进行归因，并形成“问题发现—策略优化—回归评测—灰度验证”的持续进化闭环

听众收益

• 理解电商导购这类复杂 Agent 场景中，如何在搜索推荐、商品、营销、履约和售后等多域之间通过 Subagent、Skill/Tool 注入完成体系化的 Agent 搭建
• 掌握生产级 Agent 落地中的实践踩坑
• 了解如何基于线上 Badcase、执行轨迹和评测结果，建立从失败归因到策略优化、回归验证和灰度上线的自进化闭环，减少重复试错

DeepSwarm 是小红书技术风险团队构建的通用 RCA Agent 平台，面向容量、变更、异常等场景的故障根因分析，目前以容量根因分析作为首个规模化生产场景。

在运维场景里，Agent Harness 的设计需要兼顾可核对、人机协同与时效性：结论要有证据支撑，不确定时敢说“我不知道”；Agent 能自主调查，也支持人随时核验、补充信息和纠正方向；考虑到值班同学通常只能等待几十秒，需要尽早给出可用判断。这些要求共同影响了 Harness 的设计取舍：如何提高诊断可靠性、减少无效探索，并在有限时间内交付有依据的结果。

分享将展开可观测上下文工程、基于 Session Tree 的诊断过程管理，以及时效性约束下的执行与交付设计：如何将原始观测数据加工成可用证据，如何先建立公共事实、再通过多个分支验证根因假设，如何将固定排查流程封装为工具，并控制上下文规模与结果交接成本。最后结合多维评测、容量场景的验证反馈和真实翻车案例，复盘生产实践中的踩坑，以及何时需要人工核验与介入。

演讲提纲

1. 运维场景下 Agent 的三个设计目标

• 结论可核对、过程可协同、结果及时交付——这三个目标如何影响 Harness 的设计取舍
• 为什么选择容量根因分析作为首个规模化生产场景
• DeepSwarm 架构概览：数据与领域工具、诊断 Harness、交互与结果交付

2. 可观测上下文工程：把原始信号加工成可用证据

• 上下文质量决定诊断型 Agent 的结论上限
• metric / log / trace / change 的上下文加工思路与关键取舍
• 对齐异常时间窗、聚合重复信息、保留关键差异、标明数据缺口

3. Session Tree：让诊断过程可追溯，支持多分支探索与人工介入

• 线性会话的局限：不同调查方向容易相互干扰，纠偏与继续调查需要保留原有路径完整保留调查历史，按需构建模型上下文：共享已有事实，隔离各分支的调查过程
• 控制分支交接的信息量：各分支向主分支返回简洁结论、关键证据引用和未决问题，完整过程保留在分支中，支持按需核验
• 支持人工介入：通过历史预览、回退与 Fork，从指定位置纠正方向、继续调查

4. 时效性约束下的执行与交付：两段式下钻与假设验证

• 第一阶段：问题定界，建立公共事实——明确异常时间窗、影响范围、关键变化与数据缺口，减少重复调查
• 第二阶段：提出假设，按需多分支深挖——基于公共事实形成候选根因，依托 Session Tree 寻找支持证据与反证
• 执行分工：固定排查交给工具，动态判断交给 Agent——将成熟排查步骤封装为领域工具，减少重复规划与多轮调用；Agent 负责选择验证路径、综合证据与调整调查方向，每类 Agent 只提供必要的工具与技能
• 控制执行成本，明确停止条件——控制分支数量、调查深度和交接成本，根据证据充分性与时间预算收敛，保留未决假设与后续核验方向
• 及时交付可用结果——区分调查进展、已确认事实与初步判断；明确判断依据和未决问题，生成可核对的诊断报告及结构化结果

5. 多维评测闭环：从一次翻车到系统改进

• 如何判断诊断真的变好：围绕结论准确性、证据充分性与时效性，结合自动评测和 SRE 盲评
• 一次真实翻车复盘：还原错误结论如何产生，明确 Agent 的能力边界与人工介入点
• 让教训持续生效：将 Bad Case 纳入回归评测，并据此调整输出约束、验证步骤和停止条件

6. 容量场景的生产验证与展望

• 上线规模与覆盖：接入的核心服务数、覆盖的容量告警比例
• 效果数据：SRE 采纳率、首次可用判断耗时、完整诊断耗时，以及诊断错误率与典型错误类型
• 当前能力边界：哪些问题能够独立完成诊断，哪些仍需人工补充证据和判断
• 展望：积累服务与场景知识、探索诊断到处置的闭环，以及从容量向更多 RCA 场景扩展

实践痛点

• 上下文加工的信息取舍：压得太狠会丢失关键信号，压得太松会增加上下文负担；不同数据源需要针对性加工
• 固定流程与动态判断的分工：封装不足会导致重复规划和调用，封装过度会限制对现场变化的适应能力；需要明确工具的适用条件与输出边界
• 多分支的收益与交接成本：并行不一定更快，重复查询、启动等待和结果摘要都可能抵消收益；精简交接内容时，需要保留关键证据引用，支持按需回查与核验
• 时效性与完备性：及时的初步判断更有实用价值，但何时停止调查、如何表达未决问题，需要结合真实反馈持续迭代
• 评测体系的运营成本：基准集维护，以及更具挑战性的测试案例构造，都需要 SRE 持续投入

演讲亮点

1. 可观测上下文工程：把原始数据加工成可靠的诊断依据

• 从容量 RCA 实践出发，展示 metric / log / trace / change 如何被加工为可供诊断的结构化证据。通过加工前后的具体对比，解释时间对齐、关键差异保留和数据缺口表达如何影响最终判断，分享信息压缩与证据完整性之间的工程取舍

2. Session Tree：让诊断过程可追溯，支持多分支探索与人工介入

• 完整保留调查历史，按需构建模型上下文。各分支共享已有事实、独立开展调查，通过简洁结论与证据引用完成结果交接，支持按需回查。结合历史预览、回退与 Fork，让人工核验、纠偏和继续调查成为 Harness 的原生能力

3. 时效性驱动的执行：用工具完成固定排查，用多分支验证根因假设

• 以两段式下钻组织诊断：先定界、建立公共事实，再提出假设、按需多分支验证。将成熟排查流程封装为领域工具，减少重复规划与调用，结合时间预算和证据充分性明确停止条件，在时效约束下交付可核对的诊断结果

听众收益

• 建立诊断型 Agent 的设计视角：从可核对、人机协同与时效性出发，识别自身场景的边界约束，选择匹配的 Harness 机制
• 掌握可观测上下文加工思路：理解如何将原始指标、日志、调用链和变更记录提炼为可用证据，保留关键差异并表达数据缺口
• 获得可借鉴的诊断执行方法：理解公共事实、候选假设、分支验证与结果交接如何配合，判断哪些流程值得封装为工具、哪些决策需要动态判断，以及何时并行、何时停止
• 理解人机协同与持续改进如何落地：通过可追溯的调查过程支持人工核验与纠偏，将真实失败转化为输出约束、回归案例和执行策略的改进

多 Agent 把一局网页游戏跑起来并不难。个人练习里，Demo 能进、能打、能结束。难的是把它接进团队：组织认知要转，成本要能评估，边界要去探。

游戏研发里做 Agentic，常见情况是：

• 能跑通 — Harness 能调工具，Demo 能玩，下一步不知道干什么
• 接不进 — 个人练习停在自己这，组织不知道这东西算不算数、要花多少、能碰到哪
• 验不了 — 对错靠聊天里模型自评，没有「这一次过了」
• 用不起 — 工作台在，日常还是开新聊天，loop 转不起来

我们的实践：Harness 叙事的是接入更多插件，Loop 是为目标不断做减法。先用 Loop Harness 让策划自己把需求拆开、做出来、自动验收，但策划的注意力不该放在质量上，研发不能甩手。再在研发侧把 Build Loop 做成 Build Control：人先在 loop 里拍板，再把人往外抽；一开始目标切错，后面迭代越快越不值得信。工作台基于 DeepSeek Harness。本次分享讲 Demo 之后，Loop 怎么接进团队。

演讲提纲

1. 背景：Demo 能跑，接不进团队

• 个人练习：网页游戏 Demo 里的多 Agent 协作
• 协作不是瓶颈；后面会在多模态、引擎适配的多个阶段撞墙
• Harness 叙事的是接入更多插件，Loop 是为目标不断做减法
• 真正难的是接进团队：认知转型、评估成本、探索边界
• 痛点：Loop 接进团队时，认知、成本、边界怎么评估

2. 实践：Loop Harness 让策划自己开发需求

• 帮策划做三件事：需求拆解、实现、自动化验收——需求能自己切开、能做出一版、过线不靠口头说
• 策划的注意力不应放在质量。质量是研发的职责，Loop Harness 不是把测试、过线、背锅转交给策划
• 所以研发不能甩手：策划在 loop 里出需求、出实现；研发守验收、守质量、守「这次能不能过」
• Loop Harness 做减法：只留给策划「这个需求要什么」，不把插件、模型、质量面板堆到策划面前
• 痛点：如何把拆解、实现、自动验收交给策划，又不把质量注意力压过去、不让研发甩手

3. 实践：研发实践中的 Loop Engineering

• Build Loop 就是 Build Control。Human in the loop 到 Human out of the loop 不是切换开关，是信任建设：人先对每一次构建拍板，Agent 跑；人少碰，是因为验收还在，不是因为人不管了
• 人还在的时候，拍板权在人；人往外抽，权要留在 loop 的验收上，不能留在模型自评里
• 一开始 loop 的目标错了（Spec 切偏、过线切错），后续迭代交不出信任：跑得越勤，错得越稳，人更不敢退出
• 先把目标按住，再谈人退出。目标不对就停、就改 Spec，不要用更多迭代去「跑出信心」
• 痛点：人怎么从 in the loop 退到 out of the loop，信任落在哪；目标一开始切错，为什么多跑几次也交不出信任

4. 实践：工作台，让 loop 有人愿意接着转

• 基于 DeepSeek Harness：上一个需求长出来的能力，下一个还能用；工作台可克隆
• 日历/待办：现在该验证哪一次构建
• 后台 tmux：构建是长任务，人离开 loop 还在转
• Git 任务列表：下一步从当前 Spec 来，不从聊天贴
• 授人以渔：愿意把日常控制放到这条 Build Loop 上，而不是每次重开 Demo
• 痛点：工作台如何避免变成第二个聊天窗（待办垃圾场、tmux 过多、Git 太吵）

实践痛点

认知门槛相对较高，很多人处在Chat、Vibe Coding的状态

前沿亮点

• 结合 DeepSeek Harness 定制化提效
• 需求级工作台，而不是又一个聊天 Agent：人改 Spec 和红节点，不改 prompt；验收是 Graph 节点变绿，失败可单点重跑。这是从 Harness 跨到 Loop 的接口，不是口号
• Spec 按 DDD 划界、编译成可并行 DAG：区别于手拖画布。多个需求已按此落地，拆成数十个可见节点并行；边上约束的是上游产物（接口/模型/Spec 片段），上游没齐下游不能绿
• DeepSeek Harness 的插件化 + 三个可复用演示：日历/待办、持久 tmux、Git 远端任务列表同等展开，每块都带真坑（垃圾场待办、会话过载、远端噪声）。证明 Loop 要接到「下一步从哪来、人看哪一路、能力如何复用到下一需求」
• 授人以渔有技术载体：成员在 Multica 里用 Harness 克隆领域 Agent，组织资产越用越厚，而不是平台组再发明一套通用机器人

听众收益

• 了解前沿 Loop Engineering 实践
• 拿到 Demo 之后的下一跳：从「Harness 能跑」到「需求进、节点绿出」的工作台接口，以及 Loop 三层怎么拆着设计，避免停在技术叙事
• 一套可借鉴的切分与关系维护方法：需求级 SDD 先 DDD 划界，再编译 DAG；用上游产物约束并行，处理「太粗不能重跑 / 太细会扯皮」
• 三个可复用的工作台插件方向及避坑：认知卸载（待办不要变成垃圾场）、后台持久会话（tmux 要解决看哪一路）、远端任务驱动（Git 列表必须过滤）。帮助团队少把空转换到下一个容器里

AI 已渗透产研链路各个工种，但让这些能力沉淀为组织级的交付效率，仍是 AI Native 组织面临的重要问题。大型需求的成本，多半不在写代码，而在跨角色的反复对齐与验证断点。飞猪交付大脑的解法是打造一条超级流程：把冗长的交付链路收敛为需求对齐、Coding实现、测试验收几个关键阶段，让 Agent 成为流程的第一公民，并串联整条链路。本次分享将拆解这条流程的设计、工程实现与真实效果。

演讲提纲

1. 组织级提效，关键在流程而非工具

• 挑战：个体提效 不等于 整体交付提效
• 解法：用 Agent 串联起超级流程，拉齐各环节断点

2. 交付大脑：把交付链路收敛成一条超级流程

• 主链路三段式：需求对齐 → Coding 实现 → 测试验收
• Agent 作为第一公民，串联并编排整条链路
• 版本化 Spec 做多角色事实基线，异步澄清替代对齐会
• 交付过程沉淀为可复用记忆，让流程持续进化

3. 端到端 Loop 的工程实现

• 小闭环：单端自验证、自修复
• 大闭环：前后端联调、端到端验证，跑通真实业务链路
• 可控收敛：完成条件 + 人工接管，避免 Loop 空转

4. 案例：一个真实需求的全流程与效果

• 从需求到交付的完整实现
• 角色协作怎么变、AI 边界在哪、实测效果如何

实践痛点

• 协同 vs 成本：多角色共享一份 Spec 能减少信息差，但人人都进所有环节，反而拖慢决策——得按影响面定向拉人，而非全员全程
• AI 自主 vs 人工接管：Loop 想让 AI 自动收敛，但总有它自证不了、反复震荡的环节——必须预设完成条件和接管点，否则流程会在个别地方空转

演讲亮点

• 交付大脑把 AI 沉淀进交付流程本身，用 Agent 编排、多角色共享 Spec 的一条超级流程，让组织整体交付变快
• 让 Agent 成为流程的第一公民——主导编排，人做关键决策与接管，形成 Human + Agent 的新型协作

听众收益

• 组织级提效的思路：怎样把散落在各工种的 AI 能力，收敛成一条可复用的交付流程
• 多角色协同的落地法：用版本化 Spec 和前置协议契约拉齐产研测，用异步澄清替代对齐会
• AI 自验证闭环的工程设计：怎样让 AI 在真实环境里完成“编码—运行—修复”并可控收敛

我们团队承担零售大部分营销相关 H5 页面以及大量中后台页面研发，月均响应约 200 个需求，本次分享将围绕三类真实落地场景，呈现 AI Agent 从“生成”走向“交付”的三次工程化跃迁：第一次跃迁聚焦中后台场景，突破“人工编码”瓶颈，通过“ AI + DSL ”将标准化页面转化为自动化流水线，解决规模化生产效率问题；第二次跃迁深入互动业务场景，Agent 不再单点生成代码，而是串联需求澄清、前后端开发、中后台配置、自动化发布，打通全链路AI化闭环，破解系统协同难题；第三次跃迁攻坚 C 端复杂场景，自研 AI Native 交付级产品，通过 Skill、知识库与 MCP 动态装配，叠加多 Agent “生产—评审”协同机制，让 AI 具备复杂决策与质量自闭环能力，近期 7 天完成 23 个需求交付，平均人工干预仅 2.22 次；而贯穿三次跃迁的 AI 巡检体系，则作为质量底座，确保每一次能力升级都能守住线上稳定性与问题快速响应的底线。希望借此与大家共同探讨 AI 在规模化前端研发中的工程化落地之道。

演讲提纲

1. 为什么 AI 会写代码，却还不会交付

• 京东业务前端承担大量 H5 和中后台需求，研发效率直接影响业务响应速度
• AI Coding 已经显著提升代码产出，但生成代码、完成需求和业务上线是三个不同层次
• 核心命题：如何把 AI 从研发辅助工具，升级为能够持续交付结果的 Agent

2. 第一次拐点：从代码生成到领域工程

以京东运营中后台自动化交付为例

• 通用模型会写代码，但不了解内部组件、业务规则和交付规范
• 将组件、知识和研发规则沉淀为 DSL、Schema、Skill 与知识库
• 通过“生成—运行—验证—修复”闭环，提高首版可用率
• 核心观点：确定性能力交给工程系统，不确定性问题交给模型

3. 第二次拐点：从单 Agent 到交付 Loop

以 自研 AI Native 为例

• 将 Agent、Skill、知识库、MCP、执行器和任务状态统一纳入交付平台
• 通过多 Agent 分工，形成生产、评审、返工和再验证的交付循环
• 支持人工介入、主动反问、暂停续跑和会话恢复
• 核心观点：Agent 不是越自主越好，人机交接线决定交付可靠性

4. 第三次拐点：从交付代码到交付业务结果

以京东互动万花筒 Agent 为例

• 交付目标不再是生成代码，而是直接创建一个经过评审、可以使用的互动活动
• 前后端交互层面的设计和验证
• 通过确定性 Graph 串联意图识别、内容生成、活动创建、自动评审与修复
• Agent 通过工具、API 和 MCP 操作真实业务系统
• Agent 安全风险及解决方案
• 核心观点：流程明确的场景适合 Graph，探索型任务适合开放式 Loop

5. 从三个案例抽象出一套 Agent 交付方法

一套可交付的 Agent 系统需要五个基本要素

• 领域上下文：让 Agent 理解业务，而不只是理解代码
• 任务编排：根据场景选择单 Agent、多 Agent、Graph 或 Loop
• 工具执行：让 Agent 能够操作代码仓库和真实业务系统
• 安全及质量守门：验证代码、运行结果和业务结果
• 人机协作：明确 Agent 自主执行与人工决策的边界

6. 总结：衡量 AI 的指标需要改变

• 从 AI 代码占比，转向需求交付率
• 从单次生成成功率，转向闭环修复能力

实践痛点

• 如何在 DSL 标准化约束下，兼顾复杂业务表达与高质量风格化 UI 生成
• 如何保障多 Agent 协作的一致性与人机交接效率，同时满足算力、成本和响应时延要求
• 如何突破 lint、单测和类型检查的质量边界，对 AI 代码的性能、转化和视觉体验进行场景化验证与风险拦截

前沿亮点

• 基于领域 DSL 的 AI 自动化交付
  • 将高频、低定制页面抽象为 DSL 与组件协议，AI 只生成业务意图，让任何人无需技术背景也能安全、稳定地交付生产可用功能
• 多智能体协同的人机共治交付体系
  • 复杂需求场景，摒弃单 Agent 端到端完成复杂需求的理想化假设，按能力边界组织多 Agent 协作，并由跨团队专家在关键节点决策，形成可靠、可控的交付闭环
• AI 自动化巡检闭环
  • 面向研发治理场景构建多能力 Agent 平台，将体验评估、性能优化、资损风险识别和架构问题诊断统一到一个智能走查框架中。区别于业界常见的性能监控、代码扫描或架构评审工具，它不是孤立输出指标，而是结合页面、代码和仓库上下文进行综合判断，形成可解释、可追溯、可落地的风险洞察与优化建议

听众收益

• 建立从“代码生成”到“自动化交付”的完整认知
  • 理解各 AI 效率指标的区别，建立更贴近业务价值的 Agent 评价指标
• 掌握企业级 Agent 的三种工程化路径
  • 了解领域 DSL、专家团 Loop、确定性 Graph 分别适用于哪些场景，以及如何进行技术选型
• 获得可复用的多 Agent 专家团设计方法
  • 学习如何通过主理人、领域专家、独立验收官、共享工作区和质量门禁，构建“规划—生产—验收—返工”的交付闭环
• 借鉴真实业务落地经验与取舍
  • 从京东运营后台、自研 AINative 和互动万花筒三个案例中，了解识图失真、上下文污染、验收滞后和高风险操作等实际问题及解决思路

随着 Code Agent 开始承担越来越复杂、越来越长程的软件开发任务，仅靠 Harness 提供上下文、工具和执行环境，已经难以保证 Agent 持续稳定地产出结果。如何让 Agent 不仅“完成任务”，还能判断结果、发现问题、自动修正，并通过持续迭代不断提升效果，成为 Agent 工程化落地的新挑战。

本次分享将以网易智企 CodeWave SDD 的实践为例，介绍如何从 Harness 进一步走向 Loop，围绕 Benchmark 评测体系建设、小成本开发试错、自动化智能化迭代、现场可观测 等方面，分享 Agent Loop 的工程实践，包括如何构建评估体系、自动执行与修正任务，以及如何通过可观测和反馈持续优化。同时结合实践中的成本、效果与适用范围，分享 Loop 工程落地过程中的取舍与经验。

演讲大纲

1. 从 Harness 到 Loop：Agent 工程实践的演进

• 从 Vibe Coding 到 SDD：开发流程的变化
• Harness 在实际应用中的问题与人工介入
• 执行、验证、修正的 Loop 设计

2. CodeWave SDD 的 Harness 实践

• 需求拆解与 Spec 驱动开发
• 上下文、工具与执行环境设计
• 大规模 SDD 任务的执行与优化

3. Benchmark 与评估体系建设

• Code Agent Benchmark 的数据集构建与管理
• LLM-as-Judge、Rule-based、SWE Style、Hybrid 等评估方式
• 测试结果量化与问题定位

4. 自动执行、问题修正与 Agent 迭代

• 自动化任务执行与测试评估
• 基于评测结果的问题分析与 Auto Correction
• 执行—评估—修正—重跑的闭环
• 分数驱动的 Agent 策略迭代与成本控制

5. 可观测与持续优化

• Agent 执行过程的监控与告警
• 执行链路追溯与结果回放
• 线上问题反馈与迭代优化

6. 实践总结：Loop 工程的落地取舍

• Loop 工程的适用场景与前置条件
• Benchmark 规模、评估质量与自动化程度的平衡
• 自动化收益与 Token、算力等成本的权衡
• 从 Harness 到 Loop 的实践路径与经验

实践痛点

• 合理评估 ROI，选择合适的范围进行实施
• Benchmark 需要有一定的规模化样本

前沿亮点

• 控制论角度的 Loop 工程方法：区别于把 Loop 讲成“定时触发、worktrees、连接器”等工具组合的解读，本议题给出“环工程的核心思想 + 环分析法 + 多视角诊断”的可复用框架，并用它驱动分析全部实践内容
• 面向复杂 Agent 的分层 Benchmark 与混合评估体系：覆盖全流程阶段的测试集，结合 LLM-as-Judge(Rubric)、SWE Style、Rule-based、Hybrid 等多种评估策略，构建完善的测评体系
• 分数驱动的 Agent 自我迭代机制：把“自动化执行 + 自动化测评 + 智能化修复”组成闭环，让 Agent 在受控边界内做低成本自我迭代
• 长程任务的稳定性提升与 Harness Loop 工程实践经验

听众收益

• 一套判断闭环是否真正成型的检查方法
• Agent 自我迭代的落地条件与边界
• 可借鉴的评估与度量体系设计经验
• 从 Harness 走向 Loop 的实施路径和经验