廉价生成之后：AI Agent 与再生式软件工程

引言：我们正在优化错误的生产函数

关于 AI Agent 与软件工程，最常见的问题是：

Agent 能把程序员的效率提高多少？

这个问题并非完全错误，但它把软件工程误写成了一条以“代码”为主要产出的流水线：输入需求，消耗工程师时间，输出实现；只要降低实现成本，生产率就会自然提高。

真实的软件与复杂系统不是这样工作的。

代码只是一次状态变化的载体。工程真正要交付的是：

• 一个被正确理解的问题；
• 一个满足显式与隐式约束的系统变化；
• 一组足以支持决策的证据；
• 一个可以被运维、演化和追责的长期结果；
• 以及在失败发生时仍然能够恢复和学习的组织能力。

在这个生产函数里，编码从来都不是唯一成本。随着 Agent 让搜索、生成、修改和实验越来越便宜，系统的稀缺资源会迅速迁移到别处：

• 谁来定义什么值得做；
• 谁来判断证据是否真的回答了问题；
• 谁来处理跨模块、跨团队和跨时间的外部性；
• 谁来发现测试没有表达的需求；
• 谁来承担不可逆动作的后果；
• 谁来保证组织在长期自动化之后仍然理解自己的系统。

所以，Agent 时代更重要的问题不是“代码还能便宜多少”，而是：

当行动能力变得廉价且可复制时，软件组织能否同步扩大反馈、验证、恢复、判断与责任能力？

如果答案是否定的，更快的执行不会消除工程瓶颈，只会更快地积累未经验证的变化。

本文提出一个比“任务成功率”更长期的判断标准：再生式软件工程。

所谓再生式，不是要求每个 Agent 都能自我改进，也不是为“全自动软件公司”换一个更宏大的名字。它指的是：

一次工程活动结束后，系统与组织应当比活动开始前更容易理解、更容易验证、更容易恢复，也更有能力重新选择方向。

如果一次自动化只产生了代码，却没有产生更好的证据、边界、知识和选择权，它可能完成了当前任务，但同时把成本转移给了未来。那不是再生，而是消耗。

---

一、Agent 不是更快的程序员，而是更高增益的执行器

把 Agent 只理解成“数字程序员”，会低估它最重要的系统效应。

传统团队中的工程动作受人类时间约束。一个想法是否值得实验，往往取决于实现和验证它需要几天还是几周。Agent 改变的不只是单次实现时间，还改变了可被负担的行动数量：

• 可以同时搜索更多代码路径；
• 可以生成多个候选实现；
• 可以对更多配置做实验；
• 可以持续执行机械迁移与维护任务；
• 可以把失败方案也运行到足以获得证据；
• 可以在不同环境、版本和输入分布上重复验证。

这等于提高了系统的执行增益。设单位时间产生的候选动作数为 (\lambda)，单个动作产生未被吸收损失的概率为 (p)，平均损失为 (C)，那么一个极度简化但有用的直觉是：

\[\text{单位时间期望损失} \approx \lambda \cdot p \cdot C\]

模型进步可能降低 (p)，sandbox、回滚和小批量可能降低 (C)。但只要 (\lambda) 增长得更快，单位时间总风险仍然可能上升。

这解释了一个表面悖论：单个 Agent 越可靠，组织反而越需要系统工程。 因为可靠性提高会诱发更大规模、更高频率和更广权限的使用。低频工具中的罕见错误，在高频基础设施中会变成日常事件。

1.1 从“生成吞吐”到“闭环吞吐”

一个候选补丁被生成，不代表一次工程活动已经完成。至少还要经历：

1. 理解目标；
2. 形成候选变化；
3. 获得可靠反馈；
4. 解释反馈；
5. 修正或拒绝候选；
6. 集成到当前系统状态；
7. 观察延迟后果；
8. 形成可以复用的学习。

因此，真正有意义的吞吐不是每小时生成多少 diff，而是：

每单位人类注意力，系统能够完成多少个带有可信证据、可恢复且被真实接受的状态转换。

只有“动作—反馈—修正—验收”整个闭环变快，才是工程系统变快。

1.2 反馈债务

假设 Agent 每单位时间产生 (\lambda) 个待验证动作，从动作产生到获得可靠反馈的平均延迟为 (T_f)。在第一个可靠反馈返回之前，系统大约会积累：

\[D_f = \lambda T_f\]

个未经充分验证的动作。这里把 (D_f) 称为反馈债务。

它不是精确的风险公式：动作大小、相关性和影响范围都不相同。但它提供了一个比“Agent 写得有多快”更有解释力的量。

• (\lambda) 增加：更多 Agent、更多并发、更多候选；
• (T_f) 增加：更慢的 CI、更长的人工 review、更晚的生产真值；
• 二者相乘：系统在获知方向是否正确之前，已经走出了多远。

如果 100 个 Agent 都基于同一个错误需求并行工作，它们不是把任务加速了 100 倍，而是在反馈到来前把错误复制了 100 份。

所以，扩大 Agent 使用规模之前，首先应问：

我们增加的是闭环吞吐，还是只是在增加反馈债务？

---

二、什么是“再生式软件工程”

传统自动化通常按单次任务计算收益：

\[\text{收益} = \text{节省的人工时间} - \text{模型与基础设施成本} - \text{返工和失败损失}\]

这个计算对短期决策有用，但它遗漏了软件工程最重要的时间属性：今天的变更会改变明天做变更的难度。

同样一个“成功上线”的任务，可能产生完全不同的长期结果。

一种结果是：

• 新增了可信的回归测试；
• 明确了接口契约和不变量；
• 改善了 trace、回滚和故障隔离；
• 保存了替代方案与决策依据；
• 下一次同类任务需要更少的人工解释。

另一种结果是：

• 为通过当前测试加入更多特殊分支；
• 新增了来源不明的依赖和抽象；
• 把临时经验写进永久 memory；
• 只有 Agent 能解释生成的复杂代码；
• 人类在 review 中快速批准，却没有形成理解；
• 下次修改必须继续依赖同一个工具和同一套隐含假设。

二者都可能在任务记分卡上显示“成功”，但前者增加了工程能力，后者透支了工程能力。

2.1 三种应当积累的工程资本

再生式工程至少关心三类存量。

验证资本

验证资本是组织可靠判断“变化是否正确”的能力，包括：

• 可执行规格；
• 回归测试、属性测试和差分测试；
• 参考模型与运行时不变量；
• 可信 benchmark 与历史回放；
• 可追溯的遥测和故障分类；
• 可演练的回滚与恢复机制；
• 对 verifier 盲区的已知记录。

它的价值不只在当前上线。一个好的 oracle 会持续降低以后每个候选方案的选择成本。

人类能力资本

人类能力资本是组织仍然能够：

