信贷评估智能体
我们设计、构建并部署一个 AI 智能体,读取并交叉核对贷款文件、标记差异,并为你的信贷主管提供可直接决策的摘要——而放贷决定仍由人来做。

见效后会有什么改变
每份申请耗时
当前人工审核
约 25–35 分钟
使用智能体
约 5–8 分钟
节省的时间
每份申请约节省 20–25 分钟——每月 300 份申请约合 100–125 小时,大约相当于半名全职审核人员。
为估算;实际时间取决于文件数量与案件复杂度。
阶段 1 · 界定
业务问题
马来西亚放贷机构的信贷团队将每份申请作为一整套材料接收——身份证、薪资单、银行对账单、融资表格、经销商报价。审核人员一天的大部分时间花在机械性工作上:核对各文件是否一致,而不是判断是否放贷。这个过程缓慢,疲劳时容易出错,两名主管对同一份文件的尽职程度也略有不同。
阶段 2 · 梳理
当前的人工流程
- 01打开申请材料及每份文件
- 02用肉眼阅读并提取关键字段
- 03跨文件交叉核对姓名、收入与账户
- 04追查缺失的月份或不一致之处
- 05之后才开始真正的信贷判断
问题所在: 瓶颈在于文件比对,而非决策——而这恰恰是最容易疲劳、且因人而异的部分。
阶段 3 · 设计
智能体化流程
我们将审核重新设计为 evaluator-optimizer 循环:智能体读取并核对整套材料,评估每一项检查,并反复迭代,直到能生成一份干净、有证据支撑的摘要——无法解决的则上报给人处理。
评估器会反复核对并重新读取,直到检查通过——即 evaluator-optimizer 循环。
看一个案件在智能体中逐步流转——它负责读取与比对;最终决定仍由人来做。
逐步流程
- 1
读取文件
智能体读取整套材料中的每份文件——身份证、薪资单、银行对账单、融资表格、经销商报价——读取文字,并对扫描件和手机照片使用视觉能力提取内容。
- 2
提取结构化字段
它将关键字段提取为一条结构化记录——姓名、身份证号、雇主、申报收入、银行账户、每月负债——并为每一项标注来源文件。
- 3
跨材料交叉比对
它将这些字段相互核对:身份证 vs 薪资单 vs 申请上的姓名;申报收入 vs 实际工资入账;对账单账户 vs 表格账户;所需月份是否齐全。
- 4
评估并迭代(循环)
评估步骤为每项检查打分;当置信度低或检查未通过时,智能体会重新读取或索取缺失的部分再定稿——即 evaluator-optimizer 循环。
- 5
标记并生成摘要
它生成一页式摘要:申请人、通过的检查、以及需要关注的两三项——每一项都附带具体数字及其来源文件。
- 6
交给人处理
信贷主管审阅被标记的项目并做出放贷决定。没有任何内容会被自动批准。
阶段 4 · 构建
我们如何用 Claude 构建
我们在 Claude 上以标准循环构建智能体——收集上下文(导入文件与案件数据)、采取行动(通过 Model Context Protocol 连接的工具进行提取与交叉比对)、验证工作(在呈现前自查其标记)。防护机制与完整审计轨迹从第一天就内建,因此每个决定都可以被还原。
集成对接
- 贷款发起 / 核心系统
- 文件库或收件箱
- 可选:征信局或银行对账单查询
底层实现
- Claude Agent SDK 运行该循环;工具通过进程内 MCP 服务器提供给它。
- 工具:文档库读取器、视觉/OCR 提取器、字段匹配器,以及(可选)征信局或银行对账单查询。
- 防护机制:严格的 JSON 模式输出、对核心系统无写入权限、以及对身份证号、薪资单和对账单符合 PDPA 的处理。
- 人在环路:智能体生成一份结构化的审阅包;主管的决定被记录并留痕以供审计。
- 评估框架:一组历史案例的黄金集(含欺诈)配合确定性检查;每次改动在接触实时申请前都要经过回归测试。
阶段 5 · 架构
单一模型还是多智能体?
信贷审核是顺序进行、共享同一案件上下文的,因此一个完善配置的单一模型是正确选择——可靠、更省成本、也更易审计。
我们把多智能体设计(约 15 倍 token)留给真正并行、广度优先的工作——而非一个紧耦合的单一案件。
哪个模型做什么
读取并提取文件内容(含扫描件)
对杂乱的真实文件具备可靠的视觉与结构化提取能力。
跨材料交叉比对与推理
主力模型——中等成本下的强推理能力,处理绝大多数案件。
处理模糊 / 临界案件
仅在 Sonnet 标记低置信度时调用——占申请的一小部分。
高频简单检查
对无需完整推理的批量是/否检查最便宜、最快。
成本估算
AI 用量——每份申请
输入文件 + 推理 + 输出摘要,按 Claude Sonnet 的 token 费率
约 RM 0.60–1.20
AI 用量——每月 300 份申请
使用 Batch API 处理非紧急的夜间任务约可减半
约 RM 180–360 / 月
构建(一次性)
聚焦单一产品线的智能体约需数周工程;简短的需求梳理后我们给出固定报价
按集成范围报价
持续运营
相比其省去的人工审核时间,成本很小
监控 + 支持
仅为估算,按约 1 美元兑 4.70 令吉以令吉显示;每 token 费率以 Anthropic 公布的定价为准(请核对最新数字)。实际 AI 用量取决于文件大小与每月业务量。
阶段 6 · 评估
我们如何衡量成效
- 先做确定性检查——字段匹配、必需月份齐全、账户一致性
- 自我验证——智能体在呈现前自查其标记
- 业务 KPI——每份文件的审核时间、一致性、处理量、以及拦截到的问题
我们采用 Agent GPA 框架——Goal、Plan、Action,当前衡量智能体可靠性的标准——并结合人工基线来评估。 (reference)
设定基线
我们先在样本上测量当前的人工流程——每份文件耗时、两名审核员得出相同结论的一致程度、以及有多少问题漏掉。这个人工基线是衡量每个智能体指标的基准,因此提升是可证明的,而非假设。
我们测试什么——Goal · Plan · Action
与资深审核员的一致度
在留出案例上,其摘要、标记与建议检查是否与专家一致
必需检查全部执行
每一项规定检查都执行——不遗漏
无无谓的循环
仅在检查确实未通过时才重新读取,而非无端反复
字段提取准确率
是否正确读取每个字段——姓名、收入、账户?
差异召回率(拦截率)
黄金集中真实的不一致,有多少被标记出来
误报率
多久会标记出并非真正问题的内容
无凭空捏造的数字
摘要中的每个数字都能追溯到来源文件
上线关卡
在智能体于历史案例黄金集(含已知欺诈)上超过人工基线并达到这些 GPA 目标之前,它不会接触任何实时申请。每次改动在上线前都要针对同一数据集做回归测试。
阶段 7 · 交付
我们如何交付
我们先在你真实的历史文件上做概念验证——包括杂乱和欺诈的案例——在接触实时申请前先证明可靠性。聚焦单一产品线的落地只需数周。
常见问题
- 智能体会批准或拒绝贷款吗?
- 不会。它负责读取、比对和标记;由人类信贷主管做出批准或拒绝的决定。在马来西亚的受监管借贷中,人在环路中至关重要。
- 如何符合 BNM 与 PDPA 的要求?
- 通过完整的审计轨迹让决定可被还原,并围绕 PDPA 对信贷数据处理、存储与访问位置的要求来构建。请将此视为你合规团队的起点,而非法律意见。
- 部署需要多长时间?
- 针对单一聚焦产品线的概念验证通常只需数周;全面落地需要更长时间,主要是因为集成和让审核人员适应,而不是 AI 本身。
案例基于真实的匿名合作,细节已作概括处理。Anchor Sprint 是 Anthropic Claude 合作伙伴网络成员——部署与落地伙伴,而非分销商。以上为一般信息,非法律或合规意见。
