企业官网建设流程全解析

Chamath 说长时程任务仍是笑话：AI 的幻灭低谷，开发者该怎么看

过去两年，AI 圈最不缺的就是“颠覆性进展”。今天 Agent 写代码，明天大模型做研究，后天仿佛全人类都能被 AI 接管。但就在这种氛围里，一个反共识的声音值得注意：Chamath 认为，长时程任务至今仍然是个笑话，AI 正在走向幻灭低谷。

这句话扔出来，很多人第一反应是“他又在唱衰”。但真正在一线做过 Agent 开发的人，可能反而会心一笑。因为大家心里都清楚：Demo 里的乖巧 Agent 和真实业务里的自动化流程，中间隔着的不是一层窗户纸，而是一整座工程大山。长时程任务的可靠性、成本、可观测性和容错能力，目前确实没有达到“可用”的标准线。

这篇文章不想跟着喊口号，也不想无脑反驳。我想从技术角度拆一拆：Chamath 的判断依据是什么，长时程任务到底难在哪，为什么“幻灭低谷”对开发者来说反而是件好事，以及在这个阶段我们到底该怎么用 AI 才不亏。

1. 先搞清楚：他在说“AI 没用”还是“AI 被高估了”

要理解 Chamath 的观点，得先明确一个边界。他并不是说大模型没有价值，也不是说 AI 写文章、做总结、搞代码补全没用。他说的是“长时程任务”（long-horizon tasks）——也就是那种需要 Agent 自主规划、多步骤执行、跨系统调用、持续数小时甚至数天的复杂任务。

这类任务的典型代表包括：

• 让 AI 从零开始做一个完整的软件功能，包括需求分析、编码、测试、部署、修复缺陷。
• 让 AI 在几十个数据源中做竞品调研，产出结构化报告，并根据反馈自动迭代。
• 让 AI 像一个真实员工一样，处理客服工单、协调多个系统权限、操作多个后台。

这些场景的共同点是：步骤多、链条长、失败点密集、外部依赖复杂。演示视频里，AI 可以顺畅地完成“帮我订一张去北京的机票，找好酒店，安排三天的行程”。但在真实生产环境中，它可能在第 2 步就因权限不足崩溃，在第 5 步因 API 返回格式变化而胡言乱语，在第 10 步干脆忘记了最初的目标。

ChatGPT 之类的工具擅长的是“单次高质量生成”，部分 Agent 框架能做到“短链路的自主执行”，但距离“长时程任务的稳定自治”，确实还有明显差距。所以 Chamath 说的“笑话”，不是嘲笑 AI 本身，而是嘲笑资本市场和舆论对 AI 能力的过度包装。

2. 长时程任务为什么这么难：不只是模型问题，更是系统工程问题

很多非技术人员会以为，长时程任务难在“模型不够聪明”。但真实瓶颈往往不在模型智力，而在工程实现。拆开看，至少有四个层面的难题。

2.1 错误累积与偏差漂移

一个单步成功率高达 99% 的任务，执行 100 步之后，整体成功率会跌到约 36%。如果用成本更高的模型和更细的提示词，把单步成功率提到 99.5%，100 步之后也只有约 60%。这不是玄学，而是最基本的概率叠加。

实际问题比这更麻烦：Agent 每执行一步，都会改变上下文状态。如果某一步产生了错误输出，后续所有步骤都会构建在错误的基础之上，而且这种偏差往往不会自动修正。人类在意识到跑偏时会停下来重新审视目标，但当前的 Agent 系统缺少这种“元认知”机制，它只会忠诚地把错误放大。

2.2 外部系统的不确定性

长时程任务几乎不可能在封闭环境里完成。Agent 必须调用 API、操作数据库、读写文件、触发 CI/CD 流水线，甚至操作第三方 SaaS 系统。这些外部系统并不会因为调用方是 AI 就变得友好。

网络超时、接口鉴权过期、字段格式变化、业务方临时更新了参数、下游服务出现 503——任何一个不可控因素都会中断任务链条。更麻烦的是，Agent 往往无法从失败中恢复。它可能重试三次，也可能是直接把错误信息写进结果，然后假装任务完成了。

做 Agent 开发的同行应该都遇到过这种情况：打开日志，发现 Agent 在凌晨三点反复调用一个已经失效的接口，重试了二十次，烧掉了大量 token，最后产出一份完全错误的结果。这已经是目前长时程任务最典型的失败模式。

2.3 上下文窗口的物理限制

长时程任务意味着长时间的执行过程，也意味着巨量的中间上下文。一个执行了 2 小时的任务，可能产生几十万 token 的中间日志、工具返回结果、思考过程。这些信息无法全部塞进上下文窗口，必须做截断、摘要或向量化存储。

