企业官网建设流程全解析

最近关于 AI 行业阶段的一个判断引发了不少讨论：Chamath 认为长时程任务仍然是笑话，AI 即将进入幻灭低谷。这个判断听起来刺耳，但放到实际工程里并不全是情绪发泄。过去一年里，AI Agent 的演示视频确实惊艳，但真正把 Agent 放到生产环境处理多步骤任务的人，大概率都遇到过任务跑一半就停、错误不断累积、上下文被污染的情况。长时程任务不是“把 Prompt 写长一点”就能解决的，它涉及模型能力、状态管理、工具调用、评估体系和容错机制等多个层面的工程问题。

本文从工程视角拆解这个观点。先说明长时程任务到底是什么，再分析它为什么容易失败，然后提供一个不依赖外部大模型 API 的最小沙盘实验，用来复现“任务步骤变多后成功率下降”的过程。最后讨论幻灭低谷对 AI 工程投入节奏的影响，以及团队和个人开发者可以从哪些方向提高长时程任务的成功率。

1. 先理解“长时程任务”在 AI 工程里到底指什么

1.1 从单轮问答到多步执行：AI 能力维度的变化

传统的大模型应用形态是单轮问答：用户输入问题，模型输出答案。这个过程的反馈循环很短，输入和输出在同一个会话里完成，即使模型说错，用户也能立刻发现并重新提问。

长时程任务不同。它要求模型在多个步骤之间保持目标一致，持续操作外部系统，并且在中间结果不符合预期时自行调整。典型场景包括：

• 从数据库读取数据，经过清洗、转换、去重后再写入目标表。
• 根据需求文档生成代码，编译、运行测试、修复报错、再次运行。
• 自动化处理一批工单，每张工单需要查询信息、调用接口、确认结果、记录日志。
• 把一个跨系统的数据迁移任务拆成多个阶段，每个阶段都要校验上一阶段的输出。

这些任务的共同点是：模型不能只生成一段文本，它必须在一个闭环里完成“理解状态、决定动作、观察结果、修正下一步”的循环。这个循环每多转一圈，系统的不确定性就会增加一分。

1.2 长时程任务的三个典型技术特征

判断一个任务是不是长时程任务，可以看三个特征。

第一，步骤数量多。任务被拆成多个子步骤，子步骤之间存在依赖关系，后一步要依赖前一步的输出。步骤越多，链条越长。

第二，外部反馈延迟。模型调用工具后，结果不会立刻变成可用的最终答案，需要解析返回值、判断是否成功、决定是继续还是重试。这个反馈过程可能涉及网络请求、文件读写、数据库事务，甚至需要等待人工审批。

第三，状态需要持久化。Agent 在执行过程中不能只靠模型上下文记住“做到哪一步”，因为上下文会溢出，也会被中间日志污染。状态必须存放在可查询、可回滚的结构化位置。

如果某个任务只是“写一封邮件草稿”，它仍然是短时程任务。如果这个任务是“把 200 个客户按规则分层，生成个性化邮件，发送前经过审批，发送后记录送达状态”，它就已经进入了长时程任务范畴。

1.3 为什么演示视频会高估 Agent 的能力

演示视频通常经过精心剪辑。视频里的 Agent 可能只跑了一次成功路径，没有展示失败重试、上下文污染、工具返回异常和人工介入的过程。观众看到的是“点一下按钮，任务自动完成”，但工程上真正难的是那些没有出现在视频里的分支情况。

这种现象并不只在 AI 领域存在，任何自动化系统在演示时都会选择最优路径。但大模型 Agent 有一个特殊问题：它的每一步输出都是概率性的，即使同样的输入、同样的 Prompt，两次运行也可能得到不同结果。演示视频只能证明“这个任务在某种条件下可以完成”，不能证明“这个任务在生产环境里可以稳定完成”。

所以“长时程任务仍是笑话”这个观点，核心指向的是稳定性问题。不是模型不能写代码、不能调工具，而是多步执行下的成功率还没有达到生产可用的标准。

2. 为什么长时程任务容易失败：五个核心瓶颈

2.1 误差累积：小错误到最后被放大

