为什么大模型企业都在强调可以连续工作XX小时的Agent和模型？长时运行Agent解析（Long-Running Agents）

在 2025-2026 年的 AI 领域，一个现象越来越突出：各大企业如 Anthropic、OpenAI 等，在产品发布和演示中反复强调他们的 AI 代理（Agent）能够“连续运行数小时、整夜执行任务、无人值守”。例如，Anthropic 的工程博客中展示了如何让 AI 代理在长项目中自主运行数小时，甚至跨多个会话保持进度。 McKinsey 的 2025 年 AI 全球调查也指出，AI Agent的长期运行能力正驱动实际价值创造。 这不是简单的营销噱头，而是反映了 AI 从短期交互向复杂任务处理的转变。在很多博客和文章中，把这种强调长时间不间断运行的AI Agent系统称为长时Agent（即Long-Running Agents）。

很多人常见的误解是认为长时间运行的Agent是指“模型一直在思考”，像一个不眠不休的超级大脑。事实上，这种长时运行更多是系统级设计的结果：任务被作业化处理，结合恢复机制和治理框架，模型只是其中一环。

本文将简单分享一下为什么现在的企业都强调长时运行的Agent，它的价值以及可能需要什么才能做好。

1. 定义：什么叫“长时运行 Agent”

长时 Agent 不是简单的长上下文模型、更大 token 处理能力，或更长的对话历史。这些是基础，但不足以定义长时运行。

相反，长时 Agent 是指 AI 系统能够跨多个会话、多次工具调用和多阶段产物，仍能完成同一个目标。LangChain 的 Agent 工程状态报告中强调，长时代理的核心在于处理长地平线任务，通过内存和工具集成实现。 X 平台上的讨论也指出，长时代理如 Anthropic 的 Claude Code，能自主运行数小时完成特征部署。

那么简单总结一下，一个长时运行的Agent需要至少具备下面三个方面的能力：

• 自治
  自己拆解任务、调度子步骤、纠错并收敛到目标。
• 上下文工程
  信息外置存储、选择性取用、阶段性压缩，避免上下文爆炸。
• 耐久运行时
  支持断线恢复、异步作业、检查点、可观测性，以及权限与预算控制。

2. 长时运行的AI Agent价值：为什么“能跑很久”会改变产品形态

说了长时运行的Agent之后，很自然的一个问题是为什么我们需要这种形态的Agent。简单来说不是我们期望长时运行，而是因为很多复杂的任务只能通过拆解步骤，不间断的、持续的解决才能获得最终的答案。早先大家讨论AI Agent应用的时候重点关注调用接口、工具等能力，但是比较少关注一次性调用可能也无法解决复杂问题。而AI Agent应用想要获得实际的价值，需要能解决更多步骤的工具调用以及更多的上下文问题。这里主要体现在下面几个方面：

大模型的应用从“回答”变成“交付”

之前的 LLM 或者说 Copilot 的主要目的是提供文本回答，稍微复杂一点的可以通过RAG（检索增强生成）来获取答案。而长时 Agent 的目标是能生成实际交付物，如代码 PR、报告、数据表、工单、配置变更或可复现实验结果。这里的关键差异在于解决这些复杂的问题，需要有阶段产物 + 验证 + 继续推进的能力。这一点在IBM 的 2025 年的AI Agent 预期和现实的报告中也有体现，即AI Agent更加强调从“一次性输出”转向“迭代交付”。

大模型应用从“同步聊天”变成“异步作业”

针对我们所说的这些复杂任务，例如为网站增加一个新的功能，用户不再需要守着聊天窗口，而是提交任务后，让大模型在后台运行，用户随时查进度或拿阶段结果即可。大模型应用从原来的那种同步聊天的方式扩展到复杂的异步任务处理方式。

大模型应用从“单次调用成本”变成“任务级运营”

显然，长时间运行的AI Agent关注的指标也与此前单次 token 成本转向任务级指标：如成功率、恢复率、人工介入次数、平均花费、平均用时、漂移率等。Young Urban Project 的 2025 挑战报告强调，这些指标也是构建AI Agent的关键。

3. 长时运行Agent和脚本化 LLM Loop 的差异到底在哪

