连续半年只用 Agent 写代码，开发者终于找到了边界

截至 2026 年 8 月 27 日，AI Agent 已经从“帮我补一段函数”进入“替我推进整个开发任务”的阶段。问题也随之变了：开发者不再只关心模型能不能写出代码，而是关心一套完全由 Agent 驱动的工作流，能不能长期运行、能不能维护、能不能在出错后找到责任链。

一位开发者在连续半年只使用 AI Agent 编写代码后，公开复盘了这段经历。这里的“只使用 Agent”不是把编辑器换成带聊天框的 IDE，而是把需求理解、代码搜索、方案设计、实现、运行测试和部分调试都交给编码 Agent，人类主要负责确定目标、提供约束和验收结果。

这份复盘最有价值的结论是：Agent 编程的瓶颈已经从“模型会不会写代码”，转向“开发者能不能设计一套让模型持续犯小错、快速暴露、容易回滚的系统”。

Agent 编程不是自动补全，而是任务委托

AI Coding Agent 是一种能够读取代码库、调用开发工具、修改文件并运行验证命令的模型驱动软件系统。它和传统代码补全的差别，在于它处理的是一段任务，而不是一个光标位置。

传统补全通常回答“这一行代码应该怎么写”，Agent 则要回答“为了完成这个需求，我接下来应该查哪些文件、修改哪些模块、运行哪些测试”。前者的上下文主要是光标附近的代码，后者的上下文包括项目结构、依赖关系、历史约定、命令输出和当前任务状态。

这意味着 Agent 的工作质量取决于闭环，而不是某一次生成结果。一个完整闭环至少包括以下步骤：

• 理解任务目标和验收标准；
• 在代码库中定位相关模块和调用链；
• 形成足够小、可以验证的修改计划；
• 编写代码并处理编译、类型检查或静态检查错误；
• 运行测试和真实场景验证；
• 汇总变更、风险和仍未解决的问题。

如果其中任何一个环节缺失，Agent 都可能交付一份“看起来合理”的代码。它可能通过格式检查，却改变了隐含的业务行为；也可能补上了测试，却只是把自己的实现重新验证了一遍。

半年实践后的第一个变化：人从写代码变成管上下文

上下文管理是 Agent 编程中比提示词技巧更重要的基础能力。上下文管理是指把项目规则、任务状态、代码事实和历史决策按优先级提供给模型，让它在正确时间看到正确信息。

开发者在实践中形成了一套相对固定的启动流程。每次打开项目，Agent 先加载工作协议，再读取开发流程、资源索引和任务状态，而不是等待人类把背景信息一段段重新粘贴进去。

这种做法解决了一个常见问题：长对话并不等于完整记忆。对话越长，早期约束越容易被压缩、遗漏或混入新的临时结论。把关键规则写入稳定文件，把任务进度写入可持久化的状态文件，Agent 才能在新会话中恢复工作，而不是每次从零开始猜。

一个实用的上下文分层可以这样理解：

| 层级 | 内容 | 适合放置的位置 | 主要作用 | |---|---|---|---| | L1 | 不可违反的安全规则、架构边界、禁止操作 | 系统级配置或项目根目录规则 | 防止越界和误操作 | | L2 | 代码规范、测试命令、模块约定、领域术语 | 项目级说明文件 | 约束日常实现 | | L3 | 当前任务背景、临时假设、调试记录 | 任务文件或动态上下文 | 支撑当前工作 |

这个分层有一个容易被忽略的细节：关键约束不能只放在动态历史里。动态历史会被截断、总结或压缩，而“不能修改数据库迁移”“不能绕过权限校验”这类规则一旦丢失，后果不是回答质量下降，而是直接产生错误变更。

上下文的目标也不是越多越好。十几个工具的参数说明、几千行无关日志和一整套历史对话，会让模型在真正开始解决问题前，先消耗大量注意力阅读说明书。更有效的做法是把长期信息落盘，把当前任务压缩成摘要和待办，只在需要时加载相关文件。

第二个变化：工具越多，Agent 不一定越强

工具设计决定了 Agent 的决策难度。工具设计是指为模型提供文件读取、搜索、编辑、测试、版本控制和外部系统访问能力时，对工具边界、参数格式和副作用做出的工程安排。

很多团队的第一反应是把能力拆得越细越好：读取文件有一个工具，按名称搜索有一个工具，按正则搜索又有一个工具，查看目录、查看符号、查看依赖各自再做一个工具。这样看上去更加“原子化”，但模型需要在更多相似选项中做决策。

过度原子化会带来三类成本。

第一，决策链变长。本来一次明确的代码搜索，可能被拆成列目录、读取文件、筛选名称、再次读取四步。每多一次调用，就多一个参数错误、路径错误或理解偏差的机会。

第二，工具 Schema 会吞噬上下文。Schema 是工具的参数定义、类型约束和说明信息。工具数量增加后，模型还没有执行任务，就要先理解一整套接口；当多个工具名称和参数高度相似时，模型可能选择错误工具，或者只关注部分描述。