长时程任务最直观的失败原因是误差累积。模型每一步都有一定概率犯错，可能是理解错了输入，可能是生成了错误的工具参数，也可能是把中间结果写错了位置。单步错误率看着不高，但只要任务步骤足够多，整条链路的成功率就会快速下降。

假设每一步的成功率是 95%，5 步任务的总成功率是 0.95 的 5 次方，约 77%。如果任务有 20 步，总成功率降到约 36%。如果每步成功率只有 90%，20 步任务的总成功率只有约 12%。这个指数关系是数学层面的，和模型聪明不聪明没有直接关系。

这也是为什么很多 Agent 在 2 到 3 步的演示里表现良好，一旦进入真实业务场景，几十个步骤连环执行，失败率就变得不可接受。

2.2 上下文窗口不等于决策容量

大模型的上下文窗口越来越长，但长上下文不意味着模型能有效利用所有信息。任务执行过程中，每一步的工具返回、日志、错误信息都要拼进上下文。随着上下文变长，模型需要从大量文本里定位关键状态，注意力分散，出错概率反而上升。

更麻烦的是，上下文里既包含事实状态，也包含推理过程、错误信息、历史动作。模型很难区分“哪一段是最新的真实状态”和“哪一段只是我之前的猜测”。一旦模型基于过期状态做决策，后续步骤就会建立在错误地基上。

上下文窗口解决的是“能不能容纳”的问题，工程上还需要解决“该把什么放进去”的问题。长时程任务里，正确做法不是把所有历史都塞给模型，而是只把当前步骤需要的结构化状态和少量必要上下文传给模型。

2.3 工具调用和状态管理没有统一契约

Agent 要完成长时程任务，几乎必须调用外部工具：查数据库、写文件、调接口、执行命令。每个工具都有自己的参数格式、返回结构和错误语义。Agent 框架如果只是把工具描述拼进 Prompt，让模型“自由发挥”，很容易出现参数缺漏、类型错误、返回解析失败。

例如一个工具返回 JSON，正常情况包含status字段，失败情况可能返回error字段。模型如果只用status判断成功，就可能把失败请求当成成功。工具调用层需要一个统一协议，明确什么算成功、什么算失败、失败后应该重试还是终止。

状态管理同样是关键。如果每一步的中间结果只是字符串拼接，下一步就很难判断前一步是否真的完成。结构化状态应该包含步骤编号、输入快照、输出快照、校验结果、执行时间、重试次数等字段，让 Agent 和运维人员都能看清当前进度。

2.4 自我修正机制本质上是概率性的

很多 Agent 框架宣称具备自我修正能力：模型发现错误后，读取错误信息，重新规划，再次尝试。这个机制听起来很合理，但实际执行时存在两个问题。

第一，模型不一定能正确识别错误。有时工具已经返回了明确异常，模型仍然按照原计划继续执行，把异常信息忽略掉。第二，重新尝试可能产生新的错误。模型可能修正了参数格式，却又在下一步选择错误分支。自我修正在短路径上有效，在长路径上会变成新的不确定性来源。

工程上不能把“自我修正”当作默认能力。更稳妥的做法是给 Agent 设置最大重试次数，每步执行后强校验输出，校验失败就进入预设的修复流程，而不是让模型自由发挥。

2.5 任务完成度的评估本身很困难

短时程任务容易评估，答案是 A 还是 B，一眼就能判断。长时程任务不同，任务的最终结果可能是“数据已迁移”“代码已部署”“工单已处理”，但“处理完成”的标准很难形式化。

比如“把 200 个客户分层并发送邮件”，成功的标准是什么？是接口全部返回 200，还是每一封邮件都被客户打开？显然不能混为一谈。没有明确的完成标准，Agent 就无法判断自己是否已经完成，也就无法决定何时停止。很多 Agent 任务失败不是模型能力不足，而是目标定义不清楚，系统在错误的方向上反复执行。

3. 用最小沙盘实验复现“长时程任务翻车”

3.1 实验目标：不依赖外部大模型也能看到失败率曲线

