FDE-Wiki

主题

#Agent#ROI#案例研究#应用架构#行业大模型

本专题不谈"AI 改变世界"的口号，只回答一个问题：在一个具体行业的真实业务现场，Agent 到底长什么样、怎么分工、怎么衡量、怎么回本。每个行业都按"业务痛点 → Agent 架构（人机分工 / 工具链 / MCP / HITL）→ 关键指标 → ROI"四段式拆解，并标注信息来源。凡公开可核证的数字均给出出处，无法核证的设计参数会显式说明。

一、为什么需要一份"行业案例集" ​

过去两年 Agent 落地最大的问题不是模型不够强，而是行业方把 Agent 当成"更聪明的搜索框"，导致项目在三个地方反复翻车：第一，业务方说不清"Agent 替掉了流程中的哪一步、留下了哪几步";第二，技术方只堆工具调用（tool calling），却没有设计人机分工（human-in-the-loop，HITL）的边界;第三，验收时只有"演示效果"，没有可量化的 ROI 闭环。

本专题的写法是：每一个案例都把 Agent 放回原业务流程里，明确指出它接管了哪几个步骤、人保留哪些决策权、用到了哪些工具与 MCP（Model Context Protocol）数据连接器，并尽量给出行业基准指标与回收期估算。这样做的目的是让 FDE/FDSE 在驻场时可以拿这套模板去和客户对齐"我们到底在交付什么"。

二、金融行业：反金融犯罪调查 Agent ​

2.1 业务痛点 ​

反洗钱（AML）调查是银行合规部门最痛苦的高频低效环节。一套典型的 AML 监控系统每天会基于规则引擎吐出几千到几万条告警，其中绝大多数是误报——行业公认的误报率长期在 90%~95% 之间。一名调查员处理一个中等复杂度的案件（case）平均要花 30 分钟到数小时，需要跨核心系统、支付流水、客户 KYC、负面新闻、对账文件等七八个数据源来回切换，最后产出一份 SAR（Suspicious Activity Report，可疑活动报告）草稿。人员流动率高、培训周期长、合规罚款风险大，是典型的"高技能劳动被低价值信息搬运淹没"的场景。

2.2 Agent 架构 ​

FIS 与 Anthropic 合作推出的 Financial Crimes AI Agent 是当前最具代表性的公开案例，Amalgamated Bank 为早期合作机构。其架构可拆为四层：

  • 模型层：以 Claude 为推理内核，承担告警分级、证据汇总、报告起草三类长文本推理任务。
  • 工具层：通过 FIS 自有的 AML 平台 API 调用交易图谱、客户画像、制裁名单、负面新闻检索（典型如外部风险情报源）、文档检索（KYC、尽调文件、之前的案件结论）等工具。
  • MCP / 数据连接层：FIS 作为 MCP server 暴露合规数据上下文，使 Agent 能在统一协议下访问多源数据，而不必为每个数据源写一次性适配代码——这正是 MCP 在金融场景的核心价值：把"接数据"的工程量从"每个项目重写一遍"压到"配置一次复用"。
  • 人机分工（HITL）：Agent 不直接关停账户、不直接提交 SAR。它的输出是"调查草稿 + 证据链 + 置信度标注"，由人类调查员复核后点击提交。所有 Agent 决策保留可审计的操作日志，满足监管对可追溯性的硬性要求。

2.3 关键指标 ​

FIS 公开宣称该 Agent 可将 AML 告警与案件的调查时间"从数天压缩到数分钟"，并显著降低误报。在 FDE 实际验收时应锚定以下三类可核证指标：单案件平均处理时长（baseline vs. with agent）、误报二次过滤率（Agent 建议关单且经人复核通过的比例）、SAR 草稿一次通过率。需要强调的是，"days to minutes"是厂商标语，FDE 落地时应按客户自己的 baseline 折算，避免在汇报中直接搬运。

2.4 ROI ​

按一名调查员年薪（美国市场 8~12 万美元）× 团队规模 20 人估算，若 Agent 使单案件处理时长下降 60%，相当于释放约 12 个 FTE 的有效产能，或在不增编前提下把案件吞吐量提升 1.5 倍以上。对一个中型银行合规部门，年化节省通常在 数百万美元量级，并显著降低因案件积压导致的监管罚款尾部风险。典型的 PoC→生产回收期在 9~15 个月。

