Appearance
AI 编程进入 Agent 时代：变化的不是输入框，而是软件生产方式
系列第 01 篇
面向读者：有 Git、测试和团队开发经验的职业开发者
最后核验：2026-07-20
对应视频：第 06 集《AI 编程进入 Agent 时代：从代码建议到可验证交付》
很多人第一次使用 AI 编程工具时，会把它理解成“更聪明的自动补全”：输入一句自然语言，工具吐出一段代码，开发者复制、运行、修改。这个理解在早期并没有错，但它已经不足以解释今天的产品。当前主流工具不只生成文本，还能搜索整个仓库、编辑多个文件、运行终端命令、控制浏览器、读取测试结果、创建分支，甚至在云端工作几十分钟后提交一组可审查的改动。
这意味着 AI 编程的基本单位正在变化。过去的基本单位是“一次建议”或“一段代码”，现在越来越接近“一项软件任务”。当基本单位扩大，风险也随之扩大：一行补全错误通常会在开发者眼前暴露；一个 Agent 错误理解业务边界，却可能同时修改接口、测试、配置和依赖，并用一段流畅的自然语言告诉你它已经完成。
本文建立整套系列最重要的心智模型：AI 编程不是让模型代替工程师敲键盘，而是让一个具备行动能力、但仍会犯错的软件执行体进入研发流程。我们要设计的不是一句“万能 Prompt”，而是它工作的环境、权限、反馈和停止条件。
阅读路线：先看全局，再进入机制
视频版先展示整章地图，再逐层展开。博客沿用同一判断顺序，但保留更多机制、案例、失败模式和生产边界：
- 能力演进：区分补全、Chat、同步 Agent、Cloud Agent 与 Review Agent 的责任变化。
- 工程闭环：把模型放回任务契约、工具反馈、测试和审查组成的控制系统。
- 任务适配：用可描述性、可验证性和破坏半径决定自治上限。
- 生产边界：把团队采用、权限和交付责任落到可执行门禁。
这四步不是目录装饰，而是一条决策链：能力演进 → 工程闭环 → 任务适配 → 生产边界。阅读后面的案例时，可以随时回到这条链判断当前问题发生在哪一层。
真实问题：为什么同一个工具有时惊艳，有时制造返工
设想两个任务。
第一个任务是“给这个已有校验器补三个边界测试，并运行相关测试”。相关文件明确，成功标准由测试给出，Agent 可以读取现有测试风格，新增用例，然后根据红绿结果调整。即使第一次生成不正确，失败信息也会把它拉回轨道。
第二个任务是“重构订单系统，让它更优雅、更稳定”。什么叫优雅？允许改变接口吗？数据库能迁移吗？稳定具体指吞吐、可用性还是错误恢复？如果没有业务背景和验收方式，Agent 只能用训练数据中的常见模式补全这些空白。它可能创建很多结构正确的代码，却解决了错误的问题。
差异并不主要来自模型智商，而来自任务的可描述性与结果的可验证性。这是判断 AI 编程风险的第一原则。
图 1 展示的是能力范围扩大，而不是旧能力被彻底淘汰。补全仍然适合写局部样板；Chat 仍适合解释概念；同步 Pair 适合边探索边澄清；本地 Agent 适合在真实仓库中完成小任务；Cloud Agent 适合边界清晰、环境可重建的异步任务；Review Agent 则提供第二视角。成熟使用方式不是永远选择最高自治，而是为任务选择最低但足够的自治级别。
机制：从建议系统到行动系统
1. 自治级别改变人的介入位置
代码补全中，模型只提出候选文本，开发者逐段接受。局部编辑中，开发者指定文件和选区，AI 决定具体改法。同步 Agent 中，人给出任务目标，Agent 自行搜索、编辑、运行命令，但开发者持续观察。异步 Agent 中，人往往只在开始时定义任务、结束时审核结果。到了自动化阶段，Agent 可能由 Issue、告警或定时事件触发，人的职责上移为制定策略和门禁。
自治越高，越不能依赖“我会盯着它”。同步会话中的误操作可以在下一秒被打断；云端任务可能已经运行十几分钟并产生多个提交。此时需要用分支、沙箱、网络白名单、短期凭据、CI 和审批替代持续注视。
一个实用判断是：如果任务失败后你无法快速识别错误，也无法低成本回退，就不应该直接提高自治级别。自治不是奖励模型能力，而是对任务可控性的判断。
2. Agent 是一个完整系统
把 AI 编程等同于模型，会导致错误的工具比较和错误的改进方向。一个 Coding Agent 至少包含六层：
- 目标与约束：当前任务、非目标、验收标准。
- Harness：组织对话、工具循环、权限、重试与上下文。
- 模型：理解信息，产生下一步动作候选。
- 工具：搜索、读写文件、终端、浏览器、MCP。
- 反馈：编译错误、测试、日志、截图和 Diff。
- 治理：沙箱、审批、分支保护、审计和责任人。
同一个模型放进不同 Harness，会表现得像不同产品。有的工具擅长精确应用 Diff，有的擅长在大仓库检索，有的提供浏览器验证，有的提供远程隔离环境。模型升级当然重要，但仓库是否能稳定构建、测试是否能给出清晰信号、工具是否容易被正确调用，往往同样决定最终结果。
3. 人、Agent 和确定性工具各自擅长什么
AI 擅长快速遍历候选、识别常见模式、连接分散上下文和执行重复修改；它不天然拥有团队未写下来的业务事实，也不能为产品取舍和风险承担责任。确定性工具擅长回答格式、类型、编译、测试和扫描能覆盖的问题，但它们不会自行理解为什么要改。人类则擅长目标选择、冲突权衡、例外判断和责任确认，却不适合手工完成大量机械变更。
合理分工不是“AI 写代码，人检查语法”，而是：人定义什么值得做、哪些边界不能破坏；Agent 收集事实并执行候选方案；编译器和测试提供不可争辩的反馈；Reviewer 检查工具覆盖不了的业务和系统风险；Owner 决定是否交付。
4. 生成代码只是闭环中的一个环节
一项可靠任务通常经过六步：任务契约、探索、计划、实现、验证、审查。小改动可以合并探索和计划，但不能省掉目标与验证；复杂功能可以产生正式 Spec，但仍需要回到具体可执行任务。
这里最容易被忽略的是探索。Agent 如果不读真实实现，就会根据文件名、框架常识或用户描述猜测系统结构。另一个常被忽略的是验证：如果任务没有可运行的完成检查，Agent 只能用“代码看起来合理”作为停止条件。自然语言自述不是证据，测试退出码、实际 HTTP 响应、截图对比或性能数据才是。
5. 可描述性与可验证性决定委托上限
四个象限可以直接用于任务分流：
- 清晰且可验证：局部缺陷、补测试、机械迁移、明确接口，最适合 Agent。
- 清晰但难验证：视觉审美、主观文案、复杂性能猜测，需要更密集的人机协作。
- 模糊但可验证：可以先做实验，通过反馈逐步澄清，不宜一开始大范围修改。
- 模糊且难验证：产品方向、核心架构、跨组织规则，应先由人完成决策与规格工作。
“AI 能不能做”不是最好的问题。更好的问题是：如果它做错了，系统多快能发现？谁能判断？回退成本多大？
6. 同步与异步是两种不同控制方式
同步 Agent 贴近本地环境，开发者可以在它搜索错误目录时立即纠偏，适合陌生仓库、需求尚在形成和需要频繁决策的任务。异步 Agent 在隔离环境中工作，适合依赖齐全、任务边界稳定、检查可以自动运行的任务。异步的优势是减少等待并允许并行，代价是环境重建、上下文交接和最终审核更重要。
两者都不应该绕过 Git。同步 Agent 需要可回退的工作区或 worktree；异步 Agent 应只在专用分支上提交。所谓“后台完成”只是改变工作发生的位置，不改变代码进入主干的责任链。
7. Vibe 原型不是生产交付
Vibe Coding 降低了表达软件想法的门槛：描述想要的界面或流程，运行，看结果，再按感觉调整。对于原型、一次性脚本和低风险内部工具，这种方式很有价值。问题出现在“能运行”被误解为“可以生产使用”。
生产化至少要补回行为规格、错误路径、数据边界、权限、测试、依赖治理、可观测性、部署与回滚。原型证明的是价值假设，生产系统要证明的是在明确条件下持续提供正确行为。这是两种不同的完成定义。
一个可运行的最小工作方式
即使还没有配置复杂 Rules 或 MCP，也可以从下面的任务结构开始：
text
目标：修复用户退出后仍可访问个人资料的问题。
背景：请求 GET /api/profile 在 session 失效后仍返回 200。
范围：auth middleware、profile endpoint 及相关测试。
非目标：不重构整个 session 模块，不改变登录协议。
验收：无有效 session 返回 401；有效 session 仍返回 200。
验证：先补失败集成测试，再运行 auth 模块和全量测试。
交付：说明根因、改动、测试证据和剩余风险。这个 Prompt 并不“聪明”，但它把任务变成了可执行合同。接下来可以要求 Agent 先只读探索：定位 middleware、路由、现有测试与 session 失效逻辑；确认调用链后再给计划；计划通过后才允许编辑。这样做的价值不在于增加步骤，而在于把最昂贵的方向错误提前暴露。
三种团队采用路径
不同团队不必从同一个入口开始。维护成熟后端服务的团队，通常先从补测试、解释调用链和局部缺陷进入，因为这些任务的正确性最容易由现有 CI 判断。前端或产品原型团队可以先用同步 Agent 和浏览器验证，把自然语言意图快速转成可交互版本，但进入主干前仍要补组件约束、响应式检查和可访问性。平台团队则可能直接关注 Cloud Agent、自动 Review 和组织策略，但前提是仓库已经能在隔离环境中稳定安装、构建和测试。
第一阶段的目标不应是“让所有开发者都用”，而是找到两到三类任务，建立人工基线，记录 Agent 运行时间、人工主动时间、审查时间、返工次数和缺陷。第二阶段再把重复出现的仓库事实写进 AGENTS.md，把复杂流程封装为 Skill，把机械检查放进 Hook 或 CI。第三阶段才考虑异步和并行，因为只有此时团队知道哪些输入足以让任务独立运行。
采用过程还需要保留退出机制。某个任务连续两次偏离、验证环境不稳定、需要高权限生产数据，或 Reviewer 无法在合理时间理解 Diff 时，应把 Agent 降回只读研究或局部辅助。成熟度不是自治不断上升，而是团队能够根据任务风险随时升降自治，并清楚说明为什么。
团队还要避免把“AI 生成比例”设为绩效目标。这个指标会鼓励扩大 Diff、减少人工重写，却无法说明用户价值、质量或总成本。更可取的目标是缩短可验证任务的交付周期、减少重复劳动，同时保持或改善首次 CI 通过率、Review 返工和发布后缺陷。
失败模式
失败一：直接要求“完成整个项目”
空仓库生成演示应用通常很顺畅，因为几乎没有隐性约束。真实 Brownfield 仓库则包含兼容、历史数据、组织边界和部署约束。一次性让 Agent 处理整个功能，会把每个未写明的条件都变成模型假设。修正方法是拆成探索、规格、接口、实现和验证节点，并让每个节点有独立产物。
失败二：把 Agent 的解释当成事实
Agent 可能说“所有测试已经通过”，但实际只运行了一个测试文件；也可能说“保持了向后兼容”，却没有检查消费者。要求它报告命令、退出码、断言数量和未运行项；重要路径由外部工具再次执行。
失败三：自治越高越先进
开发者容易用“能否无人值守”衡量工具。实际上，模糊需求中的频繁人工交互不是失败，而是正确的控制方式。只有任务清晰、环境可复现、结果可验证、权限可隔离时，后台运行才真正节省注意力。
失败四：为了让测试通过而修改测试
如果任务只说“让 CI 变绿”，Agent 可能放宽断言、屏蔽错误或跳过测试。任务契约必须写明行为目标和禁止事项，并审查测试是否在修复前真实失败、修复后因正确原因通过。
失败五：把所有信息都塞进上下文
上下文不是越多越好。大量无关文档和日志会挤占真正约束，增加错误工具选择。稳定知识进入仓库规则，低频流程进入 Skill，当前代码按搜索结果加载，长日志只保留与错误相关的片段。
生产边界
Agent 可以被允许搜索、编辑和运行测试，但生产凭据、资金动作、权限变更、数据库破坏性操作和发布审批必须有更强边界。自然语言规则只能影响行为，不能替代文件系统隔离、网络白名单、短期凭据、分支保护和 CI。
对于身份、支付、隐私、基础设施和安全修复，至少需要独立 Reviewer、确定性扫描、明确回滚和责任人批准。即使工具生成了大部分代码，提交者仍需理解变更的行为、限制和证据。
实践清单
- [ ] 先判断任务的可描述性与可验证性。
- [ ] 为任务选择最低但足够的自治级别。
- [ ] 写清目标、范围、非目标、验收和验证命令。
- [ ] 复杂任务先只读探索，再评审计划。
- [ ] 使用分支或 worktree 隔离 Agent 改动。
- [ ] 给 Agent 一个能读取的 Pass/Fail 检查。
- [ ] 审查 Diff，而不是只看最终自然语言摘要。
- [ ] 区分本地通过、真实路径通过和远程已发布。
- [ ] 高风险动作使用沙箱、审批和最小权限。
- [ ] 把重复错误沉淀为规则、测试或确定性工具。
读完之后，你应该能完成什么
- 能为一项任务选择最低但足够的自治级别。
- 能解释模型能力与 Agent 系统能力为什么不是同一件事。
- 能识别哪些任务应先澄清而不是立即生成。
- 能为团队试点定义证据、退出和责任边界。
如果只能复述概念，却不能完成上述动作，说明还没有把内容转化成工程能力；可以回到对应机制图、失败模式和实践清单重新核对。
小结
Agent 时代真正的新能力，是让模型进入“读取环境—采取动作—读取反馈”的循环。真正的新风险，也是它能够在错误理解下产生真实动作。成熟的 AI 编程实践不会围绕一个万能模型建立，而会围绕任务契约、上下文、工具、验证和责任边界建立。
下一篇将深入 Agent 内部：Harness 怎样组织工具调用，上下文窗口为什么会退化，权限系统怎样参与每一步，以及 Agent 为什么会在没有证据时提前宣布完成。