👋 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):IDLE="idle"EDITING="editing"VERIFYING="verifying"RETRY="retry"ESCALATE="escalate"# 升级到人工DONE="done"@dataclassclassLoopContext:max_retries:int=3retry_count:int=0failure_history:list=field(default_factory=list)defshould_escalate(self)->bool:# 关键：连续两次相同失败，说明 Agent 卡住了，必须升级iflen(self.failure_history)>=2:returnself.failure_history[-1]==self.failure_history[-2]returnself.retry_count>=self.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):ctx=LoopContext()snapshot=take_snapshot()whilectx.state!=LoopState.DONE:patch=agent.propose(task,ctx.failure_history)apply_patch(patch)result=verifier.check()ifresult.passed:ctx.state=LoopState.DONEelifctx.should_escalate():rollback(snapshot)ctx.state=LoopState.ESCALATEelse:ctx.failure_history.append(result.fingerprint)ctx.retry_count+=1returnctx代价机制是灵魂：每次重试都消耗预算，预算耗尽必须升级人工。没有代价的循环，Agent 会无限试错；代价太高的循环，Agent 会不敢改。我们把内层单次重试成本设为"可忽略"，外层升级成本设为"必须人工介入"，形成梯度。
效果验证
在 QQ 飞车的一个中型模块（约 8 万行 C++/Lua 混合代码）上做了对照实验：
| 指标 | 直接接入 Agent | 引入 Loop Engineering |
|---|---|---|
| 端到端任务完成率 | 41% | 78% |
| 平均重试次数 | 4.2 | 1.6 |
| 人工复核耗时/任务 | 22 分钟 | 9 分钟 |
| Token 成本/任务 | 1.0x | 0.7x |
复现步骤很直接：选一个已有测试覆盖的模块，让 Agent 完成一个真实需求（如"新增一个赛道碰撞检测的边界条件"），分别用两种方式跑 20 次，记录完成率和重试次数。关键是要用同一批任务，否则对比没有意义。
值得注意的是，完成率提升主要来自升级机制的及时触发——那些 Agent 注定搞不定的任务，被更早地交回人类，而不是让 Agent 反复烧钱。
边界与演进
Loop Engineering 不是银弹，它有明确的适用边界：
- 不适用于探索性任务：当需求本身模糊、没有明确验证标准时，循环无法收敛，此时应该先做人工意图澄清；
- 不适用于超长链路任务：如果单个任务跨越 10+ 模块，外层循环的端到端验证会变得极慢，需要先做任务分解；
- 验证器质量决定上限：如果测试本身覆盖不足，Loop 只会让 Agent 更快地"通过假测试"，这是最危险的情况。
下一步优化方向有两个：一是自适应重试预算，根据任务复杂度动态调整max_retries，而不是固定 3 次；二是跨任务记忆，把历史失败指纹沉淀成团队级的"避坑库"，让新任务在开始前就避开已知陷阱。
回到最初的问题：Agentic 研发转型的难点从来不是"Agent 能不能写代码"，而是"我们能不能为 Agent 设计一个它会认真对待的反馈闭环"。Loop Engineering 的本质，是把人类工程师多年积累的"试错直觉"显式化成机器可执行的循环规则——这才是转型真正的工程含量所在。
