PayPack

01PayPack 是什么？AI Agent 支付中间件（middleware）

PayPack 是一款让 AI Agent 自动付款的支付中间件（middleware）。它把散落在各处的支付底层能力——x402、AP2、支付宝、微信、USDC、ETH——封装成一个统一的 agent.pay() 接口。

所谓「支付中间件」，指的是位于 Agent 与支付渠道之间的一层封装：Agent 只说「我要付这笔钱、付给谁、付多少」，中间件负责按渠道差异完成签名、下单、验签、回调通知、状态落库这一整套动作。开发者不需要读几百页开放平台文档，不需要写几十行 RSA2 签名代码，也不需要自己处理沙箱与回调。

它的适用对象是国内外的 AI 应用开发者：用 LangChain、LlamaIndex、Dify 搭建 Agent 的团队，以及需要让 Agent 自主购买 API 额度、数据服务、算力的场景。对这类场景来说，PayPack 提供的是一层可替换的支付适配层，而不是一个封闭的收银台。

需要注意的是，PayPack 与同站的志辉模拟交易、志辉量化系统是相互独立的产品：前者面向开发者做支付，后者面向交易学习者做训练与考核，二者在账户与资金上不互通。

02AI Agent 自动付款要解决哪些问题

让 Agent 自己付钱，难点并不在「发起一笔支付」，而在下面这几件事上。绝大多数团队第一次尝试时，都会在第三、第四点上卡住。

• 渠道碎片化：国内走支付宝与微信，海外走 USDC 与 ETH，两条链路的签名方式、回调格式、对账口径完全不同，需要写两套代码。
• 协议差异：x402 与 AP2 是两套并行的 Agent 支付协议，服务端返回 402 时的交互流程不同，Agent 侧需要能自动判断并切换。
• 额度失控：Agent 是自动运行的，一次循环 Bug 就可能重复下单。没有日支出上限与熔断，风险是不可控的。
• 可追溯性：出了争议要能回放「谁在什么时候、因为什么、付了多少钱」，这就要求每一笔都有完整的审计日志。
• 小额高频：Agent 之间的结算常常是几分钱级别，传统支付的费率与最小金额结构并不适合这种形态。

PayPack 的设计目标是让上面这五件事都由中间件承担，业务代码只需要描述意图。换句话说，业务方关心的是「付给谁、付多少」，而不是「怎么签、怎么验、怎么重试」。

03已验证的真实支付（数字事实）

下面这些数字来自真实环境跑通的支付闭环，不是概念验证或界面截图。每条都可在源码仓库的示例与提交记录中核对。

四条链的覆盖让同一套代码可以在不同网络之间迁移：Base 与 Arbitrum 的低手续费适合小额高频，以太坊主网适合较大金额，Polygon 则常用于已有生态的团队。

当前发布版本为 0.5.0，以 Python 包形式分发，同时提供 Gitee 与 GitHub 两个镜像仓库。版本号与包大小可以在 PyPI 页面与仓库 release 中直接核对。

04三步接入：让 Agent 自动完成 payments

从零到跑通一笔支付宝支付，只需要三步。整个流程不需要申请额外的支付牌照或中间账户。

pip install https://gitee.com/rhcjw_com/paypack/raw/master/dist/langchain_paypack-0.5.0-py3-none-any.whl

from paypack.signer.alipay import AlipaySigner
from paypack import AgentPay

signer = AlipaySigner(app_id="你的APPID", private_key_path="私钥.pem", sandbox=True)
pay = AgentPay(signer=signer, network="alipay", spend_limit_daily=10.0)

# AI 付人民币
receipt = pay.send(to="用户支付宝user_id", amount=0.01, currency="CNY")

# 链上支付：自动处理 HTTP 402
response = requests.get("https://api.data-provider.com/premium")
if response.status_code == 402:
    content = pay.auto_handle_402(response)

链上支付场景下，auto_handle_402(response) 会读取响应里的付款要求，按当前链与币种发起付款，成功后自动重放原请求。整个过程对上层 Agent 是透明的，Agent 不需要知道 402 的存在。

如果要限制 Agent 的花钱能力，可以在初始化时设定 spend_limit_daily，并在业务侧对单笔金额做二次校验。两道限制同时生效，任何一道超限都会直接拒绝写入审计日志。

05支持哪些支付方式？支付宝、微信与 crypto（USDC/ETH）

PayPack 在一套接口下同时覆盖法币与链上两类通道，这意味着同一个 Agent 可以既给国内用户发支付宝收款，又给海外服务用 USDC 付款。

• 支付宝：支持 RSA2 签名、电脑网站支付、订单查询与退款；沙箱与生产环境共用一套调用方式。
• 微信支付：支持 JSAPI 与 Native 扫码两种形态，回调通知由中间件统一处理。
• USDC / ETH：覆盖 Base、以太坊、Polygon、Arbitrum 四条链，私钥不出本地。
• x402 与 AP2：对上层暴露统一的付款语义，协议差异在中间件内部消化。

需要说明的边界是：PayPack 负责「发起与确认支付」，不负责持有用户资金。商户号、结算账户仍然属于使用方自己，这既是合规要求，也让资金流保持在可审计的既有体系内。

对于同时服务国内与海外用户的团队，这套组合可以避免维护两套支付代码。国内渠道用于人民币收款，链上渠道用于向海外 API 供应商付款，两条链路共用同一份额度控制与审计日志。

06PayPack 与其他 AI Agent 支付中间件对比

