1. 从一问一答到跑一整条链路工程重心到底挪到了哪很多人第一次接触 Agent脑子里想的还是更聪明的聊天框——问一句答一句最多加个工具调用。但真把 Agent 放到生产环境里跑长任务比如让它自己规划一次数据迁移、自己盯一个持续两小时的爬取流程、自己根据中间结果反复调整策略你会发现一个很反直觉的事实模型能力往往不是瓶颈工程才是。我最早做 Agent 项目时也踩过这个坑。当时觉得只要 Prompt 写得够好、模型选得够强任务自然能跑通。结果一个帮我整理这批文档并生成摘要的任务单次调用跑得挺漂亮一旦改成分批处理 200 个文件、失败要重试、中间要落盘、最后要汇总整个系统就开始各种诡异行为上下文越滚越长导致后面完全跑偏、某个工具调用超时后整个循环卡死、重试逻辑把已经成功的步骤又跑了一遍。这些问题没有一个是模型不够聪明造成的全是工程问题。所以这篇想聊的核心就一句话当 Agent 从单次回答走向长任务执行工程工作发生的位置从怎么问转移到了怎么管。管什么管上下文、管循环、管状态、管失败、管并发、管安全边界。这也是为什么最近 Context Engineering、Loop Engineering、Graph Engineering 这些词会密集出现——它们本质上都是在回答长任务 Agent 的工程该做在哪一层。这篇文章适合两类人看一类是已经能跑通单次 Agent 调用、但一上长任务就翻车的开发者另一类是正准备搭 Agent 框架、想提前知道坑在哪里的同学。我会尽量把每个环节为什么这么做讲清楚而不是只丢一堆概念。下面这张表先给个全局印象后面逐层展开。阶段工程重心典型问题对应工程词单次回答Prompt 措辞、格式约束答非所问、格式不对Prompt Engineering多步工具调用工具描述、参数校验调错工具、参数幻觉Tool/Function Calling长任务执行上下文、循环、状态、失败恢复跑偏、卡死、重复执行Context / Loop Engineering多 Agent 协作编排、通信、职责边界互相等待、责任不清Graph Engineering2. 长任务 Agent 和单次回答差的不是步数而是状态2.1 单次回答为什么简单它是无状态的单次回答的本质是无状态函数输入一段文本输出一段文本调用结束一切归零。你不需要关心上一次说了什么因为根本没有上一次。这种模式下工程复杂度几乎全部集中在输入端——也就是 Prompt 怎么写、few-shot 怎么给、输出格式怎么约束。这就是 Prompt Engineering 的主场。无状态带来的好处是巨大的可预测、可重试、可并行。同一个请求发十次结果大差不差失败了直接重发没有任何副作用。所以单次回答的工程问题本质上是输入优化问题。2.2 长任务为什么难它是有状态的而且状态会累积一旦任务需要多步执行Agent 就变成了有状态系统。它要记住前面做了什么、当前在哪一步、下一步该干嘛、哪些中间结果还有用。这些记忆要么塞进上下文要么落到外部存储。而状态一旦存在所有分布式系统的老问题就全来了状态一致性上下文里记的和外部存储里存的对不上怎么办状态膨胀上下文越滚越长模型注意力被稀释后面开始胡说。状态恢复跑到一半崩了怎么从断点续跑而不是从头再来我见过太多项目单次调用效果惊艳一改成循环执行就原形毕露。原因就是开发者还在用无状态思维写有状态系统——每次循环都把完整历史塞进去既不裁剪也不摘要跑到第十几轮上下文就爆了模型开始忽略早期指令任务彻底跑偏。2.3 一个具体的翻车场景举个我实际遇到的例子。任务是遍历一个目录下的所有 Markdown 文件逐个提取关键信息并汇总成一张表。听起来简单但拆开看先列目录拿到文件列表工具调用对每个文件读取内容工具调用可能几十次对每个文件内容做信息提取模型调用可能几十次汇总所有提取结果模型调用如果每步都把完整历史塞进上下文到第 20 个文件时上下文里已经堆了 19 个文件的完整内容加 19 次提取结果。这时候模型面对的是一个几万 token 的历史包袱它要么开始偷懒只处理最近几个文件要么把不同文件的信息串在一起。这不是模型不行是我没做上下文管理。正确的做法是文件内容读完、提取完就丢弃原文只保留提取结果提取结果用结构化格式比如 JSON存到外部上下文里只放一个进度指针和已完成的摘要。这样无论处理 10 个还是 200 个文件上下文大小都是可控的。3. Context Engineering长任务里最容易被低估的一层3.1 上下文不是越多越好而是越准越好新手最容易犯的错就是觉得上下文给得越全模型表现越好。这在单次回答里勉强成立在长任务里是灾难。原因有两个第一注意力是有成本的。上下文越长模型对每一部分的关注度越被稀释。你塞进去 50 条历史模型可能只认真看了最近 5 条前面 45 条变成了背景噪音甚至干扰判断。第二上下文是花钱的。每一轮循环都带着完整历史token 消耗是线性甚至平方级增长的。一个跑 100 轮的任务如果每轮都带全量历史成本会高到离谱。所以 Context Engineering 的核心命题是在每一轮只给模型此刻真正需要的信息。这需要你主动设计而不是被动累积。3.2 上下文分层把信息按生命周期分类我的做法是把上下文里的信息按生命周期分成几层每层用不同的管理策略信息类型生命周期管理策略系统指令/角色设定全程不变固定放在最前永不裁剪任务目标全程不变固定但可精简表述当前进度/状态每轮更新只保留最新覆盖旧的近期操作历史短期滑动窗口只留最近 N 轮早期操作摘要长期定期压缩成摘要替换原文工具返回的大块数据用完即弃提取关键信息后立即丢弃原文这张表是我踩了无数坑之后总结的。关键在于区分必须常驻和用完即弃。系统指令和任务目标必须常驻否则模型会忘记自己是谁、要干嘛而工具返回的原始数据一旦提取出有用信息原文就该扔掉。3.3 上下文压缩什么时候压、怎么压上下文压缩是长任务的必修课。我的经验是不要等到快满了才压而是按轮次定期压。比如每完成 5 轮操作就把这 5 轮的详细历史压缩成一段摘要。压缩的方式有几种各有取舍规则压缩按固定模板提取关键字段比如第 X 步调用了 Y 工具结果是 Z。优点是稳定、便宜缺点是可能丢细节。模型压缩让模型自己总结前几轮做了什么。优点是灵活、能抓重点缺点是额外消耗一次调用且可能总结失真。混合压缩关键步骤用规则精确记录次要步骤用模型概括。我一般用混合方式。对于状态变更类的操作比如写文件、改数据库用规则精确记录因为这些不能出错对于探索类的操作比如搜索、试错用模型概括因为细节不重要。提示压缩摘要本身也要控制长度。我见过有人把 10 轮历史压成一段 2000 字的摘要那等于没压。摘要应该控制在原文的 10% 到 20%。3.4 一个反直觉的经验有时候要主动遗忘这一点很多人想不到。长任务里主动丢弃某些信息反而能提升表现。比如一个任务前期走了弯路试了几个错误方案这些失败尝试如果一直留在上下文里会持续干扰模型后续判断——它可能反复纠结于之前为什么失败而不是专注当前方案。我的做法是当确认某个方向彻底放弃后把相关的失败历史从上下文里清掉只在摘要里留一句方案 A 已排除原因是 X。这样既保留了教训又不让细节拖累后续推理。4. Loop Engineering让 Agent 循环转得动也停得下4.1 循环的本质一个带退出条件的 while长任务 Agent 的执行骨架说白了就是一个循环初始化状态 while 任务未完成 and 未超限: 构造当前上下文 调用模型决策 执行工具/动作 更新状态 检查退出条件 返回结果看起来简单但每一行都是坑。Loop Engineering 要解决的就是这个循环怎么设计才既转得动能推进任务又停得下不会死循环或提前退出。4.2 退出条件最容易写错的地方退出条件是循环的命门。写得太松Agent 会无限循环写得太紧任务没完成就退出了。常见的退出条件有几类任务完成信号模型明确输出完成或返回最终结果。步数上限硬性限制最多跑 N 步防止失控。时间上限超过 X 秒强制退出。无进展检测连续 K 步状态没有实质变化判定卡死。错误上限连续失败 M 次放弃。我的经验是这几类要组合使用不能只靠一种。只靠任务完成信号最危险因为模型可能永远不认为自己完成了只靠步数上限又太粗暴可能任务差一步就完成却被砍掉。实际配置时我会设一个宽松的步数上限比如预估需要 20 步就设 50 步配合无进展检测作为主要退出机制。无进展检测怎么判断比较连续几步的状态快照如果关键字段比如已完成的任务项数量没变化就认为卡住了。4.3 循环里的防重复执行这是长任务里特别隐蔽的坑。Agent 在循环中可能因为上下文丢失或判断失误把已经做过的操作又做一遍。比如已经写过的文件又写一次、已经发过的请求又发一次。防重复的核心是幂等性设计 操作记录。具体做法每个有副作用的操作执行前先查操作记录看是否已执行过。操作记录用唯一标识比如文件路径 操作类型作为 key。对于无法幂等的操作比如发消息要么加去重 ID要么在执行前做二次确认。我在一个批量处理项目里就吃过这个亏Agent 重试时把已经处理成功的文件又处理了一遍导致结果里出现重复条目。后来加了操作记录表每次执行前先查表问题才解决。4.4 循环的节奏控制还有一个容易被忽略的点循环跑太快未必是好事。如果 Agent 每一步都立刻执行下一个动作中间没有思考间隙它可能陷入局部最优——比如反复微调同一个参数而不是跳出来换个思路。我的做法是在循环里加入阶段性回顾每跑 N 步强制插入一次总结当前进展、评估方向是否正确的步骤。这一步不执行具体操作只做反思。实测下来这能显著减少 Agent 钻牛角尖的情况。5. Graph Engineering当单个循环不够用时的编排5.1 什么时候需要从循环升级到图单个循环能搞定线性任务但现实任务往往不是线性的。比如一个内容生产 Agent先调研、再写初稿、再审核、审核不过要回到写作、审核过了要排版、排版后要发布。这里面有分支、有回退、有并行用单个 while 循环表达会非常别扭。这时候就需要 Graph Engineering——把任务建模成一张有向图节点是执行单元边是流转条件。这其实就是把工作流编排的思路引入 Agent。5.2 图结构的几个关键设计设计 Agent 图时我关注这几个点节点粒度一个节点应该是一个语义完整的动作比如调研是一个节点写初稿是一个节点。粒度太细会导致图过于复杂太粗又失去灵活性。边的条件边不是无条件的而是带判断的。比如审核通过 → 排版、审核不通过 → 回到写作。状态传递节点之间传递什么是整个上下文还是只传关键状态我倾向于只传关键状态避免上下文在图里无限膨胀。终止节点图必须有明确的终点否则会绕圈。5.3 多 Agent 协作图的一种特殊形态多 Agent 本质上是图的一种实现——每个 Agent 是图里的一个节点或子图。但多 Agent 引入了新的工程问题通信和职责边界。我见过不少多 Agent 项目失败不是因为 Agent 不够强而是因为职责没划清。比如两个 Agent 都能修改文件结果互相覆盖或者一个 Agent 等另一个 Agent 的输出但对方根本没打算产出。我的经验是每个 Agent 的职责要能用一句话说清且不重叠。如果两个 Agent 的职责描述有交集就该合并或重新划分。另外Agent 之间的通信最好走结构化消息比如 JSON而不是自然语言减少误解。协作模式适用场景工程要点串行流水线步骤明确、前后依赖状态传递要精简并行分工子任务独立结果合并要处理冲突主从调度一个协调者 多个执行者协调者不能成为瓶颈辩论/评审需要多视角验证控制轮次防止无限争论6. 长任务 Agent 的失败恢复与并发处理6.1 失败是常态不是异常长任务跑得越久遇到失败的概率越高。网络抖动、工具超时、模型返回格式错误、外部服务限流……这些在单次回答里是异常在长任务里是日常。所以失败恢复不是可选项是必选项。我的原则是每个可能失败的操作都要有明确的失败处理策略。策略无非几种重试、跳过、降级、终止。选哪种取决于这个操作的重要性关键操作比如写数据库失败必须重试重试失败则终止整个任务。次要操作比如日志上报失败可跳过不影响主流程。可替代操作比如主模型失败降级到备用方案。6.2 断点续跑让任务能从中间恢复长任务最怕的是跑到 90% 崩了只能从头再来。解决这个的关键是状态持久化把任务的当前状态定期落盘崩溃后能从最近的检查点恢复。状态里要存什么至少包括当前执行到哪一步、已完成的操作记录、中间结果、上下文摘要。恢复时从这些状态重建上下文继续往下跑。这里有个细节检查点的粒度要合适。太粗比如整个任务只存一次等于没存太细每步都存开销太大。我一般按语义阶段存比如每完成一个子任务存一次。6.3 并发Agent 怎么扛住同时跑多个任务单个长任务已经够复杂如果要同时跑几十上百个任务问题会指数级放大。核心挑战有三个资源竞争多个任务同时调用同一个工具或模型接口可能触发限流。状态隔离任务之间不能互相污染状态。成本控制并发任务多了token 消耗可能失控。我的做法是引入任务队列 限流器。所有任务进队列由固定数量的 worker 消费worker 数量根据下游接口的承载能力设定。每个任务有独立的上下文和状态存储互不干扰。同时给每个任务设 token 预算上限超了就暂停或降级。注意并发不是越高越好。我见过有人把并发开到几百结果下游接口直接被打挂所有任务一起失败。并发数应该由最慢的那个下游环节决定。7. 安全边界长任务 Agent 必须有的刹车7.1 为什么长任务的安全问题更严重单次回答就算答错了最多是输出一段错误文本影响有限。但长任务 Agent 是有手的——它能调工具、能写文件、能发请求。一旦跑偏可能造成真实破坏删错文件、发错消息、改错数据。所以长任务 Agent 必须有明确的安全边界。这不是锦上添花是保命设计。7.2 几道必须设的防线我的实践里至少设这几道权限最小化Agent 能碰的资源严格限制在任务需要的范围内。不需要写权限就不给写权限。危险操作确认删除、覆盖、发送这类不可逆操作执行前要么人工确认要么走二次校验。沙箱隔离让 Agent 在受限环境里执行即使出错也影响不到主系统。操作审计所有有副作用的操作都记日志出问题能追溯。预算熔断token、时间、调用次数都设上限超了自动停。7.3 一个具体的教训我之前做一个自动整理文件的任务Agent 有删除权限。测试时一切正常结果有一次它判断失误把一批不该删的文件标记成了临时文件。幸好我设了删除前先移到回收目录的规则才没造成实际损失。从那以后我定了个规矩Agent 的任何不可逆操作都要先转成可逆操作。删除改成移动覆盖改成备份后写发送改成先存草稿。这样即使判断错了也有挽回余地。8. 从 Prompt 到 Graph一个 Agent 工程师的能力地图8.1 这几层工程不是替代关系是叠加关系很多人问学了 Context Engineering 是不是就不用管 Prompt 了不是。这几层是叠加的不是替代的。Prompt Engineering 解决怎么表达Context Engineering 解决给什么信息Loop Engineering 解决怎么循环Graph Engineering 解决怎么编排。一个成熟的长任务 Agent这四层都得有。从能力成长的角度我建议的学习顺序是先把 Prompt 写明白能稳定拿到想要的输出格式。再学工具调用让 Agent 能操作外部世界。然后啃上下文管理这是长任务的分水岭。接着设计循环和失败恢复让任务能稳定跑完。最后学图编排和多 Agent处理复杂任务。8.2 面试和实战里最常被问的点如果你在准备 Agent 相关的面试或者想检验自己的理解这几个问题很能区分水平长任务里上下文膨胀怎么处理考 Context EngineeringAgent 陷入死循环怎么办考 Loop Engineering多个 Agent 职责重叠怎么解决考 Graph Engineering任务跑到一半崩了怎么恢复考状态管理怎么防止 Agent 执行危险操作考安全边界能把这几个问题讲清楚基本就摸到长任务 Agent 的门槛了。8.3 我个人的一点体会做 Agent 这几年最大的感受是Agent 工程的难点从来不在让模型更聪明而在让系统更可靠。模型能力每年都在涨但可靠性问题不会因为模型变强就自动消失——因为可靠性是工程问题不是智能问题。我见过太多团队把精力全砸在 Prompt 调优上结果系统一上量就崩。也见过一些团队模型用得不算最强但工程做得扎实长任务跑得又稳又省。差距就在这些看不见的工程层里。最后分享一个我常用的自检清单每次设计长任务 Agent 前过一遍上下文里有没有用完即弃的数据没丢循环的退出条件是不是组合设置的有副作用的操作有没有防重复失败了能不能从断点恢复危险操作有没有刹车并发上量后下游扛不扛得住这六个问题答不上来任务大概率跑不稳。答上来了剩下的就是调优的事了。
1. 从一问一答到跑一整条链路工程重心到底挪到了哪很多人第一次接触 Agent脑子里想的还是更聪明的聊天框——问一句答一句最多加个工具调用。但真把 Agent 放到生产环境里跑长任务比如让它自己规划一次数据迁移、自己盯一个持续两小时的爬取流程、自己根据中间结果反复调整策略你会发现一个很反直觉的事实模型能力往往不是瓶颈工程才是。我最早做 Agent 项目时也踩过这个坑。当时觉得只要 Prompt 写得够好、模型选得够强任务自然能跑通。结果一个帮我整理这批文档并生成摘要的任务单次调用跑得挺漂亮一旦改成分批处理 200 个文件、失败要重试、中间要落盘、最后要汇总整个系统就开始各种诡异行为上下文越滚越长导致后面完全跑偏、某个工具调用超时后整个循环卡死、重试逻辑把已经成功的步骤又跑了一遍。这些问题没有一个是模型不够聪明造成的全是工程问题。所以这篇想聊的核心就一句话当 Agent 从单次回答走向长任务执行工程工作发生的位置从怎么问转移到了怎么管。管什么管上下文、管循环、管状态、管失败、管并发、管安全边界。这也是为什么最近 Context Engineering、Loop Engineering、Graph Engineering 这些词会密集出现——它们本质上都是在回答长任务 Agent 的工程该做在哪一层。这篇文章适合两类人看一类是已经能跑通单次 Agent 调用、但一上长任务就翻车的开发者另一类是正准备搭 Agent 框架、想提前知道坑在哪里的同学。我会尽量把每个环节为什么这么做讲清楚而不是只丢一堆概念。下面这张表先给个全局印象后面逐层展开。阶段工程重心典型问题对应工程词单次回答Prompt 措辞、格式约束答非所问、格式不对Prompt Engineering多步工具调用工具描述、参数校验调错工具、参数幻觉Tool/Function Calling长任务执行上下文、循环、状态、失败恢复跑偏、卡死、重复执行Context / Loop Engineering多 Agent 协作编排、通信、职责边界互相等待、责任不清Graph Engineering2. 长任务 Agent 和单次回答差的不是步数而是状态2.1 单次回答为什么简单它是无状态的单次回答的本质是无状态函数输入一段文本输出一段文本调用结束一切归零。你不需要关心上一次说了什么因为根本没有上一次。这种模式下工程复杂度几乎全部集中在输入端——也就是 Prompt 怎么写、few-shot 怎么给、输出格式怎么约束。这就是 Prompt Engineering 的主场。无状态带来的好处是巨大的可预测、可重试、可并行。同一个请求发十次结果大差不差失败了直接重发没有任何副作用。所以单次回答的工程问题本质上是输入优化问题。2.2 长任务为什么难它是有状态的而且状态会累积一旦任务需要多步执行Agent 就变成了有状态系统。它要记住前面做了什么、当前在哪一步、下一步该干嘛、哪些中间结果还有用。这些记忆要么塞进上下文要么落到外部存储。而状态一旦存在所有分布式系统的老问题就全来了状态一致性上下文里记的和外部存储里存的对不上怎么办状态膨胀上下文越滚越长模型注意力被稀释后面开始胡说。状态恢复跑到一半崩了怎么从断点续跑而不是从头再来我见过太多项目单次调用效果惊艳一改成循环执行就原形毕露。原因就是开发者还在用无状态思维写有状态系统——每次循环都把完整历史塞进去既不裁剪也不摘要跑到第十几轮上下文就爆了模型开始忽略早期指令任务彻底跑偏。2.3 一个具体的翻车场景举个我实际遇到的例子。任务是遍历一个目录下的所有 Markdown 文件逐个提取关键信息并汇总成一张表。听起来简单但拆开看先列目录拿到文件列表工具调用对每个文件读取内容工具调用可能几十次对每个文件内容做信息提取模型调用可能几十次汇总所有提取结果模型调用如果每步都把完整历史塞进上下文到第 20 个文件时上下文里已经堆了 19 个文件的完整内容加 19 次提取结果。这时候模型面对的是一个几万 token 的历史包袱它要么开始偷懒只处理最近几个文件要么把不同文件的信息串在一起。这不是模型不行是我没做上下文管理。正确的做法是文件内容读完、提取完就丢弃原文只保留提取结果提取结果用结构化格式比如 JSON存到外部上下文里只放一个进度指针和已完成的摘要。这样无论处理 10 个还是 200 个文件上下文大小都是可控的。3. Context Engineering长任务里最容易被低估的一层3.1 上下文不是越多越好而是越准越好新手最容易犯的错就是觉得上下文给得越全模型表现越好。这在单次回答里勉强成立在长任务里是灾难。原因有两个第一注意力是有成本的。上下文越长模型对每一部分的关注度越被稀释。你塞进去 50 条历史模型可能只认真看了最近 5 条前面 45 条变成了背景噪音甚至干扰判断。第二上下文是花钱的。每一轮循环都带着完整历史token 消耗是线性甚至平方级增长的。一个跑 100 轮的任务如果每轮都带全量历史成本会高到离谱。所以 Context Engineering 的核心命题是在每一轮只给模型此刻真正需要的信息。这需要你主动设计而不是被动累积。3.2 上下文分层把信息按生命周期分类我的做法是把上下文里的信息按生命周期分成几层每层用不同的管理策略信息类型生命周期管理策略系统指令/角色设定全程不变固定放在最前永不裁剪任务目标全程不变固定但可精简表述当前进度/状态每轮更新只保留最新覆盖旧的近期操作历史短期滑动窗口只留最近 N 轮早期操作摘要长期定期压缩成摘要替换原文工具返回的大块数据用完即弃提取关键信息后立即丢弃原文这张表是我踩了无数坑之后总结的。关键在于区分必须常驻和用完即弃。系统指令和任务目标必须常驻否则模型会忘记自己是谁、要干嘛而工具返回的原始数据一旦提取出有用信息原文就该扔掉。3.3 上下文压缩什么时候压、怎么压上下文压缩是长任务的必修课。我的经验是不要等到快满了才压而是按轮次定期压。比如每完成 5 轮操作就把这 5 轮的详细历史压缩成一段摘要。压缩的方式有几种各有取舍规则压缩按固定模板提取关键字段比如第 X 步调用了 Y 工具结果是 Z。优点是稳定、便宜缺点是可能丢细节。模型压缩让模型自己总结前几轮做了什么。优点是灵活、能抓重点缺点是额外消耗一次调用且可能总结失真。混合压缩关键步骤用规则精确记录次要步骤用模型概括。我一般用混合方式。对于状态变更类的操作比如写文件、改数据库用规则精确记录因为这些不能出错对于探索类的操作比如搜索、试错用模型概括因为细节不重要。提示压缩摘要本身也要控制长度。我见过有人把 10 轮历史压成一段 2000 字的摘要那等于没压。摘要应该控制在原文的 10% 到 20%。3.4 一个反直觉的经验有时候要主动遗忘这一点很多人想不到。长任务里主动丢弃某些信息反而能提升表现。比如一个任务前期走了弯路试了几个错误方案这些失败尝试如果一直留在上下文里会持续干扰模型后续判断——它可能反复纠结于之前为什么失败而不是专注当前方案。我的做法是当确认某个方向彻底放弃后把相关的失败历史从上下文里清掉只在摘要里留一句方案 A 已排除原因是 X。这样既保留了教训又不让细节拖累后续推理。4. Loop Engineering让 Agent 循环转得动也停得下4.1 循环的本质一个带退出条件的 while长任务 Agent 的执行骨架说白了就是一个循环初始化状态 while 任务未完成 and 未超限: 构造当前上下文 调用模型决策 执行工具/动作 更新状态 检查退出条件 返回结果看起来简单但每一行都是坑。Loop Engineering 要解决的就是这个循环怎么设计才既转得动能推进任务又停得下不会死循环或提前退出。4.2 退出条件最容易写错的地方退出条件是循环的命门。写得太松Agent 会无限循环写得太紧任务没完成就退出了。常见的退出条件有几类任务完成信号模型明确输出完成或返回最终结果。步数上限硬性限制最多跑 N 步防止失控。时间上限超过 X 秒强制退出。无进展检测连续 K 步状态没有实质变化判定卡死。错误上限连续失败 M 次放弃。我的经验是这几类要组合使用不能只靠一种。只靠任务完成信号最危险因为模型可能永远不认为自己完成了只靠步数上限又太粗暴可能任务差一步就完成却被砍掉。实际配置时我会设一个宽松的步数上限比如预估需要 20 步就设 50 步配合无进展检测作为主要退出机制。无进展检测怎么判断比较连续几步的状态快照如果关键字段比如已完成的任务项数量没变化就认为卡住了。4.3 循环里的防重复执行这是长任务里特别隐蔽的坑。Agent 在循环中可能因为上下文丢失或判断失误把已经做过的操作又做一遍。比如已经写过的文件又写一次、已经发过的请求又发一次。防重复的核心是幂等性设计 操作记录。具体做法每个有副作用的操作执行前先查操作记录看是否已执行过。操作记录用唯一标识比如文件路径 操作类型作为 key。对于无法幂等的操作比如发消息要么加去重 ID要么在执行前做二次确认。我在一个批量处理项目里就吃过这个亏Agent 重试时把已经处理成功的文件又处理了一遍导致结果里出现重复条目。后来加了操作记录表每次执行前先查表问题才解决。4.4 循环的节奏控制还有一个容易被忽略的点循环跑太快未必是好事。如果 Agent 每一步都立刻执行下一个动作中间没有思考间隙它可能陷入局部最优——比如反复微调同一个参数而不是跳出来换个思路。我的做法是在循环里加入阶段性回顾每跑 N 步强制插入一次总结当前进展、评估方向是否正确的步骤。这一步不执行具体操作只做反思。实测下来这能显著减少 Agent 钻牛角尖的情况。5. Graph Engineering当单个循环不够用时的编排5.1 什么时候需要从循环升级到图单个循环能搞定线性任务但现实任务往往不是线性的。比如一个内容生产 Agent先调研、再写初稿、再审核、审核不过要回到写作、审核过了要排版、排版后要发布。这里面有分支、有回退、有并行用单个 while 循环表达会非常别扭。这时候就需要 Graph Engineering——把任务建模成一张有向图节点是执行单元边是流转条件。这其实就是把工作流编排的思路引入 Agent。5.2 图结构的几个关键设计设计 Agent 图时我关注这几个点节点粒度一个节点应该是一个语义完整的动作比如调研是一个节点写初稿是一个节点。粒度太细会导致图过于复杂太粗又失去灵活性。边的条件边不是无条件的而是带判断的。比如审核通过 → 排版、审核不通过 → 回到写作。状态传递节点之间传递什么是整个上下文还是只传关键状态我倾向于只传关键状态避免上下文在图里无限膨胀。终止节点图必须有明确的终点否则会绕圈。5.3 多 Agent 协作图的一种特殊形态多 Agent 本质上是图的一种实现——每个 Agent 是图里的一个节点或子图。但多 Agent 引入了新的工程问题通信和职责边界。我见过不少多 Agent 项目失败不是因为 Agent 不够强而是因为职责没划清。比如两个 Agent 都能修改文件结果互相覆盖或者一个 Agent 等另一个 Agent 的输出但对方根本没打算产出。我的经验是每个 Agent 的职责要能用一句话说清且不重叠。如果两个 Agent 的职责描述有交集就该合并或重新划分。另外Agent 之间的通信最好走结构化消息比如 JSON而不是自然语言减少误解。协作模式适用场景工程要点串行流水线步骤明确、前后依赖状态传递要精简并行分工子任务独立结果合并要处理冲突主从调度一个协调者 多个执行者协调者不能成为瓶颈辩论/评审需要多视角验证控制轮次防止无限争论6. 长任务 Agent 的失败恢复与并发处理6.1 失败是常态不是异常长任务跑得越久遇到失败的概率越高。网络抖动、工具超时、模型返回格式错误、外部服务限流……这些在单次回答里是异常在长任务里是日常。所以失败恢复不是可选项是必选项。我的原则是每个可能失败的操作都要有明确的失败处理策略。策略无非几种重试、跳过、降级、终止。选哪种取决于这个操作的重要性关键操作比如写数据库失败必须重试重试失败则终止整个任务。次要操作比如日志上报失败可跳过不影响主流程。可替代操作比如主模型失败降级到备用方案。6.2 断点续跑让任务能从中间恢复长任务最怕的是跑到 90% 崩了只能从头再来。解决这个的关键是状态持久化把任务的当前状态定期落盘崩溃后能从最近的检查点恢复。状态里要存什么至少包括当前执行到哪一步、已完成的操作记录、中间结果、上下文摘要。恢复时从这些状态重建上下文继续往下跑。这里有个细节检查点的粒度要合适。太粗比如整个任务只存一次等于没存太细每步都存开销太大。我一般按语义阶段存比如每完成一个子任务存一次。6.3 并发Agent 怎么扛住同时跑多个任务单个长任务已经够复杂如果要同时跑几十上百个任务问题会指数级放大。核心挑战有三个资源竞争多个任务同时调用同一个工具或模型接口可能触发限流。状态隔离任务之间不能互相污染状态。成本控制并发任务多了token 消耗可能失控。我的做法是引入任务队列 限流器。所有任务进队列由固定数量的 worker 消费worker 数量根据下游接口的承载能力设定。每个任务有独立的上下文和状态存储互不干扰。同时给每个任务设 token 预算上限超了就暂停或降级。注意并发不是越高越好。我见过有人把并发开到几百结果下游接口直接被打挂所有任务一起失败。并发数应该由最慢的那个下游环节决定。7. 安全边界长任务 Agent 必须有的刹车7.1 为什么长任务的安全问题更严重单次回答就算答错了最多是输出一段错误文本影响有限。但长任务 Agent 是有手的——它能调工具、能写文件、能发请求。一旦跑偏可能造成真实破坏删错文件、发错消息、改错数据。所以长任务 Agent 必须有明确的安全边界。这不是锦上添花是保命设计。7.2 几道必须设的防线我的实践里至少设这几道权限最小化Agent 能碰的资源严格限制在任务需要的范围内。不需要写权限就不给写权限。危险操作确认删除、覆盖、发送这类不可逆操作执行前要么人工确认要么走二次校验。沙箱隔离让 Agent 在受限环境里执行即使出错也影响不到主系统。操作审计所有有副作用的操作都记日志出问题能追溯。预算熔断token、时间、调用次数都设上限超了自动停。7.3 一个具体的教训我之前做一个自动整理文件的任务Agent 有删除权限。测试时一切正常结果有一次它判断失误把一批不该删的文件标记成了临时文件。幸好我设了删除前先移到回收目录的规则才没造成实际损失。从那以后我定了个规矩Agent 的任何不可逆操作都要先转成可逆操作。删除改成移动覆盖改成备份后写发送改成先存草稿。这样即使判断错了也有挽回余地。8. 从 Prompt 到 Graph一个 Agent 工程师的能力地图8.1 这几层工程不是替代关系是叠加关系很多人问学了 Context Engineering 是不是就不用管 Prompt 了不是。这几层是叠加的不是替代的。Prompt Engineering 解决怎么表达Context Engineering 解决给什么信息Loop Engineering 解决怎么循环Graph Engineering 解决怎么编排。一个成熟的长任务 Agent这四层都得有。从能力成长的角度我建议的学习顺序是先把 Prompt 写明白能稳定拿到想要的输出格式。再学工具调用让 Agent 能操作外部世界。然后啃上下文管理这是长任务的分水岭。接着设计循环和失败恢复让任务能稳定跑完。最后学图编排和多 Agent处理复杂任务。8.2 面试和实战里最常被问的点如果你在准备 Agent 相关的面试或者想检验自己的理解这几个问题很能区分水平长任务里上下文膨胀怎么处理考 Context EngineeringAgent 陷入死循环怎么办考 Loop Engineering多个 Agent 职责重叠怎么解决考 Graph Engineering任务跑到一半崩了怎么恢复考状态管理怎么防止 Agent 执行危险操作考安全边界能把这几个问题讲清楚基本就摸到长任务 Agent 的门槛了。8.3 我个人的一点体会做 Agent 这几年最大的感受是Agent 工程的难点从来不在让模型更聪明而在让系统更可靠。模型能力每年都在涨但可靠性问题不会因为模型变强就自动消失——因为可靠性是工程问题不是智能问题。我见过太多团队把精力全砸在 Prompt 调优上结果系统一上量就崩。也见过一些团队模型用得不算最强但工程做得扎实长任务跑得又稳又省。差距就在这些看不见的工程层里。最后分享一个我常用的自检清单每次设计长任务 Agent 前过一遍上下文里有没有用完即弃的数据没丢循环的退出条件是不是组合设置的有副作用的操作有没有防重复失败了能不能从断点恢复危险操作有没有刹车并发上量后下游扛不扛得住这六个问题答不上来任务大概率跑不稳。答上来了剩下的就是调优的事了。
