百度垂类搜索展现服务如何通过Agentic代码交付提升效率

在搜索结果展现这类业务中，随着形态和场景的快速膨胀，传统的交付模式正面临巨大挑战。一个看似简单的数据转换逻辑，从需求到上线，往往需要经历漫长的开发、联调和发布流程。当这种需求从几个变成几百上千个时，人工成本会线性增长，交付效率的瓶颈就变得尤为突出。

那么，有没有可能让机器来编写这些逻辑，并确保它能安全、快速地生效？这正是RenderFlow要回答的问题。它并非一个简单的代码生成工具，而是一套围绕“生成、执行、反馈、修复、发布”构建的完整工程闭环。其目标很明确：在不改动核心业务架构的前提下，将单场景逻辑的交付周期从天级压缩到分钟级，并将需要人工介入的比例降至5%以下。目前，这套系统已支撑了近千个场景的线上稳定运行。

01 背景与现状

1.1 搜索结果展现的传统交付流程

回顾传统的交付模式，一个展现需求从提出到上线，通常要串联产品、设计、研发、测试等多个角色，经历需求评审、开发、测试、上线等多个阶段。这套流程在业务早期是有效的，但随着结果形态日益复杂、流量规模持续扩大，其局限性开始显现。

1.2 规模化交付的主要挑战

当场景数量从个位数迈向百位数甚至千位数时，传统模式面临三个核心挑战：

首先，是逻辑生产和验证的成本问题。单个场景的开发周期或许可控，但规模化后，人工编写、数据标注、联调验证的成本会呈线性增长。历史数据显示，新增一个品类的覆盖平均需要4天，复杂行业的数据对接周期可达一周，某些标注流程甚至需要投入7个人天。这种成本结构，显然无法适应热点场景需要快速覆盖和持续迭代的节奏。

其次，是单场景逻辑的生效链路过长。在传统架构下，展现逻辑通常与服务代码强耦合，任何细微调整都需要走一遍完整的服务构建、测试和发布流程。这意味着，即使只想快速验证一个小改动，也得等待整个服务的发布窗口，灵活性和效率大打折扣。

最后，是方案的泛化与扩展能力不足。现有的解决方案往往是为特定场景定制的，缺乏可复用的抽象。当面对新的品类或更复杂的需求时，团队往往需要从头开始梳理和适配，难以快速复制成功经验。

1.3 从 LLM 生成到 Agentic 交付闭环

大语言模型（LLM）的出现，为破解上述困局提供了新的思路。它的价值不在于碘伏整个交付流程，而是瞄准其中成本最高、最依赖人力的环节——逻辑的生产、验证和迭代。

但必须清醒认识到，模型生成的代码并不等同于可上线的代码。它可能包含运行时错误，可能无法理解复杂的业务约束，其行为在真实流量面前也存在不确定性。因此，RenderFlow设计的核心，不是一次性的代码生成，而是构建一个包含“生成、执行、反馈、修复、发布”的智能体（Agentic）闭环，确保模型产物能够被安全、可靠地交付到线上。

02 RenderFlow 的设计与实现

2.1 整体架构与执行流程

基于上述目标，RenderFlow将整个交付过程拆解为一组紧密衔接的工程模块。你可以将其理解为一个为代码生成任务量身定制的“智能体框架”（Agent Harness），它把上下文组织、模型调用、执行验证、质量审查和版本发布都纳入了统一的工程化管理。其整体架构如下图所示：

整个流程可以概括为四个层次加一个独立治理流程：

输入准备层负责构建结构化的任务上下文。系统为每类业务场景预定义了适配器，封装了特定的Prompt模板、配置格式和测试策略。用户只需通过表单填写参数，系统便能自动组装出包含需求描述、API文档、目标数据格式（Schema）、输出约束和测试用例的完整Prompt，将隐性的业务经验转化为可复用的配置。

生成与修复层构成了核心的迭代闭环。代码生成器（Coder）根据Prompt产出代码后，会提交到可执行引擎中运行。如果执行失败，错误信息会被结构化，并由审查器（Reviewer）分析并生成修复建议，驱动下一轮代码生成，形成“生成-执行-反馈-再生成”的循环。

可执行引擎层提供了统一的运行时底座。这是关键的设计决策：将业务逻辑从服务代码中解耦，以配置形式动态加载和执行。预览、测试和线上环境复用同一套引擎，从根本上保证了验证环境与线上环境的一致性，避免了“测试通过，上线出错”的尴尬局面。

