RenderFlow：百度垂类搜索展现服务的 Agentic 代码交付实践

​

导读

本文以搜索结果展现为例，介绍 RenderFlow 如何将 LLM 代码生成能力落地到线上服务。随着结果形态和业务场景持续增加，传统依赖人工完成逻辑编写、联调验证和问题修复的链路，逐渐暴露出交付周期长、重复适配多、调整成本高等问题。

RenderFlow 围绕"生成、执行、反馈、修复、发布"构建交付闭环：Prompt 适配器负责沉淀场景上下文，可执行引擎负责承载模型产物，多轮修复机制用于收敛生成质量，覆盖发布前、发布中、上线后的质量保障则用于控制线上风险。上线后，单场景数据转化逻辑交付从天级压缩到分钟级，需人工介入修改的比例降至 5% 以下；当前系统已支撑近千个场景的线上运行。

01 背景与现状

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

在传统模式下，一个搜索结果展现需求从提出到最终上线，通常要经历需求评审、开发、测试和上线四个阶段。整条链路跨产品、设计、研发、测试等多个角色，流程较长，协作成本也较高。

这类交付方式在早期能够满足需求，也支撑了不少场景上线。但随着结果形态持续增加、流量规模不断扩大，传统链路的局限逐渐显现。

1.2 规模化交付的主要挑战

• 逻辑生产和验证成本偏高。从历史业务接入经验看，新增品类覆盖平均 4 天，复杂行业的数据对接周期可达 1 周；部分数据标注与模板挖掘流程曾需要 7 人天级投入。单个场景看似可控，但当需求扩展到百级、千级场景时，人工开发、标注、联调、验证和问题修复成本会随规模线性增长，难以适应热点场景的快速覆盖和持续迭代。

• 单场景逻辑生效链路长。 传统模式下，展现逻辑通常随服务代码统一管理和发布，单个场景的逻辑调整也需要进入服务级变更流程。随着场景数量增加，这种以服务为单位的生效方式难以支撑单场景逻辑的快速验证、独立生效和低成本回退。

• 泛化与扩展能力不足。 现有方案能够支撑部分固定场景，但面对更多品类和更复杂需求时，往往需要针对单个场景重复梳理和适配，难以快速复制和扩展到更大范围。

1.3 从 LLM 生成到 Agentic 交付闭环

LLM 的引入，并不是要改变整条传统交付流程，而是为其中成本最高、最依赖人工的逻辑生产、验证和迭代环节提供新的可能。随着模型在代码生成、上下文理解和复杂约束遵循方面的能力提升，结果展现逻辑开始具备从人工编写走向自动生成的基础。

但在真实业务场景中，模型生成结果并不能直接等同于可上线结果。生成代码还需要经过执行验证、错误修复、效果一致性确认和发布风险控制，才能进入线上链路。因此，RenderFlow 关注的不是一次性的 LLM 代码生成，而是围绕生成、执行、反馈、修复和发布构建 Agentic 闭环。

02 RenderFlow 的设计与实现

2.1 整体架构与执行流程

基于第一章提出的交付目标，RenderFlow 将代码生产、执行验证、反馈修复和发布治理拆解为一组相互衔接的工程模块，使模型生成结果能够在同一条链路中完成验证、迭代和上线。整体架构如下图所示：

架构自上而下分为输入准备、生成与修复、可执行引擎、结果输出四层，右侧独立设置发布与治理流程。整体上看，这套架构可以理解为 RenderFlow 的 Agent Harness：它将上下文组织、模型生成、执行反馈、质量护栏和版本发布组织在同一套工程框架中。

• 输入准备：构建结构化任务上下文。平台为每类业务场景定义独立适配器，封装该场景特有的 Prompt 模版、配置格式与测试策略；用户通过动态表单填写场景参数后，系统自动选择适配器并组装 Prompt。实际组装时，Prompt 会将需求描述、API/字段说明、目标模版 Schema、输出约束和测试样例组织成固定结构，将原本依赖人工描述的场景适配经验转化为可复用的模版和配置。

• 生成与修复：形成反馈迭代闭环。Coder 根据 Prompt 生成转换代码；代码提交到可执行引擎运行验证；若执行失败，错误信息会被整理为结构化反馈，由 Reviewer 生成修复约束，并注入下一轮生成，形成"生成 → 执行 → 反馈 → 再生成"的闭环。

• 可执行引擎：提供统一执行底座。核心决策是将业务逻辑与服务运行解耦------代码以配置形式动态注入，由引擎在运行时解释执行。预览执行、自动化测试、线上执行三个阶段复用同一套引擎，保证验证环境与线上环境行为一致，降低验证漂移风险。

