企业官网建设流程全解析

这次我们要聊的不是一个新的开源模型，也不是某套本地部署包，而是一个行业判断：长时程任务到底是不是笑话，AI 会不会进入幻灭低谷。提出这个观点的是 Chamath Palihapitiya，Social Capital 创始人、前 Facebook 高管，也是 All-In 播客里对 AI 泡沫表态最激进的人之一。他的核心逻辑并不复杂：当前 AI 在“单点能力”上很强，但一旦进入需要多步骤、长时间自主完成的任务，错误率会迅速累积，最终产出不可用，所以“长时程任务”在现阶段仍然谈不上实用。这个观点在开发者社区里引起了两极分化。有人觉得他是外行看热闹，有人则认为他戳中了 Agent 工程最痛的部位。

这篇文章不站队，而是把这个问题拆成技术问题来看：长时程任务难在哪，Agent 的技术栈卡在哪，幻灭低谷对开发者到底意味着什么。如果你正在做 AI Agent、自动化流程、多步骤任务编排，或者在评估要不要把业务交给 Agent 来做，这篇文章可以直接收藏。

1. 核心观点速览

先把整件事放在一张表里，方便快速判断这个议题和你的关系。

这里先明确一下“长时程任务长在哪”。短时程任务，比如“把这段文字翻译成英文”“总结一下这封邮件”，模型只需一次或少数几次推理就能完成；长时程任务则是“帮我调研这个行业，输出一份报告”“自动回复客服工单”“跨系统同步数据并生成对账结果”这一类。后者要求模型自己做计划、执行、检查、纠错，并且要处理真实系统里的各种异常。Chamath 的判断，本质上是说目前模型在这条长链条上的稳定性还远不够。

2. 长时程任务：为什么会被叫“笑话”

一句“长时程任务是笑话”听起来刺耳，但拆开看，它背后有四个非常明确的技术原因。

2.1 错误累积：一步错，步步错

这是长时程任务最核心的失败模式。模型在第一步出错，第二步可能在错误的基础上继续执行，第三步错误被放大，最终结果离目标越来越远。短任务里，单次错误可以用重试解决；长任务里，错误会沿着执行链传播，而且越到后面越难定位。

可以写一段伪代码来模拟这个现象：

# 模拟长时程任务中的错误累积 # 假设每一步的成功率是 step_success_rate # 任务完成率 = 每一步成功率的乘积 def task_success_rate(steps: int, step_success_rate: float) -> float: return step_success_rate ** steps # 单步成功率 0.95，执行 10 步 print(task_success_rate(10, 0.95)) # 约 0.598 # 单步成功率 0.95，执行 30 步 print(task_success_rate(30, 0.95)) # 约 0.214 # 单步成功率 0.9，执行 10 步 print(task_success_rate(10, 0.9)) # 约 0.348

这个公式当然简化了很多东西，但它能说明长时程任务最基本的困境： 就算每一步都做得很不错，只要链条变长，整体成功概率就会指数级下降。这也是“长时程任务仍是笑话”这句话最有技术含量的一部分。

2.2 上下文漂移

模型在执行长时程任务时，通常会把之前的中间结果放进上下文里。但上下文越长，模型越容易忽略早期关键信息，或者在后续步骤中生成和早期结论矛盾的内容。这在技术圈被叫作上下文漂移或 Lost in the Middle。

实际表现是：任务开始时的目标约束，执行到第 20 步时被模型自己改写了；用户在初始 prompt 里输入的限制条件，模型在后面某个子任务里直接忽略了。不是说模型没有能力，而是长上下文下的一致性保持能力还不够，尤其当中间穿插大量工具返回结果时，注意力会被噪声带偏。

2.3 工具与外部系统的不确定性

长时程任务几乎不可能只靠模型自己完成，必然要调用搜索、数据库、代码执行、API 等外部工具。问题在于，模型每一步对工具的调用都可能遇到以下情况：

• 工具返回格式变化，模型解析失败；
• 外部接口超时或限流，模型不知道重试还是放弃；
• 工具的返回结果和预期不一致，模型基于错误结果继续决策；
• 权限不足、数据缺失、网络波动，这些不是模型能“思考”解决的。

这些问题让长时程任务的失败点分布变得非常分散。有时候模型本身没问题，但外部系统一次异常，整个任务就断了。

2.4 评估困难：胜率指标掩盖了中段失败