为了验证“步骤越多，成功率越低”这个判断，我们构建一个最小沙盘实验。它不调用任何外部大模型 API，也不依赖网络，只用一个模拟模型来模拟每一步可能出现的执行错误。

这个实验的价值有两个。第一，它把长时程任务的失败原因压缩成最核心的“单步错误率”和“任务步数”两个变量，方便观察趋势。第二，它可以作为真实 Agent 系统的简化模型，后续可以替换成真实模型和真实工具，复用同样的成功率和排查思路。

3.2 项目结构与核心类设计

项目只需要一个 Python 文件，包含四个核心对象：

• Step：描述一个子步骤，包括步骤名、输入键、输出键。
• RandomModel：模拟不稳定的大模型，以固定概率返回错误。
• Task：按顺序执行步骤列表，更新状态，记录执行轨迹。
• simulate：多次运行任务，计算成功率。

这种设计与真实 Agent 框架的抽象方向一致：真实框架里的Agent相当于Task，LLM相当于RandomModel，外部工具相当于步骤里的输入输出映射。区别只是真实模型的错误率不是均匀分布，而是与任务难度、Prompt 质量、工具设计相关。

3.3 完整可运行代码

下面是完整的沙盘实验代码，保存为long_horizon_sandbox.py。

# long_horizon_sandbox.py import random from dataclasses import dataclass from typing import Dict, List, Tuple @dataclass class Step: name: str input_keys: List[str] output_key: str class RandomModel: """模拟不稳定的大模型：以固定概率产生错误。""" def __init__(self, error_rate: float = 0.2): self.error_rate = error_rate def complete(self, step_name: str, input_data: dict) -> dict: if random.random() < self.error_rate: return { "status": "error", "message": f"model failed at {step_name}", } return { "status": "ok", "data": {"value": input_data.get("value", 0) + 1}, } class Task: def __init__(self, steps: List[Step]): self.steps = steps def run( self, model: RandomModel, initial_state: dict ) -> Tuple[bool, dict, List[str]]: state = dict(initial_state) trace = [] for step in self.steps: input_data = {k: state.get(k) for k in step.input_keys} output = model.complete(step.name, input_data) trace.append(f"{step.name}: {output}") if output["status"] != "ok": return False, state, trace state[step.output_key] = output["data"] return True, state, trace def build_n_step_task(n: int) -> Task: steps = [] for i in range(1, n + 1): input_key = "state_0" if i == 1 else f"state_{i - 1}" steps.append( Step( name=f"step_{i}", input_keys=[input_key], output_key=f"state_{i}", ) ) return Task(steps) def simulate(task: Task, model: RandomModel, trials: int = 1000) -> float: success = 0 for _ in range(trials): ok, _, _ = task.run(model, {"state_0": {"value": 1}}) if ok: success += 1 return success / trials if __name__ == "__main__": random.seed(42) for step_count in [3, 5, 8, 12]: task = build_n_step_task(step_count) model = RandomModel(error_rate=0.1) rate = simulate(task, model) print(f"steps={step_count}, error_rate=0.1, success_rate={rate:.2%}") for error_rate in [0.0, 0.1, 0.2, 0.3]: task = build_n_step_task(5) model = RandomModel(error_rate=error_rate) rate = simulate(task, model) print(f"steps=5, error_rate={error_rate}, success_rate={rate:.2%}")

运行方式：

python long_horizon_sandbox.py

这段代码没有使用真实大模型，但它完整复现了长时程任务的执行链路：每个步骤读取前一步的输出，经过一次模型调用后写入新的状态，只要任一步返回错误，整个任务就终止。

3.4 运行结果与结果解读

由于代码中设置了random.seed(42)，运行结果具有可重复性。理论上的成功率同样可以手算：如果单步错误率是 0.1，单步成功率是 0.9，N 步任务的总成功率约等于 0.9 的 N 次方。

• 3 步任务，理论成功率约 72.9%。
• 5 步任务，理论成功率约 59.0%。
• 8 步任务，理论成功率约 43.0%。
• 12 步任务，理论成功率约 28.2%。

如果把单步错误率提高到 0.2，5 步任务的理论成功率约 32.8%；提高到 0.3，约 16.8%。