下表按同一套维度比较目前主流的几个 Agent 支付方案。判断标准是「能否直接服务国内用户的人民币支付需求」，而不是功能数量。

这张表也说明了 PayPack 的局限：如果你的用户全部在海外、只刷信用卡，Stripe Agent Toolkit 的生态与文档成熟度更高，没有必要为了统一而统一。反过来，只要业务里存在人民币收款需求，其他方案就需要额外自建一层国内通道。

如何选择，可以按下面的判断走：用户主要在国内、且需要自动收款或自动付款，选 PayPack；用户全在海外、只涉及信用卡，选 Stripe Agent Toolkit；只需要钱包基建、支付逻辑自己写，看 Privy。三者并不是互相替代的关系，实际项目里也可能同时使用。

07LangChain / LlamaIndex / Dify 集成方式

PayPack 以工具（Tool）的形式暴露给 Agent 框架，因此不需要改造框架本身。对 LangChain，插件包名为 langchain-paypack，安装后直接作为工具注册。

• LangChain：注册为 Tool 后，Agent 在遇到付费接口时自动调用；插件已提交官方社区集成讨论（Issue #38727）。
• LlamaIndex：以 Tool 形式挂载，复用同一份 AgentPay 实例。
• Dify：通过自定义工具接入，适合低代码编排的团队。
• 原生 Python：不依赖任何框架，直接调用 pay.send() 与 auto_handle_402()。

无论走哪条集成路径，额度控制、审计日志与熔断都发生在 AgentPay 实例上，因此安全边界不依赖框架的实现方式。这一点在把 Agent 交给非技术团队使用时尤其重要。

08上游仓库与许可：早期社区版 Apache-2.0，当前及后续迭代版闭源

早期社区版以 Apache 2.0 许可发布，源码托管在 Gitee 与 GitHub 两个仓库，PyPI 上的包名为 langchain-paypack。Apache 2.0 允许商用、修改与再分发，但要求保留版权与许可声明。当前及后续迭代版本为闭源，用于「数字基地」建设，不随仓库发布。

• 中文文档与主要开发在 Gitee 仓库进行，国内访问更稳定。
• GitHub 仓库作为国际镜像，便于海外团队查看与提交问题。
• PyPI 提供标准 wheel 包，可纳入既有依赖管理流程。
• License 全文见 Apache 基金会官方页面，仓库根目录也随附一份。

需要区分的是三类东西：早期社区版开源代码（Apache 2.0，可自由使用）、当前与后续迭代版本（闭源，用于「数字基地」建设）、以及托管与商业模块（PayPack Cloud 云服务，以及需要 License Key 的商业模块如微信支付模块）。三者的可用性、计费与支持条款各自独立，云服务条款与开源代码许可无关。

09trading 与教学策略示例类 Agent 的付费场景

在交易与量化领域，Agent 的付费需求出现得比其它行业更早：策略运行过程中需要按次购买行情、按调用购买因子数据、按时长租用算力，这些支出天然适合由 Agent 自主完成。

• 行情与数据订阅：Agent 按需购买数据接口额度，用多少付多少，避免长期包月浪费。
• 算力与回测资源：回测任务提交前先完成计费，任务结束自动结算。
• 服务调用付费：调用他人发布的教学示例信号或分析服务时，按调用量自动付款。
• 收款侧：策略提供方用支付宝或微信向国内用户收款，用 USDC 向海外用户收款。

需要明确的是，PayPack 只处理「付费」这一层，不涉及交易执行、不触碰资金账户、也不提供投资建议。交易与投资相关的功能由使用方自己的系统承担，两者在架构上应当分离，这也是把支付风险与交易风险隔开的基本做法。

把付费逻辑独立成一层之后，交易系统本身的复杂度不会增加，而支出的可审计性会明显提高——每一笔数据采购、算力租用都能对应到具体任务。

10PayPack 适合谁、不适合谁

适合以下情况：

• 用 LangChain / LlamaIndex / Dify 搭建 Agent，需要让 Agent 自主为 API、数据、算力付费的开发者。
• 业务面向国内用户，需要支付宝或微信收款，同时希望保留链上支付能力的团队。
• 需要为 Agent 设定支出上限、并要求支出可审计的团队。

不适合以下情况：

• 用户全部在海外、只使用信用卡支付——这类需求用 Stripe Agent Toolkit 更直接。
• 需要的是托管资金、清结算或代收代付牌照服务的场景——PayPack 不持有资金，不提供此类服务。

把边界写清楚，是为了避免选型时产生误解：PayPack 解决的是「Agent 如何完成一次支付」，而不是「如何搭建一个支付机构」。

12相关链接与参考来源

本页引用的技术规范与官方文档如下，均为可公开访问的原始来源，便于核对文中提到的协议与接口定义。

• x402 协议规范：x402.org（HTTP 402 付费协议）
• 支付宝开放平台文档：opendocs.alipay.com（RSA2 签名与网站支付）
• 微信支付开发文档：pay.weixin.qq.com（JSAPI 与 Native 支付）
• LangChain 官方文档：python.langchain.com（Tool 与 Agent 用法）
• Apache 2.0 许可全文：apache.org/licenses/LICENSE-2.0

「国内 AI 开发者想让 Agent 自动付钱，之前只能自己读支付宝开放平台文档、写 RSA2 签名、处理回调。PayPack 把这些都封装掉了，两行代码就能跑通真实支付。」

—— PayPack 项目维护者 · 厦门世准科技

13立即体验：平台试用

如果不想先在本地跑代码，可以直接用云托管版本验证一遍完整链路：下单、支付、回调、权益发放。