1. AppLooper: An Agentic Application Engineering Loop for Accountable Release with Virtual-User Feedback
- 作者/来源： Zihong He、Chen Liang、Hai-Ning Liang
- 发布日期： 2026-08-14
- arXiv： https://arxiv.org/abs/2608.14093
- AlphaXiv： https://www.alphaxiv.org/abs/2608.14093
- 代码： https://github.com/ZihongHe/applooper
推荐理由： coding agent 的长循环已经能持续实现、测试和修复，但真正进入产品开发后，更难的问题是需求漂移、用户重新进入流程时不知道当前状态，以及“测试通过”并不等于目标用户真的能完成任务。AppLooper 值得看的是它没有继续堆一个更聪明的 coder，而是把 owner intent、独立测试、virtual users、版本化候选和最终 release authority 做成一个可追踪的软件交付闭环。它更像一份 AI-native product/software factory 的 lifecycle 设计，而不是单纯的 agent benchmark。
核心要点：
- 系统把开发拆成五个责任边界明确的角色：application owner、development agent、virtual-user cohort、owner-intent simulation agent 和 testing agent。需求先被冻结，开发 agent 只围绕确认后的目标持续生成 versioned candidates，最终发布权始终保留给人。
- 验证不是一个统一的“critic”：virtual-user agents 从目标用户和使用场景出发实际操作界面；owner-intent agent 只重测用户明确确认过的需求并在证据不足时 abstain；testing agent 保持只读，负责复现失败、回归测试和 browser checks。不同验证器拥有不同 evidence boundary 和 permission boundary。
- 所有 requirement、feedback、finding、implementation change、retest 和 owner inspection 都绑定到具体 candidate version；一旦 candidate 改变，旧版本的验收结论会失效。这个设计把 agent 的“持续迭代”转成了 version-bounded evidence → human-authorized release，比只看最终 diff 或 pass/fail 更接近真实软件交付。
2. Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model
- 作者/来源： Stephanie Jarmak
- 发布日期： 2026-08-14
- arXiv： https://arxiv.org/abs/2608.13867
- AlphaXiv： https://www.alphaxiv.org/abs/2608.13867
推荐理由： 这篇 314 页的 engineering monograph 很适合作为 coding-agent 系统设计的参考手册。它的核心判断是：coding agent 被 benchmark 成“模型”，但上线后其实是一个分布式软件系统。 很多看起来像模型能力不足的问题，实际来自 harness、environment state、retrieval、memory、permissions、verification 或 observability；因此只换更强模型往往不能把局部提升传导到 end-to-end reliability。
核心要点：
- 作者综合 164 篇学术工作、100 条 practitioner records、29 个 benchmark records、17 个实际 agent-system case records，将可靠性建模成依赖链：task construction → execution environment → retrieval/context → state management → permissions → verification/review → observability/resource allocation。上游层一旦失真，下游的模型评分也可能失去意义。
- 论文整理了 206 条 reliability records，其中 193 条是 gated practices、56 条被深入展开，另有 13 条 research leads，并提供 evidence ledger、可运行的 evaluation/reliability protocols 和 5 个可复用 agent skills。重点不是“best practice 清单”，而是让每个可靠性判断都能追溯到证据和适用边界。
- 一个重要方法论是 dependency / repair asymmetry：某一层造成的失败，未必能在同一层修复。例如 retrieval 缺上下文时，增加模型推理预算可能只是更昂贵地失败；verification 不可信时，提高生成质量也无法证明结果正确。对 harness 工程而言，应该先定位系统瓶颈，再决定是换模型、改工具、改上下文还是改验证闭环。