一件很反常的事我把手上十几份材料摊开千问Go! 的官方发布与媒体实测、OpenAI DevDay 2026 的 Dots 说明、豆包手机助手二代的路线公告、Manus 2.0 与 Cascade 框架的技术叙述、智谱 AutoGLM 与 Kimi OK Computer 的产品文档。关于能力各家讲得非常充分。关于可靠性几乎全部停留在「效果显著」「大幅提升」这类不可证伪的表述。具体缺什么任务成功率没有分母。跑了一百个任务成了几个没有。人工接管率没有。有多少比例的任务最终需要人来收尾样本量与统计口径没有。演示案例是挑过的还是随机的失败模式分布没有。失败是超时、权限拒绝、还是判定错误基准测试这个有一些OSWorld、WebVoyager 之类但那些是公开环境下的通用基准跟「在真实商家身上把一笔退款要回来」不是一回事。流传的一些数字我核了来源都不可采信。比如「内测跑通 200 万任务流」只在自媒体出现官方从未确认比如「企业端 Agent 任务完成率不足 5%」我能检索到的都是二手转述取不到原始研究。我在这一篇里不会引用任何一个我核不到源的数字包括这两个。那问题就来了为什么整个品类集体不公布这个指标一、因为成功率是这个品类里最难看的指标原因不难猜而且很实在。第一它必然很低而且低得没法解释。通用 Agent 基准在干净环境下都做不到很高真实商业环境里页面改版、风控拦截、条款歧义、客服敷衍成功率只会更低。一旦公布竞品当天就有素材。第二它把责任问题从模糊变成明确。「AI 可能出错」是可以被用户默认接受的「成功率 61%意味着 39% 的任务需要你重做或者自己收尾」是一个具体的、可被投诉和索赔的数字。第三它没有可比口径。什么算「成功」对方口头答应算吗金额低于用户要求但用户接受了算吗跨了三天的任务算一次还是三次口径不统一公布反而制造混乱。第三条其实是好消息——它意味着谁先把口径定义清楚并公开谁就拿到了这个品类的度量话语权。这跟当年 SRE 把 SLO、错误预算这些概念定义出来之后可靠性讨论就再也没回到「我们系统挺稳的」那种状态是一模一样的过程。所以下面我给一套我认为可以直接用的指标体系。它来自企业级智能体治理的 KPI 框架我按个人智能体场景改写了阈值。图 8 Personal Agent 可靠性指标体系与告警阈值二、四个核心指标的定义与阈值指标一任务成功率 TSRTask Success RateTSR 成功闭合任务数 / 总任务数 × 100%分母包含COMPLETE、FAILED、ROLLBACK 三类状态目标值不低于 92%。告警线低于 90% 触发 P1低于 85% 触发 P0。92% 这个数字一定会有人质疑——真实商业环境怎么可能到 92%我的回应是这个阈值应该按场景分别设定而不是全局平均。全局 92% 是个方向性目标但真正有操作价值的是「航班延误理赔场景的 TSR 是多少」「价保退差价场景是多少」。全局平均数只会用来掩盖长尾场景的溃败。还有一个必须定的规则接系列第 2 篇「对方口头答应」不计入成功。只有到账核验或可回查工单号才算闭合。否则你的 TSR 会虚高而且虚高在演示时完全看不出来。指标二工具成功率工具成功率 工具调用成功次数 / 总调用次数 × 100%目标值不低于 80%。关键要求必须按通道分列统计。协议通道、浏览器通道、界面兜底通道的成功率天然不同混在一起算会掩盖协议层的退化——界面通道成功率暴跌的时候只要它占总调用比例小全局数字看起来还很健康而实际上你的核心通道已经坏了。指标三重规划频率重规划频率 每百任务中需要调整执行路径的次数目标值不高于 15 次每百任务。这个指标我特别想推荐给大家因为它是最好的漂移预警。它突然上升通常不是模型变笨了而是上游变了页面改版、接口字段变更、商家政策调整、风控规则收紧。等你从 TSR 上看出问题已经晚了两周重规划频率是当天就能看出来的。指标四人工接管率接管率 触发人工确认或中止的任务占比这个指标反直觉它过低比过高更危险。高风险场景涉及资金、涉及不可回滚动作的接管率如果接近 0说明你的接管阈值定得太松或者人工确认节点被绕过了。这种情况下 TSR 再高都不能上线——因为你可能只是把一堆没被拦下来的错误动作安静地执行完了。所以接管率必须分场景设定区间而且要双向告警过高说明能力不足过小说明闸门失效。三、指标掉了必须能定位到层损耗归因链光有数字没有归因等于没有。三类损耗、根因与改进措施损耗类型根因改进措施工具调用失败API 超时、权限不足、页面改版导致定位失败重试机制 权限预检 通道降级依赖阻塞上游证据未到位、外部审核未返回依赖感知调度 状态持久化恢复内容质量不达标条款引用错误、幻觉出并不存在的政策护栏层输出核验 条款库强校验第三行是 Personal Agent 场景里最特殊的一类值得多说两句。Agent 幻觉出「不存在的政策」比幻觉出「不存在的事实」危险得多。前者会直接进入与商家的交涉过程构成一个错误主张。它不会以「胡说八道」的形式被发现只会以「商家拿出条款原文说你说错了」的形式被发现——那时候你的用户已经在电话里跟客服吵了十分钟。对策是把条款来源做成强校验引用Agent 引用的每一条政策必须带来源 URL 与抓取时间戳且交涉前由一层确定性代码回查该条款文本是否仍然一致。不允许模型自由复述政策内容。这条实现起来不难但我在公开材料里几乎没看到哪家提到。这可能正是它们不公布成功率的原因之一。四、埋点字段最小集缺任何一项你都没法做分场景归因。这是我建议的字段task_id, agent_id, intent_hash, channel, status,start_time, end_time, replan_count, human_takeover,error_type, amount_before, amount_after, evidence_refs几个字段的设计意图说明一下intent_hash把用户原始意图哈希化用于同一意图的多次执行对比。没有它你无法回答「同一个需求昨天成功今天为什么失败」。channel执行通道。上面说的分通道统计全靠它。replan_count重规划次数不是布尔值。分布形态比均值有用。amount_before / amount_after逆向履约场景必备。用户要求退 100、实际退到 30这在传统「成功/失败」二值里被记成成功但它是你需要知道的那一类失败。evidence_refs证据链引用。确保任意一次历史执行可被完整复现。统计周期实时计算 每日汇总 每周趋势。周报固定输出两张表分场景成功率和分场景接管率。这两张表应该是这个品类里最该被公开的东西。存储按日归档为结构化记录保留原始证据链引用。五、成本坍塌之后可靠性的性质变了现在回到那个最实际的问题凭什么认为这件事现在能做、两年前不能做答案在成本上。两组公开数字推理侧OpenAI 在 DevDay 2026 把新模型 GPT-6.1 Sol 的 API 定价报到每百万输入 2 美元、每百万输出 10 美元并明确它约为同期旗舰档约五分之一的价格。框架侧Manus 公布其 Cascade 框架使 Token 消耗减少 23.2%、任务完成时间缩短 28.2%、运行成本降低 32%。这两组数字表面上是「省钱消息」。但它们的真实含义是成本下降改变的不是支出是「允许失败多少次」。一次任务如果重试三次的成本从「不可接受」变成「可以接受」那么失败处理策略就从「必须一次做对」变成「可以多路尝试后择优」。这是架构范式的变化前者要求一个足够强的模型一步做对本质是在赌模型能力后者允许编排层同时试协议通道、自助流程、图文客服三条路然后核验取最优本质是在做工程冗余。而工程冗余是可以被测试、被度量、被回归的。模型一步做对不行。这就是我认为可靠性会成为唯一护城河的原因——因为它终于变成了一个可工程化的东西而不是一个祈祷事项。图 9 单次任务的延迟预算与成本结构顺带把成本度量补一句。别只算「省了多少人工工时」那是生产力视角容易高估。我建议的口径是ROI business_value / (tokens x unit_price compute_cost)三个维度一起看生产力周期缩短、错误率下降、节省工时、绩效转化率、参与度、新增收入流、资源计算时间、网络请求、存储占用。目标值不低于 3.0低于 2.0 触发效率告警。资源维度那条我特别喜欢避免用火箭送快递。一个查航班延误信息的任务不需要最强模型一个跟客服博弈争取现金赔偿的任务需要。模型分层调度本身就是 Token ROI 的最大杠杆点而它的前提恰恰是你有分场景的成功率数据——否则你不知道哪些任务可以降级到便宜模型。指标体系和成本模型在这里闭环了。六、给评测集设计的三条建议如果你要自建评测三条我认为最重要的第一必须包含不可回滚动作。很多评测集只测「查询与生成」那测出来的成功率对生产毫无指导意义。要测「提交申请」「发起支付」「发送正式函件」并且判定标准里包含「是否在不该提交的时候提交了」。第二必须包含对抗样本。塞进若干条含注入指令的客服回复和商品页测你的系统会不会被带偏。这一条几乎没人做但它现在是最可能出事的口子见系列第 3 篇。第三必须包含跨天恢复场景。任务挂起八小时后回来你的系统能不能从正确状态继续而不是从头再交涉一遍。这条测的是状态持久化而状态持久化恰恰是最容易被 demo 掩盖的缺陷。再加一条判分纪律判分逻辑必须与模型解耦。不能用一个 LLM 去判另一个 LLM 有没有成功。用账户流水、工单回查、确定性断言。七、系列收尾这个品类的三个真问题四篇写完把判断收一下。第一技术路线之争已经结束了。协议优先、界面兜底、关键动作回人工——三家在不同大洲独立收敛到同一个架构。接下来比的是执行质量不是路线选择。第二真正的稀缺资源是「商家愿意开放接口」和「敢为结果负责」。前者是商务与生态问题不是算法问题后者是治理与保险问题也不是模型问题。谁能把这两件事做出来谁就赢。而这两件事恰好都是中国厂商的强项区——阿里有履约链蚂蚁有支付底座字节有本地生活。第三可靠性证据是这个品类目前最大的空白也是最容易建立的差异化。全行业没有一家公布过带样本量的分场景成功率与人工接管率。第一家公布的产品会在企业采购和监管沟通两侧同时拿到溢价。这不是技术判断是市场判断——一个所有人都没有指标的领域第一个给出指标的人自动成为参照系。如果你是做 Agent 的我最后一条建议非常具体先把那两张表做出来哪怕不对外公布。分场景成功率和分场景接管率。有了它你的每一次架构决策才有反馈信号没有它你只是在换不同的模型赌运气。讨论一个具体的度量问题想请教做过 LLM 应用评测的朋友跨天异步任务的「成功」应该怎么计时一次理赔交涉从发起到到账可能三天中间还夹着商家审核。如果按发起时点计你的成功率会滞后三天才收敛如果按最后一次交互计又会把长尾拖延的任务算成失败。我目前倾向于双指标发起时点 结案时点分开统计但没想清楚哪个更适合进 SLO。参考来源检索与核验截止 2026 年 10 月 13 日。1. OpenAI DevDay 2026GPT-6.1 Sol API 定价每百万输入 2 美元、输出 10 美元约为同期旗舰档五分之一、ChatGPT Pro 500 美元档与 Pro 200 档额度调整、Dots 的只读后台与 Auto-review 机制Agent Skills 汇编2026-09-29https://agentskills.codes/blog/openai-devday-2026-recap-agent-builders2. Manus 公布 Cascade 框架数据Token 消耗减少 23.2%、任务完成时间缩短 28.2%、运行成本降低 32%恢复独立运营与 Manus 2.0、Cue 发布信息智东西新浪财经2026-10-08https://finance.sina.com.cn/roll/2026-10-08/doc-iniunvxm3821244.shtml3. 千问推出 Personal Agent「千问Go!」执行过程界面实时展示、可随时介入或中止上海证券报·中国证券网2026-10-13http://www.cnstock.com/commonDetail/8013544. 努比亚豆包手机助手二代 NaviX Ultra 的「协议优先、GUI 兜底、人工确认」路线艾媒咨询2026-10-06https://www.iimedia.cn/c1104/117830.html5. 实测千问开放平台三类终端接入与首批合作方名单新京报2026-08-10https://www.bjnews.com.cn/detail/1786344285129403.html6. QuestMobile 2026 年 6 月 AI 原生 App 月活榜千问 1.67 亿、豆包 3.82 亿IT之家转述2026-07-14https://www.ithome.com/0/976/383.htm7. 阿里千问升级个人 AI 助理Personal Agent「千问 Go!」即将发布含已实现的购物、打车、快递、理财等办事范围IT之家2026-10-13https://www.ithome.com/1/012/244.htmTSR 92%、工具成功率 80%、重规划频率 15 次每百任务、Token ROI 3.0 等阈值以及四指标框架、埋点字段最小集、损耗归因链、评测集三条建议取自企业级智能体治理 KPI 体系并按个人智能体场景改写属作者建议基线非行业标准文本亦不代表任何厂商的实际水平。