QQ飞车Agentic研发：用Loop Engineering把同类问题只犯一次

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

本文基于 AICon 全球人工智能开发与应用大会 2026（深圳站）上的分享《QQ 飞车 Agentic 研发转型过程中的 Loop Engineering》整理。分享者每月大约消耗三百亿 token，围绕这一量级下的真实使用经验，系统拆解了 loop engineering 的理解与实践框架：从 hook 级循环、CI 级循环，到工作流的结构化拆分，再到团队层面的 graph engineering，路径的核心是从“让 agent 做具体事”走向“让 agent 学会如何做事”。

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

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

今天讲 loop，我觉得这个话题很适合在不同环境下交流和学习，因为 loop 解决的是具体场景中的具体问题，而且不同环境之间有很强的相似性。

三月份刚开始聊 harness engineering 的时候，我也有点困惑：它到底指什么？确实很抽象。当时我理解它大概有两个目标：一是在工作时间内把并发尽量拉高，可以同时操控五到十个 agent 一起工作；二是在非工作时间，比如我们睡觉时，它还能继续运转。最近一个月我大概消耗了三百亿 token，在这个量级下，主要收益来自工作时间并发度的提升。所以今天先聊 loop engineering；非工作时间这一块还没有真正 loop 起来，需要和大家进一步探讨。

回到当前更受关注的 ROI，而不是单纯烧 token、降 token 消耗的 KPI 叙事。为什么需要 loop？我觉得它和自动驾驶很相似。我是有驾照的人，不用自动驾驶也可以把车开到路上，那为什么还要自动驾驶？本质上是想通过技术手段降低个人的认知负担，同时提升整体质量和能力上限。

loop 和 harness 的区别在于，loop 有明确目标、锚定目标。它是把模型或 agent 的概率性想象力，通过迭代形式转化为真实业务产出的过程。另一个需要建设的是我们和 agent 的交互形式：什么时候应该 human in the loop、human on the loop、human out of the loop，什么时候该 closed loop，什么时候该 open loop。

六月份刚听到 loop engineering 这个词时，我也有疑惑。当时 Claude Code 创始人 Boris Cherny 说自己不再去 prompt agent，只写 loop。过了几个月，我慢慢体会到 prompt agent 和写 loop 的最大区别：prompt agent 更聚焦解决具体问题，比如我们会要求 agent：“这段代码写得太长了，帮我精简一点。”而 writing loop 是要求 agent：“你怎么没发现这段代码写得太长了？下次应该主动去发现，应该主动提问：这段代码有哪些优化空间？”这样我们的 idea 就能通过迭代沉淀到 loop 里，让同类问题只犯一次，也就是“圣人不二过”的状态。

技术上，吴恩达老师提出过三层划分，更偏技术视角，从单点循环、任务编排到多步工作流，做了三层 loop 的划分。我从工程实践角度出发，也有四层：第一层是 hook 级别，第二层是 CI 级别，这两层和吴恩达老师的划分比较接近；第三层是对工作结构的结构化拆分；第四层是组织团队的提效。如果从技术角度翻译，loop 很像循环、重复工作，像定时任务每天干一件事。但如果只是一个没有意义、没有思考、没有经验的重复，并不能带来价值。所以 loop 在我的定义里是一个迭代。

定义迭代，在我们工作场景里首先要锚定到底迭代什么，这一点特别重要。左边是我的一些想法：第一，如果为了 loop 一些 ROI，让 skill 的 token 减少 20% 也能工作，但当模型越来越快，这真的是我们业务场景需要迭代的吗？第二，如果需要迭代我们自己的 agent，我们是业务开发，但 agent 越来越多，包括 coding agent 越来越多，这时迭代的 ROI 是否足够？第三，有点暴论：我们可以写一套 skill evaluation，评测 skill 的表现和各项指标，包括它在长期演进中的效果。但在实际研发过程中会发现，我们使用的 agent 和 skill 层级已经到了上百个级别，如果要去 loop 这个评测、去思考它在真实研发场景中的表现，很难把额外的东西摆正。

右边是今年年初看到的一个科研自动化系统，它给了我不小启发。它通过非常结构化的形式自动产出论文。先不评价论文本身质量，它用清晰的结构让论文产出效率和稳定性在几百小时内保持稳定，而且成本相对较低。所以今天我想交流的是：我们怎么 loop 自己的工作流本身。希望能给一部分内容带来思考和借鉴。

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

