这次我们不看具体模型也不给部署命令而是一个值得技术人认真对待的行业判断Chamath Palihapitiya 在近期公开评论中表示长时程任务仍是笑话AI 即将进入幻灭低谷。这个判断听起来很刺耳尤其是现在 AI Agent、多智能体、自动化工作流天天刷屏的情况下。但作为实际接触过 Agent 开发的人我更想把这句话当技术问题来拆而不是当情绪化吐槽。长时程任务到底难在哪为什么一个长期观察硅谷的投资人会说出“笑话”这种词如果幻灭低谷真的来了它影响的不是 ChatGPT 聊天而是大量正在做 Agent 产品、长时程自动化、智能体平台的团队。本文会用工程视角拆解这个观点内容包括长时程任务难在哪里、当前主流方案为什么表现不稳定、幻灭低谷的判断依据是什么、对开发者选型和落地有什么影响以及如果你非要做长时程任务应该怎么设计验证流程。1. 观点核心速览先把这次讨论的关键信息整理清楚方便后面展开。项目内容观点提出者Chamath Palihapitiya硅谷投资人Social Capital 创始人核心判断长时程任务仍是笑话AI 将陷入幻灭低谷批评对象AI Agent 长时程任务、智能体自动化相关产品与过高估值技术关键词AI Agent、长时程任务、多步规划、上下文管理、任务评测痛点指向错误累积、状态丢失、成本失控、结果不可复现对开发者的影响需要重新评估长时程任务的工程可行性本文关注点从技术角度判断哪些问题真实存在哪些还有优化空间需要先说明一点这里讨论的不是某个具体软件工具而是整个 AI Agent 方向上的长时程任务能力。Chamath 的批评主要集中在“让 AI 完成一个需要多个步骤、需要记住中间状态、需要跨工具协作的复杂任务”这件事上。2. 长时程任务指的是什么在继续之前需要把“长时程任务”这个词定义清楚否则容易把聊天和自动化混为一谈。2.1 什么是长时程任务长时程任务英文常写作 Long-Horizon Tasks指需要模型在较长时间跨度内通过多个步骤完成一个目标的任务。典型特征有任务步骤多不是一步问答能完成的。中间状态需要维护比如需要记住前面几步的结果。需要调用外部工具比如搜索引擎、代码解释器、数据库、API。最终结果依赖多个中间步骤是否全部正确。举例来说“帮我写一篇行业分析报告”就是长时程任务它需要搜集资料、阅读多篇来源、整理信息、拟定框架、分段撰写、再检查修改。每一步都依赖前一步的输出且中途可能遇到来源失效、信息矛盾、上下文被截断等问题。2.2 为什么它和普通问答难度完全不同普通问答是单轮或少数几轮交互模型只需要理解当前问题并生成回答没有长期状态负担。长时程任务则要求模型正确拆解目标把大任务分解成可执行的子任务。执行过程中不迷失原始目标。维护一个可靠的中间状态随时知道“现在做到哪了”“还缺什么”。在关键节点自我检查如果结果不对能够修正。整个过程消耗大量 token成本随时间线性增长。所以 Chamath 说长时程任务“仍是笑话”本质是在说当前模型在处理这种多步任务时成功率不够稳定用户体验达不到产品级要求。3. 长时程任务的核心技术难点拆解这一部分是重点。长时程任务之所以难不是某一个环节出了问题而是多个技术瓶颈叠加在一起导致整体可靠性下降。下面逐个说。3.1 错误累积问题模型每一步都有一定的错误率哪怕单步错误率只有百分之一任务一旦拆成二十步、五十步最终成功率会迅速下降。如果把每一步的成功率都当作独立事件总成功率等于各步骤成功率的乘积。假设每步成功率是 90%二十步任务的总成功率只有不到 12%。很多长时程任务在实际运行中成功率甚至撑不到二十步就已经崩了。这就是为什么单看模型能力觉得“还行”一旦跑完整链路就会暴露大量问题。Chamath 所谓的笑话更多是这个意思演示环境下能做五步、十步放到真实任务中五十步、一百步就不可控了。3.2 上下文与状态维护长时程任务必须记录中间状态比如已经搜索过哪些内容、已经生成了哪个模块、还有哪些信息缺失。当前主流做法是把历史记录全部塞进上下文让模型自己判断状态。这个方案有两个问题。第一上下文长度有限随着任务推进早期重要信息可能被挤掉。第二模型从长上下文中提取关键状态的能力并不稳定经常出现“前面做过的事后面忘了”的情况。解决状态维护问题更可靠的做法是把状态显式写入外部存储比如数据库、JSON 文件或专门的记忆模块而不是完全依赖模型自带上下文。但很多 Agent 产品并没有这么做因为工程复杂度会显著上升。3.3 工具调用的不确定性长时程任务几乎必然需要调用外部工具。问题在于工具返回结果格式不稳定可能包含大量无关信息。工具可能超时、报错或返回空数据Agent 需要判断是否需要重试。多个工具之间有依赖关系时一个失败可能导致后续步骤全部失效。这些都是典型的工程可靠性问题而不是模型推理能力问题。换句话说就算模型推理能力很强如果工具链路不稳定整体任务依然会失败。3.4 目标漂移长时程任务执行到一半时模型可能会“忘记”最初的用户目标开始顺着中间结果越跑越偏。尤其在多轮 Agent 循环中模型容易对中间信息过度投入把次要问题当成主要目标处理。目标漂移是 Agent 开发中最难察觉的问题之一因为结果看起来“好像完成了”但交付物和用户原始需求并不匹配。产品层面需要强约束机制比如把用户目标写成不可变的任务描述每次循环前重新加载。3.5 评测困难普通模型的评测相对成熟有标准数据集可以算准确率、BLEU、ROUGE 等指标。但长时程任务要评测的是“多步执行后最终结果是否正确”这里存在两个问题很多任务没有唯一正确答案只有“可用”和“不可用”的边界。人工评测成本高自动化评测又很难覆盖中间状态是否正确。评测体系缺失的后果是团队很难判断一个 Agent 到底进步了还是退步了难以量化交付结果。这也是投资人诟病的方向之一——产品讲得很好但实际效果缺乏可验证的标准。4. 当前主流方案的实际表现现在的长时程任务落地通常会走几条技术路径但它们各有局限。4.1 思维链推理模型在生成最终答案前先生成一段推理过程让模型逐步思考。这个方法在短任务上提升明显但在长时程任务中推理路径越长模型越容易出现“一本正经地胡说八道”。思维链本身不保证中间步骤绝对正确。4.2 ReAct 风格 AgentReAct 是 Reasoning Acting 的模式模型交替进行推理和行动调用工具获取信息再基于新信息继续推理。这是很多 Agent 框架的基础但实际运行中经常出现循环调用同一个工具没有任何新进展。在错误的分支上反复尝试。工具调用格式错误被系统反复纠正。4.3 多智能体协作把大任务拆分给多个子 Agent每个 Agent 负责一部分再通过一个编排者汇总。这种方式在演示场景很好用但工程复杂度成倍上升尤其是子 Agent 之间通信、状态同步、冲突处理。所谓“三个臭皮匠顶个诸葛亮”在 Agent 场景里未必成立可能只是把错误拆散到多个角色里。4.4 长期记忆方案通过向量数据库、外部记忆或摘要机制让 Agent 能保留更长期的信息。这个方向是对的但远未成熟。记忆检索是否准确、摘要是否会丢失关键细节、记忆和当前上下文的优先级如何权衡都是问题。所以从整体看当前长时程任务不是没有进展而是进展停留在“能演示、能跑通少量案例”的阶段。距离稳定交付还有很大的工程距离。5. 幻灭低谷的判断依据Chamath 提到的“幻灭低谷”来自技术成熟度曲线指的是新技术在公众预期膨胀后到达实际表现低于预期的阶段资本和关注度随之回落。5.1 预期曲线回顾过去两年AI 领域的预期曲线大致是这样走的大模型能力惊艳引发大量关注。Agent 概念兴起AutoGPT、BabyAGI 等早期项目刷屏。各类 AI 编程助手、Agent 平台融资不断。产品开始交付但用户发现长时程任务并没有传说中那么强。资本开始重新审视 ROI甚至出现看空声音。Chamath 的判断正是处于“预期很高但实际落地一般”这个阶段。5.2 为什么说低谷可能真的会来从工程角度看低谷是否会来取决于三个问题第一长时程任务的成功率是否能达到可用水平。如果大量任务成功率只有百分之五十以下企业很难把它放进生产流程。第二成本是否可控。长时程任务消耗大量 token一次任务可能烧掉几美元甚至几十美元。对 C 端产品来说这几乎是不可接受的成本结构。第三是否有可复现性。同一任务跑两次结果不一致这在很多严肃业务场景中是不可接受的。企业可以接受人工审核但无法接受结果完全不可控。当这三个问题同时存在时产品评估很容易从“AI 能否完成”变成“AI 能否稳定低成本完成”答案往往令人失望。这就是幻灭低谷的根源。6. 对 AI 工程师和产品团队的实际影响Chamath 的观点如果成立意味着什么需要分层来看。6.1 对技术选型的影响做 AI Agent 的团队可能需要重新审视自己的方向如果你的产品核心就是“长时程自动执行”要及早验证成功率而不是堆功能。如果只是用 Agent 做短流程辅助比如“写摘要”“翻译”“生成代码片段”受影响较小。如果计划用长时程任务替代人力岗位需要预留人工兜底机制。6.2 对技术评估方式的影响过去团队评估 Agent 可能只看“能不能跑通几个演示案例”。低谷期更合理的做法是建立小规模评测集覆盖 50 到 100 个真实任务统计成功率、耗时、token 消耗、人工介入次数用数据说话。6.3 对成本预算的影响长时程任务的 token 消耗必须提前预估。一次复杂任务的 token 消耗可能远高于普通对话。如果产品是免费面向用户需要严格控制任务长度和调用次数否则成本会迅速失控。7. 如果你非要做长时程任务应该怎么验证虽然现实不乐观但不代表长时程任务没有空间。问题在于要用工程方法去管理不确定性而不是直接相信 Demo。下面这套验证流程可以作为参考。7.1 先做最小可运行实验不要一开始就搭建完整产品先写一个最小脚本让模型完成一个只有三到四个子步骤的任务。# 任务设计示例完成一个小型资料整理任务 task_plan [ 搜索关于AI Agent的最新文章, 总结每篇文章的核心观点, 合并所有观点并生成500字摘要, 输出Markdown格式的报告 ]先观察这四步能否稳定完成记录每次运行的成功率、耗时和 token 消耗。7.2 逐步增加任务长度四步跑通后加到八步、十二步、二十步观察成功率的变化曲线。这一步是最关键的如果二十步任务成功率已经从 80% 掉到 30%那就要认真考虑产品化是否可行。建议使用表格记录实验数据任务步数运行次数成功次数成功率平均耗时平均token消耗410990%40秒8000810770%90秒200001210550%150秒35000注意上表是示意具体数值要以你自己的模型和任务为准。7.3 设计状态持久化机制不要只靠模型上下文记忆中间状态建议把状态写入文件或数据库。这里给出一个通用伪代码思路import json state { step: 0, collected_data: [], last_result: None } # 每一步执行后更新状态 def update_state(key, value): state[key] value with open(agent_state.json, w) as f: json.dump(state, f, ensure_asciiFalse, indent2)通过持久化状态即使 Agent 中途崩溃也可以从最近一次保存的位置恢复。7.4 预留人工审核节点在关键步骤处设置人工确认节点比如调用付费 API 前。删除或修改重要数据前。最终结果对外发布前。人工介入会牺牲一点自动化率但能显著提升整体任务的可控性。7.5 建立回归评测集选一批代表性任务每次模型升级或框架改动后跑一遍评测集观察成功率和质量是否有变化。没有评测集的 Agent 开发基本是在盲人摸象。8. 接口 API 与批量任务的关系长时程任务和普通批量任务有一个关键区别普通批量任务是流水线式的每个任务相互独立长时程任务则是单个任务内部包含多个步骤每个步骤都可能调用接口。8.1 接口调用设计要点如果你要把长时程任务做成服务接口设计需要注意必设超时时间避免长时间无响应。支持任务 ID方便查询执行状态。支持异步回调而不是让客户端一直等待。记录每一步的输入输出日志便于排查。8.2 通用调用示例下面是一个任务执行的简化 Python 模板展示如何为长时程任务封装接口调用import requests task_id task_123456 url http://127.0.0.1:8000/agent/run payload { task_id: task_id, goal: 整理近一周的AI行业新闻输出摘要, max_steps: 20, callback_url: http://127.0.0.1:8000/agent/callback } try: response requests.post(url, jsonpayload, timeout60) data response.json() print(任务已创建:, data[status]) except requests.exceptions.Timeout: print(任务提交超时请检查服务状态)注意这只是通用调用模板实际接口路径和参数需要按你选用的 Agent 框架调整。8.3 批量任务的正确打开方式如果你的场景确实需要批量执行长时程任务建议不要直接并发几十个 Agent 同时跑而是先小批量试跑 2 到 3 个任务。确认成功率和成本可接受后再扩大并发。为每个任务配置独立的日志和状态文件。失败任务自动重试但重试次数不超过两次。9. 资源占用与性能观察方法长时程任务的资源占用通常是动态变化的不能只看单次推理的显存占用还要观察整个过程的内存、CPU、API 调用频率。9.1 显存占比如何观察如果你用的是本地模型可以通过显存监控工具观察整个任务执行过程中显存的变化。长时程任务的特点是显存占用会随上下文长度增加而上升任务越往后输入越长显存压力越大。显存占用需要以你自己的模型规模和上下文长度为准不同模型差异很大不要盲目参考网上的数据。9.2 成本和延迟观察对于调用云 API 的长时程任务重点观察每个子任务的 token 消耗。整条任务链路的总 token 消耗。每步的响应延迟。是否有无效重试比如同一个工具调用失败后反复重试。建议在每次 Agent 循环中打印当前累计 token 消耗及时发现有成本异常的执行路径。# 伪代码统计单步消耗 def log_step_cost(step_name, prompt_tokens, completion_tokens): total prompt_tokens completion_tokens with open(cost.log, a) as f: f.write(f{step_name}: {total} tokens\n)10. 常见问题与排查方法长时程任务开发中常见的问题整理成下面这张排查表问题现象可能原因排查方式解决方案Agent 中途停止执行超出最大步数限制或模型输出异常查看日志中的循环次数和结束原因调整 max_steps 参数增加异常处理上下文太长导致截断任务步骤多历史记录累积观察 token 数是否接近上限引入摘要机制或状态持久化工具调用一直失败接口地址错误或参数格式不对检查工具调用的返回日志修正工具描述和参数 schema结果和需求不一致目标漂移对比最终输出和初始任务描述在每轮循环开头重新加载用户目标同一任务多次跑结果不同模型采样随机性高统计多次运行结果差异降低 temperature或增加校验后重跑批量任务中途某个失败单条数据异常查看失败任务的日志对单条任务重试隔离失败样本11. 最佳实践与使用建议回到 Chamath 的观点上我的判断是他说对了一部分但也忽略了一部分工程上的机会。长时程任务现状确实不成熟但并不意味着没有空间只是空间存在于边界明确、有强校验机制、允许人工介入的场景里。下面几条最佳实践可以直接落地。11.1 先画清楚任务边界不要把整个工作流交给 AI而是把任务拆成“AI 能稳定完成的部分”和“必须人工介入的部分”。一个好的长时程任务设计是把 80% 的中间步骤交给 AI关键决策点留给人。11.2 评测优先于功能迭代先把评测集建立起来再考虑加功能。没有评测你就无法分辨模型输出到底是进步还是退步。评测集可以很小但必须覆盖真实任务场景。11.3 成本写进产品指标建议在需求评审时就把 token 成本纳入考量。如果一次长时程任务的成本超过人工成本的十分之一那产品化就要非常谨慎。11.4 日志要完整长时程任务必须保留完整执行日志包括每一步的输入、输出、工具调用结果、花费时长、token 数。否则出了 bug 完全没有办法排查。11.5 注意合规边界用 AI 处理数据时要确认数据来源和授权范围不要在未经授权的情况下处理他人隐私数据。涉及用户信息的任务需要明确告知并由用户确认。12. 总结现在回到题目本身Chatam 说长时程任务仍是笑话AI 将陷幻灭低谷。从技术现状看他的批评有合理依据。长时程任务在多步规划、状态维护、错误累积、成本控制和效果评测上都还没有达到稳定可交付的水平尤其是中间任何一个环节掉链子最终结果都可能失效。但如果因此把整个方向否定我觉得也过于极端。更准确的判断是长时程任务不是“笑话”而是“工程成熟度不足”。演示能力已经有了产品级稳定性还有距离。对开发者来说这件事的启示不是放弃 Agent而是用评测数据代替市场宣传来建立预期。缩减任务长度减少错误累积。状态持久化不要依赖上下文记忆。人工兜底关键节点保留监督。控制成本别让 token 消耗吃掉产品毛利。如果你正在做一个长时程任务相关的产品建议先跑通一个最小闭环记录成功率、成本和人工介入次数再决定是否加码。建议先做上面第 7 节的最小任务实验用数据判断你的场景到底值不值得继续投入。