QQ飞车代理研发改造流程中的循环工程

在 AI 辅助研发从“提示词工程”走向“系统编排”的转型中，如何让 agent 的循环真正沉淀为可复用的工程能力，是当前一线研发团队面临的核心命题。 本文整理自腾讯高级后台开发工程师、项目组 Agent 落地负责人任磊达在 AICon 全球人工智能开发与应用大会 2026（深圳站）的分享《QQ 飞车 Agentic 研发转型过程中的Loop Engineering》。他基于每月约三百亿 token 的密集使用经验，在分享中系统阐述了他对 loop engineering 的理解与实践框架。他从 hook 级循环、CI 级循环、工作流结构化拆分到团队层面的 graph engineering，逐步展开了一套从“让 agent 做具体事”到“让 agent 学会如何做事”的迭代方法论。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 从 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 我们的工作流本身的，希望一部分东西能给大家思考和借鉴。 Loop 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 的操作