智能体替人花钱之后：那条规则该由谁来写

结论先行：智能体开始替人付款、替人操作账号之后，企业真正缺的不是工具，而是一份写给机器看的授权协议——哪些钱能自己花、哪些动作必须回头问人。

过去两年关于智能体的讨论，集中在"它能不能干活"。最近这半年，讨论的重心悄悄换了：智能体能不能替人花钱、能不能替人登录账户、能不能在没人盯着的时候自己点确认。这三个问题的答案，正在从技术问题变成一份需要有人写、有人审、有人签字的文件问题。

这份文件叫授权协议。它现在还没有统一模板，但监管文件、行业自律公约和主流支付平台的做法，已经把它的骨架拼得差不多了。把这副骨架翻译成大白话，你会发现其中有一块活是个人创业者能接的——帮企业把智能体的权限边界写成一张能执行的清单。

一、智能体开始动手之后，企业多出来的三个问题

先说清楚为什么这份文件突然变重要了。以前企业用软件，权限是配在系统里的：谁能看哪张表、谁能点哪个按钮，是管理员在后台勾选出来的，写完基本不动。现在不一样了——智能体的权限不是勾选项，而是一份需要写下来的委托。

因为你交给它的不是"打开这个软件"，而是"帮我把这件事办完"。这句话里藏着预算、偏好、禁止事项和必须回头问人的条件，全都没写出来。行业内的说法是：智能体有输出随机性、逻辑不够透明的特点，如果盲目给它交易决策权限，会直接冲击资金交易的信任基础。

谁在交易：是用户本人、是智能体在代理、还是智能体被别的东西利用了冒充用户。这三者的责任划分完全不同。
为何交易：单笔金额在预算内，不代表这笔交易属于原始委托。让智能体买咖啡，结果买了拿铁；预算三十元花了三百元，这些都是偏离。
出了事谁负责：现行规则基本都围绕"人作为最终决策者"构建，而智能体自动发起交易的新模式与之并不适配。

把智能体接进业务之前，先回答这三个问题。答不出来就不要开权限——这也是监管文件反复强调的那句话：用户对智能体的自主决策享有知情权和最终决策权。

二、行业已经给出的答案，其实是一份清单模板

值得读的是：围绕这件事，监管部门和行业组织在最近一年里已经形成了一套相当完整的表述。把它翻译成能落到纸上的东西，是下面五件套。

最小权限：完成这次任务需要什么，才开放什么，不该多给。这条原则在最新的智能体安全治理框架里被明确写出——不为了省事一次性把账号、文件夹、支付权限全开。
分级授权：自主程度要分档。有行业协议参照自动驾驶的思路，把智能体支付的自主化从"每笔都要人确认"到"完全自主"分成六档，中间两档是主推区间——单一任务内可自主发起、超出预设范围就得回来问。
人工确认要带足信息：让人点头之前，得让人看清收款对象、金额、异常提示，以及这笔交易是否符合原始委托。但同时要避免变成"甩锅式确认"——如果每次都弹一个"是否确认"，审核的人会形成惯性点同意，人工审核就流于形式。
默认拒绝：审批系统异常、用户没有响应、或者根本没有对应的审批规则时，操作不能自动继续，应当默认拒绝。这一条最容易被漏写，也是出事时最关键的一条。
全程可追溯：身份可识别、授权可验证、行为可监控、责任可追溯。行业协议里对应的做法是每一笔自主交易都绑定委托凭证、决策日志和执行令牌，数据不可篡改。

另外还有两条行业基础设施层面的共识：一是引入"了解你的智能体"（KYA）的概念，把过去只针对人的客户识别，扩展到智能体身份；二是资金隔离——主流支付平台的做法是给智能体单独开一个受限额度的独立钱包账户，和用户主账户物理隔离，风险敞口天然被限定住。