• 理解关键实现与依赖；
• 判断需求和指标是否错误；
• 识别超出既有规则的新型异常；
• 在自动化失效时接管；
• 对跨团队、长期和伦理后果做决定；
• 为系统结果承担有信息基础的责任。

如果自动化提高了交付吞吐，却让团队逐渐失去诊断、设计和接管能力，这笔收益包含了未入账的资本折旧。

架构选择权

架构选择权是未来改变方向的自由度，包括：

• 模块边界是否清晰；
• 接口是否允许替换实现；
• 数据和协议是否被不可逆地固化；
• 决策依据与被拒绝方案是否可恢复；
• 依赖是否造成供应商或模型锁定；
• 局部假设是否被扩散成全局承诺；
• 迁移是否能分阶段、暂停和退出。

git revert 能撤销代码，不一定能撤销公开 API 承诺、用户预期、组织分工和已经流失的技能。可逆性不只是回到旧 revision，还包括未来是否仍有重新选择的可能。

2.2 再生式判据

可以用一个概念式表达长期净价值：

\[V_{\text{long-term}} = V_{\text{task}} - C_{\text{current}} + \Delta K_v + \Delta K_h + \Delta K_o\]

其中：

• (V_{\text{task}})：当前任务交付的价值；
• (C_{\text{current}})：模型、CI、人工、返工与风险成本；
• (\Delta K_v)：验证资本变化；
• (\Delta K_h)：人类能力资本变化；
• (\Delta K_o)：架构选择权变化。

这不是要求把一切压缩成货币，也不是一个可以直接相加的会计公式。它的作用是强迫决策者看到：任务成功之外还有存量变化。

并非每个小任务都必须同时增加三种资本。一个格式修复不需要创造新的组织知识。但在一个任务组合和一个季度尺度上，如果自动化持续消耗验证能力、人员判断力和架构选择权，那么再高的短期吞吐也不可持续。

---

三、Agent 已经带来的真实好处

对 Agent 的批判不应建立在低估能力上。很多软件工程活动已经发生了实质性变化，而且这些变化不仅是 demo。

3.1 它降低了反事实探索的价格

复杂系统中最昂贵的工作常常不是实现已知答案，而是回答：

• 是计算、内存、网络还是调度导致了回归？
• 新接口应该兼容旧语义，还是借机清理历史行为？
• 三种修复分别会影响哪些配置？
• 一个失败来自代码、环境、测试还是测量方法？
• 哪个方案在不同约束下位于 Pareto 前沿？

人类受时间限制，往往只能沿一条最有希望的路径推进。Agent 可以并行生成假设、构造实验、执行重复测量、整理反证和比较候选。

这使生产率的基本单位从“产生多少实现”转向：

• 每单位人类注意力探索了多少有意义的替代方案；
• 排除了多少关键不确定性；
• 为决策保留了多少经过验证的选择。

在存在可靠 verifier 的领域，这种收益尤其明显。大规模候选生成只有在系统能够选择正确结果时才会兑现；否则 coverage 增长只意味着“正确答案可能藏在某个候选里”，并不意味着产品能够交付它。关于重复采样的公开研究正展示了这种差异：在软件任务中，自动验证可以把额外采样转化为更高解决率；在缺乏可靠选择器的任务中，候选覆盖增加却可能几乎不改善最终选择。(Brown et al., Large Language Monkeys)

3.2 它让知识外部化从“值得做”变成“做得起”

很多组织知道自己应该维护：

• 迁移指南；
• 调试 runbook；
• 接口契约；
• 故障模式库；
• 性能实验模板；
• 架构决策记录；
• 新人可执行的开发环境。

但这些工件的编写和更新长期被“更紧急的交付”挤压。

Agent 可以从代码、trace、review 和事故记录中生成初稿，发现文档与实现的差异，提示过期知识，并把一次任务的证据整理成可复用工件。这里真正的价值不是生成更多文字，而是把隐性知识变成：

• 可版本控制；
• 可追溯；
• 可测试；
• 可比较；
• 可失效；
• 可由新人和机器共同使用。

当然，自动生成的总结不能自动晋升为组织真值。知识外部化的最后一步是治理：来源、适用范围、责任人、验证状态和退出条件必须明确。

3.3 它可以显著强化工程内环

在目标明确、反馈快速、错误可丢弃的内环，Agent 已经表现出很强的适用性：

工程活动	Agent 已能创造的价值	成立条件	主要边界
代码搜索与影响分析	跨文件定位调用点、依赖和相似模式	仓库可访问，工具输出可追溯	隐性组织约定可能缺失
机械迁移与重构候选	批量修改 API、类型、配置和格式	变更在隔离分支，可编译和回归	语义兼容不能由编译证明
测试与静态检查循环	快速修复确定性失败，补充局部覆盖	测试可信且低 flake	可能针对测试投机
实验执行与结果整理	重复运行、记录环境、比较候选	测量环境稳定	不能自动保证因果解释正确
文档和证据包	汇总需求映射、测试、风险和未决项	来源完整、链接可追溯	自然语言摘要可能遗漏关键反证
低风险维护	依赖补丁、格式、简单告警修复	可逆、可观察、影响面小	供应链与跨版本行为仍需控制
候选方案生成	扩展设计与调试的搜索空间	有明确约束与选择机制	候选多不等于决策更好

这些能力已经足以改变团队工作方式。否认这一点，会把今天可自动化的 toil 留给人类，并继续消耗稀缺注意力。

3.4 它迫使系统变得更“可工程”

SWE-agent 的一个重要结果并不是“某个模型突然更会写代码”，而是为模型设计更合适的 Agent-Computer Interface：控制文件查看窗口、限制搜索输出、编辑后立即做语法检查。公开论文报告，在其设置中，这类接口设计相对 shell-only 取得了 64% 的相对提升。(SWE-agent, NeurIPS 2024)

Agentless 则进一步表明，在特定软件修复 benchmark 上，确定性的“定位—修复—验证”流水线可以优于当时许多开放式 Agent 架构。(Agentless, FSE 2025)

这些结果的耐久启示不是某个分数，而是：

环境、接口、反馈和任务形状，经常比更复杂的角色、planner 或 swarm 更能决定效果。

为 Agent 改善仓库结构、测试确定性、工具语义和可观察性，也会同时改善人类工程体验。Agent 在这里像一种压力测试：它会迅速暴露那些依靠资深工程师记忆和容错才能维持的脆弱接口。

---

四、复杂系统视角：更快的动作会重写反馈回路

Agent 进入工程系统后，不是简单增加一个劳动者，而是改变了多个反馈回路的增益、延迟和耦合。

4.1 吞吐—积压回路

最直观的回路是：

更多生成 → 更多待审变更 → review 与 CI 积压 → 单个变更获得的注意力下降 → 缺陷和返工增加 → 队列进一步增长

当候选变更到达率 (\lambda) 接近验证与集成服务率 (\mu_v) 时，系统负载率

