AI 会写代码，但不会替你负责：从 Chatbot 到 Agent
训练营开场时，我让同学们区分两种体验：一种是在聊天框里询问“注册接口应该怎么写”，另一种是把项目交给 AI，让它自己阅读文件、修改代码、运行命令，再根据报错继续修复。
前者更接近 Chatbot，后者才是 Agent。两者都使用大模型，但工作方式和风险完全不同。
Chatbot 给建议，Agent 改变环境
传统 Chatbot 的主要能力是理解文字并生成回答。它可以解释代码、提供示例、帮助头脑风暴，但通常不会主动把任务推进到交付结果。
Agent 则会在目标驱动下循环工作：读取项目、制定计划、调用工具、修改文件、运行测试、观察结果，再决定下一步。它不只“说”，还会对外部环境采取动作。
这也是为什么 AI 编程工具给人的冲击比普通问答更大。以前你需要把答案复制到编辑器里逐步执行；现在 Agent 可以自己完成一连串操作，甚至同时调度浏览器、终端、Git 和多个专业能力。
Agent 的任务闭环
课堂上我用一条简化循环解释 Agent：
- 感知：读取需求、代码、页面、报错和当前项目状态。
- 计划：判断要改哪些模块、先做什么、如何验证。
- 执行：编辑文件、运行命令、调用浏览器或其他工具。
- 反馈：检查输出是否符合目标，发现偏差后调整。
这个循环会持续进行，直到任务完成、资源用尽或遇到无法自行解决的阻塞。
真正需要注意的是：循环跑起来，不代表方向一定正确。如果最初目标模糊、验收条件缺失，Agent 也可能非常勤奋地把错误方案做得越来越完整。
为什么 AI 会一本正经地做错
大模型的基础仍然是根据上下文预测合适的后续内容。它可以表现出推理和规划能力，但不会像项目负责人一样天然拥有真实业务目标，也不会自动承担上线后的结果。
常见偏差包括：
- 需求没写清时，AI 自己补出看似合理的规则。
- 没有限定范围时，顺手增加登录、权限或第三方服务。
- 没有读取现有架构时，引入一套不一致的新技术。
- 没有真实运行时，把“代码写完”当成“功能完成”。
- 测试只覆盖自己刚写的实现，没有覆盖用户真正关心的行为。
这些问题不是 Agent 不够努力，而是它缺少必须由人提供的边界、判断和事实反馈。
人在 Agent 工作流里的四个责任
第一，定义目标。不要只说“做个水果商城”，要说清楚第一版优先解决什么业务问题。
第二，确认计划。复杂任务执行前，检查技术选型、影响范围、依赖关系和验证方式。
第三，提供反馈。页面截图、网络请求、服务端日志、测试结果，都是比“好像不对”更有效的反馈。
第四，做最终验收。AI 可以生成验收用例，却不能替你决定这些用例是否真的代表业务要求。
一个注册功能的完整例子
如果任务是“完成用户注册”，一个受控的 Agent 工作流应该是：
- 人先确认注册字段、重复账号处理、密码规则和成功结果。
- Agent 阅读 PRD、页面原型、后端架构和数据库迁移方式。
- Agent 输出实现计划，说明页面、接口、表结构和测试范围。
- 人确认没有夹带登录、短信或第三方认证等范围外需求。
- Agent 实现并启动真实服务。
- 人与 Agent 一起验证注册成功、重复账号、非法参数等场景。
- 测试通过后提交代码，再开始下一个功能。
这时 Agent 的速度被放进了一个可控框架，而不是让它自由发挥。
什么时候应该停下来
出现下面情况时，不要继续追加提示词让 Agent 盲目修：
- 它开始同时改动大量无关文件。
- 技术方案与原项目明显不一致。
- 同一个错误连续修复多次仍然反复出现。
- 你已经说不清当前代码由哪些改动组成。
- 测试通过，但真实页面或接口仍然不可用。
正确做法是停止执行，回到目标和证据：确认当前运行的服务、查看真实报错、缩小任务边界，必要时回退到上一个可用版本。
讲师判断：自动执行越强，人工检查点越要清楚
课堂上最危险的状态不是 AI 报错，而是它连续操作很久，学生却已经不知道当前发生了什么。因此我会要求每个小组提前设置三个检查点：执行前确认计划和影响范围，执行中观察关键文件与命令，执行后用真实页面、接口和测试验收。检查点不是为了限制 Agent，而是为了让失败尽早暴露。
当任务具有数据删除、权限调整、依赖升级或部署影响时，还要提高人工确认等级。可以让 AI 提方案、做只读检查和准备改动，但真正产生不可逆影响前必须停下来。会踩刹车，是使用 Agent 的核心能力之一。
课后练习
选择一个你熟悉的 AI 编程任务，把过程分成“感知、计划、执行、反馈”四栏。记录每一步由谁完成、用了什么证据、最后由谁判断完成。你会很快看到：Agent 可以承担大量动作，但责任链条仍然必须由人建立。