我们内部跑一个“自动竞品调研”Agent，流程只有四步：①搜索行业报告 ②提取关键数据 ③生成对比表格 ④输出策略建议。前三步的成功率看起来很美——单步都在90%左右。但把四步串起来，端到端跑通率直接跌到65%。如果拉到十步，按(0.9)^10计算，成功率只剩35%。这才是多步任务在第三步前后崩塌的数学真相：错误在累积，只是前两步刚好被你忽略了。
人类做长任务时，脑子里有个持续更新的待办清单。但LLM Agent没有，它只有上下文窗口里的历史消息。我们曾在32k上下文模型的Agent上观测到一个典型现象：任务进行到第20步时，System Prompt加上工具返回的JSON，已经占去近8k token；再叠加前19轮的对话历史，留给当前推理的可用空间被严重挤压。更隐蔽的是“状态漂移”——Agent在第五步认定的“主要竞品”，到第十步因为早期上下文被压缩或摘要失真，竟然把名字写错，导致后续分析全部跑偏。没有显式的状态机或外部记忆模块，Agent的行为就像沙滩上的字，浪一打就模糊。
很多团队低估了长程任务的上下文消耗。假设每步Agent平均生成500 token，工具返回平均800 token，十步下来就是13k token。再加上System Prompt和各种模板，32k窗口看似宽裕，实则很快触顶。一旦触顶，就要靠滑动窗口或摘要来“腾地方”。我们实测过，简单的滑动窗口丢弃早期轮次，会让Agent在需要回溯原始需求时完全抓瞎；而粗粒度摘要则容易漏掉关键约束——比如用户最初要求的“预算上限不能超过50万”，在摘要里被压缩成“注意预算”，Agent在后续调用采购工具时直接越过红线。
Agent调用外部工具时，失败是常态而非意外。搜索引擎API可能在第三步超时，数据库查询返回了空结果，代码执行器抛出了未捕获的异常。最危险的是“重试风暴”：我们有个Agent在调用第三方财务数据接口时，因为对方限流，连续三次重试均失败，每次间隔指数退避（1秒、2秒、4秒），但Agent没有外部记忆记录这次失败，第四步又触发新一轮调用，最终把API配额打满，整个流程卡死。没有失败标记和冷却机制的重试，只是把崩溃延迟了30秒。
要让Agent跑完长流程，不能指望模型本身变聪明，得在工程层做兜底。
Checkpoint（检查点）：我们在每完成一个逻辑单元（比如“数据收集完毕”或“单份报告生成”）后，把当前状态——包括记忆摘要、已确认的中间结果、待办队列——序列化写入外部存储（如Redis或S3）。这不是简单的日志，而是可供恢复的“快照”。一旦后续步骤失败，不需要从头再来，而是回到上一个Checkpoint。实测中，这能把十步任务的平均重跑成本从10步降到2.3步。
回滚（Rollback）：Checkpoint的真正价值在于回滚。我们设计了一个策略：当工具连续失败超过阈值（比如2次），或LLM输出置信度评分（基于自洽性采样）低于0.6时，自动触发回滚到上一个稳定状态，并尝试换用备用工具或调整提示词。这比让Agent在错误状态上继续“硬撑”要可靠得多。
可观测性（Observability）：长程Agent必须是“白盒”。我们在每个Step里注入结构化日志，记录：当前目标、占用token数、工具调用耗时、返回值摘要、以及Agent的自我评估（如“我认为这一步完成了80%”）。这些指标汇聚到一个时间线视图里，运维人员一眼就能看出崩溃发生在哪一步、当时Agent的上下文还剩多少、工具返回了什么异常。没有这些，定位“第三步崩了”需要逐行翻日志，耗时从5分钟变成2小时。
人工接管（Human-in-the-loop）：再完美的自动化也有边界。我们在关键决策点（如“是否发送邮件”、“是否批准采购”）和置信度极低时，强制暂停Agent，把当前状态摘要推送给人类审核。界面显示的不是原始JSON，而是人话总结：“Agent已对比3家供应商，倾向选A，理由是XX。上下文剩余token：4200。是否继续？”人类点确认或修改后，Agent带着新指令恢复执行。这个机制让我们的生产环境Agent，在20步以上的复杂流程里，端到端完成率从不到40%提升到了87%。
多步Agent的崩溃很少是单一原因造成的，而是状态丢失、错误累积、上下文爆炸和工具脆弱性的叠加效应。与其在Prompt里反复叮嘱“请认真思考”，不如承认LLM的固有局限，用Checkpoint保存进度、用回滚控制错误扩散、用可观测性照亮黑盒、用人工接管守住最后防线。让Agent跑完长流程，靠的不是模型的“意志力”，而是工程上的冗余设计。
