长时程任务为何总翻车？Agent工程化闭环的四个技术瓶颈与解法

最近，投资人 Chamath 的一句评论在 AI 圈里传得很快：长时程任务仍是笑话，AI 将陷入幻灭低谷。这句话大概率会让不少正在做 Agent 产品的人感到冒犯，但稍微冷静一点，就会发现它戳中了当前 AI 应用最疼的地方。过去一年，我们见过太多惊艳的 demo：AI 能写代码、能做 PPT、能查资料、能写文章。可一旦让它从头到尾独立完成一个需要持续十分钟以上、跨多个工具、并且需要不断修正方向的真实任务，成功率就会断崖式下跌。问题到底出在哪里？是模型还不够聪明，还是我们对“长时程任务”的理解本身就出了问题？

我的判断是：长时程任务暴露的不是 AI 的智商，而是整个 Agent 工程化体系的幼稚。所谓“幻灭低谷”，其实是一次迟到但必要的行业体检。与其争论“AI 是不是笑话”，不如看清楚笑话背后的机制，然后再决定怎么把事做成。

1. 先别急着反驳：短任务惊艳和长时程翻车为什么同时存在

1.1 一个每天都在发生的场景：写脚本能对，跑流程就崩

你可以自己复现一个最简单的对比。给 AI 一个需求：写一个 Python 脚本，把某个目录下的 CSV 文件合并，生成一个汇总 Excel。大多数模型都能直接给出可运行的代码。但如果你把任务改成这样：

请你先调研目录结构，和用户确认合并规则，写脚本，在临时环境里执行一次，如果遇到日期格式不一致就自动修复，最后输出结果文件并验证行数是否正确。

你会发现，模型很可能在前面几步还正常，到中途就忘记最初的数据规则，或者在没有真实执行环境的情况下直接假设“执行成功”。这不是模型不会写代码，而是它不具备“长时间维持一个任务状态并主动纠错”的稳定能力。

单次代码生成，模型只需要在输入和输出之间建立映射。长时程任务则要求模型同时做好规划、记忆、工具调用、结果校验和计划调整。这两件事的难度完全不在一个量级。

1.2 单步准确率再高，也扛不住多步串联的指数衰减

假设模型每一步的准确率是 98%。两步都正确的概率是 96%，五步是 90%，二十步就只剩下 67%。如果每一步还需要调用外部工具，而工具结果本身也有 5% 的异常率，那么二十步任务的成功率会掉到 30% 以下。

这不是某个模型的缺陷，而是串联系统的数学现实。更麻烦的是，大语言模型的错误不是均匀随机分布的，它会在某个步骤上出现“自信的错误”——模型会非常流畅地告诉你“已经完成了”，但实际上它根本没调用工具，或者把上一步输出当成了事实。这种“流畅的错误”比直接报错更难排查，因为它不会触发异常处理机制，只会让后续步骤沿着错误方向继续推进。

1.3 真正的问题不是没有世界模型，而是缺少闭环验证

很多人把长时程任务的失败归因于“AI 没有世界模型，不理解真实世界”。对 Agent 而言，更贴切的解释是：AI 没有可靠的验证机制。

一个人类工程师在写代码时，会通过编译器报错、测试用例、代码审查、线上监控来不断获得反馈，然后修正自己的行为。而当前的 Agent 大多数只是“生成下一步动作”，并没有真正把执行结果当作修正依据。换句话说，它不是在“做任务”，而是在“表演做任务”。

当没有闭环验证时，步骤数越多，表演和现实的偏离就越大。所以 Chamath 说“长时程任务仍是笑话”，其实是在说：当前的 Agent 在“没有人在环上持续纠偏”的开放任务里，还不能成为可信的执行者。

2. 从“长时程任务”这个批评里，拆出四个真实的技术瓶颈

2.1 错误累积：一步错，步步错，而且无法自知

错误累积是长时程任务的第一杀手。单次输出中的小误差，会被后续步骤当成事实输入。例如，模型先错误地假设某个函数存在，后面所有代码都基于这个假设，最终编译失败。更糟糕的是，模型往往会在生成“错误修复计划”时继续沿用一个已经错误的中间状态，而不是回到根因。