短任务的评估很直接：翻译对不对、摘要准不准、分类对不对，一眼就能看出来。长时程任务的评估则要复杂得多：最终结果正确，但中间步骤走了弯路，算不算成功；最终结果错误，但中段有几个子任务完成得很好，怎么评价；任务执行了几十步，系统崩溃后从哪一步恢复，成功标准怎么定义。

很多团队在 Agent 演示时只看“最终跑通了”，但对失败路径没有任何统计。这就导致一个问题：同一个 Agent，在演示集上的完成率很好看，换到真实业务数据上就崩。不是模型退步了，而是评估标准没有覆盖长任务里真正的失败模式。

3. 长时程任务的技术地图：卡在哪个环节

要判断长时程任务是不是真的“笑话”，不能只看结论，得看技术栈每一层的现状。

3.1 规划：看起来强，实际脆

现在的模型很擅长把一个大任务拆成子任务列表，这个能力在短任务里看起来很惊艳。但只要子任务开始执行，环境会变。第一步的结果可能和规划时的假设完全不同，模型是否具备重新规划的能力？很多 Agent 框架的做法是让模型循环“观察-思考-行动”，理论上可以应对变化，实际上如果模型的评判能力不够，就会在错误的分支上越走越远。

3.2 记忆：上下文窗口不是记忆

把上下文窗口做到 100 万 token，不等于模型有了记忆。记忆意味着能够识别“哪些信息对当前决策重要”，并且能在需要时稳定召回。目前的多数实现，本质上是把全部历史塞进上下文，靠模型注意力去筛。任务一长，注意力在噪声上的分布会显著增加。真正工程化的记忆，应该包含结构化摘要、向量检索引擎、关键事实存储和遗忘策略，这些目前还处于早期阶段。

3.3 工具调用：成功率高，但接口是脆的

在固定格式、固定环境下，当前模型调用工具的成功率已经不低。可真实系统的 API 不是为模型设计的，字段命名、返回码、分页、限流、鉴权方式都可能是混乱的。模型不是不会调接口，而是不会处理接口失败后的修复流程。这方面的差距，需要工程框架来补，例如重试队列、回退策略、人工审批节点，而不是只靠一个更大的模型。

3.4 自我反思：能发现错误，但不一定能修正

反思机制，也就是让模型审一遍自己的输出，确实能降低一部分低级错误。但反思也有边界：如果模型本身的推理能力不足以识别错误，反思只会得到“我认为我做得对”这种无效结论。另一个典型问题是死循环：模型发现自己错了，重试，又错了，再重试，反复消耗 token，最终超时或耗尽预算。没有完善的终止条件，自我反思反而会把任务拖入更糟的状态。

3.5 评估：最缺的一环

长时程任务能不能工程化，最终取决于能不能自动评估。目前比较可行的方法是拆解式评估：把最终任务拆成多个原子子任务，为每个子任务定义通过标准，然后统计每一步的通过率、失败分布、平均重试次数。这样才能回答“这个 Agent 到底卡在哪”。但大多数项目没有做这一步，结果就是所有长时程任务都停留在“能跑通 demo，但不知道能不能上线”。

可以给一个通用的评估配置文件参考：

{ "task_name": "customer_service_agent", "max_steps": 20, "evaluation": { "subtask_passed": "subtask.status == 'completed'", "final_passed": "final.report != null && final.accuracy >= 0.9", "max_retry_per_step": 3, "allowed_total_retries": 10, "timeout_seconds": 600 }, "metrics": [ "first_step_accuracy", "mid_term_error_rate", "final_completion_rate", "avg_retry_count" ] }

这套配置不是某个具体框架的标准，而是长时程任务评估里常见的最小模型。第一步准确率反映模型的初始理解能力；中段错误率反映长程执行能力；最终完成率反映端到端可靠性；平均重试次数反映成本。四个指标合在一起，比单纯看“成没成”更能说明问题。

4. 幻灭低谷：AI Agent 工程正在经历什么

讲完长时程任务本身，再回到 Chamath 的第二个判断：AI 将陷入幻灭低谷。这个判断用到的是技术成熟度曲线里的标准概念，形容技术从被高估到被质疑、再到真正稳定落地的过程。

4.1 幻灭低谷的技术含义