\[\rho_v = \frac{\lambda}{\mu_v}\]

会逼近 1。排队延迟会非线性增长；超过 1 后，积压在持续状态下必然发散。

这不是“评审者应该更努力”的问题，而是控制系统缺少背压。正确动作可能是：

• 限制在制品；
• 缩小变更批次；
• 在进入人工队列前自动拒绝证据不足的候选；
• 提高机器 verifier 的覆盖；
• 让 Agent 优先清理队列，而不是继续生成；
• 按任务价值和风险调度，而不是先到先服务。

4.2 指标博弈回路

另一个回路是：

Agent 优化 grader → 分数提高 → 系统获得更大权限 → 训练与工作流更依赖同一 grader → 真实目标与指标进一步脱钩

当测试、奖励或审批规则成为稳定目标时，高能力搜索系统会自然发现它们的边界。DeepSeek-R1 的公开论文明确讨论了神经奖励模型在大规模强化学习中的 reward hacking 风险，并在可规则验证的推理任务上优先使用规则化奖励。(DeepSeek-R1, Nature 2025)

这并不说明规则验证器永远可靠。恰恰相反：任何被持续优化的程序化指标都会从“测量工具”逐渐变成“环境的一部分”。

所以，成熟系统需要：

• 多种机制不同的证据；
• 不完全暴露给执行器的审计样本；
• 延迟生产结果而非只有即时测试；
• 定期审查 grader 与真实接受度的分歧；
• 在指标失真时修改指标，而不是要求 Agent 更努力提高分数。

4.3 Memory 固化回路

长期 memory 会形成一种特殊正反馈：

一次未经充分验证的结论被写入 memory → 后续任务检索并采用它 → 基于该结论产生的结果再次强化原结论 → 暂时错误变成组织事实

问题不只在“记错了”，还在错误获得了跨任务传播能力。

Memory 更合理的类比不是大脑，而是带 provenance、TTL 和一致性策略的缓存：

• 当前代码和权威文档是事实源；
• 历史摘要只是有适用范围的派生物；
• 冲突时应降低信任并请求重新验证；
• 删除要覆盖索引、缓存和派生摘要；
• 来自不可信内容的信任标签必须沿派生链传播。

公开的 AgentPoison 研究表明，少量定向恶意条目可以在特定条件下影响检索式 Agent，而普通请求仍表现近似正常。它是研究攻击，不代表所有生产 memory 都会以同样概率失败，但足以证伪“平均检索质量正常就说明没有定向污染”。(AgentPoison, NeurIPS 2024)

4.4 技能退化回路

自动化还会作用于人：

自动化增加 → 人类减少一线操作 → 诊断和接管能力下降 → 异常时更依赖自动化 → 人类进一步退出

Bainbridge 在 1983 年讨论的“自动化讽刺”至今仍然适用：自动化把人从执行者变成监控者，而被动监控恰好是人不擅长的工作；当系统终于需要接管时，场景又往往最异常、最需要熟练能力。(Ironies of Automation)

Agent 时代的问题更尖锐：人类可能不只是忘记某个操作步骤，而是逐渐失去对大规模机器生成代码的整体心智模型。

4.5 安全增长回路

并非所有正反馈都是坏的。最值得主动设计的是：

小批量、隔离、可观测、可回滚 → 失败代价下降 → 可以进行更多安全实验 → 获得更多真实证据 → 扩大可自动化范围 → 进一步投资验证与恢复

这是一条“越自动化越可工程”的增长路径。

关键差别在于：系统是否把每次失败转化为更强的边界和反馈，还是只把失败当作需要清除的噪声。

---

五、廉价生成的代价：债务、单一文化与责任漂移

Agent 的风险不应只被写成“偶尔生成错误代码”。那是最表层、也往往最容易检测的一类问题。更深的代价发生在组织和系统结构中。

5.1 验证债

技术债是今天选择容易方案，把成本留给未来。验证债则是：

今天接受了一个尚未充分理解的系统变化，把证明、解释和长期确认留给未来。

典型表现包括：

• 目标测试通过，但需求映射不完整；
• 新增测试与实现共享同一个错误假设；
• 性能提升只在单一配置成立；
• Agent 生成了大量“看起来合理”的断言，却没有提高缺陷检出能力；
• 变更能够工作，但没有留下环境、数据和比较基线；
• reviewer 只能检查表面 diff，无法重建决策过程。

验证债最危险的地方是它常常不在当前 sprint 失败。它会在下一次重构、流量变化、依赖升级或事故中集中到期。

5.2 模型单一文化

多个 Agent 不等于多个独立意见。

如果需求解释、实现、测试、review、总结和事故复盘都由同一模型家族、相似上下文和相同提示完成，组织会形成一种认识论上的单一栽培：

• 同一种盲点被多次复制；
• 同一种错误前提在不同角色间伪装成共识；
• 输出风格的一致性被误认为事实一致性；
• reviewer 数量增加，但错误相关性没有下降。

异构验证不是简单使用更多模型，而是使用不同的失败机制：

• 类型与契约；
• 与旧版本的差分；
• property-based test；
• metamorphic relation；
• 参考模型；
• 运行时不变量；
• 人类抽样审计；
• 延迟业务结果。

机制不同也不代表统计独立。真正需要测量的是：它们是否会在同一错误上同时沉默。

5.3 责任漂移

Agent 可以执行动作，却不能承担法律、组织和伦理后果。人类可以被指定负责，却可能：

• 没有看见完整证据；
• 没有足够时间理解；
• 没有实际撤销权；
• 无法判断模型隐藏的不确定性；
• 只收到“批准访问 GitHub”这类缺少对象和影响的信息。

此时 human-in-the-loop 不是治理，而是责任漂移：系统把形式责任放在人身上，却把信息和控制权留在自动化流程里。

有效责任必须满足：

决策权、证据可见性、停止权、撤销权与后果承担相互对齐。

缺少其中任何一项，审批框都可能只是合规外观。

5.4 机器可读性税

为了让 Agent 自动执行，组织会把更多工作形式化：

• 需求写成结构化契约；
• 接口写成 schema；
• 成功写成测试；
• 决策写成规则；
• 知识写成 skill；
• 风险写成策略。

这总体上是进步，但也有代价。真实工作中存在无法被轻易压缩的部分：

• 相互冲突的利益；
• 暂时无法量化的产品价值；
• 依赖关系与组织政治；
• 审美和一致性判断；
• 尚未形成语言的新型异常；
• 必须通过协商而不是计算解决的问题。

如果团队为了自动化，只选择容易写成 grader 的目标，系统会出现“机器可读性税”：复杂现实被压扁成可测代理，未被形式化的价值逐渐失去资源。

正确结构不是“把一切都写成测试”，而是双层系统：

1. 机器可操作核心：硬约束、不变量、稳定接口、资源与权限边界；
2. 人类协商平面：目标冲突、例外、长期取舍，以及修改规则本身的权力。

