问题到底出在哪里

长时间 AI Agent 在 2025 年和 2026 年突然变热，并不难理解。模型越来越会写代码、调工具、读文档，很多团队自然会继续追问下一步: 既然单步任务已经能做，为什么不能把任务链拉长，让系统自己跑上几十分钟、几小时，甚至跨天完成？

真正的分歧，就出在这里。短链路任务的进步，的确已经非常明显；但一旦任务变长，问题就不再只是模型会不会推理，而是整套系统能不能连续保存现场、控制误差、处理失败，并在关键时刻让人接管。很多演示里看起来接近全自动的 Agent，到了真实环境里却会被上下文漂移、状态断裂、重复重试和成本失控拖住，原因就在这里。

所以，长时间 Agent 不该被理解成“更聪明的单次调用”，而应被理解成“带模型的工作系统”。模型决定天花板，系统决定均值。这个顺序如果搞反，后面的讨论几乎都会飘。

原文来源讲了什么，没讲什么

你最开始发来的材料，主要对应 Zylos Research 在 2026 年 1 月那篇《Long-Running AI Agents and Task Decomposition 2026》。它有价值，但它不是那种可以直接落进架构评审会的硬文档，更像一篇把研究、产品、投资判断和行业信号一起编进同一条叙事线的综述。

这种写法的好处，是能迅速把版图铺开。读者会很快知道长时间 Agent 为什么突然成了热点，哪些机构在推，哪些框架在补底座，哪些公司已经开始拿它讲故事。问题也同样明显: 证据强度不一样的东西被摆在了同一张桌子上。实验数据、工程实践、厂商文档和市场判断如果不先拆层，读起来很容易顺，落到系统设计上却会失真。

更稳妥的读法，是把它拆成三层。第一层看哪些判断有一手技术证据支撑；第二层看哪些属于产业趋势，可以帮助判断方向；第三层再看哪些说法更适合做沟通口号，而不适合直接写进工程决策。这样读，材料就会从“很会讲故事”变成“能帮团队少走弯路”。

哪些证据是真正硬的

如果只谈证据最硬的部分，我会首先看 METR。METR 的研究重要之处，不在于它给出了一句很抓眼球的“每七个月翻一倍”，而在于它持续测量 frontier 模型在给定成功率下，能够完成多长时间跨度的人类任务。这种测量方式更克制，也更接近我们真正需要的东西：不是模型能不能偶尔成功，而是它能在多大任务跨度上保持统计意义上的可用性。

第二类更硬的证据来自 Anthropic 的工程文章。Anthropic 没有把问题写成一种神秘的“Agent 自主性跃迁”，而是直接指出：Agent 必须跨多个 context window 工作，而每一个新 session 天生都会丢失现场。如果没有足够好的 harness 去保存工件、阶段摘要和下一步指令，复杂任务很快就会退化。

第三类硬证据来自框架级文档。无论是 LangGraph 的 persistence，还是 Microsoft Agent Framework 的 checkpoints，都在隐含地说明同一个现实：生产级 Agent 默认会失败，关键不在于避免一切失败，而在于能不能在合理的中间状态恢复。

  • METR 支撑的是任务跨度能力增长，而不是长时间稳定性已经成熟。
  • Anthropic 支撑的是跨上下文连续工作仍然是核心难题。
  • 框架文档支撑的是 checkpoint、persistence、resume 已经成为必选能力。

哪些说法更像行业口号

像“35 分钟后所有 Agent 都会明显衰减”“任务时长翻倍，失败率翻四倍”这种表达，很适合在文章中建立记忆点，但不应当被理解成物理定律。更合理的理解是：任务一长，系统性风险会非线性上升；而这个上升速度，取决于模型、上下文工程、工具设计、验证层和恢复策略的共同作用。

同样地，某些企业案例也更适合作为方向性参考，而不是严肃的架构证据。比如“数十万个 PR”“效率提升 20%”这样的数字，如果没有任务类型、审查方式、人类介入比例和成本结构，就很难直接拿来指导系统设计。它们最多说明一件事：市场上已经有人在认真投入这类系统，且的确从中拿到了一部分收益。

投资机构关于 AGI 的判断更是如此。它们可以激发产品想象力，但不能替代技术定义。对工程团队来说，最重要的不是参与概念争论，而是搞清楚：什么条件下系统能稳定跑完 30 分钟、2 小时、8 小时。

  • 记忆友好的表达不等于工程上足够精确的结论。
  • 案例故事可以帮助判断方向，但不能替代架构证据。
  • 真正的工程问题不是“是不是 AGI”，而是“能不能稳定完成任务”。

为什么 Planner-Worker 仍然是默认起点

