作者｜任磊达，腾讯高级后台开发工程师、项目组 Agent 落地负责人

编辑｜宇琪

审核｜罗燕珊

策划｜AICon 全球人工智能开发与应用大会

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

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

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

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

今天讲 loop，我觉得这个东西很值得在不同环境下进行交流和学习，因为 loop 的目标是解决具体场景的具体问题，而且在不同环境下有很大的类似性。

三月份刚聊 harness engineering 的时候，我有一个困惑：什么是 harness engineering？它听起来很抽象。我当时的想法是，它的目标可能有两个：第一是在工作时间让并发尽量高，可以同时操控五到十个 agent 一起工作；第二是在非工作时间，比如我们睡觉的时候，它能继续工作。最近一个月我大概消耗了三百亿 token，在这个量级下，主要还是工作时间并发度的提高在起作用，所以首先讲 loop engineering，非工作时间这一块还没有真正 loop 起来，需要跟大家进一步探讨。

回到今天，大家更关注 ROI 这一块，而不是怎么烧 token、怎么降低 token 消耗这种 KPI 叙事。为什么需要 loop？我觉得它跟自动驾驶很像。我作为一个考了驾照的人，不用自动驾驶也可以把车开在路上，那为什么要自动驾驶？其实是希望通过技术手段减轻个人思维认知负担，提高整体质量和能力。

loop 这个东西跟 harness 的区别是，loop 是明确目标、锚定目标的。它是用来把模型或者 agent 的概率性想象力，通过迭代的形式，变成一个真实的业务产出。另一个需要 build 的是我们跟 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 这个东西，去思考 evaluation 的效果以及它在真实研发场景中怎么样，是很难把额外的东西摆正的。

右边是今年年初的一个科研自动化系统，这给了我启发。它通过非常结构化的形式自动化论文产出。不说论文本身质量，它通过清晰的结构让整个论文产出效率和稳定性能几百小时稳定产出，而且成本相对低。所以今天我想跟大家交流的是我们是怎么 loop 我们的工作流本身的，希望一部分东西能给大家思考和借鉴。

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

第一个是 hook 级别的 loop，我比较想聊 custom-inter 这块，比如日志格式，在 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 时做耗时更长的 linter，让问题解决。但是，agent 现在已经习惯性跳过检查，目前没有特别好的办法，只能从 agent 的 MD 文档上面约束。

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

3Loop 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 触发，把 linter 失败信息给 agent，agent 会自动修这些失败信息，再重新推送到当前分支，重新触发流水线，相当于重新跑一次 linter，让它变绿。完成了一个 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 协同时，让注意力投入越来越少，让协同越来越清晰。就像我最初说的科研自动化系统一样，如果我们能 build 一个可以信任的结构，就只需要在结构里面做非常小、非常集中的关注点的事情，产出质量肯定更高，这和 agent 的生产管理是一样的。

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

4Loop 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 框架，让整个团队用。这样会导致一个问题：可能是一个同学或少部分同学去构建 SDD 框架，更多同学去用，但这并不符合整个 agent 时代。我们希望每一个同学都在 build loop 这个过程，不能让每个同学都只用一套工作流而参与不到整套工作流的 loop 和提升。所以我们的暴论是希望做场景化的 SDD，跟需求绑定。每个需求可以有自己的一套 SDD，成本很低，但让每个同学都有参与度。这里举的例子是 UDC 场景的 SDD，它掌握的点和直接用 SDD 差不多，但可以让每个同学有更多参与度参与到 loop 里，再回灌到底层 SDD 的组件化框架里面。

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

6踩坑与反思

从 build loop 角度讲一下我们在 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 量特别异常，烧了五亿、十亿 token。深度分析之后，发现在我们那个上下文过多时，会导致推理出来的 skill fork 不断递归。因为 agent 本身有幻觉，到那个节点递归之后，就会一直在那里循环烧 token，什么都没有实现。

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

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

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

会议推荐