这次我们要聊的不是一个新的开源模型也不是某套本地部署包而是一个行业判断长时程任务到底是不是笑话AI 会不会进入幻灭低谷。提出这个观点的是 Chamath PalihapitiyaSocial Capital 创始人、前 Facebook 高管也是 All-In 播客里对 AI 泡沫表态最激进的人之一。他的核心逻辑并不复杂当前 AI 在“单点能力”上很强但一旦进入需要多步骤、长时间自主完成的任务错误率会迅速累积最终产出不可用所以“长时程任务”在现阶段仍然谈不上实用。这个观点在开发者社区里引起了两极分化。有人觉得他是外行看热闹有人则认为他戳中了 Agent 工程最痛的部位。这篇文章不站队而是把这个问题拆成技术问题来看长时程任务难在哪Agent 的技术栈卡在哪幻灭低谷对开发者到底意味着什么。如果你正在做 AI Agent、自动化流程、多步骤任务编排或者在评估要不要把业务交给 Agent 来做这篇文章可以直接收藏。1. 核心观点速览先把整件事放在一张表里方便快速判断这个议题和你的关系。事项说明观点来源Chamath 在公开播客、社交媒体上多次表达对 AI 长时程任务和行业周期的判断核心判断长时程任务当前不可靠AI 将进入幻灭低谷长时程任务定义需要模型自主完成多个步骤、跨工具调用、长时间运行并保持结果可控的任务技术难点错误累积、上下文漂移、工具调用不稳定、评估缺失行业周期背景对应 Gartner 技术成熟度曲线中的“幻灭低谷”阶段对开发者的影响Agent 项目可能从“能演示”走向“能交付”中间存在明显落差本文重点拆解长时程任务失败原因给出工程化验证与落地建议这里先明确一下“长时程任务长在哪”。短时程任务比如“把这段文字翻译成英文”“总结一下这封邮件”模型只需一次或少数几次推理就能完成长时程任务则是“帮我调研这个行业输出一份报告”“自动回复客服工单”“跨系统同步数据并生成对账结果”这一类。后者要求模型自己做计划、执行、检查、纠错并且要处理真实系统里的各种异常。Chamath 的判断本质上是说目前模型在这条长链条上的稳定性还远不够。2. 长时程任务为什么会被叫“笑话”一句“长时程任务是笑话”听起来刺耳但拆开看它背后有四个非常明确的技术原因。2.1 错误累积一步错步步错这是长时程任务最核心的失败模式。模型在第一步出错第二步可能在错误的基础上继续执行第三步错误被放大最终结果离目标越来越远。短任务里单次错误可以用重试解决长任务里错误会沿着执行链传播而且越到后面越难定位。可以写一段伪代码来模拟这个现象# 模拟长时程任务中的错误累积 # 假设每一步的成功率是 step_success_rate # 任务完成率 每一步成功率的乘积 def task_success_rate(steps: int, step_success_rate: float) - float: return step_success_rate ** steps # 单步成功率 0.95执行 10 步 print(task_success_rate(10, 0.95)) # 约 0.598 # 单步成功率 0.95执行 30 步 print(task_success_rate(30, 0.95)) # 约 0.214 # 单步成功率 0.9执行 10 步 print(task_success_rate(10, 0.9)) # 约 0.348这个公式当然简化了很多东西但它能说明长时程任务最基本的困境 就算每一步都做得很不错只要链条变长整体成功概率就会指数级下降。这也是“长时程任务仍是笑话”这句话最有技术含量的一部分。2.2 上下文漂移模型在执行长时程任务时通常会把之前的中间结果放进上下文里。但上下文越长模型越容易忽略早期关键信息或者在后续步骤中生成和早期结论矛盾的内容。这在技术圈被叫作上下文漂移或 Lost in the Middle。实际表现是任务开始时的目标约束执行到第 20 步时被模型自己改写了用户在初始 prompt 里输入的限制条件模型在后面某个子任务里直接忽略了。不是说模型没有能力而是长上下文下的一致性保持能力还不够尤其当中间穿插大量工具返回结果时注意力会被噪声带偏。2.3 工具与外部系统的不确定性长时程任务几乎不可能只靠模型自己完成必然要调用搜索、数据库、代码执行、API 等外部工具。问题在于模型每一步对工具的调用都可能遇到以下情况工具返回格式变化模型解析失败外部接口超时或限流模型不知道重试还是放弃工具的返回结果和预期不一致模型基于错误结果继续决策权限不足、数据缺失、网络波动这些不是模型能“思考”解决的。这些问题让长时程任务的失败点分布变得非常分散。有时候模型本身没问题但外部系统一次异常整个任务就断了。2.4 评估困难胜率指标掩盖了中段失败短任务的评估很直接翻译对不对、摘要准不准、分类对不对一眼就能看出来。长时程任务的评估则要复杂得多最终结果正确但中间步骤走了弯路算不算成功最终结果错误但中段有几个子任务完成得很好怎么评价任务执行了几十步系统崩溃后从哪一步恢复成功标准怎么定义。很多团队在 Agent 演示时只看“最终跑通了”但对失败路径没有任何统计。这就导致一个问题同一个 Agent在演示集上的完成率很好看换到真实业务数据上就崩。不是模型退步了而是评估标准没有覆盖长任务里真正的失败模式。3. 长时程任务的技术地图卡在哪个环节要判断长时程任务是不是真的“笑话”不能只看结论得看技术栈每一层的现状。技术环节当前状态主要问题任务规划演示效果强真实场景脆弱缺少对环境动态变化的感知记忆管理上下文窗口越来越大但不是记忆长程一致性差检索效率低工具调用单次调用成功率较高接口异常、格式变化、重试策略缺失自我反思能发现部分错误纠错能力有限容易陷入循环任务评估指标简单化缺少中段过程评估与失败路径分析3.1 规划看起来强实际脆现在的模型很擅长把一个大任务拆成子任务列表这个能力在短任务里看起来很惊艳。但只要子任务开始执行环境会变。第一步的结果可能和规划时的假设完全不同模型是否具备重新规划的能力很多 Agent 框架的做法是让模型循环“观察-思考-行动”理论上可以应对变化实际上如果模型的评判能力不够就会在错误的分支上越走越远。3.2 记忆上下文窗口不是记忆把上下文窗口做到 100 万 token不等于模型有了记忆。记忆意味着能够识别“哪些信息对当前决策重要”并且能在需要时稳定召回。目前的多数实现本质上是把全部历史塞进上下文靠模型注意力去筛。任务一长注意力在噪声上的分布会显著增加。真正工程化的记忆应该包含结构化摘要、向量检索引擎、关键事实存储和遗忘策略这些目前还处于早期阶段。3.3 工具调用成功率高但接口是脆的在固定格式、固定环境下当前模型调用工具的成功率已经不低。可真实系统的 API 不是为模型设计的字段命名、返回码、分页、限流、鉴权方式都可能是混乱的。模型不是不会调接口而是不会处理接口失败后的修复流程。这方面的差距需要工程框架来补例如重试队列、回退策略、人工审批节点而不是只靠一个更大的模型。3.4 自我反思能发现错误但不一定能修正反思机制也就是让模型审一遍自己的输出确实能降低一部分低级错误。但反思也有边界如果模型本身的推理能力不足以识别错误反思只会得到“我认为我做得对”这种无效结论。另一个典型问题是死循环模型发现自己错了重试又错了再重试反复消耗 token最终超时或耗尽预算。没有完善的终止条件自我反思反而会把任务拖入更糟的状态。3.5 评估最缺的一环长时程任务能不能工程化最终取决于能不能自动评估。目前比较可行的方法是拆解式评估把最终任务拆成多个原子子任务为每个子任务定义通过标准然后统计每一步的通过率、失败分布、平均重试次数。这样才能回答“这个 Agent 到底卡在哪”。但大多数项目没有做这一步结果就是所有长时程任务都停留在“能跑通 demo但不知道能不能上线”。可以给一个通用的评估配置文件参考{ task_name: customer_service_agent, max_steps: 20, evaluation: { subtask_passed: subtask.status completed, final_passed: final.report ! null final.accuracy 0.9, max_retry_per_step: 3, allowed_total_retries: 10, timeout_seconds: 600 }, metrics: [ first_step_accuracy, mid_term_error_rate, final_completion_rate, avg_retry_count ] }这套配置不是某个具体框架的标准而是长时程任务评估里常见的最小模型。第一步准确率反映模型的初始理解能力中段错误率反映长程执行能力最终完成率反映端到端可靠性平均重试次数反映成本。四个指标合在一起比单纯看“成没成”更能说明问题。4. 幻灭低谷AI Agent 工程正在经历什么讲完长时程任务本身再回到 Chamath 的第二个判断AI 将陷入幻灭低谷。这个判断用到的是技术成熟度曲线里的标准概念形容技术从被高估到被质疑、再到真正稳定落地的过程。4.1 幻灭低谷的技术含义技术成熟度曲线的核心逻辑是一项新技术刚出现时市场对它的期望会迅速超过实际能力当第一批真实用户开始用它做关键业务时发现效果不达预期期望就会快速回落随后技术进入缓慢改进期最终才形成稳定生产力。如果把 AI Agent 放进这个模型里看过去两年的高期待和现在大量长时程任务“Demo 惊艳但生产不可用”的反馈确实符合幻灭低谷的典型特征。4.2 哪些能力已经被验证需要客观看待的是并不是所有 AI 能力都处在幻灭期。以下场景已经被相当多的生产环境验证过文本分类、信息抽取、情感分析代码生成辅助、单元测试生成、代码解释短文本翻译、摘要生成基于 RAG 的固定文档问答语音转文字、OCR 等单点识别任务。这些任务的共同点是输入边界清晰输出可验证失败成本可控。它们不会因为“幻灭低谷”的讨论而退步。4.3 哪些能力还在演示阶段需要真正质疑的是完全自主的长时程任务、复杂多步骤工作流、跨系统自动决策。这些场景里模型要承担大量规划和纠错责任而当前工程体系还没能补齐错误累积、上下文漂移、接口故障处理这些问题。把这些任务称为“演示级能力”比直接说“笑话”更准确也更符合实际体验。4.4 对“AI 将陷幻灭低谷”的判断边界按公开讨论的常见转述Chamath 的判断是有保留空间的。更稳妥的理解是他会认为市场对 AI 的过度投资会先于技术成熟到来导致行业整体估值和关注度回落。对开发者来说这意味着两件事一是资本和市场热度可能收紧纯靠概念拿资源会变难二是真正具备工程价值的产品会在这个过程中被筛选出来。幻灭低谷不是技术的终点而是“演示级”和“生产级”开始分道扬镳的节点。5. 工程化瓶颈盘点长时程任务距离可用还差什么如果说上一节讨论的是行业周期这一节就落到具体工程问题。我把长时程任务从“能演示”到“能交付”之间的差距分成五个瓶颈。瓶颈典型表现对业务的影响当前可行解决方案可靠性不足长任务完成率低失败路径不可预测无法稳定交付缩小任务范围增加人工审核节点成本不可控长任务 token 消耗高重试次数多单次任务成本超出业务预算设置执行预算限制最大步数和重试次数人工兜底缺失Agent 失败后没有接管机制异常流程堆积运维压力大设计人工审批和转人工通道数据回流困难失败案例没有进入训练或 prompt 优化同类错误反复出现建立失败样本库定期回归测试安全与合规风险自动决策难以审计不适合高风险业务保留完整轨迹日志限制敏感操作权限这五个瓶颈里可靠性是核心。成本、数据、安全都可以靠制度设计来缓解但可靠性不足会让整个任务在源头失去信任。所以工程化的第一步不是让 Agent 更聪明而是设计一个能在 Agent 不稳定时仍然不失控的系统框架。5.1 可靠性不达标时不要直接追求全自动化目前最稳妥的做法是“分段自动化 人工审批节点”。让 Agent 负责执行有明确规则的子任务在关键决策点停下来由人来确认。等某个环节的通过率稳定超过阈值再逐步减少人工介入。这一步不是妥协而是长时程任务进入生产环境的必经过程。5.2 成本预算要按失败场景设计很多团队只算了成功路径的 token 成本没有算失败路径。一次任务重试 5 次、调用 20 次工具、每次返回 2000 token成本会迅速翻倍。建议在 Agent 框架层面加入最大步数、单步最大 token、重试次数上限超出后强制终止并转人工。把失败成本纳入预算模型长时程任务才具备可算的经济性。5.3 数据回流是 Agent 持续改进的燃料幻灭低谷期最常见的现象是同类错误反复发生因为失败样本没有被收集。工程化团队应该把每一次 Agent 执行的轨迹、报错、人工修正结果记录下来形成失败样本库。每隔一段时间用这些样本做回归测试再针对性优化 prompt、工具调用策略或评估规则。这个闭环是长时程任务从不可用走向可用的关键。6. 如何验证一个长时程任务是否真的可用如果你正在评估某个 Agent 框架或者自研长时程任务系统不要只信演示建议用下面这套流程做一次独立验证。6.1 设计一个最小可验证任务先选一个业务上真实存在、但边界足够小的任务。例如任务目标读取某个目录下的 20 个 PDF 发票提取关键字段汇总成一个表格成功标准字段准确率不低于 95%表格格式完全正确执行限制最多 30 步超过即失败人工兜底每一步识别结果可以人工抽查。这个任务既不复杂到无法控制又包含了解析、提取、结构化输出、批量处理等多个环节足够暴露长时程任务里的大部分问题。6.2 记录完整执行轨迹不要只记录最终结果要记录每一步的输入、输出、决策理由、工具调用结果、重试次数。这样后期分析失败路径时才能知道到底是在规划层、工具层还是输出层出的问题。# 通用执行轨迹统计模板需要按实际框架调整 import json from collections import Counter with open(agent_trajectory.json, r, encodingutf-8) as f: traces json.load(f) step_counter Counter() error_counter Counter() for trace in traces: for step in trace[steps]: step_counter[step[type]] 1 if step.get(error): error_counter[step[error][type]] 1 print(步骤类型分布:, step_counter) print(错误类型分布:, error_counter)这段代码的思路是先统计执行步骤的类型分布再统计错误类型分布。如果“工具调用错误”占了大部分说明问题在接口稳定性如果“反思循环”占了大量步骤说明终止条件没设计好如果“中间结果格式错误”频发说明 prompt 或解析逻辑需要修复。6.3 用过程指标评价而不是只看完成率评价长时程任务至少要看四组数据指标含义阈值建议首步正确率模型是否在第一步就理解任务目标应尽量接近 90%中段纠错率模型在中间步骤出错后能否自动纠正低于 50% 时系统很难稳定最终完成率端到端成功比例生产环境建议 95% 以上平均重试次数稳定性和成本的综合体现超过 3 次需要关注这些阈值是一个通用参考具体到不同业务可以调整但主轴很清晰不要用最终完成率掩盖过程失败。如果最终完成率很高但中段纠错率很低说明任务本身简单Agent 的鲁棒性并没有被真正验证。6.4 加入回归测试机制长时程任务系统改一个 prompt可能影响所有下游步骤。因此要为每个已验证的任务维护一套回归测试集。每一次提示词更新、模型切换、工具接口变更都在这套测试集上跑一遍对比完成率、重试次数、错误分布三个指标。一旦关键指标下降立即回滚或修复。7. 给开发者和企业的建议回到 Chamath 观点的现实意义。长时程任务在某一天可能不再是一个“笑话”但前提是工程团队先解决下面这些问题。7.1 先做小闭环再拉长时间不要一上来就构建一个几十步的超级 Agent。先选一个 3 到 5 步的闭环任务把它做到稳定再逐步增加步骤。每增加一个步骤都要重新评估整体成功率曲线。这样做的好处是一旦失败你能很清楚地定位是新增步骤的问题还是原有逻辑的退化。7.2 让人工兜底优先于完全自动化在长时程任务不可靠的阶段系统设计应该默认“人工参与”。Agent 负责执行和草拟人工负责审批和修正。这样即使模型出错损失也可控。真正进入生产环境的长时程任务几乎都有人工审核环节这不是能力不足而是工程上必须保留的安全阀。7.3 用可观测性对抗黑盒长时程任务最可怕的地方在于你不知道它哪一步开始跑偏。所以每个任务都需要完整日志包括 prompt、模型输出、工具输入输出、重试记录、耗时、成本。只有把执行过程变成可观测数据才能在失败时快速复盘。7.4 预算要按失败成本设计每次 Agent 调用都会产生成本。如果任务可能失败预算必须包含重试和人工修复的成本。建议为每个长时程任务设置独立的 token 预算和超时阈值超出后自动终止。宁可让任务失败也不要让它在一个错误方向上消耗大量资源。7.5 安全与合规边界长时程任务一旦涉及自动操作外部系统就需要特别谨慎。自动发送邮件、自动提交订单、自动删除数据、自动修改权限这些行为必须经过确认。系统应该支持权限分级Agent 默认没有高危操作权限。日志审计建议至少保留一个完整执行周期以便出问题时追溯。8. 总结与下一步回到最初的问题长时程任务是不是笑话从行业演示来看它还没有完全脱离“笑话”的风险从技术拆解来看主要瓶颈不是模型智商而是错误累积、上下文一致性、工具调用稳定性、评估体系缺位这四个工程问题。任何一个环节解决到生产级水平长时程任务的价值都会大幅提升。对正在做 Agent 开发和选型的人来说最近这段时间最值得做的事不是追新模型而是回到业务本身把一个 3 到 5 步的真实任务做成稳定闭环。然后加上轨迹日志、失败样本库、回归测试再逐步扩展任务长度。整个过程里保持对“最终完成率”的警惕多关注首步正确率、中段纠错率和平均重试次数。数据不会骗人它能告诉你这个 Agent 到底能不能扛长时程任务。