很显然，有很多人可能会疑问，在当前这个长时Agent出现之前，也有一些脚本或者规则可以让大模型连续执行很久，如最早的AutoGPT，就是通过循环调用脚本，让大模型从十几个工具中不断选择可以执行的工具来解决问题，甚至也能达到几个小时的不间断运行。那么，最近我们强调的长时 Agent 与脚本化 LLM Loop（简单循环调用 LLM）的差异到底是啥？

其实答案也并不复杂，核心在于当前的长时运行的Agent更加强调大模型自治以及动态上下文管理。也就是说如果需要AI Agent能运行很长时间解决问题，那么意味着大模型要有更好的自主规划与调度能力，在复杂的环境下可以做出正确的选择，而不是单纯的试错。此外，也需要有选择性的使用上下文能力，毕竟随着任务的运行，上下文的信息会远超大模型的最高支持的上下文长度。

除此之外，下面几个方面也很重要。

耐久执行（Durable Execution）与可恢复

就是说，可长时间运行的AI Agent不是“一个进程一直跑”，而是允许任务跨多个离散会话继续，中间可暂停/断线/重启，靠“状态/历史/检查点”恢复到正确位置继续。Anthropic 直接把核心挑战描述为：长任务必须在离散 session 中完成，而每个新 session 起步都“没有记忆”，所以需要机制桥接。这类能力在工作流系统里更成熟：Temporal/ Durable Functions 都强调通过事件历史/重放或编排器把状态持久化、失败后恢复执行。

异步化与“作业化”的产品形态

所谓的异步化和作业化指的就是不再像大模型聊天或者Copilot那种只能同步聊天的应用，而是能进行异步的操作和任务管理。例如 OpenAI 的 Background mode、AWS AgentCore都支持且强调“长任务异步执行、避免超时、可轮询/回调结果”等。这会改变交互模式：从“你盯着它一步步聊”变成“你提交一个任务，它自己跑，给你阶段性产物/最终交付”。

可观测、可审计、可控（治理）

长时意味着决策链更长、风险面更大，所以系统通常要有：日志、进度、产物、决策依据、权限门、预算门、人工审批点等。Anthropic 的 long-running harness 思路，本质上就是把“进度与产物”外化成可读的工件来稳定推进。同时，需要考虑数据保留策略：例如 OpenAI 文档会说明 background 执行在轮询期间会暂存响应数据，对某些数据保留设置有影响。

这里我们简单描述总结如下：

4. 长时运行 Agent 一般需要什么技术和架构

在描述可能的技术或者架构前，我们可以先看看为什么长时Agent系统比较难。

长时运行的挑战在于任务延长会放大模型和系统的固有问题，这些问题具体且可测量。长程漂移是其中之一，越到任务后期，AI Agent越容易出现“自信但不对”的情况，导致目标丢失或提前宣布完成。同时，上下文爆炸则会造成信息过多，导致召回错误证据、引用过期状态或重复劳动，从而使过程变慢且成本更高。错误累积会让一次小错在后续步骤中放大，形成错误链条，甚至越修越乱，工具的副作用也变得不可控。不确定环境进一步复杂化问题，例如外部系统变化可能引发重试风暴、状态不同步或无法复现的结果。

解决这些挑战时，业界通常采用针对性的“硬办法”，对齐每个问题来设计策略。对抗长程漂移大多数是基于文件的上下文系统，采用规划-实现-验证的模式实现。 而对于上下文爆炸，采用外部记忆结合检索、压缩和隔离，只带入必要信息，其余放入存储和索引中。对错误累积的对抗包括验证驱动的设计、幂等操作、补偿机制和回滚功能，强制每个步骤进行测试和校验，确保工具可重试且关键步骤可回滚等。

基于这些描述，我们简单说一下长时Agent可能需要什么样的能力。其实简单来说可以分为三层：分别是自主规划层、上下文管理层、基础设施层。如下图所示：

虽然简单，但我觉得算是表达了这个意思。

5. 结语：长时 Agent 的真正门槛

长时 Agent 几乎是当前解决复杂问题必然出现的一种模式。换个角度看，如果哪家模型可以用很长的时间解决一个非常复杂的问题，这背后代表的不仅是模型智力的强大，也是AI Agent系统工程能力的强大。所以，在做大模型应用的时候，其实我们也不应该完全追求时延等指标。而是需要一个可以长时间稳定运行的AI Agent来解决复杂的任务或者问题。这对于运维、数据分析、代码工程等都有很大的帮助。