这个结果说明两个问题：

第一，即使模型单步表现已经不错，任务步数一旦增加，整体成功率也会显著下降。长时程任务失利不一定是“模型太笨”，更可能是任务被拆得太长，而每一步的误差没有得到及时拦截。

第二，真实系统的成功率不可能只靠 Prompt 提升。需要在每一步加入校验、重试、状态回滚和人工审批，把单步错误对最终结果的影响降到最低。

3.5 参数变化对成功率的影响

这个沙盘里的error_rate可以理解为“模型在当前任务上的单步失败概率”。不同任务、不同 Prompt、不同工具设计下，这个值差别很大。

这张表给工程实践提供了一个重要启示：长时程任务的第一优先级不是让模型更聪明，而是降低每一步的失败率，并且控制任务步数。如果一个任务必须经过 20 步，即使单步失败率只有 5%，最终成功率也只有约 36%，这个水平在生产环境通常不可接受。

4. “幻灭低谷”对 AI 工程投入意味着什么

4.1 技术成熟度曲线里的位置判断

“幻灭低谷”来自技术成熟度曲线，它描述一项新技术从被过度关注到回归理性、再到逐步成熟的过程。曲线大致经历五个阶段：技术触发、期望膨胀顶峰、幻灭低谷、启蒙斜坡、生产力平台。

过去两年，AI Agent、AI 编程、AI 应用开发这些方向获得了大量关注。演示视频里，Agent 可以自动写代码、自动操作浏览器、自动处理数据流水线。这些内容把市场期望推到了很高位置。但当开发者和企业真正把 Agent 接入业务系统后，会发现长时程任务的稳定性不足、评估困难、维护成本高，于是期望开始回调。Chamath 判断 AI 将进入幻灭低谷，本质上是在说：当前的能力已经被高估，接下来会进入一段失望和理性调整期。

这个判断是否成立，需要观察具体技术方向的表现。但有一点是确定的：任何新技术在经历期望膨胀后都会迎来回调，回调不一定代表技术失败，而是说明从业者开始用生产标准重新审视技术。

4.2 学习环境与生产环境的真实差距

讨论 AI 是否进入幻灭低谷，需要区分学习环境和生产环境。学习环境里跑通一个 Agent Demo，通常只需要满足“最终结果看起来对”这一个条件。生产环境则完全不同。

生产环境至少需要额外考虑：

• 配置外置化，不能把 API Key、数据库地址写在代码里。
• 日志和监控，要能回答“这个任务现在执行到哪一步、为什么停在这里”。
• 权限和安全，Agent 能访问的系统资源必须收敛到最小范围。
• 异常处理，工具调用超时、返回异常、数据格式不一致都要有明确策略。
• 回滚方案，中间步骤出错后，如何恢复到一个安全状态。
• 成本控制，每一步模型调用都会产生 token 费用，长任务成本会快速上升。

很多项目在 Demo 阶段看起来很好，但部署到生产环境后失败率飙升，并不是模型能力变了，而是生产环境里的异常分支远多于演示环境。所谓幻灭低谷，很多时候不是 AI 退步了，而是人们的评估标准从“能不能做出来”变成了“能不能稳定地做出来”。

4.3 哪些任务已经落在生产力平台，哪些还在低谷

不同 AI 任务的成熟度差异很大。用“短反馈循环”和“长反馈循环”来区分更实用。

短反馈循环任务包括：单轮问答、文本摘要、代码补全、邮件润色、信息抽取。这些任务的结果可以立即被用户检查，错误成本低，已经在不少产品里进入生产力平台。

长反馈循环任务包括：跨系统数据处理、自动化代码仓库维护、长时间运行的数据迁移、自主决策类业务流。这些任务需要多步执行、状态持久化、异常恢复，当前仍处于工程化早期，失败率较高，可以认为正处在幻灭低谷附近。

这个表并不精确，但它能帮助团队判断：当前不要在长反馈循环任务上给用户过高承诺，而应该优先把短反馈循环任务做扎实，再逐步向长任务延伸。

4.4 团队应该怎样安排 AI 实验预算

