TL;DR

过去十几期文章的核心议题是「生成质量」——怎么让 AI 写出更好的代码、更准确的文档、更合理的架构。但本期三篇论文揭示了一个更根本的转向：Agent 进入工程系统后，失败不再发生在「生成」环节，而在「多轮保持、栈层定位、工具闭环」这三个被系统性忽视的环节。

  1. 多轮退化：40%–73% 的任务在第 2–8 轮丢失首轮已满足的行为，主因是后轮代码与早轮隐含需求冲突。唯一有效缓解是 Verification Gate。
  2. 栈层盲区：软件工程边界正从「可执行代码」扩展到「半可执行制品」（prompt、policy、route），但团队普遍缺乏定位语言和资产意识。
  3. 工具断环：LLM Agent 装配并跑通静态分析工具的成功率仅 77%，远低于自报；架构设计比换模型更关键。

核心观点：当生成不再是瓶颈，上下文保持、栈层可见、工具闭环就成了新的主战场。

📋 本文结构

  1. 背景：生成问题已被「基本解决」
  2. 多轮退化：Vibe Coding 的真实失效模式
  3. 栈层盲区：半可执行制品的资产化难题
  4. 工具断环：分析工具自动装配的七个陷阱
  5. 三者的共同指向
  6. 反直觉洞察
  7. 可落地动作清单

1. 背景：生成问题已被「基本解决」

这个说法当然有争议，但趋势是明确的：单轮 HumanEval Pass@1 从 2023 年的 50% 爬升到 2026 年的 90%+，Claude 3.5 / GPT-4.5 / Gemini 2.0 在标准评测上已经超越大多数人类工程师。「写不出来」不再是主要矛盾。

真正的问题开始浮出水面：

  • Cursor 8 轮长会话做到一半，早轮写的功能被后轮改坏了
  • Agent 读不懂团队的政策文档，因为那文档是半可执行制品（行为部分由概率解释）
  • 静态分析工具装好了，Agent 却跑不通，报错也看不懂

这三类问题有一个共同特征：它们不是生成质量问题，而是系统层面的协调失效。

2. 多轮退化：Vibe Coding 的真实失效模式

2.1 论文核心发现

arXiv 2607.01855 做了迄今最系统的多轮对话退化研究。研究者将 HumanEval+/MBPP+ 任务改造成 8 轮需求演化链——不是简单重复 prompt，而是让需求在每一轮都有增量变化（例如：第 3 轮要求修改 API 签名，第 5 轮引入并发约束）。最终得到 542 任务 × 6 模型 × 8 轮 = 26016 个实例。

关键数据：

  • 40%–73% 的任务在后续轮次丢失了早轮已满足的行为
  • 主要失效机制不是「写不出」，而是 Cross-Turn Conflict——后轮代码与早轮隐含需求冲突，早轮行为被悄悄破坏
  • HumanEval Pass@1 与多轮需求保留率之间几乎没有相关性——单轮高分严重高估了可靠性

2.2 为什么 Verification Gate 是唯一有效的缓解

研究测试了多种缓解策略（结构化提示、需求锚定、任务分解），唯一稳定有效的是 Verification Gate：

在接受新代码之前，先用新代码跑早轮的测试用例。失败则回滚重试，而不是继续往前改。

DeepSeek-V3 应用 Verification Gate 后，末轮质量从 75.8% 提升到 87.9%。效果显著，原因也很朴素：你永远需要有人对「改坏之前对的」这件事负责。

2.3 对 Vibe Coding 的重新定性

Vibe Coding 的倡导者会说「让 Flow 持续，不要打断」。这没错，但前提是 Flow 不会悄悄破坏之前完成的东西。如果 40%–73% 的任务会在第 2–8 轮退化，那么 「不要打断 Flow」本质上是在积累技术债，而不是在加速。

更准确的说法应该是：Vibe Coding + Verification Gate，而不是 Vibe Coding 单独成立。

2.4 评测基准的范式转移

这篇论文最重要的贡献可能是揭示了 Pass@1 作为评测指标的破产。单轮高分是一种幻象。真正需要的是：

  • 需求保留率（Requirement Retention Rate）：多轮对话后，原有需求被满足的比例
  • 回归密度（Regression Density）：每轮引入的回归数量
  • 冲突发现延迟（Conflict Discovery Latency）：从冲突产生到被发现的时间

