Agentic payments：你的AI智能体能花钱，但它能收钱吗？

前阵子我在折腾一个项目，用Claude一口气把整个应用搭完了——前端、后端、数据库、认证、部署，一条龙搞定。正当我觉得自己像个黑客一样牛X的时候，agent最后给我来了一句：“要收款？你需要一个商户账户。传统的PSP（支付服务提供商）入驻需要合规审查，预计至少等一周。”

一周。我花了一个晚上写完的应用，要等整整七天才能开始收那1英镑。这感觉就像你开着法拉利上了高速，结果发现加油站只收现金，而你得先办张银行卡等两周。

这不仅仅是我的经历。我和很多用AI搭产品的朋友聊过，每个人都卡在同一个地方。所以今天我想深入聊聊这个事儿——为什么收钱成了AI时代的瓶颈，以及我们到底该怎么解决它。

---

1. 现在大家都在做什么？让AI能花钱

先说个背景。现在整个行业都在疯狂造“让AI能花钱”的基础设施。

• Google的AP2：给agent发一个“支付授权”，相当于给AI一张信用卡副卡
• Coinbase的x402模式：把HTTP 402状态码（需要付款）变成机器之间的微支付协议，就像给API加了个投币口
• 各种Agent钱包：ERC-4337智能钱包、托管钱包、阈值签名钱包……多到数不过来

这些都很酷。但问题来了——你仔细想想，2026年的AI agent们一天到晚在干嘛？答案是：造产品。

• 用Lovable一个晚上搭个应用
• 用Cursor一个周末搞个SaaS
• 用Claude Code半天写个内部工具

每一个产品最终都需要一件事：收钱。而目前没有任何“花钱协议”能解决“收钱”的问题。

---

2. 每个agent都会撞上的那堵墙

让我给你还原一个我亲眼见过不下百次的场景：

➜ ~ claude "finish my app"
✓ scaffold — Next.js + Tailwind
✓ UI — components & design system
✓ UX — onboarding flow polished
✓ auth — Google sign-in wired
✓ database — schema + migrations
✓ deploy — production live
▸ application is almost ready…
✗ missing: payments

然后agent会告诉你：

“要收款你需要一个商户账户。传统PSP入驻需要合规审查——预计至少等一周才能获批。”

你看，一个晚上写完的应用，要等7天才能开始收1英镑。这哪是风险管理？这分明是上个世纪的工作流——那时候软件要开发好几个月，而且没人回去改这个流程。

更糟的是，如果你连公司都没有：传统路径得先走Stripe Atlas（500美元），非美国创始人还得等IRS发EIN号（雇主识别号），这一等就是几周——而且这还只是“申请资格”的门槛，还没开始真正的入驻审核呢。

所以现在软件的瓶颈已经从“写代码”变成了“收钱”。讽刺不？

---

3. 什么叫“Agent原生”的收款方案？

花钱那边已经有协议了（AP2、x402），但收款这边需要四个核心特性。我把它们拆开来讲清楚：

3.1 机器可读的一切

现在的开发者越来越多不是人，而是AI agent。这意味着你需要：

• llms.txt：一个标准化的、AI能一次性读完的文档格式。就像网站的robots.txt，但给LLM用
• Agent优先的API参考文档：不是给人类看的那种长篇幅、带示例的文档，而是结构化、语义清晰、一个请求就能拿到所有信息的格式

想象一下，你的agent要集成支付，它需要读几十页的开发者文档——如果文档不是机器可读的，agent要么理解错，要么直接放弃。

3.2 供给工具，不只是管理工具

Stripe有个MCP服务器（Model Context Protocol服务器），能让你用自然语言操作已有的账户——查客户、退款、开发票。这很好，但问题是：你得先有一个账户。

Agent原生的需求是更底层的能力：创建账户。不是“管理你已经有的东西”，而是“从零开始给你一个东西”。

这就好比：有人给了你一把车钥匙，但你没车。你需要的是能直接“造一辆车”的工具，而不是“开锁”的工具。

3.3 渐进式KYB（了解你的企业）

这是最核心的设计理念。传统流程是这样的：

1. 你提交申请
2. 他们审核（人工+自动化）
3. 等一周到几周
4. 通过后才能上线

而渐进式KYB是这样的：

1. 你提交基本信息
2. 立刻上线，但有一个真实的、带限额的账户（比如最多收1500英镑）
3. 背景验证在后台并行进行
4. 验证通过后，限额自动解除

风险通过限额和监控来管理，而不是让所有人排队等。这就像信用卡——你第一次申请可能只有2000额度，用好了慢慢涨。而不是“先证明你靠谱，再给你卡”。

3.4 限定范围的凭证

这是安全的基础。你的agent持有的令牌应该：

• 只能创建结账会话，不能提现、不能改设置、不能看其他商户的数据
• 永远不是平台的主密钥——如果agent被黑了，损失是可控的

想想看：如果你把自己的Stripe密钥给了agent，agent被注入恶意指令怎么办？所以必须是最小权限原则：agent只需要一个“能创建支付链接”的令牌，就只给这个权限。

---

4. 实际长什么样？我们搭了一个

基于上面这四个原则，我们团队（UniPaaS，FCA授权的支付机构）做了个东西叫 paas.build。

MCP服务器（给agent用的）

git clone https://github.com/UNIPaaS/paas-build-mcp
claude mcp add paas-build -- node paas-build-mcp/paas-build-mcp.mjs

然后你只需要跟agent说一句：

“把我的业务上线”

agent就会依次调用三个工具：

1. identify_business：通过网络搜索解析你的业务信息
2. go_live：创建真实的商户账户（同时创建沙箱和生产环境，同一会话内完成）
3. create_checkout：生成一个可支付的链接

直接API调用（给人类开发者）

如果你不想用MCP，也可以直接调API：

curl -sX POST https://api.paas.build/api/go-live \
  -H 'content-type: application/json' \
  -d '{"business":"My App","website":"myapp.com","region":"uk"}'
# 返回：
# {
#   "sandbox": {"vendorId": "xxx", "accessToken": "yyy"},
#   "production": {"vendorId": "xxx", "accessToken": "yyy"}
# }

关键点：

• 个人开发者当天就能上线，有额度限制（大约1500英镑），直到验证完成
• 不需要成立公司——这对独立开发者、side project、学生项目来说是巨变
• 前端集成只需要三行React代码（用@paasbuild/react包）
• 费率统一：3.9%

---

5. 这个循环意味着什么？

当花钱和收钱这两半都完备时，有意思的事情发生了：

1. 一个agent用API调用（花钱）构建了一个产品
2. 产品上线开始收款
3. 产品的收入自动覆盖agent自己的API调用成本

完整的经济循环，没有人类在关键路径上，人类只在授权层掌控。

这才是真正的agentic payments——不只是“能花钱”，而是“能赚钱”。

---

6. 一些个人想法

我是UniPaaS的联合创始人兼CTO。我们这周刚推出paas.build。说实话，做支付基础设施十几年，我从来没见过像现在这样的范式转换。

以前我们总说“软件正在吞噬世界”，但那是人类写代码。现在agent在写代码，而人类在设定目标和边界。支付不应该成为这个新世界的瓶颈。

如果你在用Lovable、Bolt、Cursor或者Claude Code做项目，我真的很想听听你的支付痛点在哪。我们为每个平台都写了集成指南，欢迎来聊。

毕竟，如果你的agent能在一晚上造出一个能收钱的产品，那才是真正的魔法时刻。