三、金融行业：信贷尽调 Agent ​

3.1 业务痛点 ​

对公信贷尽调是另一个"信息搬运重于判断"的高耗时场景。客户经理撰写一份授信调查报告，要拼合工商、涉诉、税务、上下游、舆情、财报、行业对标等十余类外部数据，再套用行内授信模板，单笔报告耗时 3~7 个工作日，且高度依赖个人经验，质量参差。

3.2 Agent 架构 ​

  • 人机分工：Agent 负责"数据采集 + 结构化录入 + 模板初稿 + 风险点提示";客户经理和风险审批人员保留"实地走访、定性判断、最终签批"的决策权。
  • 工具链：工商查询（如天眼查/企查查类 API）、裁判文书网/执行信息公开网检索、财报解析（PDF→结构化）、舆情检索、行内 CRM 与授信系统的读写 API。
  • MCP：把行内风控规则库、历史授信案例库、行业研究报告库封装成 MCP server，Agent 在写报告时按需检索相似案例与风险条款，避免"凭空生成"。
  • HITL：每个数据点必须挂来源链接，风险审批人员可以一键核验;Agent 不得自行调整评级结论。

3.3 关键指标 ​

报告初稿生成时长（baseline 3~5 天 → Agent 辅助 1~3 小时）、数据点溯源覆盖率（应 ≥ 95%，即报告中每个数字都能点开原始来源）、风险点漏报率（用历史已出险案件回测）。

3.4 ROI ​

按一家区域性银行年新增对公授信客户 2000 户、户均尽调 4 个工作日估算，若 Agent 把初稿环节压缩 70%，可释放约 8~10 个 FTE，年化人力节省 150~250 万元人民币。更重要的是把尽调周期从"周"压到"天"，直接提升对公业务的市场响应速度——这是 FDE 在汇报时容易被忽视的非货币 ROI。

四、医疗行业：病历质控 Agent ​

4.1 业务痛点 ​

病历质控（病案首页、运行病历、终末病历的完整性 / 一致性 / 合规性检查）是三甲医院病案室的硬性工作。一份出院病历要在 24~72 小时内完成内涵质控，缺陷率直接挂钩 DRG/DIP 付费、等级评审与医保结算。传统做法是病案室编码员逐份人工抽审，覆盖率通常不到 20%，且发现缺陷时病历已归档，修改成本高。

4.2 Agent 架构 ​

  • 人机分工：Agent 做全量病历的"预筛 + 缺陷定位 + 修改建议";编码员和主任医师保留"复核 + 否决 + 终签"权。
  • 工具链：HIS/EMR 系统的病历读取 API、ICD-10/ICD-9-CM-3 编码库、DRG 分组器、医院质控规则库（如首页必填项、诊断与手术一致性、性别限定诊断等）。
  • MCP：把质控规则、编码标准、历史缺陷案例封装为 MCP server，使 Agent 可以按规则编号反查依据，避免"模型自己拍脑袋判错"。
  • HITL：所有"缺陷判定"必须输出可点击的规则依据和原文位置;高危缺陷（如主诊断与手术矛盾）强制人工复核，Agent 不得自动改写病历。

4.3 关键指标 ​

全量质控覆盖率（20% → 接近 100%）、缺陷检出召回率（以编码员复核为金标准，行业实践值在 85%~92%）、单份病历质控耗时（人工 15~30 分钟 → Agent 预筛 1~3 分钟 + 人工复核 3~5 分钟）、DRG 入组准确率提升幅度。

4.4 ROI ​

以一家年出院 5 万人次的三甲医院估算，质控覆盖率从 20% 提升到 95% 以上，相当于把"被动罚款"转为"主动拦截"。按 DRG 拒付 / 下调率每下降 1 个百分点对应数百万元医保收入，Agent 项目通常在 6~12 个月 内通过减少拒付收回投入，病案室人力则从"低覆盖抽审"转向"高价值编码争议处置"，是少有的"质量与成本双正向"场景。