面对幻灭低谷的判断，团队容易走两个极端。一个极端是继续追热点，把所有业务都往 Agent 上装，最后被失败率拖垮。另一个极端是觉得 AI 被高估，停止投入，错过真正能落地的地方。

更现实的做法是分级投入。对短反馈循环任务，可以快速试点，因为这些任务验证成本低，失败影响小。对长反馈循环任务，先做小范围沙盘验证，设定明确的成功率指标，再决定是否扩大范围。对底层模型和框架选型，保持抽象接口，不要把业务逻辑和某一家模型绑定太深。

预算安排上，除了模型调用费用，还要留出评估和观测系统成本。长时程任务上线后，真正烧钱的地方往往不是 token，而是排查失败时消耗的人力。一个没有日志、没有状态检查、没有完成度定义的任务，就算模型能力很强，团队也不敢放心让它自动执行。

5. 提高长时程任务成功率的工程手段

5.1 拆短任务：把长时程变成短时程

提高成功率最直接的手段是减少任务步数。把一个大任务拆成多个可以独立运行的短任务，每个短任务只做一件事，做完后把结果持久化，再由编排系统决定下一步。

例如跨系统数据迁移，不要写一个 Agent 让它从头到尾自动执行全部步骤。可以拆成：数据导出、格式校验、数据转换、数据导入、结果核对五个阶段。每个阶段是一个独立的短任务，阶段之间有明确输入输出和校验逻辑。某个阶段失败，只需要重跑该阶段，不需要从头再来。

这个思路的核心是“每个阶段都是可验证的”。短任务容易评估，因为它的输入输出范围小，成功标准清晰。多个短任务通过编排系统连接后，整体仍然是一个长流程，但每一步的失败范围被限制住了。

5.2 结构化状态：不要让 Agent 在文本里找状态

Agent 执行过程中，状态要放在外部，而不是只放在模型上下文里。常见的做法是使用 JSON 或数据库记录状态。

状态对象至少包含这些字段：

{ "task_id": "task_20250101_001", "current_step": "normalize", "steps": [ { "name": "extract", "status": "done", "output_summary": "rows=1000", "finished_at": "2025-01-01T10:00:00Z" }, { "name": "normalize", "status": "running", "attempts": 2, "last_error": "field phone format mismatch" } ], "run_mode": "manual_review_required" }

每一步开始前，从状态对象里读取输入；每一步结束后，立即把输出摘要和校验结果写回状态。这样即使模型上下文被截断或污染，编排系统仍然知道任务真实执行到了哪里。

5.3 阶段门与人工审批

对高风险步骤，不要完全信任自动执行。阶段门是指在关键节点设置检查点，由程序自动校验或由人工确认后，才允许进入下一阶段。

适合设置阶段门的节点包括：

• 数据写入前，先预览影响行数和样例数据。
• 代码合并前，先跑测试和静态检查。
• 邮件或消息发送前，先审阅内容模板。
• 涉及删除、覆盖、权限变更的操作前，必须二次确认。

人工审批会增加延迟，但能显著降低不可逆错误的风险。生产环境通常采用“自动执行 + 关键节点人工审批”的模式，而不是让 Agent 全程无监督执行。

5.4 用校验模型和可观测性兜底

除了执行模型，还可以引入一个独立的校验步骤。校验不一定需要大模型，可以用规则、Schema 校验、断言、单元测试等方式完成。

例如工具返回后，第一层校验检查字段是否存在、类型是否正确、数值是否在合理范围；第二层校验检查业务规则，比如金额大于 0、状态值是否在枚举范围内；第三层校验由规则引擎或小模型完成，比较当前输出和历史模式是否一致。

可观测性同样重要。每个 Agent 任务都要有 trace 日志，记录每一步的输入摘要、输出摘要、模型调用耗时、token 消耗、错误信息。没有这些数据，长时程任务一旦失败，排查就像在迷宫里找路。

5.5 可复用的发布前检查清单

上线一个长时程 Agent 任务前，建议对照这份清单检查：