在今天的约束下，Planner-Worker 仍然是最值得从零开始采用的结构，不是因为它时髦，而是因为它老实。强模型负责理解目标、拆任务、定义验收和处理真正困难的判断；更便宜的模型或执行器负责那些边界清楚、可批量推进、失败后也容易重跑的步骤。这样分工，首先省的是成本，其次省的是上下文，最后省的是错误扩散半径。

很多团队一谈多 Agent 就会不自觉地把角色越拆越多，仿佛角色数量本身就是先进性。但在多数项目里，决定成败的从来不是名义上的 agent 个数，而是边界划分是否明确。规划层管什么，执行层管什么，谁来验收，谁能中断，谁能升级给人，这些边界一旦不清楚，再多角色也只是在扩大同步成本。

因此，Planner-Worker 更像一套朴素的生产纪律。它不浪漫，却很适合第一版系统: 先把高杠杆决策和低杠杆执行分开，再决定哪些地方值得继续加角色、加验证、加治理。

真正决定上限的是上下文工程

长时间 Agent 的关键，不在更大的上下文窗口，而在更好的上下文工程。很多团队直觉上会把问题理解成“窗口不够大”，于是把希望寄托在更长的 prompt、更大的模型输入上。但实际运行里，更大的窗口经常先带来成本失控和信息稀释，而不是更好的记忆。

更合理的做法，是把上下文拆成层：系统级不变量、任务级目标与约束、子任务级局部上下文，以及即时工作记忆。真正应该频繁裁剪的是最后一层，而不是把一切历史都一股脑保留在 prompt 里。

这件事的本质是：对长任务来说，大上下文是资源，不是架构。真正的架构来自外部状态存储、决策日志、检索式回填和可恢复的工件链条。

  • 不是“塞更多”，而是“留对的、丢错的、按需取回”。
  • 原始工具输出应该落盘，模型只看摘要与引用。
  • 决策日志比无脑向量记忆更重要，因为它更可读、更可验证。

为什么检查点、验证和回滚是分水岭

生产级 Agent 最大的问题往往不是会失败，而是会假装自己成功。它写完一段代码就说“已完成”，但实际上没有跑测试；它生成了一个答案就说“已结束”，但实际上没有经过业务规则校验。这类“假完成”比显式失败更危险，因为它会把错误静默推入后续流程。

所以从架构角度看，最关键的定义不是“Agent 完成了什么”，而是“系统如何判定完成”。一套严肃的系统必须把完成定义成通过验证：结构正确、规则正确、测试通过、关键工件存在、必要时经过人工审批。

这也是 checkpoint、rollback 和 approval gate 重要的原因。它们不是为了让系统看起来更复杂，而是为了让系统在错的时候能停住，在需要的时候能接管，在崩的时候能续跑。

  • 没有验证的完成，不叫完成。
  • 没有 checkpoint 的长任务，重试成本会快速失控。
  • 没有人工门的高风险动作，不适合上生产。

我的判断：长时间 Agent 不是更聪明的聊天机器人

如果只留一句判断，我会写成这样: 长时间 Agent 的竞争，表面上看是在比模型，真正比的却是系统工程。未来两年最拉开差距的，未必是单步推理再提升多少，而是谁能把工作流、状态、验证、恢复、预算和治理真正做成默认能力。

一旦接受这个前提，很多看似分散的工程问题就重新连到了一起。超时、幂等、回放、审计、重试风暴、状态一致性，这些熟悉的分布式系统问题并没有消失，只是换了新的外壳，跑进了“模型推理 + 工具调用 + 人类审批 + 外部服务”的混合链路里。

这也解释了为什么长时间 Agent 的产品形态不会停在聊天框。真正成熟的系统，会越来越像异步工作台: 有任务状态，有阶段汇报，有人工接管，有审计线索，也有明确的完成标准。没有这些，长时间只是看起来长，谈不上真正可用。

最后压缩成八条最实用的结论

如果要把整件事压成最短版本，我会留下面这组结论。它们不是完整方法论，但足够作为团队讨论和架构设计的出发点。

  • 长时间 Agent 的问题是真的，而且会越来越重要。
  • 模型能力增长最快的是可尝试的任务跨度，不是生产稳定性。
  • 长任务的主要难点在状态、验证、恢复和成本，而不是单步推理。
  • Planner-Worker 依然是今天最现实的默认架构起点。
  • 上下文工程的关键不是大，而是分层、裁剪和按需取回。
  • Checkpoint、rollback、approval gate 是生产系统的基础设施。
  • 产品体验会从同步问答转向异步任务流和阶段汇报。
  • 真正的壁垒会在系统层，而不是只在模型层。

更新附注

  • 版本：v1.1

更新日期：2026-03-31 更新原因：重写开头、来源辨析、Planner-Worker 与结论段，压低模板化表达，收紧论证节奏，并把正文口吻统一到更克制的长文风格。