夜雨聆风2026 年，主流 AI 编程工具全面转向 Agent 模式。Cursor Agent Mode、Claude Code、Windsurf——都把"自主规划、多步执行、自动修复"作为核心卖点。
Demo 很惊艳，但真正在项目里用起来，开发者踩的坑远比想象的多。
今天这篇，不讲概念，只讲暗坑。每个坑都来自真实踩坑场景，附防御方案。
一、删除文件：Agent 觉得没用，就真删了
这是被吐槽最多的问题，没有之一。
Agent 模式下，AI 会自主判断代码依赖关系。当它认为某个文件"未被引用"，就可能直接删除。问题在于，Agent 对动态引用的理解几乎是零。
一个真实案例：Agent 判断某个 middleware 文件"未被使用"将其删除，实际上该文件通过动态 import 在运行时加载。删除后本地测试没问题（因为没有覆盖那个路径），部署到线上才报错。
还有开发者反映，Agent 直接删掉了整个 utils 目录，理由是"这些函数没有被引用"。
防御方案：
1. 明确告知 Agent 不要删除任何文件，只做标记或注释。Claude Code 可以在 CLAUDE.md 里写死这条规则，Cursor 可以在 .cursorrules 中约束。
2. 删除操作必须人工确认。所有工具都支持确认模式，不要关掉它。
3. 永远用 Git。每次 Agent 操作前确保工作区干净，出问题一条 git reset 就能回滚。
二、过度修改：改一个函数，它重写整个文件
Agent 模式的"主动性"有时过了头。
你让它修改一个函数的逻辑，它不仅改了那个函数，还"顺手"重构了文件里其他函数的命名、调整了代码风格、甚至修改了它认为"不够好"的实现。看起来很勤快，但每一个"顺手"都可能引入新 bug。
更危险的是修改配置文件。有开发者的 Agent 修改了 .env 文件，把线上配置改掉了，导致密钥泄漏。
防御方案：
1. 任务描述越精确越好。不要说"优化这个文件"，要说"只修改 handleAuth 函数中的 token 校验逻辑，不要改动其他任何代码"。
2. 每次只给一个子任务。大任务拆成小步骤，每步确认后再进行下一步。
3. 敏感文件（.env、config、docker-compose）加入 Agent 的排除列表。
三、错误级联：一步错，步步错
Agent 模式最可怕的不是单步做错，而是错误会级联放大。
典型场景：Agent 错误理解了需求，修改了 A 文件；发现 A 的改动导致 B 文件报错，于是去"修复"B；修复 B 又导致 C 出问题，继续修 C……最终 6 个文件被改得面目全非，而根源只是第一步的理解偏差。
有开发者的真实经历：让 Agent 重构一个模块，它先删了旧文件，再创建新文件，import 路径全错了，然后它又去"修复"这些 import 错误，越改越乱。最终 token 消耗超过 12 万，代码还不如不改。
防御方案：
1. 关键节点加入人工确认。不要让 Agent 一次性跑完所有步骤。
2. 一旦发现 Agent 的方向偏了，立即中断，不要让它"自己修"。
3. Git diff 检查每一步的变更，确认方向正确再继续。
四、Token 消耗：钱烧得比你想的快
Agent 模式的 token 消耗比普通补全模式高出一个量级。
社区实测数据：简单 bug 修复约 2-5 万 token，中等重构约 5-10 万 token，大型功能开发 10-20 万 token 起。对比普通补全模式，Agent 模式的 token 消耗约为 5-50 倍。
最极端的案例：一次对话消耗 8 万 token，实际有效改动只有 3 行代码。原因是 Agent 在项目中反复遍历上下文，做了大量无效推理。
更坑的是"自修复循环"——Agent 制造了错误，然后花更多 token 去修复自己制造的错误，消耗指数增长。
防御方案：
1. 设置 token 预算硬上限。Claude Code 支持 budget 控制，超过阈值自动停止。
2. 缩小上下文范围。不要让 Agent 读取整个项目，只给它相关的文件和目录。
3. 及时开启新对话。长对话的上下文会不断膨胀，单次对话不要超过 30 分钟。
4. 简单任务用普通模式。只有明确边界的大任务才开 Agent 模式。
五、幻觉式操作：编造不存在的 API 和文件
Agent 不只是输出文本幻觉，它会基于幻觉执行真实操作。
典型表现：编造不存在的 API 调用，创建项目中从未定义过的工具函数，引用不存在的文件路径。最危险的是，它可能声称已经调用了某个工具，实际上并没有执行——但后续推理基于"已经执行"的前提继续展开。
防御方案：
1. 工具调用结果必须原样返回，不要让 Agent 转述或总结执行结果。
2. 关键操作后手动验证。Agent 说"已经执行了数据库迁移"，你自己看一眼数据库。
3. 使用结构化输出和 Schema 校验，约束 Agent 的输出格式。
六、确认疲劳：点着点着就不看了
这是所有 Agent 工具都面临的人性化问题。
Agent 模式下，每一步操作都需要用户确认。起初你会仔细看每一条变更，但确认了 30 次之后，手指比脑子快——直接点击"全部接受"。
这就是确认疲劳。你给了 Agent 一把钥匙，它开哪扇门你都不看了。
防御方案：
1. 重要操作（删除、配置变更、数据库操作）保持强制确认，不要设为自动通过。
2. 每次确认前花 10 秒扫一眼 diff，不理解的改动拒绝。
3. 批量操作分批确认，不要一次性通过所有变更。
七、安全盲区：Prompt 注入可能来自你的代码
安全研究者已经证实：Agent 编程工具可以被恶意代码注入。
攻击路径不是来自你的提示词，而是来自代码本身。Agent 会读取项目中的所有文件来理解上下文——包括 README、代码注释、package.json 中的描述字段。如果这些文件中包含精心构造的指令，Agent
可能会执行未授权操作，比如向外部服务器发送数据、在代码中植入后门。
这在克隆开源仓库后使用 Agent 编程时尤其危险。
防御方案：
1. 不熟悉的开源项目，先审查再让 Agent 读取。
2. 敏感操作（网络请求、文件写入、命令执行）保持人工确认。
3. Agent 的网络访问权限做最小化限制。
写在最后
Agent 模式不是不能用，而是不能无脑用。
它的价值在于处理复杂的多步任务，比如跨文件重构、系统性 bug 修复、项目脚手架搭建。这些场景下，Agent 的效率远超手动操作
但前提是：你始终是驾驶员，Agent 是副驾。方向你定，油门你踩，刹车你随时能拉。
五条核心原则：
1. 永远用 Git，随时可以回滚。
2. 任务描述精确，一步一个子任务。
3. 关键节点人工确认，发现偏了立即中断。
4. 简单任务用普通模式，Agent 模式只在必要时启用。
5. 控制上下文范围和 token 预算，避免无效消耗。
Agent 模式是 2026 年编程工具的必然方向，但工具再强，审慎永远不过时。
---
关注【AI漫步技术】，每期一个 AI 实用干货，不踩坑、不迷路。