AI Agent越来越能执行复杂开发任务以后，一个很明显的问题也开始出现：

任务越长，越容易“前面做得很好，后面慢慢跑偏”。

刚开始时，Agent可能准确理解了需求：

• 修改指定模块；

• 不改公共接口；

• 保留现有测试；

• 只处理当前Bug。

但执行到后面，却可能出现：

• 修改范围越来越大；

• 开始顺手重构无关代码；

• 忘记最初约束；

• 重复处理已经完成的部分；

• 最终结果和最开始的目标出现偏差。

这类问题很多时候不是Agent突然“不会写代码”了。

真正的问题是：

长任务需要持续维护任务状态，而不能只依赖最开始的一段Prompt。

---

一、为什么短任务更容易保持准确？

假设任务只是：

修改一个接口里的参数校验。

执行路径可能只有：

找到文件
↓
修改逻辑
↓
运行测试
↓
完成

整个过程很短。

Agent始终围绕一个明确目标工作。

但如果任务变成：

重构用户模块，同时调整接口、测试、缓存和文档。

执行过程可能变成：

分析项目
↓
修改Service
↓
调整接口
↓
修复测试
↓
处理缓存
↓
更新类型
↓
重新测试
↓
补文档

步骤越多，需要持续记住的信息也越多。

---

二、任务跑偏通常不是突然发生的

很多长任务并不会在第二步就明显出错。

更常见的是：

第一步正确
↓
第二步正确
↓
第三步出现一个新问题
↓
为了处理新问题增加修改
↓
后续开始围绕新问题继续扩展

慢慢地，最开始的目标就被弱化了。

例如原任务只是：

修复登录状态刷新问题。

执行到后面却变成：

顺便重构整个认证模块。

技术上可能有合理性。

但已经偏离了最初任务边界。

---

三、“上下文还在”不等于“任务状态清楚”

Agent可能仍然能看到前面的对话。

但真正需要维护的不只是文字上下文。

还包括：

• 已经完成了什么；

• 哪些约束不能改变；

• 当前正在解决什么；

• 哪些问题属于原任务；

• 哪些问题只是过程中发现的新问题。

如果这些状态没有明确整理，任务就很容易越做越散。

所以长任务真正需要的是：

显式任务状态。

---

四、阶段目标可以减少任务漂移

复杂任务最好不要只设置一个最终目标。

例如：

完成整个用户模块重构。

可以拆成：

阶段一

确认影响范围，不修改代码。

阶段二

只修改核心业务逻辑。

阶段三

补充测试并验证。

阶段四

处理相关文档和清理。

每个阶段都回答：

当前只需要完成什么？

这样Agent就不容易一次把所有事情混在一起。

---

五、Checkpoint为什么很重要？

Checkpoint可以理解成：

长任务里的阶段检查点。

例如完成第一阶段以后，先输出：

已完成：
确认登录逻辑涉及3个文件。

未修改：
公共Auth接口。

发现：
缓存逻辑可能存在关联问题。

下一步：
只修改login.service.ts。

然后再继续。

这一步的价值在于：

让Agent重新对齐：

目标、范围和下一步。

---

六、每完成一阶段，都应该重新检查原始约束

例如最开始规定：

1. 不修改数据库结构；
2. 不改变公共接口；
3. 不新增依赖；

执行几轮以后，Agent为了修复新问题，可能提出：

增加一个新Package会更方便。

这时候就应该回到原始要求：

是否允许新增依赖？

如果不允许，就不能因为当前方案更方便而直接突破边界。

所以长任务里，原始约束应该反复确认，而不是只在第一轮看一次。

---

七、不要让“新发现的问题”自动变成“当前任务”

这是长任务特别容易出现的情况。

例如修Bug过程中发现：

• 另一个模块代码重复；

• 某个测试结构不好；

• 某个工具函数可以优化。

这些问题可能确实存在。

但并不代表都应该现在解决。

更好的处理方式是：

当前任务：
修复登录Bug。

额外发现：
1. 测试结构可优化；
2. Auth工具函数有重复逻辑。

处理：
记录，但本次不修改。

这样可以避免任务不断膨胀。

---

八、长任务最好维护“已完成 / 待完成”清单

例如：

已完成：
- 定位Bug根因
- 修改Service
- 补充单元测试

待完成：
- 集成测试
- 检查缓存行为

不在本次范围：
- Auth模块重构
- API命名调整

这其实就是一个简化版任务状态表。

每执行几步重新更新一次，Agent更容易知道：

自己现在处于哪里。

---

九、什么时候应该暂停，而不是继续？

如果出现这些情况，可以考虑先停下来：

• 修改文件数量明显超过预期；

• 当前任务目标已经很难一句话说清；

• 连续处理多个原任务之外的问题；

• 已经不知道哪些修改属于哪一个阶段；

• 测试失败原因和最初任务越来越远。

这时候继续执行，通常只会进一步扩大Diff。

更好的方式是：

先总结当前状态，再重新确定下一步。

---

十、可以直接给Agent设置长任务规则

以后执行复杂任务，可以提前加入：

这是一个长任务，请按阶段执行。

要求：
1. 每个阶段只完成一个明确目标；
2. 每完成一阶段先总结结果；
3. 始终保留原始限制条件；
4. 新发现的问题先记录，不自动扩大任务；
5. 每阶段结束后列出“已完成、待完成、下一步”；
6. 修改范围明显扩大时暂停并说明原因。

相比一次性说：

把整个功能全部完成。

这种方式通常更稳定。

---

最后

AI Agent执行长任务时容易“前面做对，后面跑偏”，本质上不是因为长任务一定超出能力。

而是：

任务越长，需要维护的状态越多。

真正稳定的长任务工作流，不能只依赖最开始的一次Prompt。

而应该持续维护：

原始目标
↓
当前阶段
↓
已完成内容
↓
未完成内容
↓
下一步

当Agent每走一段都重新确认这些信息时，任务就更容易保持收敛。

未来Coding Agent真正重要的能力，也不只是：

能不能连续工作很久。

而是：

工作很久以后，是否还记得自己为什么开始，以及最终到底应该完成什么。

---

持续更新 Codex、Claude Code、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。