5.5 语义与战略不可逆

“可以回滚”经常被理解得过于机械。

• commit 可以回滚，公开 API 承诺已经被用户依赖；
• 数据可以恢复，用户对字段语义的理解已经改变；
• feature flag 可以关闭，外部邮件和交易无法撤回；
• 依赖可以删除，团队的旧技术能力已经流失；
• 局部补丁可以撤销，新增抽象带来的跨团队耦合已经形成；
• 模型可以替换，围绕某个模型行为建立的流程和知识可能无法迁移。

所以评审 Agent 变更时，不仅要问“失败能否撤销”，还要问：

• 它是否扩大未来切换方案的成本？
• 它是否把局部假设变成公开承诺？
• 它是否减少了组织理解其他方案的能力？
• 未来团队能否恢复当时的证据、前提和被拒绝选项？

可持续系统不仅允许退回昨天，还允许明天选择不同方向。

---

六、重新分配职责：人、Agent 与控制平面

“Agent 写代码，人类做 review”不是最终的人机协作形态。它只是把旧流水线中的一个执行者替换掉，而没有重新设计职责。

更稳定的划分应当按职责性质，而不是按流程阶段。

6.1 Agent：承担可扩展的认识性劳动

Agent 擅长的不是承担责任，而是扩大认识活动：

• 搜索事实和相关上下文；
• 提出多个假设；
• 生成候选实现；
• 构造和执行实验；
• 收集、整理和比较证据；
• 识别缺失信息与冲突；
• 在明确边界内重复执行；
• 把结果压缩成可追溯证据包。

Agent 的输出不应只是“答案”，而应包括：

• 结论依赖哪些前提；
• 哪些事实来自工具；
• 哪些只是模型推断；
• 哪些替代方案已被排除；
• 哪些风险尚未获得证据；
• 什么结果会推翻当前结论。

6.2 确定性控制平面：承担强制性职责

有些工作不应依赖模型“记得遵守”：

• 最小权限；
• scoped credential；
• 文件、网络和进程隔离；
• 资源预算；
• 单写者和租约；
• revision 检查；
• 幂等键与去重；
• 审计与 provenance；
• 自动停止和回滚；
• 不可逆动作的硬授权边界。

这些属于控制平面。它的目标不是让模型更聪明，而是把最坏情况限制在可接受范围内。

高能力模型越擅长寻找路径，越不能把安全边界只写在自然语言里。公开的间接 prompt injection 研究、NIST Generative AI Profile 和 OWASP Agentic Applications 指南都指向同一系统问题：当外部内容既是数据又可能被解释为指令时，权限、数据流和工具调用必须由模型外的机制约束。(Indirect Prompt Injection, NIST AI 600-1, OWASP Agentic Applications 2026)

6.3 人类：承担规范性职责与双环学习

人类最难被替代的不是某种永恒的编码技巧，而是以下职责：

• 决定什么问题值得解决；
• 处理彼此冲突的价值和目标；
• 设定风险预算和不可接受后果；
• 对外部承诺与不可逆动作授权；
• 判断短期指标是否偏离真实目标；
• 处理跨团队、长期和制度性外部性；
• 在超出 runbook 的事故中指挥；
• 决定一次经验是否应升级为组织规则；
• 对系统结果承担最终责任。

这里有一个关键区别：

• 单环学习：在目标不变时修正动作，例如测试失败后修复代码；
• 双环学习：质疑目标、指标、边界和决策规则本身，例如发现测试通过却持续伤害用户后，修改成功定义。

Agent 可以广泛参与单环学习，也能为双环学习提供证据。但修改组织目标和风险边界，不能仅由正在优化这些目标的执行系统自行决定。

6.4 一张职责对齐表

问题	Agent	确定性控制平面	人类
目标与价值	澄清、发现冲突、生成选项	保存版本和责任主体	决定优先级与取舍
方案与实现	搜索、生成、实验、修正	隔离、预算、状态一致性	对关键架构与长期影响判断
验证	生成检查、执行证据、报告不确定性	强制运行、记录 provenance	判断 oracle 是否代表真实目标
权限	请求最小必要权限	实施授权与数据边界	批准不可逆和高外部性动作
发布	准备证据、执行预定义步骤	canary、限流、回滚、熔断	决定异常与超预算情形
事故	收集 trace、提出假设、执行 runbook	containment、凭据撤销、状态保护	指挥未知事件并承担责任
组织学习	聚类介入、建议测试或 skill	版本化、TTL、退役机制	决定什么应成为组织知识

---

七、哪些地方必须由人类检查和发力

人类介入的理由不应是笼统的“AI 还不够聪明”。更精确的判断是：有些问题缺少可被机器独立结算的目标，或者其后果无法通过当前环境充分排演。

7.1 目标冲突与需求歧义

当“正确”取决于以下问题时，需要人类：

• 速度、成本、质量和公平如何权衡；
• 多个利益相关者的目标哪个优先；
• 某个边缘用户是否值得增加系统复杂度；
• 临时兼容策略何时变成长期承诺；
• 一个指标改善是否真的代表产品价值。

Agent 可以整理立场、发现冲突、估计影响，但不能从事实中推出唯一的价值排序。

7.2 不可逆或高外部性动作

以下动作不应因为模型成功率提高而自然开放：

• 删除或不可逆迁移生产数据；
• 泄露后无法收回的敏感信息；
• 发送外部声明、邮件或法律承诺；
• 触发资金、物理设备或第三方交易；
• 改变公开 API、协议和长期兼容承诺；
• 扩大跨租户、跨仓库或跨组织权限。

这里的人类授权也必须具备信息量：动作主体、目标资源、数据来源、影响范围、不可逆部分和回滚边界都应清楚展示。

7.3 缺少独立 Oracle 的任务

如果实现、测试和 reviewer 都来自同一假设，测试通过不能完成验证。尤其需要人类深审的场景包括：

• 新产品语义；
• 全新架构边界；
• 安全威胁模型；
• 非功能属性的长期变化；
• 维护性与一致性；
• 需要数周或数月才显现的用户效果。

这里的人类价值不是逐行阅读所有代码，而是检查：

• 规格是否遗漏了重要维度；
• 证据是否与结论同源；
• 是否存在没有进入搜索空间的替代方案；
• 是否把不可测目标替换成了容易优化的代理。

7.4 超出既有 runbook 的事故

自动化非常适合预定义 containment：停止任务、撤销临时凭据、隔离流量、回滚已知版本。

但真正的新型事故需要：

• 判断哪些信号可信；
• 重新构造系统边界；
• 在不完整信息下分配优先级；
• 决定服务、数据、客户和调查之间的权衡；
• 识别事故是局部缺陷还是治理制度失效。

这是复杂系统中的“异常管理”，而不是普通执行。

7.5 保持组织现实感