五、医疗行业：保险预授权 Agent ​

5.1 业务痛点 ​

商业医疗险与部分公疗的"预授权"（治疗前向保险公司申请许可，如某类靶向药、高值耗材、特殊检查）流程冗长。医院端医生要填表 + 附病历摘要上传，保险端医学审核员要查条款、比对指南、打电话与医院沟通，单件处理 2~5 个工作日，患者常因等不及而自费垫付，引发投诉。

5.2 Agent 架构 ​

  • 人机分工：Agent 负责"申请表结构化抽取 + 条款比对 + 医学必要性证据汇总 + 初步建议（同意 / 补材料 / 拒付）";医学审核员保留终审权，尤其对边界病例与高金额申请。
  • 工具链：保单条款库检索、临床指南 / 药品说明书检索、病历摘要生成、医院 HIS 对接读取诊疗记录。
  • MCP：把条款库、指南库、历史授权案例库做成 MCP server，让 Agent 的每一次"建议"都能挂出条款原文与相似案例。
  • HITL：金额超过阈值（如单项 > 5 万元）或 Agent 置信度低于阈值的申请强制人工;Agent 输出始终标注"建议，非决定"。

5.3 关键指标 ​

预授权平均处理时长（天级 → 小时级）、自动通过率（明确符合条款的简单申请，行业实践在 40%~60%）、补材料一次通过率、拒付申诉率（衡量 Agent 是否过度拒付）。

5.4 ROI ​

保险端：审核人力释放 30%~50%，医学审核员转向复杂案件;医院端：预授权等待时间下降直接提升患者满意度与垫付回款速度。综合回收期 12~18 个月，附带"提升续保率"这种隐性收益。

六、制造业：视觉质检 + 缺陷处置 Agent ​

6.1 业务痛点 ​

传统机器视觉质检（基于规则或纯 CV 模型）只能告诉你"这里有缺陷"，无法回答"这是什么缺陷、要不要报废、能不能返修、要不要停机调整工艺"。一线质检员仍要逐张复核高置信度报警，并对缺陷做分类与处置决策，是典型"判断被推给人"的瓶颈。

6.2 Agent 架构 ​

  • 人机分工：CV 模型做缺陷检测;Agent 做缺陷分类、根因推测（关联工艺参数）、处置建议（接收 / 返修 / 报废 / 停机）、工单生成与 MES 写回;质检班长保留边界件终判与停机决策权。
  • 工具链：CV 推理服务、MES（生产工单）、SCADA / 设备参数采集、SPC（统计过程控制）、返修工艺库、质量追溯系统。
  • MCP：把工艺参数历史、缺陷图谱库、返修 SOP 封装为 MCP server，Agent 可以反查"上次出现同类缺陷时是哪段工艺漂移"。
  • HITL：首次出现的缺陷类型、处置为"报废"或"停机"的高代价决策强制人工确认;Agent 的处置建议进入工单但带"建议"标记。

6.3 关键指标 ​

缺陷分类准确率（以质检班长复核为金标准，实践值 88%~94%）、误报率（防止 CV 把良品判废）、漏检率（安全相关指标，必须极低）、从发现缺陷到工艺调整的平均响应时长（小时级 → 分钟级）。

6.4 ROI ​

按一条产线年产值数千万元、报废率每降 0.5% 对应数十万元估算，Agent 项目在 6~12 个月内通过降低误报废和缩短工艺调整响应时间回本。更关键的是把"质检数据"从"事后统计"变成"实时反馈工艺"的闭环，这是 FDE 汇报时容易被低估的战略价值。

七、制造业：设备运维 Agent ​

7.1 业务痛点 ​

预测性维护（PdM）讲了多年，多数工厂仍停留在"传感器数据采集 + 阈值报警"，报警之后怎么做完全靠老师傅经验。设备台账、维修历史、备件库存、厂家手册散落在不同系统，故障处置平均修复时间（MTTR）居高不下。