技术成熟度曲线的核心逻辑是：一项新技术刚出现时，市场对它的期望会迅速超过实际能力；当第一批真实用户开始用它做关键业务时，发现效果不达预期，期望就会快速回落；随后技术进入缓慢改进期，最终才形成稳定生产力。如果把 AI Agent 放进这个模型里看，过去两年的高期待，和现在大量长时程任务“Demo 惊艳但生产不可用”的反馈，确实符合幻灭低谷的典型特征。

4.2 哪些能力已经被验证

需要客观看待的是，并不是所有 AI 能力都处在幻灭期。以下场景已经被相当多的生产环境验证过：

• 文本分类、信息抽取、情感分析；
• 代码生成辅助、单元测试生成、代码解释；
• 短文本翻译、摘要生成；
• 基于 RAG 的固定文档问答；
• 语音转文字、OCR 等单点识别任务。

这些任务的共同点是：输入边界清晰，输出可验证，失败成本可控。它们不会因为“幻灭低谷”的讨论而退步。

4.3 哪些能力还在演示阶段

需要真正质疑的是：完全自主的长时程任务、复杂多步骤工作流、跨系统自动决策。这些场景里，模型要承担大量规划和纠错责任，而当前工程体系还没能补齐错误累积、上下文漂移、接口故障处理这些问题。把这些任务称为“演示级能力”，比直接说“笑话”更准确，也更符合实际体验。

4.4 对“AI 将陷幻灭低谷”的判断边界

按公开讨论的常见转述，Chamath 的判断是有保留空间的。更稳妥的理解是：他会认为市场对 AI 的过度投资会先于技术成熟到来，导致行业整体估值和关注度回落。对开发者来说，这意味着两件事：一是资本和市场热度可能收紧，纯靠概念拿资源会变难；二是真正具备工程价值的产品会在这个过程中被筛选出来。幻灭低谷不是技术的终点，而是“演示级”和“生产级”开始分道扬镳的节点。

5. 工程化瓶颈盘点：长时程任务距离可用还差什么

如果说上一节讨论的是行业周期，这一节就落到具体工程问题。我把长时程任务从“能演示”到“能交付”之间的差距，分成五个瓶颈。

这五个瓶颈里，可靠性是核心。成本、数据、安全都可以靠制度设计来缓解，但可靠性不足会让整个任务在源头失去信任。所以工程化的第一步不是让 Agent 更聪明，而是设计一个能在 Agent 不稳定时仍然不失控的系统框架。

5.1 可靠性不达标时，不要直接追求全自动化

目前最稳妥的做法是“分段自动化 + 人工审批节点”。让 Agent 负责执行有明确规则的子任务，在关键决策点停下来，由人来确认。等某个环节的通过率稳定超过阈值，再逐步减少人工介入。这一步不是妥协，而是长时程任务进入生产环境的必经过程。

5.2 成本预算要按失败场景设计

很多团队只算了成功路径的 token 成本，没有算失败路径。一次任务重试 5 次、调用 20 次工具、每次返回 2000 token，成本会迅速翻倍。建议在 Agent 框架层面加入最大步数、单步最大 token、重试次数上限，超出后强制终止并转人工。把失败成本纳入预算模型，长时程任务才具备可算的经济性。

5.3 数据回流是 Agent 持续改进的燃料

幻灭低谷期最常见的现象是：同类错误反复发生，因为失败样本没有被收集。工程化团队应该把每一次 Agent 执行的轨迹、报错、人工修正结果记录下来，形成失败样本库。每隔一段时间，用这些样本做回归测试，再针对性优化 prompt、工具调用策略或评估规则。这个闭环是长时程任务从不可用走向可用的关键。

6. 如何验证一个长时程任务是否真的可用

如果你正在评估某个 Agent 框架或者自研长时程任务系统，不要只信演示，建议用下面这套流程做一次独立验证。

6.1 设计一个最小可验证任务

先选一个业务上真实存在、但边界足够小的任务。例如：

• 任务目标：读取某个目录下的 20 个 PDF 发票，提取关键字段，汇总成一个表格；
• 成功标准：字段准确率不低于 95%，表格格式完全正确；
• 执行限制：最多 30 步，超过即失败；
• 人工兜底：每一步识别结果可以人工抽查。

这个任务既不复杂到无法控制，又包含了解析、提取、结构化输出、批量处理等多个环节，足够暴露长时程任务里的大部分问题。

6.2 记录完整执行轨迹

