最近投资人 Chamath 的一句评论在 AI 圈里传得很快长时程任务仍是笑话AI 将陷入幻灭低谷。这句话大概率会让不少正在做 Agent 产品的人感到冒犯但稍微冷静一点就会发现它戳中了当前 AI 应用最疼的地方。过去一年我们见过太多惊艳的 demoAI 能写代码、能做 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 化的信号不适合 Agent 化的信号任务时长单个子任务能在分钟级内完成需要运行数小时且中间不可断步骤依赖子任务之间相对独立任意步骤失败都会导致全局推翻错误可恢复性失败后可以从检查点恢复失败后必须从头开始验证信号有明确的测试、比对、检查方式输出靠人主观判断没有客观标准工具环境有 API、命令行等可控接口需要操作不稳定的 GUI、验证码、第三方权限领域知识规则明确、逻辑固定需要大量隐含经验、价值判断人工介入成本少量节点人工确认即可每步都需要人确认自动化意义变小这张表本质上在说长时程任务能不能做不只看模型能力还要看任务本身是不是“可验证、可回滚、可分段”。闭环越强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 跑挂了不要盲目重试也不要直接换一个更大的模型。按下面的顺序排查通常能快速定位问题看最终输出是完全错误中间卡住还是工具调用失败。看执行日志确认每一步是否真实执行模型有没有编造结果。看上下文是否因为截断或漂移导致模型忘记目标或约束。看验证器验证器本身设计是否合理阈值是否过于严格或宽松。看子目标划分子目标粒度是不是太粗导致一步出错连带后面全部失败。举个例子。如果你在日志里发现模型声称“调用成功”但工具层根本没有调用记录那问题出在工具调用校验需要强制返回码检查。如果你发现模型在后期还在使用已经过期的中间变量那就要提高状态文件的刷新频率并在每次调用前注入最新版本。如果子目标包含的价值判断太多那就把该步骤改为人工决策点。注意不要让 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 做点实事我的建议很简单从一个小而清晰、有明确验证标准的任务开始先跑通再拉长别急着给它一整个工作流。