7.2 Agent 架构 ​

  • 人机分工：Agent 负责"报警分诊 + 历史相似故障检索 + 维修步骤生成 + 备件可用性查询 + 工单派发";维修工程师保留现场判断与施工权。
  • 工具链：IoT 时序数据平台、CMMS（计算机化维护管理系统）、设备手册 RAG、备件库存 ERP、厂家知识库。
  • MCP：把手册、维修历史、备件目录做成 MCP server，Agent 在生成维修步骤时按设备型号与故障代码精准检索，避免通用大模型的"幻觉式建议"。
  • HITL：涉及停机、动火、高处作业等安全相关操作强制人工确认并签字;Agent 仅生成作业指导书草稿。

7.3 关键指标 ​

MTTR 下降幅度（实践值 20%~40%）、首次修复率（FTFR，减少反复维修）、计划外停机时长下降、备件库存周转改善。

7.4 ROI ​

按单台关键设备单次非计划停机损失数万元到数十万元估算，MTTR 下降 30% 即可在数月内收回 Agent 项目投入。隐性收益是把"老师傅脑中的经验"沉淀为可检索的知识资产，降低对个别人的依赖。

八、政务行业：12345 派单 + 坐席辅助 Agent ​

8.1 业务痛点 ​

12345 政务服务便民热线日均呼入量在省会城市可达数万通，传统流程是话务员接听→手工填单→按经验派单到承办单位→督办→回访。痛点集中在三处：派单主观性强导致反复退单、话务员要边听边查知识库导致通话时长长、诉求响应链路长。

8.2 Agent 架构（基于公开案例） ​

公开报道显示，苏州、无锡、阜新、昆山等地以及浪潮云、神州数码、来也科技、零点有数等厂商均有落地。架构共性：

  • 人机分工：Agent 做"实时语音转写 + 智能填单 + 知识推荐 + 智能派单";话务员保留对话主导权、核实关键信息、处理复杂情绪诉求;督办员保留退单与考核权。
  • 工具链：ASR/TTS、政务知识库、工单系统、承办单位责任清单、地理信息（用于按属地派单）。
  • MCP：把权责清单、知识库、历史工单做成 MCP server，让派单决策可解释（"为什么派给城管而不是街道"）。
  • HITL：派单准确率不达 100% 是常态，低置信度工单进人工复核队列;Agent 不得自动结案或自动回访。

8.3 关键指标（均为公开数据） ​

阜新"国标政务大模型"试点：智能派单准确率 > 90%、工单处理效率提升 25%、诉求响应时间缩短 30%。浪潮云某市方案：工单一次转办成功率提升至 99.65%。苏州上线"智能话务大模型"，覆盖智能填单、知识推荐、智能派单三个核心场景。

8.4 ROI ​

按一个省会城市 12345 中心 200~300 名话务员估算，单通处理时长下降 20% 即可释放数十 FTE 或显著降低外包成本。更重要的非货币收益是"诉求响应提速"带来的市民满意度与政府公信力——这是政务项目汇报时必须单独列出的"政治 ROI"。

九、政务行业：政务问答 Agent ​

9.1 业务痛点 ​

群众办事要查"办什么、带什么材料、找谁办、多久办完"，传统做法是翻政府网站（信息分散、过期）或打 12345（占线）。窗口工作人员也缺乏统一的"一网通办"知识源。

9.2 Agent 架构 ​

  • 人机分工：Agent 做"意图识别 + 事项检索 + 材料清单生成 + 办事地点/时间查询";复杂情形（如涉多部门联办）转人工窗口或在线客服。
  • 工具链：政务服务事项库、办事指南库、办事地点 GIS、预约系统 API。
  • MCP：把事项库与指南库做成 MCP server，确保回答有出处;严禁 Agent 用通用知识"编造"材料清单（这是政务场景的红线）。
  • HITL：高频高危事项（如户籍、税务）的回答在上线初期全部人工复核后再外放。

9.3 关键指标 ​

意图识别准确率、回答可溯源率（应 100%）、人工接管率、群众满意度评分。

9.4 ROI ​

直接节省话务与窗口咨询人力;间接提升"一网通办"办件量与网办率，后者是各地营商环境考核的硬指标。

十、零售行业：智能导购 + 售后 Agent ​

10.1 业务痛点 ​

