# 单步成功率 99%，十步之后只剩九成：Agent 工作流的可靠性是谁在保证

把单次调用做到 99% 成功率，很多团队都觉得够稳了。可一段十步的 Agent 任务跑完，成功率只剩约 90%；把单步压到 95%，十步之后连六成都不到。这不是模型不行，而是可靠性在链条上按乘法累积。看懂这笔账，才知道 Agent 的稳定性该往哪里投。
## 一、可靠性是乘出来的，不是加出来的

一条任务链的成功率，是每一步成功率的乘积。这个规律很朴素，后果却不轻：
- 单步 99%，走 5 步还有 95.1%，10 步剩 90.4%，20 步掉到 81.8%。
- 单步 98%，10 步剩 81.7%，20 步只剩 66.8%。
- 单步 95%，10 步剩 59.9%，20 步只剩 35.8%。

![单步成功率高，串成一条链之后的衰减](https://developer.qcloudimg.com/http-save/yehe-12517049/582db9ec30f5e1ddb1f787f53d5da1b9.png)单步成功率高，串成一条链之后的衰减真实业务里的 Agent 任务，动辄十几二十次模型与工具调用：一次代码修复要读文件、跑测试、改代码、再验证；一次客服工单要识意图、查订单、核规则、写回复。于是“每一步都还行”的链路，跑成整体就明显掉队。
更麻烦的是，单步那 1% 的失败不会平均分布在链路上，它会往两个方向放大。一种是中断，任务直接停在中间，至少还能看见；另一种更隐蔽——失败被当成正常结果写回上下文，模型拿着错误的信息继续往下推。后一种不报错，却会把一次失败变成一串错误。
## 二、同一个模型，换一套运行框架能差 20 个百分点

既然稳定性是工程问题，那第一刀就不该砍在模型上，而该砍在模型外面那套东西上。这套东西在 2026 年有了正式的名字：Harness。行业里把它缩成一句公式——Agent = Model + Harness，模型提供能力，harness 决定这份能力在真实任务里能发挥几成。
三组公开的对照实验都很说明问题：
- marmelab 审计了 246 个仓库，同一个模型、相同的 25 项任务，只在 8 种不同的 harness 配置下运行，任务成功率从 68% 到 88% 不等。
- LangChain 的编码 Agent 把 Terminal Bench 2.0 的成绩从 52.8% 提到 66.5%，模型权重一个字节没改，动的是系统提示词、工具定义、中间件和验证循环。
- GLM-5.1 在 100 项 SWE-bench Verified 任务上，只调整模型能看到的上下文、可调用的工具和失败后的反馈，成功率从 52.5% 升到 65.5%。

![同一个模型，换一套运行框架的成绩差](https://developer.qcloudimg.com/http-save/yehe-12517049/9c9d89e8c192b8d5b8b27ec05fb5784c.png)同一个模型，换一套运行框架的成绩差同一颗模型，成绩能差十几个到二十个百分点。这说明模型能力正在被商品化——当大家都能用到同一档模型时，差距就落在谁把上下文组织得更干净、工具接得更规范、失败反馈得更清楚。
## 三、一次工具调用里，有四件事必须做对

把链条拆开看，Agent 的每一步都是“从产生意图到把结果写回上下文”的一次触达。这段路只有四件事，但每一件都容易草草了事：
- 检索：在模型开口之前，先把它能选的工具收敛到一个可控范围。工具从十个涨到六十个，描述开始互相重叠，“查订单”和“查订单详情”就会选错。
- 鉴权：把调用者身份一路带下去，能按能力、按参数范围做限制。只做接口层的服务账号鉴权，一句“帮我查下隔壁部门的单”就真能查出来。
- 执行：超时设多少、重试几次、哪些能重试，都是工程判断。把超时统一设成 30 秒，查询类接口能把线程池占满，反过来拖死整条链路。
- 回执：把原始 JSON 裁剪、归一化，再把 `{"code": 50001}` 这类业务错误码翻译成模型能懂的话。直接塞回去，既浪费 Token，又容易让模型把失败当成数据。

四件事里，最容易被低估的是回执。错误信息其实是写给模型的重试指令：一句“调用失败”只会让模型放弃或盲目重试，而“参数 user_id 应为 UUID，你传的是用户名”能让它下一轮直接改对。模型表现出的自我修复能力，很多时候不是它变聪明了，而是错误信息里带着修复指令。
## 四、重试分三层，越小的事越往下沉

既然会失败，就要重试。但重试不能一把抓，得按错误的性质分层，各管各的：
![重试的三层分工](https://developer.qcloudimg.com/http-save/yehe-12517049/9bc736cc6de384f0fa570eccd071cd82.png)重试的三层分工- 工具层管瞬时故障。网络抖动、限流、超时，在工具实现内部自动重试，指数退避两到三次，对模型完全透明。模型不该为基础设施的抖动浪费推理轮次。
- 模型层管语义错误。参数传错、逻辑走偏，让模型读着错误信息自己修正。但这一层要设上限，同一个工具连续失败三次就停，否则会陷入死循环、白烧 Token。
- 编排层兜住全链失败。整条任务链反复失败之后，降级到更简单的路径、换工具、换模型，或者干脆转人工。

越往上层重试越贵。能在工具层消掉的抖动，就别让它上升到模型层，更别让它惊动整条编排链。
## 五、工具不是越多越好

模型的每一次选择，都是在候选工具里做判断。候选越多，判断越容易偏。经验上，工具数量控制在 10 到 20 个以内比较稳；到 30 个以上，模型的选择准确率会开始出现可测量的下降。超过这个量级，得先分组，让主 Agent 路由到持有小组工具的子 Agent。
粒度也要拿捏。太粗的工具是个坑，比如一个 execute_task(type, params) 的“万能接口”，参数全靠模型猜；太细同样不行，每件小事一个工具，模型要在几十个工具里规划调用链，而总成功率是各步的乘积，步骤越多越脆。比较稳的切法是按“一次业务动作”为单位：查订单是一个工具，内部查了主表又查物流，对外只暴露一个入口。
## 六、幂等是重试的前提

有一件事得先做对，再谈重试：幂等。
不幂等的写操作，配上自动重试，等于重复下单。真实事故里并不少见：模型判断“这笔转人工”，调用建单接口超时后重试了一次，系统里立起三个工单，来了三个客服；或者异步发送的提示接口返回 200，那只是“已入队”，真正的投递悄悄失败，没有回执落到系统里——用户干等，系统以为成功。
这类问题的讨厌之处在于低频、难复现、影响面大，写业务逻辑时很难想到，真跑起来才暴露。工程上的做法也直接：所有写操作带上幂等键或请求指纹，重试命中同一次业务动作就自动去重；异步链路必须等到最终回执，再更新业务状态。这一层不做，前面所有的重试设计都是在给自己埋雷。
## 七、看不见的失败，最难修

失败率压下来之后，剩下的是排查成本。一次失败会话，网关日志、应用日志、模型输入输出散在三个系统里，时间戳还对不齐，一个报障花掉半小时，一天来三个就报废半天。
所以生产级的 Agent 要有一套可观测体系，把一次任务拆成可回放的层级：Session 表示一段用户会话，Trace 表示一次请求，Span 表示其中一次模型调用或工具执行。OpenTelemetry 的 GenAI 语义约定正在把这套字段标准化，模型、Token、耗时、错误状态都能挂到同一条链上。
判断标准可以很具体：随便给一个失败会话的 ID，能不能在十分钟内说清它卡在哪一步、为什么卡、有没有留下副作用。做不到，就说明这条链路还是黑的。可观测不只是为了修问题，它也是成本治理的入口——同一个模型被重试了几次、哪一步把上下文撑大了，这些账拆开 Trace 才看得见。
## 八、把“换模型”做成配置项

前面几节讲的都是单条链路的稳定性。但真实系统里还有一个更大的不稳定源：链路上每一个依赖，都可能自己出问题。
Agent 通常不会只用一个模型：意图识别用轻量模型，复杂推理上调大模型，格式校验再交给一个更小的模型。多模型的好处是各司其职、成本和效果兼顾，代价是每接一个模型，就要多申请一套密钥、多配一个 endpoint、多处理一类鉴权，编排的复杂度随模型数量往上跳。
更大的问题是单点。链路越长，依赖越多，任何一个上游抖动，都可能把整条任务拖垮；这条链上没有可切换的备份，一次超时就会放大成一次任务失败。
把不同来源的模型额度收进同一层接入，是个省力的做法：上游每个来源单独报价，买家只面对一套接口，某个来源不可用时能切到其他可用来源。对上层应用来说，“换模型”从一次运维变更变成一次配置修改。

对稳定性的意义有两点：单点不再致命，某个货源抖动时，任务能切走继续跑，而不是整条链一起挂；计费口径统一，账单能按模型、按调用逐笔对上，前面说的成本归因才有落点。
## 写在最后

Agent 的可靠性，是一笔可以逐项拆开的工程账。失败按乘法累积，所以要把单步做扎实；同一颗模型换个框架能差二十个百分点，所以要给模型配好外面那层；错误要分层重试、写操作要幂等、链路要能被追到底。
模型还在按月变强，把这套账算清楚的能力不会过期。真要接入多模型，先在一个项目上把上下文、工具、回执和观测做对，再接第二个——这一步走稳了，稳定性就是可以持续复利的资产。

把单次调用做到 99% 成功率，很多团队都觉得够稳了。可一段十步的 Agent 任务跑完，成功率只剩约 90%；把单步压到 95%，十步之后连六成都不到。这不是模型不行，而是可靠性在链条上按乘法累积。看懂这笔账，才知道 Agent 的稳定性该往哪里投。

单步成功率 99%，十步之后只剩九成：Agent 工作流的可靠性是谁在保证

人工智能

架构设计

后端

Agent工作流可靠性受乘法累积效应影响，单步99%成功率十步后仅剩九成。提升稳定性关键在于优化Harness层，包括检索、鉴权、执行和回执四环节，合理控制工具数量并实现分层重试与幂等设计，建立可观测体系，将多模型接入配置化以降低单点风险。

OpenTelemetry

客服工单

中间件

LangChain

路由

Agent

JSON

腾讯云双十一大促

agentobs

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

单步成功率 99%，十步之后只剩九成：Agent 工作流的可靠性是谁在保证-腾讯云开发者社区-腾讯云

单步成功率 99%，十步之后只剩九成：Agent 工作流的可靠性是谁在保证

单步成功率 99%，十步之后只剩九成：Agent 工作流的可靠性是谁在保证

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