OOOMETA/OS
← 返回洞察

2026 年 9 月 · 5 分钟阅读

AI 工单分诊:96% 准确率,月成本 30 美元

AI 工单分诊:96% 准确率,月成本 30 美元

关键定义

阈值型自动化 把智能体的动作分成两段的运行方式:置信度高于一个显式配置的阈值就自动执行,低于阈值就转人工处理。

转人工路径 低置信工单交给人时附带的上下文。带上已充实的信息,转人工才有信息增益,人工做的是判断而不是重新调查。

周一上午,一家法律行业软件商的运维团队打开工单队列:上周积下来 34 到 40 张,来自 268 个客户环境。这个 38 人的团队为这些环境提供支持,自动化之前,每张工单要走 15 到 25 分钟的人工调查,先看是哪套系统、哪个客户、属性归谁,再去翻知识库和工单历史。

他们上线了一个由 Amazon Nova Lite 驱动的分诊器,2.5 周里审阅了 109 张工单,约 96% 的判定与人工结论一致;按自动化前的基线估算,每周回收 8 到 14 个工程师小时。整套系统的账单不到 30 美元一个月,其中模型推理不到 1 美元,这意味着一个团队不需要走预算审批就能把它放进生产。

这些数字由 Aderant 与 AWS 联合署名发布,只有一个来源,没有独立验证:样本是 109 张工单,工时那一条原文用的词是 estimates。可以写「该部署方报告」,不能写成行业基线,也不能把 96% 当作分诊类系统的通行水平。

一、这个案例值钱的地方不是 96%

准确率数字是最容易漂移的部分。它取决于工单类型分布、客户环境的同质程度、团队自己定义的「分诊正确」是什么。换一个组织,同样的模型可能掉到 70%,也可能升到 99%,而这两件事都不说明做法好不好。

真正可迁移的是形态,这个案例里有三件事是稳定的。第一,阈值内自动、阈值外转人工:模型只在它有把握的范围内动手,其余交给能承担不确定性的人。第二,单人可运维:一个 Lambda、一个定时触发、一份云上指标,没有需要专职维护的组件。第三,月成本两位数美元:它低到不需要走采购流程,也就不需要先证明自己值得立项。

把这三条放在一起,能看出一个被忽略的事实:当自动化的成本落到两位数美元一个月的时候,决定做不做的变量就从预算变成了设计。预算不会否掉它,把阈值设错会。

把这套算术摊开看,更容易理解为什么问题出在门槛而不是回报。团队每周 34 到 40 张工单,按每张 20 分钟计算,是 11 到 13 个小时的调查工作;一个 38 人的团队每周理论产能超过 1,500 小时,也就是说这项工作不到整体产能的 1%。在这个量级上,任何传统立项逻辑都会把它否掉:绝对回报太小,撑不起一次采购、一次集成和一次验收。它之所以能做成,恰恰是因为成本降到了不需要证明回报的水平。

二、五段工序:识别、充实、分类、执行、观察

这套分诊器的流程有五段。识别(Identify)先判断这张工单是什么;充实(Enrich)从 Jira、Confluence、Athena 与 SharePoint 拉取相关上下文;分类(Classify)确定它属于哪一类;执行(Act)做改派、发 Teams 通知、触发预定义动作;观察(Observe)把指标写进 CloudWatch,并把低置信的工单转给人工。

这个骨架值得抄的原因在于它把「模型要做什么」限定得很窄。模型负责判断和归类,动作是预定义的,取数是被限定的,人工兜底是流程的一部分而不是异常分支。一个智能体要在生产里活下来,通常不是因为它更聪明,而是因为它的职责边界被划得足够小。

设计上有两处细节最容易漏。第一,置信阈值是显式配置项,不是提示词里的形容词。这一点决定了整条链路可观测:你能知道阈值两侧各有多少流量,也能知道改动阈值会付出什么代价。第二,每周复盘改派的纠正样本,回改提示词与路由规则。这条回路是它从「上线」变成「运营」的分界线,没有这条回路,准确率就只是一个历史快照。

还有一条边界决定了它能这么便宜。系统的数据范围限于内部运营数据,不碰客户案卷里的业务数据。这条边界既是它能通过内部评审的原因,也是它成本结构成立的原因:不需要为敏感数据额外建一套隔离与审计工程。反过来看,任何要把这类自动化延伸到客户数据的方案,成本都会跳一个数量级,那时候讨论的重点就不再是模型选型了。