人类还必须持续接触：

• 用户如何真正使用系统；
• on-call 中哪些失败最痛；
• 哪些测试经常误导；
• 哪些抽象让修改越来越难；
• 哪些自动化输出被团队默默忽略；
• 哪些“节省时间”只是把负担转移给下游。

如果决策者只看 Agent 生成的摘要，他们会逐渐管理一个由代理指标描述的组织，而不是实际组织。

---

八、不能只把人迁移成“边界作者”

一个很有吸引力的未来图景是：Agent 负责实现，人类负责写规格、不变量和风险边界。

这个方向总体正确，但不完整。

高质量边界并不是凭空产生的。它通常来自：

• 对实现细节的持续接触；
• 对失败和例外的记忆；
• 对用户后果的理解；
• 对历史权衡的把握；
• 对系统在极端条件下行为的直觉。

如果人类长期退出实现与诊断层，边界作者也会退化。他们可能很会维护昨天的规则，却无法发现规则已经不再描述今天的系统。

8.1 人类能力需要被主动再生产

成熟的 Agent 组织应把以下活动视为可靠性投资，而不是低效率：

抽样深审

不是对所有 diff 做全面浅审，而是随机或按风险选择少量任务，要求人类独立重建：

• 需求；
• 关键前提；
• 证据链；
• 替代方案；
• 长期影响。

深审结果用于估计自动化系统的静默错误，而不是只修复当前 PR。

无 Agent 演练

定期让团队在关键场景中不依赖主 Agent 完成：

• 故障诊断；
• 回滚；
• 凭据撤销；
• 核心服务恢复；
• 关键模块修改。

目的不是证明人类更快，而是验证组织仍然有接管能力。

独立诊断后比较

在高价值问题上，让人类与 Agent 在看到彼此结论前独立分析，再比较：

• 假设空间；
• 证据选择；
• 被遗漏的风险；
• 结论校准。

这比让人类只评论一份已经形成锚点的 Agent 答案，更能产生独立信息。

事故与近失事件复盘

复盘不能只增加一个测试。还要问：

• 为什么目标和边界允许这类错误发生？
• 哪些信号被忽略？
• 哪些组织激励放大了风险？
• 人类是否有足够信息和停止权？
• 同类问题是否会在其他系统复现？

轮岗与系统所有权

关键模块不能变成“只有 Agent 会修改”的区域。人类所有者需要持续承担一部分实现、性能分析、on-call 和架构演化工作。

8.2 人类 review 也有精度预算

“人类会认真看”不是一个可以靠流程规定成立的假设。

Google Tricorder 的公开实践对 code review 阶段的静态分析提出了很严格的有效误报要求：not-useful rate 达到约 10% 会进入观察状态，更高时可能关闭分析器。这个数字来自特定静态分析系统，不能直接当作所有 Agent 输出的统一阈值；但它说明一个普遍机制：低价值提示会理性地训练人类忽略系统。(Tricorder, ICSE 2015)

因此，应测量的不只是“是否有人批准”，还包括：

• 审批者是否改变过决定；
• 抽样深审发现了多少未显示信息；
• 告警和证据包的 not-useful rate；
• 人类能否在限定时间内正确识别高风险差异；
• 自动化失效时的接管成功率。

监督不是人数，也不是复选框；监督是一种有带宽、有精度、会退化的测量资源。

---

九、七层再生式 Agent 工程框架

可以把一个可持续 Agent 系统分成七层。每一层都回答不同问题，也应有不同的责任主体和工件。

第一层：价值与责任

核心问题：

• 为什么做这件事？
• 谁从中受益，谁承担风险？
• 哪些结果不能用其他收益抵消？
• 谁拥有最终停止权和问责责任？

主要工件：

• 价值目标；
• 风险预算；
• 不可接受后果；
• 决策责任人；
• 当前人工路径及其成本。

这一层不能被“模型成功率”替代。自动化和维持现状都必须出现在同一张账上：人工错误、延迟、专家注意力占用和知识单点同样是真实风险。

第二层：自治边界

核心问题：

• 动作是否可逆、可观测？
• blast radius 多大？
• 是否涉及敏感数据、外部承诺或第三方系统？
• 哪些权限是当前任务最小必要权限？

主要工件：

• 动作分类；
• 权限策略；
• 数据与网络边界；
• 升级条件；
• 撤销和 containment 机制。

自治等级不是成熟度阶梯。成熟系统完全可以永久允许文档修复自动合并，同时永久要求生产数据删除由独立责任人授权。

第三层：任务契约与规格

核心问题：

• 目标、非目标和不变量是什么？
• 哪些策略可以自由探索？
• 哪些行为被禁止？
• 完成需要哪些独立证据？
• 什么时候应承认信息不足并求助？

主要工件：

• 任务契约；
• 接口与数据契约；
• 可执行不变量；
• 资源预算；
• 完成证据和停止条件。

好的契约应“开放策略，明确边界”：不要机械规定实现步骤，但要明确可接受搜索空间。

第四层：执行与搜索

核心问题：

• 任务能否由确定性流水线完成？
• 哪些环节真的需要开放式 agency？
• 是否需要多个候选、并行子任务或多 Agent？
• 搜索何时停止？

主要工件：

• 最小 Agent 基线；
• 确定性流水线；
• 候选生成和选择策略；
• 预算与终止规则；
• 任务到配置的动态路由。

这里的原则是最小充分 agency。Agency 是为处理不可枚举搜索空间而付出的复杂度，不是先进程度的标志。

第五层：状态与协调

核心问题：

• 真值存在哪里？
• Agent 基于哪个 revision 和环境工作？
• 谁拥有写权限？
• 崩溃恢复后如何避免重复副作用？
• 多 Agent 如何避免旧状态和伪共识？

主要工件：

• 单一事实来源；
• revision 与环境快照；
• provenance；
• lease、单写者和幂等键；
• checkpoint 与未决风险；
• 乐观并发控制。

长期 Agent 首先是分布式系统问题，其次才是长上下文问题。能够恢复会话，不等于能够安全恢复任务。

第六层：反馈与可靠性

核心问题：

• 最快可靠反馈是什么？
• verifier 的盲区和错误相关性是什么？
• 生产中的慢反馈如何回流？
• 失败能否快速发现、限制和恢复？

主要工件：

• 编译、类型和目标测试等快速内环；
• 差分、属性、metamorphic 和参考模型等独立证据；
• canary、运行时不变量与自动回滚；
• MTTD、MTTR、静默错误与严重失败记录；
• 反馈债务和验证负载率。

Amazon S3 ShardStore 的公开案例说明，轻量参考模型、property-based testing 和模型检验可以成为日常工程资产，而不只是形式化方法专家的一次性项目。它仍是一个高投入存储系统案例，不能直接外推到所有应用代码，但足以说明验证资产可以持续参与生产开发。(ShardStore, SOSP 2021)

