AI Coding 之后，如何让 Agent 进入企业研发全链路？得物推荐的 Harness 实践

在 AICon 全球人工智能开发与应用大会上，InfoQ 邀请得物资深技术专家白忠魏带来演讲，分享得物推荐团队在企业级复杂系统中推进 AI 研发实践的思考与经验。演讲中，白忠魏从得物推荐的业务与工程场景出发，围绕“如何让 AI 从写代码走向完整研发迭代”这一问题，介绍了团队在 PDCA 全链路、七阶段护栏、TPRD、研发环境与测试验证、AI 推荐质量评测、三层知识体系，以及 Highway + ATV 混合 Agent 架构等方面的探索，并分享了阶段性的实战数据。 以下为演讲内容，经 InfoQ 整理。 一、从 AI Coding 走向 AI 全链路 目前，AI Coding 已经能够较好地完成从 0 到 1 的项目和相对简单的编码任务。在部分场景下，它交付的结果甚至会超出工程师的预期。对于这一点，行业内已经形成了较为明确的共识。 但在企业级项目中，AI 面临的环境要复杂得多。如果面对的是一个运行了十几年、代码量庞大的老项目，或者一个横跨多个系统和业务层级的超大型项目，AI 能否准确理解需求、控制影响范围，并对最终结果负责，仍然是一个需要持续探索的问题。 得物推荐也在推进类似实践。我们的目标并不只是让 AI 写代码，而是将 AI Coding 扩展为一套覆盖需求、开发、验收和问题反思的 AI 全链路方法。 得物推荐本身是一套较为复杂的系统。用户进入得物后，看到的推荐内容大致可以分为两部分：一部分是商品交易推荐，接近淘宝、京东的场景；另一部分是帖子和内容推荐，接近内容社区或短视频平台的场景。 整套系统包含召回、粗排、精排、推荐引擎以及大量上下游服务，是一个历史较久、规模庞大的复杂工程。如何让 AI 真正进入这类系统的研发流程，正是我们这次实践的出发点。 二、AI 驱动的研发迭代飞轮 从软件工程视角看，一次完整的研发迭代可以抽象为 Plan、Do、Check、Act 四个阶段，也就是常见的 PDCA 循环。 Plan 是需求对焦。需求开始后，产品经理和技术团队需要围绕目标、边界、上线时间和验收标准达成一致。这个阶段的主要产出包括 PRD、研发排期，以及判断需求是否达到预期的成功标准。 Do 是开发实现。这一阶段不仅包含编码，还包括上下游联调、单元测试、集成测试和功能验收，最终产出代码、单元测试及发布方案。 Check 是效果校验。需求开发完成后，需要经过测试验证、灰度发布和指标观测，判断功能上线后的真实效果。 Act 是分析、反思和问题排查。对于推荐业务而言，功能上线并不意味着研发过程结束。团队还要继续观察业务指标，处理体验类和功能类问题；一旦出现 Bad Case，便需要分析原因，并将结论带入下一轮迭代。 目前，多数团队的 AI 实践主要集中在 Do 阶段，也就是让 AI 写代码。在需求产出、测试验收、业务效果判断，以及最后的 Bad Case 分析和问题反思中，AI 的参与程度仍然有限。 我们希望做的，是将这些环节真正串联起来，让 AI 不只参与开发，而是进入完整的 PDCA 循环。 全链路 AI 化的四个前提 如果希望 AI 参与完整研发流程，那么每一个阶段都必须具备清晰的约束和判断标准。 在 Plan 阶段，需求必须足够明确，目标和边界不能反复摇摆。如果一开始的目标是 A，执行过程中又不断变成 B，后面的开发与验收就无从谈起，AI 也无法稳定执行。 在 Do 阶段，AI 的执行过程应尽量减少中断。理想状态下，工程师给出任务后，AI 可以持续运行较长时间，而不是频繁因为环境、依赖或信息不完整而向人提问。虽然距离完全自主执行仍有差距，但研发环境应尽可能降低 AI 的等待成本。 在 Check 阶段，结果必须能够量化。AI 和推荐系统在一定程度上都具有黑盒特征，我们很难了解内部每一步的全部细节，因此需要通过测试结果和后验数据判断产出是否可靠。 在 Act 阶段，经验必须能够复用。过去踩过的坑不能在后续任务中反复出现。我们会要求工程师不要在同一个问题上重复犯错，对 AI 也应当建立同样的要求。 最终，我们希望提高 AI 在整个需求链路中的渗透率和产出采纳率，同时缩短研发迭代周期。很多团队目前按照周或双周进行迭代，如果 AI 能够参与完整链路，双周迭代有机会缩短到周，周迭代则有机会缩短到天。更理想的状态是，一轮任务完成以后，系统能够自动进入下一轮，而不再受固定迭代周期的限制。 好的 Harness，是环境而不是铁笼 可以借用《楚门的世界》理解 AI Harness 的作用。 电影中，楚门生活在一个巨大的摄影棚里。摄像头、演员、天幕和围墙都在限制他的行动，但真正让他不敢离开小岛的，其实是水。童年经历使他对水产生了强烈恐惧，因此水并不是一面写着“禁止离开”的墙，而是成为了环境本身。 好的 AI Harness 也应当如此。 Harness 的作用不是在 Prompt 中堆叠大量“不要”“禁止”和“必须”，而是搭建一个让 AI 自然按照预期方式运行的环境。 如果为 AI 增加过多显性的限制，它反而可能因为无法同时满足所有条件而停止执行。更有效的方式，是把约束融入环境、工具和验证流程中，让 AI 在执行任务时，自然按照既定方式运行。 基于这一思路，我们按照 PDCA 四个环节进一步抽象出了七阶段护栏，并从护栏能力、护栏载体和约束逻辑三个方面设计整套全链路体系。 在这套体系中，人仍然承担着不可替代的作用，尤其是在技术方案评审，以及 Check、Act 两个阶段。 技术方案评审是 AI 开始长时间自主执行之前，最后一个能够由人进行双层 Review 的位置。AI 真正开始编码前，需要先提交计划采用的方案，由工程师判断其对需求的理解是否准确、技术方向是否存在偏差。否则，AI 可能沿着错误方向持续运行很长时间。 Check 和 Act 阶段则不应只关注线上稳定性。目前很多团队更擅长判断系统是否报错、接口是否超时、服务是否异常，却缺少对业务效果的智能化判断。如何让 AI 参与业务结果分析，也是全链路建设中需要继续完善的能力。 三、在 Plan、Do、Check、Act 中建立工程护栏 Plan：用 TPRD 和 Contract 把需求变成可执行边界 日常需求讨论通常采用自然语言。自然语言的问题在于，即使所有人都认为自己理解了，同一句话在不同角色眼中仍然可能具有不同含义。 为此，我们在 PRD 之后增加了一层 TPRD，并在其中引入 Contract。Contract 用来提前明确需求会影响哪些模块、优化目标是什么、应该朝哪个方向调整，以及有哪些技术约束不能突破。 技术团队也会将需要明确的技术条件提前反馈给产品同学，使需求得到更加结构化的描述。这样，AI 真正开始执行时，拿到的就不只是一段自然语言，而是一套可以理解和遵守的边界。 TPRD 是后续所有阶段的围栏。目标和方向如果不清楚，代码写得再快、测试做得再完整，也可能只是在错误方向上努力。 我曾经带一位同学去开会，原本应该去 5 号楼，结果却走到了 4 号楼。那位同学对我说：“如果方向走偏了，怎么努力都没有用。”这句话也可以概括我们建设 TPRD 的核心原因。 例如，产品提出一个需求：“用户点击不感兴趣后，少推荐一些类似商品。”这句话看起来很容易理解，但从技术