这导致很多 Agent 看起来在“努力尝试”，实际上只是在同一个错误附近打转。要减轻错误累积，必须在每完成一个子目标后做结果校验，而不是让模型连续自嗨。一个简单的习惯是：每跑完一个子任务，把真实结果的哈希、行数、状态码记录到状态文件里，后续步骤只能读取校验过的结果。

2.2 上下文漂移：模型记得开头，却忘了任务目标

长时程任务意味着模型需要处理很长的上下文。尽管现代模型动辄支持 100K、200K token，但上下文长不代表模型能有效利用。研究表明，模型对上下文中不同位置的注意力并不均衡，离当前越远的指令，越容易被忽略。

一个运行了 15 分钟的 Agent，很可能已经忘了用户最初提出的“不要改动原始文件”这类约束，只盯着最近的日志输出。这种漂移不是“记忆容量不够”，而是注意力分配问题。工程上常见的对策是：把任务目标、约束条件、当前进度写进一个独立的“状态文件”，每次模型调用前都重新注入这段关键信息，而不是只依靠对话历史。

注意：不要相信模型能“记住”你放在对话开头的要求。凡是关键约束，都要在每一轮子任务开始时显式注入。

2.3 工具调用不可靠：模型会“编造”执行结果

Agent 往往需要调用外部工具，比如执行 shell 命令、访问网页、查数据库。问题在于，模型在生成工具调用结果时，有时不会忠实返回工具的真实输出，而是根据概率预测一个“合理的结果”。这在演示环境里很难察觉，但在真实任务中会直接导致后续步骤跑偏。

例如，模型声称“文件已删除”，但文件还在；模型声称“API 返回 200”，但实际服务已经超时。所以，一个可用的 Agent 框架必须在工具调用层强制校验真实返回码，并把真实的 stdout/stderr 传回模型，而不是让模型自由想象工具结果。

这一点在本地部署开源模型时尤其明显。比如用 Ollama 跑较小参数的模型，工具遵循能力更弱，更容易出现“幻觉式的工具结果”。这里的“幻觉”不是模型故意撒谎，而是它对不确定结果的平滑预测。解决思路也简单：外部程序先接管真实执行，返回码不对绝不重试，更不要把这个错误结果写进上下文。

2.4 缺少有效的验证信号：做得对不对，没人告诉它

人类学习一个复杂任务，靠的是不断收到反馈：对了就继续，错了就调整。而当前大多数 Agent 的推理链路里，并没有一个客观的“任务奖励函数”。LLM 训练时的强化学习只能让模型生成更符合人类偏好的文本，并不能让它在具体的长任务中判断“我这样做对吗”。

所以你会看到，一个 Agent 可以很流畅地生成一份错误的报告，并且完全没有愧疚感。要解决这个问题，只能靠外部系统为每个子任务设计验证器：代码任务跑测试，数据处理任务比对统计结果，文档任务检查事实引用。没有验证器的长时程自动化，本质上是在裸奔。

3. 用一张表判断：你的任务到底适不适合 Agent 化

并不是所有长时程任务都应该自动化，也不是所有任务都不能自动化。把任务扔给 Agent 之前，先做一次“可工程化闭环”体检。下面这个表来自我自己的项目筛选经验，不一定全，但足够帮你避开大多数坑。

这张表本质上在说：长时程任务能不能做，不只看模型能力，还要看任务本身是不是“可验证、可回滚、可分段”。闭环越强，Agent 越可靠。Chamath 批评的，正是那些“不可验证、不可恢复、没有明确边界”的长任务，这类任务在今天确实还是笑话。

但反过来，如果任务本身就适合自动化，比如从固定格式日志里提取异常并生成报表，那么即使它是“长时程”的，工程上也能拆成可靠性很高的短任务流水线。所以，普通开发者看到这篇批评，先别急着站队，拿出你手里最想自动化的那个任务，对照这张表过一遍，答案已经很清楚了。

4. 工程首选：把长时程任务拆成“短时程 + 人机交互闭环”

4.1 一个能落地的架构思路：Agent 做主流程，人在关键节点做决策