发布与治理流程则扮演着工程“护栏”的角色。生成的代码必须依次通过效果预览、关键字段校验、自动化回归测试和性能比对，再经审批后才能上线。配置管理系统支持灰度发布、版本快照和快速回滚，将模型的不确定性牢牢约束在可控的工程流程内。

结果输出层最终产出前端可直接渲染的结构化模板数据，完成从配置到展现的最后一环。

以一个新增场景为例，用户配置完成后，系统自动触发上述闭环：生成代码、执行验证、多轮修复、质量审查、最终发布上线。通过这条端到端的工程化链路，LLM的生成能力被无缝对接到了真实的业务交付中。

2.2 可执行引擎

传统模式下，逻辑变更等同于服务发布，这是效率瓶颈的根源。RenderFlow的可执行引擎正是为了解决这个问题而生。它让业务逻辑以配置的形式存在，在运行时动态加载和执行，从而将生效时间从“天级”缩短到“分钟级”，并与服务发布周期彻底解耦。引擎底层选用Yaegi作为Go代码解释器，其内部结构如下图所示：

引擎的工作流程清晰而稳健：收到请求后，根据场景标识路由，动态加载对应的转换代码，并为每次执行创建独立的解释器实例。实例会加载标准库和业务方注册的能力，然后执行代码并返回结果。

在隔离与容错方面，每次请求独立的实例确保了场景间的完全隔离，单个场景的崩溃不会波及其他。引擎在多层设置了异常捕获机制，将运行时错误转化为可处理的错误结果，而非导致服务中断。对于关联多份逻辑的场景，引擎会并发执行并择优返回，兼顾了成功率和响应速度。

当然，动态解释执行必然会引入额外的性能开销。RenderFlow的优化策略并非追求替代所有静态逻辑，而是明确其适用边界：专注于输入输出明确、执行路径可控的数据转换场景。通过配置缓存、冷启动优化、高频场景预热，以及严格避免复杂计算和长链路外部调用进入解释执行路径，系统在性能与灵活性之间取得了平衡。当配置中心不可用时，引擎还能自动降级到已知稳定版本，保障服务的连续性。

这套引擎的价值远不止于“动态生效”。它为模型产物提供了一个真实、一致且可反馈的执行环境，使得预览验证、自动化测试和线上执行得以统一，执行失败的信息也能直接反哺给修复闭环。

2.3 质量保障

将LLM生成的代码用于线上服务，质量是生命线。风险不仅来自代码本身的缺陷（如空指针、数组越界），更源于业务环境的不确定性，比如上游数据结构变更、配置漂移，以及规模化后的性能容量问题。为此，RenderFlow构建了贯穿发布前、中、后的三道防线。

第一道防线：发布前拦截。代码生成后，需连过三关。静态分析首先过滤掉明显的语法和结构风险；预览执行则使用样例数据在引擎中实际运行，验证其行为；最后，自动化回归测试会在镜像环境中引入线上真实流量，进行新旧版本的结果对比和性能测试。这三关分别确保了代码的静态正确性、动态可运行性以及回归安全性。

第二道防线：发布过程拦截。在分阶段发布（灰度）过程中，每推完一个机房，系统会自动触发校验，检查服务的稳定性指标（如SLA、崩溃率、资源使用率）和核心接口功能。一旦发现异常，立即阻断后续机房的发布，将影响控制在最小范围。

第三道防线：上线后巡查。代码上线并非终点。系统会对核心场景进行分钟级的效果巡查，对全量场景进行天级巡查，校验核心字段和数据的正确性。同时，稳定性监控和流量异常预警持续运行。一旦发现问题，配置管理系统可以基于版本快照实现分钟级的快速回滚。

通过这套组合拳，模型生成代码的不确定性被层层拆解和控制，使其最终满足可验证、可观测、可灰度、可回滚的线上交付标准。

2.4 多轮修复机制

LLM单次生成代码的“一次通过率”是有上限的。在搜索展现场景中，问题主要分两类：一是运行时错误（如类型断言失败），二是业务理解偏差（如遗漏关键字段）。平台数据显示，首轮生成代码的直接接受率在82%左右，仍有改进空间。如果这部分仍需人工修复，那么LLM的价值就大打折扣。

因此，RenderFlow引入了多轮修复机制，将单次生成升级为一个智能体协作的闭环：“生成 → 执行 → 反馈 → 再生成”。其核心架构如下图所示：

这个闭环的精妙之处在于其角色分工和记忆设计。它并非简单地将错误信息扔回给模型，而是通过Coder和Reviewer两个角色的协作，并辅以修复记忆（Memory），来解决三个关键问题：

