Long-Horizon Agent 听起来很诱人：给它一个长期目标，让它自己拆解、执行、观察、修正，最后交付结果。
但我现在对“长程 Agent”这个词会更谨慎一点。短任务里，Agent 像一个聪明的脚本；长任务里，它更像一个会疲劳、会误解上下文、会被自己历史污染的初级同事。
真正的难点不在“能不能调用工具”，而在“能不能持续保持正确的任务模型”。
目标会漂移
长任务最常见的问题是 goal drift。
用户一开始说的是“修登录问题”，Agent 读着读着发现类型有点乱，测试也不顺手，组件结构还能优化。于是它先修一个测试，顺手重构一下，再为了兼容旧逻辑加一层包装。每一步都能解释，但最后 diff 一看，已经离“修登录问题”很远了。
这种漂移不是模型突然失控，而是每一步的局部合理叠在一起，变成整体不合理。
长任务需要显式的目标锚点：这次到底要解决什么，什么不做，验收标准是什么。每进入一个新阶段，都应该重新对齐目标，而不是靠对话历史里的模糊印象。
状态爆炸
Agent 的状态不只是代码状态。
它还包括用户意图、读过哪些文件、工具输出、失败尝试、临时假设、测试结果、未提交修改、环境限制。任务越久，状态越多，冲突也越多。
人类工程师会主动遗忘不重要的信息，只保留和决策有关的摘要。Agent 往往做不到。旧的错误信息、已经废弃的方案、一次性的调试输出，都可能在后续推理里重新浮上来。
所以长程 Agent 不能只靠更长 context。更长的上下文只会推迟问题，不会解决状态管理。更可靠的做法，是把事实、假设、决策、待验证事项分开记录，并且允许过期状态被明确废弃。
记忆污染
记忆是双刃剑。没有记忆，Agent 无法连续工作；记忆太随意，又会污染判断。
我最担心的是这种情况：它把临时 workaround 记成系统设计，把一次失败命令记成永久约束，把用户某次偏好泛化到所有项目，把旧分支上的实现细节带到新任务里。
长期运行后，Agent 可能不是“更懂项目”，而是“更自信地误解项目”。
好的记忆应该更接近工程文档，而不是聊天记录。它需要来源、时间、适用范围和撤销机制。尤其是架构判断，不能因为在某次会话中出现过，就自动变成全局真理。
中断恢复很难
真实工作不会连续发生。机器重启、上下文压缩、CI 失败、用户插入新需求、任务隔天继续，都是常态。
中断恢复的核心不是“恢复对话”，而是恢复可执行状态：现在在哪个分支，哪些改动属于本任务，哪些测试跑过，失败原因是什么，下一步为什么是下一步。
如果 Agent 不能在恢复时重新验证环境，就容易接着过期假设继续执行。长任务里，每次恢复都应该像一次小型交接：读当前代码、检查 diff、确认计划仍然成立，然后再行动。
验证必须内建
短任务可以靠最终测试兜底，长任务不行。因为越到后面，错误成本越高，错误来源也越难追。
Long-Horizon Agent 需要把验证变成循环，而不是收尾动作。
计划是否仍然匹配目标，要验证；代码是否符合现有模式，要验证；修复是否真的触达 root cause，要验证；用户可见行为是否符合预期，也要验证。
这里的验证不只是跑测试。它包括阅读调用链、对比 diff、检查边界条件、用浏览器走真实流程、确认没有修改无关文件。Agent 的自信不重要，证据重要。
规划和执行要分离
很多 Agent 失败，是因为它一边计划一边执行。执行中遇到局部阻力，就即时改计划；改着改着，原始设计消失了。
更稳的模式是把 planning 和 execution 分开。规划阶段回答：目标、边界、方案、风险、验收标准。执行阶段只在这个框架内推进。
遇到新事实，可以更新计划，但要显式说明为什么更新，而不是在代码里悄悄漂移。
这也是为什么好的 Agent 工作流更像工程流程，而不像聊天：先形成计划，再小步执行，再持续验证，再阶段性复盘。自由度不是越大越好，长期任务里，约束反而是智能的基础。
小结
Long-Horizon Agent 的瓶颈不是模型会不会写代码，而是它能不能长期保持任务一致性、状态清洁和验证纪律。
未来更强的 Agent 可能不只是更大的模型，而是更好的工作系统：明确的目标锚点、结构化记忆、可恢复的任务状态、持续验证，以及规划和执行的边界。
把 Agent 当成一次性代码生成器，它已经很有用；把它当成长期工程伙伴，就必须先解决这些工程化问题。