• 任务是否被拆成多个可独立验证的阶段。
• 每个阶段是否有明确的输入输出 Schema。
• 是否设置最大重试次数和最大执行时长。
• 失败后是否支持从最近一个成功检查点恢复。
• 每个工具调用是否定义了明确的成功和失败判定。
• 关键节点是否有人工审批或自动校验。
• 是否记录了完整的 trace 日志和 token 消耗。
• 是否定义了可量化的完成标准。
• 是否准备回滚方案，数据误操作后能否恢复。
• 生产环境权限是否已收敛到最小范围。

如果这些项目里有多项不满足，长时程任务上线后的失败率大概率会很高。这不是模型问题，而是工程完整度问题。

6. 常见失败模式与排查路径

6.1 长时程 Agent 常见失败现象

以下是生产环境中比较常见的失败现象。

这些现象相互关联。一个任务可能先是上下文被污染，然后 Agent 基于错误状态做决策，最终导致工具调用失败。排查时要沿着执行链路逐步定位，不能只看最后一行日志。

6.2 通用排查链路

排查长时程任务失败，建议按以下顺序进行。

第一步，确认输入是否正确。检查任务启动时传入的初始参数、文件路径、数据库连接。很多失败的根源是输入数据本身不符合预期。

第二步，确认状态是否一致。查看持久化状态对象，确认当前执行到第几步，前一步输出是否已经落库。如果状态对象和日志不一致，优先怀疑状态写入逻辑。

第三步，确认工具调用是否成功。查看工具请求参数、返回结果、超时和重试情况。重点关注返回结构是否和预期一致，错误信息是否在下一轮循环中被正确传递。

第四步，确认模型收到的上下文是否合理。在调试模式下打印发送给模型的消息，检查是否包含了过期状态、重复日志或错误信息。上下文结构问题往往是 Agent 行为异常的深层原因。

第五步，确认失败是否由重试引起。查看单步执行次数，如果某一步已经重试多次仍然失败，说明该步骤存在系统性错误，需要人工介入，而不是继续自动重试。

第六步，确认评估标准是否明确。如果任务“看起来完成了”但结果不正确，回到任务定义层，检查完成标准是否可量化、可验证。

6.3 三个最容易踩的坑

第一个坑是“无脑拼接完整上下文”。很多开发者为让模型记住历史，把每轮工具输出都追加到 Prompt 里。结果上下文越来越长，模型反而找不到关键状态。推荐做法是维护外部状态对象，每次只给模型传当前步骤的输入和少量必要历史。

第二个坑是“用文本判断执行结果”。工具返回 JSON 时，直接让模型从文本里判断成功失败，这种做法非常脆弱。模型可能因为字段位置变化、错误信息措辞不同而误判。推荐做法是在代码层面解析 JSON，用结构化的status字段判断成功失败，只有解析通过后才把结果交给模型。

第三个坑是“没有设置执行边界”。真实模型可能出现死循环，比如反复尝试同一个失败动作，或者在一组相近的参数里来回切换。如果没有最大步数、最大重试次数、总执行时长上限，任务会一直消耗 token，直到预算耗尽。推荐做法是在框架层硬编码执行边界，并由编排系统强制终止。

7. 结论：争议观点如何转化为技术行动

Chamath 关于长时程任务和幻灭低谷的判断，与其把它当成对 AI 的否定，不如把它当成一次工程视角的提醒：长时程任务至今没有被稳定解决，行业正在从盲目乐观转向冷静验证。这对真正做工程的人是好事，因为只有不再追着演示视频做产品，才会有更多精力去解决状态管理、评估体系、容错机制这些基础问题。

如果长时程任务一直做不好，AI 的应用边界就会被限制在短反馈循环里。与其争论会不会进入幻灭低谷，不如先用一个小沙盘把失败率测出来，再去决定应该在哪个环节投入工程资源。下一步可以先跑通上面的实验，然后把同样的指标应用到真实 Agent 任务里，记录单步失败率、总成功率和失败原因分布。有了这些数据，再回头看“长时程任务是不是笑话”这个问题，就会得到一个比情绪判断更有价值的答案：它不是不能做，而是需要更严格的工程手段才能做稳。