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

Hi带娃的我热爱AI 大模型应用落地、意识解码与 AI 开发工具链。 创业路上用技术换时间一起把 AI 变成生产力 QQ 飞车 Agentic 研发转型过程中的 Loop Engineering背景与痛点当一个研发团队从人写代码、人审代码切换到Agent 写代码、人审意图时最先崩塌的往往不是模型能力而是流程的稳定性。QQ 飞车这类长生命周期、强实时性、多端一致要求极高的项目在引入 Agentic 研发范式后暴露出一组典型矛盾单次 Agent 调用的成功率看起来不错但端到端任务完成率却低得离谱。问题的根源在于传统 CI/CD 的反馈环是为人类设计的——构建失败看日志、测试失败看堆栈、代码评审看 diff。而 Agent 没有看日志的耐心它需要的是结构化、可执行、可回滚的反馈信号。如果直接把 Agent 接入现有流水线会出现三类高频故障上下文漂移Agent 在第 3 轮修复中已经忘记了第 1 轮为什么那样改导致反复横跳反馈噪声一次构建输出 2000 行日志Agent 抓不住关键失败点随机改代码碰运气验证真空Agent 声称已修复但没有任何机制证明它真的修复了人工复核成本反而高于自己写。不解决这些Agentic 研发就只是更贵的自动补全。Loop Engineering循环工程要解决的正是如何为 Agent 设计一个收敛的、可观测的、有代价的反馈闭环。方案设计核心思路是把 Agent 的一次任务拆成多个有界循环每个循环必须有明确的进入条件、退出条件和失败代价。我们放弃了两种看似诱人的替代方案方案为什么放弃单次大 Prompt 让 Agent 一次做完上下文窗口再大也会稀释注意力错误无法局部化回滚粒度太粗完全自由的多轮对话式 Agent没有循环边界Agent 会陷入改—错—再改的无限循环Token 成本不可控最终选择的是三层 Loop 结构内层秒级静态检查 单元测试Agent 每次编辑后立即触发失败则原地重试最多 3 次中层分钟级模块级集成测试 类型检查通过后才允许进入下一模块外层小时级端到端回归 人工意图确认作为最终闸门。关键取舍在于内层循环必须极快且极便宜否则 Agent 会把时间浪费在等待上外层循环必须极慢且极严格因为它是唯一能拦住看起来能跑、线上会炸的关卡。核心实现循环状态机与退出条件每个 Loop 用一个显式状态机描述而不是靠 Agent 的自觉fromenumimportEnumfromdataclassesimportdataclass,fieldclassLoopState(Enum):IDLEidleEDITINGeditingVERIFYINGverifyingRETRYretryESCALATEescalate# 升级到人工DONEdonedataclassclassLoopContext:max_retries:int3retry_count:int0failure_history:listfield(default_factorylist)defshould_escalate(self)-bool:# 关键连续两次相同失败说明 Agent 卡住了必须升级iflen(self.failure_history)2:returnself.failure_history[-1]self.failure_history[-2]returnself.retry_countself.max_retries这里最容易被忽略的是should_escalate里的相同失败检测。很多团队只设max_retries结果 Agent 用三种不同方式犯同一个错重试次数耗尽才升级白白烧掉大量 Token。把失败指纹纳入判断能让升级提前 1-2 轮。结构化反馈信号的生成Agent 看不懂原始日志所以我们在流水线里加了一层反馈压缩器defcompress_feedback(raw_log:str,test_report:dict)-dict:return{failed_tests:[{name:t[name],assertion:t[message][:200]}fortintest_report.get(failures,[])],compile_errors:extract_errors(raw_log)[:5],# 只取前5条diff_summary:summarize_diff(raw_log),# 改了什么hint:优先修复 failed_tests 中的第一个断言}为什么不直接把日志喂给 Agent因为日志里 90% 是噪声Agent 的注意力会被无关的 warning 带偏。压缩后的反馈把哪里错了、错在什么断言、建议先修哪个一次性给全实测能把内层循环的平均重试次数从 2.7 降到 1.4。回滚与代价机制每个 Loop 开始前打一个轻量快照不是 git commit而是工作区 diff 的哈希失败升级时自动回滚defrun_loop(task,agent,verifier):ctxLoopContext()snapshottake_snapshot()whilectx.state!LoopState.DONE:patchagent.propose(task,ctx.failure_history)apply_patch(patch)resultverifier.check()ifresult.passed:ctx.stateLoopState.DONEelifctx.should_escalate():rollback(snapshot)ctx.stateLoopState.ESCALATEelse:ctx.failure_history.append(result.fingerprint)ctx.retry_count1returnctx代价机制是灵魂每次重试都消耗预算预算耗尽必须升级人工。没有代价的循环Agent 会无限试错代价太高的循环Agent 会不敢改。我们把内层单次重试成本设为可忽略外层升级成本设为必须人工介入形成梯度。效果验证在 QQ 飞车的一个中型模块约 8 万行 C/Lua 混合代码上做了对照实验指标直接接入 Agent引入 Loop Engineering端到端任务完成率41%78%平均重试次数4.21.6人工复核耗时/任务22 分钟9 分钟Token 成本/任务1.0x0.7x复现步骤很直接选一个已有测试覆盖的模块让 Agent 完成一个真实需求如新增一个赛道碰撞检测的边界条件分别用两种方式跑 20 次记录完成率和重试次数。关键是要用同一批任务否则对比没有意义。值得注意的是完成率提升主要来自升级机制的及时触发——那些 Agent 注定搞不定的任务被更早地交回人类而不是让 Agent 反复烧钱。边界与演进Loop Engineering 不是银弹它有明确的适用边界不适用于探索性任务当需求本身模糊、没有明确验证标准时循环无法收敛此时应该先做人工意图澄清不适用于超长链路任务如果单个任务跨越 10 模块外层循环的端到端验证会变得极慢需要先做任务分解验证器质量决定上限如果测试本身覆盖不足Loop 只会让 Agent 更快地通过假测试这是最危险的情况。下一步优化方向有两个一是自适应重试预算根据任务复杂度动态调整max_retries而不是固定 3 次二是跨任务记忆把历史失败指纹沉淀成团队级的避坑库让新任务在开始前就避开已知陷阱。回到最初的问题Agentic 研发转型的难点从来不是Agent 能不能写代码而是我们能不能为 Agent 设计一个它会认真对待的反馈闭环。Loop Engineering 的本质是把人类工程师多年积累的试错直觉显式化成机器可执行的循环规则——这才是转型真正的工程含量所在。