但压缩必然带来信息损失。Agent 在任务后期可能已经忘记了前面某个关键参数的来源，只能靠摘要“猜测”。这种压缩导致的失忆，在处理需要精细一致性保证的任务时非常危险。

2.4 可观测性和恢复能力几乎为零

传统的软件系统崩溃了，有堆栈、有日志、有指标。Agent 系统要是中途崩了，开发者往往只看到一句“抱歉，我无法完成这个任务”。既不知道它执行到了哪一步，也无法从断点继续，更没法复现问题。

这种“黑盒失败”是长时程任务落地的最大工程障碍。企业可以容忍一个偶尔出错的 API，但无法接受一个执行了 3 小时却无法审计、无法断点续跑、无法定位失败原因的“数字员工”。

3. 从“演示惊艳”到“生产可用”，中间隔了一整条工程链

很多人混淆了“技术能力”和“产品能力”。ChatGPT 的演示视频、Claude 的多步操作、Cursor 的自动改代码，展示的都是技术上限。但生产系统要求的是稳定下限，而不是偶尔惊艳的上限。

举一个很直观的例子：让 AI Agent 写一个 Python 脚本，它大概率能写得不错。但让这个 Agent 完成“从需求分析到灰度发布一个完整后端服务”，需要处理多少工程细节？

• 它需要理解需求文档。
• 它需要选择技术栈并创建项目结构。
• 它需要写代码，并保证风格统一。
• 它需要写单元测试，且测试覆盖率达标。
• 它需要处理依赖冲突。
• 它需要配置 CI/CD 流水线。
• 它需要上线后监控日志并修复问题。

这个过程由人类来做，也需要一个完整团队的分工协作。开发者经验会体现在每一个环节的判断上：什么时候该读文档，什么时候该查日志，什么时候该停下来和同事沟通。而当前的 Agent 系统，只是把“写代码”这一步做得比较出色，其余环节还处于“能跑但不可靠”的状态。

所以，Chamath 说“长时程任务仍是笑话”，更准确的理解是：目前 Agent 的工程化水平，配不上资本市场给它的估值。

4. 幻灭低谷不是坏事，它挤掉的是泡沫，留下的是需求

“幻灭低谷”这个词来自 Gartner 技术成熟度曲线。任何一个技术都要经历技术萌芽期、期望膨胀期、幻灭低谷期、稳步爬升恢复期和生产成熟期。

AI 在 2023 到 2025 年经历了明显的期望膨胀。那个时候，很多人认为“什么都可以交给 AI”，创业公司只要在 PPT 上写“AI 驱动”就能拿到融资，开发者只要调几个 API 就能做出明星产品。这种过热必然带来反噬——当真实效果达不到预期时，资本会冷却，舆论会转向，企业会收紧预算。

但对真正做技术的开发者来说，冷却期反而可能是最好的土壤。

• 泡沫期，大量资源被平庸的“套壳应用”消耗。
• 低谷期，大家才会认真思考哪些场景真的适合 AI，哪些只是伪需求。
• 低谷期，企业的采购标准从“看起来很酷”变成“能解决实际问题的投入产出比”。
• 低谷期，真正有工程能力的团队反而容易跑出来。

从技术演进的规律看，大模型的基础能力并没有退步，多模态、推理、工具调用都在增强。变冷的是商业预期，而不是技术路线。这个阶段能活下来的应用，往往更务实，更愿意做脏活累活，更关注与业务系统的集成深度。

5. 面对“幻灭低谷”，开发者应该怎么办

与其焦虑“AI 是不是不行了”，不如换一个视角：当前技术水位下，什么能做，什么不能做，怎么做才能不踩坑。这里给出几组实际建议。

5.1 把“长时程任务”降维成“短链路自动化”

不要一上来就追求“让 Agent 独立完成整个项目”。可以先把业务拆分成一个个短链路任务，让 AI 在每条链路上做到高可靠。比如把“AI 自动修复线上 Bug”降维成“AI 根据日志和代码上下文生成修复建议，由人来确认后合入”。前者是长时程自治，后者是短链路辅助。显然后者在今天更接地气，也更容易落地。

5.2 给 Agent 加状态管理和断点恢复

如果一个任务必须跨多个步骤执行，开发者就应该把它当分布式系统来设计，而不是当“对话”来设计。具体手段包括：

• 用工作流引擎管理步骤状态，而不是让模型自行记忆。
• 每一步的输入输出都做持久化。
• 任务失败时，能定位到具体的失败步骤。
• 支持从失败节点重试，而不是从头开始。

