长任务 Agent 跑到一半怎么办：企业必须补上的执行 Harness 一手素材： 1. Anthropic Engineering - *Effective harnesses for...
长任务 Agent 跑到一半怎么办：企业必须补上的执行 Harness
一手素材：
1. Anthropic Engineering - *Effective harnesses for long-running agents*（https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ）
2. LangChain - *LangGraph: Agent Orchestration Framework for Reliable AI Agents*（https://www.langchain.com/langgraph ）
本文把 Anthropic 和 LangChain 两份一手资料里"长任务 Agent 的执行 Harness"这条主线拉出来讲透——目标读者是企业 AI 平台架构师、Agent 系统工程师、以及正在做"小时级"或"天级"任务的 Agent 产品经理。
一句话结论
长任务 Agent 99% 的失败不是因为模型不够聪明，而是因为没有"执行 Harness"——持久化状态、检查点、恢复机制、人类介入路径，一项都没补齐。 Anthropic 在 *Effective harnesses for long-running agents* 里直接说："For tasks that take hours or days, the model is rarely the bottleneck. The harness around the model is."
如果你正在做"超过 30 分钟"的 Agent 任务，先记住三个判断标准：
- 任务是否会跨进程、跨重启继续？——如果会，必须有持久化状态。
- 任务失败后能否从中间步骤恢复，而不是从头开始？——如果不能，必须补检查点。
- Agent 遇到不确定情况时能否暂停并等待人类决策？——如果不能，必须补 Human-in-the-loop。
三个中只要命中一个，就该认真做执行 Harness。
一、为什么长任务 Agent 总是翻车
过去一年，企业 Agent 项目的"翻车现场"惊人地一致——
- 一个数据分析 Agent 跑了 2 小时，到第 90 分钟时 Token 烧光，被迫中断；
- 一个研究 Agent 跑了 5 小时，到第 3 小时时网络抖动，进程崩溃，所有进度丢失；
- 一个代码迁移 Agent 跑了 8 小时，到第 7 小时时遇到一个歧义问题，自己猜了一个答案，结果错了；
- 一个客服 Agent 处理一个复杂工单，跑了 45 分钟，最后因为超时被强制结束，客户没拿到结果。
这四种"翻车"有个共同特点：任务本身完全有能力成功，问题出在"环境"上。Anthropic 把这种环境叫做 "Agent Harness"——围绕 Agent 的"执行支架"。
短任务（5 分钟以内）不需要 Harness，因为任务从头跑到尾不重启、不跨进程、不需要恢复。但长任务（30 分钟以上）没有 Harness 就像在沙漠里开车不备轮胎——不是会不会爆胎的问题，是什么时候爆胎的问题。
Anthropic 在文档里给出了一个非常具体的数字：他们做的长任务 Agent 项目里，70% 的"失败"其实是 Harness 问题（崩溃、超时、状态丢失），只有 30% 是模型本身判断错误。
这个比例反过来说明：投入资源优化 Harness 比投入资源优化模型，回报高得多。
二、执行 Harness 的 5 个核心组件
一个合格的执行 Harness 必须包含 5 个核心组件。每个组件对应一类典型问题，缺一个长任务就会在对应场景翻车。
组件 1：持久化状态（Persistent State）
Agent 执行的每一步状态——输入、中间结果、决策、token 消耗、时间戳——必须被持久化存储。存储介质：
- 短期状态（任务进行中）：Redis、内存数据库
- 长期状态（任务完成后留档）：PostgreSQL、S3、文件系统
- 跨任务状态（不同任务之间共享）：向量数据库、知识图谱
关键不是存哪里，关键是"每一步都存"。Anthropic 推荐的状态保存频率是每完成一次工具调用就保存一次。LangGraph 在框架层面默认实现了这一点。
状态保存的内容至少包括：
- 当前任务 ID
- Agent 当前的决策点
- 已完成的工具调用列表
- 每步的输入输出
- 累计 Token 消耗
- 时间戳和耗时
组件 2：检查点与恢复（Checkpoint & Resume）
任务执行过程中必须能"打检查点"——把当前状态完整快照下来。当任务崩溃、超时、被中断时，能从最近的检查点恢复，而不是从头开始。
Anthropic 推荐两种检查点策略：
- 定时检查点：每 5-15 分钟强制打一次检查点。简单粗暴，但保证最坏情况下只丢 15 分钟进度。
- 关键节点检查点：在关键决策点（涉及资金、合规、客户承诺）前强制打检查点。即使任务崩了，关键决策前的状态是确定的。
LangGraph 提供了更精细的"分支检查点"——同一条任务流可以分多个检查点，恢复时可以选择从哪个分支继续。
恢复后必须做两件事：
- 把已恢复的状态重新加载回 Agent 的上下文（避免 Agent 重复已完成的工作）
- 给 Agent 一个"我从第 X 步继续"的明确信号（让 Agent 知道这不是新任务）
组件 3：超时与资源限制（Timeout & Resource Limits）
长任务最容易出问题的不是模型判断，而是资源耗尽。三类资源必须有明确上限：
- Token 上限：单次任务允许消耗的最大 Token。超过必须终止或拆分。
- 时间上限：单步允许的最大执行时间（建议 60 秒），单任务允许的最大总时长（建议 4 小时）。
- 工具调用上限：单任务允许的最大工具调用次数。超过说明 Agent 进入循环，必须终止。
Anthropic 的建议是给所有长任务设硬上限——不是软警告，是到了上限就强制终止。软警告在长任务里几乎一定会被忽略。
LangGraph 提供了 Thread 和 Recursion Limit 两种内置限制——Thread 控制最大调用次数，Recursion Limit 控制最大递归深度。
组件 4：Human-in-the-Loop（人工介入）
长任务一定会遇到 Agent 自己无法决定的情况——
- 业务规则冲突
- 多个方案各有优劣
- 涉及金额、合规、客户承诺
- 数据不完整或矛盾
这些情况必须让 Agent 暂停并等待人类决策，而不是自己猜。Anthropic 把这种机制叫做 "Interrupt"——中断 Agent 执行，把决策权交给人，人决定后再恢复执行。
LangGraph 提供了专门的 interrupt() 函数——在代码里调用后，Agent 立即暂停，状态保存，发送通知给指定人类，人类决策后从中断点恢复。
企业里 Human-in-the-Loop 的设计有 4 个要点：
- 明确触发条件：哪些情况必须人工介入，不能让 Agent 自由发挥
- 明确的等待超时：人类多久内必须响应（建议 30 分钟-2 小时）
- 明确的兜底：超时未响应时怎么办（自动决策 / 任务终止 / 升级到主管）
- 明确的通知渠道：邮件 / IM / 工单系统，确保人类能收到通知
组件 5：可观测与审计（Observability & Audit）
长任务必须全程可观测：
- 实时进度：当前任务进行到第几步，消耗了多少 Token，预计剩余时间
- 历史轨迹：每一步的决策、调用、结果，都可以回放
- 异常告警：超时、Token 超限、决策错误时立即通知
- 审计日志：每一步的输入输出、决策理由、人类介入记录，全部留档
Anthropic 在文档里特别强调：长任务的审计日志要保留至少 90 天，因为很多业务问题在任务完成后几天才被发现。
LangGraph 集成了 LangSmith 提供完整的可观测性——每次执行的轨迹、决策、Token 消耗都有现成仪表盘。
三、Harness 选型：自建 vs 框架
企业落地 Harness 通常有两条路：自建 vs 用现成框架。
自建
适合场景：
- 业务逻辑非常特殊，没有现成框架能覆盖
- 工程团队足够强，能维护一个 Harness 系统
- 不想被框架锁定
自建工作量：
- 状态持久化：约 1-2 周
- 检查点恢复：约 2-3 周
- 超时和资源限制：约 1 周
- Human-in-the-Loop：约 2-3 周
- 可观测性：约 2-3 周
- 总计：8-12 周
用现成框架（LangGraph、Anthropic Managed Agents 等）
适合场景：
- 业务逻辑标准（对话、文档处理、研究）
- 想快速上线，不想维护 Harness
- 接受框架的锁定成本
用框架的成本：
- 学习曲线：1-2 周
- 集成到业务系统：2-4 周
- 定制和扩展：2-4 周
- 总计：5-10 周
两条路的成本差不多——自建投入开发但灵活性高，用框架投入学习但省心。Anthropic 自己的建议是：除非有非常特殊的业务需求，否则用现成框架，把节省下来的时间投入到业务逻辑上。
LangGraph 是目前最成熟的长任务 Agent 框架——它把状态、检查点、Human-in-the-Loop、超时控制全部做成开箱即用的能力。
四、企业落地的 5 个常见误区
执行 Harness 不难，但容易做错**。以下是 5 个最常见的错误模式。
误区 1：把 Harness 当成"事后优化"
很多团队先做 Agent 业务逻辑，遇到崩溃、超时、状态丢失问题才补 Harness。这是错的——Harness 必须在 Agent 设计之初就纳入架构。
正解：在 Agent 系统设计时，第一步就是定义 Harness。把持久化、检查点、超时、人工介入作为基础设施，先搭好再写业务逻辑。
误区 2：只做检查点不做状态恢复
有些团队实现了检查点但没实现恢复——崩了之后能从检查点重启，但 Agent 不记得之前做过什么，重新跑一遍。
正解：检查点和恢复是配套的。检查点保存完整状态，恢复时把状态加载回 Agent 上下文，让 Agent 从正确位置继续。
误区 3：超时设置过长
很多团队为了"让 Agent 有充足时间"，把超时设到几小时甚至几天。结果是一个失控的 Agent 可以烧掉几千块钱还没被发现。
正解：超时必须短而严。单步 60 秒、单任务 4 小时，超时立即终止。比"任务成功"更重要的是"成本可控"。
误区 4：Human-in-the-Loop 触发条件模糊
有些团队实现人工介入但触发条件写得很模糊（"Agent 觉得需要时"），结果要么从不触发要么频繁触发。
正解：明确列出"必须人工介入"的场景清单（如"涉及金额超过 1000 元"、"涉及客户承诺"、"涉及合规规则"），Agent 命中清单就触发。
误区 5：没有失败兜底
有些团队实现 Harness 但没有"任务最终失败时"的兜底——崩了就崩了，任务就丢了。
正解：必须有失败兜底。任务失败时：
- 保留完整审计日志（事后分析）
- 通知相关人员（业务方、运维、研发）
- 自动开一个失败工单（跟踪解决）
- 暂时禁用类似任务（避免重复失败）
五、给企业的 5 条具体建议
落到行动层面：
1. 第一步：明确你的"长任务"边界。 30 分钟以上的任务算长任务，必须有 Harness。
2. 第二步：先用框架（LangGraph / Managed Agents）跑通原型。 不要一开始就自建。
3. 第三步：把持久化、检查点、超时、人工介入、可观测五件套补齐。 一项都不能少。
4. 第四步：在真实业务里跑 2-4 周，收集失败案例。 用真实失败案例驱动 Harness 改进。
5. 第五步：建立 Harness 演进机制。 任务类型在变、业务在变、Harness 必须跟着迭代。
写在最后
长任务 Agent 的成功，90% 取决于 Harness，10% 取决于模型。这是 Anthropic 在工程文档里给出的明确判断。
如果你的 Agent 任务超过 30 分钟，第一件要做的事不是优化 prompt，而是补 Harness。把持久化、检查点、超时、人工介入、可观测这五件事做扎实，你的 Agent 系统会比 80% 的同类项目稳定。
Anthropic 的建议："Treat the harness as a first-class citizen, not an afterthought."——把 Harness 当一等公民，不要当事后补丁。
*本文基于 Anthropic *Effective harnesses for long-running agents* 与 LangChain *LangGraph* 两份一手资料整理，并结合企业 AI 平台团队在长任务 Agent 工程化中的真实经验。所有事实性表述都可追溯到原始素材；具体案例为通用化描述，不指向特定企业。*
