Agent 要花你的钱,先证明它是谁——Visa、Mastercard、蚂蚁联手推 Know-Your-Agent 框架
现状之痛:这半年我们讨论 Agent,讨论的都是「它会不会做错事」。上个月 Meta 让消费级 Agent 开始自己订票、付款;支付网络紧跟着问了一个更靠前的问题——它凭什么相信这笔付款背后是一个「被授权的 Agent」,而不是一段被劫持的脚本?钱能花出去了,但「谁在花」这件事,行业到今天还没有统一答案。
读完你将:拿到一套给 Agent「证明身份」的落地方法——为什么支付网络先解身份、再解额度;一份刚发布的 Know-Your-Agent 框架到底承诺了什么、还差什么;以及不依赖任何新标准、今晚就能加到自己系统里的授权留痕三件套。全部有真实字段和真实门槛。
上一篇我写 Meta 让 Agent 自己动钱,收在一句话上:能确定的交给代码,必须交给 LLM 的,用额度把它框住。今天把闸门再往前挪一格——额度管「能花多少」,但它回答不了「谁在花」。
一、支付网络先问的,不是额度,是身份
9 月 9 日到 10 日,蚂蚁国际、Visa、Mastercard 三家一起宣布,就 Know-Your-Agent(KYA)互操作框架展开合作。BusinessWire 的官方稿写得很克制:这个框架要帮卡组织、数字钱包、Agent 平台和市场,把 Agent 的接入与识别统一起来,让 AI 驱动的支付更安全、更能规模化。PYMNTS、Forkast、The Next Web 都跟了这条。

注意这个顺序。过去两年我们给 Agent 加护栏,第一反应都是「给它多少额度」「它能调哪些工具」。现在支付网络把第一个问题换成了:这个 Agent 是谁、代谁做事、授权范围有多大、它此刻还在不在范围里。
额度是算术题,身份是证明题。算术题错了,账单上看得见;证明题错了,一笔合规外衣下的错付款可以顺利走完全流程。
KYA 的定位很像 KYC 的镜像:KYC 验的是开户的那个人,KYA 验的是替你操作的那台机器。区别在于,人只有一个身份,Agent 的身份是「委托人 + 授权范围 + 有效期」的组合,还必须能跨网络被第三方验证——单家平台自己发的令牌不够用,原因就在这里。
二、一份没有规范、没有治理、没有时间表的框架
热度归热度,得看清它现在到哪一步了。
Forkast 的报道给了三个「没有」:这份框架目前是高层的互操作意向,没有规范、没有治理机制、没有时间表。三家各自竞争的支付协议先承诺互通,真正的技术细节和治理规则都还没影。
这不是唱衰。标准化的历史大多如此——先有意向声明,再有规范草案,最后才是实现与认证。但对真要拿 Agent 去干活的人来说,它意味着一个很实际的判断:身份这件事,不能等标准长出来再动手。
同一条时间线上,Google 的 Agent Payments Protocol 做的是另一件事——它记录交易时每一方看到的信息,方便事后对账;但 Fortune 的报道点出一个缺口:当 Agent 买了一件你压根没批准的东西,这套记录帮不上忙。记录不等于授权,日志里有这件事,不等于这件事被允许过。
三、把「谁授权的」变成每个动作的必答题
我们这边的做法比标准朴素,也早得多。
这套系统跑了 276 天,error-ledger 记了 80 条事故,每条四段式写全:症状、根因、解法、状态。它回答的一直是「哪里错了」。这次 KYA 的新闻让我意识到,账本漏了一个字段——approved_by,回答「谁授权它做的」。事故账本管的是复盘,授权账本管的是追责,两件事。
围着这个字段,我们手上有三件已经跑起来的东西。
第一件,策略前置。每个动作进来先过一遍 ALLOW / DENY / 升级给人,规则写在代码里,不写在提示词里。这就是所谓的 0 号闸门——它嵌在推送脚本最前面,不通过就 exit,物理上绕不过去。
第二件,范围校验。Agent 声明自己是谁、代谁做事之后,系统检查这一次动作在不在它被授予的范围里。范围是清单,不是感觉——工具走白名单,凭据不进 Agent 的环境。
第三件,动作留痕,只增不删。这条线上我们还缺 approved_by,所以它是这次要补的那一环。

有一件事得盯住:授权范围会漂移。今天允许的动作,三个月后可能已经不是当初那件事了。范围不是一次授权就永久有效,这是留痕要盯的第二件事。