把 Agent 封装成可恢复的工作流，这是在当前模型能力下提高长时程任务成功率的有效路径。

5.3 用确定性代码兜底，非确定性模型做决策

工程上最稳妥的 Agent 架构，往往不是“让模型做所有事”，而是“让模型做决策，让代码做执行”。比如解析日志、写文件、调用 HTTP API 这类确定性的操作，应该交给传统代码完成；模型只负责理解意图、拆解步骤、选择执行路径。这样即使模型幻觉，也不会直接破坏系统状态。

5.4 不要忽视成本治理

长时程任务必然消耗更多 token。一个执行了 50 步的 Agent 任务，可能每轮迭代都要发送几万 token 的上下文。如果业务量再上来，成本会很快失控。

建议在任务设计阶段就明确 token 预算。比如：

• 限制最大步骤数。
• 对中间结果做摘要压缩。
• 对工具返回的大段内容只保留关键字段。
• 低频任务用高精度大模型，高频任务用低精度的轻量模型。

5.5 重视可观测性建设

Agent 的可观测性比传统系统更复杂，因为你需要同时追踪“模型在思考什么”和“系统在做什么”。至少应该做到：

• 记录完整运行链路，包括任务 ID、节点 ID、耗时、成本。
• 记录每一步的模型输入输出。
• 记录工具的调用参数和返回结果。
• 对失败节点做标记和分析。
• 提供慢查询分析和异常检测。

只有把 Agent 当作生产系统来监控，才能找到失败模式，进而逐步逼近“可用”的门槛。

6. 现在还适合学 Agent 开发吗

答案是可以，但请调整目标。

如果是为了找一找产品灵感，做做原型验证，现在依然是很好的时机。工具链在成熟，模型能力在提升，社区沉淀的工程范式也越来越多。

如果要投入到长时程自治 Agent 的研发，建议先评估自己的团队是否有能力解决上面提到的工程问题。如果只是调 API 接一个开源框架，大概率会在早期就碰到可靠性、成本、可观测性的天花板。

当前阶段，比较健康的入局方式是：

• 选择一个流程相对标准、反馈周期短的垂直场景。
• 先用手工脚本 + 提示词的方式跑通流程。
• 再逐步引入 Agent 框架管理状态和执行。
• 持续建设评估集，用离线评测防止模型升级带来的回归。

这种“先窄后宽、先人工后自动”的路径，比一上来就想做“通用 AI 员工”要现实得多。

7. 常见迷思与真实边界

关于长时程任务和 AI 幻灭，有四个反复出现的迷思，值得单独拎出来说明。

这四条建议收藏，在写方案或者给领导汇报的时候，直接用得上。

8. 给团队和决策者的落地建议

如果你正在为团队规划 AI 应用方向，下面这几个原则值得参考。

第一，从单点提效切入，不要从“替代人”切入。先找一个高重复、低风险、反馈明确的环节，把 AI 接进去，让效率提升被真实度量。有了一个成功的样板，再扩展边界。

第二，用预算约束产品形态。任何一个 Agent 功能上线前，都要回答：单任务平均成本多少？毛利能不能覆盖？如果用户量增加 10 倍，成本是否可控？

第三，建立持续的离线评测机制。没有评测集的 Agent 项目，就像没有测试的 Web 应用，迟早会在重构中崩塌。建议每个 Agent 场景都维护一组基准任务，每次更换模型、修改提示词、升级框架，都跑一遍回归测试。

第四，不要忽视安全与权限。当 Agent 开始操作生产系统时，最小权限原则比什么都重要。建议给 Agent 单独创建专用账号，严格限制它能访问的资源和能执行的命令，并保留完整审计日志。

9. 总结：低谷期，恰恰是动手期

回到 Chamath 的判断：长时程任务是不是笑话？从生产可用性的角度看，目前确实还撑不起“自主完成复杂任务”的承诺。但更准确的总结是——长时程任务不是不可能，而是需要大量工程工作去逼近“可用”的底线。目前的 Agent 生态，像是 2007 年的智能手机：方向是对的，硬件够用了，但操作系统、开发者工具、应用生态都还差一口气。

在幻灭低谷期，对开发者最有益的策略不是观望，也不是狂热，而是确定边界，做深场景，积累工程能力。AI 会像所有颠覆性技术一样，在质疑中成熟。对于看得懂技术水位的人来说，这个阶段恰恰是锻炼基本功、建立竞争壁垒的窗口期。

建议收藏本文，等 Agent 真正进入生产成熟期时再回来看，你会理解今天这些“保守”判断的含金量。