第三，维护成本会快速上升。每一个工具都需要独立测试、错误处理和边界条件，重复逻辑还会分散在多个入口中。FindByName 和 FindByPattern 如果有 80% 的实现相同，维护两份逻辑并不会让 Agent 更可靠，只会增加行为不一致的可能。

更合理的工具边界取决于“使用频率”和“行为确定性”。高频且确定的动作应该做成清晰的原子工具；带有副作用的动作需要审批、预览或回滚机制；低频且不确定的动作可以保留为兜底能力，但必须明确禁止哪些操作。

| 工具类型 | 典型操作 | 推荐设计 | 原因 | |---|---|---|---| | 高频、确定、无副作用 | 搜索代码、读取文件、运行类型检查 | 明确、稳定、参数少 | 降低决策成本 | | 中频、带副作用 | 修改文件、提交变更、更新配置 | 支持预览、差异查看和回滚 | 控制误操作风险 | | 低频、复杂、不确定 | 执行脚本、访问外部系统 | 作为受限兜底工具 | 避免把高风险能力暴露为默认路径 |

工具返回结果也应该标准化。无论工具执行成功还是失败，都应让 Agent 清楚看到状态、结构化数据、可读文本和错误原因，而不是从一段混合字符串中猜测发生了什么。协议稳定之后，模型才有可能稳定地处理异常。

第三个变化：复杂 Agent 架构很容易把问题放大

多 Agent 并不天然优于单 Agent。多 Agent 架构是把一个任务拆给多个具有不同角色或工具权限的模型实例，再通过调度器传递状态和结果。

在真实项目中，复杂架构经常先带来更多状态流转：规划 Agent 生成计划，执行 Agent 修改代码，审查 Agent 检查结果，测试 Agent 再运行验证，最后由汇总 Agent 整理报告。只要其中一个环节丢失上下文、误解字段或错误总结，后续 Agent 就会在错误前提上继续工作。

这类问题尤其难排查，因为最终报错的位置通常不是根因所在。一个读取文件失败的问题，可能在多个 Agent 之间被转述成“文件不存在”，再被计划器解释为“需要新建模块”，最终变成一组完全不必要的代码修改。

开发者后来选择推倒重来，把主干流程精简到最短链路：一个主要 Agent、少量高质量工具、明确的任务状态、可重复的验证命令，以及人在关键节点进行确认。这种方案看起来不如多 Agent 系统先进，却更容易回答三个问题：Agent 做了什么、结果是什么、为什么这么做。

可观测性是 Agent 工程的基本设施。可观测性是对模型调用、工具调用、返回结果、决策理由和失败路径进行完整记录，使开发者能够重建一次任务执行过程。

只记录成功路径是不够的。失败轨迹往往包含最有价值的信息，例如：

• Agent 为什么选择了某个工具；
• 工具实际返回了什么；
• 哪一步开始出现了错误假设；
• 模型是否忽略了测试失败；
• 它是否在没有新信息的情况下重复执行同一个动作。

没有 Trace 的 Agent 系统，出了问题只能重新问模型“你刚才为什么这么做”。有 Trace 的系统，开发者可以像排查分布式服务一样定位调用链、返回链和决策链。

最危险的误区：先写代码，再让 Agent 给自己补测试

测试只有在能够挑战实现时才有验证价值。测试验证价值是指测试能否独立发现实现中的错误，而不是仅仅证明当前代码按照自身假设运行。

让 Agent 先完成实现，再由同一个 Agent 紧贴实现补测试，是半年实践中最容易踩的坑之一。模型已经在实现阶段形成了对需求的解释，随后编写测试时往往会沿用同一套假设。结果是测试覆盖了代码路径，却没有覆盖真正的业务风险。

例如，一个分页接口错误地把页码当成了偏移量。Agent 可能先写出这个实现，再写一个输入页码为 1、预期返回第一批数据的测试。测试自然通过，但它没有验证第二页、边界页和总数变化，错误也就被测试“合法化”了。

更可靠的测试流程应该先从需求和已有行为出发：

1. 先定义外部可观察的行为，包括正常路径、边界条件和失败场景；
2. 优先寻找真实数据、旧版本行为、接口契约或用户报告作为参照物；
3. 让 Agent 实现代码，但保留独立的验收标准；
4. 运行测试、类型检查、静态分析和必要的端到端流程；
5. 对通过的结果进行抽样人工检查，重点看测试是否真的可能失败。

测试的独立性比测试数量更重要。几十个只验证 mock 返回值的测试，不如几个来自真实输入和历史 bug 的回归用例。Agent 可以帮助生成测试，但不能同时垄断需求解释、实现假设和最终裁判三个角色。

Agent 最适合什么任务

