先说明一点这篇文章不是站队文也不是情绪喷。Chamath 的观点在行业里确实引发了不小的争论尤其“长时程任务仍是笑话”和“AI 将陷幻灭低谷”这两句一出来就被各路开发者反复引用。但真正值得讨论的不是“他说得对不对”而是“他为什么这么说”以及“当下做 AI 应用的人到底该怎么面对这个问题”。如果你最近在做 AI Agent、自动化脚本、多步工具调用或者正在评估“要不要把一个任务完整交给大模型自主完成”那这篇文章会把概念、背景、工程难点和应对策略一次性讲清楚。1. 背景与核心概念1.1 Chamath 是谁他的观点为什么能引发讨论Chamath Palihapitiya 是风险投资公司 Social Capital 的创始人也是前 Facebook 高管。他在 AI 领域的言论一向比较犀利经常在播客和社交平台上发表“反主流”的看法。这次关于长时程任务和 AI 幻灭低谷的发言之所以能在开发者圈子里传开是因为它踩中了两个痛点很多团队做了大半年 AI Agent真正稳定跑进生产的场景极少。Demo 跟生产之间的差距比想象中大得多。他说“长时程任务仍是笑话”本质不是说 AI 没有价值而是指大模型在“短时间内、单步骤、生成类任务”上表现很好但一旦进入“多步骤、跨系统、长时间自主执行”的范畴可靠性会断崖式下降。1.2 什么是长时程任务长时程任务Long-Horizon Task指的是需要模型在较长时间内、通过多步推理和多次工具调用最终完成一个完整目标的任务。典型的例子让 AI 自动调研一个行业输出一份 50 页报告。让 AI Agent 自动完成电商订单的异常处理查订单、查物流、联系客服、退款、记录工单。让 Agent 写一个完整项目的代码然后自动编译、测试、修复、提交 PR。这些任务有几个共同点步骤多可能超过 10 步。每一步都会产生新的环境状态。中间可能出现错误需要纠错。最终结果难以用单一指标自动化评估。对比之下单轮问答、短文本生成、单张图片识别都不属于长时程任务。1.3 什么是“AI 幻灭低谷”“幻灭低谷”来自 Gartner 的技术成熟度曲线Hype Cycle。这条曲线描述了一项新技术从诞生到成熟的典型路径阶段名称特征1技术触发期新技术出现媒体开始关注2期望膨胀期市场热度最高到处是“颠覆”的叙事3幻灭低谷期落地困难项目失败资本撤退4稳步爬升期幸存者用工程化手段解决实际问题5生产成熟期技术真正成为常规生产力工具Chamath 说的“AI 将陷幻灭低谷”指的就是当前 AI 行业可能正在从“期望膨胀期”滑向“幻灭低谷期”。这一点从开发者社区的讨论中也能感受到。前两年大家聊的是“大模型能做什么”现在更多人在聊“为什么 Agent 跑不起来”“为什么长任务总是失败”“为什么上下文长了就乱”。这种转变本身就是技术周期进入新阶段的信号。2. 长时程任务为什么“难”五个工程化瓶颈如果你只看演示视频会觉得 Agent 已经无所不能。但你一旦自己搭一个需要连续调用 10 次工具的流程就会立刻遇到问题。2.1 上下文窗口不是越长越能记大模型的上下文窗口一直在变大从 4K 到 32K、128K甚至 200K。但长窗口并不意味着长记忆。这里有一个被很多人忽略的事实模型对上下文中不同位置的注意力并不是均匀的。更长的输入在推理时不仅消耗更多算力还会出现“注意力稀释”导致早期的重要信息被后续内容覆盖。具体表现就是任务跑到第八步时模型忘记了第一步设定的约束条件。所以单纯扩大上下文窗口解决不了长时程任务反而会带来更高的成本。2.2 错误累积每一步都有一点点误差长时程任务的核心难点不是某一步做不好而是错误会传递和放大。假设模型每一步工具调用的成功率是 95%听起来已经很高了。但如果一个任务需要连续调用 15 次工具最终成功率是0.95^15 ≈ 0.4633也就是说即使每一步单独看都很可靠整个任务的最终成功率也只有 46% 左右。这还没算上工具返回的数据格式变化、网络超时、中间结果不符合预期等更复杂的风险。这就是为什么很多 Agent 在演示时表现良好一上线就频繁失败——演示只覆盖了主路径生产环境全是边界情况。2.3 恢复能力模型不会自己“止损”人在执行长任务时发现某一步有问题会停下来调整方案。但当前大模型在长时程任务中的纠错能力还比较有限。常见的情况是模型发现工具返回异常但还是继续调用下一次工具。模型在错误的中间结果上继续推理导致最终结果越来越偏。模型陷入循环反复调用同一个失败工具不尝试其他方案。Agent 缺少的不是“推理能力”而是判断“当前状态是不是已经错了”的能力。2.4 状态管理模型没有真正的“记忆”从产品层面看模型每轮对话似乎都记得上下文。但从系统层面看大模型本身并没有一个持久的状态数据库。一旦任务出现中断、重试、并发状态就很容易丢失。真正的工程化 Agent 需要把状态从模型里搬出来交给外部系统管理比如数据库、Redis、任务队列。但这样一来Agent 的设计复杂度就上去了不再是“写一段 prompt 就能跑”的事情。2.5 评估困难你很难说它“做对了”短任务可以直接比较输出。比如翻译任务可以把结果跟参考译文对比。长时程任务呢我们说“让 AI 自动处理一个退款工单”怎么评估它做得对不对过程是否正确调用客服系统退款金额是否准确是否通知了用户是否留下了操作日志处理时长是否达标这些都是多维度、多步骤的结果难以用一个自动化的 LLM-as-Judge 模板来完成评估。更现实的做法是人工抽查但这就失去了“自动化”的意义。3. 到底是“笑话”还是“被低估”分环节看现状Chamath 的话在传开以后一些做 Agent 基础设施的人并不完全认同。在他们看来长时程任务的“工程外壳”正在快速成熟ChatGPT 式的对话产品只是 AI 能力的冰山一角。这里需要区分两个层面3.1 模型能力的进展确实被低估近两年推理模型reasoning model的进步是真的在逼近“自主完成长任务”的门槛。这些模型在数学、代码、逻辑规划类问题上已经能稳定地完成过去做不到的多步推理。更关键的是Agent 框架层出现了一个重要变化工具调用从“一步一问”变成了“流程内自治”。当 Agent 在一个流程中自主决定“下一步调什么工具、传什么参数、如何解析结果”时它在测试环境里已经能完成很多中等复杂度的任务。所以“笑话”这个词更多是对“无脑端到端”叙事的否定而不是对全部工程化尝试的否定。3.2 真正不成熟的是“无人值守的自主执行”即便模型能力有进展当前生产环境里跑成功的长时程 Agent绝大多数都保留了“人在回路”的机制。换句话说不是 AI 自主完成完整任务而是AI 做规划和草稿。每一步关键操作都要人工确认。出错后由人工接管而不是 AI 自我修复。这种模式虽然不够“酷”但它是当前唯一稳得住的生产形态。所以对“长时程任务是不是笑话”这个问题比较客观的结论是对“生成类”任务不是笑话已经能干活。对“执行类”任务勉强算半个笑话需要加大量工程机制。对“无人值守的完整业务闭环”目前确实还是笑话。4. 面对长时程任务工程上应该怎么落地既然当前阶段不适合“端到端无人值守”那开发者的选择不是放弃而是改变系统设计思路。这一节给出一个经过验证的工程模式把“让模型做完一切”改成“让模型在一个受控框架里完成多步操作”。4.1 核心原则任务分片 人工检查点不要让模型一口气完成 20 步任务。把任务拆成几个阶段每个阶段结束后设置检查点由人工或规则引擎校验中间结果。这里给出一个 Python 伪代码示例展示带检查点的任务执行循环# 文件路径agent_checkpoint_demo.py 带检查点的长时程任务执行框架示例 核心思路 1. 把任务拆成多个阶段 2. 每个阶段执行完做一次校验 3. 校验不通过则中断并通知人工介入 4. 全部阶段通过后任务才算完成 from typing import Any, Dict, List, Callable class TaskPhase: 单阶段任务描述 def __init__( self, name: str, executor: Callable[[Dict[str, Any]], Dict[str, Any]], validator: Callable[[Dict[str, Any]], bool], ): self.name name self.executor executor # 执行函数 self.validator validator # 结果校验函数 class AgentCheckpointPipeline: 带检查点的 Agent 任务管线 def __init__(self, phases: List[TaskPhase]): self.phases phases def run(self, init_state: Dict[str, Any]) - Dict[str, Any]: state init_state for phase in self.phases: print(f 执行阶段: {phase.name}) # 1. 执行当前阶段 result phase.executor(state) # 2. 更新状态 state.update(result) # 3. 校验结果 if not phase.validator(state): print(f!! 阶段 {phase.name} 校验失败停止执行等待人工介入) state[status] NEED_HUMAN return state print(f 阶段 {phase.name} 通过校验) state[status] SUCCESS return state # 示例用法 def call_llm_step(state: Dict[str, Any]) - Dict[str, Any]: 模拟模型执行一步任务 # 在实际项目中这里调用大模型 API并解析输出 step_result {data: 模拟执行结果} return step_result def check_step_result(state: Dict[str, Any]) - bool: 校验当前结果是否满足要求 # 正常项目里这里会有明确的规则判断 return data in state and state[data] is not None def create_demo_pipeline() - AgentCheckpointPipeline: 创建一个包含 3 个阶段的演示管线 phases [ TaskPhase( name信息收集, executorcall_llm_step, validatorcheck_step_result, ), TaskPhase( name方案生成, executorcall_llm_step, validatorcheck_step_result, ), TaskPhase( name结果输出, executorcall_llm_step, validatorcheck_step_result, ), ] return AgentCheckpointPipeline(phases) if __name__ __main__: initialState {task_id: task_001, status: PENDING} pipeline create_demo_pipeline() finalState pipeline.run(initialState) print(最终状态:, finalState)这段代码的优点包括每个阶段只面临一个相对简单、可控的子任务。校验函数独立不依赖模型自我评价。任何阶段失败都会把状态改成NEED_HUMAN避免模型在错误状态上继续硬跑。状态在外部维护不依赖上下文窗口来“记住”进度。这是当前解决长时程任务最有效的一种折中方式保留模型的生成能力同时用传统软件工程手段控制风险和复杂度。4.2 接入工单系统真实场景示例如果把上面的框架用到“自动处理退款工单”场景可以这样设计阶段1读取工单信息 - 工具调用查工单系统 - 校验工单状态是否为待处理金额是否合法 阶段2调用退款接口 - 工具调用调用支付系统退款接口 - 校验退款接口返回码是否为 200退款单号是否生成 阶段3更新工单状态 - 工具调用写回工单系统 - 校验工单状态是否成功更新为已退款每个阶段都可以独立测试、独立回滚、独立重试。某一个阶段失败不会导致整个流程混乱。如果你把任务完整交给模型自主处理模型一旦在第二阶段出错可能带着错误状态继续执行第三阶段最终造成重复退款或漏退款。4.3 日志与可观测性长时程任务的生命线长时程任务另一个容易被忽略的点是日志。短任务出错重新跑一遍就行。长任务出错如果不能定位到“哪一步、哪个参数、哪个工具调用导致异常”调试成本会非常高。建议在工程上做到每个阶段都有独立 trace_id。每次工具调用的请求参数和返回结果都落日志。任务状态变更记录到数据库表而不是只写在内存变量里。失败时保留现场方便问题复现和复盘。# 伪代码记录工具调用日志的通用装饰器示例 import functools import logging import time import uuid logging.basicConfig(levellogging.INFO) def trace_tool_call(func): 记录工具调用的输入、输出、耗时 functools.wraps(func) def wrapper(*args, **kwargs): trace_id str(uuid.uuid4()) start_time time.time() logging.info( TRACE_ID%s CALL_TOOL%s ARGS%s, trace_id, func.__name__, args, ) try: result func(*args, **kwargs) elapsed_time (time.time() - start_time) * 1000 logging.info( TRACE_ID%s TOOL_RESULT%s COST%sms, trace_id, result, round(elapsed_time, 2), ) return result except Exception as e: elapsed_time (time.time() - start_time) * 1000 logging.error( TRACE_ID%s TOOL_ERROR%s COST%sms, trace_id, repr(e), round(elapsed_time, 2), ) raise return wrapper技术上这只是一个很小的细节但在长时程任务的调试和稳定性保障上它比模型本身的推理能力更关键。5. 长时程任务常见问题与排查思路这部分整理了一些经常遇到的问题按工程实践中的出现频率排列。问题现象常见原因排查思路解决方案Agent 跑到第 8 步忘了初始需求长上下文注意力分散检查每一步的 prompt 是否包含关键约束关键信息外置到状态中不要仅靠上下文工具调用连续失败后仍然重试同一个错误失败恢复策略缺失查看日志确认重试是否触发了备用方案增加失败次数阈值达到阈值后人工接管任务状态在并发环境下丢失状态存在内存变量未持久化确认是否多个实例共享状态使用 Redis 或数据库存储任务状态模型输出 JSON 偶尔解析失败输出格式不稳定未做容错查看模型返回原始内容输出解析失败时重试一次仍失败则降级为人工处理中间结果依赖上一步格式但格式变了工具返回字段变更对比最近一次工具返回 schema做字段映射时保留容错默认值最终结果无法自动判断对错缺少评估规则明确任务成功的最少必要条件用规则校验为主LLM 评估为辅遇到长时程任务失败时建议按以下顺序排查先看日志确认失败实际发生在哪个阶段。复现现场把该阶段的输入参数完整拿到。检查是模型推理问题还是工具调用问题。区分是偶发问题还是稳定问题。针对稳定问题加校验规则或改流程设计针对偶发问题加重试和兜底策略。这里需要注意一个容易踩的坑不要通过“改 prompt”来修复长时程任务的稳定性问题。如果任务本身链路太长再精细的 prompt 也撑不住。优先改架构而不是反复调试提示词。6. AI 幻灭低谷期开发者和团队该做什么如果 Chamath 关于“幻灭低谷”的判断部分成立那接下来一段时间行业会面临一次明显的预期收缩。这个阶段对真正做技术的人来说反而是好事。下面给出一些比较务实的建议。6.1 从“模型能力竞赛”转向“问题场景选择”过去两年大家过度关注模型 benchmark但实际业务中真正卡住落地的从来不是“模型不够聪明”而是“找不到足够窄、足够明确的场景”。选择一个好的长时程任务场景应该满足步骤数量在 5 到 15 步之间不要一上来就挑战 50 步。每一步的输入输出相对结构化。有明确的任务成功标准。失败成本可控不会造成严重资损或安全问题。例如“自动整理销售数据日报”比“自动运营整个店铺”更合适作为长时程任务的起步场景。6.2 建立小规模的真实评估集与其相信“通用 benchmark 分数”不如建立一个小而准的评估集覆盖你业务场景中的典型路径和边界情况。评估集不需要很大30 到 50 个真实业务样本即可。关键是包含主路径样本。包含工具返回异常的样本。包含需要人工介入的样本。每个样本有明确的判定标准。每次更换模型、修改 prompt、调整流程都先跑一遍评估集用数据说话。6.3 把人工介入设计成“正常路径”而不是“异常兜底”很长一段时间内长时程任务都不能做到无人值守。与其把这个事实藏起来不如在设计系统时就把人工介入当成正常路径。具体做法把任务流程按节点拆分每个节点都可以独立暂停和恢复。人工审核通过后后续阶段继续执行。保留完整的操作审计日志方便追溯。这种设计虽然听起来不够“AI 原生化”但它能保证业务不失控。6.4 控制成本不要为了长任务用“大而全”的模型长时程任务涉及的 token 消耗往往远超短任务。如果你在每个阶段都调用最贵的模型成本会非常难看。合理的做法是简单工具调用用轻量模型。复杂规划和推理用强模型。路由层根据任务难度动态选择模型。对多轮同上下文的任务控制冗余 token 的注入。成本优化不是抠门而是让项目有长期运转的可能性。6.5 组织预期管理别让老板以为 AI 已经能“全自动”给团队和管理层建立合理预期是对项目的一种保护。一旦 Demo 给所有人留下“AI 能全自动完成”的印象后面任何一次失败都会被放大。比较好的沟通方式是在立项时明确说清楚这是一个“AI 辅助 人工审核”的流程目标是提升效率而不是替代人手。7. 总结长时程任务真的没救吗“长时程任务仍是笑话”这种说法适合用来打破过度宣传但不太适合作为工程判断。现实情况是模型层面的长时程推理能力在持续进步。工程层面的任务编排、状态管理、容错恢复正在慢慢补齐。真正的短板在于“端到端无人值守”的完整性以及评估体系的成熟度。所以与其争论 Chamath 的观点是否成立不如回到自己的项目里做三件事把任务拆小设置检查点。把状态外置不依赖上下文记一切。把日志做全让每一步都可追踪、可复盘。如果这三点能落地你会发现长时程任务虽然没有“笑话”那么不堪但也绝没有“演示视频”那么轻松。它需要的是软件工程耐心而不是 prompt 魔法。这也是在 AI 幻灭低谷期里真正值得长期积累的能力。