Loop Engineering 与前沿 Vibe Coding

本书工作定义: 本文把可观察, 可验证, 可终止的 agent feedback loop 称为 Loop Engineering. 该名称不是统一官方学科分类; 可靠性来自真实反馈, 独立验证和明确终止条件, 不是 “循环调用模型直到看起来能跑”.

适用范围: 本章用于 agent feedback loop 教学和面试表达; 本章 taxonomy 与工作定义不构成行业标准, 也不代表任一产品版本或能力. 核验日期与来源见文末.

本章承接 Vibe Coding 概览, Harness Engineering 和 AI Coding 工程化进阶, 聚焦任务如何在多轮执行中收敛.

学习目标

能让每轮 agent 操作产生新证据, 将失败归入可行动类别, 并在 ANR 等高风险问题上停止猜测, 回到 trace 和独立验证. 下文 loop taxonomy 与案例都是本书工作材料, 不是产品能力声明.

一, Loop 的最小状态机

Goal + Constraints + Acceptance
  -> Retrieve current context
  -> Plan minimal change
  -> Execute with scoped tools
  -> Observe tests/build/trace/device/review
  -> Classify failure
  -> Fix one cause or escalate
  -> Accept, rollback, or stop

每轮至少记录输入版本, 执行动作, 观察结果, 失败分类和下一步. 没有新证据时重复同一 prompt 不算有效 loop.

二, 可观察, 可验证, 可终止

可观察: 能看到 tool calls, diff, 命令输出, trace, 截图, 设备矩阵和成本.
可验证: 验收标准可执行; 验证者与实现输出尽量独立; 失败能复现.
可终止: 有最大轮次/预算/时间, 连续失败升级条件, 高风险人工 gate 和回退点.

常见终止条件:

验收标准满足且相关检查通过.
diff 没有范围外修改, 高风险项已批准.
证据包含环境, 版本, 命令和结果.
剩余风险已记录并有 owner.
若证据冲突, 工具不可信或连续失败, 停止自动循环而不是扩大权限.

三, 失败分类表

分类	典型信号	首个动作	不该做什么	升级条件
需求不清	验收冲突, owner 不同意	澄清不变量和非目标	用实现猜产品意图	无法得到决策 owner
上下文缺失/过期	文件/版本与回答冲突	重新读取源和 commit	用记忆补全 API	关键事实仍不可得
实现缺陷	可复现失败, diff 指向单处	最小修复和回归测试	顺带重构 / 升级依赖	修复触及跨模块契约
测试 / 环境缺陷	测试不稳定, 设备不可用	保存原始输出, 隔离环境	把失败测试删掉	无法区分产品与环境
权限 / 安全阻断	需秘密, 网络, 发布权限	停止并请求批准	扩大权限或绕过门禁	高风险操作被拒绝
性能 / ANR 不确定	trace 不足, 噪声大	收集 trace, 基线, 设备条件	靠代码阅读定根因	多轮无新证据或影响扩大

每轮在失败分类改变前不重复相同 prompt; 连续两轮没有新增证据时停止, 重新澄清或转人工.

四, Android 常见反馈循环

状态恢复 Loop

业务不变量 -> 失败测试 -> 最小实现
-> STOPPED/旋转/进程重建路径 -> 独立 review -> 收敛或回退

ANR / 性能 Loop

线上指标或可复现问题 -> trace/frame timeline
-> 提出可证伪假设 -> 最小改动 -> Macrobenchmark/设备复测
-> 对比基线, 环境和噪声 -> 决定保留或回退

完整 ANR loop 案例

** 案例为演练, 不是线上事故记录.** 症状: 特定设备上的输入 ANR 聚类. 首先冻结原始证据: 应用/系统版本, ANR trace, 发生前 breadcrumb, CPU 负载, 主线程和 Binder 对端栈. 假设 A 是主线程磁盘 I/O, 假设 B 是 Binder 调用等待; 二者都必须从 trace 证伪或支持.