第一个是 hook 级别的 loop。我比较想聊 custom-linter 这块，尤其是日志格式。在 AI 时代，AI 对日志的想象力非常大，什么都敢写，什么格式都敢写。所以我们最开始做了一个日志的 custom-linter，它是一个基于 LLM 的 linter 插件，实现起来很简单，让 agent 自己去参考文档写就行了。为什么用 linter 而不只是 rules？因为 rules 仍然在追求概率性模型，要求模型别犯错，本质是一种“许愿”。但 linter 毕竟是确定性规则，可以通过迭代让错误越来越少，能力越来越稳定。这件事一天就可以 vibe coding 出来，配置在 CI 流水线和本地开发实践中。

一个 linter 主要在两个阶段生效。第一是在 agent 写完文件之后立刻生效，触发 linter，通过增量文件 diff 报错，把上下文回流给 agent，让 agent 拿到报错信息直接修复，执行自愈能力。第二是在 pre commit 阶段，有 git hook 触发。

这里有几个坑值得介绍。第一个坑：随着大家使用 agent 越来越多，各种原因导致 CLI 兼容性问题，需要做适配。第二是 linter 本身有时不支持并发，需要管控。第三是超时逻辑需要放过，有时候可以在这一层更柔性一些。这一层柔性之后，第二次提交时再做相对耗时更长的 linter，相当于在 git commit 时做耗时更长的检查，让问题被解决。不过，agent 现在已经有习惯性跳过检查的情况，目前没有特别好的办法，只能从 agent 的 Markdown 文档层面施加约束。

这个 linter 的设计逻辑，其实反映我们对 agent 行为管理的一个核心判断：不能靠“许愿”来约束模型输出，而要依赖确定性的规则回路。当 linter 在写文件后立即触发，它本质上是在 agent 的操作闭环里插入了一个确定性校验节点，这个节点不属于模型的概率输出，而是工程硬约束。agent 拿到报错信息后自己修复，就形成了一个最小单元的 closed loop——写、检查、反馈、修复，人在其中不需要介入。

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

第二层是 CI 的 loop。我们在 agent 研发转型中有一个很大的变化，就是从 SVN 的研发模式切到 Git 研发模式。因为 SVN 模式对 agent 的输入输出并不信任，没有一个很好的阶段去做管控和让 human loop 参与。因此我们在 CI 的 MR 里做了很多工作。

流程大概是：推送特性分支后，通过 CI 的 hook 事件自动创建 MR。创建 MR 后有两条并行流水线：上面是 linter 的红灯自愈，也就是 linter 报错后自动尝试修复；下面是自动 review 流程。后面再自动修复、合入。整个过程是一个注意力管理过程，相当于把人的注意力从重复事务中不断抽离。像我开场说的，我们使用自动驾驶的原因，就是把重复粗糙的事交给机器，而机器可能做得比我们更好。

linter 分为三种：第一种是开源的官方 linter；第二种是插件型 linter，比如刚才说的 custom-linter，它在开源 linter 里以插件化方式植入我们的规则；第三种是前两种都不支持时自研 linter。linter 失败后会调起一个自愈流程，让 failStages 触发，把失败信息给 agent，agent 自动修复这些失败项，再重新推送到当前分支，重新触发流水线，相当于重跑一次 linter，让它变绿。这样就和 agent 一起完成了这些重复粗糙工作的修复。

我们的 auto approve 流程量不多。auto approve 相当于把一定权限授权给 coding agent 和 AI verify agent，它一定是规则化的。我们很明确哪些东西从来不需要 review，就放进 auto approve。这样在人不需要关注的情况下，自动建请求、自动放行、自动合入，让整个 Git 研发流程像之前 SVN 一样，基本不需要人的参与和阻塞，从而大幅提高效率。

最后想交流 CI 里的评论闭环。当 agent 产出的代码越来越多，一个 MR 有上千行甚至上万行时，人的注意力会很难管理：到底应该 review 什么？这种最佳实践一定要 loop 到研发流程循环里。首先基于规则，命中规则的内容通过正则形式触发提问；触发提问后，相当于 MR/PR 的一条评论，收到 hook 反馈后会自动回答。另外还可以做一个反向 loop，当回答不对时再 loop。实际举例：@OCI 对 CI 说，这个 MR，你需要把这个文档总结成一句话。第一是基于规则的行业提问；第二是调 agent 完成上面的提问并提供反馈入口，基于反馈再 loop 整个 review 流程，让它越来越好。