Agent 在边界清晰、反馈快速、结果可验证的任务上最有价值。一个任务是否适合交给 Agent，可以从四个条件判断：是否有参照物、是否能自测、是否存在架构蓝图、是否有人负责最终方向。

| 任务类型 | Agent 适配度 | 适合原因 | 人类仍需负责的部分 | |---|---:|---|---| | 有完整测试的业务模块修改 | 高 | 反馈快，回归范围清楚 | 判断行为是否符合业务目标 | | 重复性较高的迁移和重构 | 中高 | 规则可以明确表达 | 设计迁移顺序和回滚方案 | | 新增简单 CRUD 或后台页面 | 高 | 接口和页面结构相对标准 | 审核权限、异常和交互细节 | | 没有参照物的核心架构设计 | 中低 | 需求不确定，错误成本高 | 确认边界、取舍和长期约束 | | 涉及安全、支付、数据删除的操作 | 低 | 副作用大，难以仅靠测试覆盖 | 人工审批和独立审计 | | 跨多个遗留系统的排障 | 中 | Agent 能扩大搜索范围 | 验证因果链，避免相关性误判 |

Agent 不擅长替团队做产品判断。它可以根据描述实现一个权限系统，却无法独立决定哪些角色应该拥有权限；它可以重构一套接口，却无法知道某个看似冗余的字段是否被外部客户依赖。代码任务越接近“已知问题、明确约束、可执行验证”，自动化收益越高；越接近“定义问题和承担后果”，人类参与越不可替代。

这套工作流真正改变了什么

Agent 编程改变的不是开发者是否写代码，而是开发者把时间花在哪里。过去，人可能用一上午定位调用链、修改样板代码，再用半小时处理格式和类型错误；现在，Agent 可以压缩这些机械环节，开发者则需要投入更多时间描述目标、审查差异和补充验证。

因此，效率不能只看“生成了多少行代码”。更有意义的指标包括任务从开始到可合并的时间、返工次数、回滚次数、线上缺陷数、测试失败被发现的阶段，以及开发者审查一次变更所需的时间。

已有行业调查也提醒开发者，AI 编码工具的普及率并不等于生产力线性增长。补充材料提到的一项覆盖 12 万名开发者、450 家公司的数据中，92.6% 的开发者每月使用 AI 编码助手，但每周节省时间中位数仍约为 4 小时。工具相同、事故结果却可能相反，说明组织流程、代码库质量和验收机制比“是否接入 Agent”更关键。

半年实践后的合理结论不是“以后不用程序员了”，也不是“Agent 只能写玩具代码”。更准确的说法是：程序员的核心工作正在从逐行生产代码，转向定义系统边界、组织上下文、设计反馈回路和承担最终判断。

给开发者的落地建议

第一，先让 Agent 在一个可回滚的小项目里跑通闭环。不要一开始就接入生产数据库、部署系统和所有内部工具。先验证它能否稳定完成搜索、修改、测试和报告。

第二，把项目规则写成模型可以持续读取的文件。规则应包含目录结构、常用命令、不可触碰的边界、测试入口和提交要求，而不是一份没人维护的长篇开发手册。

第三，给每个任务设置明确的完成条件。所谓“完成”至少应包含修改范围、测试命令、预期输出、已知风险和未验证部分。没有验收标准的任务，最后只能靠开发者凭感觉审查。

第四，优先建设高质量工具，而不是堆工具数量。搜索、读取、编辑和测试是高频主路径，应该保证参数简单、返回稳定、错误清楚；带副作用的命令则应支持预览和回滚。

第五，把 Trace 和差异审查纳入日常流程。任何 Agent 修改都要能回答“改了哪些文件、为什么改、验证了什么、还有什么没验证”。这比让模型写一段更漂亮的解释更重要。

第六，测试要尽量独立于实现。把真实输入、历史缺陷、边界条件和外部契约放进验收标准，避免让 Agent 根据刚写出的代码反推测试答案。

最后，保留人工停止权。Agent 连续重复调用、修改范围突然扩大、测试失败后强行绕过，都是应该立即暂停任务的信号。一个好的 Agent 工作流不是让模型永远自动运行，而是让它在不确定性升高时及时把控制权交还给人。

结语：真正的门槛是可控性

连续半年只用 Agent 写代码，证明了编码 Agent 已经可以承担相当一部分日常工程工作，但也证明了“能写出来”和“值得合并”之间仍然隔着一整套工程纪律。

Agent 的上限由模型能力决定，下限则由工具、上下文、测试和回滚机制决定。对开发者来说，最值得投入的不是继续寻找一句神奇提示词，而是把代码库整理成 Agent 能理解的形状，把任务拆成可以验证的步骤，把失败记录成可以复盘的证据。

截至 2026 年，Agent 编程最现实的范式仍然是人机协作：模型负责扩大执行带宽，人类负责定义问题、约束风险并验收结果。谁先建立这套控制系统，谁才更可能把“会写代码的模型”变成真正可用的生产力工具。