当前阶段，最稳妥的长时程任务自动化不是“全自动无人值守”，而是“分段自动 + 关键节点人工确认”。

以一个 10 步任务为例，可以拆成三个子阶段：调研分析 → 方案撰写 → 执行验证。每个子阶段结束后，Agent 自动生成一份中间结果报告，由人确认后才进入下一阶段。这样做有两个好处：第一，错误只在段内累积，不会跨段放大；第二，人工确认点也为系统提供了客观的“成功信号”，相当于把主观判断环节重新交还给了人。

别小看这个“妥协”。长时程任务失败率高，不是因为模型单步能力弱，而是因为它无法在开放环境里维持一个正确的全局状态。人机交互闭环正是用来补足这块短板的。

4.2 更具体的操作：子目标、检查点、状态文件、验证器、失败重试

把方法论落到脚本里，可以按下面这套规则来做：

• 子目标拆解：把大任务写成结构化的子目标列表，每个子目标必须包含“完成条件”。
• 状态文件：为 Agent 维护一个当前状态文件，记录目标、已完成步骤、下一步计划、约束条件。每次调用模型前都重新读取状态文件。
• 检查点：在关键节点保存中间结果，并允许失败后从检查点恢复。
• 验证器：为每个子目标设计验证函数，比如“代码是否编译通过”“输出文件是否存在且行数大于 0”。
• 日志：完整记录每个步骤的输入、输出、工具调用结果，这是排查问题的唯一依据。
• 失败重试：设置最大重试次数，重试前要求模型总结失败原因并修改计划，而不是直接在原错误上重跑。

一个简化的 Agent 循环伪代码是常见写法，可以直接作为设计参考：

state = init_state(task) while not state.finished(): subgoal = plan_next_subgoal(state) result = execute_with_verification(subgoal) if result.valid: state.update(subgoal, result) save_checkpoint(state) else: issue = identify_error(result) if retry_count < MAX_RETRY: state.add_feedback(issue) retry_count += 1 else: ask_human_for_decision(issue)

这段伪代码的核心思想很简单：没有验证，就没有下一步。验证失败的反馈要写回状态文件，而不是靠模型自己“反思”。

4.3 排查长时程任务失败的系统性链路

当 Agent 跑挂了，不要盲目重试，也不要直接换一个更大的模型。按下面的顺序排查，通常能快速定位问题：

1. 看最终输出：是完全错误，中间卡住，还是工具调用失败。
2. 看执行日志：确认每一步是否真实执行，模型有没有编造结果。
3. 看上下文：是否因为截断或漂移导致模型忘记目标或约束。
4. 看验证器：验证器本身设计是否合理，阈值是否过于严格或宽松。
5. 看子目标划分：子目标粒度是不是太粗，导致一步出错连带后面全部失败。

举个例子。如果你在日志里发现模型声称“调用成功”，但工具层根本没有调用记录，那问题出在工具调用校验，需要强制返回码检查。如果你发现模型在后期还在使用已经过期的中间变量，那就要提高状态文件的刷新频率，并在每次调用前注入最新版本。如果子目标包含的价值判断太多，那就把该步骤改为人工决策点。

注意：不要让 Agent 把“我感觉成功了”当作“真的成功了”。凡是写在自然语言结果里的结论，都必须通过外部验证器复核。

5. 幻灭低谷未必是坏事：AI 工程化反而会迎来“靠谱红利”

5.1 技术成熟度曲线：从泡沫顶峰到幻灭低谷，再到生产力平台

任何技术都会经历一个类似曲线：新的能力被展示出来，资本和媒体一拥而上，期望被拉到不切实际的高度；进入真实场景后，缺陷暴露，失望情绪蔓延；最后，真正能解决问题的产品逐步沉淀下来，技术才进入生产力平台期。

AI 过去两年正处于“期望膨胀期”。任何 demo 都会被放大成“取代人类”。但一旦进入生产环境，长时程任务的脆弱性就会集中暴露，于是类似“笑话”“幻灭低谷”的说法开始出现。这是非常正常的周期现象。

幻灭低谷的准确含义，不是技术结束了，而是市场开始用严苛标准审视产品。之前靠宣传取胜的公司可能会被清洗，而那些愿意处理验证、日志、错误恢复、人机交接等脏活的团队，反而会在这个阶段拉开差距。

