第 29 章：Agent 经济与商业化 — 当 Agent 学会花钱和赚钱¶
2026 年 Agent 领域最容易被忽视、但确定性最高的一条主线是：Agent 正在从"消耗你的 API 额度"进化为"拥有自己的身份、预算和支付能力"。这一层协议和基建正在快速成型，而中文内容几乎空白——本章把这条线一次讲透，并给开发者一条清晰的变现路线图。
29.1 为什么「Agent 经济」是下一个确定性机会¶
过去两年 Agent 领域的竞争集中在"调度"和"编排"（第 3–10 章）、"工程化"（第 25–27 章）。但一条更深的主线一直在水面下推进：
2024：Agent 会调用工具（人付钱，Agent 干活）
2025：Agent 会调用别人的 Agent（MCP / A2A 协议成熟）
2026：Agent 会花钱、会定价、会签约（Agent Payments / Agent Identity）
判断依据（2026-10 实测）：
- 支付巨头全部进场：Visa、Mastercard、PayPal、Stripe 均已发布面向 AI Agent 的支付产品线（Visa Intelligent Commerce、Mastercard Agent Pay、PayPal Agent Toolkit、Stripe Agent Toolkit）。
- 协议标准出现：Google 牵头的 AP2（Agent Payments Protocol）、Coinbase 主推的 x402（HTTP 原生微支付）、IETF 的 Agent 联网付费标准草案（402 状态码复活），三股力量在收敛。
- Agent Identity 立法与规范起步：让 Agent 以"可问责的身份"调用 OAuth、持有密钥、签署交易，是支付落地的前置条件——Cloudflare、Okta、Auth0 已推出 Agent Identity 方案。
给你的启示：编排框架会过时（第 18 章选型决策树每半年就要重画），但"身份、授权、支付"是 Agent 经济的协议层，一旦定型十年不变。现在进入，等于 2015 年进入移动支付。
29.2 三大支付协议速览¶
29.2.1 x402：HTTP 402 状态码的复活¶
Coinbase 开源 · 语言无关 · 链上结算（USDC）为主，兼容法币扩展
它是什么：HTTP 协议里的 402 Payment Required 状态码沉睡了三十年，x402 把它激活为机器间微支付标准：客户端请求资源 → 服务端返回 402 + 价目 → 客户端用签名凭证自动付款 → 重试拿到内容。全程无人工、无账户体系、单笔可低至 $0.001。
为什么适合 Agent：Agent 调用第三方 API / 爬取数据 / 调用另一个 Agent 时，最大的摩擦是"开户、绑卡、审批"。x402 让 Agent 拿着预算密钥即可按次付费，天然适配机器对机器的长尾小额交易。
最小闭环（伪代码）：
GET /api/weather → 402 {"price": "0.001 USDC", "pay_to": "0xABC..."}
X-PAYMENT: <签名凭证> → 200 + 数据 # 服务端验证后放行
29.2.2 AP2：Google 的「可问责支付」¶
Google 牵头 · 与 x402 互补（AP2 定义"为什么付"，x402 解决"怎么付"）
它是什么：AP2 的核心贡献是Mandate（授权凭证）体系——用户、Agent、商家三方之间用密码学签名传递"谁授权了这笔交易"：
- Intent Mandate：用户意图（"帮我在预算 ¥200 内买双跑鞋"）
- Cart Mandate：Agent 选好商品后的购物车快照，需用户签名确认
- Payment Mandate：支付时刻的责任链，任何一方可事后审计
为什么重要：它回答了 Agent 商业化最尖锐的问题——Agent 买错了东西谁负责？ AP2 的答案不是"信任模型"，而是"每一环都可验证、可追责"。银行和卡组织只接受这种答案。
29.2.3 平台自营路线：Stripe / PayPal Agent Toolkit¶
不想碰协议细节的最短路径：Stripe 和 PayPal 都发布了官方 Agent Toolkit，把支付抽象成 Agent 的普通工具调用（MCP server 或 function calling 均可）。适合快速给现有 Agent 加"收款"能力——比如你的 Agent 帮用户生成了报告，用户在对话里直接付款。
29.2.4 选型对照¶
| 方案 | 定位 | 结算 | 学习成本 | 适合谁 |
|---|---|---|---|---|
| x402 | 机器间微支付 | 链上（USDC）为主 | 低 | 数据/API 按次售卖、Agent 间付费调用 |
| AP2 | 可问责消费支付 | 卡组织/银行 | 中高 | 电商、需要合规审计的场景 |
| Stripe/PayPal Toolkit | 平台内收款 | 法币 | 极低 | 给现有 Agent 快速加收款 |
三者不冲突：现实中常见组合是 x402 管 Agent↔Agent 长尾交易，AP2 管 Agent↔商家大额消费，Toolkit 管你自己的产品收款。
29.3 Agent Identity：没有身份就没有经济¶
支付的前置问题是身份。2026 年的主流方案有三层：
- 人类委托授权（Delegated OAuth）：Agent 持有用户 OAuth token 的受限子集，权限最小化 + 全程审计。适合"替我操作"类 Agent。
- 独立 Agent 身份：Agent 拥有自己的密钥对与 DID（去中心化身份），第三方可验证"这是哪个主体签发的 Agent"。x402 与 AP2 的签名体系都建在这层。
- 预算硬约束（Spend Mandate）：无论哪种身份，工程实践上都必须给 Agent 加金额上限、频率上限、白名单收款方三道闸——这是把"模型幻觉"和"资金安全"隔离的最后防线。
⚠️ 红线：永远不要把主卡、主密钥直接交给 Agent。所有实验请用独立子账户 + 单笔限额。这一条在第 25 章权限体系支柱之上，还要再加资金维度。
📚 串联阅读：第 25 章 Harness Engineering（权限体系支柱）→ 第 11 章 MCP 协议（工具授权模型）→ 第 16 章 可观测性（支付行为的审计日志）
29.4 开发者变现路线图（从 0 到收钱）¶
这一节是本章的落点：学会 Agent 经济协议之后，你自己如何收钱。按成熟度分四级，每级都有 2026 年已验证的路径。
第 1 级：内容变现（门槛最低）¶
- 开源核心 + 付费增值：手册类/工具类仓库保持 MIT 开源换取影响力与信任，将「深度模板库、企业级示例、答疑社群」做成付费层。关键指标是 Watchers 和 CLI 装机量（见第 30 章评测驱动迭代）。
- Sponsor / 赞助：GitHub Sponsors、爱发电。适合 500+ stars 后开启。
第 2 级：Agent 产品收款（Toolkit 路线）¶
- 用 Stripe / PayPal Agent Toolkit 给你的 Agent 产品加收款，在对话内完成付费转化，转化率远高于跳转网页。
- 定价模式参考：按次（单份报告）、订阅（月度监控类 Agent）、按结果（成交抽佣）。
第 3 级：把你的服务变成 x402 端点¶
- 把已有的 API（爬虫、检索、生成、评测）包成 x402 可付费端点，让其他 Agent 成为你的客户。2026 年的先发红利在于：市面上可被机器付费消费的端点仍然稀缺。
- 收入模型从"卖给人"变成"卖给 24 小时不睡觉的机器"。
第 4 级：企业级 Agent 交付（AP2 路线）¶
- 企业场景（采购 Agent、对账 Agent）需要 AP2 级别的可问责性。提供"协议合规 + 审计日志 + 权限矩阵"的整体方案，客单价最高。
- 这一层的技术栈贯穿全书：编排（3–10 章）+ Harness（25 章）+ 可观测性（16 章）+ 本章协议层。
变现检查清单¶
- 我的开源资产是否有清晰的「免费/付费」分界线（而不是含糊地说"以后可能收费"）？
- 是否装好了收款的最短路径（Sponsors / Toolkit）？
- Agent 持有的每一把密钥是否都有金额与频率上限？
- 每一笔 Agent 发起的交易是否可审计、可追责（Mandate / 日志）？
- 是否有一项服务可以包装成机器可付费的端点？
29.5 本章小结¶
- Agent 经济的三根支柱：身份（Agent Identity）→ 授权（Mandate）→ 支付（x402 / AP2 / Toolkit），缺一环都跑不通。
- 协议层比框架层保值：框架半年洗牌一次，支付与身份标准十年一遇。
- 开发者变现四级火箭：内容 → 产品收款 → 机器可付费端点 → 企业交付，每一级都可以立刻动手。
- 资金安全红线：限额、白名单、可审计，任何实验都不得突破。
📚 串联阅读：第 28 章 2026 热门项目全景 → 第 25 章 Harness Engineering（权限体系）→ 第 30 章 Agent 评测（用评测证明你的付费服务值这个价）