最近关于 AI 行业阶段的一个判断引发了不少讨论Chamath 认为长时程任务仍然是笑话AI 即将进入幻灭低谷。这个判断听起来刺耳但放到实际工程里并不全是情绪发泄。过去一年里AI Agent 的演示视频确实惊艳但真正把 Agent 放到生产环境处理多步骤任务的人大概率都遇到过任务跑一半就停、错误不断累积、上下文被污染的情况。长时程任务不是“把 Prompt 写长一点”就能解决的它涉及模型能力、状态管理、工具调用、评估体系和容错机制等多个层面的工程问题。本文从工程视角拆解这个观点。先说明长时程任务到底是什么再分析它为什么容易失败然后提供一个不依赖外部大模型 API 的最小沙盘实验用来复现“任务步骤变多后成功率下降”的过程。最后讨论幻灭低谷对 AI 工程投入节奏的影响以及团队和个人开发者可以从哪些方向提高长时程任务的成功率。1. 先理解“长时程任务”在 AI 工程里到底指什么1.1 从单轮问答到多步执行AI 能力维度的变化传统的大模型应用形态是单轮问答用户输入问题模型输出答案。这个过程的反馈循环很短输入和输出在同一个会话里完成即使模型说错用户也能立刻发现并重新提问。长时程任务不同。它要求模型在多个步骤之间保持目标一致持续操作外部系统并且在中间结果不符合预期时自行调整。典型场景包括从数据库读取数据经过清洗、转换、去重后再写入目标表。根据需求文档生成代码编译、运行测试、修复报错、再次运行。自动化处理一批工单每张工单需要查询信息、调用接口、确认结果、记录日志。把一个跨系统的数据迁移任务拆成多个阶段每个阶段都要校验上一阶段的输出。这些任务的共同点是模型不能只生成一段文本它必须在一个闭环里完成“理解状态、决定动作、观察结果、修正下一步”的循环。这个循环每多转一圈系统的不确定性就会增加一分。1.2 长时程任务的三个典型技术特征判断一个任务是不是长时程任务可以看三个特征。第一步骤数量多。任务被拆成多个子步骤子步骤之间存在依赖关系后一步要依赖前一步的输出。步骤越多链条越长。第二外部反馈延迟。模型调用工具后结果不会立刻变成可用的最终答案需要解析返回值、判断是否成功、决定是继续还是重试。这个反馈过程可能涉及网络请求、文件读写、数据库事务甚至需要等待人工审批。第三状态需要持久化。Agent 在执行过程中不能只靠模型上下文记住“做到哪一步”因为上下文会溢出也会被中间日志污染。状态必须存放在可查询、可回滚的结构化位置。如果某个任务只是“写一封邮件草稿”它仍然是短时程任务。如果这个任务是“把 200 个客户按规则分层生成个性化邮件发送前经过审批发送后记录送达状态”它就已经进入了长时程任务范畴。1.3 为什么演示视频会高估 Agent 的能力演示视频通常经过精心剪辑。视频里的 Agent 可能只跑了一次成功路径没有展示失败重试、上下文污染、工具返回异常和人工介入的过程。观众看到的是“点一下按钮任务自动完成”但工程上真正难的是那些没有出现在视频里的分支情况。这种现象并不只在 AI 领域存在任何自动化系统在演示时都会选择最优路径。但大模型 Agent 有一个特殊问题它的每一步输出都是概率性的即使同样的输入、同样的 Prompt两次运行也可能得到不同结果。演示视频只能证明“这个任务在某种条件下可以完成”不能证明“这个任务在生产环境里可以稳定完成”。所以“长时程任务仍是笑话”这个观点核心指向的是稳定性问题。不是模型不能写代码、不能调工具而是多步执行下的成功率还没有达到生产可用的标准。2. 为什么长时程任务容易失败五个核心瓶颈2.1 误差累积小错误到最后被放大长时程任务最直观的失败原因是误差累积。模型每一步都有一定概率犯错可能是理解错了输入可能是生成了错误的工具参数也可能是把中间结果写错了位置。单步错误率看着不高但只要任务步骤足够多整条链路的成功率就会快速下降。假设每一步的成功率是 95%5 步任务的总成功率是 0.95 的 5 次方约 77%。如果任务有 20 步总成功率降到约 36%。如果每步成功率只有 90%20 步任务的总成功率只有约 12%。这个指数关系是数学层面的和模型聪明不聪明没有直接关系。这也是为什么很多 Agent 在 2 到 3 步的演示里表现良好一旦进入真实业务场景几十个步骤连环执行失败率就变得不可接受。2.2 上下文窗口不等于决策容量大模型的上下文窗口越来越长但长上下文不意味着模型能有效利用所有信息。任务执行过程中每一步的工具返回、日志、错误信息都要拼进上下文。随着上下文变长模型需要从大量文本里定位关键状态注意力分散出错概率反而上升。更麻烦的是上下文里既包含事实状态也包含推理过程、错误信息、历史动作。模型很难区分“哪一段是最新的真实状态”和“哪一段只是我之前的猜测”。一旦模型基于过期状态做决策后续步骤就会建立在错误地基上。上下文窗口解决的是“能不能容纳”的问题工程上还需要解决“该把什么放进去”的问题。长时程任务里正确做法不是把所有历史都塞给模型而是只把当前步骤需要的结构化状态和少量必要上下文传给模型。2.3 工具调用和状态管理没有统一契约Agent 要完成长时程任务几乎必须调用外部工具查数据库、写文件、调接口、执行命令。每个工具都有自己的参数格式、返回结构和错误语义。Agent 框架如果只是把工具描述拼进 Prompt让模型“自由发挥”很容易出现参数缺漏、类型错误、返回解析失败。例如一个工具返回 JSON正常情况包含status字段失败情况可能返回error字段。模型如果只用status判断成功就可能把失败请求当成成功。工具调用层需要一个统一协议明确什么算成功、什么算失败、失败后应该重试还是终止。状态管理同样是关键。如果每一步的中间结果只是字符串拼接下一步就很难判断前一步是否真的完成。结构化状态应该包含步骤编号、输入快照、输出快照、校验结果、执行时间、重试次数等字段让 Agent 和运维人员都能看清当前进度。2.4 自我修正机制本质上是概率性的很多 Agent 框架宣称具备自我修正能力模型发现错误后读取错误信息重新规划再次尝试。这个机制听起来很合理但实际执行时存在两个问题。第一模型不一定能正确识别错误。有时工具已经返回了明确异常模型仍然按照原计划继续执行把异常信息忽略掉。第二重新尝试可能产生新的错误。模型可能修正了参数格式却又在下一步选择错误分支。自我修正在短路径上有效在长路径上会变成新的不确定性来源。工程上不能把“自我修正”当作默认能力。更稳妥的做法是给 Agent 设置最大重试次数每步执行后强校验输出校验失败就进入预设的修复流程而不是让模型自由发挥。2.5 任务完成度的评估本身很困难短时程任务容易评估答案是 A 还是 B一眼就能判断。长时程任务不同任务的最终结果可能是“数据已迁移”“代码已部署”“工单已处理”但“处理完成”的标准很难形式化。比如“把 200 个客户分层并发送邮件”成功的标准是什么是接口全部返回 200还是每一封邮件都被客户打开显然不能混为一谈。没有明确的完成标准Agent 就无法判断自己是否已经完成也就无法决定何时停止。很多 Agent 任务失败不是模型能力不足而是目标定义不清楚系统在错误的方向上反复执行。3. 用最小沙盘实验复现“长时程任务翻车”3.1 实验目标不依赖外部大模型也能看到失败率曲线为了验证“步骤越多成功率越低”这个判断我们构建一个最小沙盘实验。它不调用任何外部大模型 API也不依赖网络只用一个模拟模型来模拟每一步可能出现的执行错误。这个实验的价值有两个。第一它把长时程任务的失败原因压缩成最核心的“单步错误率”和“任务步数”两个变量方便观察趋势。第二它可以作为真实 Agent 系统的简化模型后续可以替换成真实模型和真实工具复用同样的成功率和排查思路。3.2 项目结构与核心类设计项目只需要一个 Python 文件包含四个核心对象Step描述一个子步骤包括步骤名、输入键、输出键。RandomModel模拟不稳定的大模型以固定概率返回错误。Task按顺序执行步骤列表更新状态记录执行轨迹。simulate多次运行任务计算成功率。这种设计与真实 Agent 框架的抽象方向一致真实框架里的Agent相当于TaskLLM相当于RandomModel外部工具相当于步骤里的输入输出映射。区别只是真实模型的错误率不是均匀分布而是与任务难度、Prompt 质量、工具设计相关。3.3 完整可运行代码下面是完整的沙盘实验代码保存为long_horizon_sandbox.py。# long_horizon_sandbox.py import random from dataclasses import dataclass from typing import Dict, List, Tuple dataclass class Step: name: str input_keys: List[str] output_key: str class RandomModel: 模拟不稳定的大模型以固定概率产生错误。 def __init__(self, error_rate: float 0.2): self.error_rate error_rate def complete(self, step_name: str, input_data: dict) - dict: if random.random() self.error_rate: return { status: error, message: fmodel failed at {step_name}, } return { status: ok, data: {value: input_data.get(value, 0) 1}, } class Task: def __init__(self, steps: List[Step]): self.steps steps def run( self, model: RandomModel, initial_state: dict ) - Tuple[bool, dict, List[str]]: state dict(initial_state) trace [] for step in self.steps: input_data {k: state.get(k) for k in step.input_keys} output model.complete(step.name, input_data) trace.append(f{step.name}: {output}) if output[status] ! ok: return False, state, trace state[step.output_key] output[data] return True, state, trace def build_n_step_task(n: int) - Task: steps [] for i in range(1, n 1): input_key state_0 if i 1 else fstate_{i - 1} steps.append( Step( namefstep_{i}, input_keys[input_key], output_keyfstate_{i}, ) ) return Task(steps) def simulate(task: Task, model: RandomModel, trials: int 1000) - float: success 0 for _ in range(trials): ok, _, _ task.run(model, {state_0: {value: 1}}) if ok: success 1 return success / trials if __name__ __main__: random.seed(42) for step_count in [3, 5, 8, 12]: task build_n_step_task(step_count) model RandomModel(error_rate0.1) rate simulate(task, model) print(fsteps{step_count}, error_rate0.1, success_rate{rate:.2%}) for error_rate in [0.0, 0.1, 0.2, 0.3]: task build_n_step_task(5) model RandomModel(error_rateerror_rate) rate simulate(task, model) print(fsteps5, error_rate{error_rate}, success_rate{rate:.2%})运行方式python long_horizon_sandbox.py这段代码没有使用真实大模型但它完整复现了长时程任务的执行链路每个步骤读取前一步的输出经过一次模型调用后写入新的状态只要任一步返回错误整个任务就终止。3.4 运行结果与结果解读由于代码中设置了random.seed(42)运行结果具有可重复性。理论上的成功率同样可以手算如果单步错误率是 0.1单步成功率是 0.9N 步任务的总成功率约等于 0.9 的 N 次方。3 步任务理论成功率约 72.9%。5 步任务理论成功率约 59.0%。8 步任务理论成功率约 43.0%。12 步任务理论成功率约 28.2%。如果把单步错误率提高到 0.25 步任务的理论成功率约 32.8%提高到 0.3约 16.8%。这个结果说明两个问题第一即使模型单步表现已经不错任务步数一旦增加整体成功率也会显著下降。长时程任务失利不一定是“模型太笨”更可能是任务被拆得太长而每一步的误差没有得到及时拦截。第二真实系统的成功率不可能只靠 Prompt 提升。需要在每一步加入校验、重试、状态回滚和人工审批把单步错误对最终结果的影响降到最低。3.5 参数变化对成功率的影响这个沙盘里的error_rate可以理解为“模型在当前任务上的单步失败概率”。不同任务、不同 Prompt、不同工具设计下这个值差别很大。error_rate步数 5 的理论成功率步数 10 的理论成功率步数 20 的理论成功率0.0195.1%90.4%81.8%0.0577.4%59.9%35.8%0.1059.0%34.9%12.2%0.2032.8%10.7%1.2%这张表给工程实践提供了一个重要启示长时程任务的第一优先级不是让模型更聪明而是降低每一步的失败率并且控制任务步数。如果一个任务必须经过 20 步即使单步失败率只有 5%最终成功率也只有约 36%这个水平在生产环境通常不可接受。4. “幻灭低谷”对 AI 工程投入意味着什么4.1 技术成熟度曲线里的位置判断“幻灭低谷”来自技术成熟度曲线它描述一项新技术从被过度关注到回归理性、再到逐步成熟的过程。曲线大致经历五个阶段技术触发、期望膨胀顶峰、幻灭低谷、启蒙斜坡、生产力平台。过去两年AI Agent、AI 编程、AI 应用开发这些方向获得了大量关注。演示视频里Agent 可以自动写代码、自动操作浏览器、自动处理数据流水线。这些内容把市场期望推到了很高位置。但当开发者和企业真正把 Agent 接入业务系统后会发现长时程任务的稳定性不足、评估困难、维护成本高于是期望开始回调。Chamath 判断 AI 将进入幻灭低谷本质上是在说当前的能力已经被高估接下来会进入一段失望和理性调整期。这个判断是否成立需要观察具体技术方向的表现。但有一点是确定的任何新技术在经历期望膨胀后都会迎来回调回调不一定代表技术失败而是说明从业者开始用生产标准重新审视技术。4.2 学习环境与生产环境的真实差距讨论 AI 是否进入幻灭低谷需要区分学习环境和生产环境。学习环境里跑通一个 Agent Demo通常只需要满足“最终结果看起来对”这一个条件。生产环境则完全不同。生产环境至少需要额外考虑配置外置化不能把 API Key、数据库地址写在代码里。日志和监控要能回答“这个任务现在执行到哪一步、为什么停在这里”。权限和安全Agent 能访问的系统资源必须收敛到最小范围。异常处理工具调用超时、返回异常、数据格式不一致都要有明确策略。回滚方案中间步骤出错后如何恢复到一个安全状态。成本控制每一步模型调用都会产生 token 费用长任务成本会快速上升。很多项目在 Demo 阶段看起来很好但部署到生产环境后失败率飙升并不是模型能力变了而是生产环境里的异常分支远多于演示环境。所谓幻灭低谷很多时候不是 AI 退步了而是人们的评估标准从“能不能做出来”变成了“能不能稳定地做出来”。4.3 哪些任务已经落在生产力平台哪些还在低谷不同 AI 任务的成熟度差异很大。用“短反馈循环”和“长反馈循环”来区分更实用。短反馈循环任务包括单轮问答、文本摘要、代码补全、邮件润色、信息抽取。这些任务的结果可以立即被用户检查错误成本低已经在不少产品里进入生产力平台。长反馈循环任务包括跨系统数据处理、自动化代码仓库维护、长时间运行的数据迁移、自主决策类业务流。这些任务需要多步执行、状态持久化、异常恢复当前仍处于工程化早期失败率较高可以认为正处在幻灭低谷附近。任务类型反馈周期当前成熟度感受主要工程难点文本摘要、问答秒级较高幻觉、格式不稳定代码补全秒级较高上下文窗口、项目结构理解单文件代码生成分钟级中高编译错误、依赖缺失多文件代码生成小时级中低模块间接口、测试覆盖跨系统数据迁移小时到天级低状态管理、幂等、回滚自动化运维操作分钟到小时级低权限、审计、安全边界这个表并不精确但它能帮助团队判断当前不要在长反馈循环任务上给用户过高承诺而应该优先把短反馈循环任务做扎实再逐步向长任务延伸。4.4 团队应该怎样安排 AI 实验预算面对幻灭低谷的判断团队容易走两个极端。一个极端是继续追热点把所有业务都往 Agent 上装最后被失败率拖垮。另一个极端是觉得 AI 被高估停止投入错过真正能落地的地方。更现实的做法是分级投入。对短反馈循环任务可以快速试点因为这些任务验证成本低失败影响小。对长反馈循环任务先做小范围沙盘验证设定明确的成功率指标再决定是否扩大范围。对底层模型和框架选型保持抽象接口不要把业务逻辑和某一家模型绑定太深。预算安排上除了模型调用费用还要留出评估和观测系统成本。长时程任务上线后真正烧钱的地方往往不是 token而是排查失败时消耗的人力。一个没有日志、没有状态检查、没有完成度定义的任务就算模型能力很强团队也不敢放心让它自动执行。5. 提高长时程任务成功率的工程手段5.1 拆短任务把长时程变成短时程提高成功率最直接的手段是减少任务步数。把一个大任务拆成多个可以独立运行的短任务每个短任务只做一件事做完后把结果持久化再由编排系统决定下一步。例如跨系统数据迁移不要写一个 Agent 让它从头到尾自动执行全部步骤。可以拆成数据导出、格式校验、数据转换、数据导入、结果核对五个阶段。每个阶段是一个独立的短任务阶段之间有明确输入输出和校验逻辑。某个阶段失败只需要重跑该阶段不需要从头再来。这个思路的核心是“每个阶段都是可验证的”。短任务容易评估因为它的输入输出范围小成功标准清晰。多个短任务通过编排系统连接后整体仍然是一个长流程但每一步的失败范围被限制住了。5.2 结构化状态不要让 Agent 在文本里找状态Agent 执行过程中状态要放在外部而不是只放在模型上下文里。常见的做法是使用 JSON 或数据库记录状态。状态对象至少包含这些字段{ task_id: task_20250101_001, current_step: normalize, steps: [ { name: extract, status: done, output_summary: rows1000, finished_at: 2025-01-01T10:00:00Z }, { name: normalize, status: running, attempts: 2, last_error: field phone format mismatch } ], run_mode: manual_review_required }每一步开始前从状态对象里读取输入每一步结束后立即把输出摘要和校验结果写回状态。这样即使模型上下文被截断或污染编排系统仍然知道任务真实执行到了哪里。5.3 阶段门与人工审批对高风险步骤不要完全信任自动执行。阶段门是指在关键节点设置检查点由程序自动校验或由人工确认后才允许进入下一阶段。适合设置阶段门的节点包括数据写入前先预览影响行数和样例数据。代码合并前先跑测试和静态检查。邮件或消息发送前先审阅内容模板。涉及删除、覆盖、权限变更的操作前必须二次确认。人工审批会增加延迟但能显著降低不可逆错误的风险。生产环境通常采用“自动执行 关键节点人工审批”的模式而不是让 Agent 全程无监督执行。5.4 用校验模型和可观测性兜底除了执行模型还可以引入一个独立的校验步骤。校验不一定需要大模型可以用规则、Schema 校验、断言、单元测试等方式完成。例如工具返回后第一层校验检查字段是否存在、类型是否正确、数值是否在合理范围第二层校验检查业务规则比如金额大于 0、状态值是否在枚举范围内第三层校验由规则引擎或小模型完成比较当前输出和历史模式是否一致。可观测性同样重要。每个 Agent 任务都要有 trace 日志记录每一步的输入摘要、输出摘要、模型调用耗时、token 消耗、错误信息。没有这些数据长时程任务一旦失败排查就像在迷宫里找路。5.5 可复用的发布前检查清单上线一个长时程 Agent 任务前建议对照这份清单检查任务是否被拆成多个可独立验证的阶段。每个阶段是否有明确的输入输出 Schema。是否设置最大重试次数和最大执行时长。失败后是否支持从最近一个成功检查点恢复。每个工具调用是否定义了明确的成功和失败判定。关键节点是否有人工审批或自动校验。是否记录了完整的 trace 日志和 token 消耗。是否定义了可量化的完成标准。是否准备回滚方案数据误操作后能否恢复。生产环境权限是否已收敛到最小范围。如果这些项目里有多项不满足长时程任务上线后的失败率大概率会很高。这不是模型问题而是工程完整度问题。6. 常见失败模式与排查路径6.1 长时程 Agent 常见失败现象以下是生产环境中比较常见的失败现象。现象可能原因检查重点处理建议任务执行到一半中断工具调用超时、模型 API 异常查看任务 trace 和日志增加超时重试设置断点续跑Agent 反复执行同一动作缺少状态变化检测比较相邻步骤的输出和状态增加去重判断设置最大步数下一步使用了过期状态状态只存在上下文里检查状态对象是否持久化将状态外置每步结束写入存储工具返回错误但 Agent 仍继续成功判定规则不严格检查工具调用协议在框架层统一校验返回结构上下文被日志和错误信息污染每次循环拼接完整历史查看发送给模型的 token 内容只传递当前步骤所需摘要和状态任务显示完成但结果错误缺少最终结果校验检查完成标准和验收条件增加结果校验和人工抽检这些现象相互关联。一个任务可能先是上下文被污染然后 Agent 基于错误状态做决策最终导致工具调用失败。排查时要沿着执行链路逐步定位不能只看最后一行日志。6.2 通用排查链路排查长时程任务失败建议按以下顺序进行。第一步确认输入是否正确。检查任务启动时传入的初始参数、文件路径、数据库连接。很多失败的根源是输入数据本身不符合预期。第二步确认状态是否一致。查看持久化状态对象确认当前执行到第几步前一步输出是否已经落库。如果状态对象和日志不一致优先怀疑状态写入逻辑。第三步确认工具调用是否成功。查看工具请求参数、返回结果、超时和重试情况。重点关注返回结构是否和预期一致错误信息是否在下一轮循环中被正确传递。第四步确认模型收到的上下文是否合理。在调试模式下打印发送给模型的消息检查是否包含了过期状态、重复日志或错误信息。上下文结构问题往往是 Agent 行为异常的深层原因。第五步确认失败是否由重试引起。查看单步执行次数如果某一步已经重试多次仍然失败说明该步骤存在系统性错误需要人工介入而不是继续自动重试。第六步确认评估标准是否明确。如果任务“看起来完成了”但结果不正确回到任务定义层检查完成标准是否可量化、可验证。6.3 三个最容易踩的坑第一个坑是“无脑拼接完整上下文”。很多开发者为让模型记住历史把每轮工具输出都追加到 Prompt 里。结果上下文越来越长模型反而找不到关键状态。推荐做法是维护外部状态对象每次只给模型传当前步骤的输入和少量必要历史。第二个坑是“用文本判断执行结果”。工具返回 JSON 时直接让模型从文本里判断成功失败这种做法非常脆弱。模型可能因为字段位置变化、错误信息措辞不同而误判。推荐做法是在代码层面解析 JSON用结构化的status字段判断成功失败只有解析通过后才把结果交给模型。第三个坑是“没有设置执行边界”。真实模型可能出现死循环比如反复尝试同一个失败动作或者在一组相近的参数里来回切换。如果没有最大步数、最大重试次数、总执行时长上限任务会一直消耗 token直到预算耗尽。推荐做法是在框架层硬编码执行边界并由编排系统强制终止。7. 结论争议观点如何转化为技术行动Chamath 关于长时程任务和幻灭低谷的判断与其把它当成对 AI 的否定不如把它当成一次工程视角的提醒长时程任务至今没有被稳定解决行业正在从盲目乐观转向冷静验证。这对真正做工程的人是好事因为只有不再追着演示视频做产品才会有更多精力去解决状态管理、评估体系、容错机制这些基础问题。如果长时程任务一直做不好AI 的应用边界就会被限制在短反馈循环里。与其争论会不会进入幻灭低谷不如先用一个小沙盘把失败率测出来再去决定应该在哪个环节投入工程资源。下一步可以先跑通上面的实验然后把同样的指标应用到真实 Agent 任务里记录单步失败率、总成功率和失败原因分布。有了这些数据再回头看“长时程任务是不是笑话”这个问题就会得到一个比情绪判断更有价值的答案它不是不能做而是需要更严格的工程手段才能做稳。
AI Agent长时程任务成功率为何下降？工程拆解与沙盘实验
最近关于 AI 行业阶段的一个判断引发了不少讨论Chamath 认为长时程任务仍然是笑话AI 即将进入幻灭低谷。这个判断听起来刺耳但放到实际工程里并不全是情绪发泄。过去一年里AI Agent 的演示视频确实惊艳但真正把 Agent 放到生产环境处理多步骤任务的人大概率都遇到过任务跑一半就停、错误不断累积、上下文被污染的情况。长时程任务不是“把 Prompt 写长一点”就能解决的它涉及模型能力、状态管理、工具调用、评估体系和容错机制等多个层面的工程问题。本文从工程视角拆解这个观点。先说明长时程任务到底是什么再分析它为什么容易失败然后提供一个不依赖外部大模型 API 的最小沙盘实验用来复现“任务步骤变多后成功率下降”的过程。最后讨论幻灭低谷对 AI 工程投入节奏的影响以及团队和个人开发者可以从哪些方向提高长时程任务的成功率。1. 先理解“长时程任务”在 AI 工程里到底指什么1.1 从单轮问答到多步执行AI 能力维度的变化传统的大模型应用形态是单轮问答用户输入问题模型输出答案。这个过程的反馈循环很短输入和输出在同一个会话里完成即使模型说错用户也能立刻发现并重新提问。长时程任务不同。它要求模型在多个步骤之间保持目标一致持续操作外部系统并且在中间结果不符合预期时自行调整。典型场景包括从数据库读取数据经过清洗、转换、去重后再写入目标表。根据需求文档生成代码编译、运行测试、修复报错、再次运行。自动化处理一批工单每张工单需要查询信息、调用接口、确认结果、记录日志。把一个跨系统的数据迁移任务拆成多个阶段每个阶段都要校验上一阶段的输出。这些任务的共同点是模型不能只生成一段文本它必须在一个闭环里完成“理解状态、决定动作、观察结果、修正下一步”的循环。这个循环每多转一圈系统的不确定性就会增加一分。1.2 长时程任务的三个典型技术特征判断一个任务是不是长时程任务可以看三个特征。第一步骤数量多。任务被拆成多个子步骤子步骤之间存在依赖关系后一步要依赖前一步的输出。步骤越多链条越长。第二外部反馈延迟。模型调用工具后结果不会立刻变成可用的最终答案需要解析返回值、判断是否成功、决定是继续还是重试。这个反馈过程可能涉及网络请求、文件读写、数据库事务甚至需要等待人工审批。第三状态需要持久化。Agent 在执行过程中不能只靠模型上下文记住“做到哪一步”因为上下文会溢出也会被中间日志污染。状态必须存放在可查询、可回滚的结构化位置。如果某个任务只是“写一封邮件草稿”它仍然是短时程任务。如果这个任务是“把 200 个客户按规则分层生成个性化邮件发送前经过审批发送后记录送达状态”它就已经进入了长时程任务范畴。1.3 为什么演示视频会高估 Agent 的能力演示视频通常经过精心剪辑。视频里的 Agent 可能只跑了一次成功路径没有展示失败重试、上下文污染、工具返回异常和人工介入的过程。观众看到的是“点一下按钮任务自动完成”但工程上真正难的是那些没有出现在视频里的分支情况。这种现象并不只在 AI 领域存在任何自动化系统在演示时都会选择最优路径。但大模型 Agent 有一个特殊问题它的每一步输出都是概率性的即使同样的输入、同样的 Prompt两次运行也可能得到不同结果。演示视频只能证明“这个任务在某种条件下可以完成”不能证明“这个任务在生产环境里可以稳定完成”。所以“长时程任务仍是笑话”这个观点核心指向的是稳定性问题。不是模型不能写代码、不能调工具而是多步执行下的成功率还没有达到生产可用的标准。2. 为什么长时程任务容易失败五个核心瓶颈2.1 误差累积小错误到最后被放大长时程任务最直观的失败原因是误差累积。模型每一步都有一定概率犯错可能是理解错了输入可能是生成了错误的工具参数也可能是把中间结果写错了位置。单步错误率看着不高但只要任务步骤足够多整条链路的成功率就会快速下降。假设每一步的成功率是 95%5 步任务的总成功率是 0.95 的 5 次方约 77%。如果任务有 20 步总成功率降到约 36%。如果每步成功率只有 90%20 步任务的总成功率只有约 12%。这个指数关系是数学层面的和模型聪明不聪明没有直接关系。这也是为什么很多 Agent 在 2 到 3 步的演示里表现良好一旦进入真实业务场景几十个步骤连环执行失败率就变得不可接受。2.2 上下文窗口不等于决策容量大模型的上下文窗口越来越长但长上下文不意味着模型能有效利用所有信息。任务执行过程中每一步的工具返回、日志、错误信息都要拼进上下文。随着上下文变长模型需要从大量文本里定位关键状态注意力分散出错概率反而上升。更麻烦的是上下文里既包含事实状态也包含推理过程、错误信息、历史动作。模型很难区分“哪一段是最新的真实状态”和“哪一段只是我之前的猜测”。一旦模型基于过期状态做决策后续步骤就会建立在错误地基上。上下文窗口解决的是“能不能容纳”的问题工程上还需要解决“该把什么放进去”的问题。长时程任务里正确做法不是把所有历史都塞给模型而是只把当前步骤需要的结构化状态和少量必要上下文传给模型。2.3 工具调用和状态管理没有统一契约Agent 要完成长时程任务几乎必须调用外部工具查数据库、写文件、调接口、执行命令。每个工具都有自己的参数格式、返回结构和错误语义。Agent 框架如果只是把工具描述拼进 Prompt让模型“自由发挥”很容易出现参数缺漏、类型错误、返回解析失败。例如一个工具返回 JSON正常情况包含status字段失败情况可能返回error字段。模型如果只用status判断成功就可能把失败请求当成成功。工具调用层需要一个统一协议明确什么算成功、什么算失败、失败后应该重试还是终止。状态管理同样是关键。如果每一步的中间结果只是字符串拼接下一步就很难判断前一步是否真的完成。结构化状态应该包含步骤编号、输入快照、输出快照、校验结果、执行时间、重试次数等字段让 Agent 和运维人员都能看清当前进度。2.4 自我修正机制本质上是概率性的很多 Agent 框架宣称具备自我修正能力模型发现错误后读取错误信息重新规划再次尝试。这个机制听起来很合理但实际执行时存在两个问题。第一模型不一定能正确识别错误。有时工具已经返回了明确异常模型仍然按照原计划继续执行把异常信息忽略掉。第二重新尝试可能产生新的错误。模型可能修正了参数格式却又在下一步选择错误分支。自我修正在短路径上有效在长路径上会变成新的不确定性来源。工程上不能把“自我修正”当作默认能力。更稳妥的做法是给 Agent 设置最大重试次数每步执行后强校验输出校验失败就进入预设的修复流程而不是让模型自由发挥。2.5 任务完成度的评估本身很困难短时程任务容易评估答案是 A 还是 B一眼就能判断。长时程任务不同任务的最终结果可能是“数据已迁移”“代码已部署”“工单已处理”但“处理完成”的标准很难形式化。比如“把 200 个客户分层并发送邮件”成功的标准是什么是接口全部返回 200还是每一封邮件都被客户打开显然不能混为一谈。没有明确的完成标准Agent 就无法判断自己是否已经完成也就无法决定何时停止。很多 Agent 任务失败不是模型能力不足而是目标定义不清楚系统在错误的方向上反复执行。3. 用最小沙盘实验复现“长时程任务翻车”3.1 实验目标不依赖外部大模型也能看到失败率曲线为了验证“步骤越多成功率越低”这个判断我们构建一个最小沙盘实验。它不调用任何外部大模型 API也不依赖网络只用一个模拟模型来模拟每一步可能出现的执行错误。这个实验的价值有两个。第一它把长时程任务的失败原因压缩成最核心的“单步错误率”和“任务步数”两个变量方便观察趋势。第二它可以作为真实 Agent 系统的简化模型后续可以替换成真实模型和真实工具复用同样的成功率和排查思路。3.2 项目结构与核心类设计项目只需要一个 Python 文件包含四个核心对象Step描述一个子步骤包括步骤名、输入键、输出键。RandomModel模拟不稳定的大模型以固定概率返回错误。Task按顺序执行步骤列表更新状态记录执行轨迹。simulate多次运行任务计算成功率。这种设计与真实 Agent 框架的抽象方向一致真实框架里的Agent相当于TaskLLM相当于RandomModel外部工具相当于步骤里的输入输出映射。区别只是真实模型的错误率不是均匀分布而是与任务难度、Prompt 质量、工具设计相关。3.3 完整可运行代码下面是完整的沙盘实验代码保存为long_horizon_sandbox.py。# long_horizon_sandbox.py import random from dataclasses import dataclass from typing import Dict, List, Tuple dataclass class Step: name: str input_keys: List[str] output_key: str class RandomModel: 模拟不稳定的大模型以固定概率产生错误。 def __init__(self, error_rate: float 0.2): self.error_rate error_rate def complete(self, step_name: str, input_data: dict) - dict: if random.random() self.error_rate: return { status: error, message: fmodel failed at {step_name}, } return { status: ok, data: {value: input_data.get(value, 0) 1}, } class Task: def __init__(self, steps: List[Step]): self.steps steps def run( self, model: RandomModel, initial_state: dict ) - Tuple[bool, dict, List[str]]: state dict(initial_state) trace [] for step in self.steps: input_data {k: state.get(k) for k in step.input_keys} output model.complete(step.name, input_data) trace.append(f{step.name}: {output}) if output[status] ! ok: return False, state, trace state[step.output_key] output[data] return True, state, trace def build_n_step_task(n: int) - Task: steps [] for i in range(1, n 1): input_key state_0 if i 1 else fstate_{i - 1} steps.append( Step( namefstep_{i}, input_keys[input_key], output_keyfstate_{i}, ) ) return Task(steps) def simulate(task: Task, model: RandomModel, trials: int 1000) - float: success 0 for _ in range(trials): ok, _, _ task.run(model, {state_0: {value: 1}}) if ok: success 1 return success / trials if __name__ __main__: random.seed(42) for step_count in [3, 5, 8, 12]: task build_n_step_task(step_count) model RandomModel(error_rate0.1) rate simulate(task, model) print(fsteps{step_count}, error_rate0.1, success_rate{rate:.2%}) for error_rate in [0.0, 0.1, 0.2, 0.3]: task build_n_step_task(5) model RandomModel(error_rateerror_rate) rate simulate(task, model) print(fsteps5, error_rate{error_rate}, success_rate{rate:.2%})运行方式python long_horizon_sandbox.py这段代码没有使用真实大模型但它完整复现了长时程任务的执行链路每个步骤读取前一步的输出经过一次模型调用后写入新的状态只要任一步返回错误整个任务就终止。3.4 运行结果与结果解读由于代码中设置了random.seed(42)运行结果具有可重复性。理论上的成功率同样可以手算如果单步错误率是 0.1单步成功率是 0.9N 步任务的总成功率约等于 0.9 的 N 次方。3 步任务理论成功率约 72.9%。5 步任务理论成功率约 59.0%。8 步任务理论成功率约 43.0%。12 步任务理论成功率约 28.2%。如果把单步错误率提高到 0.25 步任务的理论成功率约 32.8%提高到 0.3约 16.8%。这个结果说明两个问题第一即使模型单步表现已经不错任务步数一旦增加整体成功率也会显著下降。长时程任务失利不一定是“模型太笨”更可能是任务被拆得太长而每一步的误差没有得到及时拦截。第二真实系统的成功率不可能只靠 Prompt 提升。需要在每一步加入校验、重试、状态回滚和人工审批把单步错误对最终结果的影响降到最低。3.5 参数变化对成功率的影响这个沙盘里的error_rate可以理解为“模型在当前任务上的单步失败概率”。不同任务、不同 Prompt、不同工具设计下这个值差别很大。error_rate步数 5 的理论成功率步数 10 的理论成功率步数 20 的理论成功率0.0195.1%90.4%81.8%0.0577.4%59.9%35.8%0.1059.0%34.9%12.2%0.2032.8%10.7%1.2%这张表给工程实践提供了一个重要启示长时程任务的第一优先级不是让模型更聪明而是降低每一步的失败率并且控制任务步数。如果一个任务必须经过 20 步即使单步失败率只有 5%最终成功率也只有约 36%这个水平在生产环境通常不可接受。4. “幻灭低谷”对 AI 工程投入意味着什么4.1 技术成熟度曲线里的位置判断“幻灭低谷”来自技术成熟度曲线它描述一项新技术从被过度关注到回归理性、再到逐步成熟的过程。曲线大致经历五个阶段技术触发、期望膨胀顶峰、幻灭低谷、启蒙斜坡、生产力平台。过去两年AI Agent、AI 编程、AI 应用开发这些方向获得了大量关注。演示视频里Agent 可以自动写代码、自动操作浏览器、自动处理数据流水线。这些内容把市场期望推到了很高位置。但当开发者和企业真正把 Agent 接入业务系统后会发现长时程任务的稳定性不足、评估困难、维护成本高于是期望开始回调。Chamath 判断 AI 将进入幻灭低谷本质上是在说当前的能力已经被高估接下来会进入一段失望和理性调整期。这个判断是否成立需要观察具体技术方向的表现。但有一点是确定的任何新技术在经历期望膨胀后都会迎来回调回调不一定代表技术失败而是说明从业者开始用生产标准重新审视技术。4.2 学习环境与生产环境的真实差距讨论 AI 是否进入幻灭低谷需要区分学习环境和生产环境。学习环境里跑通一个 Agent Demo通常只需要满足“最终结果看起来对”这一个条件。生产环境则完全不同。生产环境至少需要额外考虑配置外置化不能把 API Key、数据库地址写在代码里。日志和监控要能回答“这个任务现在执行到哪一步、为什么停在这里”。权限和安全Agent 能访问的系统资源必须收敛到最小范围。异常处理工具调用超时、返回异常、数据格式不一致都要有明确策略。回滚方案中间步骤出错后如何恢复到一个安全状态。成本控制每一步模型调用都会产生 token 费用长任务成本会快速上升。很多项目在 Demo 阶段看起来很好但部署到生产环境后失败率飙升并不是模型能力变了而是生产环境里的异常分支远多于演示环境。所谓幻灭低谷很多时候不是 AI 退步了而是人们的评估标准从“能不能做出来”变成了“能不能稳定地做出来”。4.3 哪些任务已经落在生产力平台哪些还在低谷不同 AI 任务的成熟度差异很大。用“短反馈循环”和“长反馈循环”来区分更实用。短反馈循环任务包括单轮问答、文本摘要、代码补全、邮件润色、信息抽取。这些任务的结果可以立即被用户检查错误成本低已经在不少产品里进入生产力平台。长反馈循环任务包括跨系统数据处理、自动化代码仓库维护、长时间运行的数据迁移、自主决策类业务流。这些任务需要多步执行、状态持久化、异常恢复当前仍处于工程化早期失败率较高可以认为正处在幻灭低谷附近。任务类型反馈周期当前成熟度感受主要工程难点文本摘要、问答秒级较高幻觉、格式不稳定代码补全秒级较高上下文窗口、项目结构理解单文件代码生成分钟级中高编译错误、依赖缺失多文件代码生成小时级中低模块间接口、测试覆盖跨系统数据迁移小时到天级低状态管理、幂等、回滚自动化运维操作分钟到小时级低权限、审计、安全边界这个表并不精确但它能帮助团队判断当前不要在长反馈循环任务上给用户过高承诺而应该优先把短反馈循环任务做扎实再逐步向长任务延伸。4.4 团队应该怎样安排 AI 实验预算面对幻灭低谷的判断团队容易走两个极端。一个极端是继续追热点把所有业务都往 Agent 上装最后被失败率拖垮。另一个极端是觉得 AI 被高估停止投入错过真正能落地的地方。更现实的做法是分级投入。对短反馈循环任务可以快速试点因为这些任务验证成本低失败影响小。对长反馈循环任务先做小范围沙盘验证设定明确的成功率指标再决定是否扩大范围。对底层模型和框架选型保持抽象接口不要把业务逻辑和某一家模型绑定太深。预算安排上除了模型调用费用还要留出评估和观测系统成本。长时程任务上线后真正烧钱的地方往往不是 token而是排查失败时消耗的人力。一个没有日志、没有状态检查、没有完成度定义的任务就算模型能力很强团队也不敢放心让它自动执行。5. 提高长时程任务成功率的工程手段5.1 拆短任务把长时程变成短时程提高成功率最直接的手段是减少任务步数。把一个大任务拆成多个可以独立运行的短任务每个短任务只做一件事做完后把结果持久化再由编排系统决定下一步。例如跨系统数据迁移不要写一个 Agent 让它从头到尾自动执行全部步骤。可以拆成数据导出、格式校验、数据转换、数据导入、结果核对五个阶段。每个阶段是一个独立的短任务阶段之间有明确输入输出和校验逻辑。某个阶段失败只需要重跑该阶段不需要从头再来。这个思路的核心是“每个阶段都是可验证的”。短任务容易评估因为它的输入输出范围小成功标准清晰。多个短任务通过编排系统连接后整体仍然是一个长流程但每一步的失败范围被限制住了。5.2 结构化状态不要让 Agent 在文本里找状态Agent 执行过程中状态要放在外部而不是只放在模型上下文里。常见的做法是使用 JSON 或数据库记录状态。状态对象至少包含这些字段{ task_id: task_20250101_001, current_step: normalize, steps: [ { name: extract, status: done, output_summary: rows1000, finished_at: 2025-01-01T10:00:00Z }, { name: normalize, status: running, attempts: 2, last_error: field phone format mismatch } ], run_mode: manual_review_required }每一步开始前从状态对象里读取输入每一步结束后立即把输出摘要和校验结果写回状态。这样即使模型上下文被截断或污染编排系统仍然知道任务真实执行到了哪里。5.3 阶段门与人工审批对高风险步骤不要完全信任自动执行。阶段门是指在关键节点设置检查点由程序自动校验或由人工确认后才允许进入下一阶段。适合设置阶段门的节点包括数据写入前先预览影响行数和样例数据。代码合并前先跑测试和静态检查。邮件或消息发送前先审阅内容模板。涉及删除、覆盖、权限变更的操作前必须二次确认。人工审批会增加延迟但能显著降低不可逆错误的风险。生产环境通常采用“自动执行 关键节点人工审批”的模式而不是让 Agent 全程无监督执行。5.4 用校验模型和可观测性兜底除了执行模型还可以引入一个独立的校验步骤。校验不一定需要大模型可以用规则、Schema 校验、断言、单元测试等方式完成。例如工具返回后第一层校验检查字段是否存在、类型是否正确、数值是否在合理范围第二层校验检查业务规则比如金额大于 0、状态值是否在枚举范围内第三层校验由规则引擎或小模型完成比较当前输出和历史模式是否一致。可观测性同样重要。每个 Agent 任务都要有 trace 日志记录每一步的输入摘要、输出摘要、模型调用耗时、token 消耗、错误信息。没有这些数据长时程任务一旦失败排查就像在迷宫里找路。5.5 可复用的发布前检查清单上线一个长时程 Agent 任务前建议对照这份清单检查任务是否被拆成多个可独立验证的阶段。每个阶段是否有明确的输入输出 Schema。是否设置最大重试次数和最大执行时长。失败后是否支持从最近一个成功检查点恢复。每个工具调用是否定义了明确的成功和失败判定。关键节点是否有人工审批或自动校验。是否记录了完整的 trace 日志和 token 消耗。是否定义了可量化的完成标准。是否准备回滚方案数据误操作后能否恢复。生产环境权限是否已收敛到最小范围。如果这些项目里有多项不满足长时程任务上线后的失败率大概率会很高。这不是模型问题而是工程完整度问题。6. 常见失败模式与排查路径6.1 长时程 Agent 常见失败现象以下是生产环境中比较常见的失败现象。现象可能原因检查重点处理建议任务执行到一半中断工具调用超时、模型 API 异常查看任务 trace 和日志增加超时重试设置断点续跑Agent 反复执行同一动作缺少状态变化检测比较相邻步骤的输出和状态增加去重判断设置最大步数下一步使用了过期状态状态只存在上下文里检查状态对象是否持久化将状态外置每步结束写入存储工具返回错误但 Agent 仍继续成功判定规则不严格检查工具调用协议在框架层统一校验返回结构上下文被日志和错误信息污染每次循环拼接完整历史查看发送给模型的 token 内容只传递当前步骤所需摘要和状态任务显示完成但结果错误缺少最终结果校验检查完成标准和验收条件增加结果校验和人工抽检这些现象相互关联。一个任务可能先是上下文被污染然后 Agent 基于错误状态做决策最终导致工具调用失败。排查时要沿着执行链路逐步定位不能只看最后一行日志。6.2 通用排查链路排查长时程任务失败建议按以下顺序进行。第一步确认输入是否正确。检查任务启动时传入的初始参数、文件路径、数据库连接。很多失败的根源是输入数据本身不符合预期。第二步确认状态是否一致。查看持久化状态对象确认当前执行到第几步前一步输出是否已经落库。如果状态对象和日志不一致优先怀疑状态写入逻辑。第三步确认工具调用是否成功。查看工具请求参数、返回结果、超时和重试情况。重点关注返回结构是否和预期一致错误信息是否在下一轮循环中被正确传递。第四步确认模型收到的上下文是否合理。在调试模式下打印发送给模型的消息检查是否包含了过期状态、重复日志或错误信息。上下文结构问题往往是 Agent 行为异常的深层原因。第五步确认失败是否由重试引起。查看单步执行次数如果某一步已经重试多次仍然失败说明该步骤存在系统性错误需要人工介入而不是继续自动重试。第六步确认评估标准是否明确。如果任务“看起来完成了”但结果不正确回到任务定义层检查完成标准是否可量化、可验证。6.3 三个最容易踩的坑第一个坑是“无脑拼接完整上下文”。很多开发者为让模型记住历史把每轮工具输出都追加到 Prompt 里。结果上下文越来越长模型反而找不到关键状态。推荐做法是维护外部状态对象每次只给模型传当前步骤的输入和少量必要历史。第二个坑是“用文本判断执行结果”。工具返回 JSON 时直接让模型从文本里判断成功失败这种做法非常脆弱。模型可能因为字段位置变化、错误信息措辞不同而误判。推荐做法是在代码层面解析 JSON用结构化的status字段判断成功失败只有解析通过后才把结果交给模型。第三个坑是“没有设置执行边界”。真实模型可能出现死循环比如反复尝试同一个失败动作或者在一组相近的参数里来回切换。如果没有最大步数、最大重试次数、总执行时长上限任务会一直消耗 token直到预算耗尽。推荐做法是在框架层硬编码执行边界并由编排系统强制终止。7. 结论争议观点如何转化为技术行动Chamath 关于长时程任务和幻灭低谷的判断与其把它当成对 AI 的否定不如把它当成一次工程视角的提醒长时程任务至今没有被稳定解决行业正在从盲目乐观转向冷静验证。这对真正做工程的人是好事因为只有不再追着演示视频做产品才会有更多精力去解决状态管理、评估体系、容错机制这些基础问题。如果长时程任务一直做不好AI 的应用边界就会被限制在短反馈循环里。与其争论会不会进入幻灭低谷不如先用一个小沙盘把失败率测出来再去决定应该在哪个环节投入工程资源。下一步可以先跑通上面的实验然后把同样的指标应用到真实 Agent 任务里记录单步失败率、总成功率和失败原因分布。有了这些数据再回头看“长时程任务是不是笑话”这个问题就会得到一个比情绪判断更有价值的答案它不是不能做而是需要更严格的工程手段才能做稳。
