案例背景：一家支付机构为什么值得看
拉卡拉是持有支付业务许可证的第三方支付机构（深交所 300773.SZ），服务对象以中小商户为主。选择它作为复盘对象有三个理由：其一，数据出自半年报这一法定披露文件，而非营销通稿，数据至少经过审计口径的约束；其二，其 AI 应用覆盖了产品端、业务流程端与研发组织端三个层次，是少见的「全链路」样本，而非单点客服机器人；其三，支付行业对数据安全与合规的要求严苛，在这种行业里跑通的工程做法对金融、政务等强监管行业更有参考价值。
先看披露的整体口径。2026 年上半年，拉卡拉营收同比增长 22.86%，扣非归母净利润同比增长 50.28%；跨境支付累计服务商户超 25 万家（同比增长 55.86%）。AI 相关披露集中于半年报「全力推进 AI 向实」一节，核心量化指标如下：
| 指标 | 数值 | 披露口径 |
|---|---|---|
| 累计落地 AI Agent | 71 个 | 含员工自建智能助手 |
| 日均 Token 消耗 | 40 亿+ | 全公司口径 |
| AI Coding 代码采用率 | 70% | 研发流程 |
| 整体研发效率提升 | 35% | 公司自评口径 |
| 客户咨询一次性解决率 | 84.7% | AI 智能体嵌入客服工作台后 |
| 智能客服转人工率 | 13% | 全年 800 万+ 次接线中人工替代超 70% |
| 商户入网审核时长 | 缩短约 75% | AI 审核 + 本地化 OCR |
| AI 审核准确率 | 超 98% | 日均处理上万件合规审查 |
商户端·产品层：AI 钱包与「对话即服务」
商户端产品（AI 钱包）解决的是中小商户数字化服务的经典痛点：功能越堆越多，入口越藏越深。查一笔账单、确认结算进度、处理 POS 机故障，传统模式下需要商户自己知道「功能在哪个页面」。AI 钱包的改造思路是让商户用文字或语音直接描述需求，由系统理解意图后匹配服务——目前已覆盖账单查询、结算查询、设备答疑、经营助手等高频场景。
这一层的工程含义容易被低估：它不是给 App 加一个聊天窗口，而是把原有的功能导航体系重新组织为意图到服务的映射。商户不需要学习菜单层级，交互复杂度从「人找功能」转移到「系统理解人」。对本站读者的参照价值在于：面向非专业用户（如个体商户）的智能体产品，交互层的设计权重不低于模型能力——用户说不清术语，系统就得扛住模糊表达。
业务流程·嵌入层：客服 84.7% 与审核 -75% 的口径辨析
业务流程层是这份披露里信息密度最高的部分，但也是口径最需要小心的部分。
客服侧：半年报表述为「AI 智能体嵌入客服工作台，客户咨询一次性解决率提升至 84.7%」。关键限定词是「嵌入工作台」——这是人机协同架构：AI 在客服人员的工作界面里辅助理解、查询与处理，而非完全无人值守的自动应答。因此 84.7% 与某些海外案例宣传的「全自动解决率」（如 TSA Ace 案例的 96% 免转人工）不是同一口径：前者度量「首次接触即解决」的服务质量，且包含人工参与；后者度量「无需人工介入」的替代率。两个数字不可横向比大小。
更清晰的替代率口径在另一组数字里：智能客服转人工率降至 13%，全年 800 多万次客户接线服务中人工替代率超 70%——这组口径与海外案例可比性更高，也更能反映真实的自动化深度。账单查询、设备报修、功能指引这类高频、低风险、强规则的咨询，是自动化的主力场景。
审核侧：商户入网环节引入 AI 审核与本地化 OCR，自动识别、提取、校验营业执照与法人身份信息。三个量化结果：审核时长缩短约 75%、人工审核量下降三分之二、日均处理上万件合规审查且准确率超 98%。「本地化」三个字值得注意——营业执照与法人身份属于敏感个人信息，在支付行业的监管语境下选择本地部署的识别能力而非公有云 API，是合规约束直接塑造技术选型的典型案例。
延伸的效率数据是：商户接入周期从传统约 7 天缩短至小时级，AI 智能体可自动生成核心支付接口调用代码、覆盖 65 个细分行业。这与客服/审核共同构成「商户体验时间」的完整压缩：从进件审核到接口对接，等待环节被系统性移除。
研发组织·内化层：70% 代码采用率怎么读
研发侧的披露是「AI Coding 代码采用率达 70%，整体研发效率提升 35%」。「代码采用率」（AI 生成代码被保留进代码库的比例）已是行业通用口径，GitHub、Google 等均发布过类似指标，70% 处于已披露企业案例的较高区间——作为对照，公开报道中行业普遍区间多在 30% 到 60% 之间，头部互联网公司披露过 50% 上下的水平。
但两条提醒必须放在前面：其一，采用率高不等于质量高——AI 生成代码的采用往往伴随代码审查与返工成本的上升（行业研究普遍观察到重度 AI 使用团队 bug 与重写率的增加），70% 的采用率若无缺陷率、返工率数据配套，无法直接推断研发质量的变化；其二，「研发效率提升 35%」是公司自评的综合口径，未披露测量方法（是交付周期、人均产出还是迭代速度）。两条数据放在一起，合理的读法是：AI Coding 已深度进入这家支付机构的交付主流程，但「效率提升」的幅度应以公司自身前后对比为参照，而非跨企业横比。
规模账本：71 个 Agent 与日均 40 亿 Tokens
71 个 Agent 与日均 40 亿+ Tokens 这组总量数据，放在行业坐标系里有信息量：
- 71 个 Agent 的构成：半年报明确其中包含「支持每位员工创设自身工作需要的智能助手」——即相当比例是员工自建的长尾助手，而非全部是核心业务智能体。这与 IDC 调研中企业平均运行约 11 条生产级 Agent 工作流的口径并不矛盾：71 是全量计数（含自建工具型助手），11 是公司出资的生产工作流均值。两种统计口径在跨案例对比时经常被混用，值得警惕。
- 40 亿 Tokens/日意味着什么：按年化约 1.46 万亿 tokens 计，这已经是一个中型推理集群的消费量级。对照 IDC 统计的、有可见性企业的月均 Agent 推理支出约 11.76 万美元，拉卡拉这个量级的日消耗对应的成本账单、以及它是否纳入了统一治理（模型路由、缓存、预算护栏），半年报没有披露——而这恰恰是复制该案例时最该先算的账。
商户端产品（AI 钱包）、业务流程嵌入（客服+审核）、研发组织内化（AI Coding+员工自建助手）——三层共享同一个「AI+数据」双中台底座。结构的价值在于复用：客服与审核复用同一套意图理解与 OCR 能力，员工助手复用同一套平台工具链，避免每个场景重复造轮子。
可迁移的四条经验
剥离行业特性后，这份案例有四条做法对计划规模化的企业有直接参考价值：
- 用「流程嵌入」替代「单点工具」：客服 AI 不是独立问答机器人，而是嵌进客服工作台的辅助层；审核 AI 不是独立系统，而是嵌进入网流程的流水线工位。Agent 的价值在流程的接缝处，不在孤立的对话窗口里。
- 让员工成为 Agent 的生产者：71 个 Agent 中大量来自员工自建，公司提供平台与工具链而非中心化排期开发。这解决的是规模化落地的老难题——需求长尾太散，中心化研发永远排不过来。
- 合规约束前置到技术选型：审核环节选本地化 OCR 而非云端 API，把数据不出域作为架构前提。强监管行业的 Agent 落地，合规设计不是上线前的检查项，而是选型时的首要约束。
- 披露可验证的量化结果：用法定文件披露具体百分比而非形容词，使案例本身可被审计与复核。这一点对内对外都成立——对内是治理纪律，对外是行业参照。
三条提醒与未披露清单
辩证地看，这份披露的局限同样清晰：
- 厂商自报、缺基线对照：84.7%、70%、35% 等指标均为公司自评，未披露改造前的基线值与测量方法。横向引用时应标注口径，避免与不同口径的海外案例直接比大小。
- 技术栈未披露：底层模型、智能体框架、平台供应商均未公开。外部观察者无法判断其能力边界来自自研还是采购，「AI 平台为底座」的具体形态（公开报道提及 AI 钱包、MOSS 平台等产品名，但架构细节有限）尚不可考。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
- 成本与质量的另一半账本缺失：日均 40 亿 tokens 对应的成本账、AI 生成代码的缺陷率与返工率、AI 审核误判的申诉率——这些「负向指标」的缺位不影响成果的真实性，但会影响复制者的预期校准。任何准备对标的企业，都应把这半本账纳入自己的立项测算。
总体而言，拉卡拉案例的价值不在某个单点数字的惊人程度，而在它示范了一条已被验证的路径：支付行业这类强监管、高合规门槛的业务，智能体规模化落地是可实现的——前提是把 AI 当作流程改造工程而非产品功能堆叠，并且接受「三分之二的账本先亮出来」这个不完美但诚实的起点。