三、阈值之上自动、阈值之下转人工,是默认形态

有人把这套做法读成过渡方案:等模型更准了,阈值就可以取消,全部自动化。按买方现场的实际情况,这个读法站不住。

转人工不是能力不足的补丁,它承担一项明确职能:把不确定性交还给能承担它的一方。后台运维的改派错了,成本是客户环境里多绕一圈的人力;医疗或金融场景里错了,成本是合规事件。阈值把「模型有多大把握」和「错了谁承担」这两件事显式挂钩,这正是流程设计里最值钱的一段。

转人工路径本身也有设计质量之分。如果转过去的是原始工单,人工还要从头调查一遍,收益只落在被自动处理的那部分上。如果转过去的是已经充实过的上下文——相关的 Jira 链接、环境标识、历史相似工单——人工接到的是判断任务,而不是调查任务。这个案例里节省的 8 到 14 小时,主要来自后一种情形:即便工单最终由人处理,前置调查也已经被削掉了。

阈值的位置是可以调的运营参数,不是一次性设置。调低,自动化率上升,错误改派的成本上升;调高,人工量回升,等待时间变长。每周复盘纠正这件事的意义,就是让这条曲线随着业务变化慢慢挪到合适的位置——它是一项例行工作,不是上线时做一次的配置决定。

四、买方自报的自主度分级:66%、0%、37%

单个案例只能说明一种做法可行,买方现场的分布更有说服力。一份由智能体厂商 Leah 委托 IDC 执行的调研(n=410 名企业技术决策者)给出几个数字:66% 的组织已经在生产中运行智能体;部署了带策略护栏的全自主运行的是 0%;37% 的场景要求智能体在行动之前必须有人工签核;智能体相关预算在 12 个月内翻倍,部署规模的计划值是 6 倍。

同一份调研里还有一组关于协同的数字,由 CIO Dive 转述:只有 29% 的智能体之间会互相交互,7% 达到所谓的「高级编排」,超过一半仍然停留在基础或工作流式的交接。引用这两条时要标注转述来源,因为报告全文需要留资下载,这些数字的口径定义我们无法逐项复核。

口径上还有三条必须写清。这是厂商委托执行的调研,挂在委托方的获客页面上,不是中立普查。0% 全自主是这 410 家样本的自报结果,只能写「该样本中无一家」,不能外推成「没有任何企业给过智能体自主权」。6 倍与预算翻倍都是计划值,不是已实现值,不能写成企业部署已经增长 6 倍。

把这些数字放在一起,得到的画面不是「企业落后」,而是买方已经在按自主度分级管理。66% 上了生产、0% 给全自主、37% 要求行动前签核,这三件事同时成立,说明分级自治与审批边界不是顾问提出的模型,而是现场已经在跑的做法。前面那个工单分诊器就是它的一个具体形态:自动化在阈值内,签核在阈值外,两者共存于同一条工作流。

另一条推论对做产品的人更重要:多智能体编排在买方现场的覆盖率很低。29% 互通、7% 高级编排意味着,不能把它当作客户已经购买、正在使用的能力来对话。现场真正缺的是运行时可见性与事后可核验的证据——知道每个智能体在什么状态下做了什么,以及出了问题时能取出记录。这也解释了为什么这些数字和近期多起智能体运行时失准的信号指向同一个缺口。

五、成本已经不是决策门槛,设计才是

我们的判断是:当一个月 30 美元的自动化工具能替代每周十几个小时的调查工时,这件事的门槛不在预算,在设计。决策链条上的否决点从「值不值得批」移到了「阈值设在哪、纠偏谁负责、数据边界划在哪」。

这个位移带来一个二阶效应:可自动化的机会集合扩大了。以前只有那些规模足够大、能撑起一个立项流程的场景才会被自动化,现在一个 38 人团队每周几十张工单的场景也够格做——因为它不再需要论证回报,只需要一个周末的工程时间。企业 AI 的增量很可能大量来自这类「顺手做掉的小事」,而不是少数旗舰项目。这一点值得记下来:用旗舰项目的 ROI 框架去评估这类机会,会系统性地低估它们。

低成本形态成立有三个前提,缺一条就要重新设计。第一,任务有明确的判定标准,且对错能在一周内被验证——分诊可以,因为改派对不对几天内就能看出来;一个季度后才见分晓的决策不行。第二,输入数据落在内部边界内,不需要为它新建合规工程。第三,错误成本可承受,也就是有转人工兜底——这一点决定了阈值可以设得保守而不损失整体效率。

