最近用 ChatGPT、Codex 跑复杂任务时我越来越关注一种特别容易被忽略的问题每一步看起来都没错最后结果却还是偏了。比如一开始的目标很清楚优化订单退款流程保证重复事件不会产生重复退款同时不改变现有API行为。Agent开始执行以后第一步分析重复事件来源。合理。第二步增加幂等判断。也合理。第三步为了让幂等判断更稳定调整数据库结构。还是合理。第四步为了兼容新结构修改Service。看起来也没问题。第五步测试失败于是调整测试和调用方式。依然能解释。最后所有测试都通过了。但回头一看却发现原本“不改变现有API行为”的约束已经被破坏。这时候最奇怪的地方就是你很难指出到底哪一步“明显做错了”。因为每一步单独看都有自己的理由。真正的问题在于Local Correctness ≠ Global Correctness局部正确不等于全局仍然正确。一、为什么每一步都合理最后还是会偏因为复杂任务不是一连串完全独立的动作。后面的每一步都会建立在前一步产生的新状态上。比如原始目标 ↓ 决策A ↓ 产生状态A ↓ 决策B基于状态A ↓ 产生状态B ↓ 决策C基于状态B如果A只发生一点点偏移B又默认A是正确的C再继续基于B推进最后偏差就会被不断累积。这很像导航。每次只偏一点点短距离看不明显。但走得足够远以后最终位置可能已经离目标很远。所以复杂Agent任务真正危险的往往不是一次大的错误。而是很多次“小幅合理偏移”。二、Agent特别容易优化“当前问题”比如当前测试失败了。Agent此时最直接的目标就是把测试修绿。于是它可能改实现。改Mock。调参数。换调用方式。这些动作对“当前测试失败”来说都可能是合理的。但更大的问题是为了让这个测试通过有没有破坏更上层目标比如原始约束是不能改变现有API行为但为了通过测试Agent把同步接口改成异步返回局部问题解决了。全局目标却已经变了。所以复杂任务里最需要警惕的是Current Error Fix ≠ Original Goal Progress修掉当前错误不一定等于更接近最终目标。三、为什么这种偏移很难被发现因为每一步都有Evidence。例如测试失败。日志报错。类型检查不通过。依赖冲突。这些都是很强的局部信号。而最初的目标通常只是一段文字。随着任务越来越长新产生的日志、代码和测试不断进入上下文。原始目标反而越来越“远”。于是Agent会自然把注意力放到最近发生的事情。而不是不断重新确认我们最开始到底要完成什么。这也是为什么长任务里最近上下文很容易压过原始目标。四、局部测试全绿也可能掩盖全局偏移这类问题特别容易出现在测试里。比如Agent修改三个模块模块A测试通过 模块B测试通过 模块C测试通过看起来非常稳。但原始目标可能要求A B C 组合以后 旧客户端仍然完全兼容如果测试只验证每个模块自己的行为就可能出现Local Tests PassSystem Goal Fails所以复杂任务不能只问“测试是不是绿了”还要问“这些测试有没有验证原始目标”这两个问题不一样。五、中间决策会悄悄改变任务定义复杂Agent任务经常出现这种情况原始目标修复退款重复处理执行到一半以后Agent认为根因是架构问题。于是任务逐渐变成重构退款处理架构再继续重新设计事件消费流程最后你会发现Agent做了很多有价值的工作。但已经不是原来的任务了。这不是明显失败。反而更危险。因为结果可能技术上更漂亮。工程上更复杂。但业务上根本没有必要。六、所以复杂任务需要“Goal Anchor”我现在更推荐在任务开始时除了写目标再保留一个非常短的Goal Anchor——目标锚点。例如最终目标 重复退款只产生一次业务副作用 必须保持 现有API行为不变 历史订单兼容 不扩大权限范围这几句话要足够短。目的就是无论任务跑多少步都可以快速重新对齐。而不是每次重新读一大段Prompt。七、每个阶段都应该问一次还在完成原目标吗比如Agent准备进入下一阶段前可以检查当前修改解决了什么 是否仍然符合原始目标 有没有破坏关键约束 有没有新增原本不存在的任务这其实就是Re-alignment Check不是重新规划整个任务。只是检查方向有没有偏。复杂任务如果没有这个动作很容易一路执行到底才发现结果已经不是最开始要的结果。八、不要只看“下一步合理不合理”这是最容易误判的地方。比如下一步是为了修测试修改接口返回结构。单独看可能合理。但真正应该问的是修改接口返回结构是否违反原始约束所以决策不能只做当前问题 → 下一步还要加一层当前问题 → 候选动作 → 和原始目标比对 → 再执行这一层虽然简单却能挡住很多任务漂移。九、为什么“完成条件”还不够有些任务已经定义了完成条件测试通过 构建成功 Bug不再复现但这些通常只能判断任务有没有结束。却未必能判断结果有没有偏。比如Bug确实修好了。测试也全绿。但为了修Bug接口语义变了。性能变差。兼容性被破坏。所以还需要一组更稳定的Invariants——不变量。也就是任务执行过程中无论怎么变化都不能破坏的条件。比如API兼容必须保持 权限不能扩大 同一事件最多一次副作用 历史数据必须可读这些比“测试通过”更接近全局正确。十、目标和不变量最好分开目标回答要做到什么例如修复重复退款不变量回答做的过程中什么绝对不能被破坏例如旧API保持兼容 不允许扩大权限 退款金额不能超过原订单金额这样Agent可以自由改变实现方案但不能突破这些边界。这比要求“严格按照原计划执行”更灵活。十一、为什么多步任务特别需要Checkpoint任务越长越容易发生累计偏差。所以可以每完成一个阶段就做一次Goal 现在仍然是什么 Current State 已经变成什么 Drift 有没有偏离 Next 下一步是否仍然服务于Goal这不需要很复杂。关键是让Agent定期从“继续执行”切换到“重新看全局”。很多偏移在早期其实很小。越早发现修正成本越低。十二、还有一个常见问题Agent会把“已有结果”当成正确前提比如前一步生成了一个新设计。下一步Agent通常会默认这个设计已经确认。然后继续往下。再下一步又默认前两步都没问题。于是一个早期小错误可能逐渐变成整个后续流程的基础。所以复杂任务里有些关键中间产物应该标记成PROVISIONAL也就是暂时方案。还没有成为最终事实。只有验证以后才升级成CONFIRMED这样能减少“错误中间结果被一路继承”的问题。十三、怎么判断任务已经开始偏有几个信号很明显。第一修改范围越来越大但原始目标没有变化。第二Agent越来越难解释当前修改和最初需求有什么直接关系。第三测试越来越多但原始核心场景反而没有再次验证。第四新产生的子问题开始超过主问题。第五开始出现“顺便重构”“为了以后扩展”“最好一起优化”这类动作。这些不一定是错。但都值得触发一次Goal Recheck。十四、我更推荐一个简单的收敛流程复杂任务可以用Goal ↓ Execute ↓ Checkpoint ↓ Compare with Goal ↓ Correct Drift ↓ Continue不是一路Execute ↓ Execute ↓ Execute ↓ Finish真正成熟的Agent Workflow应该具备不断执行也不断校正方向。十五、给自己看一个指标目标偏移率这篇我建议只看一个指标Goal Drift Rate——目标偏移率可以简单理解为最终关键结果中偏离原始目标或关键约束的部分 ÷ 全部关键结果例如一个复杂任务最终有10个关键结果。其中8个完全符合原始目标。2个虽然技术上成立但已经违反最初约束。那么目标偏移率 20%。这个指标真正想看的不是Agent犯了几个Bug。而是做到最后结果还像不像最初要的那个结果。十六、目标偏移率高先查什么我一般会先看第一原始Goal是不是太长、太模糊。第二有没有明确关键不变量。第三中间决策有没有持续被当成已确认事实。第四阶段之间有没有Checkpoint。第五测试是否只验证局部没有验证原始场景。第六Agent是否开始处理大量非阻塞问题。这些地方比继续加更多Prompt更值得先处理。十七、Plus和Pro怎么判断如果你的复杂任务现在经常出现前面看起来都对。做到最后才发现方向偏了。修改很多。测试很多。但最终结果和最初目标已经不完全一致。那真正限制效率的通常不是 ChatGPT、Codex 容量。而是缺少持续的Goal Alignment。这种阶段Plus通常已经够用。先把Goal Anchor。Invariant。Checkpoint。中间状态确认。目标重对齐做好收益通常比单纯增加执行容量更明显。如果这些机制已经比较稳定长任务能够定期重新对齐目标。关键不变量持续验证。中间决策不会无限继承。目标偏移率也长期较低。同时还有大量成熟复杂任务排队这时候Pro才更容易放大效率。因为增加的AI容量是在一个能够持续校正方向的Workflow里工作。最后复杂Agent任务最危险的情况不一定是某一步明显做错。反而可能是每一步都看起来合理。然后最终结果越来越偏。因为局部正确只能证明当前动作有理由。它不能自动证明整个任务还在朝原始目标前进。所以以后让 ChatGPT、Codex 跑长任务时除了检查代码。测试。Diff。还应该周期性问一句“我们现在做的还是最开始要做的那件事吗”真正成熟的Agent Workflow不是每一步都正确就够了。还必须保证所有正确的步骤最后仍然指向同一个正确目标。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。