这三个指标还没有成为标准，但它们比 Pass@1 更能预测真实场景中的可靠性。

3. 栈层盲区：半可执行制品的资产化难题

3.1 六环诊断模型

Feldt（Chalmers）在 Agentic Engineering 2026 的主旨演讲中提出了一个六环诊断模型，将软件工程制品按「可执行程度」分层：

┌─────────────────────────────────────────────────────┐
│              六环诊断模型（按可执行程度）              │
│                                                      │
│  第6环 │ 社会制度适配（法律、监管、文化）              │
│  第5环 │ 运行逻辑（生产环境行为）                     │
│  第4环 │ 控制（监控、告警、恢复策略）                  │
│  第3环 │ 编排执行（工作流、CI/CD、调度）               │
│  第2环 │ 指令制品（prompt、policy、route）            │
│  第1环 │ 可执行制品（代码、配置、测试）                │
│                                                      │
└─────────────────────────────────────────────────────┘

关键洞察：软件工程的边界正在从「可执行代码」扩展到「半可执行制品」。第 2 环的 prompt、policy、route 规则，行为部分由人解释、部分由概率解释，而非确定性执行。

3.2 为什么这是被忽视的盲区

过去几期讨论的「Agent-Friendly Documentation」「Spec-First」本质上都在讨论第 2 环。但我们一直缺少一个统一的定位语言——不是又一套框架，而是让大家知道自己在讨论哪一层。

Stack Overflow 的联合创始人 Joel Spolsky 说过：“，语言决定思维，思维决定工具。” 当我们没有「半可执行制品」这个词汇时，团队就不会把它当成一类需要管理的资产。

结果是：

  • prompt 散落在各个 Agent 的聊天记录里，没有人知道哪个是最新版本
  • policy 规则由某个工程师「凭感觉」维护，没有审计记录
  • route 决策逻辑藏在代码里，但没有人知道为什么走了这条分支而不是那条

3.3 从暗知识到可审查资产

将半可执行制品变成可审查资产，需要三步：

  1. 发现：梳理团队所有的 prompt、policy、route 清单
  2. 登记：每项标注负责人、更新频率、最后校验日期
  3. 定位：建立栈层定位语言，让每次讨论都知道在第几环

这不是元编程，这是工程系统的自我感知。一个不能感知自己各层状态的系统，注定会在第 2–4 环之间产生大量隐性错误。

4. 工具断环：分析工具自动装配的七个陷阱

4.1 论文核心发现

arXiv 2604.11270 首次系统评测 LLM Agent 在「给项目装配并跑通静态分析/符号执行工具」这类任务上的表现。35 个 tool-project 对（7 种工具 × 10 个 C/C++/Java 项目），关键数据：

  • Gemini-3-Flash 后端 + AnalysisAgent 架构 = 94% 人工核验成功率
  • ExecutionAgent（同后端）= 77%
  • LLM 自报成功率普遍高于真实成功率，尤其在部分完成的场景

AnalysisAgent 的核心设计：分阶段（stage mixing）+ 单动作周期 + 证据校验。ExecutionAgent 的问题是把工具装配和工具执行混在一个阶段里，导致错误定位困难。

4.2 七个陷阱（来自实验观察）

基于论文数据的归纳，LLM Agent 装配工具时最容易掉的七个陷阱：

  1. 环境感知缺失：不知道依赖项已经安装，试图重复安装导致冲突
  2. 路径假设硬编码：假设工具在固定路径，真实环境路径不同则失败
  3. 输出格式误解：把警告当成错误，或把错误信息中的建议当成真实问题
  4. 部分成功误报：工具跑通了但只覆盖了部分分析维度，Agent 认为 100% 完成
  5. Java 工具链尤其难：Maven/Gradle 生命周期与静态分析工具的集成比 C++ 复杂得多
  6. 全程序分析失败：需要跨文件的依赖分析时，工具装配正确但分析失败
  7. 错误本地化失败：报错后 Agent 在错误位置附近打转，找不到真正原因

4.3 架构比模型更关键

研究的一个反直觉结论：AnalysisAgent 用 Gemini-3-Flash 打败了 ExecutionAgent 用更强后端。差异来自架构设计，不来自 LLM 能力。

这意味着：

换更强模型能提升的上限，由架构设计决定。如果 stage mixing + evidence verification 没做对，换 GPT-5 也是在低上限上优化。