还要说明这套形态不解决什么。它不产生端到端的业务回报证据:回收的 8 到 14 小时是估算的产能,不是已经记账的成本节约。如果这十几个小时只是让工程师更清闲,报表上看不见任何变化。要让这类项目在财务上站得住,仍然需要把它折算成可核对的口径,比如工单平均闭环时间、客户环境的事故响应时间。

这也解释了低成本形态一个常被误判的性质:它的价值不在单点 ROI,而在组织学习的速度。一个周末做出来的分诊器,无论成功还是失败,都会留下一条真实数据——这类任务的判定标准能不能写清、置信阈值该设在哪、纠偏要占多少人力。这条数据是下一个更大规模项目的输入。用一次性项目的验收标准去衡量它,会把这些信息价值一起算掉。

六、把这套形态抄回自己组织的清单

第一,先写清判定标准与可判定性。你要能回答一句:如果模型判错了,多久能知道,谁知道?答不出时间尺度的任务,不适合做阈值型自动化。

第二,把阈值变成显式配置项,并记录两侧的流量比例,因为阈值的位置决定了收益与风险的分配。阈值写在提示词里的方案不叫阈值型自动化,那只是希望模型谨慎一点。

第三,让转人工路径带有信息增益。转出去的不该是原始工单,而是已经充实过的上下文。这条决定了你的收益上限:只有被自动处理的那部分省了时间,收益是线性的;连人工处理的工单也省掉调查时间,收益才是结构性的。

第四,把每周纠偏列成例行工作。记纠正率,回改提示词与路由规则,像维护告警规则一样维护它。没有这条回路,准确率数字会在几个月内悄悄失效。

第五,给成本设天花板,并把它当成设计约束。这个案例的月成本不到 30 美元,意味着它不需要经过采购流程;如果你设计的方案月成本是几千美元,它需要证明的东西完全不同,不要拿低成本形态的合理性去支撑高成本方案。

如果一张工单在你这里平均要花 20 分钟人工调查,而团队每周有几十张,真正要问的不是「该不该上 AI」,而是「改派对不对,能不能在一周内被验证」。能,就从一张工单的阈值开始;不能,先把判定标准建起来。

来源

AWS 客户案例:Aderant 用 Amazon Nova 构建智能工单分诊(2026-09-24,Aderant 与 AWS 联合署名): aws.amazon.com/blogs/machine-learning/aderant-builds-intelligent-ticket-triage-with-amazon-nova。

IDC 调研落地页(由 Leah 委托执行,n=410): leahai.com/lp/idc-agentic-enterprise-report;编排与互通数字的转述来源: ciodive.com/news/agents-remain-disconnected-enterprises-double-down/831317(2026-09-25)。

常见问题

96% 的分诊准确率可以直接引用吗?+

要带限定。这个数字来自 Aderant 与 AWS 联合自报,样本是 2.5 周内的 109 张工单,原文措辞是约 96%。可以写某部署方公布,不能当行业基线。

每周回收 8 到 14 个工程师小时是实测值吗?+

不是。原文用词是估算,基线是自动化前每张工单 15 到 25 分钟的人工调查时间。引用时必须保留估算这一限定。

月成本不到 30 美元是怎么构成的?+

整套系统运行在单个 Lambda 上,由 EventBridge 在工作日每小时触发,模型调用走 Bedrock,推理部分不到 1 美元一个月,其余是基础设施与存储费用。

为什么阈值外的工单要转人工而不是让模型硬答?+

因为错误改派的成本落在客户环境上。低置信转人工把不确定性交还给能承担它的人,同时让人工拿到已经充实过的上下文,做判断而不是重新调查。

厂商委托 IDC 的 410 家调研里,0% 全自主说明什么?+

它说明在这批样本里,没有一家把带策略护栏的全自主运行部署到生产。这是样本自报口径,不能外推成所有企业都没给过智能体自主权。

多 agent 编排是买方已经买好的能力吗?+

不是。同一份调研里只有 29% 的智能体之间会互相交互,7% 达到高级编排。把它当作买方现场已有的能力来对话,会错判需求。

这套低成本形态需要什么前提?+

三条:任务有明确判定标准且对错可在一周内验证,输入数据落在内部边界内,错误成本可承受(有转人工兜底)。缺一条就要重新设计。