电商与线下零售都面临"导购人力成本高、复购转化低、售后退货处理慢"。客服 Agent 早期版本（规则机器人）体验差，大模型 Agent 上线后可承担更复杂的"理解需求 + 推荐商品 + 处理售后"全链路。

10.2 Agent 架构 ​

  • 人机分工：Agent 做需求澄清、商品检索与推荐、订单查询、退换货初判、物流跟踪;人工客服保留投诉升级、VIP 客户、金额超阈值的退款终审权。
  • 工具链：商品知识库（含规格、库存、促销）、订单系统、CRM、物流 API、退换货规则引擎。
  • MCP：把商品库、促销规则、退换货政策做成 MCP server，Agent 的每个推荐与退货建议都挂出处。
  • HITL：投诉、差评、客诉升级强制人工;Agent 不得自行决定大额退款。

10.3 关键指标 ​

会话自动解决率（行业实践 50%~70%）、平均会话时长、转人工率、复购率提升、退货处理时长。

10.4 ROI ​

按一个中型电商客服中心 100 人估算，自动解决率 60% 可释放约 40~50 人或承接 2 倍以上咨询量。回收期 6~12 个月。隐性收益是 7×24 在线与多语言支持。

十一、物流行业：供应链调度 Agent ​

11.1 业务痛点 ​

供应链调度涉及订单、库存、运输、仓储多环节，异常（缺货、延误、爆仓）发生时调度员要在多系统间反复切换做决策。Salesforce Agentforce 在此场景的定位是把"跨系统手动协调"自动化。

11.2 Agent 架构（参考 Salesforce Agentforce 公开案例） ​

Salesforce 公开的代表案例是 Regal Rexnord（全球传动与动力设备制造商），在 Salesforce Order Management 内测试开箱即用的 AI Agent，检索订单数据以优化全球供应链。Jade Global 实施的另一 SaaS 客户案例显示 Agentforce 自动化了 80% 的线索判定，手工工作量下降 70%（注：此数据为销售场景，供应链场景的公开量化数据有限，FDE 落地时不应直接套用）。架构共性：

  • 人机分工：Agent 做异常检测、跨系统数据汇总、调度方案草拟、通知与工单生成;调度员保留终判与对外沟通权。
  • 工具链：OMS（订单管理）、WMS（仓储）、TMS（运输）、ERP、供应商协同平台。
  • MCP / 数据连接：Salesforce 的做法是把 CRM/OMS 数据封装为 Agent 可调用的上下文，类似 MCP 的思路。
  • HITL：高代价决策（如改航、紧急空运、停产）强制人工。

11.3 关键指标 ​

异常响应时长（小时级 → 分钟级）、调度方案采纳率、库存周转改善、订单准时交付率（OTIF）提升。

11.4 ROI ​

供应链 Agent 的价值很大一部分体现在"避免损失"（缺货导致的销售损失、延误导致的罚金），FDE 汇报时应同时列出"效率节省"与"风险规避"两类收益。回收期通常 12~18 个月。

十二、能源行业：资产运维 Agent（参考 MCP 模式） ​

12.1 业务痛点 ​

新能源（光伏、风电、储能）资产分散在广袤地域，运维高度依赖现场巡检与历史故障经验。逆变器、风机齿轮箱、储能 BMS 等关键设备的故障代码、厂家手册、运维历史、SCADA 实时数据散落各处，现场工程师处置效率受限。

12.2 Agent 架构（基于 MCP 模式的设计，非具体厂商公开指标） ​

需要说明：SB Energy（SoftBank 旗下美国能源平台，近年重心转向 AI 数据中心与储能）与 MCP / Claude 之间没有公开可核证的具体合作指标。本节按"MCP 模式在能源资产运维上的典型设计"来写，FDE 在与能源客户沟通时应明确这是设计范式而非已落地数字：

  • 人机分工：Agent 做故障分诊、运维历史检索、厂家手册检索、备件查询、工单生成、安全作业提醒;现场工程师保留施工与签收权。
  • 工具链：SCADA / IoT 时序数据、CMMS、设备厂家手册 RAG、备件 ERP、气象数据（影响光伏 / 风电出力）、无人机巡检图像。
  • MCP：把设备手册、故障代码库、运维历史、备件目录封装为 MCP server，使 Agent 能按设备型号与故障代码精准反查处置步骤——这是 MCP 在能源运维场景的核心价值：把"厂家知识私有化"变成"Agent 可调用的统一上下文"。
  • HITL：涉电、涉高、涉火的运维操作强制人工确认;Agent 仅生成作业指导书草稿与备件清单。

