长程任务不是把短任务循环很多次。它真正难的地方在于上下文会膨胀错误会累积目标会漂移。现有 Agent 框架几乎都在围绕这三类约束做取舍。导语Agent 做短任务时很多问题不明显。让它查一个接口、改一小段代码、总结一篇文档通常只需要少量步骤失败也容易回滚。但一旦任务变长性质就变了。比如修一个跨多个文件的 bug先理解代码库再定位问题再改实现再补测试再处理失败用例。又比如自动完成一个网页操作打开页面、登录、填表、跳转、处理异常、确认结果。再比如科研实验闭环提出假设、跑实验、分析数据、调整方案、继续迭代。这些任务都有一个共同特征Agent 必须在几十个甚至上百个决策步里保持状态连续、目标一致和错误可控。这类任务通常被称为 Long Horizon Task也就是长程任务。长程任务真正难不是因为单步推理一定很复杂而是因为三类约束会随着步数增长一起放大。图长程 Agent 任务中的三类系统性约束上下文爆炸轨迹越长模型越看不清最基础的 Agent 循环通常是 ReActThought、Action、Observation不断重复。这个模式在短任务里很直接。但它有一个天然问题每一步产生的思考、动作和观测都会进入上下文。步数越多轨迹越长token 压力越大。10 步任务可能已经需要数千 token。到了 30 步、50 步历史就会变成沉重负担。即使上下文窗口足够大模型也不一定能稳定关注中间位置的信息。Lost in the Middle 这类现象说明信息在窗口里不等于信息被有效使用。所以上下文爆炸不是单纯的容量问题而是状态管理问题。长程任务需要决定哪些信息保留、哪些压缩、哪些归档、哪些在需要时检索回来。误差积累单步小错会变成系统性偏差长程任务里的错误不是简单相加而是会复合。假设 Agent 每一步准确率是 95%。看起来很高但连续 20 步后整体全对的概率约为0.95^20 ≈ 36%如果是 50 步0.95^50 ≈ 7.7%更麻烦的是错误会污染后续观测。第 N 步选错文件第 N1 步看到的上下文就变形第 N2 步可能在错误前提上继续推理。这就是级联失败。长程任务需要的不是“每一步尽量聪明”这么简单而是要有验证、纠错、回滚和重新规划机制。目标漂移最危险的是看起来还在工作目标漂移比报错更难处理。Agent 运行时间越长局部信息越多原始目标越容易被挤到边缘。它可能开始追逐一个中间子目标修某个测试、改某个函数、解释某个页面状态。表面上它一直在行动实际上已经偏离最初任务。这类失败通常没有明显异常。Agent 不会报错它只是“认真地做错方向”。因此长程任务必须有某种全局锚点计划、状态机、管理者、验收标准或者持续可见的任务目标。图长程任务不是连续调用模型而是维持目标、状态和反馈的工程系统七种 Agent 框架路线本质是在三类约束中取舍现在主流 Agent 框架大多可以放进七类路线中ReAct、Plan-and-Execute、TreeSearch、Reflexion、Memory-Augmented、Multi-Agent、StateMachine。它们不是谁完全替代谁而是在不同约束上做不同交换。图七类 Agent 框架路线在不同约束之间做交换ReAct最清晰的基线也最完整地暴露问题ReAct 的循环很简单先思考再行动再观察环境反馈然后进入下一轮。它的优势是通用、直观、实现成本低。LangChain AgentExecutor、早期 AutoGPT 这类系统都能看到它的影子。但 ReAct 不处理长程问题。所有历史线性堆积错误没有系统纠正目标没有硬锚点。当任务超过 15 到 20 步后上下文爆炸、误差积累和目标漂移会同时出现。所以 ReAct 更像一条 baseline。它的价值不是解决长程任务而是把长程任务的问题暴露得足够清楚。Plan-and-Execute用计划压缩未来但押注计划正确Plan-and-Execute 把任务拆成两个阶段Planner 先生成完整步骤列表。Executor 按计划逐步执行失败时再触发重规划。这个模式的优势是压缩未来。一个 10 步计划可能只需要几百 token而裸 ReAct 跑完 10 步可能已经堆出几千 token 轨迹。计划本身还是一个全局锚点能缓解目标漂移。问题在于它假设计划大体正确。复杂任务往往需要边做边理解。还没动手之前Planner 对环境、代码和异常路径的理解可能并不充分。如果初始计划错了Executor 反而会把错误忠实执行下去。因此Plan-and-Execute 缓解了上下文爆炸和目标漂移但可能放大早期规划错误。TreeSearch用搜索降低单步错误但计算量会爆炸TreeSearch 把 Agent 决策建模成一棵树每个节点是状态每条边是一个可能动作。系统可以在关键节点探索多个分支通过评估函数选择更优路径。它对误差积累的攻击很直接。裸 ReAct 每一步只有一次机会TreeSearch 允许在局部多试几条路用搜索后的结果替代单次选择。这在数学推理、短链路规划等任务中很有效。但长程任务上搜索空间会指数级增长。几十步任务如果每步都展开多个候选路径计算量很快不可承受。每条路径还需要上下文反过来又加重上下文压力。所以 TreeSearch 更适合作为局部决策优化器而不是完整长程任务架构。Reflexion让失败变成压缩后的经验Reflexion 的思路是执行失败后不只是重试而是让 Agent 反思哪里错了把反思写入记忆再带着教训重新尝试。它通常包含四个角色或阶段图Reflexion 把失败轨迹压缩成可复用经验Reflexion 的价值在于它把完整失败轨迹压缩成几条经验既缓解上下文压力也给下一轮尝试提供纠错信息。但它有一个前提Agent 能反思出真正原因。这并不总成立。LLM 的错误有时不是“想得不够仔细”而是知识盲区、工具误用、接口理解错误或评估标准缺失。让它反思自己不具备的能力很可能只能得到表层总结。Reflexion 对“做错了什么”有帮助但对“是否仍然对准原始目标”帮助有限。Memory-Augmented扩展上下文窗口但不等于理解状态Memory-Augmented 架构借鉴了操作系统的记忆管理把 Agent 记忆拆成多层记忆层作用Working Memory当前上下文窗口保存当前步骤需要的信息Short-term Memory近期操作缓冲保存最近状态和观测Long-term Memory向量库或知识图谱保存可长期复用的经验和知识Memory Manager负责写入、压缩、换页和检索MemGPT、Generative Agents、Letta 都属于这类思路。它对上下文爆炸很有价值因为它把有限上下文变成了可管理的外部存储。但记忆增强解决的是存储不自动解决检索相关性。存了不代表能在正确时刻取出来。长程任务真正困难的是状态理解当前最相关的信息是什么、哪些历史已经过期、哪些约束必须保留。如果检索召回不稳长期记忆就会变成“看似存在、实际用不上”的档案库。Multi-Agent把上下文拆开也把复杂度转移到协作Multi-Agent 把任务拆给多个专门化 Agent。常见模式包括 Manager-Worker、GroupChat、Pipeline。它是少数理论上同时触及三类约束的路线约束Multi-Agent 的缓解方式上下文爆炸每个子 Agent 拥有独立上下文实现隔离和水平扩展误差积累多 Agent 交叉检查引入外部视角目标漂移Manager 维护全局目标Worker 聚焦局部任务但它不是免费午餐。很多长程任务本质上是串行的第 N 步依赖第 N-1 步的结果。强行拆并行会导致子任务假设不一致。Agent 之间还需要传递信息接口处会产生损耗。协调复杂度不是消失而是换了位置。Multi-Agent 对任务可拆、接口清楚、角色明确的场景很有效对强串行、高耦合任务管理成本会迅速上升。StateMachine用工程结构锁住目标但牺牲自主性StateMachine 或状态图把任务执行显式建模成节点和边。每个节点有进入条件、执行逻辑、退出条件状态对象在图中流动。LangGraph、StateFlow、Microsoft Semantic Kernel Process 都属于这一类思路。它对目标漂移最有效因为拓扑结构就是任务骨架。Agent 不能随意跑偏只能沿着状态转移执行。它也能缓解上下文爆炸因为状态对象只保留关键字段而不是完整历史轨迹。问题是它不提升单步决策质量。如果某个节点内部判断错了状态机本身不会自动变聪明。更深一层看状态机把任务结构从 Agent 推理中外化到了工程代码里。这提高可靠性但降低泛化性。它更像“带 LLM 步骤的工作流”而不是完全自主 Agent。这正是 Agent 范式的一条根本张力自主性越高可靠性越难保证可靠性越高自主空间通常越被压缩。三类约束与七种框架的矩阵框架路线上下文爆炸误差积累目标漂移核心矛盾ReAct未解决未解决未解决只是暴露问题Plan-and-Execute缓解可能恶化缓解计划与执行割裂TreeSearch可能恶化缓解未解决搜索空间指数增长Reflexion缓解缓解未解决自我评估有盲区Memory-Augmented缓解未解决未解决检索质量决定上限Multi-Agent缓解缓解缓解协调复杂度上升StateMachine缓解未解决强缓解用泛化性换可靠性这个矩阵说明了一个现实没有单一架构能无代价解决长程任务。每条路线都在用某个约束的恶化换另一个约束的改善。图不同 Agent 架构的核心差异最终都会落到可靠性、自治性和工程约束的权衡验证器决定可靠性上限所有纠错机制最后都会遇到同一个问题用什么验证结果验证方式优点局限同一个 LLM 自检成本低、集成简单容易有认知同构盲区多模型交叉验证能缓解单模型盲区标准可能不一致环境反馈最可靠如编译器、测试、真实 API只适合可形式化验证的任务人类监督能处理开放判断成本高无法无限扩展这也是为什么编程 Agent 相对更容易做出可用系统它有编译器、测试、静态检查和运行环境。开放研究、策略分析、复杂运营决策这类任务缺少明确环境反馈可靠性上限自然更低。接口设计往往比推理提示更关键SWE-agent 一类研究给了一个重要提示Agent 成功率不只取决于模型也取决于 Agent-Computer Interface也就是 Agent 如何观察和操作环境。同一个模型使用默认 bash 和普通编辑器接口可能很快陷入不可恢复的状态。给它更适合机器操作的文件搜索、补丁编辑、测试反馈和状态观察接口成功率会明显提升。很多所谓推理错误实质是接口错误Agent 看不到关键状态、不能局部修改、不能低成本回滚、不能确认动作影响。长程任务需要的环境接口至少要满足四点能力作用可观测Agent 能知道自己在哪、做了什么、环境发生了什么可逆错误动作可以撤销或最小化影响可验证每一步都有清晰反馈而不是靠猜可局部操作支持小范围读写避免把环境当成黑盒把工具从“给人用”改造成“给 Agent 用”往往是提升长程任务可靠性的高性价比路径。组合架构是当前更现实的答案现实系统通常不会只用一种架构。一个相对稳妥的长程 Agent往往会组合多层机制图计划、状态、执行、反馈、验证和记忆共同构成长程 Agent 的可靠性基础计划层压住全局目标状态管理层避免轨迹失控执行层完成具体动作验证层处理错误记忆层保存可复用上下文。这不是完美解而是工程补丁的组合。每层都会引入新的复杂度但在编程、网页操作、运维排查等有环境反馈的领域它比裸 ReAct 更接近可用。结语长程任务不是短任务的简单延长。步数一长上下文、错误和目标都会变成系统性问题。ReAct 暴露问题Plan-and-Execute 压缩未来TreeSearch 攻击局部错误Reflexion 把失败变成经验Memory-Augmented 扩展上下文Multi-Agent 引入分工StateMachine 用工程结构锁住路径。这些路线都有效也都有代价。未来真正可靠的 Agent 系统大概率不是某一个框架单点胜出而是围绕任务类型、验证条件、环境接口和风险边界动态组合这些机制。长程任务的关键不是让 Agent 更像一个无限自主的人而是给它足够清晰的状态、反馈、约束和纠错路径。推荐阅读Agent Memory 架构拆解别再把向量库当唯一记忆系统Agent Tool Interface 架构拆解为什么好工具比强模型更决定成败Hermes Skill Runtime 架构拆解三层加载如何压住 Agent 上下文成本团队落地 Agent 工程化 Loop 的一些必看小技巧Agent Loop 架构拆解让 AI Agent 自己跑完验收闭环
