Agent Bucket + OCR + 微信支付特约商户进件：一个多智能体系统的存储底座实践

原创

悟空码字

发布于 2026-08-11 10:12:06

大家好，我是小悟。

进件材料散落各处、进度靠人盯、敏感信息明文流转，这是服务商在拓展特约商户时反复踩的坑。本文记录如何用 Agent Bucket 作为多智能体协作系统的持久化底座，把微信支付特约商户进件做成一件"可记忆、可追溯、可回退"的工程。

一、进件为什么需要一套"会记忆"的系统

微信支付服务商替商户发起进件（即特约商户入驻）时，要采集主体、联系人、经营、结算、银行账户五大类信息，字段加起来超过四十个。其中身份证号、银行卡号、手机号属于敏感个人信息，按规定必须用微信支付平台公钥做 RSA 加密后才能上送，明文严禁出现在传输链路里。材料侧还要上传营业执照、法人身份证正反面、结算银行卡照片，商户随手一拍往往单张就有四五兆。

以前这套流程靠运营在电子表格里登记、在群聊里催商户发图、手工把字段粘进微信支付商户平台。问题从来不在"能不能做"，而在"做不做得稳"：商户发来的图太大传不上去，字段填错要翻半天聊天记录找原始材料，运营换班后新人接不住进度，同一个商户被重复问一遍身份证号。其实想解决的不是省掉人工，而是给这套流程一个不会失忆的底座，让多个智能体分工协作时，每一个中间状态都能被持久化、被恢复、被审计。

这就是 Agent Bucket 进入系统的原因。

二、Agent Bucket 在多智能体里的位置

先说下怎么开通Agent Bucket，登录智能体桶Agent Bucket。

创建智能体桶

创建空间

把进件系统拆成三个智能体：编排智能体负责串流程、派任务；材料预审智能体调用腾讯云 OCR 把营业执照和身份证识别成结构化文本；加密落库智能体专门处理敏感字段的 RSA 加密和写入存储。它们各自只关心自己的职责，但必须共享同一份"事实"。Agent Bucket 承担的就是这份事实的存储：它以 Space（商户空间）为一级容器，Task（进件任务）为二级单元，外加一组用于协作的分享令牌。三个智能体之间不直接互相传文件，而是把产物写入 Bucket，再从 Bucket 读取下游需要的状态。

这种设计的直接好处是故障隔离。加密落库智能体处理到一半崩了，编排智能体重启后从 Bucket 读到的还是上一次写到一半的任务快照，不需要商户重新传图。底层存储可以是腾讯云 COS 这类对象存储，Bucket 的抽象层把 V5 签名、分区、生命周期这些细节屏蔽掉，上层只看到 put / get / delete 三个动作，换存储后端也不用动业务代码。

三、一次特约商户进件的完整旅程

一个商户从建空间到拿到进件单号，在系统里是这样走的：先建 Space，再在 Space 下建进件 Task；材料不齐时由材料预审智能体调用腾讯云 OCR 把营业执照和身份证识别成结构化文本，自动回填表单；图片超过两兆就先压缩；敏感字段经 RSA-OAEP 加密后连同元数据写入 Bucket；最后编排智能体用微信支付 v3 接口（签名方案 WECHATPAY2-SHA256-RSA2048）提交，把返回的进件单号和状态回写 Bucket。

微信支付 v3 进件的请求体本身就是一个结构化的拼装过程：contact_info 装联系人姓名、手机、邮箱；subject_info 装主体类型（企业还是个体户）、营业执照、法人信息；business_info 装经营类目与场景；settlement_info 装结算规则；bank_account_info 装银行卡；addition_info 装补充材料。这些段落里大部分字段和 OCR 预审抽出来的结构化文本是对得上的，提前落进 Bucket，提交时直接组装，不必临时再去问商户。

值得单独说一下补正环节。微信支付驳回后，商户不需要从头来过，因为原任务还躺在 Bucket 里，运营在旧任务上改字段、重新加密、重新提交即可。进度对商户和运营两边都可见，因为 Bucket 里存的是同一份权威状态，而不是某个人微信里的截图。

四、敏感字段怎么安全落地：加密与存储的衔接

微信支付要求上送的身份证、银行卡、手机号必须用平台证书或微信支付公钥做 RSA 加密，密文用 base64 编码。这里有个工程上的细节：商户填进来的可能是一段 PKCS#1 的 BEGIN RSA PUBLIC KEY，也可能是 PKIX 的 BEGIN PUBLIC KEY，甚至还可能是整张 BEGIN CERTIFICATE 平台证书。三种格式本质都装着同一对 (n, e) 模幂参数，但字节结构完全不同，解析错一层就会得到垃圾值。