后面两项是脏活自动解决。切到 Git 流程时，很多 issue 提出来后因为没有 PM 参与，常常没有流转，所以需要定时 loop 检查和修复。冲突也一样：当 agent 提交代码越多，人的 review 精力不够，基本就会产生冲突，我们也会定时修复和合入。这一层的核心逻辑是把人从“发现者”角色中解放出来，让机器成为第一道防线。linter 报错后自动修、review 提问后自动答、issue 和冲突定时清，这些都是在 CI 流水线框架内构建的小型闭环。每个闭环都有明确触发条件、执行体和验收标准，所以可以被观测、被迭代。

之前在业务安全团队工作积累下来的经验，就是把问题拆成事前、事中、事后结构，让结构更清晰，从而提高并发数量。其实就是在和 agent 协同时，让注意力投入越来越少，让协同越来越清晰。就像开头说的科研自动化系统一样，如果我们能构建一个可以信任的结构，就只需要在结构里做非常小、非常集中的关注点，产出质量自然更高。这和 agent 的生产管理是一样的。

我们到底是要 build 一个 agent，还是要用好一个 agent？harness 是帮我们把模型能力提供出来、让我们能用的能力。在实际业务场景中，我们并不是 build agent/coding agent 团队。如果一直去学习或只关注 agent 的 harness，我们的 loop 是转不起来的，因为我们没有反馈，也没有 KPI。所以我们更关注项目层的 harness，更关注从模型里借鉴的很多东西，比如 max turns、知识库、目标成本、稳定合规，但注意力和反馈循环是不同的。

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

怎么建立项目的 harness？第一个是工作流。参考业务安全里常见的拆分架构，把工作流拆为事前、事中、事后，不同阶段我们和 agent 的交互方式完全不一样。事前阶段输入可能是一个模糊需求，目标是澄清成结构化文档；事中阶段让 agent 自主尝试，甚至在人完全不参与的情况下产出和审查 PR/MR；事后则是审查模式。

这里有一条很严格的纪律：人和 agent 的交互或评论，一定要放在事后，不要放在事中。因为事中如果要和 agent 交互并且 loop 起来，我们必须去读 agent 的日志和 CLI 文件，很难快速验证它是否真的循环起来了。但如果事后在 PR 里评论，就相当于把信息存进了数据库，包括解决评论时它也会自然 loop 起来。loop 起来之后，我们可以观察它是否真的解决了评论，以及是否顺带修复了行数相关的问题。

事前要把模糊的东西变成清晰结构化，让 agent 成功的概率更高。这里参考了 Superpowers·Brainstorm 和 Mattpott·Grill-me 两套方法，核心是苏格拉底式提问，不断追问，直到它认为对需求理解没有问题了。我们也要迭代自己的实现，不能直接照搬到项目。比如最近一个需求问了我两百多个问题才结束，我们要思考：怎么把两百多个问题用更好的交互形态提出来？是不是在企业微信甚至微信上提问，回答会更有效率、更容易迭代？这也是为什么现在许愿式的外部 coding 产物还不能上生产环境：我们仍然需要把边界约束、验收标准和风险都跟它明确清楚。

拆分好文档之后，事中的第一个阶段需要想清楚一个问题。这里从业务安全借鉴了一个概念，叫“查杀分离”：查一个黑客黑产行为和打击一个黑产行为，尽量使用不同的观测层级和指标。放到现在聊 Vibe Coding 的场景里，就是验证阶段会花很多时间写单测、拉高单测覆盖率。覆盖率驱动的验证，它的 loop KPI 就是覆盖率。但问题在于：把测试拉上去之后，它相当于给代码上了一把锁，我们却不知道这些测试到底有没有用、究竟在测什么。我们已经 review 代码很累，再 review 测试精力更弱。只有当我们改代码时，这些测试会一而再再而三地出来阻挠，不让我们更快地修改。它更像负担，甚至债务。所以更需要风险驱动。怎么做到风险驱动？一定要在事中的第一个阶段，把拆分好的结构化文档独立交给 agent，让它做测试策略和测试方案实现。参考机器学习中训练集和验证集分离、业务安全中的常态分离，避免 agent 自写自测的问题，这也有一系列论文研究依据。

第二个是事中的结构化升级。三月份我的并发度大概是五个工作区左右，到七八月已经到了十几二十个并发度。之前也尝试过很多手段，后来发现并发度的提升一定来自更清晰的结构。当通过 build loop 让结构更清晰，我们能信任这个结构、信任底层 harness 时，并发度就会自然提高。右边是我当前需求的工作台，我们提倡为每个需求建一个工作台，对不同目录进行并发实现。并发有两种实现方式。第一种是通过多目录和多分支的形式，比较学术、科学，但问题在于冲突会在合线时集中爆发，而且很大，大部分时间会花在合线上。现在随着模型能力越来越强，面向三个月甚至六个月以后的模型，我们的思考是：尝试让模型甚至 agent 本身在同一个工作区里修改耦合度相对较高的文件，这样它会在修改的同时修复冲突，人在其中的介入也相对更少。

