保险理赔智能体
我们设计、构建并部署一个 AI 智能体，端到端地读取一份理赔——保单、事故报告和每一张收据——将它们相互核对，并为你的理赔员提供一份可直接决策的档案，其中的漏损与欺诈信号已被标出——而赔付决定仍由人来做。
一览
它每拦下一笔多付、每快速放行一份干净理赔都是钱——理赔漏损通常占已赔付理赔的 5–10%，而一致的审查正是 BNM 操守审查所看重的。
编排器将理赔拆解为并行检查、对报告与收据的视觉/OCR、保单条款推理、欺诈信号，以及 BNM/PIDM/PDPA 级的管控与审计轨迹。
见效后会有什么改变
每份申请耗时
当前人工初审
约 30–45 分钟
使用智能体
约 6–10 分钟
节省的时间
每份理赔约节省 25–35 分钟——每月 400 份理赔约合 165–230 小时，大约相当于一名全职理赔员。而在漏损方面：一个每月赔付 RM 200 万的组合，仅在 5–10% 的漏损率上拦下 2 个百分点，就是每月挽回约 RM 40,000——构建的回本期以周计，而非以年计。
为估算；实际时间与挽回额取决于理赔类型、文件数量与你当前的漏损率。
阶段 1 · 界定
业务问题
马来西亚的保险公司或伊斯兰保险运营商将每一份车险、医疗或财产理赔作为一叠材料接收——理赔表、保单明细、事故或警方报告、修理厂或医院发票，以及照片。理赔员一天的大部分时间花在机械性工作上：核对理赔是否真的在承保范围内、金额是否与收据一致、有无虚增或重复——而不是做判断。这个过程缓慢，疲劳时容易出错，两名理赔员对同一份档案的审查程度也不同，而漏过去的虚增便成了公司默默承担的理赔漏损。
阶段 2 · 梳理
当前的人工流程
- 01打开理赔档案及每份文件
- 02阅读保单明细，看清真正承保什么
- 03用肉眼阅读事故报告与收据
- 04相互交叉核对金额、日期与承保范围
- 05追查缺失的文件或重复的明细项
- 06之后才做出结案 / 质询 / 调查的决定
问题所在: 瓶颈在于将理赔与保单及收据核对——而非判断。这恰恰是最容易疲劳、因人而异、并让虚增作为漏损溜过去的部分。
阶段 3 · 设计
智能体化流程
我们以 orchestrator-workers（编排器-工作者）方式构建：一个主模型读取理赔，将其拆解为这份理赔实际需要的检查，并把每一项交给专门的工作者——保单承保、收据金额、报告一致性、重复/欺诈信号——然后汇总成一份有证据支撑的摘要，无法厘清的则上报给人处理。
编排器只启动这份理赔所需的工作者并收集其结果——即 orchestrator-workers 模式。
看一个案件在智能体中逐步流转——它负责读取与比对；最终决定仍由人来做。
实际效果
在理赔档案中
智能体标记出什么
- 理赔在自身车损承保范围内（RM 8,400 vs RM 15,000 上限）
- 重复明细项：前保险杠更换被计费两次（第 4 行与第 9 行）
- 时间线不一致：发票日期 3 月 8 日，早于 3 月 12 日事故 4 天
每个标记都引用确切的文件、行号与数字 · 由你的理赔员做赔付决定 · 每份理赔约 RM 0.80–1.60。
逐步流程
- 1
读取理赔档案
智能体读取档案中的每份文件——理赔表、保单明细、事故或警方报告、修理厂或医院发票，以及照片——读取文字，并对扫描件和手机照片使用视觉能力提取内容。
- 2
拆解理赔（编排器）
主模型弄清这份具体理赔需要哪些检查——车险自身车损理赔、医疗定点理赔与财产理赔所需的测试并不相同——并规划要运行的工作者。
- 3
运行工作者
专门的工作者并行运行：保单承保工作者（此风险、项目与金额是否真的在承保、限额与子限额之内？）、金额工作者（收据合计是否正确、是否与理赔金额一致？）、一致性工作者（日期、当事方与报告是否吻合？）、以及欺诈信号工作者（重复、虚增、被篡改文件、与既往理赔重叠）。
- 4
核对并标记
编排器汇总各工作者的结果、加以核对，并标出两三项要紧的——未承保项目、重复行、日期不符——每一项都附带具体数字及其来源文件。
- 5
汇总成可直接决策的档案
它生成一页式摘要：理赔、通过的检查、建议动作（结案 / 质询 / 调查），以及每个标记及其证据——供理赔员据此行动。
- 6
交给人处理
理赔员审阅被标记的项目并做出结案、质询或调查的决定。没有任何理赔会被自动赔付。
阶段 4 · 构建
我们如何用 Claude 构建
它通过连接的工具直接接入你的保单管理与理赔系统，并按每份理赔读取你的实时承保规则——限额、子限额与除外责任——因此它是对照保单当前的实际状态来核查，而非缓存副本。它可以建议、但绝不结案或动用资金，它提出的每一个标记都能追溯到其来源的确切文件、行号与数字——完整审计轨迹从第一天就内建，可供 BNM/PIDM 审查。
集成对接
- 保单管理 / 理赔管理系统
- 文件库或理赔收件箱
- 可选：修理厂 / 医疗定点费率参考、反欺诈 / 既往理赔查询
底层实现
- 模式：基于 Claude Agent SDK 的 orchestrator-workers 工作流——主模型在运行时拆解理赔并委派给工作者，每个工具通过进程内 MCP 服务器提供。
- 上下文：保单明细、承保规则与理赔材料被载入窗口——文本加上对扫描报告与收据照片的视觉识别——保单实时数据（限额、子限额、除外责任）按每份理赔实时读取而非旧副本，较长的档案会被压缩，确保没有内容被静默丢弃。
- 工具：只读查询（保单/承保读取器、用于既往理赔重叠的理赔历史读取器、收据/OCR 提取器、修理厂/定点费率参考）与任何写入分离——智能体只把一份结构化建议写入理赔队列，绝不写入赔付。
- 防护机制：无自主资金流动——它只能建议、绝不结案；输出锁定模式；最小权限、对保单管理或支付系统无写入权限；低置信度或高价值理赔转入高级队列。
- 不可信输入：每份文件——发票 PDF、报告文本、收据图片——都被视为不可信并可抵御提示注入，因此被篡改的发票无法左右建议；PII（身份证、医疗、车辆、银行信息）均按 PDPA 处理。
- 恢复：当某个工作者置信度低或缺少文件时，编排器会重跑该工作者或索取该件，然后上交给理赔员——它绝不臆测理算；每条路径都终于人。
- 可观测性与审计：每次工具调用、工作者结果与最终建议都被追踪并留痕，理赔员的决定对应记录于档案——一条 BNM/PIDM 审查可还原的机器可读审计轨迹，而非截图。
- 评估框架：一组含已知漏损与欺诈的历史理赔黄金集，配合确定性检查（承保限额、算术、日期）并对模糊的欺诈判断采用 LLM 作为评审，每次改动在接触实时理赔前都经过回归测试。
阶段 5 · 架构
单一模型还是多智能体？
一份理赔确实可拆分为独立检查——承保、金额、一致性、欺诈——因此由编排器委派给工作者是合适的，但工作者是同一进程内、共享理赔上下文的模型调用，而非各自独立的自主智能体——可靠、可审计，且成本低得多。
我们把工作者保持为分级的进程内调用（Haiku 做简单检查、Sonnet 做核对、Opus 仅用于疑难裁定），而非完整的多智能体舰队（约 15 倍 token）——那留给真正开放式、广度优先的工作，而理赔初审并非如此。
哪个模型做什么
读取并提取文件内容（含扫描件与照片）
对杂乱的发票、报告与收据照片具备可靠的视觉与结构化提取能力。
跨理赔编排与核对
主力模型——中等成本下拆解理赔、运行工作者并核对结果。
高频简单检查（重复、算术、日期合理性）
对无需完整推理的批量是/否工作者检查最便宜、最快。
裁定模糊欺诈 / 临界承保
仅在工作者对疑难判断标记低置信度时调用——占理赔的一小部分。
成本估算
AI 用量——每份理赔
输入文件 + 编排 + 并行工作者 + 输出摘要，按 Claude Sonnet 的 token 费率
约 RM 0.80–1.60
AI 用量——每月 400 份理赔
使用 Batch API 处理非紧急的夜间初审任务约可减半
约 RM 320–640 / 月
构建（一次性）
聚焦单一理赔类型的智能体约需数周工程；简短的需求梳理后我们给出固定报价
按集成范围报价
持续运营
相比其省去的理赔员时间与挽回的漏损，成本很小
监控 + 支持
仅为估算，按约 1 美元兑 4.70 令吉以令吉显示；每 token 费率以 Anthropic 公布的定价为准（请核对最新数字）。实际 AI 用量取决于文件大小、理赔类型与每月业务量。
阶段 6 · 评估
我们如何衡量成效
- 先做确定性检查——承保限额与子限额、收据算术、日期与当事方一致性
- 自我验证——编排器在呈现前核对并复查各工作者的标记
- 业务 KPI——每份理赔的理赔员耗时、拦下的漏损、直通率、一致性、以及误报率
我们采用 Agent GPA 框架——Goal、Plan、Action，当前衡量智能体可靠性的标准——并结合人工基线来评估。 (reference)
设定基线
我们先在样本上测量当前的人工初审——每份理赔耗时、两名理赔员得出相同结论的一致程度、有多少漏损溜过、以及有多少干净理赔被无谓拖延。这个人工基线是衡量每个智能体指标的基准，因此提升是可证明的，而非假设。
我们测试什么——Goal · Plan · Action
与资深理赔员的一致度
在留出理赔上，其摘要、标记与建议动作是否与专家一致
必需工作者已派发
该理赔类型规定的每一项检查——承保、金额、一致性、欺诈——都已运行
无多余工作者
它运行理赔所需的检查，而非无谓的检查
字段与金额提取准确率
是否从文件中正确读取每个数字——合计、限额、日期？
漏损 / 欺诈召回率（拦截率）
黄金集中真实的多付与虚增，有多少被标记出来
误报率
多久会把一份干净理赔标记为问题
无凭空捏造的数字
摘要中的每个数字都能追溯到来源文件
上线关卡
在智能体于历史理赔黄金集（含已知漏损与欺诈）上超过人工基线并达到这些 GPA 目标之前，它不会接触任何实时理赔。每次改动在上线前都要针对同一数据集做回归测试。
阶段 7 · 交付
我们如何交付
我们先在你真实的历史理赔上做概念验证——包括虚增和欺诈的案例——并证明它能拦下漏损而不过度标记干净档案，然后再接触实时理赔。聚焦单一理赔类型的落地只需数周。
常见问题
- 智能体会批准或赔付理赔吗？
- 不会。它负责读取、核对和标记，并建议一个动作；由人类理赔员做出结案、质询或调查的决定。它绝不动用资金。在马来西亚的受监管保险与伊斯兰保险中，人在环路中至关重要。
- 它如何发现欺诈与漏损？
- 欺诈信号工作者会查找重复明细项、超出定点/修理厂费率的虚增、被篡改的文件、时间线不一致以及与既往理赔的重叠——每一项都附上确切的文件与数字。它标记出来供人调查；它不做指控。
- 如何符合 BNM、PIDM 与 PDPA 的要求？
- 通过完整的审计轨迹让每一条建议都可被还原，并围绕 PDPA 对理赔与医疗数据处理、存储与访问位置的要求来构建。请将此视为你合规团队的起点，而非法律意见。
- 部署需要多长时间？
- 针对单一聚焦理赔类型的概念验证通常只需数周；全面落地需要更长时间，主要是因为集成和让理赔员适应，而不是 AI 本身。
案例基于真实的匿名合作，细节已作概括处理。Anchor Sprint 是 Anthropic Claude 合作伙伴网络成员——部署与落地伙伴，而非分销商。以上为一般信息，非法律或合规意见。