在加密模块里做了一层 PEM 结构识别：先判断进来的是裸公钥还是证书，证书就先抽出里面的 SubjectPublicKeyInfo，再统一解析出 (n, e)，最后用 OAEP-SHA256 填充加密。之所以选 OAEP 而不是老的 PKCS#1 v1.5 填充，是因为 OAEP 带随机盐和 SHA256 哈希，能挡住选择密文攻击，而 v1.5 在理论上有可利用的弱点。

加密产出的密文不会散在内存里等提交，而是随任务元数据一起 put 进 Bucket，按 space/task 两级分区存放。这样即便提交环节失败，密文也已经在存储里，重试时直接读取即可，不用让商户重复提供敏感信息。解密钥匙只在微信支付侧，系统自始至终只持有密文，运营和日志里看不到任何明文。

五、材料预处理：OCR 预审与图片压缩

商户发来的照片质量参差不齐，有的手机直出十几兆，有的拍得歪斜模糊。在上传环节加了两道闸：第一道是体积闸，超过两兆先压；第二道是识别闸，压完再调腾讯云 OCR。

压缩用 Pillow 实现，策略是先把最长边缩到两千像素以内，再按 JPEG 或 WebP 从质量 92 逐级降到 0.3，直到体积落到两兆以下，过程中保留肉眼可见的信息。OCR 区分印刷体和手写体两种模式：营业执照、身份证走印刷体识别，个体工商户手写的经营备注走手写体。识别出的文字直接回填到表单对应字段，运营只需核对，不必逐字敲。

预审的意义不只是省力。OCR 能从一张营业执照里抽出统一社会信用代码、商户全称、注册地址，这些字段恰恰是 subject_info 的必填项，提前结构化能大幅降低提交后被驳回的概率。预审回填准确率够高，运营核对一遍就能提交，材料被打回的次数明显比纯手工填低。

六、Space 与任务的生与死：级联删除

数据要有入口，也要有出口。运营确认某个 Space 不再需要，或者某个进件任务填错了想重来，系统要能干净地删，而且不能误伤同空间下其它在途任务。

删除分两个粒度。删单任务只清该 Task 下的材料和状态；删 Space 则递归清掉它名下的所有子任务，再级联清除这批任务关联的分享令牌，最后做物理文件清理。把删除做成"先列影响范围、再二次确认、最后物理清理"的三段式，避免误删连累商户其它在途进件。分享令牌单独级联，是因为它逻辑上挂在任务上，却可能已经被分发出去，不显式回收就会留下悬空链接，别人还能用旧链接看到已删任务。

七、踩过的坑与工程取舍

第一，存储分区粒度。一开始把所有任务平铺在一个目录，删除 Space 时要遍历全量文件判断归属，慢且易漏。改成 space/task 两级分区后，删 Space 直接删前缀，干净利落，也顺带让每个任务的读写路径更短。

第二，加密与落库的时序。早期把加密放在提交那一刻，结果提交失败就要重加密、重采集，体验差。把密文提前落 Bucket，提交变成幂等的"读密文再上送"，重试成本趋近于零，商户完全感知不到中间失败。

第三，OCR 与压缩的顺序。先压再识别，而不是先识别再压，是因为大图直接送 OCR 既慢又费配额，压到合理体积后识别准确率几乎没有损失，成本却降了一截。这个顺序后来成了处理所有用户上传图片的默认姿势。

第四，删除的可见性。级联删除一开始只返回成功，运营不知道到底清了哪些子任务和令牌。改成先返回一份影响范围清单，确认后再执行，等于在危险操作前加了一道护栏。对存储底座来说，删得对比删得快重要得多。

八、写在最后

Agent Bucket 在这套系统里不是最显眼的角色，它没有 OCR 那样能直接给人看结果，也没有加密那样有密码学光环，但它是让多智能体真正"协作"起来的关键。没有它，每个智能体都是金鱼记忆，流程一断就得重来；有了它，进件变成了一条可追溯、可恢复、可回退的流水线。

对服务商来说，扩展特约商户的瓶颈从来不是"会不会调接口"，而是"能不能把一堆散乱的材料和状态稳稳地管起来"。Agent Bucket 给出的答案，是把状态管理从业务逻辑里剥离出来，交给一个专门的、有生命周期的存储底座。这篇文章记录的，就是用它托起微信支付特约商户进件的全过程，也希望能给正在做类似多智能体系统的你一点参照。