5.2 对开发者而言，接下来最值得投入的三件事：可评估性、可观测性、可控性

在低谷期，最值得做的不是继续追新模型，而是把 Agent 工程的基础能力补齐。

• 可评估性：为你的 Agent 建立明确的任务完成率指标，不是“感觉它变聪明了”，而是“一百个真实任务里，它能独立完成多少个，需要人工干预多少次”。
• 可观测性：记录每次调用的输入输出、token 成本、延迟、错误类型，并形成趋势看板。
• 可控性：设计多种降级策略。长任务失败时能不能退回短任务？全自动不行时能不能变半自动？能不能让用户随时接管？

这三个词可以成为团队下一步的北极星。它们不像“新模型出来了”那么刺激，但决定了一个 Agent 能不能从 demo 阶段走进生产环境。

5.3 给团队和决策者的建议：别用 demo 做判断，用任务完成率做判断

如果你有预算和决策权，建议不上听任何专家的定性评价，包括这篇博客。只做一件事：选 20 个生产环境里的真实任务，做成标准测试集，记录三个数据——独立完成率、平均人工干预次数、平均任务时长。

用这个测试集去评估模型、框架和 Agent 方案。这个月跑一次，下个月跑一次，半年后再跑一次。你会发现，比“模型智商高不高”更有价值的是“系统可靠性能不能持续改善”。

对普通开发者来说，也别在“哪个模型最强”上反复横跳。先把属于自己的任务闭环做扎实，再用真实数据决定下一步买哪家的 API，或者本地部署什么模型。

6. 回到 Chamath 的批评：哪些说对了，哪些可能低估了工程的力量

6.1 他对的部分：当前 Agent 在非结构化长任务上确实脆弱

如果“长时程任务”的定义是“用户给一个模糊目标，AI 自己拆解、自己规划、自己执行、自己纠错、自己交付”，那么当前所有主流模型都还不值得托付。

原因就是我们前面讨论的错误累积、上下文漂移、工具幻觉、缺少验证。这不是某个产品的问题，而是大语言模型概率生成机制的结构性问题。那些把 Agent 宣传片当成生产可用的团队，大概率会在第一轮真实任务里被反噬。Chamath 在这方面的判断是对的。

6.2 他低估的部分：工程化拆解能把长任务变成一系列可控短任务

但他可能低估了工程的力量。人类在做复杂项目时，也不是靠单次“全知全能”，而是靠工作分解、里程碑评审、测试回归、风险预案。这些方法论完全可以迁移到 AI Agent 的架构里。

当你把一条 20 步的长任务，拆成 4 个 5 步子任务，并且每个子任务都配置验证器和人工确认点，系统的整体可靠性会大幅提升。此时，“长时程任务”不再是一个不可分割的混沌体，而是一串可靠的短任务组合。Chamath 的批评适用于“不加约束的全自动幻想”，但不太适用于“面向可信交付的系统设计”。

6.3 我的最终判断：未来的主力不会是“全能 Agent”，而是“长在业务流程里的窄 Agent”

真正的机会不是做一个能帮人完成所有事的通用 Agent，而是把 Agent 嵌入到具体业务流程里：自动处理账单对账、自动生成周报初稿、自动进行代码评审、自动巡查数据库慢查询。

这些场景的共同点是：任务边界清晰、验证信号明确、失败影响可控。它们虽然不是“长时程任务”的终极形态，但却是今天能产生实际价值的形态。等这些窄 Agent 的可靠性逐步积累，再逐步延长任务周期，才是更现实的演进路径。

所以，“长时程任务仍是笑话”这句话，我更愿意把它理解成一个提醒：AI 的智能感来自语言流畅性，而不是执行可靠性。幻灭低谷确实会来，但它的意义不是让人离场，而是让那些只靠 demo 活着的人离场，让那些愿意做脏活累活、搭验证器、做日志、设计人工交接点的人获得真正的红利。

如果你正打算用 Agent 做点实事，我的建议很简单：从一个小而清晰、有明确验证标准的任务开始，先跑通，再拉长，别急着给它一整个工作流。