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 应用能不能交付的胜负手。 长时程任务为何难？AI Agent工程化落地指南
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 应用能不能交付的胜负手。