如果你正在做一个 AI Agent 产品一定遇到过这样的局面对话里的模型表现得像个聪明助手可一旦让它自己搞定一件需要连续操作 20 步、跨越多个工具、持续好几分钟的完整任务结果往往惨不忍睹。它会忘记开头定的目标会在第三步重复第一步的操作会在第 15 步突然生成一段和上下文毫无关系的输出更常见的是——在某次工具调用返回一个意外格式后整个任务直接崩溃。硅谷知名投资人 Chamath Palihapitiya 近期对 AI 的一番评价把这种落差推到了台前。他的核心观点很尖锐长时程任务Long-Horizon Tasks仍然是 AI 的明显短板行业将进入幻灭低谷期。话虽然难听但如果你亲自跑过一个稍微复杂一点的 Agent 流程大概率会承认他说的有相当一部分是事实。这篇文章不打算跟着情绪走。我想做的是拆开这件事为什么长时程任务这么难当前技术瓶颈到底卡在哪一层所谓幻灭低谷对开发者究竟意味着什么更重要的是工程师现在能做什么才能让自己手里的 AI 项目不在低谷期被淘汰看完本文你会得到一套可执行的判断框架以及一个带状态机、检查点、结构化日志的长任务最小代码示例可以直接拿去调整自己的 Agent 架构。1. 这篇文章真正要解决的问题围绕 Chamath 评论的讨论很容易滑向两个极端。一派认为这是他不懂技术的偏见另一派则借此唱衰整个 AI 行业。但这两派都没说中要害。真正的要害在于长时程任务不是一个再迭代几版模型就能解决的问题它是一个工程问题、架构问题、系统设计问题。模型能力只是其中一环甚至不是最核心的一环。想想看我们评价 ChatGPT、Claude、文心一言这类产品时体验最好的场景是什么是一问一答——用户提问模型回答用户再追问。这类短交互里模型只需关注当前上下文不需要长时间记住中间状态也不需要跨系统协调资源。模型在这类任务上确实已经非常强。但真实业务不是这样运作的。一个数据分析师的工作流可能是登录数据平台 → 拉取三张表 → 写 SQL 清洗 → 跑统计模型 → 生成图表 → 写解读 → 发邮件给业务方。这七步需要七个工具、六次状态转换、多次结果校验中间任何一步出错都可能需要回退重来。当前大多数 AI Agent 产品恰恰在最需要稳定性的地方暴露出弱点。所以本文要解决的不只是Chamath 说得对不对而是三个更实际的问题长时程任务失败的根本原因是什么哪些原因在模型层哪些在架构层。幻灭低谷期里什么样的 AI 项目会被淘汰什么样的会留下来。作为开发者现在可以用什么工程手段让已有的 Agent 项目先活下来、再变强。如果你正在做 AI Agent 开发、正在为企业选型 AI 自动化工具或者你只是好奇AI 到底能不能真的自主干活这篇文章都值得读完。2. Chamath 的核心判断与长时程任务的定义2.1 一句话概括 Chamath 的批评Chamath 的批评并不是AI 没用而是更具体的判断AI 在短时程、高容错的场景里已经够用但在需要长时间自主规划、连续决策、跨工具协作的任务上仍然不像样。他据此推断市场对 AI 能力的预期已经透支接下来会进入一段失望期——也就是幻灭低谷。这个判断的关键词是长时程任务。要理解他的批评到底有没有道理先得把这个词说清楚。2.2 什么是长时程任务学术界和工程界对 Long-Horizon Tasks 的界定不完全统一但核心特征是一致的任务需要多步决策单次决策片段无法完成任务必须依赖跨越长时间跨度的规划、执行、记忆和纠错能力。举几个典型例子让 Agent 自己完成一个跨系统的数据迁移包括风险评估、执行迁移、验证数据一致性、回滚预案。让 Agent 根据业务需求自主编写并运行一组测试根据失败结果反复修复代码最终提交一个可合入的 MR。让 Agent 管理一个长期项目拆解需求、分配任务、跟进进度、处理阻塞、输出周报。这些任务的共同点是步骤多、耗时长、存在不确定性、需要记忆中间结果、必须能从失败中恢复。2.3 为什么短任务的成功掩盖了长任务的失败目前市面上很多 AI 产品 Demo 展示的其实是短时程任务单点工具调用的缝合体。用户看演示时觉得太强了真正投入生产后却发现完全不是那么回事。维度短时程任务Single-Turn长时程任务Long-Horizon决策次数1 到 3 次10 次以上上下文依赖依赖当前单轮输入依赖历史多轮状态错误容忍度高错了用户可以重问低一步错可能带偏全局工具调用少单个工具多工具、多系统、跨接口恢复能力不需要必须支持断点续跑评测方式看回答质量看任务完成率和成功率产品价值提效助手自动化执行体现在的尴尬在于短时程任务的成功率已经达到产品化门槛所以大量产品急着拿它当卖点可一旦用户把它当长时程任务用立刻露馅。Chamath 说的笑话本质上不是模型笨而是产品承诺的能力和实际架构能支撑的能力之间出现了巨大裂缝。3. 长时程任务失败的四个技术真相为什么长时程任务这么难拆开看至少有四个层面的原因层层叠加最终导致任务崩盘。3.1 错误累积一步错步步错这是最本质的原因。假设模型单步操作的成功率是 95%听起来很高。但如果一个任务需要连续执行 20 步且中间没有任何校验和纠错机制那么理论上的全流程成功率是0.95^20 ≈ 0.358也就是说即使每一步都做到 95% 的准确率20 步之后整体成功率也只有三成多。这还没算工具调用本身可能出现的超时、限流、返回格式异常。如果单步成功率降到 90%20 步下来成功率只剩约 12%。ChatGPT 这类对话产品为什么感觉可靠因为用户随时在纠错——你看到它说错了重新问一句就行。但长时程任务里模型没有人肉纠错器错误会像滚雪球一样累积。3.2 上下文漂移模型会忘事长时程任务意味着长时间运行长时间运行意味着上下文不断增长。但模型处理上下文的能力是有限的。不是说上下文窗口不够长——现在的模型动辄支持 100k、200k 甚至更长的上下文。问题是上下文越长模型对早期信息的注意力就越容易被冲淡。尤其是执行到第 15 步时第 1 步的目标描述、约束条件、用户偏好可能已经被中间的工具返回结果淹没。这就是经典的上下文漂移现象。模型不是不想遵守初始指令而是它在大量中间信息的干扰下记不清初始指令的优先级了。就像一个人同时做五件事做到第三件时忘了第一件的验收标准是什么。3.3 工具调用的不确定性链路越长越脆弱Agent 的每一次工具调用都像一个外部系统的请求可能超时、可能限流、可能返回格式变化、可能权限不足、可能网络抖动。短时程任务里用户看到失败可以立刻重试或换一种方式长时程任务里一次工具调用的失败可能让整个 Agent 陷入重试—失败—再重试—更混乱的循环。更麻烦的是工具返回结果往往是半结构化的。Agent 需要从一段夹杂日志、JSON、表格、文字的混合输出中提取关键信息。一旦提取失误后续所有决策都建立在错误信息上。3.4 状态管理缺失没有检查点就没有恢复能力这是最容易被忽视、但工程上最致命的一点。当前大量 Agent 框架的设计是对话式的——把每一个中间结果都塞进消息列表把上下文当状态用。这带来的结果是一旦某个环节出错Agent 只能从头开始整个任务或者从当前时刻盲目重试无法回到上一个稳定检查点。真正的长时程任务系统必须有显式的状态管理哪个步骤完成了、哪个步骤失败了、中间产物存在哪里、失败后应该回退到哪个节点。这些状态不应该只存在于模型的上下文中而应该存在于持久化的存储里。4. 幻灭低谷对工程师意味着什么4.1 Gartner 曲线与幻灭低谷幻灭低谷Trough of Disillusionment来自 Gartner 技术成熟度曲线。一个新技术往往会经历五个阶段技术触发、期望膨胀顶峰、幻灭低谷、启蒙爬坡、生产力平台期。AI 在过去两年显然走过了前两个阶段。ChatGPT 引爆全球大模型融资额节节攀升几乎所有软件都想加上AI 能力。而今天当长时程任务这类真实工程难题暴露出来当企业发现AI 自动化落地困难行业的情绪温度开始下降。这很正常甚至是健康的。4.2 资本叙事与工程现实的错位Chamath 的判断之所以有市场是因为他精准戳中了一个错位资本需要讲增长故事故事需要 AI 无所不能而工程需要面对真实约束约束让 AI 只能在特定场景先落地。错位最集中的体现就是AI 自主完成任务这个叙事。Demo 里Agent 可以完美规划、执行、交付生产环境里Agent 会卡在权限审批、数据权限、工具返回格式、异常分支处理上。这不是模型没有进步而是从模型能理解任务到系统能可靠完成任务之间隔着巨大的工程鸿沟。大部分产品团队还没填完这道鸿沟资本市场却已经按照填完之后的估值在定价了。4.3 低谷期是工程红利期换个角度看幻灭低谷恰恰是工程师最好的入场窗口。泡沫期里随便讲个 AI 故事就能拿到资源但真正做事的人往往被噪音淹没。低谷期里喧嚣退去留下来的需求都是真实需求能存活的产品必须真正解决问题。AI 能力会继续提升但可靠地把它嵌入业务系统的能力才是穿越周期的竞争力。所以不要被幻灭低谷吓到。更准确的说法是模型的泡沫正在破裂工程的价值正在回归。5. 长时程任务引擎的最小实现讨论完原理接下来给一个可以落地的参考实现。这个例子刻意保持最小化但包含了长时程任务系统最核心的三个基础设施状态机、检查点、任务计划描述。5.1 任务状态机长任务的第一块地基长时程任务系统不能把流程状态隐式地放在模型上下文里。你必须显式地建模每个任务节点的状态。# 文件路径examples/task_state.py from enum import Enum from dataclasses import dataclass, field from typing import Any class TaskStatus(Enum): PENDING pending RUNNING running WAITING_TOOL waiting_tool CHECKPOINT checkpoint SUCCEEDED succeeded FAILED failed CANCELLED cancelled dataclass class TaskNode: node_id: str name: str status: TaskStatus TaskStatus.PENDING attempts: int 0 max_attempts: int 3 checkpoint: dict field(default_factorydict) result: Any None error: str def can_retry(self) - bool: return self.attempts self.max_attempts def mark_success(self, result: Any) - None: self.result result self.status TaskStatus.SUCCEEDED def mark_failure(self, error: str) - None: self.error error self.status TaskStatus.FAILED这个类做的事情很简单每一个任务节点都记录自己的状态、尝试次数、检查点数据和错误信息。max_attempts限制了重试次数can_retry()决定是否允许再次执行。状态机是整个长时程任务系统的骨架没有它任务一旦失败就是失控。5.2 检查点机制让长任务可断点续传状态机只是第一步更重要的是把状态持久化到磁盘或数据库。这样即使进程崩溃、网络中断、模型超时任务也可以从最近一个成功的检查点继续执行而不是从头再来。# 文件路径examples/checkpoint_runner.py import json import time from pathlib import Path from task_state import TaskNode, TaskStatus class CheckpointRunner: def __init__(self, plan: list, checkpoint_dir: str ./checkpoints): self.plan [TaskNode(**item) for item in plan] self.checkpoint_dir Path(checkpoint_dir) self.checkpoint_dir.mkdir(parentsTrue, exist_okTrue) def execute(self): for node in self.plan: if node.status TaskStatus.SUCCEEDED: continue while node.can_retry(): node.status TaskStatus.RUNNING try: # 这里替换为真实的模型调用、工具调用或子任务执行 node.result self._run_step(node) node.mark_success(node.result) self._save_checkpoint(node) break except Exception as exc: node.attempts 1 node.mark_failure(str(exc)) self._save_checkpoint(node) else: raise RuntimeError( f节点 {node.node_id} 最终失败: {node.error} ) return self.plan def _run_step(self, node: TaskNode): # 示例实际项目里这一步会调用大模型 API 或工具 API return {step: node.node_id, time: time.time()} def _save_checkpoint(self, node: TaskNode): path self.checkpoint_dir / f{node.node_id}.json payload { node_id: node.node_id, status: node.status.value, attempts: node.attempts, error: node.error, checkpoint: node.checkpoint, result: node.result, } path.write_text( json.dumps(payload, ensure_asciiFalse, indent2) )这里的_run_step()是留给你接真实逻辑的地方。接入模型 API 时把工具调用的中间产物也放进node.checkpoint这样即使下一步失败你也能定位到具体是哪一步、哪个中间数据出了问题。5.3 用 YAML 描述任务计划长时程任务还有一个被低估的问题任务计划可读性差。把任务节点直接写死在代码里不利于业务方 review也不利于流程变更。工程上推荐用声明式配置来描述任务计划。# 文件路径examples/task_plan.yaml workflow: data_analysis_report description: 从数据源拉取数据、清洗、生成摘要报告 tasks: - node_id: fetch_data name: 拉取原始数据 max_attempts: 3 checkpoint: type: raw_data - node_id: clean_data name: 数据清洗 max_attempts: 2 depends_on: fetch_data - node_id: summarize name: 生成摘要报告 max_attempts: 2 depends_on: clean_data - node_id: validate name: 校验报告质量 max_attempts: 1 depends_on: summarizeYAML 的好处是业务人员能看懂流程开发人员能快速调整参数版本管理工具可以清晰追踪任务计划的变更历史。把流程和代码解耦是长时程任务从实验室 Demo走向生产系统的关键一步。5.4 结构化日志让每一步可审计长时程任务运行时间长、步骤多如果没有结构化日志出问题后你根本不知道是哪一步先出错、错误是什么、当时的上下文是什么。这里强烈建议为任务执行设计独立的日志格式。# 文件路径examples/structured_log.py import json import logging class TaskLogger: def __init__(self, logger_name: str agent_task): self.logger logging.getLogger(logger_name) self.logger.setLevel(logging.INFO) def log_step(self, node_id: str, event: str, extra: dict | None None): record { node_id: node_id, event: event, extra: extra or {}, } self.logger.info(json.dumps(record, ensure_asciiFalse)) def log_metric(self, name: str, value: float): record {metric: name, value: value} self.logger.info(json.dumps(record, ensure_asciiFalse))每完成一步记录一个node_id和事件每次调用工具记录耗时和返回状态每次失败记录错误类型和重试次数。这些日志是后续做评测、报警、根因分析的基础数据。6. 从演示到生产三个关键工程改造上面的最小实现能帮你跑通一个带检查点的长任务流程。但要真正用于生产至少还要做三件事。6.1 状态持久化从内存任务到数据库任务检查点文件适合本地验证生产环境建议把任务状态存到数据库PostgreSQL、MySQL 或 Redis。核心表结构可以这样设计CREATE TABLE agent_task ( id BIGSERIAL PRIMARY KEY, workflow_id VARCHAR(64) NOT NULL, node_id VARCHAR(64) NOT NULL, status VARCHAR(32) NOT NULL, attempts INT DEFAULT 0, max_attempts INT DEFAULT 3, error TEXT, checkpoint JSONB, result JSONB, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), UNIQUE (workflow_id, node_id) );把状态放进数据库后你的 Agent 任务就具备了跨进程恢复能力。哪怕服务重启任务也能从数据库里读出每个节点的状态继续执行未完成的部分。这是长时程任务和一次性对话在产品形态上最根本的区别。6.2 人工审批与工具调用边界长时程任务在生产环境里还有一个现实约束权限与审批。不是所有步骤都适合自动化。比如删除线上数据修改生产配置对外发送重要邮件这些操作在执行前应该设置人工审批节点。当前主流 Agent 框架已经支持tool approval机制但在自定义长任务系统里你需要自己实现一条规则任务计划里显式标记哪些节点需要人工审批。执行到审批节点时任务暂停状态改为WAITING_TOOL。审批通过后任务从暂停节点继续执行。审批拒绝后任务进入CANCELLED状态并记录原因。没有审批边界的长时程任务在企业内部是无法获得信任的。这不是技术问题而是治理问题但它会直接决定产品能不能落地。6.3 任务级评测用基线数据说话很多团队评测 Agent 还停留在问几个问题看回答像不像样的阶段。长时程任务必须建立任务级评测基线。建议从三个维度采集数据成功率一个完整任务从开始到交付的成功比例。这是最重要的指标。平均步骤数完成一个任务实际需要多少步。步骤数越多出错概率越大。失败恢复率任务失败后通过重试或回退恢复的比例。有了这些指标你才能回答Chamath 说的是不是对的——不是凭感觉而是看自己系统的真实数据。7. 常见误区与排查思路长时程任务系统的故障排查和传统后端系统很不一样。下面整理几个高频问题的排查思路。问题现象可能原因排查方式解决方案任务执行到中段忽然失忆重复执行已完成的步骤上下文过长导致模型忽略早期指令或状态未持久化查看结构化日志中每个节点的执行顺序和处理时间引入显式状态机改为从数据库读取任务状态单步成功率很高但整体成功率极低错误在步骤间累积前置错误污染后续决策统计每步失败率识别成功率最低的节点在关键节点增加校验和人工审批工具调用返回格式变化导致解析失败上游接口变更或返回内容包含意外分支检查工具调用日志和返回原始内容为工具返回增加 schema 校验失败时快速失败并重试重试导致重复副作用重复发送邮件、重复扣费工具调用不是幂等的重试逻辑未做去重检查重试时的工具调用次数为每个工具调用生成全局唯一 request_id实现幂等任务失败后无法定位是哪一步出错日志不完整缺少节点维度的上下文检查是否记录每个节点的 checkpoint 和 error建立结构化日志统一记录 node_id、event、error一个特别容易踩的坑是重试逻辑设计不当。很多长时程任务失败就无脑重试当前步骤但如果当前步骤不是幂等的重试十次可能造成十次副作用。正确的做法是区分可安全重试和需要人工介入两类节点可安全重试的节点设置最大重试次数达到上限后进入等待人工处理状态。8. 对抗幻灭的工程原则回到开头的问题面对幻灭低谷工程师该怎么办我的建议是握住三条原则。8.1 最小闭环优先不要一开始就追求AI 全自动完成一切。选一个真实业务场景把任务拆到最小闭环保证这个闭环在 90% 的情况下能稳定走通再逐步扩大任务范围。一个能稳定完成 3 步任务的可信系统比一个 40% 概率跑完 20 步然后失控的 Demo 有用得多。8.2 可观测性高于模型选型很多团队纠结用哪个模型做 Agent 更好。实际上当前阶段决定长时程任务成败的往往不是模型智商而是系统的可观测性和恢复能力。先把日志、指标、跟踪、检查点做扎实再换模型评估效果你才有足够的数据支持判断。8.3 把失败当作一等公民传统软件工程里失败是异常分支长时程任务系统里失败是常态。设计每一个任务节点时先问三个问题失败了能不能恢复失败后有没有留痕失败达到上限后谁来处理只有把失败路径设计得和成功路径一样清晰长时程任务才真正具备产品可信度。9. 总结与后续学习方向回到 Chamath 的判断。他说长时程任务仍是笑话这句话的准确性取决于笑话的定义。如果你追求的是一个 Agent 说一句话就把复杂业务自动跑完那目前的工程现状确实还撑不起这个叙事。但把问题拆细看笑话的根源不在模型能力不够而在于我们把长时程任务当成了对话式推断问题而不是需要状态机、检查点、日志、评测、权限治理共同支撑的系统工程问题。这也是为什么幻灭低谷对工程师不是坏消息。当资本叙事退潮真正被检验的是产品能否在真实环境里稳定完成长时程任务——而这件事恰恰可以通过工程手段持续改进。建议下一步按这个顺序实践先选一个 3 到 5 步的真实业务任务显式建模任务状态机。给每个节点加检查点把状态持久化到数据库。为所有关键操作加结构化日志统计成功率、步骤数、恢复率。拿到基线数据后再去调模型、换提示词、优化单步工具调用。这样走下来你的 Agent 项目至少不会在低谷期被淘汰因为你有真实可评估的可靠性数据而不是一个漂亮的 Demo 和几句未来已来的口号。