AI 写了这么多代码，人怎么 review？分享一下我的观点。左边是许愿式 review：拉起很多种模型、很多个 agent 并发拉很多次，让它们深度 review 代码。但这是实验式实现，会产生很大的信息噪声，我们是否能相信它的产出、能否有效归纳它的输出？并不确定。右边是更结构化的实现：针对不同角度分配不同的子 agent 进行分析，再合并结论。更关键的还是前面说的，把 review 输出与人的 review 结合，合入到我们自己的 harness 里，回灌后 skill、rules、memory 都会留在工作区里，让整个 loop 越来越好用。

另外还有一个文档问题。写代码 Vibe Coding 时，agent 写了上千行之后，人的认知负担很大。有时 agent 没有把文档顺便带上来，这个 MR 看起来就很累。所以我在流水线里加了一个 linter：当改动量大于一定阈值时，自动调整文档。相当于前面说的 linter 自愈流程：当 linter 发现改动量足够大但文档不够全时，就补充文档，保证认知是渐进式的，可以先看文档了解这个 MR 要做什么，再看细节。这个 linter 对“文档和代码永远对不齐”的问题也有借鉴意义。

怎么判断这一套 loop 在变好？loop 本身是一个 KPI、OKR，一定要有一个指标来观察。无论是观测指标还是真实 benchmark，我们这里更多是观测指标。首先在事后，我们不断把 MR 评论回灌到 memory 和记忆里，MR 评论数会相对变少，但不可能绝对归零。第二，重复评论的占比会越来越少，追求“不二过”。如果 loop 之后还在不断犯同样错误，说明 loop 没有生效。第三，事前澄清耗时也会慢慢降低，因为事后回灌会让 agent 更多读到我们的习惯和信息。

总结一下：人其实只在事前做选择题，事后做 review 和评论。当人的注意力在很大程度上被集中和释放后，让 agent 承担更多工作，我们能构建信任的 loop，并发度自然提高。也就是事前是决策模式，事中是完全不管、让它 auto 的模式，事后是审查模式。这三个指标的设定，本质上是把人从“执行者”变成“决策者”和“审查者”的角色转换具象化。MR 评论数下降，说明 agent 在逐渐吸收我们的偏好和习惯；重复评论占比下降，说明记忆系统在起作用；澄清耗时降低，说明事前提问在变得更精准。只有这三个指标同步向好，才能说 loop 真正在迭代，而不是空转。

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

最后想聊 graph engineering。这个很新，我聊的不一定对。右边其实还不是 graph engineering，只是我的工作台。如果我把这样一个工作台 loop 起来，会看到很多任务依赖。团队协作也类似，不同 KPI 之间也有不同依赖。左边是我理解中 graph engineering 的必要性和重要性：我们个人的 loop 往往是尝试解决一类问题，比如自动修冲突。如果我把修冲突这个 loop build 好了，团队其他成员再 deploy 这个修冲突 loop，并没有提高整个团队产出，它更像复制了我的 loop，只是一个 exercise，而不是 engineering product。团队 loop 和组织提效，更需要 graph engineering 的编排，让整个团队享受到 AI 技术红利。提效团队时，也需要更多组织或管理层面的手段。

第一个是前面说的，我们提倡为每一个需求构建一个工作台，因为构建工作台成本很低，却能大幅降低成本、提高并发度。但如果每个需求都有独立工作台，就变成了一个烟囱。烟囱越来越多时，能力很难复用，很多基础能力会重复建设。上周 DeepSeek harness 的插件化给了我们启发：把工作台里的东西重构成插件。用的时候不一定是直接复用，因为直接复用这个 harness 会带来 UI 混乱。我们可以 @ 一下 agent，说“你借鉴一下另一个同学写的这个工作台插件，截个图给他”，它就会自然地把东西借鉴过来。

第二个是我个人的暴论：SDD 是 context engineering 的最大实践，因为它管理好了 agent 的上下文。但 SDD 的常规实践是引入一套框架，甚至构建一套自研 SDD 框架，让整个团队来用。这样会导致一个问题：可能是一个或少数同学去构建 SDD 框架，更多同学只是使用者，这并不符合整个 agent 时代的要求。我们希望每个同学都在 build loop 这个过程中，不能让每个同学都只用一套工作流而参与不到整套工作流的 loop 和提升。所以我们的暴论是：做场景化的 SDD，与需求绑定。每个需求可以有自己的一套 SDD，成本很低，但能让每个同学都有参与度。这里举的例子是 UDC 场景的 SDD，它掌握的点和直接用 SDD 差不多，但可以让每个同学更有参与感地进入 loop，再回灌到底层 SDD 的组件化框架里。