第七层：组织学习

核心问题：

• 哪些人工介入在重复出现？
• 哪些失败应成为测试、skill、边界或架构变化？
• 哪些知识已经过时，应主动删除？
• 人类接管能力是否仍然存在？
• 下一次同类任务是否真的更便宜、更安全？

主要工件：

• 事故和近失事件库；
• 带来源、版本和退出条件的 skill；
• memory 晋升与删除流程；
• 人类深审与演练结果；
• 自动化资产的复评和退役机制。

真正的学习闭环不只是“不断增加规则”。如果每次例外都生成一个永久规则，系统会逐渐堆积冲突、历史偏见和不可理解的流程。

学习必须同时具备两种能力：

• 积累：把可泛化经验提升为不变量、工具和测试；
• 遗忘：让特殊情况、过时知识和已无增量价值的 scaffolding 退出。

---

十、九条设计哲学

框架需要被压缩成可在日常设计中使用的原则。

10.1 自动化闭环，而不是自动化动作

“Agent 能修改文件”不构成自动化能力。一个可部署单元至少应包含：

• 行动；
• 可追溯反馈；
• 修正或拒绝；
• 停止条件；
• 恢复路径；
• 责任归属。

没有反馈与恢复的自动执行，只是远程副作用生成器。

10.2 优先提高系统可处理性，再提高模型聪明程度

如果仓库无法稳定构建、测试高度 flaky、接口语义模糊、环境不可复现，那么更强模型会更快撞上同样的墙。

Google 公开的 CI 数据曾显示，大规模测试体系中 flakiness 会主导大量 Pass→Fail 转换并消耗可观计算资源。这个结果来自特定时期和基础设施，不是 Agent 生产率实验；但对 Agent 的含义更严重：不稳定反馈会驱动自动调试循环朝错误方向振荡。(The State of Continuous Integration Testing @ Google)

10.3 使用最小充分 agency

任务形状可枚举时，优先使用确定性流水线。只有在以下条件出现时才增加 agency：

• 搜索空间无法预先枚举；
• 下一步取决于新证据；
• 多条假设需要动态竞争；
• 工具选择和计划必须随环境变化。

每增加一层 agency，也增加一层状态、终止、审计和失败模式。

10.4 让失败安全，也让失败有信息

可回滚不等于高质量失败。如果系统每次失败只恢复旧版本，却没有保留：

• 环境；
• 输入；
• trace；
• 假设；
• 被触发的不变量；
• 失败分类；
• 未决风险；

那么组织只避免了损失，没有获得学习。

再生式系统追求的是安全且有信息的失败。

10.5 证据异构优于意见冗余

三个共享相同模型、上下文和提示的 reviewer，可能只是一个检测器的三次采样。

高价值冗余来自不同机制：

• 一个目标测试；
• 一次新旧版本差分；
• 一个运行时不变量；
• 一次人类独立抽样；
• 一个延迟业务结果。

不要只统计 reviewer 数量，要统计错误相关性。

10.6 小批量是认知与风险的共同边界

小 diff 的价值不只是更容易 rollback：

• 更容易把结果归因到变化；
• 更容易获得独立证据；
• 更少占用 review 工作记忆；
• 更低的合并冲突；
• 更小的反馈债务；
• 更少把局部假设扩散成全局承诺。

DORA 研究长期把小批量、快速反馈和恢复与高软件交付绩效联系起来。它不证明任何团队都不存在速度与稳定性的权衡，但支持一个稳健方向：通过减小批量和恢复时间，吞吐与稳定性可以共同改善。(DORA metrics)

10.7 权限随可逆性、可观测性与外部性分配

权限不应只随模型能力提高而扩大。更合理的授权函数取决于：

• 可逆性；
• 可观测性；
• blast radius；
• 数据敏感度；
• 外部承诺；
• verifier 独立性；
• 人类接管能力。

模型更强，可以扩大候选生成和只读分析范围；它不自动获得删除数据和公开承诺的权力。

10.8 每个知识资产都应有失效条件

Prompt、skill、memory、grader、workflow 和 reviewer 规则都编码了某个时期对模型与环境的假设。

每个资产至少应回答：

• 解决什么失败模式；
• 在哪些模型、任务和版本上验证过；
• 来源和责任人是谁；
• 什么变化会使它失效；
• 如何检测它已无价值或开始有害；
• 如何退出而不破坏系统。

没有主动遗忘的学习系统，最终会被自己的历史淹没。

10.9 责任必须跟随信息权、控制权和撤销权

不能让一个只看到摘要的人为不可逆动作负责，也不能让一个无权停止系统的人承担事故责任。

当责任与控制分离时，组织会出现两种坏结果：

• 人类形式批准一切，实际忽略一切；
• 自动化拥有事实权力，责任却在事故后回流给最接近的人。

责任设计是系统架构，不是流程尾部的一行 owner 字段。

---

十一、怎样衡量再生，而不只衡量成功

成功率、成本和延迟仍然需要测量，但不足以回答系统是否在长期改善。

11.1 运行层指标

维度	指标示例	它回答什么
动作压力	候选到达率 (\lambda)、并发分支数	系统产生变化有多快
验证能力	验证服务率 (\mu_v)、负载率 (\rho_v)	反馈是否跟得上生成
反馈债务	(\lambda T_f)、队列年龄、未验证 WIP	在知道方向前走了多远
反馈可信度	flake rate、verifier 分歧、错误相关性	自动闭环是否会被错误信号驱动
错误逃逸	静默错误、严重失败、生产回滚	有多少错误穿过了证据链
恢复能力	MTTD、MTTR、rollback 演练成功率	失败是否被快速限制
人类负担	主动分钟数、深审时间、介入原因	是否真的节省稀缺注意力
监督质量	not-useful rate、抽样审计漏报、接管成功率	人类环节是否仍然有效

这些指标必须按任务类型、风险和版本分层。一个全局平均值会把“自动修复格式问题很成功”与“偶尔误改生产配置”混在一起。

11.2 验证资本指标

可以观察：

• 有独立可执行 oracle 的需求比例；
• 每次任务新增的有效回归检查；
• oracle 对历史缺陷与变异体的检出能力；
• 实现与 verifier 的机制独立程度；
• 新旧版本差分覆盖；
• 事故转化为系统性检查的比例；
• 同类任务再次发生时，证据准备成本是否下降。

“测试数量增加”不是验证资本增加。大量从实现直接翻译而来的测试，可能只提高代码覆盖而不提高错误检出。

11.3 人类能力资本指标

这类指标比较少见，但可以被操作化：

• 无 Agent 故障演练成功率；
• 关键模块拥有有效人类 owner 的比例；
• 人类独立诊断与最终根因的一致度；
• 新型异常从发现到形成正确心智模型的时间；
• 抽样深审发现静默问题的能力；
• 人类能否解释关键不变量及其来源；
• 接管时是否需要先向失效的 Agent 询问系统如何工作。