对于工程团队来说，这个结论的实践意义是：先投资架构设计，再投资模型采购。 顺序反了会浪费大量预算。

5. 三者的共同指向

三篇论文在表面上讨论不同问题，但深层指向完全一致：

生成环节 ────────→ 协调环节
「写不出」            「改坏之前对的」
「看不懂」            「不知道自己在哪层」
「装不好」            「装配完了跑不通」

Agent 进入工程系统后，主要失效点从「单点生成」迁移到「系统协调」。 这不是某篇论文的发现，而是三篇独立工作从不同角度汇聚出的共同结论。

具体来说：

  • 多轮退化是跨时间的协调失效（早轮 vs 晚轮）
  • 栈层盲区是跨空间的协调失效（第 2 环 vs 第 1 环）
  • 工具断环是跨组件的协调失效（工具 vs 环境 vs 输出解释）

6. 反直觉洞察

6.1 单轮评测正在误导整个行业

HumanEval Pass@1 是 2023 年的指标，2026 年的工程实践已经远超它的适用范围。行业继续引用它是因为它方便，不是因为它准确。用 Pass@1 评估一个 8 轮 Vibe Coding 会话的质量，大概相当于用短跑成绩评估马拉松训练效果。

6.2 「强模型」解决不了「乱架构」

AnalysisAgent vs ExecutionAgent 的对比说明：在工程系统层面，架构问题的回报率远高于模型升级。如果你的 Agent 每次装配工具都失败，换一个更强的模型只是在给一个错误架构加速。

6.3 半可执行制品是下一个技术债来源

大多数团队已经在大量使用 prompt 和 policy，但几乎没有人把它们当成「需要维护的资产」来管理。五年后，当这些 prompt 版本混乱、policy 互相冲突的时候，我们会意识到这是 2026 年欠下的技术债。

6.4 验证不是创新，是纪律

Verification Gate 的朴素性是它最大的美德。在一个吹捧「下一个革命性框架」的领域，一个「跑一下历史测试」的动作听起来毫无新意。但它有效。在工程领域，最终区分高可靠系统和低可靠系统的，往往不是谁用了更炫酷的技术，而是谁有更好的纪律。

7. 可落地动作清单

Verification Gate 引入 Vibe Coding 工作流

  • 在 Cursor / Windsurf 设置「每轮提交前回跑历史测试」的习惯锚点
  • 自测练习：选一个 8 轮以上的历史会话，统计末轮 vs 首轮的需求保留率（人工即可，不需要自动化）
  • 储备提示词模板：「请在修改前先跑原有测试，确认不破坏后再提交」

半可执行栈资产登记

  • 梳理团队所有 prompt、policy、route 清单（对应「指令制品」环）
  • 每项标注：负责人、更新频率、最后校验日期
  • 目的：让「栈层定位」从暗知识变可审查资产

分析工具 Agent 试点

  • 选一个 C/C++ 项目，装好 clang-tidy 或 semgrep 其中之一
  • 用 Agent 跑「装好→跑通→报告」全流程，人工核验成功率
  • 对比不同 Agent 架构（stage mixing vs monolithic）的表现差异
  • 记录哪个环节（环境感知 / 路径解析 / 输出解释）最容易失败

结语

本期三篇论文的共同价值，不是提供了某个新框架或新范式，而是重新划定了问题的边界。

过去十几期讨论的「架构收敛 / Spec-First / 可追责性」解决的是「生成环节的可靠性」。本期三条则指向一个更深的事实：当生成不再是瓶颈，上下文保持、栈层可见、工具闭环就成了新的主战场。

这不是换一套提示词就能解决的事。这是工程系统层面的协调问题，需要从评测基准、资产管理和架构设计三个方向同时推进。

你所在团队的 Agent 工程，目前卡在哪一环？

参考文献

  1. Regression Accumulation in Multi-Turn LLM Programming Conversations. arXiv:2607.01855. https://arxiv.org/html/2607.01855
  2. Feldt, R. The Semi-Executable Stack: Agentic Software Engineering and the Expanding Scope of SE. Agentic Engineering 2026. https://arxiv.org/html/2604.15468
  3. Evaluating LLM Agents on Automated Software Analysis Tasks. arXiv:2604.11270. AnalysisBench + AnalysisAgent. https://arxivx.org/abs/2604.11270