Agent 与软件工程
Coding Agent 不是“自动补全的进化”，而是软件工程流程里多了一个不知道疲倦、需要管理的工程参与者。这一节讨论流程本身如何被改变。
工作流的变迁：从补全到委托
Agent 进入编码的方式经历了四代：
- 补全（Copilot 式）：行内续写，人是唯一作者。
- 对话式修改：贴报错、要片段，人负责所有上下文与集成。
- 任务委托：整个 issue 交给 Agent，产出 PR，人做评审。Agent 自主探索仓库、跑测试、多轮迭代。
- 流程自动化：Agent 值守 CI（自动修 flaky 测试）、做代码评审、维护依赖升级——软件工程流水线的一部分。
第四代是当下的前沿，也是本节的主题：当 Agent 成为流程参与者，工程实践要随之调整。
变化一：仓库开始“为 Agent 写文档"
AGENTS.md（以及同类约定）正在成为仓库标配：构建命令、测试入口、目录结构、代码规范、禁区——写给 Agent 看的项目说明书。这带来一个有趣的转变：文档的读者扩展了，写好文档的收益直接体现在 Agent 的产出质量上。很多团队的切身体会：为 Agent 写清楚 README 的过程，顺手治好了“文档年久失修”的老病。
变化二：评审成为人的核心工作
当实现被委托，人的精力从“写”转向“验”与“审”：
- 验收标准的编写成为一等技能：写清 Goal（验收条件、边界、禁区）的质量，直接决定委托产出（见 Planning 与 Goal）。
- 代码评审的比重上升。人从作者变成评审者，需要更擅长快速建立对大 diff 的全局理解。
- 评审 Agent 上岗：让另一个 Agent 以挑剔视角预审 diff（找漏洞、查边界条件），人只处理它标记的问题。实践中的有效模式是派一个独立上下文的评审 Agent——没有作者立场，比“自己检查自己”可靠得多。
变化三：测试的地位进一步上升
可验证性是 Agent 发挥的前提（这正是编程是 Agent 主场的原因，见 Coding Agent 一章）。工程上的推论：
- 测试是给 Agent 的护栏：测试覆盖越全，Agent 自主迭代的空间越大——它能在没有人的情况下发现并修正自己的错误。
- 测试是 Loop 的出口：把“测试通过”写进 Goal，Agent 就有了机器可判的完成标准。
- 反之，没有测试的代码库不适合委托：Agent 改完无法自证正确，人审也没法审——先补测试，再上 Agent。
变化四：规模化的新问题
Agent 大量参与后出现的新挑战：
- PR 洪流：并行 Agent 产出大量 diff，评审带宽成为瓶颈。对策：按风险分级（小改动自动合并、核心模块必须人审）。
- 风格漂移与架构侵蚀：每个 Agent 都局部合理，累积起来偏离架构意图。对策：架构决策记录（ADR）与禁区清单进
AGENTS.md，CI 加架构守护规则。 - 安全审查不可省略：Agent 生成的代码可能引入依赖投毒、注入漏洞——安全扫描必须进流水线（见安全与权限）。
一句话总结
软件工程没有被 Agent 取代，而是发生了分工迁移：人上移到目标、架构与评审，Agent 下沉到探索、实现与迭代。这恰是本教程反复出现的模式——把可验证的部分交给机器，把判断留给人。