T0: APM 聚类 -> 保存 trace 与筛选条件
T1: 主线程 stack 显示 wait? -> 同时查看锁 owner/Binder 对端/CPU
T2: 最小复现或可控注入 -> trace 对比基线
T3: 若确认同步 I/O -> 移出主线程,保留取消/超时/结果回投边界
T4: 加入 regression instrumentation/trace marker -> 设备复测 -> 灰度
T5: 观察 ANR 分母,版本/机型分层和新回归 -> 保留,回退或升级人工

若 trace 显示主线程在等待远端 Binder, 不能仅把调用移动到后台就宣称解决, 仍要检查调用是否必须同步, 对端为何阻塞, 超时 / 降级是否符合业务. 验证以同条件 trace, 响应性和 ANR 指标口径为准; 没有线上样本时只写 “实验验证”, 不写线上收益.

Gradle / 依赖 Loop

保存原始失败 -> 核对 AGP/Gradle/JDK/Kotlin/KSP 兼容矩阵
-> 最小配置改动 -> 运行目标 task -> 检查依赖图与范围外升级

UI 设备在环 Loop

patch -> Preview/UI test/screenshot -> 真机或模拟器
-> 系统栏/键盘/深色/字号/无障碍/性能 -> 反馈具体差异 -> 收敛

targetSdk / 隐私 Loop

列出行为变化与地区要求 -> 扫描受影响路径 -> 分模块改造
-> 多版本设备矩阵/隐私复核 -> 灰度指标 -> 回滚预案

五, 前沿话题地图

以下九项是本文用于教学的 taxonomy, 不是统一官方分类. 各产品能力与可用区域变化较快, 必须按日期和官方文档核验.

异步 coding agents: 后台读取 issue/spec, 修改代码并产出 PR.
多 agent 分工: Planner/Builder/Reviewer/Verifier, 但需要独立证据和清晰 owner.
Repository instructions: 把项目规则放入可版本化的仓库文件.
Context retrieval: 按任务检索代码, 文档, issue 和运行证据.
MCP 与工具生态: 通过开放协议暴露 tools/resources/prompts, 同时治理 server trust.
Evals 与 benchmark: 固定任务集衡量正确率, 越权率, 成本和回归.
设备 / 浏览器在环: 用真实 UI, 日志, trace 和截图作为反馈.
Human-in-the-loop: 在支付, 隐私, 发布, 依赖和架构变更处审批.
Provenance 与审计: 记录模型 / 工具版本, 数据来源, diff, 命令和批准事件.

六, 如何评估 Agent Loop

不要只看 “是否最终生成 patch”. 建议指标:

维度	示例指标
正确性	固定任务通过率, 缺陷逃逸率, 恢复路径覆盖率
约束遵守	越权文件修改率, 未批准工具调用率
收敛	平均轮次, 重复失败率, 人工升级率
质量	review 返工, 弱测试比例, 安全问题数
效率	wall-clock, token / 计算成本, 人工介入时间
可恢复	回退成功率, 审计完整率, 失败可复现率

评估应固定仓库基线, 任务集, 模型/工具版本和预算. OpenAI Evals 是评估框架/方法资料之一; SWE-bench 是独立的真实软件工程 benchmark 项目. 两者不能写成同一个产品或标准.

七, 多 agent 产出示例

下面复用上文 “特定设备输入 ANR 聚类” 的同一演练. 四个角色共享 task_id: anr-input-2026-08-07-01, base_ref: <pinned-commit>, 而不是共享结论; trace-17, patch-8f31 等均为最小示例 ID, 不是已执行的生产记录.

Planner
  task_id: anr-input-2026-08-07-01
  evidence: trace-17 shows main thread waiting during input; device matrix device-A/API-34
  hypothesis: synchronous repository lookup is on the input path
  non_goals: no dependency upgrade; no Binder timeout change without trace evidence
  acceptance: same-condition trace removes lookup from main-thread input path; cancellation remains safe

Builder
  task_id: anr-input-2026-08-07-01
  patch_id: patch-8f31 (commit: <not-created>)
  change: move repository lookup behind existing dispatcher; preserve cancellation and result handoff
  evidence: diff patch-8f31; command record command-22
  unexecuted: device-A trace capture and Macrobenchmark were not run

