1.5 Coding Agent 自主编程时代：从生成代码到执行和验证

把采购任务交给同事时，你希望他根据清单核对库存、购买缺少的材料，遇到缺货时再反馈，而不是只写一份“应该怎样采购”的说明。编码智能体（Coding Agent）同样把工作向前推进了一步：围绕目标读取项目、修改文件、运行工具，再根据结果调整下一步。

这里的“自主”有明确边界。它指在任务范围和权限内连续执行，不代表无限记忆、无限重试，更不代表每次都能完成任务。

一个编码智能体由哪些部分组成

可以先把它理解为四部分的配合：模型提出下一步行动，工具负责执行，任务状态保存进度，运行程序负责权限和停止条件。

模型本身不会直接按下键盘或打开文件。它提出“读取这个文件”“执行这条测试命令”等调用请求，由外部程序完成操作，并把结果交回。这个区别决定了智能体的实际能力既取决于模型，也取决于工具和运行环境。

以修复搜索错误为例

假设用户反馈：“搜索关键词前后多一个空格，就找不到笔记。”一个合理的处理过程可以是：

步骤	具体工作	可检查的依据
确认现象	用带空格的关键词复现	原功能确实返回空列表
定位实现	查找搜索输入和过滤函数	找到没有处理首尾空格的位置
修改	在合适位置统一整理输入	修改差异与需求相符
验证	检查普通关键词、带空格关键词和纯空格	三种输入都符合约定
交付	说明修改文件及测试结果	可以复查的运行记录

智能体的价值在于把这些步骤连接起来，减少人在文件、终端和聊天之间转述信息的工作。若第一次定位错误，它可以读取新的反馈后调整；若缺少启动环境或业务规则，它也应明确指出缺口。

怎样交代任务更容易得到可用结果

任务至少需要目标、范围、参考资料和验收条件。例如：

修复笔记搜索对首尾空格敏感的问题。沿用现有搜索规则，不增加依赖。请先找到搜索实现，再修改并验证普通关键词、带空格关键词和纯空格输入。最后说明修改位置与验证结果。

这比“全面优化项目”容易完成，因为完成与否有具体标准。智能体越能够连续行动，越需要清晰的终点；否则它可能把一次小修复扩展成没有必要的重构。

“测试通过”还要看测了什么

成功运行检查是重要证据，但不是万能证明。只检查语法，不能证明搜索结果正确；只测正常输入，不能说明空输入已经处理；测试本身的预期写错，也可能让错误代码通过。

可以把验收分为三个层次：

• 能启动：环境、依赖和基础语法没有阻止程序运行。
• 能完成目标：真实输入经过业务流程后，得到预期结果。
• 没有破坏相关功能：原来的关键用法仍然有效。

交付说明应区分“已经执行”“建议补测”和“当前无法验证”，避免用一句“已完成”掩盖尚未检查的部分。

扩展工具为什么还需要约束

通过 MCP（模型上下文协议），智能体可以连接额外的工具和数据服务。它更像统一的接口规范，不会自动赋予数据库权限，也不会替你决定哪些操作应该开放。

例如，读取测试数据库与修改正式数据库的影响不同。开发任务只需读文件时，就不必开放整个电脑的目录；需要运行测试时，可以明确使用测试环境。连续失败后，也应先重新分析原因，而不是无限重复同一个动作。

常见的产品形态

形态	示例与官方入口	关注点
终端工具	Claude Code、Aider	命令执行、项目上下文与版本控制
编辑器扩展	Cline、Roo Code	文件修改、权限设置和模型配置
开发平台	OpenHands、Devin	执行环境、任务交付和外部系统集成

同一产品可能同时提供多种入口。评估时应观察它是否能在你的项目上定位问题、控制改动范围并提供验证依据，而不是只比较它运行在终端还是网页。