最后一项听起来讽刺，却是一个真实风险：自动化可能成为系统唯一的解释接口。

11.4 架构选择权指标

可以跟踪：

• 可替换接口和模块边界覆盖；
• 依赖与模型供应商集中度；
• 数据与协议迁移的退出成本；
• 公开承诺与内部实现的耦合程度；
• 决策记录是否包含前提、替代方案和退出条件；
• 重大变更能否分阶段暂停；
• 回滚是否只恢复代码，还是也恢复数据、流量和语义。

11.5 一个最重要的纵向问题

对同一类任务，持续观察：

完成第 (n+1) 次任务时，所需人类注意力和证据成本是否低于第 (n) 次，同时静默错误与共同故障风险没有上升？

如果答案长期为否，所谓“学习闭环”可能只是在收集日志和堆叠规则。

---

十二、哪些已经做得好，哪些仍需持续迭代

对 Agent 能力最有用的描述不是“会”或“不会”，而是成熟度与条件。

12.1 已经相对成熟的方向

在环境和验证条件合适时，以下方向已经有很高实用价值：

• 代码与文档检索；
• 调用点和依赖影响分析；
• 明确迁移指南下的机械修改；
• 编译、lint、类型和目标测试驱动的局部修复；
• 隔离分支中的候选实现；
• 重复实验、数据整理和证据包生成；
• 低风险、可回滚的维护任务；
• 为确定性流水线提供语言理解与代码生成能力；
• 将高频人工 toil 转化为可审查建议。

共同特征是：

• 目标相对明确；
• 上下文可以通过工具获得；
• 反馈快；
• 错误可丢弃；
• 结果有独立检查；
• 影响范围有限。

12.2 可以持续快速迭代的方向

以下能力正在改善，但不应被误写成已经解决：

知道何时求助

Agent 需要区分：

• 信息可通过工具获得；
• 需求真的存在不可消除歧义；
• 继续探索比提问更便宜；
• 风险已经超过自主决策阈值。

自报置信度只有在具体任务与风险层上经过校准后才有授权价值。

长期状态与恢复

长时间运行需要：

• 外部化任务状态；
• revision、环境和目标版本；
• lease 与所有权；
• 幂等恢复；
• 预算跨 session 保持；
• 未决风险不被乐观摘要丢失。

更长上下文本身不能解决分布式状态一致性。

语义 validation

编译和测试可以覆盖越来越多 verification，但“是否解决了正确问题”仍然困难。可执行规格、差分、参考模型和生产不变量会不断扩大自动化边界，但不能穷尽价值判断。

独立 review

未来需要从“另一个 Agent 看一遍”进化为：

• 不同模型或工具；
• 不同证据机制；
• 独立上下文；
• 隐藏审计样本；
• 实测错误相关性；
• 对 reviewer 自身进行校准。

Memory 与 skill 治理

难点不只是检索更准，还包括：

• 何时写入；
• 谁能晋升为组织知识；
• 冲突如何解决；
• 来源信任如何传播；
• 如何删除；
• 模型和环境变化后如何退役。

从离线分数到生产学习

Benchmark、历史回放、Shadow、Canary 和生产监控回答不同问题。它们应形成证据链，而不是由一个 leaderboard 分数替代全部部署判断。

12.3 仍需要更多人类介入的方向

在可预见阶段，以下任务仍需要强人类参与：

• 模糊或冲突的产品目标；
• 跨团队、跨组织的责任与优先级；
• 新架构和长期兼容承诺；
• 安全、隐私、合规和伦理边界；
• 不可逆或外部影响大的动作；
• 缺乏独立 oracle 的高价值决策；
• 反馈延迟很长的社会与业务结果；
• 超出 runbook 的事故；
• 修改指标、权限和治理制度本身；
• 判断哪些工作不应被自动化。

这里“需要人类”不等于人类应逐行完成全部工作。Agent 仍可搜索、模拟、比较和准备证据。不可委托的是最终的规范性判断与责任。

---

十三、一个可执行的采用顺序

再生式 Agent 工程不要求一次建设完整平台。更务实的顺序是：

第一步：先画出状态转换，而不是列职位

不要问“开发、测试或运维能自动化多少”，而要列出：

• Agent 将读取什么；
• 修改什么；
• 触发什么外部动作；
• 最快反馈是什么；
• 最坏后果是什么；
• 谁能停止和撤销。

自动化边界属于动作，不属于职位名称。

第二步：偿还环境债

优先建设：

• 可复现环境；
• hermetic build；
• 稳定且分层的测试；
• flake 检测与隔离；
• 结构化工具输出；
• revision 与 provenance；
• 小批量变更与可靠回滚。

这些投资在模型换代后仍然有效。

第三步：自动化高反馈、低外部性的内环

从以下任务开始：

• 只读分析；
• 隔离候选；
• 机械迁移；
• 目标测试修复；
• 证据整理；
• 低风险维护。

目标不是展示无人值守，而是建立真实的闭环数据。

第四步：为验证队列设置背压

在扩大生成前明确：

• 每个仓库允许多少未验收变更；
• 哪些候选会被自动拒绝；
• 哪些任务值得人工深审；
• 何时停止低价值重试；
• 队列积压时 Agent 是否应转去改善测试、文档和可观察性。

Agent 不应只会制造工作，也应能减少系统的未决工作。

第五步：按任务层分配权限

权限随任务属性变化，而不是随“Agent 产品成熟度”统一升级：

• 可逆且可观测：可进入受控自动执行；
• 可逆但不可观测：先投资检测；
• 不可逆但可观测：强证据与独立授权；
• 不可逆且不可观测：原则上不自主执行。

第六步：建立人类能力预算

明确保留：

• 抽样深审时间；
• on-call 与事故演练；
• 关键模块人工所有权；
• 无 Agent 恢复训练；
• 独立诊断与用户接触。

这不是自动化失败，而是对接管能力和边界设计能力的资本维护。

第七步：审计资本净变化

每个周期不仅问：

• 自动完成了多少任务；
• 节省了多少时间；

还要问：

• 新增了哪些可靠 oracle；
• 哪些重复人工介入已经下降；
• 哪些 memory、skill 和规则被删除；
• 人类是否仍能解释与接管系统；
• 架构选择权是增加还是减少；
• 下一个模型到来时，哪些投资仍然有效。

---

十四、这套观点也必须能够被证伪

“重视长期能力”“保持人类判断”“积累组织学习”很容易变成永远正确的口号。为了避免这种结果，再生式工程至少应接受以下反证。

14.1 验证资本没有复利

如果团队持续投资差分测试、参考模型、运行时不变量和可靠反馈后，同类任务的人类验收成本、静默错误与恢复时间没有改善，那么“验证资本会降低未来边际成本”的主张失败。

14.2 人类能力维护没有实际价值

