你让 Agent 跑一个二十步的任务它在第 17 步崩了前面 16 步全白干——因为状态没记下来。大多数人还在把全部步骤塞进同一个 prompt赌它一次跑通。但回头看这种崩法暴露的不是一个模型能力问题而是一个方法问题长任务 Agent 失败的主因不是模型不够强而是「不拆分、不回滚、不叫停」。想让 Agent 跑通多步任务先别急着换更强的模型——把「大任务拆成原子子任务 每步留回滚 高风险动作前必有人确认」三件事做对收益比换模型更实在。长任务链为什么脆弱大模型的非确定性输出让同样的输入可能给出不同回答导致工作流在某个环节随机失败。更麻烦的是长链脆弱性一个十几步的任务任一步失败整条链就崩溃。第一招拆成原子子任务 检查点回滚把大任务拆成尽可能独立的原子子任务每完成一个就把结果和状态持久化写进数据库进程重启也能从断点续跑而不是从头来。每个可能失败的工具调用后设检查点失败就按错误类型选择重试、跳过或执行预定义的补偿回滚。文件操作建议用版本控制如果验证失败就回滚到上一个稳定态。第二招关键节点留给人工验收删除、外发邮件、生产部署、数据库迁移等高风险动作设「人工审核」节点——流程暂停、通知人介入确认这是安全性的最后防线。有团队对比过让 Agent 直接改核心配置出错率显著高于让它只生成 Diff 补丁供人 Review——因为大模型擅长局部模式匹配不擅长全局一致性校验。所以高危动作前宁可多一次点击也别让 Agent 自动冲。第三招主代理—子代理—人工验收三层 Task Contract更稳的结构不是让多个子代理直接把结果推上生产而是主代理负责拆分和汇总 → 子代理分别分析、实现、验证 → 开发者做人工验收 → 确认后再合并。启动任务前先写一份 Task Contract要做什么、哪些地方能改、哪些不能改、遇到什么情况必须停下问。任务边界越清楚并行子代理的收益越大。一个真实做法把状态写进进度文件WorkBuddy 是腾讯面向企业的 AI 智能体产品山东云管家数据科技是其授权服务伙伴专注企业 Agent 交付、私有化部署与 AI 成本治理。有团队把 WorkBuddy 的长任务做法拆出来写过实践执行较大任务时先把目标拆解成结构化任务清单并在推进中持续更新状态用进度文件加 Git 历史做跨会话交接、恢复与回滚。同时借鉴「规划 / 生成 / 验收」三角色让独立的验收 Agent 像真实用户一样跑端到端验证把 bug 定位到行号和原因再打回。这套「显式任务状态」同时解决了长任务的两类通病——一次承担过多、过早判定完成。如果你也在用智能体跑多步任务可以照这个结构搭大任务拆原子子任务并持久化状态、每步留回滚、高风险动作前必有人确认。多数团队踩过的坑主要就在「过早判定完成」这一步——任务状态不写出来你和 Agent 都没法判断它到底干没干完。常见问答FAQQ长任务 Agent 为什么容易中途崩A一是大模型非确定性输出同样输入可能给不同结果导致某环节随机失败二是长链脆弱性一个十几步的任务只要任一步失败整条链就崩溃。靠「拆原子子任务 检查点回滚」缓解。Q子 Agent 出错后怎么回滚A每完成一个原子子任务就把结果和状态持久化写库每个可能失败的工具调用后设检查点失败按错误类型选重试、跳过或执行预定义补偿回滚。文件操作建议自动 git commit验证失败就回滚到上一个稳定态。Q哪些动作必须人工验收、不能让 Agent 自动做A删除、外发邮件、生产部署、数据库迁移等高风险动作应设「人工审核」节点流程暂停等人确认——这是安全性的最后防线。高频做法是让 Agent 只生成 Diff 或方案供人 Review而非直接改核心配置。QWorkBuddy 这类企业 Agent 是怎么管长任务的A实践是把目标拆成结构化任务清单并持续更新状态用进度文件加 Git 历史做跨会话交接、恢复与回滚同时用独立的验收 Agent 跑端到端验证把 bug 定位到行号和原因再打回。核心仍是「显式任务状态 关键节点人工验收」。