• 发布与治理：提供工程护栏。 代码生成后，需要经过效果预览、关键字段校验、自动化回归、性能对比，再经审批推送上线。配置管理系统支持分阶段发布、全量发布、版本快照和快速回滚，将模型生成的不确定性约束在可验证、可分阶段发布、可回退的工程流程内。

• 结果输出：产出可直接渲染的结构化模版数据。线上执行服务动态加载转换逻辑，将原始数据转化为前端可消费的结构化模版数据，完成从场景配置到线上展现的闭环交付。

以一次新场景接入为例，用户录入配置后，系统自动生成 Prompt 并调用 LLM 产出代码；代码在可执行引擎中执行验证，失败则进入多轮修复，成功后经过预览、测试、审批和发布，最终在线上动态加载生效。通过这条工程链路，RenderFlow 将 LLM 的生成能力接入真实执行、自动修复和发布治理过程，完成从场景配置到线上生效的端到端交付。

2.2 可执行引擎

传统模式下，展现逻辑以静态代码形式存在于服务仓库中，每次变更都需要经历完整的构建发布链路。即使只是调整一个字段映射或输出结构，也可能需要重新开发、测试和发布，整个周期从天级别到周级别不等。当系统需要支撑成百上千个场景并频繁迭代时，这一链路成为交付效率的主要瓶颈。

在 RenderFlow 中，可执行引擎承担"执行环境"的角色。它将模型生成的转换逻辑从服务代码中剥离，以配置形式存储在配置管理系统中，由执行服务在运行时动态加载。引擎底层选择 Yaegi 作为 Go 代码解释器，使每次逻辑更新从"发布服务"简化为"更新配置"，无需编译、无需重启，生效速度以分钟计，且与服务的发布周期完全解耦。引擎内部结构如下图所示：

• 执行流程。引擎接收到请求后，根据场景标识路由到对应的执行路径，从配置管理系统加载该场景的转换代码，并为本次执行创建独立的解释器实例。实例初始化后，会加载标准库能力和业务侧注册的符号能力，再注入转换代码并调用约定入口完成数据转换，最终将结果组装为结构化的模版数据返回。整个过程中，代码加载、解释执行和结果构建各环节相互独立，便于单独演进和问题定位。

• 隔离与容错。每次请求创建独立的解释器实例，实例间无共享状态，单个场景的代码异常不会扩散到其他场景或服务本身。引擎在执行路径的多个层级设置了异常恢复机制，将运行时错误统一转化为可处理的错误结果返回，而非触发服务级故障。当一个场景关联多份转换逻辑时，引擎并发执行后择优返回最完整的结果，兼顾容错与响应速度。

• 性能与稳定性。动态解释执行相比静态编译会引入额外开销，主要集中在配置获取、解释器初始化、符号加载以及动态代码求值几个阶段。RenderFlow 的优化重点不是让解释执行替代所有静态服务逻辑，而是将其用于输入输出边界明确、执行路径可控的结果展现逻辑：配置侧通过缓存、冷启动优化和高频配置预热降低读取成本；执行侧通过入口约定和符号集合控制减少解释器加载范围，并避免复杂计算、长链路外部调用和有状态逻辑进入解释执行路径。当配置管理系统不可用时，引擎可降级到已有代码版本继续执行，保证服务连续可用。

这套可执行引擎的价值不只是让代码动态生效，更重要的是为模型产物提供了统一的执行与反馈环境：预览验证、自动化测试和线上执行复用同一套引擎，执行失败时的错误结果也可作为多轮修复的反馈来源。

2.3 质量保障

LLM 生成代码的风险不仅来自代码本身，例如越界、空指针、类型断言失败等运行时错误，也来自真实业务环境中的不确定性：上游数据结构变化可能导致字段路径失效，配置变更可能引入结果差异，规模化运行后还可能带来性能和容量风险。为此，RenderFlow 将质量保障贯穿发布前、发布中和上线后全过程，形成逐层递进的三道防线。

• 发布前拦截：验证代码能够正确运行。代码生成后，系统依次进行静态分析、预览执行和自动化回归测试。静态分析用于过滤越界、空指针等结构性风险；预览执行使用样例数据在可执行引擎上验证运行时行为；自动化回归测试则在镜像环境部署待发布配置，引入线上真实查询进行新旧版本 Diff 对比和性能测试。三者分别覆盖静态结构、运行行为和回归影响，任一环节未通过都会拦截发布请求。