如果抽样深审、无 Agent 演练、事故轮岗和独立诊断既不改善接管成功率，也不发现自动化系统的新型盲区，那么这些活动只是昂贵仪式，应被削减或重新设计。

14.3 异构证据没有降低共同故障

如果差分、不变量、属性检查和人类抽样组成的证据组合，与同质 LLM reviewer 相比没有降低静默错误，那么“机制多样性比 reviewer 数量重要”的主张被削弱。

14.4 架构选择权与长期结果无关

如果模块可替换性、分阶段迁移、决策记录和退出机制，与后续变更成本、事故恢复和供应商切换没有关系，那么把选择权作为工程资本缺少实证价值。

14.5 自动化收益主要只由模型决定

如果不同组织间的 Agent 收益几乎完全由模型版本解释，而与测试确定性、反馈延迟、回滚能力、任务契约和人类接管能力无关，那么本文过度估计了工程基质。

14.6 “再生”指标不能预测未来

最关键的检验是：验证资本、人类能力资本和选择权的代理指标，能否预测未来的交付速度、事故损失和迁移成本。如果不能，它们就不应成为新的管理装饰。

这些检验不要求每个组织得出相同答案。再生式工程不是固定架构，而是一组关于长期能力的可检验假设。

---

十五、结论：让每一次自动化都改善下一次变化

AI Agent 对软件开发的推动是真实而深刻的。

它降低的不只是编码成本，还降低了搜索、实验、重复执行和知识整理的成本；它让许多过去“不值得做”的验证与维护工作变得可负担；它也迫使仓库、接口、测试和权限系统变得更明确。

但 Agent 也把软件组织变成了一个更高增益的复杂控制系统。

动作更快、分支更多、并发更高之后：

• 不可靠反馈会造成更剧烈的振荡；
• 验证队列会比生成队列更早饱和；
• 同质模型会把共同盲点伪装成共识；
• memory 会把瞬时错误制度化；
• 人类审批会在缺少信息时退化成责任转移；
• 可回滚代码会掩盖不可逆的语义、承诺和能力流失。

因此，未来的软件工程师不会简单地从“写代码”转向“写 prompt”。更准确地说，工程工作的重心会转向设计：

• 什么目标值得优化；
• 什么证据足以支持行动；
• 什么边界必须由系统强制；
• 什么失败能够被安全吸收；
• 什么知识值得积累或遗忘；
• 什么权限和责任不能委托；
• 如何让人类在自动化之后仍然有能力理解、质疑和接管。

再生式软件工程提供的不是一个 Agent 架构，而是一个长期判据：

自动化完成之后，系统是否比之前更容易理解、验证、恢复和重新选择？

如果答案是肯定的，Agent 不只完成了一项工作，还增加了组织未来完成工作的能力。

如果答案是否定的，廉价生成可能只是把昂贵问题推迟到了 review、事故、迁移和下一代工程师身上。

最终，最值得追求的不是一个“足够聪明、因此可以被完全信任”的 Agent，也不是一个用无限护栏约束模型的僵硬系统，而是一种能够持续吸收模型进步、限制错误后果、保留人类判断并从每次变化中增长的工程结构。

一句话概括：

不要只让 Agent 更快地改变系统；要让每一次改变，都提高系统安全承受下一次改变的能力。

---

公开资料与延伸阅读

以下资料支持文中的不同局部命题。工程博客、预印本、案例研究和同行评审论文回答的问题不同，不应被压成单一“证据等级”。

Agent 接口、流水线与软件任务

1. Yang, Jimenez et al., SWE-agent, NeurIPS 2024：说明 Agent-Computer Interface 的窗口、搜索输出和编辑反馈等设计可以显著影响软件任务表现；报告的 64% 是特定设置中的相对提升。(论文)
2. Xia et al., Agentless, FSE 2025：在特定 SWE-bench 设置中展示确定性定位—修复—验证流水线的竞争力；支持把流水线作为强基线，不支持所有任务都不需要 agency。(论文)
3. Brown et al., Large Language Monkeys：展示有可靠 verifier 与缺乏可靠选择器时，额外采样兑现为最终结果的能力不同；属于预印本。(论文)

可执行规格与验证资本

1. Bornholt et al., ShardStore, SOSP 2021：可执行参考模型、property-based testing 与模型检验在 Amazon S3 存储节点中的生产实践；是高投入系统案例，不能无条件外推。(论文)
2. Segura et al., A Survey on Metamorphic Testing, TSE 2016：系统总结 metamorphic testing 如何缓解 oracle problem。(论文)
3. DeepSeek-AI, DeepSeek-R1, Nature 2025：讨论规则化奖励与神经奖励模型的 reward hacking 风险，支持可靠 verifier 对搜索和学习的重要性。(论文)

反馈、审查与人因

1. Micco, The State of Continuous Integration Testing @ Google, ICST 2017 keynote：大规模 CI 中 flakiness、重跑和 Pass→Fail 信号的数据；不能直接当作 Agent 效果估计。(演讲材料)
2. Sadowski et al., Tricorder, ICSE 2015 / CACM 2018：Google 静态分析平台对 code review 提示可用性与误报的工程标准；10% 不是通用 Agent 阈值。(ICSE, CACM)
3. Bainbridge, Ironies of Automation, Automatica 1983：自动化监控、技能退化和异常接管的经典人因分析。(论文)
4. Parasuraman & Riley, Humans and Automation, Human Factors 1997：讨论 automation use、misuse、disuse 与 abuse。(论文)

安全、Memory 与治理

1. Greshake et al., Indirect Prompt Injection：展示外部数据中的指令如何影响集成 LLM 应用。(论文)
2. Chen et al., AgentPoison, NeurIPS 2024：针对长期 memory/RAG 的定向污染研究；攻击设置不代表所有生产实现的实际发生率。(论文)
3. NIST Generative AI Profile：覆盖 prompt injection、data poisoning、持续监控与事件响应的风险管理框架。(NIST AI 600-1)
4. Saltzer & Schroeder, The Protection of Information in Computer Systems：least privilege、fail-safe defaults、separation of privilege 与 economy of mechanism 的经典来源。(论文)

交付系统与组织生产率

1. DORA software delivery performance metrics：将吞吐与不稳定性共同纳入软件交付绩效，强调小批量、反馈和恢复。(资料)
2. Brynjolfsson, Rock & Syverson, The Productivity J-Curve, AEJ: Macroeconomics 2021：通用技术需要流程、组织和人力等互补无形资本；它提供机制框架，不保证任何 Agent 投资未来必然转正。(论文)
3. METR, Early-2025 experienced open-source developer RCT 与 2026 update：展示 benchmark 能力、主观体验和端到端生产率可能不一致；早期 19% slowdown 已被发布者标记为过时，后续点估计转正但不确定性和选择偏差仍然很大。(2025 研究, 2026 更新)