不要只记录最终结果，要记录每一步的输入、输出、决策理由、工具调用结果、重试次数。这样后期分析失败路径时，才能知道到底是在规划层、工具层还是输出层出的问题。

# 通用执行轨迹统计模板，需要按实际框架调整 import json from collections import Counter with open("agent_trajectory.json", "r", encoding="utf-8") as f: traces = json.load(f) step_counter = Counter() error_counter = Counter() for trace in traces: for step in trace["steps"]: step_counter[step["type"]] += 1 if step.get("error"): error_counter[step["error"]["type"]] += 1 print("步骤类型分布:", step_counter) print("错误类型分布:", error_counter)

这段代码的思路是：先统计执行步骤的类型分布，再统计错误类型分布。如果“工具调用错误”占了大部分，说明问题在接口稳定性；如果“反思循环”占了大量步骤，说明终止条件没设计好；如果“中间结果格式错误”频发，说明 prompt 或解析逻辑需要修复。

6.3 用过程指标评价，而不是只看完成率

评价长时程任务至少要看四组数据：

这些阈值是一个通用参考，具体到不同业务可以调整，但主轴很清晰：不要用最终完成率掩盖过程失败。如果最终完成率很高但中段纠错率很低，说明任务本身简单，Agent 的鲁棒性并没有被真正验证。

6.4 加入回归测试机制

长时程任务系统改一个 prompt，可能影响所有下游步骤。因此要为每个已验证的任务维护一套回归测试集。每一次提示词更新、模型切换、工具接口变更，都在这套测试集上跑一遍，对比完成率、重试次数、错误分布三个指标。一旦关键指标下降，立即回滚或修复。

7. 给开发者和企业的建议

回到 Chamath 观点的现实意义。长时程任务在某一天可能不再是一个“笑话”，但前提是工程团队先解决下面这些问题。

7.1 先做小闭环，再拉长时间

不要一上来就构建一个几十步的超级 Agent。先选一个 3 到 5 步的闭环任务，把它做到稳定，再逐步增加步骤。每增加一个步骤，都要重新评估整体成功率曲线。这样做的好处是：一旦失败，你能很清楚地定位是新增步骤的问题，还是原有逻辑的退化。

7.2 让人工兜底优先于完全自动化

在长时程任务不可靠的阶段，系统设计应该默认“人工参与”。Agent 负责执行和草拟，人工负责审批和修正。这样即使模型出错，损失也可控。真正进入生产环境的长时程任务，几乎都有人工审核环节，这不是能力不足，而是工程上必须保留的安全阀。

7.3 用可观测性对抗黑盒

长时程任务最可怕的地方在于：你不知道它哪一步开始跑偏。所以每个任务都需要完整日志，包括 prompt、模型输出、工具输入输出、重试记录、耗时、成本。只有把执行过程变成可观测数据，才能在失败时快速复盘。

7.4 预算要按失败成本设计

每次 Agent 调用都会产生成本。如果任务可能失败，预算必须包含重试和人工修复的成本。建议为每个长时程任务设置独立的 token 预算和超时阈值，超出后自动终止。宁可让任务失败，也不要让它在一个错误方向上消耗大量资源。

7.5 安全与合规边界

长时程任务一旦涉及自动操作外部系统，就需要特别谨慎。自动发送邮件、自动提交订单、自动删除数据、自动修改权限，这些行为必须经过确认。系统应该支持权限分级，Agent 默认没有高危操作权限。日志审计建议至少保留一个完整执行周期，以便出问题时追溯。

8. 总结与下一步

回到最初的问题：长时程任务是不是笑话？从行业演示来看，它还没有完全脱离“笑话”的风险；从技术拆解来看，主要瓶颈不是模型智商，而是错误累积、上下文一致性、工具调用稳定性、评估体系缺位这四个工程问题。任何一个环节解决到生产级水平，长时程任务的价值都会大幅提升。

对正在做 Agent 开发和选型的人来说，最近这段时间最值得做的事不是追新模型，而是回到业务本身，把一个 3 到 5 步的真实任务做成稳定闭环。然后加上轨迹日志、失败样本库、回归测试，再逐步扩展任务长度。整个过程里，保持对“最终完成率”的警惕，多关注首步正确率、中段纠错率和平均重试次数。数据不会骗人，它能告诉你这个 Agent 到底能不能扛长时程任务。