腾讯轻量云江露：LoopForge多Agent编排如何让Agent从写代码走到交付

当Agent真正嵌入企业流程，哪些活能放心交给AI？50+实战案例会给出答案。

AI的角色正在变：过去是回答问题的辅助工具，如今要理解目标、调用系统、把任务做完。Agent进入企业流程之后，真正要回答的已不是"怎么把AI做出来"，而是哪些工作能交给它、结果怎么验收、权限与成本风险怎么收住。大模型往推理、工具调用、多模态和长任务方向延伸，开发重心也从单次调用转向上下文、工具、执行环境与反馈回路的设计；Coding Agent则从代码补全，长成了能读懂代码库、跑测试、完成复杂任务的工程协作者。OpenAI、Google Cloud、Anthropic 的最新实践指向同一个结论：模型决定Agent能做什么，工程决定它能不能真正进入生产、创造价值。

2026 年 AICon 人工智能开发与应用大会·北京站已经启动，时间是 12 月 18–19 日，地点在北京新云南皇冠假日酒店。大会以探索 A 应用边界为主题，设 13 大技术专题，涵盖大模型后训练、推理优化、Agent 工程、知识工程、智能体评测与安全、自进化系统、AI 软件交付、原生架构及组织变革等方向，一线技术专家会到场讲AI技术突破和企业规模化落地的真实实践。

腾讯轻量云研发专家江露已确认参加"Agentic Software Engineering｜从代码生成到软件交付"专题，带来主题分享《从"能写代码"到"能交付"：腾讯轻量云 LoopForge 多 Agent 编排实践》。Coding Agent确实在提升代码生成效率，可一旦进入团队级交付流程，新的工程问题就冒出来了：执行步骤对不齐，实现和评审之间缺乏有效隔离，验证能力跟不上并发增长，失败之后也没有清晰的恢复路径。单次任务成功，不等于团队就有了可持续的软件交付能力。江露团队的实践显示，除了模型能力，流程约束、验证机制和人机职责划分同样左右交付结果。

为此，江露团队搭了多 Agent 交付平台 LoopForge。流程主干、节点依赖和门禁由确定性 DAG 定义，节点内的分析与执行交给 Agent，关键决策点则留人工审批。再配上可执行 SOP、实现与评审角色隔离、交付产物留存和失败重跑，原本依赖单次会话表现的执行过程，就变成了可验证、可追溯、可恢复的交付流程。

江露这次分享围绕三个递进的工程问题展开。第一，单个需求怎样按既定流程走完交付；第二，任务并发涨上来后，怎样用分层质量门禁控制变更风险；第三，交付流程怎样延伸到生产运维，形成"巡检发现—聚类建单—自动修复—验证—人工确认合入"的闭环。据江露介绍，团队基于该体系累计合入 836 个合并请求（MR），日均吞吐提升 7.8 倍，无线上故障；在 SkillHub 场景中，最近一个月完成自动修复 0 人工干预并合入的线上 Issue 超过 60 个。每个阶段的落地成果、推进路径和踩过的坑，分享里都会讲到。

江露是腾讯轻量云专家、后台研发负责人，管 DNS、Skillhub 等后台研发工作。2014 年她先后入职百度、腾讯，在腾讯做过 CVM、DNS、Skillhub 相关领域的研究和落地，拿过多项公司级奖项。眼下她关注的是 AI 在个人或组织级提效上的研究与应用。

她在本次会议的详细演讲内容如下：

演讲提纲

1. 交付困境：Agent 能写代码，为什么交付不稳

• 有四个症状：流程不可复现、自己评审自己、关键关口没人把控、过程不可追溯。还有一个误区：以为让 Agent 自由编排就够了，实际批量执行时会跳步、跑偏、中途停下。

2. 核心思路：DAG 管主干，Agent 管节点，人管签字

• 职责怎么分？流程、门禁和回退交给确定性编排，执行细节交给 Agent，最终判断交给人。整体演进是从 Human in the Loop（人盯过程）走到 Human on the Loop（工程托底，人只做确认）。

3. 阶段一 稳定交付：把团队经验变成可执行的 SOP

• 节点分四类：Agent、脚本、人工审批、子 SOP；不需要 AI 的地方就不用 AI。实现、评审、测试各用独立的上下文和模型，避免自己评审自己。节点之间靠产物交接，在途任务锁定 SOP 版本，失败后能从指定节点重跑，过程可回溯。

• 效果：累计交付 200+ 个需求与 Issue，产品和后端同学跨界合入 105+ 个前端 MR。

4. 阶段二 规模化质量：用验证门禁替代人盯

• 新瓶颈也来了：一个人能同时并发十几个任务，再靠人逐个盯，质量和吞吐没法兼得。于是设了 5 道门禁：单测与增量覆盖、Diff 缺陷挖掘、异构模型交叉审查、3 分钟分支环境加 E2E、产品体验走查。

• 效果：合入 836 个 MR，无线上故障；一次通过率 54.8%，经过门禁打回和 Agent 返工后，终态成功率达到 95.4%。踩过的坑是：一次通过率低，根源在上游需求质量，前置需求澄清门禁比加并发更有效。

阶段三的目标是主动闭环，让系统自己发现问题，而不是继续等人来提需求。

• 交付流程稳定下来之后，新瓶颈浮出水面：问题还是得靠人去发现、去建单。

• 闭环链路这样走：先巡检日志、K8s 和慢 SQL，再聚类建单，接着按缺陷修复 SOP 推进，产出 MR、测试报告和根因报告，最后由人工确认合入。

• 效果上，最近一个月有 60+ 个线上 Issue 被自动修复并合入。

听众收益

• 这套实践能让人掌握多 Agent 交付流程的设计方法：怎样划分确定性编排、Agent 自主执行和人工审批三者的职责，节点类型、角色隔离、产物交接与失败恢复各自的设计要点在哪里。

• 同时得到一份分层质量验证的参考清单，理清单测、变更审查、异构模型审查、分支环境 E2E 与产品体验走查各自负责哪部分验证，以及验证没过时怎么把问题送回修复流程。

• 还能建立一组评估交付体系的指标视角，用一次通过率、终态成功率、执行耗时、端到端耗时和项目实际使用情况来判断问题主要卡在需求与上下文、验证机制，还是人工协作环节。

想了解更多，可扫码或联系票务经理 18514549229 咨询。