12.3 关键指标（设计目标，非实测） ​

故障分诊准确率、MTTR、单次现场运维的平均准备时长、备件一次到位率、可利用率（availability）提升幅度。

12.4 ROI ​

新能源资产运维 Agent 的价值主要来自"提升可利用率"（每提升 1% 的等效利用小时数对应可观电费收入）与"降低非计划停机损失"。FDE 在此场景汇报时务必区分"设计预期"与"已验证收益"，避免把厂商 demo 数字当成承诺。

十三、跨行业共性：Agent 架构模式 ​

把八个行业案例横切，可以提炼出反复出现的架构模式：

  • 三段式 Agent：感知（接告警 / 接工单 / 接会话）→ 推理（检索 + 规划 + 生成）→ 行动（写回系统 / 派单 / 草稿）。三段都要可审计。
  • 检索增强优于自由生成：所有高风险场景都把规则库、手册、历史案例做成可检索上下文（MCP server / RAG），而不是让模型自由生成。这是"真实不注水"在架构层的体现。
  • 工具颗粒度要细：把"查工商""查涉诉""查手册第几页"拆成独立工具，比给 Agent 一个大而全的 API 更可控。
  • 可解释性是验收前提：Agent 的每个输出都应能挂出数据来源与规则依据，否则行业方不会签收。

十四、跨行业共性：HITL 设计 ​

HITL 不是"出错了再让人看"，而是架构层就要定义清楚的三类边界：

  • 金额 / 代价阈值：超过阈值的人工确认（如大额退款、停产、停机）。
  • 置信度阈值：Agent 自评置信度低于阈值的转人工。
  • 安全 / 合规红线：涉及人身安全、监管报送、对外法律效力的操作，无条件人工确认。

FDE 在交付时要做的，是和客户一起把这三类边界写进配置，而不是临场拍脑袋。这条经验比任何模型选型都更决定项目成败。

十五、跨行业共性：ROI 量化方法 ​

跨行业 ROI 可统一拆为四类，避免只算"省了多少人头":

  1. 直接人力节省：FTE 释放或承接量提升。
  2. 质量收益：缺陷率、误报率、漏检率、拒付率下降带来的直接经济价值。
  3. 时效收益：处理时长缩短带来的收入提前确认、客户满意度提升、续保率/复购率提升。
  4. 风险规避：合规罚款、非计划停机、缺货损失的尾部风险下降——这一类最容易被低估，却往往是行业方真正愿意买单的理由。

回收期上，八个行业的经验值集中在 6~18 个月，越偏后台流程（如 AML 调查、病历质控）回收越快，越偏实时调度（如供应链、能源运维）回收越慢但战略价值更高。

本专题小结 ​

  1. Agent 落地的真正难点不在模型能力，而在"人机分工边界、工具/MCP 数据上下文、HITL 设计、ROI 量化"四件事——这四件事任何一件没做扎实，项目都会沦为演示。
  2. 跨八个行业看，成功的 Agent 都遵循"检索增强 + 细粒度工具 + 强制可解释 + 分层 HITL"的同构模式，行业差异主要体现在数据源与规则库，而非 Agent 本身的形态。
  3. FDE 的交付价值在于：把客户模糊的"我要个 AI"翻译成"Agent 接管哪几步、人保留哪几步、用什么指标验收、几个月回本"，并用可追溯文档固化下来——这正是 CDEF 方法论中 Design 与 Engineer 阶段的核心产物。
  4. 公开数据要诚实标注来源，厂商口径（如"days to minutes"）不能直接搬进对客户的承诺，FDE 必须按客户自身 baseline 重新折算后再开口。

本专题来源 ​

本站由原始 Markdown 调研报告自动构建 · 原文未改动

FDE 调研报告 (2026)