• 发布过程拦截：控制配置推送风险。配置分阶段推送时，每个机房部署后自动触发校验：检查服务稳定性指标，包括SLA、panic率、CPU与内存占用，以及核心场景接口功能，发现异常立即阻断后续机房推送。对于转换代码变更，系统会根据变更涉及的具体场景动态选择对应的校验用例，避免无差别全量回归带来的成本。

• 上线后巡查：持续发现线上退化。代码上线后，系统对核心场景执行分钟级效果巡查，对全量场景执行天级巡查，覆盖各机房，校验核心字段非空和返回数据一致性。同时，链路稳定性监控与调用量异常预警持续运行。当问题发生时，配置管理系统可基于版本快照快速回滚。

通过这套质量保障链路，RenderFlow 将模型生成的不确定性拆解到不同阶段处理：发布前验证正确性，发布中控制扩散范围，上线后持续监控退化。它使 LLM 生成代码不再只是"能运行"，而是进一步满足可验证、可观测、可分阶段发布、可回退的线上交付要求。

2.4 多轮修复机制

LLM 单轮生成代码存在天然不确定性。在线上搜索结果展现场景中，这种不确定性主要表现为两类问题：一类是运行时错误，例如数组越界、空指针、类型断言失败；另一类是场景理解不完整，例如字段路径遗漏、边界数据处理不足、输出结构不符合预期。平台数据也验证了这一点：首轮生成代码的用户接受率为 82%，仍有一定比例结果需要人工修改。如果仍然依赖人工逐一修复，LLM 的价值会更多停留在降低首轮编码成本上，规模化交付能力难以充分释放。

为此，RenderFlow引入独立的多轮修复机制，将单次代码生成升级为"生成 → 执行 → 反馈 → 再生成"的 Agentic 修复闭环。整体架构如下图所示：

在这个闭环中，Prompt 组装不是一次性的输入构造，而是随修复阶段动态变化：生成阶段面向 Coder，组装初始需求、当前代码和 Memory 中累积的历史修复约束，驱动模型重新生成完整代码；审查阶段面向 Reviewer，组装执行反馈和错误摘要，要求模型只输出下一轮必须遵守的修复约束，而不直接生成代码。Reviewer 产出的修复约束写入 Memory 后，会在下一轮生成阶段重新注入 Coder Prompt，使约束随迭代持续累积。简化后的上下文结构如下：

Coder Prompt:
 -需求与上下文：{{需求描述 / 字段说明 / 目标 Schema}}
 -历史修复建议：{{constraint_1...constraint_n}}
 -当前代码：{{current_code}}
 -输出要求：重新生成完整可执行代码

Reviewer Prompt:
 -执行反馈：{{语法错误 / 运行时异常 / 日志 / 结果 Diff}}
 -输出要求：只生成修复约束constraint，不输出代码

这一机制并不是简单把报错再次丢给模型，而是围绕 Coder、Reviewer 和修复记忆解决三个关键问题。

• 避免局部补丁：Reviewer 只给约束，不直接改代码。在这个分工下，Reviewer 只产出自然语言形式的修复约束，例如"访问切片前检查长度""类型断言需要增加 ok 判断"，而不直接输出修复后的代码。这是一个刻意的设计选择：它避免模型机械复制局部补丁，而是促使 Coder 在下一轮生成时重新理解完整需求和约束，从整体上生成更健壮的代码。

• 避免修复回退：修复约束单调累积。 多轮修复中常见的问题是"修了新问题，丢了旧约束"。RenderFlow 将每轮 Reviewer 产出的修复约束写入 Memory，并在下一轮以"历史修复建议"的形式注入 Coder Prompt。例如，数组越界错误会被抽象为"访问列表元素前必须检查长度"，下一轮生成时模型会同时看到当前代码和所有历史约束。修复约束只增不减、自动去重，使约束集合随迭代单调增长，避免已修复问题被重新引入。

• 避免重复踩坑：Memory 沉淀通用修复经验。 可执行引擎捕获异常后，会将解释器堆栈、字段路径和触发输入整理为结构化错误摘要，再由 Reviewer 生成修复约束。任务内 Memory 保存当前任务的历史修复约束；任务外则可按错误模式沉淀通用经验，例如类型断言失败、数组越界、空值访问和字段缺失等。随着修复约束增多，系统会对相似建议进行去重和归并压缩，避免上下文持续膨胀。