首先，避免“打补丁”式修复。Reviewer的角色被设定为“军师”，而非“操刀手”。它只分析错误，输出自然语言描述的修复约束（例如：“访问切片前必须检查长度”），而不直接修改代码。这样一来，下一轮的Coder就必须基于完整的原始需求和所有历史约束，重新生成一份全新的、更健壮的代码，从而避免了在错误代码上局部修补可能带来的结构性问题。

其次，避免修复过程“开倒车”。在多轮交互中，一个常见陷阱是修复了新问题，却无意中破坏了已解决的旧问题。RenderFlow的Memory机制确保了修复约束的“单调递增”。每一轮Reviewer产生的约束都会被记录，并在下一轮作为“历史修复建议”注入给Coder。这些约束会去重、合并，但绝不会被丢弃，从而保证已解决的问题不会复现。

最后，沉淀可复用的修复经验。系统会将执行引擎捕获的异常，结构化地抽象为错误模式（如“数组越界”、“空值访问”）。这些模式不仅用于当前任务的修复，还会被沉淀到通用经验库中。随着处理场景的增多，系统能积累越来越丰富的修复模式，实现越用越智能。

在工程实现上，系统也考虑了降级策略。当模型服务不可用时，可以降级到基于规则引擎的预设修复提示，保障修复流程不中断。

实践表明，引入多轮修复后，大多数问题能在2到3轮内收敛，需要人工介入的比例降至5%以下。更重要的是，修复记忆将每一次的调试经验都转化为了可复用的工程资产。

03 落地效果与实践总结

3.1 落地效果

自上线以来，RenderFlow在多个维度取得了可量化的收益：

交付效率方面，单场景数据转换逻辑的交付周期从天级、周级压缩到了30分钟以内，实现了从配置到上线的分钟级端到端交付。

代码质量方面，结合多轮修复机制，需人工修改的比例降至5%以下，且质量保障体系覆盖了从生成到上线的全链路，显著降低了线上风险。

服务能力方面，基于Yaegi的可执行引擎已在搜索核心场景中稳定运行，验证了动态解释执行架构在高压业务下的可行性。

覆盖规模方面，系统已支撑近千个业务场景的日常迭代，横跨多条业务线，覆盖了从简单数据抽取到复杂语义映射的多种需求类型。

3.2 实践思考

回顾整个落地过程，RenderFlow的定位非常清晰：它并非一个追求通用性的全能代码助手，而是一个专注于“搜索结果展现”这一特定领域的交付闭环系统。这与Devin、SWE-Agent等致力于解决开放域编程任务的智能体，或Copilot这类聚焦于IDE内辅助编程的工具，有着本质区别。

它的设计哲学是，通过收敛任务边界（结构化数据转换）、统一执行环境（可执行引擎）和严格工程治理（质量保障），来换取生产环境下的高度可控性和可靠性。这种“有所为，有所不为”的选择，是其能够大规模落地的关键。

当然，这套方案也有其明确的边界。多轮修复后，仍有约5%的场景需要人工介入，通常源于那些需要深度业务知识进行模糊判定的情况，或者线上长尾数据未被样例覆盖。此外，解释执行的性能天花板决定了它更适合逻辑轻量、IO密集的数据转换任务；对于计算密集型或强状态依赖的场景，仍需通过架构拆分来回退到静态服务实现。随着系统规模扩大，修复记忆的治理、上下文长度的控制，也是需要持续优化的工程课题。

3.3 总结

综上所述，RenderFlow的核心实践表明，将LLM生成的代码用于生产，不能仅仅依赖模型本身的能力。它更需要一套坚实的工程体系来保驾护航。这套体系可以提炼为三项关键设计：

第一，可执行引擎提供了动态底座。它将逻辑从服务中解耦，实现配置化动态加载，让迭代效率发生了质变，并保证了从测试到上线环境的一致性。

第二，质量保障体系构筑了工程护栏。通过发布前验证、发布中拦截、上线后巡查的三层防线，将模型的不确定性约束在了可验证、可灰度、可回滚的安全范围内。

第三，多轮修复机制实现了智能收敛。通过Coder/Reviewer分工协作和修复记忆累积，系统能够自动诊断和修复大部分问题，将人工从重复的调试工作中解放出来，并让系统具备了持续学习进化的能力。

从更高视角看，RenderFlow构建了一个完整的“智能体框架”。它将模型、执行环境、反馈循环、记忆模块和治理机制有机整合，形成闭环。正是这个闭环，使得LLM的灵活生成能力，能够被安全、高效、规模化地转化为稳定的线上交付能力，最终在近千个场景的复杂业务中，将交付效率提升了一个数量级，同时确保了线上服务的稳定可靠。