问题到底出在哪里

关于长时间 AI Agent 的讨论，在 2025 年和 2026 年明显升温。几乎每隔几周，都会出现一篇新的长文，试图证明模型即将进入可以连续自主工作的时代。很多叙事把这件事讲成一条很顺的进步曲线：模型越来越强，任务跨度越来越长，企业很快就会把大量工作迁移给 Agent。

但如果把这些材料拆开看，会发现真实情况没有那么线性。今天的前沿模型确实已经很擅长处理短链路、局部封闭、反馈清晰的任务，尤其是在代码、检索和简单办公流程里表现突出。真正麻烦的是，一旦任务持续时间变长、步骤依赖变多、工具调用次数增大，系统就会开始暴露另一类问题：上下文漂移、状态断裂、错误累积、重试风暴，以及成本快速膨胀。

换句话说，长时间 Agent 的难点不是“模型会不会想”，而是“系统能不能稳”。这也是为什么同样的模型，在 demo 里看起来像是已经接近全自动，在真实生产环境里却常常卡在一堆工程细节上。

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

你最开始发来的文章，主要对应的是 Zylos Research 在 2026 年 1 月发布的《Long-Running AI Agents and Task Decomposition 2026》。这篇文章很有启发性，但它不是同行评审论文，更像一篇研究综述加产业判断。它把 METR 的评估、Anthropic 的工程实践、LangGraph 和 Microsoft Agent Framework 的能力说明、Gartner 和 Camunda 的 adoption 数据，以及 Sequoia 的投资判断揉在了一起。

这种写法的价值在于可以快速搭出全景图，让读者知道问题在哪、行业在往哪里走、工程上有哪些共识。风险则在于，证据强弱会混在一起。技术团队最容易踩的坑，就是把趋势判断当成了工程事实，把营销性数字当成了可直接落地的设计依据。

所以真正有用的阅读方式，不是问“这篇文章对不对”，而是问三个问题：第一，哪些结论来自一手技术证据；第二，哪些只是行业趋势；第三，哪些表达更适合作为沟通口号，而不适合直接进入系统设计文档。

  • 原文最大的价值在于把“长时间 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 还是多 Agent 并不是最关键的。反过来说，如果边界不清楚，角色再多也只是增加更多 prompt、更多状态同步和更多 trace 难题。

我会把 Planner-Worker 看成一种经济学和工程学共同约束下的结构化妥协。它不一定最优雅，但在今天最可能做出稳定的第一版系统。

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

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

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

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

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

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

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

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

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

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

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

如果只允许我给一句结论，那就是：长时间 Agent 本质上是一种带 LLM 的工作系统。它的上限由模型决定，但它的均值由系统决定。未来两年，真正拉开差距的不会只是模型能力，而是工作流设计、工具契约、验证深度、恢复能力、预算管理和治理边界。

这也意味着，工程团队应该把自己熟悉的分布式系统直觉重新拿回来。超时、幂等、死锁、重试风暴、状态一致性、审计、回放，这些问题并没有消失，只是现在发生在“模型推理 + 工具 + 人类审批 + 外部服务”组成的混合流程里。

一旦这么理解，很多架构决策就会立刻清晰：为什么不能只谈 prompt，为什么必须做 decision log，为什么必须把完成定义成验证通过，以及为什么产品形态会从秒回聊天转向异步协作。

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

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

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