四、一份可照抄的授权校验骨架
落到代码上,授权校验和额度闸一样朴素。核心是把「它想做」和「它被允许做」拆成两个必须分别通过的东西。
# Authorization check: prove who, before letting it act
def authorize(agent, action):
if not agent.identity: # who is acting
raise Denied("no identity") # anonymous -> reject
if action.tool not in agent.allowed_tools: # what it may do
return escalate_to_human(action) # out of scope -> human
if not agent.mandates.matches(action): # on whose behalf
raise Denied("out of mandate") # beyond mandate -> reject
if action.amount > agent.confirm_threshold:
return escalate_to_human(action) # big action -> human
rec = execute(action) # only place it acts
ledger.append(rec, actor=agent.identity, approved_by=action.approval)
return rec
验证思路和验证发布门禁一样,三步就能看到授权链路在工作:
# dry-run the three boundaries
python3 authz.py --dry-run --anonymous # expect: Denied: no identity
python3 authz.py --dry-run --tool unknown # expect: escalate_to_human
tail -3 ledger.jsonl # expect: every rec has approved_by
顺序还是不能反:先有身份和范围,再给执行能力。先让 Agent 跑起来、再补授权,等于先把自己的名字签在一张空白支票上。
五、留痕优先于标准
KYA 这类框架会解决「可验证」——让一个 Agent 的身份被陌生网络认出来。它解决不了「该不该」:一份凭据再漂亮,也不告诉你这次付款在业务上是否成立。
所以当下两件事可以并行:一边等标准,一边把自己这侧的授权留痕做扎实。标准是别人的时间表,留痕是你自己的。等标准落地那天,一份字段齐全的动作账本,就是你手上第一件能直接对齐规范的东西。
边界也要说清楚。这套东西能回答「谁授权、范围多大、有没有越界」,回答不了「这个授权本身合不合理」。前者是工程问题,后者仍然是人拍板的事。
身份不是一张证书,是每一次动作都能回答「谁授权的」。
结尾
支付网络开始问「Agent 是谁」,说明这条路已经走到需要身份基础设施的深度。对我们来说这是好事——因为留痕这件事,不依赖任何人的规范先落地。
机器负责快,人负责对。补一句:账本负责回答「谁让它快的」。
此刻的你
一句话读懂:支付三巨头刚就 Know-Your-Agent 框架达成合作,给 Agent 一个可跨网络验证的身份;但规范落地要等,而「谁授权的」这件事今晚就能做——身份与授权留痕,是动钱治理的下一层。
三个认知
- 治理的顺序在变:支付网络先问身份,再问额度。额度是算术题,身份是证明题,后者错得更隐蔽。
- 标准还在纸面,不能等:Forkast 说得直接,框架目前无规范、无治理、无时间表;只记录交易的方案,也回答不了「这笔压根没被批准」。
- 留痕优先于标准:授权字段今晚就能加,KYA 规范要等它慢慢长出来。谁先把自己的授权追溯做扎实,谁先对齐规范。
你应该带走的真正价值
- 价值一(技术人/团队场景):拿到授权校验的最小骨架——身份、工具范围、委托范围、确认点、账本五处检查,都能写成一个函数里的 if,不依赖任何新标准。
- 价值二(个人开发者/OPC 场景):一套「先证明、再执行」的落地写法,把身份与范围校验放进真正执行动作的那一层;让「越界发不出去」由代码保证,而不是由记性保证。
- 价值三(长期机制场景):把 approved_by 写进每一条动作记录,只增不删;再挂一个定时复盘,把当天的越界尝试回流成明天的范围清单。账本越厚,授权越干净。
三步行动
| 步骤 | 动作 | 验证 |
|---|---|---|
| 1 | 列出 Agent 能自主执行的动作,圈出其中涉及钱或不可逆操作的那些 | 每个动作都能说出委托人是谁、范围多大 |
| 2 | 给这些动作加一层身份与范围校验,放在真正执行的入口 | dry-run 一个越界动作,被物理拒绝或升级给人 |
| 3 | 动作账本加 approved_by 字段,挂一个定时复盘 | 随机抽一条记录,能追到授权来源 |
金句:身份可验证是可选项,授权可追溯是必选项——KYA 解决前者,你先做后者。
延伸阅读(实践派系列)
- Meta 让 Agent 自己订票付钱:消费级 Agent 开闸,治理的最后一公里是资金闸门
- AI 编程助手在企业网络装了「无主代码」:Coding Agent 供应链安全的工程化答案
- Agent 工程化物理化体系全景——从概率到确定性的完整工程路径
关于作者 无记——AI / Agent / 数智化转型实践者。只写亲手跑通的东西,不聊概念。关注我,一起把认知变现。

浙公网安备 33010602011771号