还有一条来自实践的警告：权限管不住钱，接口本身更危险。有些机构已经明确表示不接受智能体直接触发资金划拨、转账支付、账户开立销户这类改变账户状态的动作，只允许它做信息归集和材料初筛这类前置辅助工作；境外也有多家银行在最近收紧第三方智能体访问客户账户的权限。业内用了一个很形象的比喻：多环节串联会让可靠性逐级相乘下降，单步可靠性是百分之九十九时，乘起来大约只剩九成，而这类业务的差错容忍度低得多。

三、为什么这份清单值一次收费

现在回到个人创业者能切进去的地方。判断一档活值不值得做，看三件事：客户是不是真的在痛、这件事是不是必须有人做、做完的结果能不能被检验。

这份清单三项全中：

真的在痛：智能体权限这件事没有标准答案，行业还在演进，但客户已经不能等——不等就意味着要么全放开（出事），要么全不放开（用不起来）。两头都是成本。
必须有人做：这件事不是买一个软件能解决的。它要求把客户的业务流程拆开，判断哪一步可以让机器做、哪一步必须人确认、哪一步在异常时该停下。这需要读业务，不只是读文档。
结果可检验：交付物很明确——一张权限矩阵表、一份人工确认触发清单、一份默认拒绝与异常处置规则。上线前做一次越权测试，看智能体会不会做出没被授权的动作，测一次就知道清单有没有漏洞。

收费理由也清楚：这份清单直接决定事故率和审计成本。一个被审过的权限方案，客户敢把更大的权限打开；一个没被审过的，客户会一直把权限锁在最小范围，你也就一直没有后续生意。

四、一人公司怎么切：三个交付物 + 三个坑

如果要动手，我建议把交付固定成三份东西，一次做完、一次验收、一次归档：

权限矩阵表：一行一个动作，列出动作名称、由谁触发、涉及哪些数据、影响金额区间、是否允许自主执行、触发了找谁确认。这张表是后面所有事的基础。
人工确认触发清单：明确写出哪些情况必须停下来问人，并且把问人时的提示信息写全——对象、金额、异常点、与原始委托的偏差。避免只写"重要操作须经确认"这种没法执行的句子。
默认拒绝与异常处置规则：审批无响应、审批系统异常、规则缺失、超出授权范围、遇到未定义动作，这五种情况分别默认怎么处理。这一份是出事时唯一能救你的东西。

三个坑要提前避开：

把规则写成一句原则。"涉及资金的操作必须人工确认"——这句话在执行时没有边界，智能体无法判断哪一笔算"涉及资金"，最后会退化成什么都不拦，或者什么都拦。要写具体触发条件。
照抄别人家的分级编号。分级是按自己的业务风险分的，不是按别人的。同一笔两千元的订单，对一家做批发和一家做奢侈品回收的公司，风险完全不是一回事。要按金额敏感度和动作影响面自己切档。
只写允许的，不写默认怎么办。绝大多数授权文件只列了"可以做什么"，没有列"遇到没写的情况怎么办"。而系统默认行为往往不是"拒绝"，是"按最接近的规则猜一个"。

五、这份协议和你签给客户的服务合同，是同一件事的两头

最后说一个把这行和之前几期连起来的观察。企业允许智能体自己花钱，和你答应客户"我会用 AI 帮你做这件事"，本质上是同一类问题：授权边界写在哪里。

一边是决策授权——用户决定让智能体做到哪一步、哪些事它可以自己拍板、哪些必须回来问你；另一边是执行授权——你承诺交付到什么程度、哪些环节是机器做哪些环节是人做、出了偏差由谁兜底。行业文件里的原话是授权被拆成"决策授权"与"执行授权"，决策层的归责目前尚不明确。

对个人创业者来说，这是一件值得记住的事：过去你只需要管好执行这一头，因为决策一直是人做的，错了也是人担。现在机器开始替你决策了，两头都得写清楚。能把这套东西写成条款的人，在任何一边都比只会干活的人更值钱。