QQ 飞车 Agentic 研发转型过程中的 Loop Engineering

在 AI 辅助研发从“提示词工程”向“系统编排”转型的当下，如何让 Agent 的循环真正沉淀为可复用的工程能力，成为一线研发团队的核心命题。

本文整理自腾讯高级后台开发工程师、项目组 Agent 落地负责人任磊达在 AICon 全球人工智能开发与应用大会 2026（深圳站）的分享《QQ 飞车 Agentic 研发转型过程中的 Loop Engineering》。基于每月约三百亿 Token 的密集使用经验，他系统阐述了对 Loop Engineering 的理解与实践框架，从 Hook 级循环、CI 级循环、工作流结构化拆分到团队层面的 Graph Engineering，逐步展开了一套从“让 Agent 做具体事”到“让 Agent 学会如何做事”的迭代方法论。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

从 Harness 到 Loop：为什么需要迭代系统

Loop 的目标是解决具体场景的具体问题，在不同环境下具有高度相似性。与 Harness Engineering 追求高并发和全天候运行不同，Loop Engineering 更关注 ROI 和业务产出。其核心在于将模型或 Agent 的概率性想象力，通过迭代转化为确定的业务成果，并明确 Human-in-the-loop、Human-on-the-loop 或 Closed-loop 的交互边界。

Prompt Agent 聚焦于解决单次具体问题，而 Writing Loop 则致力于将解决问题的思路沉淀下来，避免重复犯错，实现“圣人不二过”。从工程实践角度，可将 Loop 划分为四个层级：Hook 级别、CI 级别、工作流结构化拆分以及组织团队提效。Loop 并非无意义的重复，而是基于经验积累的迭代。

定义迭代需锚定目标。相比单纯降低 Token 消耗，更应关注业务场景下的实际效能。参考科研自动化系统的结构化产出模式，通过清晰的结构实现高效、稳定且低成本的持续产出，是 Loop WorkFlow 的核心借鉴点。

Loop Agent Context：自定义 Linter 的自愈实践

第一层是 Hook 级别的 Loop，以 Custom Linter 为例。针对 AI 生成代码日志格式混乱的问题，引入基于 LLM 的 Linter 插件。相较于 Rules 的概率性约束，Linter 提供确定性规则，通过迭代不断减少错误。该 Linter 在两个阶段生效：一是 Agent 写完文件后立刻触发，通过增量 Diff 报错并回流上下文，实现 Agent 自愈；二是 Pre-commit 阶段通过 Git Hook 触发。

实践中需注意 CLI 兼容性适配、Linter 并发管控及超时逻辑柔性处理。核心逻辑是在 Agent 操作闭环中插入确定性校验节点，形成“写-检查-反馈-修复”的最小 Closed Loop，无需人工介入即可实现自我修正。

Loop CI：MR 流程中的注意力管理

第二层是 CI 级别的 Loop。团队从 SVN 切换至 Git 研发模式，旨在通过 MR 流程更好地管控 Agent 输入输出并引入 Human Loop。流程包括：推送特性分支自动创建 MR，并行执行 Linter 红灯自愈和自动 Review。Linter 失败后触发自愈流程，Agent 自动修复并重新推送流水线，直至变绿。

Linter 分为开源官方、插件化定制及自研三类。对于明确无需 Review 的内容，采用 Auto Approve 流程，实现自动建请求、放行和合入，大幅减少人工阻塞。此外，构建评论闭环：基于规则触发 MR 评论提问，Agent 自动回答并形成反馈 Loop；同时定时自动处理遗留 Issue 和代码冲突，将人从“发现者角色”解放出来，让机器成为第一道防线。

借鉴业务安全团队的事前、事中、事后拆分逻辑，构建可信任的结构化体系，使注意力投入更少，协同更清晰。

Loop WorkFlow：事前、事中、事后的拆分逻辑

建立项目 Harness 需对工作流进行结构化拆分：

• 事前：将模糊需求澄清为结构化文档。采用苏格拉底式提问，通过多轮交互确保 Agent 准确理解需求边界、验收标准和风险。
• 事中：Agent 自主尝试，实现查杀分离（测试策略与实现分离），避免自写自测带来的验证盲区。提倡为每个需求建立独立工作台，支持多目录或多分支并发。随着模型能力提升，倾向于在同一工作区内由 Agent 自行解决高饱和度文件的冲突，减少人工介入。
• 事后：审查模式。严格规定人与 Agent 的交互评论放在事后（如 PR 评论），便于存储和 Loop 回溯。Review 时采用结构化方法，分配子 Agent多角度分析，并将结果回灌至 Memory 和 Rules 中。

针对代码量增大导致的认知负担，在流水线中增加文档 Linter，当代码改动超过阈值且文档缺失时，自动补充文档，保证认知渐进式。

评估 Loop 效果的指标包括：MR 评论数下降（Agent 吸收偏好）、重复评论占比降低（记忆系统生效）、事前澄清耗时缩短（提问更精准）。人转变为决策者和审查者，Agent 承担执行工作，从而提升并发度和信任度。

团队层面的 Graph Engineering 与场景化 SDD

个人 Loop 需转化为组织能力。通过 Graph Engineering 编排团队任务依赖，避免能力孤岛。提倡为每个需求构建低成本工作台，并将其重构为插件，通过 Agent 参考能力实现“软复用”，避免 UI 混乱。

推行场景化 SDD（软件驱动开发），将 SDD 与具体需求绑定，让每位同学参与 Loop 构建并回灌至底层组件框架，平衡个人参与度与标准化。

踩坑与反思

在实践中遇到以下主要挑战：

1. 上下文膨胀：SDD 随 MR 回灌不断增大，超出模型上下文限制。解决方案是实施二级路由机制，按需加载 Index，将上下文从数百 K 降至百 K 级别。
2. 递归死循环：Sub-agent 过多且上下文复杂时，Agent 幻觉可能导致 Skill Fork 无限递归，消耗大量 Token。需严格控制 Sub-agent 的使用场景。
3. 防御性扩张：简单需求因 Review Agent 过度建议基础设施和可观测性内容，导致代码量和评审轮次激增。需设定有界循环（Bounded Loop），明确循环终止条件，提升 ROI。

未来展望参考 OpenClaw 和 Hermes 等工具，侧重定时触发、插件化记忆及结构化反馈机制，实现基建的渐进式提升。Loop Engineering 的本质是构建信任，当团队信任这套结构时，产能和 ROI 才能得到有效保障。

会议推荐