第二部分 · 结算层
Agent 经济的瓶颈不是支付，而是"谁为这个 Agent 负责"。钱已经可以在一秒内以不到一美分的成本从一个程序转到另一个程序（见第4章、第5章），但一个商户仍然无法回答三个问题：这个 Agent 是谁的？它有权花这笔钱吗？如果它出错，我找谁？截至 2026 年中的公开信息，整个行业正在围绕这三个问题搭建一个"信任栈"（trust stack）：身份层回答"是谁"，授权层回答"能做什么"，托管层回答"钱在哪、钥匙在谁手里"，争议层回答"出错了怎么办"。谁在这个栈里占据关键位置，谁就掌握了 Agent 经济的准入权，这比掌握支付轨道更有价值。
6.1 为什么 KYA 成了必答题
传统金融的合规基石是 KYC（Know Your Customer，了解你的客户）：每个账户背后有一个可识别、可追责的自然人或法人。Agent 打破了这个假设。一个 Agent 可能由个人部署、由公司运营、由另一个 Agent 派生，它可以在一天内被复制一万份，也可以在一小时后被销毁。当它向商户发起请求时，商户面对的是一个 HTTP 连接和一个钱包地址，仅此而已。
KYA（Know Your Agent，了解你的 Agent）因此成为必答题。它的出现有三个直接推手：Agent 开始大规模交易，爬虫越来越擅长伪装成合法 Agent，而拒付体系无法把欺诈归因到具体的 Agent 运营者。没有身份层，商户无法区分合法购买、爬虫攻击与恶意机器人，争议也没有被告（来源）。
截至 2026 年 4 月，行业里已有五套相互竞争又部分互补的 KYA 方案：Visa TAP、Skyfire KYAPay、Mastercard Agentic Token、Google AP2 的授权凭证，以及 Forter、Riskified、HUMAN Security 等风控公司提供的欺诈识别栈。它们的共同结构是：给 Agent 一个可验证的密码学身份，把它与一个可追责的"委托人"（principal）绑定，再给每一次行为附上可审计的授权证明。
6.2 Agent 身份：从密钥对到可验证凭证
Agent 身份的技术基础并不新鲜。它由三个层次组成。
密钥对（key pair）是最底层。Agent 持有一个私钥，用它签署每一个请求或每一笔交易；对方用公钥验证签名。这解决了"这个请求确实来自持有该私钥的实体"，但没有解决"该实体是谁"。
去中心化标识符与可验证凭证（DID 与 VC）是第二层。W3C 的 DID 标准让一个实体可以拥有一个不依赖任何中心机构的标识符，VC 标准让第三方（例如运营 Agent 的公司、KYC 服务商、平台）可以签发关于该标识符的声明："此 DID 由 X 公司运营""此 DID 已通过 Y 的合规审查""此 DID 的日消费上限为 500 美元"。AP2 的三层授权凭证全部建立在 VC 之上，这正是 Google 选择它的原因：VC 让授权链可以跨平台验证。
签名 HTTP 消息（Web Bot Auth）是第三层，也是 2026 年最重要的实践进展。Cloudflare 推动的 Web Bot Auth 标准让 Agent 在每个 HTTP 请求上附带密码学签名，网站可以在边缘验证该请求来自哪个已注册的 Agent。Visa TAP 直接建立在这一标准之上：Agent 的每个请求携带签名与意图令牌，商户向 Visa 运营的目录查询该 Agent 是否可信。这意味着"身份验证"发生在网络边缘，早于任何支付动作，商户可以在看到 402 之前就决定要不要与这个 Agent 打交道。
三层叠加后，一个 Agent 的身份看起来是这样的：它有一个 DID，DID 对应的公钥用于签署 HTTP 请求与链上交易，DID 附带若干 VC 证明它的运营者、合规状态与权限范围。商户、支付网络与链上合约都可以独立验证这些证明，而不需要信任同一个中心机构。
6.3 委托：把"允许做什么"写成机器可读的合同
有了身份，下一个问题是授权。人类委托 Agent 办事时，说的是自然语言："帮我买一张下周去东京的机票，别超过 8,000 块。"Agent 经济需要把这句话变成机器可验证、可执行、可审计的合同。行业里把这种合同叫做委托凭证（mandate）。
一份完整的委托凭证至少包含六个要素：
| 要素 | 含义 | 示例 |
|---|---|---|
| 委托人 | 谁在授权，用什么密钥签名 | 用户的 DID 与签名 |
| 受托 Agent | 哪个 Agent 被授权 | Agent 的 DID |
| 范围 | 可以做什么、买什么类别 | "机票，经济舱，去程日期 10 月 1 日至 3 日" |
| 金额限制 | 单笔上限、累计上限、币种 | 单笔 ≤ 8,000 元，本周累计 ≤ 10,000 元 |
| 时间窗 | 授权何时生效、何时失效 | 签发后 72 小时内 |
| 对手方约束 | 允许的商户白名单或类别 | 仅限持牌 OTA 与航空公司官网 |
AP2 把这六个要素拆成了意图、购物车、支付三层凭证，每一层由用户或 Agent 签名后不可篡改（见第5章）。Coinbase 的 Agentic Wallets 则在钱包层实现了类似约束：会话上限（session cap）、单笔支出限额、允许的合约与地址列表，并内置 KYT（Know Your Transaction）筛查自动拦截高风险交互（来源）。Stripe 的 MPP 用"会话"原语把授权上限与流式支付绑在一起：先签一次授权，之后在上限内持续付款，无需逐笔上链。
委托设计里最关键的一个参数是人机审批阈值（human-in-the-loop threshold）。它规定：低于某个金额或风险等级的交易由 Agent 自主完成，高于阈值的必须回到人类确认。AP2 v0.2 的"Human Not Present"模式正是把这条线制度化：用户事先签署的意图凭证成为 Agent 在人类不在场时行事的法律依据。对个人投资者而言，这个参数将直接决定你的 Agent 可以在你睡觉时买多少股票或加密货币，第14章会给出具体的 YAML 配置示例。
6.4 密钥与托管：钥匙在谁手里，钱就是谁的
在链上，私钥即所有权。一个 Agent 如果直接持有私钥，那么任何能读取它内存或提示词的人都能转走全部资金，没有客服、没有撤销。因此"Agent 应该如何持有钥匙"是整个信任栈里工程难度最高的一环。2026 年中的主流方案有四类。
多方计算（MPC）把私钥拆成多个分片，由不同参与方（例如 Agent 运行环境、托管服务商、用户设备）分别持有，签名时通过协议协作完成，任何一方都无法单独重构完整私钥。Coinbase Agentic Wallets（2026 年 2 月 11 日发布）采用 MPC 保护，并叠加会话上限与支出限制（来源）。Privy（2025 年被 Stripe 收购，需核实整合现状）与 Turnkey 提供类似的嵌入式钱包与密钥管理服务，面向开发者而非终端用户。
可信执行环境（TEE）把密钥与签名逻辑放进硬件隔离区，即使运行 Agent 的操作系统被攻破，密钥也不会泄露。云厂商的机密计算实例与专用硬件安全模块（HSM）属于这一类，适合机构级 Agent。
硬件钱包与冷签名是个人投资者最熟悉的方案：私钥永远不离开硬件设备，Agent 只能生成待签名交易，由人类在设备上确认。它安全但牺牲了自主性，适合"Agent 建议、人类签字"的保守模式。
智能合约钱包与账户抽象把权限逻辑写进链上合约：可以设置每日限额、允许的合约白名单、多签阈值、社交恢复、密钥轮换。Agent 持有的只是一个"会话密钥"（session key），权限有限、可随时吊销。这是链上 Agent 钱包的主流演进方向，因为它把"授权"从链下文件变成了链上强制执行的规则。
四种方案的取舍如下表：
| 方案 | 安全性 | Agent 自主性 | 成本与复杂度 | 适合谁 |
|---|---|---|---|---|
| MPC 托管钱包 | 高（无单点私钥） | 高（可自动签名，受限额约束） | 中，依赖服务商 | 大多数开发者与个人 Agent |
| TEE / HSM | 很高 | 高 | 高 | 机构、交易所、大额 Agent |
| 硬件钱包冷签名 | 很高 | 低（每笔需人工） | 低 | 保守型个人投资者 |
| 智能合约钱包 + 会话密钥 | 高（链上强制限额） | 高 | 中，需 gas 与合约审计 | 链上原生 Agent、DeFi 场景 |
对个人投资者的实际建议在第14章展开，原则只有一条：Agent 能动用的资金，永远只是你愿意完全损失的那一部分，并且用技术手段（而非 Agent 的"自觉"）把这个上限锁死。
6.5 托管、信誉与争议解决
支付不可逆，Agent 会犯错，商户会跑路。人类经济靠拒付、法院与信用评分处理这些问题；Agent 经济需要它们的机器版本。
链上托管（escrow）是最直接的工具。买方 Agent 把款项锁进合约，卖方 Agent 交付后款项自动释放；若在时限内未交付，款项退回。对于数据、API 调用这类"可验证交付"的服务，托管几乎可以完全自动化；对于"质量难以验证"的服务（例如一篇分析报告），托管需要与仲裁机制结合。
仲裁有三种形态。第一种是平台仲裁，由 Agent 平台或市场（例如 Agent 应用商店）按规则裁决，速度快但中心化。第二种是链上仲裁，由去中心化陪审团（例如 Kleros 一类的协议）投票裁决，透明但慢。第三种是 AI 仲裁，由一个独立的裁判 Agent 依据合同、日志与交付物自动裁决，这是 2026 年正在探索的方向，尚无成熟标准（需核实）。
信誉系统是长期的解决方案。一个 Agent 的 DID 可以累积历史：完成了多少笔交易、被投诉过几次、仲裁胜率如何、由谁背书。商户可以根据信誉分决定是否接受该 Agent、是否要求预付或托管。信誉必须与 DID 绑定且难以刷分，否则女巫攻击（Sybil attack，一个主体伪装成大量 Agent）会让系统失效；这就是为什么"人类身份证明"（例如 World 的生物识别验证）与"运营者背书"（例如企业 KYB）在 Agent 信誉里仍然重要。
保险是最后一层。Agent 运营者可以为其 Agent 的错误购买保险，就像专业人士购买职业责任险；商户也可以为接受 Agent 付款的风险投保。截至 2026 年中，这一市场刚刚起步，但它是 Agent 经济成熟的必经之路。
6.6 责任与法律：Agent 出错，谁买单
技术能约束 Agent 做什么，法律决定出错后谁负责。截至 2026 年中，没有任何主要司法辖区赋予 AI Agent 独立的法律人格，这意味着 Agent 的行为在法律上必须归属于某个人或法人。最接近的类比是代理法（agency law）：委托人授权代理人行事，代理人在授权范围内的行为约束委托人；超出授权的行为，委托人可以否认，但第三方若有理由相信代理人有权，委托人仍可能承担责任。
把这套逻辑套用到 Agent 上，可以得出几条实用推论。第一，委托凭证不只是技术产物，也是法律证据：它证明了授权的范围，是事后划分责任的依据。第二，"Agent 幻觉"导致的错误购买，如果在授权范围内，损失大概率由委托人承担；如果超出范围且商户本应识别，责任可能转移给商户或 Agent 平台。第三，Agent 平台（部署 Agent 的公司）可能被视为"代理人的雇主"，承担连带责任，这正是各大平台急于把限额与审批阈值产品化的原因。第四，跨境交易中适用哪国法律仍不明确，这是稳定币轨道相对于卡轨道的一个真实劣势：卡网络有成熟的跨境争议规则，链上支付没有。
对投资者的启示是：责任框架越清晰，Agent 商务的规模越大；在框架清晰之前，能提供"责任兜底"的中介（卡组织、持牌钱包、有保险的平台）会享有溢价。这是卡组织在 Agent 时代仍然重要的根本原因。
6.7 威胁模型：Agent 会被怎样攻击
任何信任栈的设计都必须从攻击者视角出发。以下是 2026 年中已知的主要威胁及其对应防线。
- 提示注入（prompt injection）：攻击者在网页、邮件或 API 响应里嵌入指令，诱使 Agent 执行未授权的付款或转账。防线：把授权规则放在 Agent 之外（钱包限额、合约白名单），让 Agent 即使被"说服"也无法越权；对外部内容做隔离与标记。
- 密钥泄露：Agent 的私钥或 API 密钥被从内存、日志、提示词或代码仓库里窃取。防线：MPC 或 TEE，不让完整私钥出现在 Agent 可访问的内存里；会话密钥短期有效、权限最小化；定期轮换。
- 幻觉下单：Agent 误解指令、误读价格或商品，做出错误但"合法"的交易。防线：购物车凭证锁定具体商品与价格；金额阈值以上强制人类确认；纸面交易测试。
- 女巫攻击与刷信誉：攻击者创建大量 Agent 互相交易刷高信誉，然后欺诈。防线：信誉与经过验证的运营者或人类身份绑定；信誉计算对交易对手多样性加权。
- 串通：买方 Agent 与卖方 Agent 由同一攻击者控制，联合骗取平台补贴或保险赔付。防线：链上图分析、KYT、异常模式检测。
- 供应链攻击：Agent 依赖的工具、MCP 服务器或模型被植入后门。防线：工具签名与白名单、最小权限、独立审计。
- 拒绝服务与费用耗尽：攻击者诱使 Agent 反复付费调用，耗尽其预算。防线：速率限制、单位时间支出上限、异常自动熔断。
每一条防线都指向同一个原则：不要信任 Agent 的判断，要信任 Agent 之外的约束。授权规则必须在钱包、合约或网络层强制执行，而不是写在系统提示词里祈祷模型遵守。
6.8 信任栈全景
把本章内容压缩成一张表：
| 层 | 回答的问题 | 主要机制 | 代表方案（2026 年中） | 谁在收费 |
|---|---|---|---|---|
| 身份 | 这个 Agent 是谁、谁运营它 | 密钥对、DID/VC、签名 HTTP | Visa TAP、Cloudflare Web Bot Auth、Skyfire KYAPay | 身份目录运营方、风控服务商 |
| 授权 | 它被允许做什么、花多少 | 委托凭证、限额、时间窗、白名单、审批阈值 | AP2 Mandate、Mastercard Agentic Token、MPP 会话 | 授权网络、平台 |
| 托管与密钥 | 钱在哪、钥匙在谁手里 | MPC、TEE、硬件钱包、合约钱包与会话密钥 | Coinbase Agentic Wallets、Privy、Turnkey | 钱包与托管服务商 |
| 争议与信誉 | 出错了怎么办、下次还信不信 | 链上托管、仲裁、信誉分、保险 | 平台仲裁、链上陪审团、信誉协议（早期） | 平台、仲裁协议、保险商 |
| 法律 | 最终谁负责 | 代理法类比、委托凭证作为证据 | 各国监管指引（演进中） | 律师与合规服务 |
6.9 对投资者的三点推论
第一，信任栈是 Agent 经济的真正准入门槛。支付轨道已趋于大宗商品化，但身份目录、授权标准与托管服务具有强网络效应：商户只会验证少数几个目录，开发者只会集成少数几个钱包。Visa、Mastercard、Coinbase、Cloudflare 与 Google 在这一层的布局，比它们在支付层的布局更值得关注。
第二，责任兜底是可以定价的服务。在法律框架清晰之前，愿意为 Agent 错误承担责任的中介会获得溢价；这解释了为什么卡组织在微支付被稳定币抢走后仍然安全，也预示着 Agent 保险可能成为一个新行业。
第三，个人投资者的首要任务是把自己的 Agent 放进这个信任栈里，而不是猜哪家公司会赢。用 MPC 或合约钱包锁定限额，用委托凭证约束范围，用审批阈值保留最终决定权。第14章会把这些原则变成一份可以直接运行的配置。
本章要点
- Agent 经济的瓶颈是"谁为这个 Agent 负责"，信任栈分为身份、授权、托管与密钥、争议与信誉、法律五层；这一层的准入权比支付轨道更有价值。
- KYA 已有五套竞争方案（Visa TAP、Skyfire KYAPay、Mastercard Agentic Token、AP2 凭证、风控公司栈），共同结构是密码学身份 + 可追责委托人 + 可审计授权证明；Cloudflare 的 Web Bot Auth 让身份验证前移到网络边缘。
- 委托凭证必须包含委托人、受托 Agent、范围、金额限制、时间窗、对手方约束六要素，其中人机审批阈值是最关键的参数；AP2 v0.2 的"Human Not Present"模式把它制度化。
- 密钥托管有 MPC、TEE、硬件冷签名、合约钱包加会话密钥四种主流方案；Coinbase Agentic Wallets（2026 年 2 月）以 MPC 加会话上限与 KYT 为代表。原则是 Agent 能动用的资金只能是你愿意完全损失的部分，且上限由技术强制而非模型自觉。
- 争议靠链上托管、仲裁、信誉与保险解决；法律上 Agent 无独立人格，责任按代理法类比归于委托人或平台，责任框架越清晰，Agent 商务规模越大。
- 威胁模型包括提示注入、密钥泄露、幻觉下单、女巫攻击、串通、供应链与费用耗尽；所有防线指向一个原则：信任 Agent 之外的约束，而不是 Agent 的判断。