如果一个智能体只能连续执行三次工具调用那么它在五步以上的真实任务里成功率会肉眼可见地下降如果这个任务还需要中途记忆中间结果、出错后自己恢复难度会立刻翻倍。最近在评测圈讨论比较多的 WeaveBench把这类问题直接摆到了台面上长程智能体可靠性尚未真正解决公开榜单里的最佳成绩也只有 41.2%。作为开发者看到一个 benchmark 数字可能只是猎奇但真正要关心的是这个数字是怎么测出来的为什么模型在长程任务里会掉链子以及我们自己接的 Agent 要怎样做才能减少这种掉链子。这篇文章会从概念、基准、评测方法到工程优化逐个拆解并给出一个可以本地运行的可靠性评估 Demo帮助你判断自己接入的 Agent 是否具备“长程作战”能力。1. 什么是长程智能体为什么可靠性是硬门槛1.1 从单轮问答到长程任务长程智能体Long-horizon Agent通常指需要完成多步骤、多工具调用、跨长时间窗口任务的智能体。和单轮问答不同它不能只给一个答案而是要像一个初级员工一样拿着目标清单一步步操作系统、数据库、外部 API最终交付一个完整结果。举个例子用户问“帮我把昨天支付成功但没发货的订单整理成工单并通知仓库处理”基础的问答模型可能只能输出一段处理建议。而一个长程智能体需要先连接订单系统筛选出符合条件的订单再判断库存状态然后创建工单最后推送通知给仓库。整个过程通常要跨 610 个步骤还可能遇到订单状态不一致、库存接口超时、通知失败等意外情况。这类任务的特点是动作链长、外部系统依赖强、中间状态必须被记住。任何一个环节出现偏差后续步骤都会受到影响。所以长程智能体真正的难点不是“理解指令”而是“在多个步骤里保持稳定”。1.2 典型应用场景长程智能体并不是研究玩具在业务系统里已经有非常多的落地场景订单售后处理查询订单、核对售后条件、生成退货单、通知物流每一步都要操作真实系统。故障排查读取日志、检查服务状态、定位异常指标、执行修复脚本最后输出排查报告。跨系统数据核对从多个数据库或 API 拉取数据做字段比对生成差异报告并自动触发修正流程。自动化报表生产定时抓取数据、聚合计算、生成图表、发送邮件需要全链路无人干预。客服投诉闭环识别用户诉求、查询历史工单、分配责任部门、跟踪处理结果直到最终关闭工单。这些场景的共同点是任务可以拆成有依赖关系的子步骤前一步结果会作为后一步输入。也就是说中间状态一旦丢失后面的动作就可能建立在错误前提上。1.3 可靠性的三个考验长程智能体的可靠性可以从三个维度去理解。第一个是状态一致性。任务执行到第 5 步时Agent 是否还记得第 3 步产生的订单编号如果只依赖上下文拼接长对话很容易把关键变量覆盖掉最终导致工具调用参数错误。第二个是累计误差。单步成功率如果是 95%看起来不低但一个 10 步任务整体成功率会变成 0.95 的 10 次方大约只有 59.9%。如果单步成功率降为 90%10 步任务成功率就只剩 34.9%。这就是长程任务让人头疼的地方误差会随步骤指数级累积。第三个是异常恢复。真实系统不可能永远稳定工具调用超时、接口返回格式变化、权限过期都是常态。长程智能体必须能识别异常、安全重试、必要时回退到已知状态。做不到这一点任何一次偶发错误都可能让整个任务失败。2. 认识 WeaveBench一个针对长程任务的可靠性基准2.1 WeaveBench 是什么WeaveBench 是近期社区讨论较多的大模型智能体评测基准核心关注点不是单题正确率而是长程任务中的可靠性。从名称上也能看出它更强调“织网式”的连续任务执行模型需要把多个动作有序串联并且在执行过程中保持目标不偏移。通常这类基准会把一个整体任务拆成多个步骤每个步骤可能涉及工具选择、参数解析、结果校验、状态更新等操作。Agent 必须像真实业务系统里的程序一样逐步完成并最终交付结果。评测者再根据任务完成度、步骤正确性、错误恢复情况给出综合分数。它和传统 QA 基准最大的区别在于“过程即结果”。一道选择题做错了只是分数低长程任务里某一步做错了后续步骤可能全部白做甚至会对真实系统产生副作用。因此 WeaveBench 对模型的过程控制能力要求更高。2.2 为什么关注可靠性而不是答题正确性过去很长一段时间大模型评测都集中在“知识记忆”和“单轮推理”上。这类能力固然重要但真实业务对 Agent 的要求是“能办事”不是“能答题”。单轮问答中模型只需要根据静态输入生成答案不需要承担后续责任。但长程任务中模型每次输出都会触发一个动作比如创建订单、发送消息、修改配置。一次错误的工具调用可能比一次错误的回答造成更严重的后果。所以可靠性比单点正确率更接近生产环境的真实诉求。可靠性还意味着可复现和可解释。一个 Agent 如果能稳定地完成任务那么它的执行日志应该能清楚展示出每一步的输入输出、状态变化和异常处理。如果 Agent 只是偶尔成功用户无法信任它开发者也很难定位问题。2.3 41.2% 意味着什么从目前公开的测试结果来看WeaveBench 榜单上最佳成绩也只有 41.2%。这个数字不是“答题正确率”而是对长程任务完成情况的综合评分可以理解为在最理想的情况下模型也只能高质量完成不到一半的测试任务。换句话说即便使用当前最强的大模型长程任务中仍然有超过一半的场景会出现步骤缺失、状态错乱、工具参数错误或最终结果不达标。这个结果非常真实地反映了长程 Agent 的工程难度模型智商只是下限系统设计和可靠性保障才是上限。同时也提醒我们不要因为模型在单轮评测中表现优异就默认它能把几十步的复杂任务做好。上线前必须做针对性的可靠性评测用数据说话。3. 可靠性评测的核心方法与指标要衡量长程智能体是否可靠不能只看一两个 demo。我们需要一套可以量化的指标覆盖“任务完成率”“步骤正确率”“错误恢复能力”三个方面。3.1 任务级成功率Task Success Rate任务级成功率是最直观的指标计算方式是成功完成任务的数量 / 总任务数量 × 100%一个任务是否算成功通常由最终结果是否满足预期决定。比如订单处理任务最终状态必须是“退货单已创建”并且关键字段与预期一致。如果 Agent 生成了退货单但通知没发严格来说不能算完全成功。这种二元指标非常严格但能避免模型“做了一半就交差”的陷阱。生产环境往往就需要这种确定性要么完成要么不完成不能有模糊地带。3.2 子步骤成功率Step Success Rate在任务级指标之外还需要看过程指标。子步骤成功率是指所有步骤中成功执行的占比。这个指标能反映 Agent 在长链路上的动作质量也能帮助定位问题集中在哪个阶段。例如一个 10 步任务步骤 15 全部成功步骤 6 开始连续出错。任务级成功率会把这个任务判为失败但子步骤成功率仍有 50%说明 Agent 前半段是正常的问题可能出在状态保持或工具切换阶段。子步骤成功率还可以按工具维度拆分。比如查询类工具成功率很高但写操作类工具成功率低则说明模型对“修改类动作”的谨慎度或参数构造能力还不够。3.3 错误恢复率Recovery Rate真实系统永远存在偶发失败所以仅仅看“能否一次成功”并不公平。我们需要关注 Agent 在出错之后能不能自我恢复。错误恢复率可以定义为一个步骤首次执行失败后通过重试、修正参数、切换路径等方式最终成功完成的比例。如果恢复率很高说明 Agent 具备基本的容错能力如果恢复率很低说明一旦出错就会一路错到底。除了恢复率还可以看恢复开销比如平均重试次数、平均额外消耗的步骤数。恢复能力不是越激进越好反复重试同一个错误操作反而会浪费资源因此要结合具体场景设计重试策略。3.4 从 SSD 可靠性测试中借鉴的思维这里可以借鉴存储领域的经验。SSD 读写可靠性测试工具通常会对磁盘进行长时间、高强度的随机读写同时注入断电、坏块、异常中断等场景最后统计写入失败率、坏块增长趋势和重映射扇区数量。存储设备不会因为“单次读写正确”就被判定为可靠而是要看它在整个生命周期中的错误累积情况。长程 Agent 也需要类似的老化测试。评测时不能只跑几条理想路径而应该增加长时间压力测试、随机异常注入、重复任务回归观察错误率是否随时间或步骤数上升。这种思维能帮助我们尽早暴露状态丢失和错误累积问题。4. 环境准备搭建一个长程智能体可靠性评估 Demo理解了指标之后我们用 Python 写一个最小可运行的可靠性评估工具。这个工具不依赖外部大模型服务直接用标准库实现核心是演示如何把 Agent 执行轨迹转换成可靠性指标。你也可以在此基础上接入真实 Agent 的日志。4.1 环境说明操作系统Windows / macOS / Linux 均可Python 版本3.10 及以上三方依赖无使用标准库即可示例文件结构如下long_horizon_reliability/ ├── reliability_evaluator.py └── tasks.json4.2 定义任务集我们先创建一个简单的任务集文件tasks.json用来描述不同长程任务的基本信息。实际评测时任务集会更加复杂这里只做演示{ tasks: [ { id: task_001, name: 查询订单并生成退货单, steps: 6, expected: return_order_created }, { id: task_002, name: 跨系统数据核对, steps: 8, expected: reconcile_ok }, { id: task_003, name: 客户投诉处理闭环, steps: 10, expected: case_closed } ] }expected字段是任务的最终判定标准。实际项目中它可以是 JSON Schema、状态枚举或者一段校验函数。4.3 编写可靠性指标计算器接下来是核心代码reliability_evaluator.py。我们先定义StepRecord和EpisodeRecord两个数据结构分别表示单步执行记录和单个任务执行轨迹。# reliability_evaluator.py from dataclasses import dataclass, field from typing import List, Optional, Dict dataclass class StepRecord: step_id: int tool_name: str ok: bool had_error: bool False error: Optional[str] None retry_count: int 0 dataclass class EpisodeRecord: task_id: str expected: str final_result: Optional[str] success: bool steps: List[StepRecord] field(default_factorylist) def build_episodes() - List[EpisodeRecord]: 构造两个模拟的执行轨迹实际项目中可从日志解析。 ep1 EpisodeRecord( task_idtask_001, expectedreturn_order_created, final_resultreturn_order_created, successTrue, steps[ StepRecord(step_id1, tool_namesearch_order, okTrue), StepRecord(step_id2, tool_namecheck_stock, okTrue), StepRecord( step_id3, tool_namecreate_return_order, okTrue, had_errorTrue, errororder_status_conflict, retry_count1, ), StepRecord(step_id4, tool_namenotify_customer, okTrue), ], ) ep2 EpisodeRecord( task_idtask_002, expectedreconcile_ok, final_resultreconcile_pending, successFalse, steps[ StepRecord(step_id1, tool_namequery_db, okTrue), StepRecord(step_id2, tool_namequery_api, okTrue), StepRecord( step_id3, tool_namecompare_data, okFalse, had_errorTrue, errorfield_mismatch, retry_count2, ), StepRecord( step_id4, tool_namegenerate_report, okFalse, had_errorTrue, errorstate_lost, retry_count0, ), ], ) return [ep1, ep2]然后定义指标计算函数def calculate_reliability_metrics(episodes: List[EpisodeRecord]) - Dict[str, float]: total_episodes len(episodes) if total_episodes 0: return {} task_success sum(1 for ep in episodes if ep.success) total_steps 0 successful_steps 0 total_error_steps 0 total_recovered_steps 0 total_retries 0 for ep in episodes: for step in ep.steps: total_steps 1 total_retries step.retry_count if step.ok: successful_steps 1 if step.had_error: total_error_steps 1 if step.ok: total_recovered_steps 1 return { episodes: total_episodes, task_success_rate: task_success / total_episodes * 100, step_success_rate: successful_steps / total_steps * 100, avg_failures_per_task: (total_steps - successful_steps) / total_episodes, recovery_rate: ( total_recovered_steps / total_error_steps * 100 if total_error_steps 0 else 0.0 ), avg_retries_per_task: total_retries / total_episodes, } def print_metrics(metrics: Dict[str, float]) - None: print( Long-horizon Agent Reliability Metrics ) print(fEpisodes : {metrics.get(episodes, 0)}) print(fTask Success Rate : {metrics.get(task_success_rate, 0):.1f}%) print(fStep Success Rate : {metrics.get(step_success_rate, 0):.1f}%) print(fRecovery Rate : {metrics.get(recovery_rate, 0):.1f}%) print(fAvg Retries/Task : {metrics.get(avg_retries_per_task, 0):.2f}) if __name__ __main__: episodes build_episodes() metrics calculate_reliability_metrics(episodes) print_metrics(metrics)运行命令python3 reliability_evaluator.py预期输出如下 Long-horizon Agent Reliability Metrics Episodes : 2 Task Success Rate : 50.0% Step Success Rate : 75.0% Recovery Rate : 50.0% Avg Retries/Task : 1.504.4 如何接入真实 Agent上面示例使用的是手工构造的轨迹数据。真实场景下你只需要在 Agent 每次调用工具时记录一条结构化日志例如{ task_id: task_001, step_id: 3, tool_name: create_return_order, ok: true, had_error: true, error: order_status_conflict, retry_count: 1, timestamp: 2025-06-01T10:00:05Z }再把同一任务的日志聚合为EpisodeRecord就可以复用calculate_reliability_metrics完成指标统计。关键点是每一步都要有ok、had_error、retry_count字段否则无法计算恢复率。5. 提升长程智能体可靠性的工程手段评测的目的不是打分而是指导改进。下面从工程角度总结几个真正能提升长程智能体可靠性的手段。5.1 把任务拆成显式状态机很多长程 Agent 失败是因为流程隐藏在大模型自由文本输出里没有显式约束。更可靠的做法是把任务流转变成状态机让模型只能在允许的动作集合中选择下一步。下面是一个退货单处理任务的状态机示例from enum import Enum class OrderTaskState(str, Enum): INIT INIT ORDER_SEARCHED ORDER_SEARCHED STOCK_CHECKED STOCK_CHECKED RETURN_CREATED RETURN_CREATED CUSTOMER_NOTIFIED CUSTOMER_NOTIFIED DONE DONE STATE_TRANSITIONS { OrderTaskState.INIT: {search_order}, OrderTaskState.ORDER_SEARCHED: {check_stock}, OrderTaskState.STOCK_CHECKED: {create_return_order}, OrderTaskState.RETURN_CREATED: {notify_customer}, OrderTaskState.CUSTOMER_NOTIFIED: {finish}, OrderTaskState.DONE: set(), } def validate_transition(current: OrderTaskState, action: str) - bool: return action in STATE_TRANSITIONS[current]每次模型输出的动作都必须经过validate_transition校验。如果动作不符合当前状态可以要求模型重新生成或直接判定本步失败。这样可以把一个自由文本生成问题转换成更可控的流程执行问题。5.2 用持久化记忆替代上下文拼接长程任务中中间变量是最容易丢失的。与其让模型从超长上下文里找出某个订单号不如把关键状态持久化到外部存储并在每次工具调用前把需要的信息注入到提示词中。建议维护一个MemoryStore用来保存任务级变量class MemoryStore: def __init__(self): self._store {} def set(self, key: str, value) - None: self._store[key] value def get(self, key: str, defaultNone): return self._store.get(key, default) def snapshot(self) - dict: return dict(self._store)在流程开始时创建快照在每个关键节点后更新变量在失败恢复时回滚到最近一次有效快照。这样即使模型上下文被截断关键状态仍然可控。5.3 工具调用加校验层模型生成的工具参数不一定合法。直接调用外部 API 之前必须经过参数校验层包括必填字段检查、枚举范围检查、权限校验和幂等校验。尤其是创建订单、发送消息这类写操作还要加上业务前置条件判断。校验层可以是一个独立的 Python 函数也可以封装成轻量 JSON Schema。好处是即使模型生成了错误参数也能在调用外部系统前拦截下来避免造成不可逆影响。同时校验失败信息可以作为错误回传给模型引导它修正参数。5.4 设计回退与人工兜底不管工程做得多完善模型仍然可能失败。因此长程 Agent 必须设计回退策略和人工兜底通道。常见做法是设置最大重试次数和最大错误步骤数超过阈值后自动进入“人工处理”队列。对于安全敏感操作比如退款、删数据、修改权限更应在执行前要求二次确认。即便 Agent 自动化程度很高也要保留人工审核的入口。最小权限原则同样重要Agent 使用的 API Key 只授予当前任务所需的最小权限避免一个错误调用导致大范围影响。5.5 日志追踪与自动化回归可靠性问题往往在特定步骤组合下才会暴露。因此日志必须完整记录每一步的输入、输出、错误、重试次数和耗时方便事后复盘。建议每轮执行生成一个trace_id贯穿整条链路。另外要建立自动化回归测试集。每次升级模型或修改 prompt 后都在同一批长程任务上重新跑一遍评测对比任务成功率、步骤成功率和恢复率。只有指标没有下降才能放心发布新版本。6. 常见问题与排查思路在实际搭建长程智能体时会碰到各种看似随机的问题。下面整理一张排查表供快速定位。问题现象常见原因解决思路Agent 执行到第 5 步后开始混乱上下文过长导致关键状态丢失将中间变量写入外部存储控制上下文长度反复调用同一个失败工具缺少重试上限和失败标记记录每一步错误信息超过阈值后切换策略失败后无法继续没有状态回滚点在关键节点保存快照失败时恢复到最近有效状态工具参数格式不稳定模型输出自由度过高增加参数校验层使用 JSON Schema 校验不同运行环境下结果差异大提示词或依赖版本漂移统一依赖版本固定模型参数与随机种子单步成功率高但整体成功率低错误累积效应按子步骤拆分监控优先修复错误率较高的步骤这些问题的共同根源往往是“把模型当成了流程本身而没有把流程固化到工程系统里”。长程 Agent 越接近生产环境就越需要一个可靠的外壳来约束模型行为。7. 最佳实践与工程建议结合前面的分析这里列出几条长程智能体上线的工程建议避免你在生产环境踩坑。第一永远先定义“什么算成功”。在开发之前就把验收标准写清楚可以是一个状态枚举、一段 JSON Schema或者一个自定义校验函数。没有明确验收标准的任务无法做可靠性评测也无法继续优化。第二用数据驱动优化不要靠感觉调 prompt。跑一套长程任务评测记录每个任务的失败步骤和错误类型优先修复出现频率最高的问题。比如 70% 的错误都是因为日期格式解析失败那就在校验层做统一格式化。第三把重试、超时、幂等做成基础设施。几乎所有长程任务都会遇到外部服务不稳定重试机制不能只写在 prompt 里而应该在工程层统一实现。写操作必须提供幂等键避免重复执行产生重复订单或重复通知。第四控制模型自由度。不要让模型直接输出最终 JSON而是让它输出工具调用意图由程序负责参数映射和格式标准化。模型越自由系统越脆弱。第五建立安全边界。Agent 执行过程中可能触达敏感数据必须做好权限隔离和审计日志。上线前使用最小权限账号进行灰度测试确认没有越权行为后再放开权限。第六持续回归。模型升级、提示词调整、工具接口变更都会影响长程可靠性。建议把评测脚本接入 CI/CD在每次变更后自动运行一组长程任务确保关键指标不回退。8. 下一步实践建议如果你现在正准备上线一个长程 Agent建议别急着写业务逻辑先把可靠性评测脚本跑起来。不需要一开始就复现 WeaveBench 的完整任务集可以从自己业务里的 10 个典型长任务开始记录每次执行的成功率、失败步骤和恢复情况。根据这些数据优先解决“错误率最高”“影响最大”的环节逐步把模型的自由决策压缩到最小必要范围。等单步成功率提升到 98% 以上后再通过状态机、持久化记忆和人工兜底把任务级成功率拉高。长程智能体可靠性的提升本质上是一个系统工程问题。模型能力会持续进步但评测方法、流程约束和兜底机制才是决定它能不能真正落地到生产环境的关键。希望这篇文章能帮你建立一套自己的可靠性评估与优化框架在长程任务里少踩一些坑也早日跑出比 41.2% 更让人安心的成绩。
长程智能体可靠性评测与优化：从WeaveBench到工程实践
如果一个智能体只能连续执行三次工具调用那么它在五步以上的真实任务里成功率会肉眼可见地下降如果这个任务还需要中途记忆中间结果、出错后自己恢复难度会立刻翻倍。最近在评测圈讨论比较多的 WeaveBench把这类问题直接摆到了台面上长程智能体可靠性尚未真正解决公开榜单里的最佳成绩也只有 41.2%。作为开发者看到一个 benchmark 数字可能只是猎奇但真正要关心的是这个数字是怎么测出来的为什么模型在长程任务里会掉链子以及我们自己接的 Agent 要怎样做才能减少这种掉链子。这篇文章会从概念、基准、评测方法到工程优化逐个拆解并给出一个可以本地运行的可靠性评估 Demo帮助你判断自己接入的 Agent 是否具备“长程作战”能力。1. 什么是长程智能体为什么可靠性是硬门槛1.1 从单轮问答到长程任务长程智能体Long-horizon Agent通常指需要完成多步骤、多工具调用、跨长时间窗口任务的智能体。和单轮问答不同它不能只给一个答案而是要像一个初级员工一样拿着目标清单一步步操作系统、数据库、外部 API最终交付一个完整结果。举个例子用户问“帮我把昨天支付成功但没发货的订单整理成工单并通知仓库处理”基础的问答模型可能只能输出一段处理建议。而一个长程智能体需要先连接订单系统筛选出符合条件的订单再判断库存状态然后创建工单最后推送通知给仓库。整个过程通常要跨 610 个步骤还可能遇到订单状态不一致、库存接口超时、通知失败等意外情况。这类任务的特点是动作链长、外部系统依赖强、中间状态必须被记住。任何一个环节出现偏差后续步骤都会受到影响。所以长程智能体真正的难点不是“理解指令”而是“在多个步骤里保持稳定”。1.2 典型应用场景长程智能体并不是研究玩具在业务系统里已经有非常多的落地场景订单售后处理查询订单、核对售后条件、生成退货单、通知物流每一步都要操作真实系统。故障排查读取日志、检查服务状态、定位异常指标、执行修复脚本最后输出排查报告。跨系统数据核对从多个数据库或 API 拉取数据做字段比对生成差异报告并自动触发修正流程。自动化报表生产定时抓取数据、聚合计算、生成图表、发送邮件需要全链路无人干预。客服投诉闭环识别用户诉求、查询历史工单、分配责任部门、跟踪处理结果直到最终关闭工单。这些场景的共同点是任务可以拆成有依赖关系的子步骤前一步结果会作为后一步输入。也就是说中间状态一旦丢失后面的动作就可能建立在错误前提上。1.3 可靠性的三个考验长程智能体的可靠性可以从三个维度去理解。第一个是状态一致性。任务执行到第 5 步时Agent 是否还记得第 3 步产生的订单编号如果只依赖上下文拼接长对话很容易把关键变量覆盖掉最终导致工具调用参数错误。第二个是累计误差。单步成功率如果是 95%看起来不低但一个 10 步任务整体成功率会变成 0.95 的 10 次方大约只有 59.9%。如果单步成功率降为 90%10 步任务成功率就只剩 34.9%。这就是长程任务让人头疼的地方误差会随步骤指数级累积。第三个是异常恢复。真实系统不可能永远稳定工具调用超时、接口返回格式变化、权限过期都是常态。长程智能体必须能识别异常、安全重试、必要时回退到已知状态。做不到这一点任何一次偶发错误都可能让整个任务失败。2. 认识 WeaveBench一个针对长程任务的可靠性基准2.1 WeaveBench 是什么WeaveBench 是近期社区讨论较多的大模型智能体评测基准核心关注点不是单题正确率而是长程任务中的可靠性。从名称上也能看出它更强调“织网式”的连续任务执行模型需要把多个动作有序串联并且在执行过程中保持目标不偏移。通常这类基准会把一个整体任务拆成多个步骤每个步骤可能涉及工具选择、参数解析、结果校验、状态更新等操作。Agent 必须像真实业务系统里的程序一样逐步完成并最终交付结果。评测者再根据任务完成度、步骤正确性、错误恢复情况给出综合分数。它和传统 QA 基准最大的区别在于“过程即结果”。一道选择题做错了只是分数低长程任务里某一步做错了后续步骤可能全部白做甚至会对真实系统产生副作用。因此 WeaveBench 对模型的过程控制能力要求更高。2.2 为什么关注可靠性而不是答题正确性过去很长一段时间大模型评测都集中在“知识记忆”和“单轮推理”上。这类能力固然重要但真实业务对 Agent 的要求是“能办事”不是“能答题”。单轮问答中模型只需要根据静态输入生成答案不需要承担后续责任。但长程任务中模型每次输出都会触发一个动作比如创建订单、发送消息、修改配置。一次错误的工具调用可能比一次错误的回答造成更严重的后果。所以可靠性比单点正确率更接近生产环境的真实诉求。可靠性还意味着可复现和可解释。一个 Agent 如果能稳定地完成任务那么它的执行日志应该能清楚展示出每一步的输入输出、状态变化和异常处理。如果 Agent 只是偶尔成功用户无法信任它开发者也很难定位问题。2.3 41.2% 意味着什么从目前公开的测试结果来看WeaveBench 榜单上最佳成绩也只有 41.2%。这个数字不是“答题正确率”而是对长程任务完成情况的综合评分可以理解为在最理想的情况下模型也只能高质量完成不到一半的测试任务。换句话说即便使用当前最强的大模型长程任务中仍然有超过一半的场景会出现步骤缺失、状态错乱、工具参数错误或最终结果不达标。这个结果非常真实地反映了长程 Agent 的工程难度模型智商只是下限系统设计和可靠性保障才是上限。同时也提醒我们不要因为模型在单轮评测中表现优异就默认它能把几十步的复杂任务做好。上线前必须做针对性的可靠性评测用数据说话。3. 可靠性评测的核心方法与指标要衡量长程智能体是否可靠不能只看一两个 demo。我们需要一套可以量化的指标覆盖“任务完成率”“步骤正确率”“错误恢复能力”三个方面。3.1 任务级成功率Task Success Rate任务级成功率是最直观的指标计算方式是成功完成任务的数量 / 总任务数量 × 100%一个任务是否算成功通常由最终结果是否满足预期决定。比如订单处理任务最终状态必须是“退货单已创建”并且关键字段与预期一致。如果 Agent 生成了退货单但通知没发严格来说不能算完全成功。这种二元指标非常严格但能避免模型“做了一半就交差”的陷阱。生产环境往往就需要这种确定性要么完成要么不完成不能有模糊地带。3.2 子步骤成功率Step Success Rate在任务级指标之外还需要看过程指标。子步骤成功率是指所有步骤中成功执行的占比。这个指标能反映 Agent 在长链路上的动作质量也能帮助定位问题集中在哪个阶段。例如一个 10 步任务步骤 15 全部成功步骤 6 开始连续出错。任务级成功率会把这个任务判为失败但子步骤成功率仍有 50%说明 Agent 前半段是正常的问题可能出在状态保持或工具切换阶段。子步骤成功率还可以按工具维度拆分。比如查询类工具成功率很高但写操作类工具成功率低则说明模型对“修改类动作”的谨慎度或参数构造能力还不够。3.3 错误恢复率Recovery Rate真实系统永远存在偶发失败所以仅仅看“能否一次成功”并不公平。我们需要关注 Agent 在出错之后能不能自我恢复。错误恢复率可以定义为一个步骤首次执行失败后通过重试、修正参数、切换路径等方式最终成功完成的比例。如果恢复率很高说明 Agent 具备基本的容错能力如果恢复率很低说明一旦出错就会一路错到底。除了恢复率还可以看恢复开销比如平均重试次数、平均额外消耗的步骤数。恢复能力不是越激进越好反复重试同一个错误操作反而会浪费资源因此要结合具体场景设计重试策略。3.4 从 SSD 可靠性测试中借鉴的思维这里可以借鉴存储领域的经验。SSD 读写可靠性测试工具通常会对磁盘进行长时间、高强度的随机读写同时注入断电、坏块、异常中断等场景最后统计写入失败率、坏块增长趋势和重映射扇区数量。存储设备不会因为“单次读写正确”就被判定为可靠而是要看它在整个生命周期中的错误累积情况。长程 Agent 也需要类似的老化测试。评测时不能只跑几条理想路径而应该增加长时间压力测试、随机异常注入、重复任务回归观察错误率是否随时间或步骤数上升。这种思维能帮助我们尽早暴露状态丢失和错误累积问题。4. 环境准备搭建一个长程智能体可靠性评估 Demo理解了指标之后我们用 Python 写一个最小可运行的可靠性评估工具。这个工具不依赖外部大模型服务直接用标准库实现核心是演示如何把 Agent 执行轨迹转换成可靠性指标。你也可以在此基础上接入真实 Agent 的日志。4.1 环境说明操作系统Windows / macOS / Linux 均可Python 版本3.10 及以上三方依赖无使用标准库即可示例文件结构如下long_horizon_reliability/ ├── reliability_evaluator.py └── tasks.json4.2 定义任务集我们先创建一个简单的任务集文件tasks.json用来描述不同长程任务的基本信息。实际评测时任务集会更加复杂这里只做演示{ tasks: [ { id: task_001, name: 查询订单并生成退货单, steps: 6, expected: return_order_created }, { id: task_002, name: 跨系统数据核对, steps: 8, expected: reconcile_ok }, { id: task_003, name: 客户投诉处理闭环, steps: 10, expected: case_closed } ] }expected字段是任务的最终判定标准。实际项目中它可以是 JSON Schema、状态枚举或者一段校验函数。4.3 编写可靠性指标计算器接下来是核心代码reliability_evaluator.py。我们先定义StepRecord和EpisodeRecord两个数据结构分别表示单步执行记录和单个任务执行轨迹。# reliability_evaluator.py from dataclasses import dataclass, field from typing import List, Optional, Dict dataclass class StepRecord: step_id: int tool_name: str ok: bool had_error: bool False error: Optional[str] None retry_count: int 0 dataclass class EpisodeRecord: task_id: str expected: str final_result: Optional[str] success: bool steps: List[StepRecord] field(default_factorylist) def build_episodes() - List[EpisodeRecord]: 构造两个模拟的执行轨迹实际项目中可从日志解析。 ep1 EpisodeRecord( task_idtask_001, expectedreturn_order_created, final_resultreturn_order_created, successTrue, steps[ StepRecord(step_id1, tool_namesearch_order, okTrue), StepRecord(step_id2, tool_namecheck_stock, okTrue), StepRecord( step_id3, tool_namecreate_return_order, okTrue, had_errorTrue, errororder_status_conflict, retry_count1, ), StepRecord(step_id4, tool_namenotify_customer, okTrue), ], ) ep2 EpisodeRecord( task_idtask_002, expectedreconcile_ok, final_resultreconcile_pending, successFalse, steps[ StepRecord(step_id1, tool_namequery_db, okTrue), StepRecord(step_id2, tool_namequery_api, okTrue), StepRecord( step_id3, tool_namecompare_data, okFalse, had_errorTrue, errorfield_mismatch, retry_count2, ), StepRecord( step_id4, tool_namegenerate_report, okFalse, had_errorTrue, errorstate_lost, retry_count0, ), ], ) return [ep1, ep2]然后定义指标计算函数def calculate_reliability_metrics(episodes: List[EpisodeRecord]) - Dict[str, float]: total_episodes len(episodes) if total_episodes 0: return {} task_success sum(1 for ep in episodes if ep.success) total_steps 0 successful_steps 0 total_error_steps 0 total_recovered_steps 0 total_retries 0 for ep in episodes: for step in ep.steps: total_steps 1 total_retries step.retry_count if step.ok: successful_steps 1 if step.had_error: total_error_steps 1 if step.ok: total_recovered_steps 1 return { episodes: total_episodes, task_success_rate: task_success / total_episodes * 100, step_success_rate: successful_steps / total_steps * 100, avg_failures_per_task: (total_steps - successful_steps) / total_episodes, recovery_rate: ( total_recovered_steps / total_error_steps * 100 if total_error_steps 0 else 0.0 ), avg_retries_per_task: total_retries / total_episodes, } def print_metrics(metrics: Dict[str, float]) - None: print( Long-horizon Agent Reliability Metrics ) print(fEpisodes : {metrics.get(episodes, 0)}) print(fTask Success Rate : {metrics.get(task_success_rate, 0):.1f}%) print(fStep Success Rate : {metrics.get(step_success_rate, 0):.1f}%) print(fRecovery Rate : {metrics.get(recovery_rate, 0):.1f}%) print(fAvg Retries/Task : {metrics.get(avg_retries_per_task, 0):.2f}) if __name__ __main__: episodes build_episodes() metrics calculate_reliability_metrics(episodes) print_metrics(metrics)运行命令python3 reliability_evaluator.py预期输出如下 Long-horizon Agent Reliability Metrics Episodes : 2 Task Success Rate : 50.0% Step Success Rate : 75.0% Recovery Rate : 50.0% Avg Retries/Task : 1.504.4 如何接入真实 Agent上面示例使用的是手工构造的轨迹数据。真实场景下你只需要在 Agent 每次调用工具时记录一条结构化日志例如{ task_id: task_001, step_id: 3, tool_name: create_return_order, ok: true, had_error: true, error: order_status_conflict, retry_count: 1, timestamp: 2025-06-01T10:00:05Z }再把同一任务的日志聚合为EpisodeRecord就可以复用calculate_reliability_metrics完成指标统计。关键点是每一步都要有ok、had_error、retry_count字段否则无法计算恢复率。5. 提升长程智能体可靠性的工程手段评测的目的不是打分而是指导改进。下面从工程角度总结几个真正能提升长程智能体可靠性的手段。5.1 把任务拆成显式状态机很多长程 Agent 失败是因为流程隐藏在大模型自由文本输出里没有显式约束。更可靠的做法是把任务流转变成状态机让模型只能在允许的动作集合中选择下一步。下面是一个退货单处理任务的状态机示例from enum import Enum class OrderTaskState(str, Enum): INIT INIT ORDER_SEARCHED ORDER_SEARCHED STOCK_CHECKED STOCK_CHECKED RETURN_CREATED RETURN_CREATED CUSTOMER_NOTIFIED CUSTOMER_NOTIFIED DONE DONE STATE_TRANSITIONS { OrderTaskState.INIT: {search_order}, OrderTaskState.ORDER_SEARCHED: {check_stock}, OrderTaskState.STOCK_CHECKED: {create_return_order}, OrderTaskState.RETURN_CREATED: {notify_customer}, OrderTaskState.CUSTOMER_NOTIFIED: {finish}, OrderTaskState.DONE: set(), } def validate_transition(current: OrderTaskState, action: str) - bool: return action in STATE_TRANSITIONS[current]每次模型输出的动作都必须经过validate_transition校验。如果动作不符合当前状态可以要求模型重新生成或直接判定本步失败。这样可以把一个自由文本生成问题转换成更可控的流程执行问题。5.2 用持久化记忆替代上下文拼接长程任务中中间变量是最容易丢失的。与其让模型从超长上下文里找出某个订单号不如把关键状态持久化到外部存储并在每次工具调用前把需要的信息注入到提示词中。建议维护一个MemoryStore用来保存任务级变量class MemoryStore: def __init__(self): self._store {} def set(self, key: str, value) - None: self._store[key] value def get(self, key: str, defaultNone): return self._store.get(key, default) def snapshot(self) - dict: return dict(self._store)在流程开始时创建快照在每个关键节点后更新变量在失败恢复时回滚到最近一次有效快照。这样即使模型上下文被截断关键状态仍然可控。5.3 工具调用加校验层模型生成的工具参数不一定合法。直接调用外部 API 之前必须经过参数校验层包括必填字段检查、枚举范围检查、权限校验和幂等校验。尤其是创建订单、发送消息这类写操作还要加上业务前置条件判断。校验层可以是一个独立的 Python 函数也可以封装成轻量 JSON Schema。好处是即使模型生成了错误参数也能在调用外部系统前拦截下来避免造成不可逆影响。同时校验失败信息可以作为错误回传给模型引导它修正参数。5.4 设计回退与人工兜底不管工程做得多完善模型仍然可能失败。因此长程 Agent 必须设计回退策略和人工兜底通道。常见做法是设置最大重试次数和最大错误步骤数超过阈值后自动进入“人工处理”队列。对于安全敏感操作比如退款、删数据、修改权限更应在执行前要求二次确认。即便 Agent 自动化程度很高也要保留人工审核的入口。最小权限原则同样重要Agent 使用的 API Key 只授予当前任务所需的最小权限避免一个错误调用导致大范围影响。5.5 日志追踪与自动化回归可靠性问题往往在特定步骤组合下才会暴露。因此日志必须完整记录每一步的输入、输出、错误、重试次数和耗时方便事后复盘。建议每轮执行生成一个trace_id贯穿整条链路。另外要建立自动化回归测试集。每次升级模型或修改 prompt 后都在同一批长程任务上重新跑一遍评测对比任务成功率、步骤成功率和恢复率。只有指标没有下降才能放心发布新版本。6. 常见问题与排查思路在实际搭建长程智能体时会碰到各种看似随机的问题。下面整理一张排查表供快速定位。问题现象常见原因解决思路Agent 执行到第 5 步后开始混乱上下文过长导致关键状态丢失将中间变量写入外部存储控制上下文长度反复调用同一个失败工具缺少重试上限和失败标记记录每一步错误信息超过阈值后切换策略失败后无法继续没有状态回滚点在关键节点保存快照失败时恢复到最近有效状态工具参数格式不稳定模型输出自由度过高增加参数校验层使用 JSON Schema 校验不同运行环境下结果差异大提示词或依赖版本漂移统一依赖版本固定模型参数与随机种子单步成功率高但整体成功率低错误累积效应按子步骤拆分监控优先修复错误率较高的步骤这些问题的共同根源往往是“把模型当成了流程本身而没有把流程固化到工程系统里”。长程 Agent 越接近生产环境就越需要一个可靠的外壳来约束模型行为。7. 最佳实践与工程建议结合前面的分析这里列出几条长程智能体上线的工程建议避免你在生产环境踩坑。第一永远先定义“什么算成功”。在开发之前就把验收标准写清楚可以是一个状态枚举、一段 JSON Schema或者一个自定义校验函数。没有明确验收标准的任务无法做可靠性评测也无法继续优化。第二用数据驱动优化不要靠感觉调 prompt。跑一套长程任务评测记录每个任务的失败步骤和错误类型优先修复出现频率最高的问题。比如 70% 的错误都是因为日期格式解析失败那就在校验层做统一格式化。第三把重试、超时、幂等做成基础设施。几乎所有长程任务都会遇到外部服务不稳定重试机制不能只写在 prompt 里而应该在工程层统一实现。写操作必须提供幂等键避免重复执行产生重复订单或重复通知。第四控制模型自由度。不要让模型直接输出最终 JSON而是让它输出工具调用意图由程序负责参数映射和格式标准化。模型越自由系统越脆弱。第五建立安全边界。Agent 执行过程中可能触达敏感数据必须做好权限隔离和审计日志。上线前使用最小权限账号进行灰度测试确认没有越权行为后再放开权限。第六持续回归。模型升级、提示词调整、工具接口变更都会影响长程可靠性。建议把评测脚本接入 CI/CD在每次变更后自动运行一组长程任务确保关键指标不回退。8. 下一步实践建议如果你现在正准备上线一个长程 Agent建议别急着写业务逻辑先把可靠性评测脚本跑起来。不需要一开始就复现 WeaveBench 的完整任务集可以从自己业务里的 10 个典型长任务开始记录每次执行的成功率、失败步骤和恢复情况。根据这些数据优先解决“错误率最高”“影响最大”的环节逐步把模型的自由决策压缩到最小必要范围。等单步成功率提升到 98% 以上后再通过状态机、持久化记忆和人工兜底把任务级成功率拉高。长程智能体可靠性的提升本质上是一个系统工程问题。模型能力会持续进步但评测方法、流程约束和兜底机制才是决定它能不能真正落地到生产环境的关键。希望这篇文章能帮你建立一套自己的可靠性评估与优化框架在长程任务里少踩一些坑也早日跑出比 41.2% 更让人安心的成绩。