Verifier
  task_id: anr-input-2026-08-07-01
  independence: starts from base_ref plus patch-8f31; does not accept Builder's command result
  evidence: independent trace attempt trace-18 still shows a synchronous Binder wait on input path
  finding: Builder hypothesis is not proven; moving lookup did not establish the Binder dependency is absent
  decision: rework
  unexecuted: production rollout metrics unavailable in this exercise

Reviewer
  task_id: anr-input-2026-08-07-01
  evidence: compares trace-17, trace-18, patch-8f31, and cancellation invariant
  disagreement: accepts Verifier's rejection; disagrees with Builder's implied sufficiency claim
  decision: rework; require Binder peer/lock-owner evidence before changing timeout or accepting patch
  unexecuted: no release approval and no production experiment

四份产出必须引用同一 task ID, 并明确 patch 或 commit ID, 证据, 分歧和未执行项. Verifier 可以独立否定 Builder; Reviewer 的 accept/rework 决策应基于证据冲突, 而不是角色投票. 若 Verifier 使用同一 mock, 同一错误 context 或无实际检查, 多角色不构成独立证据.

八, 产品趋势的陈述边界

截至 2026-08-07, GitHub Copilot coding agent, Google Jules 和 OpenAI Codex 可作为异步或 agentic coding 产品方向的例子; 具体能力, 运行环境, 权限, 计划, 地区和计费均可能随版本变化. 面试中应按引用日期陈述各自官方文档确认的信息, 不将产品描述外推为行业标准或绝对能力保证.

GitHub Copilot coding agent: 以 GitHub 官方文档和 changelog 为准.
Google Jules: 以 Google 官方 Jules 文档和公告为准.
OpenAI Codex: 以 OpenAI 官方 Codex 文档为准.
Model Context Protocol (MCP): 以官方规范和仓库为准. 可说明其最初由 Anthropic 推出, 现按开放项目和正式治理信息理解, 不称为 “Anthropic 私有标准”.

九, 观点来源与事实来源分开

Andrej Karpathy 和 Simon Willison 的公开讨论可用于解释 Vibe Coding 的术语出处和个人观点.
产品能力, 协议语义, 稳定性和安全要求应引用对应官方文档 / 规范.
团队方法是否有效应引用自己的 eval/CI 数据, 任务集和失败样本.
观点影响力不能替代版本化产品事实, 单次案例也不能替代统计证据.

十, 面试怎么答

面试官问「你怎么保证 AI 持续迭代不失控」→ 我给 loop 设可观察, 可验证, 可终止三条边界: 每轮工具调用, diff 和命令输出可见, 验收标准可执行且验证尽量独立, 终止条件含最大轮次/预算/连续失败升级, 证据冲突或工具不可信时停止而不是扩大权限. 面试官问「怎么区分 AI 完成任务 vs 你负责任务」→ AI 完成任务指产出 patch 并通过检查; 我负责任务指需求判断, 验收定义, 证据质量和终止决定, 连续两轮无新证据时由我重新澄清或回退. 面试官问「多 agent 演练的价值与局限」→ 价值在 Planner/Builder/Verifier/Reviewer 上下文隔离, owner 清晰且验证独立时, 能发现单一角色的自证问题; 局限是共享同一 mock 或错误 context 时多角色只是互相确认, 不构成独立证据, 所以 Verifier 要能基于证据冲突否定 Builder, 而不是角色投票.

高频面试题

Q1: Loop Engineering 与 Prompt Engineering 的区别?
Prompt 关注单次表达; Loop 关注多轮状态, 工具执行, 真实反馈, 失败归因, 审批和终止.

Q2: 多 agent 一定更可靠吗?
不一定. 如果共享同一错误上下文或互相确认结论, 只会放大错误. 需要上下文隔离, 独立验证和清晰 owner.

Q3: 怎样防止 loop 越改越乱?
限制写入范围和预算, 每轮只处理一个已分类失败, 对范围外 diff 自动失败, 连续失败停止并重新澄清或交给人工.

练习与预期证据

为一个 ANR 演练填写失败分类, 每轮新证据, 假设, 停止条件和验证计划; 再为同一任务写 Planner/Builder/Verifier/Reviewer 四份最小产出. 合格证据是每一轮都能引用 trace, 命令, diff 或人工决策, 而不是重复模型结论.

Android 中级面试复习手册