1. 背景：一边是“长时程任务是个笑话”，一边是 Agent 狂奔
最近，知名投资人 Chamath Palihapitiya 在一场公开讨论中给出了一段相当尖锐的判断：当前 AI 在长时程任务上仍然“是个笑话”，行业接下来会进入幻灭低谷。
这句话很快在技术圈传开。原因很简单，它戳中了大量开发者的真实体感：Demo 里的 AI Agent 看起来很聪明，能拆解需求、调用工具、生成代码。可一旦让它独立完成一个需要几小时、几十步、跨多个系统的真实任务，它就会开始“犯迷糊”——忘记上下文、重复调用、偏离目标、把中间结果写错，最后需要人全程盯着纠正。
这不是某个模型的问题，而是整个长时程任务范式还没有被真正解决。
本文不打算停留在观点层面，而是从技术角度拆解：为什么长时程任务这么难？幻灭低谷意味着什么？更重要的是，如果我们要把 AI Agent 用在实际工程里，应该怎么设计任务、怎么控制流程、怎么评估效果。
适合的读者包括：
- 正在做 AI Agent 应用开发的工程师。
- 想用 AI 自动化办公流程，但发现效果不稳定的产品经理。
- 对大模型技术趋势感兴趣，想区分“宣传”和“工程现实”的开发者。
- 需要向团队解释“为什么 Agent 不能全自动跑起来”的技术负责人。
读完本文，你会理解长时程任务的核心瓶颈，掌握一个可落地的最小任务控制框架，并拿到一份在真实项目中值得收藏的排查清单。
2. 为什么长时程任务这么难：技术拆解
Chamath 说“长时程任务仍是笑话”，这句话如果翻译成技术语言，其实是在说：当前大模型在长距离任务依赖上的可靠性远未达标。
2.1 错误累积：一步错，步步错
短任务之所以表现不错，是因为模型只需要在有限的几步内保持正确。例如“把这段英文翻译成中文”“总结这篇文章的要点”，错误空间很小。
长时程任务完全不同。假设一个任务包含 20 个步骤，每一步模型有 95% 的概率做对，表面上已经很高了，但 20 步之后整体成功率大约是：
[ 0.95^{20} \approx 0.358 ]
也就是说，即使每一步都很稳，整条任务链的成功率也只有三成多。如果每一步的成功率降到 90%，最终成功率只剩约 12%。
这就是为什么 Agent 在演示中表现惊艳，一到真实长任务就崩盘。它不是某一步突然变傻，而是错误以指数级速度累积。
2.2 上下文窗口不等于长期记忆
很多人误以为“上下文越长，Agent 越能记住任务”，这是当前最典型的误区之一。
上下文窗口解决了“能不能容纳更多 token”的问题，但并没有解决“模型能否有效利用这些 token”的问题。当上下文中塞入几十轮工具调用记录、中间结果、用户原需求、各种报错信息后，模型很容易出现：
- 注意力分散，忽略早期关键指令。
- 把旧的中间结果当作最新状态。
- 在长上下文中重复生成相似的错误决策。
- 上下文接近上限后，被迫截断或压缩，丢失关键信息。
所以，工程上不能单纯依赖“加大窗口”来解决长时程任务，而是需要设计外部记忆机制，让模型只关注当前步骤真正需要的状态。
2.3 工具调用的不确定性与环境反馈
真实业务场景中，Agent 要操作的不只是文本，还有数据库、API、文件系统、浏览器、消息队列等外部系统。这意味着：
- 每个外部系统都可能返回意料之外的格式。
- 一次 API 调用可能超时、限流、返回脏数据。
- Agent 认为自己“已经执行成功”，但实际写入失败。
- 外部系统状态发生变化，导致 Agent 的下一步决策基于过期信息。
这类问题的本质是：大模型是一个概率系统，而业务系统要求确定性。两者之间需要一个工程层来弥合，而不是把模型直接暴露给所有外部工具。
2.4 评测指标的缺失：没有标准答案的长任务
短任务很容易评测：翻译质量可以对比参考译文，分类任务可以算准确率。长时程任务则完全不同：
- 达到同一目标可能有多种路径，没有标准答案。
- 结果正确但过程低效，算不算成功？
- 过程中出现了错误，但最终自动纠正了，应该加分还是扣分？
- 如何衡量“自主性”？用户只给了 1 次提示，还是 10 次？
目前业界还没有统一的评测方案，这也是长时程任务研究进展缓慢的原因之一。没有好的评测，就没有办法客观比较不同 Agent 方案的优劣，只能靠人工抽检。
3. 幻灭低谷：AI 周期中的真实拐点
“幻灭低谷”这个词来自技术成熟度曲线（Hype Cycle），它描述了一项技术从“期望膨胀期”跌入“泡沫破裂低谷期”，再逐步爬向“稳步爬升复苏期”的过程。
3.1 AI 正在经历典型的期望回调
过去两年，大模型的进展被资本市场和公众舆论放大了。尤其是 GPT-4 之后，行业里充斥着“AI 即将取代程序员”“Agent 将全面替代人工操作电脑”的声音。
但真正动手做工程的人会很快发现：
- 模型在公开 Benchmark 上得分很高，到私有业务数据上表现明显下降。
- AI 编程助手能补全代码，但在大型遗留系统里经常提出不兼容的修改方案。
- AI Agent 可以完成简单工单，但无法独立承担跨部门、跨系统的完整业务流程。
这些体验上的落差，就是幻灭低谷的典型表现。它不是某个人的悲观，而是技术从“实验室惊艳”走向“生产环境拷打”时的必经阶段。
3.2 哪些方向正在进入低谷
从过去一段时间的讨论热度来看，以下方向最容易被过度宣传，也最容易让实践者产生落差：
| 方向 | 宣传预期 | 实际工程现状 |
|---|---|---|
| AI Agent 全自动办公 | 告诉它一句话，它把整个流程跑完 | 只能处理流程清晰、工具稳定、异常少的场景 |
| AI 编程 | 完全替代程序员 | 更像是“高智商结对编程实习生”，仍需要人审查 |
| 长时程任务自动化 | 批量自主完成跨系统业务 | 步骤一多，可靠性和成本都不可控 |
| AI 搜索 | 替代传统搜索引擎 | 能整合信息，但仍有幻觉和时效性问题 |
这里并不是否定这些方向的价值，而是想提醒：低谷期并不代表技术失败，它代表技术开始被真实需求重新筛选。
3.3 低谷期的正面意义：回归工程化
幻灭低谷最大的好处，是倒逼行业从“追热点”回到“解决具体问题”。
当所有人都在夸 Agent 时，很少有人讨论错误恢复机制、成本控制、权限边界、可观测性。但当一个项目真正要上线时，这些才是生死线。低谷期会淘汰掉那些只靠演示视频拿融资的产品，留下能处理真实业务复杂度的方案。
对开发者个人来说，现在正是沉下心做技术积累的好时机。等到技术成熟曲线上行时，具备工程化能力的人会比只会调 API 的人更有竞争力。
4. 工程视角：如何把长时程任务从“笑话”变成“受控流程”
在模型能力短期内不会有质的飞跃的情况下，工程上的核心思路是：不要指望模型自发地完成长任务，而是把长任务拆成短任务的组合，并用代码控制流程，把不确定性关在笼子里。
4.1 先把任务拆成可以验证的步骤
长时程任务之所以难，是因为没有人知道“中间完成到哪一步了”。工程化的第一步，就是让每一步都有明确的输入、输出和验证标准。
例如，“自动整理销售周报”这个任务可以拆成：
- 从数据库读取本周销售明细。
- 调用模型生成周报初稿。
- 人工审核初稿，或通过规则校验数据一致性。
- 生成最终 Markdown 文件。
- 发送到指定邮箱。
每一步都只有一个明确目标。步骤之间通过结构化数据传递，而不是让模型自己维护状态。
4.2 状态机与工作流：比“自由发挥”更可靠
当前 Agent 产品很喜欢强调“自主规划”，但在生产环境里，自由发挥往往意味着不可控。
更务实的方案是：
- 对稳定不变的流程，使用状态机或工作流引擎，每一步都是固定代码。
- 对需要模型发挥的环节，只让模型负责局部子任务，比如生成文案、提取关键信息、判断意图。
- 对可能出现分支的地方，由代码根据中间结果决定下一步，而不是让模型再次“重新规划整个任务”。
简单说，人负责流程，模型负责细节。这比把整个流程交给模型要可靠得多。
4.3 记忆设计：上下文压缩与外部存储
长时程任务需要“记忆”，但记忆不应该全部塞进上下文。常见的工程实践包括：
- 关键信息提取：每一步结束后，从原始输出中提取关键字段，存入外部存储（数据库或文件）。
- 上下文压缩：下一轮请求只携带当前步骤所需的摘要，而不是把全部历史对话都丢给模型。
- 快照与恢复：定期保存任务状态，如果中途失败，可以从最近一个成功节点继续执行，而不是从头再来。
这种设计既降低了 token 成本，也减少了模型的注意力负担。
4.4 可观测性：日志、轨迹回放、成本追踪
长时程任务一旦出错，定位问题会非常痛苦。因此，可观测性不是可有可无的功能，而是上线的必要条件。
具体来说，建议至少记录：
- 每一步的输入与输出摘要。
- 模型调用的 token 消耗与耗时。
- 每次工具调用的请求参数与响应状态。
- 每个分支选择的依据。
- 人工干预的时间和原因。
有了这些数据，才能回答“这个 Agent 为什么失败”“它花了多少钱”“它哪一步开始跑偏”。
5. 从概念到代码：一个最小长时程任务 Agent 骨架
下面用一个最小示例演示“代码控制流程 + 模型处理局部任务”的思路。这个示例不依赖任何重型框架，只需要 Python 和一个大模型 API，方便你理解核心思想。
5.1 项目结构与依赖
long_task_demo/ ├── main.py # 入口，负责编排流程 ├── tasks.py # 定义各个任务步骤 ├── memory.py # 简单的上下文记忆管理 └── llm_client.py # 大模型调用封装依赖建议使用 Python 3.10+，大模型方面你可以按需选择 OpenAI 兼容接口或本地部署的模型。核心不依赖特定 SDK，用requests或openai库都可以。
5.2 用有限状态机控制任务流程
我们先定义一个最简状态枚举和节点数据结构。
# 文件路径：long_task_demo/tasks.py from enum import Enum class TaskState(str, Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" FAILED = "failed" NEEDS_REVIEW = "needs_review" class TaskNode: """表示长任务中的一个步骤""" def __init__(self, name: str, executor, retry_times: int = 2): self.name = name self.executor = executor # 一个可调用对象，接收 context 并返回结果 self.state = TaskState.PENDING self.retry_times = retry_times self.result = None self.error = None这里的关键点是：每一步都被包装成一个TaskNode，执行器可以是普通 Python 函数，也可以是调用大模型的函数。流程控制逻辑与模型调用解耦。
5.3 执行工具与状态保存
接下来实现一个简单的执行器。它依次执行任务节点，每个节点失败时可以重试，并支持暂停到“人工审核”状态。
# 文件路径：long_task_demo/main.py from tasks import TaskNode, TaskState class TaskRunner: def __init__(self, nodes: list[TaskNode], memory: dict): self.nodes = nodes self.memory = memory def run(self): current = 0 while current < len(self.nodes): node = self.nodes[current] node.state = TaskState.RUNNING print(f"[执行] {node.name}") success = False for attempt in range(node.retry_times + 1): try: node.result = node.executor(self.memory) node.state = TaskState.SUCCESS # 每步结束后，把关键结果写回 memory，供后续步骤使用 self.memory[node.name] = node.result success = True break except Exception as exc: node.error = str(exc) print(f"[重试] {node.name} 第 {attempt + 1} 次失败: {exc}") if not success: node.state = TaskState.FAILED # 我们可以在这里决定：中断任务，或者进入人工审核 print(f"[失败] {node.name}，任务终止") return False current += 1 print("[完成] 所有步骤执行结束") return True这个TaskRunner非常简单，但它具备了长时程任务控制的核心能力：
- 步骤之间通过
memory传递结构化数据。 - 每一步独立执行，失败可以重试。
- 失败后可以选择中断，便于人工介入。
- 没有把所有历史步骤都塞给模型，只传递当前需要的上下文。
5.4 模拟一个真实的长任务
为了验证这个骨架，我们模拟一个“整理周报并发送提醒”的三步流程：
- 调用大模型生成周报摘要。
- 用规则校验数据是否完整。
- 模拟发送。
# 文件路径：long_task_demo/main.py（续） def step_generate_report(memory: dict): # 实际项目中，你可以在这里调用大模型 API # 这里用固定返回值模拟，方便测试流程 report = "本周销售额 120 万，环比增长 5%，重点客户 A 续约完成。" if not report: raise ValueError("模型返回为空") return report def step_validate_report(memory: dict): report = memory.get("step_generate_report", "") if "销售额" not in report: raise ValueError("报告缺少销售额字段，校验失败") return {"valid": True, "report": report} def step_send_notification(memory: dict): # 模拟发送动作 report = memory["step_validate_report"]["report"] print(f"[发送] 邮件内容：{report}") return {"sent": True} if __name__ == "__main__": nodes = [ TaskNode("step_generate_report", step_generate_report), TaskNode("step_validate_report", step_validate_report), TaskNode("step_send_notification", step_send_notification), ] runner = TaskRunner(nodes, memory={}) runner.run()运行结果：
[执行] step_generate_report [执行] step_validate_report [执行] step_send_notification [发送] 邮件内容：本周销售额 120 万，环比增长 5%，重点客户 A 续约完成。 [完成] 所有步骤执行结束如果某一步失败，例如step_generate_report返回了空字符串，你会在控制台看到重试日志和最终中断信息。
5.5 这个骨架为什么值得保留
上面的示例虽然离生产级还有距离，但它演示了长时程任务工程化的最关键转变：把任务的可靠性从“模型自由发挥”转移到了“代码流程控制”上。
在这个架构下，模型只需要保证单步输出质量，步骤间的依赖关系、失败恢复、状态传递都由代码负责。即使模型能力没有提升，整体任务的稳定性也会明显改善。
6. 常见问题与排查思路
6.1 Agent 在长任务中“失忆”
现象：任务执行到中后期，Agent 忘记用户最初的要求，或者使用了已经过期的中间结果。
原因：上下文被大量中间日志和工具返回占满，模型注意力被稀释。
排查思路：
- 查看每一步发送给模型的完整 prompt，确认里面是否包含最新必要信息。
- 检查是否把历史全量塞入上下文，而不是使用摘要。
- 确认外部存储中的状态是否及时更新。
解决方案：使用外部记忆存储关键字段；每轮只传递当前步骤相关的摘要；定期压缩历史记录。
6.2 同一个调用反复失败
现象：Agent 对某个工具调用失败后，不做任何调整，原样重试多次。
原因：Agent 缺少错误分析逻辑，或者错误信息没有真正传递给它。
排查思路：
- 查看失败响应体，确认是参数错误、鉴权失败还是超时。
- 检查 Agent 是否能看到上一步的完整报错，而不是只看到“调用失败”。
解决方案：在工具调用层增加参数校验；将错误信息结构化为“错误类型 + 建议动作”，供模型参考；设置最大重试次数，避免死循环。
6.3 任务中断后无法恢复
现象：任务执行到第 15 步时进程崩溃，重跑一次又从头开始，浪费大量 token。
原因：没有任务快照机制，每一步的结果没有持久化。
排查思路：
- 确认每步结果是否写入数据库或文件。
- 检查任务启动时是否能从已有快照继续执行。
解决方案：增加任务状态持久化；启动时读取快照；将断点续跑作为长时程任务的默认能力。
6.4 成本失控
现象：长任务执行一次消耗大量 token，比人工操作还贵。
原因：不必要的历史信息反复传输；失败重试消耗额外 token；缺少单次任务的成本预算。
排查思路：
- 在日志中统计每步的 token 消耗。
- 找出 token 消耗最高的步骤，判断是否可以通过精简 prompt 优化。
解决方案：限制单任务最大 token 数；使用更便宜的模型处理简单步骤；开启上下文压缩；设置预算熔断。
6.5 评测指标不统一
现象：同一个 Agent，不同人测试得到完全不同的结论，无法判断是否改进。
原因：缺少固定的评测集和成功标准。
排查思路：
- 为任务定义可量化的成功标准，例如“是否生成合法文件”“是否调用指定接口”。
- 对无法自动判断的标准，设计人工评分表。
- 固定测试任务集合，每次修改后跑同一组用例。
解决方案：把评测用例纳入版本管理；接入 CI 流程；每次改动后自动回归测试。
7. 给开发者的实践建议
7.1 不要一开始就追求“全自动”
很多人做 Agent 项目，第一版就想做成全自动。实际上，更推荐的做法是设计成“机器干活，人盯关键节点”。
- 任务自动执行到某个决策点，停下来等人工确认。
- 关键输出先由规则校验，再决定是否放行。
- 涉及外部系统写入的操作，默认采用审批模式。
这样既保留了效率提升，也为早期系统的不可靠留出了兜底空间。
7.2 把评估放进 CI
模型应用最怕“凭感觉优化”。建议把一组固定任务作为回归用例，每次修改 prompt、调整模型或重构流程后，都跑一遍。
评估维度至少包括：
- 任务成功率。
- 平均 token 消耗。
- 平均执行时长。
- 人工干预次数。
- 错误恢复成功率。
这些指标可以量化地告诉你：这次改动到底是在变好还是变坏。
7.3 成本与延迟的边界设计
长时程任务在生产环境中，成本不是“可选优化”，而是“硬约束”。
建议在系统层面增加控制：
# 伪代码：任务运行前设置预算上限 task_budget = { "max_steps": 30, "max_token": 200_000, "max_retry": 3, "max_runtime_seconds": 1800, }一旦超出边界，任务自动暂停并通知人工处理。预算控制应该放在流程层，而不是依赖模型自行判断“是否该停止”。
7.4 安全与权限的最小化
Agent 能调用越多工具，风险就越大。务必遵守最小权限原则：
- 只授权完成任务所需的最小 API 权限。
- 涉及删除、覆盖、转账等高风险操作时，必须人工二次确认。
- 所有外部操作的请求日志和响应日志完整保存。
- 在测试环境中充分验证后，再逐步放开生产权限。
没有权限边界的 Agent，本质上是一个不可控的“内鬼候选者”。
7.5 关注可解释性
长时程任务一旦出错，你需要能回答三个问题：
- 它当时打算做什么？
- 它基于什么信息做了这个决定？
- 为什么结果和预期不一致？
这要求系统记录每一步的决策依据。对大模型步骤，至少要保存当时的 prompt 摘要和模型返回原文；对工具步骤，要保存入参出参和时间戳。
没有这些记录，你无法对 Agent 系统做迭代，只能“重启再试”。
8. 总结：低谷期正是工程化最好的窗口
回看 Chamath 的观点，“长时程任务仍是笑话”这句话，与其说是唱衰 AI，不如说是在提醒所有人：当前行业最缺的不是“更强的模型”，而是“能让现有模型稳定完成复杂任务的工程能力”。
幻灭低谷并不恐怖。它滤掉的是概念泡沫，留下的是真实需求。未来能跑出来的产品，大概率不是“让 AI 自己搞定一切”的激进派，而是那些把任务拆细、把流程控稳、把错误管好、把成本算清的系统工程派。
如果你正在做 Agent 相关项目，建议从今天开始做三件事：
- 找一个真实的长任务，把它拆成有明确输入输出的短步骤。
- 为每一步加上验证、重试和日志。
- 用固定的评测集记录每次改动的效果。
这个过程中你会发现：模型的能力边界是客观存在的，但工程能力的高低，才是最终决定一个 AI 应用能不能交付的胜负手。
