1. 从单次问答到长任务执行Agent 工程的重心到底挪到了哪里很多人第一次接触 AI Agent都是从“帮我写一段代码”“帮我总结这篇文章”开始的。这种单次问答的交互模式很直观给一个输入等一个输出不满意就重新问一遍。但真正把 Agent 放到生产环境里跑起来之后你会发现事情完全不是这个样子。一个能扛住真实业务的长任务 Agent它要面对的是几十步甚至上百步的连续决策、跨会话的状态保持、外部工具的反复调用、失败之后的重试与回滚以及多个 Agent 之间的协作编排。这时候工程工作的重心就从“怎么把提示词写好”彻底转移到了“怎么让整个执行链路稳定、可观测、可恢复”上面。我自己带过几个 Agent 项目从最早的纯 Prompt 拼接到后来引入工具调用、记忆管理、多 Agent 编排踩过的坑基本覆盖了这条演进路线上的每一个阶段。这篇文章想聊的就是当 AI Agent 从单次回答走向长任务执行工程工作到底发生在哪里我会围绕 Agent、Prompt Engineering、Context Engineering、Loop Engineering、Graph Engineering 这几个核心概念把长任务 Agent 的工程拆解讲清楚同时补充工具选型、参数计算、实操步骤和排查技巧。不管你是刚入门 Agent 开发还是已经在做多 Agent 编排应该都能从中找到可以直接抄作业的部分。先给一个整体判断单次问答的工程复杂度大概在 1 到 2 之间长任务 Agent 的工程复杂度直接跳到 8 以上。多出来的这部分几乎全部集中在上下文管理、循环控制、状态持久化、错误恢复和可观测性这五个方向上。下面我按章节逐一拆开讲。2. 长任务 Agent 的工程全景五个核心工程域2.1 为什么单次问答的工程思路在长任务里会失效单次问答的典型链路是用户输入 → 拼接 Prompt → 调用模型 → 返回结果。这条链路里工程工作主要集中在 Prompt 模板管理、模型参数调优和输出解析上。Prompt Engineering 在这个阶段确实是核心因为模型的能力边界基本由提示词决定。但长任务执行不一样。一个长任务 Agent 的典型链路是接收任务 → 拆解子目标 → 规划执行步骤 → 调用工具 → 观察结果 → 判断是否继续 → 更新状态 → 循环直到完成或失败。这条链路里Prompt 只是其中一个环节而且往往不是最关键的环节。真正决定 Agent 能不能跑完任务的是上下文怎么组织、循环怎么控制、状态怎么保存、错误怎么恢复、多个 Agent 怎么协作。我见过太多项目Prompt 写得非常漂亮单次问答效果也很好但一放到长任务里就各种崩跑到第十步忘了前面做过什么工具调用失败之后直接卡死上下文塞满之后模型开始胡言乱语。这些问题的根因都不在 Prompt 上而在工程架构上。2.2 五个工程域的分工与边界把长任务 Agent 的工程工作拆开大致可以分成五个域工程域核心问题主要手段典型失效表现Prompt Engineering怎么让模型理解当前指令提示词模板、少样本示例、输出格式约束指令理解偏差、输出格式错乱Context Engineering怎么组织模型看到的信息上下文窗口管理、检索增强、摘要压缩上下文溢出、关键信息丢失Loop Engineering怎么控制执行循环终止条件、重试策略、步数上限死循环、提前终止、步数爆炸Graph Engineering怎么编排多步骤多 Agent状态图、节点路由、条件边路由错误、状态不一致、协作死锁Harness Engineering怎么让 Agent 稳定运行沙箱隔离、权限控制、可观测性越权操作、资源泄漏、问题无法定位这五个域不是孤立的它们之间有明确的依赖关系。Prompt 是基础Context 决定模型能看到什么Loop 决定 Agent 怎么往前走Graph 决定多个步骤和多个 Agent 怎么组织Harness 决定整个系统能不能安全稳定地跑在生产环境里。很多团队的问题在于只关注了 Prompt 和 Context忽略了 Loop、Graph 和 Harness结果 Agent 在演示环境里跑得很好一上生产就各种问题。2.3 一个真实项目的工程工作量分布拿我之前做过的一个数据分析 Agent 项目举例。这个 Agent 要完成的任务是接收一个分析需求自动拆解成多个子任务调用数据库查询工具、Python 执行工具、图表生成工具最后输出一份分析报告。整个项目从立项到上线工程工作量的分布大概是这样的Prompt Engineering 相关约 15%Context Engineering 相关约 25%Loop Engineering 相关约 20%Graph Engineering 相关约 20%Harness Engineering 相关约 20%可以看到Prompt 只占了 15% 左右。剩下 85% 的工作量全部集中在上下文管理、循环控制、编排和运行保障上。这个分布和很多人的直觉是相反的但这就是长任务 Agent 工程的真实情况。3. Context Engineering长任务 Agent 的上下文管理实战3.1 上下文窗口的预算分配与计算Context Engineering 是长任务 Agent 工程里最容易被低估的部分。很多人觉得上下文管理就是“把历史消息塞进去”但实际上上下文窗口是一个需要精打细算的预算。假设你用的是 128K token 上下文窗口的模型一个长任务 Agent 的上下文预算大概可以这样分配系统提示词与工具定义8K token当前任务描述与目标4K token历史执行记录压缩后32K token检索到的相关文档48K token当前步骤的详细上下文24K token输出预留空间12K token这个分配不是固定的要根据任务类型调整。但核心原则是永远不要把所有历史消息原封不动地塞进上下文。我见过一个项目直接把所有对话历史拼进去跑到第 20 轮的时候上下文直接爆了模型开始重复之前已经完成的操作。正确的做法是分层管理。最近几轮的详细记录保留原文更早的历史做摘要压缩再早的只保留关键决策点和结论。摘要压缩可以用模型来做也可以用规则来做关键是保证压缩后的信息不丢失关键状态。3.2 上下文压缩的三种策略与选择依据上下文压缩我常用三种策略各有适用场景第一种是滑动窗口。只保留最近 N 轮对话更早的直接丢弃。这种策略实现最简单适合任务步骤之间独立性较强的场景。缺点是如果任务需要回溯早期信息就会丢失关键上下文。第二种是摘要压缩。把早期对话交给模型生成摘要用摘要替代原文。这种策略适合任务步骤之间有依赖关系的场景。摘要的质量直接决定压缩效果我一般会要求摘要必须包含已完成的步骤、当前状态、待办事项、关键决策和原因。第三种是结构化状态提取。不保留对话原文而是把任务状态提取成结构化数据比如 JSON 格式的任务进度表。这种策略适合状态明确、步骤可枚举的场景。优点是 token 消耗极低缺点是灵活性差遇到计划外的情况不好处理。实际项目里我通常是三种策略混用最近 3 到 5 轮用滑动窗口保留原文5 到 20 轮用摘要压缩20 轮以上用结构化状态提取。这样既保证了近期上下文的完整性又控制了整体 token 消耗。3.3 检索增强在长任务中的正确用法检索增强在单次问答里用得很多但在长任务 Agent 里检索的时机和内容需要重新设计。单次问答的检索是“用户问什么就检索什么”长任务 Agent 的检索应该是“当前步骤需要什么就检索什么”。我一般会在两个时机触发检索一是任务规划阶段检索与任务相关的背景知识和历史案例二是每个步骤执行前检索与该步骤相关的工具文档、参数说明和注意事项。检索结果不直接塞进上下文而是先做相关性排序和去重只保留 top-k 条最相关的内容。这里有个容易踩的坑检索结果太多会挤占上下文预算太少又可能信息不足。我的经验是每个步骤的检索结果控制在 3 到 5 条每条不超过 2K token。如果检索结果质量不高宁可少放也不要硬塞。注意检索增强的 embedding 模型和生成模型最好分开选型。embedding 模型关注检索准确率生成模型关注推理能力两者的优化目标不一样。4. Loop Engineering让 Agent 知道什么时候该停、什么时候该继续4.1 循环终止条件的四种设计模式Loop Engineering 是长任务 Agent 最核心的工程问题之一。Agent 本质上是一个循环观察 → 思考 → 行动 → 观察。如果终止条件设计不好要么死循环要么提前退出。我总结过四种终止条件设计模式第一种是目标达成终止。Agent 判断任务目标已经完成主动退出循环。这是最理想的终止方式但判断“目标是否达成”本身就是一个难题。我的做法是让 Agent 在每一步之后输出一个完成度评分连续两步评分不再提升且高于阈值时判定为达成。第二种是步数上限终止。设置最大步数超过就强制退出。这是兜底机制防止死循环。步数上限怎么定我的经验是简单任务 10 到 15 步中等任务 20 到 30 步复杂任务 50 步以上。但步数上限不能设得太低否则复杂任务会被误杀。第三种是资源耗尽终止。设置 token 预算或时间预算耗尽就退出。这种模式适合成本敏感的场景。token 预算的计算方式是预估任务平均步数 × 每步平均 token 消耗 × 安全系数 1.5。第四种是异常终止。连续多次工具调用失败、连续多次输出格式错误、或者检测到循环重复模式时主动终止并报告异常。实际项目里这四种模式通常是组合使用的。我的默认配置是目标达成终止为主步数上限和资源耗尽为兜底异常终止为保护。4.2 重试策略与退避算法的参数计算工具调用失败是长任务 Agent 的常态。重试策略设计不好要么重试太频繁导致资源浪费要么重试太保守导致任务失败。我常用的重试策略是指数退避第一次失败后等待 1 秒重试第二次等待 2 秒第三次等待 4 秒以此类推最大等待时间不超过 30 秒。重试次数一般设为 3 次超过 3 次就判定为不可恢复失败触发异常终止或降级处理。但指数退避不是万能的。对于某些错误类型比如参数错误、权限错误重试是没有意义的应该直接失败。对于网络超时、服务暂时不可用这类错误重试才有意义。所以重试策略要配合错误分类使用。我一般会把错误分成三类可重试错误网络超时、限流、不可重试错误参数错误、权限错误、需降级错误服务不可用、依赖缺失。可重试错误走指数退避不可重试错误直接失败需降级错误走备用方案。4.3 循环中的状态检查点设计长任务 Agent 跑到一半崩了如果没有状态检查点就只能从头再来。状态检查点的设计原则是在每个关键步骤完成后保存状态状态要包含恢复执行所需的全部信息。状态检查点至少应该包含当前步骤编号、已完成步骤列表、当前任务状态、关键变量值、下一步计划。保存时机一般选在工具调用成功后、模型输出解析成功后、以及每 N 步强制保存一次。恢复执行时从最近的检查点加载状态重新构建上下文然后从下一步继续执行。这里有个细节恢复执行时上下文里的历史记录可能已经过期需要重新检索或重新摘要。我一般会在恢复时重新生成一份精简的上下文只包含恢复执行必需的信息。提示状态检查点的存储建议用外部存储不要放在内存里。Agent 进程重启后内存状态会丢失外部存储才能保证恢复。5. Graph Engineering多步骤多 Agent 的编排实战5.1 从线性链到状态图的演进逻辑早期的 Agent 编排基本是线性链步骤 A → 步骤 B → 步骤 C。这种结构简单直观但只能处理固定流程的任务。一旦任务需要分支、循环、并行线性链就不够用了。状态图State Graph是目前主流的编排方式。它的核心思想是把 Agent 的执行过程建模成一张有向图节点是执行单元边是状态转移条件。每个节点执行完后根据当前状态决定走哪条边。状态图相比线性链的优势在于支持条件分支、支持循环、支持并行、支持人工介入节点。这些能力在长任务 Agent 里都是必需的。比如一个数据分析任务可能需要先判断数据源类型再决定用哪种查询方式查询失败后可能需要人工确认这些用线性链都很难表达。5.2 节点、边与状态的设计规范设计状态图时我遵循几个规范节点设计规范每个节点只做一件事节点的输入输出要明确。节点类型一般分为LLM 节点调用模型、工具节点调用外部工具、条件节点做判断、人工节点等待人工输入、终止节点结束流程。边设计规范边分为普通边和条件边。普通边表示无条件转移条件边表示根据状态判断转移。条件边的判断逻辑要尽量简单复杂的判断逻辑应该封装成独立的条件节点。状态设计规范状态是整个图的共享数据所有节点都能读写。状态设计要遵循最小必要原则只放节点间需要传递的数据。状态更新要原子化避免多个节点同时写同一个字段导致冲突。我一般会用这样的状态结构state { task_id: xxx, current_step: 3, completed_steps: [step1, step2], task_status: in_progress, variables: {}, history: [], error: None }这个结构简单但够用实际项目里可以根据需要扩展。5.3 多 Agent 协作的三种拓扑结构多 Agent 协作是 Graph Engineering 的进阶话题。我常用三种拓扑结构第一种是主管- worker 结构。一个主管 Agent 负责拆解任务和分配子任务多个 worker Agent 负责执行具体子任务。这种结构适合任务可以明确拆解的场景。主管 Agent 的 Prompt 要重点设计任务拆解逻辑和结果汇总逻辑。第二种是流水线结构。多个 Agent 按顺序处理前一个的输出是后一个的输入。这种结构适合有明确阶段划分的任务比如“检索 → 分析 → 生成报告”。流水线结构的难点在于阶段之间的接口设计输出格式必须严格约定。第三种是辩论结构。多个 Agent 对同一个问题给出不同答案然后通过投票或仲裁得出最终结果。这种结构适合需要多角度验证的场景比如事实核查、方案评估。辩论结构的成本较高一般只在关键决策点使用。选择哪种结构取决于任务的性质。任务可拆解用主管-worker任务有阶段用流水线任务需验证用辩论。实际项目里这三种结构经常混合使用。6. Harness EngineeringAgent 稳定运行的工程保障6.1 沙箱隔离与权限控制的最小实现Harness Engineering 是长任务 Agent 最容易被忽视的工程域。Agent 要调用外部工具、执行代码、访问数据如果没有沙箱隔离和权限控制风险非常大。沙箱隔离的最小实现包括文件系统隔离Agent 只能访问指定目录、网络隔离Agent 只能访问白名单地址、进程隔离Agent 执行的代码在独立进程里跑崩溃不影响主进程、资源限制CPU、内存、执行时间都有上限。权限控制的最小实现包括工具白名单Agent 只能调用授权工具、参数校验工具调用参数要经过校验、操作审计所有工具调用都要记录日志、敏感操作二次确认删除、修改类操作需要人工确认。我见过一个项目Agent 直接在主进程里执行用户输入的代码结果一段死循环代码把整个服务拖垮了。沙箱隔离不是可选项是必选项。6.2 可观测性日志、指标与追踪的三件套Agent 跑在生产环境里出问题是必然的。可观测性决定了你能不能快速定位问题。日志要记录每一步的输入输出、工具调用详情、状态变化、错误信息。日志要结构化方便检索和分析。指标要采集任务成功率、平均步数、平均耗时、token 消耗、工具调用成功率、错误分布。这些指标能帮你发现系统性问题。追踪要覆盖一个任务从开始到结束的完整链路包括每个节点的执行时间、状态转移路径、异常点。追踪能帮你定位单个任务的问题。我一般会用 OpenTelemetry 做追踪用结构化日志做记录用 Prometheus 做指标采集。这三件套搭起来Agent 的运行状态就基本透明了。6.3 并发场景下的资源竞争与隔离Agent 扛并发是个容易被低估的问题。多个任务同时跑会竞争模型调用配额、工具调用资源、存储资源。如果不做隔离一个任务的问题会影响其他任务。我的做法是每个任务分配独立的上下文空间和状态存储工具调用走统一的限流和排队机制模型调用按优先级分配配额。关键资源要做隔离比如代码执行沙箱每个任务一个避免相互影响。并发数怎么定我的经验是先压测单任务的资源消耗再根据总资源反推最大并发数。比如单任务平均消耗 2K token/秒模型配额是 100K token/秒那理论最大并发是 50实际要留 30% 余量所以设 35 左右。7. 常见问题与排查技巧实录7.1 Agent 跑着跑着就忘了前面做过什么这是上下文管理问题。排查思路先看上下文窗口是否溢出再看摘要压缩是否丢失了关键信息最后看状态检查点是否完整。解决方法优化上下文预算分配加强摘要压缩的质量控制确保状态检查点包含完整的任务进度。我一般会在摘要压缩的 Prompt 里明确要求保留“已完成步骤、当前状态、待办事项、关键决策”四类信息。7.2 工具调用失败后 Agent 直接卡死这是循环控制问题。排查思路看重试策略是否生效看错误分类是否正确看是否有降级方案。解决方法完善错误分类可重试错误走指数退避不可重试错误直接失败并触发异常终止需降级错误走备用方案。同时要确保异常终止能正确保存状态方便后续恢复。7.3 多 Agent 协作时状态不一致这是 Graph Engineering 问题。排查思路看状态更新是否原子化看是否有并发写冲突看状态同步机制是否可靠。解决方法状态更新加锁避免并发写状态同步用消息队列或事件总线确保最终一致关键状态做版本控制冲突时以最新版本为准。7.4 常见问题速查表问题现象可能原因排查方向解决方法上下文溢出历史消息未压缩检查上下文预算分层压缩控制 token 消耗死循环终止条件缺失检查循环控制逻辑加步数上限和异常终止提前退出完成度判断过严检查目标达成逻辑调整完成度阈值工具调用失败参数错误或权限不足检查工具配置完善错误分类和重试状态丢失检查点未保存检查状态存储关键步骤后强制保存并发冲突资源未隔离检查资源分配任务级隔离限流排队输出格式错乱输出约束不足检查 Prompt 约束加强格式约束和校验7.5 几个踩过坑才明白的经验第一个经验不要迷信单次问答的效果。单次问答效果好不代表长任务效果好。长任务要单独测试单独调优。第二个经验上下文不是越多越好。塞太多上下文模型反而会抓不住重点。精简、相关、结构化比堆量重要得多。第三个经验终止条件要早设计。不要等 Agent 跑飞了才想起来加终止条件。设计阶段就要把终止条件想清楚。第四个经验可观测性要提前做。不要等出问题了才加日志。Agent 上线前日志、指标、追踪三件套就要到位。第五个经验沙箱隔离不能省。Agent 执行外部代码、调用外部工具风险是实打实的。沙箱隔离是底线不是可选项。8. 从 Prompt 到 HarnessAgent 工程的能力演进路线聊到这里可以把长任务 Agent 的工程能力演进路线梳理一下。第一阶段是 Prompt Engineering解决“怎么让模型理解指令”的问题。第二阶段是 Context Engineering解决“怎么让模型看到正确的信息”的问题。第三阶段是 Loop Engineering解决“怎么让 Agent 持续正确地执行”的问题。第四阶段是 Graph Engineering解决“怎么编排多步骤多 Agent”的问题。第五阶段是 Harness Engineering解决“怎么让 Agent 安全稳定地跑在生产环境”的问题。这五个阶段不是严格串行的实际项目里经常是交叉进行的。但能力建设的优先级是明确的先把 Prompt 和 Context 做扎实再往上做 Loop 和 Graph最后用 Harness 兜底。跳过前面的阶段直接做后面的大概率会返工。我自己在带团队的时候会用这五个域做能力评估。一个 Agent 项目如果只关注 Prompt那工程成熟度大概在 1 到 2 级如果 Prompt、Context、Loop 都做得不错大概在 3 级如果五个域都有覆盖那基本到了 4 到 5 级。大部分团队卡在 2 到 3 级瓶颈往往在 Loop 和 Graph 上。最后分享一个我在实际项目里常用的检查清单每次 Agent 上线前过一遍Prompt 是否有明确的输出格式约束和少样本示例Context 是否有分层压缩策略和 token 预算控制Loop 是否有目标达成、步数上限、资源耗尽、异常终止四重终止条件Graph 是否有清晰的状态定义和条件路由Harness 是否有沙箱隔离、权限控制、可观测性三件套是否有状态检查点和恢复执行机制是否有并发隔离和限流机制是否有完整的错误分类和重试策略这个清单过一遍基本能覆盖长任务 Agent 的主要工程风险点。剩下的就是根据具体业务场景做针对性优化了。 长任务AI Agent工程实战：从Prompt到Harness的五大工程域拆解
1. 从单次问答到长任务执行Agent 工程的重心到底挪到了哪里很多人第一次接触 AI Agent都是从“帮我写一段代码”“帮我总结这篇文章”开始的。这种单次问答的交互模式很直观给一个输入等一个输出不满意就重新问一遍。但真正把 Agent 放到生产环境里跑起来之后你会发现事情完全不是这个样子。一个能扛住真实业务的长任务 Agent它要面对的是几十步甚至上百步的连续决策、跨会话的状态保持、外部工具的反复调用、失败之后的重试与回滚以及多个 Agent 之间的协作编排。这时候工程工作的重心就从“怎么把提示词写好”彻底转移到了“怎么让整个执行链路稳定、可观测、可恢复”上面。我自己带过几个 Agent 项目从最早的纯 Prompt 拼接到后来引入工具调用、记忆管理、多 Agent 编排踩过的坑基本覆盖了这条演进路线上的每一个阶段。这篇文章想聊的就是当 AI Agent 从单次回答走向长任务执行工程工作到底发生在哪里我会围绕 Agent、Prompt Engineering、Context Engineering、Loop Engineering、Graph Engineering 这几个核心概念把长任务 Agent 的工程拆解讲清楚同时补充工具选型、参数计算、实操步骤和排查技巧。不管你是刚入门 Agent 开发还是已经在做多 Agent 编排应该都能从中找到可以直接抄作业的部分。先给一个整体判断单次问答的工程复杂度大概在 1 到 2 之间长任务 Agent 的工程复杂度直接跳到 8 以上。多出来的这部分几乎全部集中在上下文管理、循环控制、状态持久化、错误恢复和可观测性这五个方向上。下面我按章节逐一拆开讲。2. 长任务 Agent 的工程全景五个核心工程域2.1 为什么单次问答的工程思路在长任务里会失效单次问答的典型链路是用户输入 → 拼接 Prompt → 调用模型 → 返回结果。这条链路里工程工作主要集中在 Prompt 模板管理、模型参数调优和输出解析上。Prompt Engineering 在这个阶段确实是核心因为模型的能力边界基本由提示词决定。但长任务执行不一样。一个长任务 Agent 的典型链路是接收任务 → 拆解子目标 → 规划执行步骤 → 调用工具 → 观察结果 → 判断是否继续 → 更新状态 → 循环直到完成或失败。这条链路里Prompt 只是其中一个环节而且往往不是最关键的环节。真正决定 Agent 能不能跑完任务的是上下文怎么组织、循环怎么控制、状态怎么保存、错误怎么恢复、多个 Agent 怎么协作。我见过太多项目Prompt 写得非常漂亮单次问答效果也很好但一放到长任务里就各种崩跑到第十步忘了前面做过什么工具调用失败之后直接卡死上下文塞满之后模型开始胡言乱语。这些问题的根因都不在 Prompt 上而在工程架构上。2.2 五个工程域的分工与边界把长任务 Agent 的工程工作拆开大致可以分成五个域工程域核心问题主要手段典型失效表现Prompt Engineering怎么让模型理解当前指令提示词模板、少样本示例、输出格式约束指令理解偏差、输出格式错乱Context Engineering怎么组织模型看到的信息上下文窗口管理、检索增强、摘要压缩上下文溢出、关键信息丢失Loop Engineering怎么控制执行循环终止条件、重试策略、步数上限死循环、提前终止、步数爆炸Graph Engineering怎么编排多步骤多 Agent状态图、节点路由、条件边路由错误、状态不一致、协作死锁Harness Engineering怎么让 Agent 稳定运行沙箱隔离、权限控制、可观测性越权操作、资源泄漏、问题无法定位这五个域不是孤立的它们之间有明确的依赖关系。Prompt 是基础Context 决定模型能看到什么Loop 决定 Agent 怎么往前走Graph 决定多个步骤和多个 Agent 怎么组织Harness 决定整个系统能不能安全稳定地跑在生产环境里。很多团队的问题在于只关注了 Prompt 和 Context忽略了 Loop、Graph 和 Harness结果 Agent 在演示环境里跑得很好一上生产就各种问题。2.3 一个真实项目的工程工作量分布拿我之前做过的一个数据分析 Agent 项目举例。这个 Agent 要完成的任务是接收一个分析需求自动拆解成多个子任务调用数据库查询工具、Python 执行工具、图表生成工具最后输出一份分析报告。整个项目从立项到上线工程工作量的分布大概是这样的Prompt Engineering 相关约 15%Context Engineering 相关约 25%Loop Engineering 相关约 20%Graph Engineering 相关约 20%Harness Engineering 相关约 20%可以看到Prompt 只占了 15% 左右。剩下 85% 的工作量全部集中在上下文管理、循环控制、编排和运行保障上。这个分布和很多人的直觉是相反的但这就是长任务 Agent 工程的真实情况。3. Context Engineering长任务 Agent 的上下文管理实战3.1 上下文窗口的预算分配与计算Context Engineering 是长任务 Agent 工程里最容易被低估的部分。很多人觉得上下文管理就是“把历史消息塞进去”但实际上上下文窗口是一个需要精打细算的预算。假设你用的是 128K token 上下文窗口的模型一个长任务 Agent 的上下文预算大概可以这样分配系统提示词与工具定义8K token当前任务描述与目标4K token历史执行记录压缩后32K token检索到的相关文档48K token当前步骤的详细上下文24K token输出预留空间12K token这个分配不是固定的要根据任务类型调整。但核心原则是永远不要把所有历史消息原封不动地塞进上下文。我见过一个项目直接把所有对话历史拼进去跑到第 20 轮的时候上下文直接爆了模型开始重复之前已经完成的操作。正确的做法是分层管理。最近几轮的详细记录保留原文更早的历史做摘要压缩再早的只保留关键决策点和结论。摘要压缩可以用模型来做也可以用规则来做关键是保证压缩后的信息不丢失关键状态。3.2 上下文压缩的三种策略与选择依据上下文压缩我常用三种策略各有适用场景第一种是滑动窗口。只保留最近 N 轮对话更早的直接丢弃。这种策略实现最简单适合任务步骤之间独立性较强的场景。缺点是如果任务需要回溯早期信息就会丢失关键上下文。第二种是摘要压缩。把早期对话交给模型生成摘要用摘要替代原文。这种策略适合任务步骤之间有依赖关系的场景。摘要的质量直接决定压缩效果我一般会要求摘要必须包含已完成的步骤、当前状态、待办事项、关键决策和原因。第三种是结构化状态提取。不保留对话原文而是把任务状态提取成结构化数据比如 JSON 格式的任务进度表。这种策略适合状态明确、步骤可枚举的场景。优点是 token 消耗极低缺点是灵活性差遇到计划外的情况不好处理。实际项目里我通常是三种策略混用最近 3 到 5 轮用滑动窗口保留原文5 到 20 轮用摘要压缩20 轮以上用结构化状态提取。这样既保证了近期上下文的完整性又控制了整体 token 消耗。3.3 检索增强在长任务中的正确用法检索增强在单次问答里用得很多但在长任务 Agent 里检索的时机和内容需要重新设计。单次问答的检索是“用户问什么就检索什么”长任务 Agent 的检索应该是“当前步骤需要什么就检索什么”。我一般会在两个时机触发检索一是任务规划阶段检索与任务相关的背景知识和历史案例二是每个步骤执行前检索与该步骤相关的工具文档、参数说明和注意事项。检索结果不直接塞进上下文而是先做相关性排序和去重只保留 top-k 条最相关的内容。这里有个容易踩的坑检索结果太多会挤占上下文预算太少又可能信息不足。我的经验是每个步骤的检索结果控制在 3 到 5 条每条不超过 2K token。如果检索结果质量不高宁可少放也不要硬塞。注意检索增强的 embedding 模型和生成模型最好分开选型。embedding 模型关注检索准确率生成模型关注推理能力两者的优化目标不一样。4. Loop Engineering让 Agent 知道什么时候该停、什么时候该继续4.1 循环终止条件的四种设计模式Loop Engineering 是长任务 Agent 最核心的工程问题之一。Agent 本质上是一个循环观察 → 思考 → 行动 → 观察。如果终止条件设计不好要么死循环要么提前退出。我总结过四种终止条件设计模式第一种是目标达成终止。Agent 判断任务目标已经完成主动退出循环。这是最理想的终止方式但判断“目标是否达成”本身就是一个难题。我的做法是让 Agent 在每一步之后输出一个完成度评分连续两步评分不再提升且高于阈值时判定为达成。第二种是步数上限终止。设置最大步数超过就强制退出。这是兜底机制防止死循环。步数上限怎么定我的经验是简单任务 10 到 15 步中等任务 20 到 30 步复杂任务 50 步以上。但步数上限不能设得太低否则复杂任务会被误杀。第三种是资源耗尽终止。设置 token 预算或时间预算耗尽就退出。这种模式适合成本敏感的场景。token 预算的计算方式是预估任务平均步数 × 每步平均 token 消耗 × 安全系数 1.5。第四种是异常终止。连续多次工具调用失败、连续多次输出格式错误、或者检测到循环重复模式时主动终止并报告异常。实际项目里这四种模式通常是组合使用的。我的默认配置是目标达成终止为主步数上限和资源耗尽为兜底异常终止为保护。4.2 重试策略与退避算法的参数计算工具调用失败是长任务 Agent 的常态。重试策略设计不好要么重试太频繁导致资源浪费要么重试太保守导致任务失败。我常用的重试策略是指数退避第一次失败后等待 1 秒重试第二次等待 2 秒第三次等待 4 秒以此类推最大等待时间不超过 30 秒。重试次数一般设为 3 次超过 3 次就判定为不可恢复失败触发异常终止或降级处理。但指数退避不是万能的。对于某些错误类型比如参数错误、权限错误重试是没有意义的应该直接失败。对于网络超时、服务暂时不可用这类错误重试才有意义。所以重试策略要配合错误分类使用。我一般会把错误分成三类可重试错误网络超时、限流、不可重试错误参数错误、权限错误、需降级错误服务不可用、依赖缺失。可重试错误走指数退避不可重试错误直接失败需降级错误走备用方案。4.3 循环中的状态检查点设计长任务 Agent 跑到一半崩了如果没有状态检查点就只能从头再来。状态检查点的设计原则是在每个关键步骤完成后保存状态状态要包含恢复执行所需的全部信息。状态检查点至少应该包含当前步骤编号、已完成步骤列表、当前任务状态、关键变量值、下一步计划。保存时机一般选在工具调用成功后、模型输出解析成功后、以及每 N 步强制保存一次。恢复执行时从最近的检查点加载状态重新构建上下文然后从下一步继续执行。这里有个细节恢复执行时上下文里的历史记录可能已经过期需要重新检索或重新摘要。我一般会在恢复时重新生成一份精简的上下文只包含恢复执行必需的信息。提示状态检查点的存储建议用外部存储不要放在内存里。Agent 进程重启后内存状态会丢失外部存储才能保证恢复。5. Graph Engineering多步骤多 Agent 的编排实战5.1 从线性链到状态图的演进逻辑早期的 Agent 编排基本是线性链步骤 A → 步骤 B → 步骤 C。这种结构简单直观但只能处理固定流程的任务。一旦任务需要分支、循环、并行线性链就不够用了。状态图State Graph是目前主流的编排方式。它的核心思想是把 Agent 的执行过程建模成一张有向图节点是执行单元边是状态转移条件。每个节点执行完后根据当前状态决定走哪条边。状态图相比线性链的优势在于支持条件分支、支持循环、支持并行、支持人工介入节点。这些能力在长任务 Agent 里都是必需的。比如一个数据分析任务可能需要先判断数据源类型再决定用哪种查询方式查询失败后可能需要人工确认这些用线性链都很难表达。5.2 节点、边与状态的设计规范设计状态图时我遵循几个规范节点设计规范每个节点只做一件事节点的输入输出要明确。节点类型一般分为LLM 节点调用模型、工具节点调用外部工具、条件节点做判断、人工节点等待人工输入、终止节点结束流程。边设计规范边分为普通边和条件边。普通边表示无条件转移条件边表示根据状态判断转移。条件边的判断逻辑要尽量简单复杂的判断逻辑应该封装成独立的条件节点。状态设计规范状态是整个图的共享数据所有节点都能读写。状态设计要遵循最小必要原则只放节点间需要传递的数据。状态更新要原子化避免多个节点同时写同一个字段导致冲突。我一般会用这样的状态结构state { task_id: xxx, current_step: 3, completed_steps: [step1, step2], task_status: in_progress, variables: {}, history: [], error: None }这个结构简单但够用实际项目里可以根据需要扩展。5.3 多 Agent 协作的三种拓扑结构多 Agent 协作是 Graph Engineering 的进阶话题。我常用三种拓扑结构第一种是主管- worker 结构。一个主管 Agent 负责拆解任务和分配子任务多个 worker Agent 负责执行具体子任务。这种结构适合任务可以明确拆解的场景。主管 Agent 的 Prompt 要重点设计任务拆解逻辑和结果汇总逻辑。第二种是流水线结构。多个 Agent 按顺序处理前一个的输出是后一个的输入。这种结构适合有明确阶段划分的任务比如“检索 → 分析 → 生成报告”。流水线结构的难点在于阶段之间的接口设计输出格式必须严格约定。第三种是辩论结构。多个 Agent 对同一个问题给出不同答案然后通过投票或仲裁得出最终结果。这种结构适合需要多角度验证的场景比如事实核查、方案评估。辩论结构的成本较高一般只在关键决策点使用。选择哪种结构取决于任务的性质。任务可拆解用主管-worker任务有阶段用流水线任务需验证用辩论。实际项目里这三种结构经常混合使用。6. Harness EngineeringAgent 稳定运行的工程保障6.1 沙箱隔离与权限控制的最小实现Harness Engineering 是长任务 Agent 最容易被忽视的工程域。Agent 要调用外部工具、执行代码、访问数据如果没有沙箱隔离和权限控制风险非常大。沙箱隔离的最小实现包括文件系统隔离Agent 只能访问指定目录、网络隔离Agent 只能访问白名单地址、进程隔离Agent 执行的代码在独立进程里跑崩溃不影响主进程、资源限制CPU、内存、执行时间都有上限。权限控制的最小实现包括工具白名单Agent 只能调用授权工具、参数校验工具调用参数要经过校验、操作审计所有工具调用都要记录日志、敏感操作二次确认删除、修改类操作需要人工确认。我见过一个项目Agent 直接在主进程里执行用户输入的代码结果一段死循环代码把整个服务拖垮了。沙箱隔离不是可选项是必选项。6.2 可观测性日志、指标与追踪的三件套Agent 跑在生产环境里出问题是必然的。可观测性决定了你能不能快速定位问题。日志要记录每一步的输入输出、工具调用详情、状态变化、错误信息。日志要结构化方便检索和分析。指标要采集任务成功率、平均步数、平均耗时、token 消耗、工具调用成功率、错误分布。这些指标能帮你发现系统性问题。追踪要覆盖一个任务从开始到结束的完整链路包括每个节点的执行时间、状态转移路径、异常点。追踪能帮你定位单个任务的问题。我一般会用 OpenTelemetry 做追踪用结构化日志做记录用 Prometheus 做指标采集。这三件套搭起来Agent 的运行状态就基本透明了。6.3 并发场景下的资源竞争与隔离Agent 扛并发是个容易被低估的问题。多个任务同时跑会竞争模型调用配额、工具调用资源、存储资源。如果不做隔离一个任务的问题会影响其他任务。我的做法是每个任务分配独立的上下文空间和状态存储工具调用走统一的限流和排队机制模型调用按优先级分配配额。关键资源要做隔离比如代码执行沙箱每个任务一个避免相互影响。并发数怎么定我的经验是先压测单任务的资源消耗再根据总资源反推最大并发数。比如单任务平均消耗 2K token/秒模型配额是 100K token/秒那理论最大并发是 50实际要留 30% 余量所以设 35 左右。7. 常见问题与排查技巧实录7.1 Agent 跑着跑着就忘了前面做过什么这是上下文管理问题。排查思路先看上下文窗口是否溢出再看摘要压缩是否丢失了关键信息最后看状态检查点是否完整。解决方法优化上下文预算分配加强摘要压缩的质量控制确保状态检查点包含完整的任务进度。我一般会在摘要压缩的 Prompt 里明确要求保留“已完成步骤、当前状态、待办事项、关键决策”四类信息。7.2 工具调用失败后 Agent 直接卡死这是循环控制问题。排查思路看重试策略是否生效看错误分类是否正确看是否有降级方案。解决方法完善错误分类可重试错误走指数退避不可重试错误直接失败并触发异常终止需降级错误走备用方案。同时要确保异常终止能正确保存状态方便后续恢复。7.3 多 Agent 协作时状态不一致这是 Graph Engineering 问题。排查思路看状态更新是否原子化看是否有并发写冲突看状态同步机制是否可靠。解决方法状态更新加锁避免并发写状态同步用消息队列或事件总线确保最终一致关键状态做版本控制冲突时以最新版本为准。7.4 常见问题速查表问题现象可能原因排查方向解决方法上下文溢出历史消息未压缩检查上下文预算分层压缩控制 token 消耗死循环终止条件缺失检查循环控制逻辑加步数上限和异常终止提前退出完成度判断过严检查目标达成逻辑调整完成度阈值工具调用失败参数错误或权限不足检查工具配置完善错误分类和重试状态丢失检查点未保存检查状态存储关键步骤后强制保存并发冲突资源未隔离检查资源分配任务级隔离限流排队输出格式错乱输出约束不足检查 Prompt 约束加强格式约束和校验7.5 几个踩过坑才明白的经验第一个经验不要迷信单次问答的效果。单次问答效果好不代表长任务效果好。长任务要单独测试单独调优。第二个经验上下文不是越多越好。塞太多上下文模型反而会抓不住重点。精简、相关、结构化比堆量重要得多。第三个经验终止条件要早设计。不要等 Agent 跑飞了才想起来加终止条件。设计阶段就要把终止条件想清楚。第四个经验可观测性要提前做。不要等出问题了才加日志。Agent 上线前日志、指标、追踪三件套就要到位。第五个经验沙箱隔离不能省。Agent 执行外部代码、调用外部工具风险是实打实的。沙箱隔离是底线不是可选项。8. 从 Prompt 到 HarnessAgent 工程的能力演进路线聊到这里可以把长任务 Agent 的工程能力演进路线梳理一下。第一阶段是 Prompt Engineering解决“怎么让模型理解指令”的问题。第二阶段是 Context Engineering解决“怎么让模型看到正确的信息”的问题。第三阶段是 Loop Engineering解决“怎么让 Agent 持续正确地执行”的问题。第四阶段是 Graph Engineering解决“怎么编排多步骤多 Agent”的问题。第五阶段是 Harness Engineering解决“怎么让 Agent 安全稳定地跑在生产环境”的问题。这五个阶段不是严格串行的实际项目里经常是交叉进行的。但能力建设的优先级是明确的先把 Prompt 和 Context 做扎实再往上做 Loop 和 Graph最后用 Harness 兜底。跳过前面的阶段直接做后面的大概率会返工。我自己在带团队的时候会用这五个域做能力评估。一个 Agent 项目如果只关注 Prompt那工程成熟度大概在 1 到 2 级如果 Prompt、Context、Loop 都做得不错大概在 3 级如果五个域都有覆盖那基本到了 4 到 5 级。大部分团队卡在 2 到 3 级瓶颈往往在 Loop 和 Graph 上。最后分享一个我在实际项目里常用的检查清单每次 Agent 上线前过一遍Prompt 是否有明确的输出格式约束和少样本示例Context 是否有分层压缩策略和 token 预算控制Loop 是否有目标达成、步数上限、资源耗尽、异常终止四重终止条件Graph 是否有清晰的状态定义和条件路由Harness 是否有沙箱隔离、权限控制、可观测性三件套是否有状态检查点和恢复执行机制是否有并发隔离和限流机制是否有完整的错误分类和重试策略这个清单过一遍基本能覆盖长任务 Agent 的主要工程风险点。剩下的就是根据具体业务场景做针对性优化了。