这一层的逻辑，是把“个人能力”转化为“组织能力”。个人 build 的 loop，如果不经过 graph 化编排和插件化重构，就只是一个私有脚本。只有把它抽象为团队的 infrastructure，才能让其他人的 agent 在自己的工作台里调用、借鉴、回灌。但这种复用不是简单的“直接引用”，而是通过 agent 的参考能力实现“软复用”，避免 UI 混乱。SDD 场景化的思路，则是在另一个维度上做平衡：既要保持个人参与度，又要沉淀到底层组件化框架中，避免个人 SDD 变成臃肿的烟囱。

6. 踩坑与反思

从 build loop 的角度，分享几个 open loop 实践中的踩坑。第一个是每个同学都做了 SDD，SDD 在不断 MR 流程中回灌，把记忆和踩坑记录了下来。然后发现，每个人自己需求的 SDD 会越来越大。到结束 token 消耗统计时，发现两百 k 上下文已经装不下了。因为很多基础模型对上下文长度仍然有要求，高级模型在 smart 区间也需要相对短的上下文。我们只能对它进一步拆分。它其实是一个 SDD，是一个 skill 作为入口。做一个二级路由：先只暴露一个二级路由，在做不同行为时再路由到第二级 index，然后再路由到第三层。这样可以把整个上下文从一个需求需要六百 k 降到一百 k 左右。

第二个是刚才聊 SDD 时顺带遇到的 loop 问题。我们 build SDD 插件时，年初 sub agent 概念很火，所以遇到点事就想加个 sub agent。skill 里也加一个 fork，加 fork 就等于起了个 sub agent。起了 sub agent 后，我去 review，发现之前有一天 token 消耗量特别异常，烧了五亿、十亿 token。深度分析后发现，当上下文过多时，推理出来的 skill fork 会不断递归。因为 agent 本身有幻觉，到那个递归节点后，就会一直循环烧 token，什么都没实现。

第三个是一个简单需求的分享。一个数据转换需求，把一种存储的数据转换成另一种存储需要的数据，本身很简单。但给它设了很多 goal，说“你好好实现”。结果因为思考深度可能过高，一天就写出了四万行代码。这个 loop 很有意思：在 MR 里，前面说的 review agent 会提很多建议，这些建议更多基于基础设施和组件的角度，导致防御性扩张，比如可观测性、原则性扩张。自动解决这些 MR 评论时，又会继续修复防御性扩张。因为 review 更多针对 MR 本身而不是 commit，导致这个 loop 越来越大。最后一天滚出了四万行代码、两百个评论、二十七轮评审，这个 MR 只能直接关掉。所以我们在做 loop 之前，可能要想清楚：它是一个循环，还是一个有界的循环，closed loop？如果能把它变成有界循环，ROI 会有很大提升。

最后做展望。业界一些 loop engineering 实践中，我觉得参考意义比较大的是 Open Claw 和 Hermes。Open Claw 更侧重定时触发和插件化记忆机制；后面的 cloud tag commerce 更多是结构化形式，让 loop 有反馈，比如达到一定轮数时触发；工具调用量过多时，认为任务过于复杂，需要沉淀 skill；人主动打断时，也认为需要沉淀 skill；还包括对 skill 本身的遗忘和淘汰，避免上下文过度膨胀。这里主要想聊递归自我进化。调研一圈发现，递归自我进化这个概念，除了模型本身角度，更多是基建本身的渐进式提升，从而可以用先前的模型训练后面的模型。从工程角度，我们更多可以参考的还是上一页的两个：Open Claw 和 Hermes。它是一种结构化机制，让我们能通过信任结构本身，让工程的 harness 越来越好。举个例子，我们能不能定时写个任务，回顾当天的 agent 日志，找出重复踩的坑，自动去修？这里面也少不了后面的 loop。

最后还想聊超级个体是否有价值。我从头到尾都在聊一个概念，就是信任。超级个体本身的价值，我觉得更多还是在“信任”这个词上。我们去信任一个团队的难度，要比信任一个超级个体的难度更高。我们 build loop 本身，也是在 build 一个信任过程。当我们能信任这个结构、信任它的实现时，loop 的产能和 ROI 才能真正摆正。