长任务 Agent 的工程化思考
长任务 Agent 的工程化思考
长任务 Agent 真正的难点，不是让模型完成一次任务，而是让它在复杂、不确定、可中断的环境中，稳定地完成大量任务。
写在前面：这些思考来自一次真实的长任务 Agent 实践
我参与一个长任务 Agent 产品，它的产品形态类似千问、豆包这样的 AI 助手，但在前端展示上更加激进：除了传统的文本和 Markdown，还直接引入了 HTML 标签渲染，让 Agent 可以生成更丰富的交互内容和结果页面。
这类产品的体验重点，不只是“回答得像不像人”，还包括任务执行过程是否可见、结果是否可验证、失败后能否恢复，以及长时间运行时用户是否会觉得系统卡住了。因此，项目中相当一部分工作都集中在长任务执行保障层，而不是单纯优化 Prompt。
下面的内容，既是对业务 Agent 工程化的一些总结，也是对这段实践的复盘。
一、从“能完成”到“可生产”
这几年，Agent 的讨论越来越热闹。很多系统都开始尝试让大模型自主规划、调用工具和执行任务，甚至希望它像一个真正的员工一样，独立完成复杂工作。
但在真实业务中，Agent 最难的问题往往不是“能不能完成一次任务”，而是：
- 能不能稳定完成一百次任务？
- 能不能在异常发生时及时止损？
- 能不能解释自己为什么做出某个决定？
- 能不能被监控、回放、评估和持续优化？
- 能不能在权限、数据和业务规则的约束下工作？
这也是长任务 Agent 和普通聊天机器人的根本区别。
普通聊天机器人可以在几轮对话中给出一个看起来不错的答案，而长任务 Agent 往往需要运行数分钟、数小时，甚至数天。它可能需要拆解目标、查询资料、调用多个系统、等待异步结果、处理中间失败，并在后续步骤中继续推进。
因此，长任务 Agent 的核心问题不只是模型能力，而是如何把模型能力放进一个可靠的工程系统中。
二、核心矛盾：在不确定性中维持确定性
业务 Agent 工程化的核心，是在业务流程可控的前提下，合理利用大模型的灵活性。
大模型擅长理解自然语言、提取信息、进行模糊判断、生成内容和处理复杂上下文。但这些能力天然带有不确定性：模型可能理解错误，可能遗漏条件，也可能生成不符合预期的工具参数。
而业务系统通常要求确定性：
- 权限不能越界；
- 金额不能计算错误；
- 状态不能随意跳转；
- 审批不能被绕过；
- 对外输出不能包含敏感信息；
- 失败后必须能够重试或回滚。
所以，工程化 Agent 不是试图消灭模型的不确定性，而是要为模型建立一个可靠的运行边界。
可以把 Agent 系统看成两部分：
外层负责确定性，内层负责灵活性。
外层由工作流、状态机、权限系统、工具网关、校验逻辑、超时机制和审计系统组成；内层才是大模型负责的智能节点。
模型可以决定应该从哪些材料中提取信息，但不应该随意决定是否可以绕过权限访问数据。模型可以生成工具参数，但工具层必须再次校验参数是否合法。模型可以提出下一步建议，但核心业务流程不能完全依赖模型自由发挥。
真正可用的 Agent，不是一个没有边界的智能体，而是一个被工程系统约束住的智能节点。
三、自主规划不是完全放任，而是被任务边界约束
在我们的系统中，核心控制层确实是一个具备自主规划能力的 Agent。它既可以处理相对直接的问题，也可以在面对复杂任务时进行拆解，并通过抽象任务工具创建子 Agent 执行不同子任务。
因此，“外层优先采用 Workflow”不能简单理解为禁止 Agent 自主规划。更准确的说法是：自主规划可以存在于控制层，但规划的入口、任务类型、执行边界和结果验证必须由系统约束。
这种设计看起来灵活，但在业务系统中很难控制：流程路径不可预测，失败后难以恢复，模型可能遗漏关键节点，也容易产生重复调用和无效循环。
对于确定性较强的流程，外层仍然应该优先采用 Workflow；对于任务结构不固定的场景，则可以让父 Agent 进行规划，但只能通过受控的抽象任务工具创建子任务。
Workflow 可以是固定流程，也可以是带有条件分支的流程图。它负责定义：
- 任务有哪些阶段；
- 每个阶段的输入和输出是什么；
- 哪些节点可以并行；
- 哪些节点必须串行；
- 哪些操作需要人工确认；
- 失败后应该重试、降级还是终止；
- 哪些状态需要持久化；
- 哪些结果可以作为后续步骤的依据。
复杂场景可以使用 Graph 编排，简单场景使用过程式代码即可。关键不在于使用什么框架，而在于流程控制权应该掌握在系统手中。
子 Agent 并不是随意创建的，而是基于特定场景和可验证条件进行选择：
- 代码生成场景的流程相对固定，可以使用经过微调的模型；
- 搜索场景基于 RAG 执行搜索，并对搜索结果生成可视化报告；
- 巡检任务场景提交异步任务，由任务调度服务拉起子 Agent 执行，结果再通过 inbox 通知主 Agent；
- 这些场景都相对确定，且结果具有一定的可验证性。
不同子 Agent 使用的模型也不完全一致。模型选择应该服从任务特征，而不是为了架构统一而强行使用同一个模型。
四、长任务必须拥有明确的状态模型
短对话 Agent 可以依赖上下文继续工作，但长任务 Agent 不能只依赖一段对话历史。
一个长任务通常会经历多个状态：
1 | 待开始 → 已拆解 → 执行中 → 等待外部结果 → 部分完成 |
这些状态不能只存在于内存中，而应该被持久化保存。至少需要记录：
- 当前任务状态；
- 已完成的步骤；
- 每一步的输入和输出；
- 工具调用记录；
- 外部任务的关联 ID；
- 重试次数；
- 错误信息；
- 下一次恢复所需的上下文；
- 用户确认或人工介入记录。
状态模型的价值在于：当进程重启、网络中断、模型超时或服务升级时，任务仍然能够继续推进，而不是从头开始。
幂等性比重试更重要
很多系统在失败后会选择重试，但如果操作本身没有幂等性，重试可能带来更严重的问题。
例如，一个“创建订单”的工具在网络超时后，系统无法判断订单是否已经创建成功。如果直接再次调用，就可能产生重复订单。
长任务 Agent 的工具调用应该尽量设计为幂等操作，通常需要请求幂等键、业务唯一号、状态查询接口，以及操作前检查和操作后确认。
一次调用失败，不一定代表业务操作失败。系统必须区分明确失败、明确成功、暂时失败和结果未知。未知状态需要通过查询恢复，而不是简单地再次执行。
五、Agent 的划分应该围绕任务角色
很多团队按照传统业务模块划分 Agent，例如订单 Agent、用户 Agent 和商品 Agent。这种方式并不一定错误，但容易让 Agent 变成传统服务模块的重新包装。
更合理的方式，是围绕用户任务中的角色划分：
- 信息收集 Agent；
- 方案规划 Agent；
- 执行 Agent；
- 审核 Agent；
- 风险控制 Agent；
- 结果解释 Agent。
每个 Agent 都应该拥有清晰的职责边界，避免一个 Agent 同时承担咨询、执行、审批和风控等多种职责。
可以用三个问题判断一个 Agent 是否拆分合理：
- 它是否有一个清晰的任务目标？
- 它是否拥有与目标匹配的工具权限？
- 它的输出是否能够被下游节点验证？
如果一个 Agent 既能读取数据、修改数据，又能做审批决策，还能向用户进行最终回复，那么它很可能承担了过多职责。
六、工具层是 Agent 连接业务系统的关键
Agent 的能力上限，往往取决于它能够安全使用哪些工具。
传统业务接口不应该直接暴露给模型，而应该经过一层面向 Agent 的工具封装。每个工具都需要提供清晰的 name、description、input schema、返回结构、错误语义、权限范围、超时策略和幂等规则。
工具描述不是简单的注释，而是模型理解业务能力的主要依据。一个好的工具应该职责单一，例如：
1 | 查询订单状态 |
而不是提供一个模糊的“处理订单”接口，让模型自行猜测它到底会修改哪些数据。
工具异常也应该返回语义化信息，而不是简单返回 request failed：
1 | { |
这样的返回结果能帮助模型判断是重试、修改参数、查询最新状态、向用户澄清，还是转人工处理。
七、记忆需要有界、异步、可治理
“把所有历史对话都塞进上下文”并不是好的记忆方案。长任务 Agent 的记忆至少可以分为：当前任务状态、短期上下文、用户偏好、用户画像、业务事实、历史操作记录和长期知识。
短期记忆适合保存当前任务所需的信息，可以通过滑动窗口、摘要或状态压缩控制上下文长度。长期偏好则可以异步抽取，不应该阻塞主流程。
尤其需要注意，业务事实不能仅仅从历史对话中推断。订单状态、库存数量、账户余额和权限信息等实时数据，必须通过业务系统查询获得。历史对话只能作为参考，不能作为事实来源。
记忆系统还需要支持查看、修改和删除，并记录来源、时间和可信度。过期信息需要失效，否则错误记忆可能在后续任务中不断放大。
八、模型选择应该服务于任务
长任务 Agent 通常包含很多不同类型的模型调用，没有必要所有节点都使用同一个大模型：
- 简单分类、路由和字段抽取使用小模型；
- 工具参数生成使用结构化输出稳定的模型；
- 复杂推理使用更强的大模型；
- 长上下文总结使用专门优化长文本的模型；
- 高风险决策采用模型加规则或人工复核。
模型选择不能只看单次调用价格，还要考虑延迟、失败率、重试成本、输出稳定性、业务错误代价和上下文长度。
九、生产化保障：并发、可观测与故障隔离
Agent 的请求链路通常更长，依赖更多，因此任何一个下游服务都可能成为瓶颈。生产环境需要重点考虑模型调用队列、工具调用并发控制、异步任务调度、限流与熔断、超时与取消、任务恢复、资源隔离、权限和成本控制。
在实际项目中，我们为 Agent 建立了专门的可观测系统。首先是用 trace 串联整个系统中的会话、异步任务、沙箱和 subagent，从而可以拉取一条任务的完整链路，包括：
- 一次任务的完整链路；
- 模型输入输出；
- 工具调用顺序；
- 每一步耗时；
- Token 使用量；
- 重试次数；
- 状态转移；
- 人工介入点；
- 最终业务结果。
除此之外，链路中还会记录模型输入输出、工具调用结果、耗时 metrics、Token 用量、失败和重试信息，并支持请求回放。对于长任务来说，这种完整链路比单独记录一次 HTTP 请求更加重要，因为真正的问题往往发生在跨服务、跨 Agent 或异步任务之间。
任务本身还需要有明确的状态模型，例如“待执行、已完成、失败、跳过”。状态模型既用于用户界面展示，也用于任务恢复、数据统计和问题排查。
在监控之外，还需要自动探测结果，以及主动 benchmark 巡检。前者用于及时发现线上结果异常，后者用于定期验证 Agent、工具和模型链路是否仍然满足预期。
十、评估不能只看最终回答
Agent 的最终结果正确，并不意味着整个过程可靠；最终结果错误，也不一定代表模型能力不足。因此，评估需要覆盖多个层面：意图识别准确率、信息抽取准确率、工具选择准确率、参数正确率、流程遵循率、状态恢复成功率、无效调用率、任务完成率、平均耗时、平均成本和安全违规率。
目前结果评估主要还是离线完成。我们通过离线评测集验证 Prompt、工具描述、模型版本和流程编排的变化，避免 Agent 的迭代变成“修复一个问题，引入另一个问题”。
对于高风险业务，还需要覆盖恶意输入、工具异常、上下文冲突、外部系统延迟、用户中途取消、权限变化和服务重启等情况。
十一、权限与人工介入是系统设计的一部分
Agent 越能执行任务，风险就越高。权限控制不能只放在 Prompt 中提醒模型，而应该由系统强制执行，包括工具级权限、用户级权限、资源级权限、数据脱敏、敏感字段保护、高风险操作二次确认、审批节点和操作审计。
人工介入也不是 Agent 失败的标志，而是复杂业务中的正常机制。当任务风险超过阈值、模型置信度不足、工具返回未知状态、业务规则冲突或操作不可逆时，系统应该请求人工确认，并提供完整上下文。
在实践中，权限控制主要落在工具层。例如工具只能访问明确授权的 workspace 范围，而不是让模型通过 Prompt 自己“记住”哪些目录可以访问。这样即使模型产生了越权意图，工具层也可以直接拒绝执行。
十二、并发、幂等与异常恢复要落到工具层
长任务系统一定会遇到并发、超时、重复投递和异步结果乱序等问题。异常恢复不能只依赖 Agent 再想一次，而需要在工具层设计幂等语义。
例如，消息推送可以根据 msgId 做幂等；文件生成则需要处理重复匹配和重复替换的问题，通过 search-replace 的语义约束，避免同一个目标被重复修改。对于异步巡检任务，还需要结合任务 ID、状态查询和结果通知机制，确保主 Agent 不会因为重复收到消息而重复处理。
十三、长时间运行需要持续沉淀能力
长任务 Agent 不应该每次都从零开始。一个方向是由 memory 模块异步沉淀长期信息，把任务执行过程中值得保留的事实、偏好和经验提取出来，避免阻塞主流程。
另一个方向是从重复流程中生成 skill：当系统发现某类任务长期以相似方式执行时，可以将稳定流程、工具组合和注意事项沉淀为可复用能力。这个方向目前还没有完全实现，但它可能是 Agent 从“每次临时规划”走向“逐渐形成工作方法”的关键。
十四、流式体验是长任务系统的全栈问题
长任务的用户体验不仅由模型速度决定。即使后端正在正常执行，如果前端长时间没有任何反馈，用户仍然会认为系统卡住了。
在项目中，我们通过流式输出工具参数，让用户能够看到 Agent 正在准备调用什么工具、任务推进到了哪个阶段，从而缓解等待过程中的卡顿感。这里需要前后端一起设计：后端要暴露足够细粒度的事件，前端要将事件转化为用户能理解的状态和结果。
这也是为什么 Agent 产品的前端不能只是一个聊天窗口。直接引入 HTML 标签渲染，本质上是在探索一种更丰富的结果呈现方式：搜索结果可以成为可视化报告，巡检任务可以成为状态面板，复杂执行过程可以成为可交互的任务视图。
一个成熟的 Agent 不是完全不需要人，而是能够在需要人的时候准确地把任务交给人。
结语：Agent 是工程体系中的智能节点
长任务 Agent 不是一个自由行动的大模型，也不是给传统接口套上一层自然语言外壳。
它更像是工程体系中的智能节点：外层用 Workflow 保证确定性，局部用 LLM 提供灵活性；工具层连接真实业务系统，状态系统保证任务可恢复；记忆系统提供必要上下文，权限与审计系统控制风险；观测与评估系统保证持续改进，人工介入机制处理真正的不确定性。
如果把所有问题都交给模型，系统最终会变得不可预测；如果完全拒绝模型的灵活性，Agent 又会退化成普通自动化流程。
真正值得追求的方向，是在确定性和灵活性之间找到合理边界：
让系统负责流程，让模型负责智能；
让工具负责执行，让权限负责约束；
让状态负责恢复，让观测负责追踪。
只有这样，Agent 才能从一次演示中的“看起来很聪明”，逐渐变成能够长期运行、稳定交付、经得起审计的生产系统。