在工程实现上，修复闭环还需要考虑外部依赖的稳定性。当模型服务不可用或 Reviewer 生成失败时，系统会降级为规则引擎，根据错误类型匹配预设修复提示，避免修复流程因单点依赖中断。

引入多轮修复后，实践中大多数问题可在 2～3 轮内收敛，需人工介入修改的比例降至 5% 以下。更重要的是，修复记忆将一次次修复从临时补丁沉淀为可复用的工程资产，使系统具备随场景规模增长而持续优化的能力。

03 落地效果与实践总结

3.1 落地效果

RenderFlow 上线后，在交付效率、生成质量和线上稳定性方面都取得了明显收益。

• 交付周期：单个场景的数据转化逻辑从人工开发的天级甚至周级压缩到分钟级，30 分钟内可完成从录入到发布的完整端到端交付。

• 代码质量：引入多轮修复后，需人工介入修改的比例降至 5% 以下，大多数问题可在 2～3 轮内收敛。质量保障链路覆盖静态分析、预览校验、自动化回归和审批发布等环节，进一步降低上线风险。

• 服务能力：可执行引擎已在搜索线上场景中稳定运行，验证了动态解释执行架构在搜索结果展现场景下的工程可行性。

• 覆盖规模：系统已接入近千个场景，横跨多条主要业务线，覆盖从结构化数据抽取到复杂语义映射的不同需求类型。

3.2 实践思考

从落地过程看，RenderFlow 并不是要构建一个覆盖任意软件开发任务的通用代码 Agent，而是选择在搜索结果展现这一类边界相对明确的场景中，优先解决"生成逻辑如何稳定执行、验证和上线"的问题。

这也决定了它与业界通用代码 Agent 的差异。Devin、SWE-Agent 更关注开放域开发任务中的自主规划、代码修改和测试执行；Copilot Workspace 更偏向 IDE 内的代码生成与开发辅助。RenderFlow 的重点在于将任务输入、代码形态、执行环境和发布流程收敛到一条确定链路中，场景适配器负责结构化输入、可执行引擎动态执行代码、质量保障体系完成生产级验证和发布治理。

这种定位降低了系统的通用性，但换来了更强的生产可控性。当然，这套方案也有明确边界：多轮修复后仍有少量场景需要人工介入，通常来自字段含义需要结合业务规则判断、样例数据无法覆盖线上长尾结构等情况。解释执行相比静态编译也存在性能上限，更适合输入输出边界清晰、可快速验证、可配置化发布的结果展现逻辑；对于复杂计算、长链路外部调用或强状态依赖的任务，仍需要通过逻辑拆分、缓存预热，或回退到静态服务实现来控制成本。随着使用规模扩大，修复记忆随使用增长也需要持续治理，通过去重、归并和错误模式沉淀控制上下文规模，避免历史约束过多影响模型关注重点。

3.3 总结

结合上述落地效果与实践边界，RenderFlow 的核心经验是：LLM 生成代码要进入线上交付链路，不能只依赖模型能力，还需要稳定的执行、反馈、修复和治理机制。围绕这一思路，系统沉淀出三项关键设计。

• 可执行引擎提供动态执行底座。 业务逻辑从服务代码中剥离，以配置形式动态加载并解释执行，使每次迭代从"发布服务"简化为"更新配置"。更重要的是，预览、测试和线上执行复用同一套引擎，保证模型产物能够被真实执行、被稳定验证、被快速生效。

• 质量保障体系提供工程护栏。 发布前的静态分析、预览执行和自动化回归，发布中的分阶段校验，以及上线后的效果巡查和稳定性监控，共同将模型生成的不确定性约束在可验证、可观测、可分阶段发布、可回退的范围内。

• 多轮修复机制推动结果持续收敛。 通过 Coder / Reviewer 双角色协作、修复约束持续累积和 Memory 经验复用，系统将一次性生成升级为"生成 → 执行 → 反馈 → 再生成"的 Agentic 修复闭环，减少人工兜底并降低同类问题重复出现的概率。

从 Agent Harness 的视角看，RenderFlow 的价值在于把模型、执行环境、反馈、记忆和治理机制组织成一个完整闭环：模型负责生成，执行引擎负责验证，错误反馈驱动修复，质量护栏控制风险，配置系统完成发布和回滚。正是这套闭环，使 RenderFlow 既保留了 LLM 生成逻辑的灵活性，又将不确定的模型输出转化为可执行、可验证、可修复、可治理的线上交付能力，从而在近千个场景的规模下，将单场景的交付周期压缩到分钟级，同时维持搜索线上服务的稳定性。

​