给智能体配手机号和钱包之前，先把权限和风控想清楚

一个做本地生活服务的团队，前阵子把智能体接进了自己的下单流程：它能自己打电话给商户确认库存，能自己在平台上下单，还能自己付款。上线第一周，团队里所有人都在庆祝效率提升——原本需要三个人轮班处理的确认电话，现在全自动。

第二周出了事。智能体在一次库存确认里，把商户报的一个临时价格当成了长期协议价，连续三天按这个价格下单，等财务对账时才发现多付了一笔不小的钱。更麻烦的是，没人知道是哪一步把那个价格记下来的，日志里只有一句正常下单。

这类事情正在变多。最近一段时间，智能体产品密集地往同一个方向走：给智能体配手机号、配账号、配钱包，让它从能回答问题变成能办成事情。方向是对的，但从能说到能办，中间隔着一道很多人没认真做的功课——权限和风控。

这篇不讲概念，给的是一套可以直接照着做的分级方法和检查清单。

先分清智能体的四种行动等级

不要一上来就谈能做什么，先按风险把行动分成四档，每一档对应不同的授权方式。

• 只读级：查信息、读数据、生成草稿。风险最低，可以全自动，唯一要做的是记录。
• 可撤销级：发内部消息、创建待办、生成并保存文件。做错了能撤回，可以全自动，但要有回滚入口。
• 外部可见级：对外发消息、提交表单、公开发布。做错了撤不回或者撤回成本很高，必须人工确认后再执行。
• 资金与承诺级：付款、下单、签约定价、对客户做出承诺。任何一笔都必须有额度上限、有审批、有完整留痕。

多数事故都发生在把第三档和第四档误当成第二档来处理。判断标准很简单：这个动作做错了，你能不能在十分钟之内、不借助外部协助的情况下撤回。能撤回的可以自动化，不能撤回的一律加确认。

额度要设在三个层面，而不是一个

很多人给智能体设权限，只设了一个总额度，比如每月最多花五千。这个做法基本无效，因为事故往往不是慢慢超额度，而是一次性打穿。

正确的做法是设三层。

• 单笔上限：任何一次操作不能超过这个数。这是最重要的一层，决定了最坏情况下单次损失有多大。
• 单日上限：一天累计不能超过这个数，用来防连续出错。
• 异常触发阈值：单笔超过某个数、或者一天内同类操作超过某个次数，自动转人工审批，不管总额还剩多少。

三层都设了，才算真的有约束。只设总额度的系统，本质上是把风险敞口开到了总额度那么大。

留痕要记到能复盘的程度

上面那个团队最大的问题不是多付了钱，是查不出来。日志里只有正常下单四个字，复盘时谁也不知道那个价格是从哪一步来的。

智能体的留痕至少要记清楚五件事。

• 输入：这一步收到的原始信息是什么，包括对方说了什么、页面显示了什么。
• 判断：智能体基于什么理由做了这个决定，它认为的关键信息是哪一条。
• 动作：具体执行了什么操作，参数是什么。
• 结果：外部返回了什么。
• 责任人配置：这一步是谁授权自动执行的，用的是哪套规则。

有了这五条，出事之后十分钟就能定位原因。没有这五条，事故复盘会变成猜谜，而下一次大概率还会犯同样的错。

留痕的成本很低，麻烦的是要坚持。建议从第一天就用统一的格式，不要等到出事再补。

手机号和账号是最容易被忽略的风险面

给智能体配手机号、配平台账号，看起来只是多了一个联系方式，实际上是把你的业务身份交出去了一部分。有几个点必须提前想清楚。

• 账号归属：用谁的实名信息注册，账号被封了怎么办，能不能找回。用个人号跑业务是常见做法，也是常见雷区。
• 行为边界：智能体在外部平台上代表的是你的品牌。它说错一句话，代价由你承担。涉及对外沟通的措辞，要有固定模板和禁用词表。
• 速率限制：智能体的操作频率远高于人，很容易触发平台的风控，导致账号被限制。给每类操作设频率上限，必要时加随机间隔。
• 可识别性：在允许的场景下主动说明是自动化助手，既是合规要求，也能降低后续纠纷的概率。

一套可以直接落地的风控清单

下面是一个最小可用的清单，上线前逐条打勾。

• 每一项自动化动作都标注了属于哪一档，第四档全部有人工审批环节。
• 单笔、单日、异常触发三层额度都已设置，且数值经过真实业务量测算，不是拍脑袋定的。
• 所有动作都有结构化日志，包含输入、判断、动作、结果、授权来源五项。
• 有一键暂停开关，且不是藏在代码里，而是运营同学也能操作。
• 有回滚预案：第三档和第四档的每一类动作，都写清楚了做错之后的具体补救步骤。
• 每周做一次日志抽查，不是为了追责，是为了在事故之前发现规则被绕过的迹象。
• 对外账号有频率上限和禁用词表，且已经跑过一轮压力测试。

这份清单不长，但能挡掉绝大多数已知的事故类型。真正危险的不是智能体做错了事，是做错了没人知道、知道了查不出来、查出来了没有止损手段。

人的角色要重新定义：从执行者变成审批者

智能体接进来之后，团队里最不适应的往往是一线执行的人。过去他们的工作是打电话、下单、核对，现在这些动作大多被自动完成了，剩下的工作是看审批队列、处理异常。这个转变如果不主动设计，会出现两个典型问题。

• 审批疲劳：确认队列里长期都是同一类明显没问题的操作，人就开始无脑点通过，审批变成了形式。解法是按风险分层，低风险的批量放行并抽样复核，只在真正需要判断的环节要人拍板。
• 能力空心化：所有执行都交给智能体之后，没人知道流程细节，一旦系统出问题没人能手工兜底。解法是保留定期的手工演练，让团队每季度完整走一遍非自动化的流程。

这两件事都不难，但需要在上线前就想清楚，而不是等团队开始抱怨了再补救。

推进节奏：先窄后宽，先慢后快

落地顺序建议这样安排。

• 前两周：只开放只读级和可撤销级，把留痕和一键暂停做扎实，先让团队熟悉智能体到底在做什么。
• 第三到四周：挑一类最标准化、最容易判断对错的外部可见动作开放，加人工确认，观察确认率和误报率。确认率长期超过九成，说明规则已经比较准了。
• 第二个月：对通过验证的动作逐步放开人工确认，同时把额度收得更紧。放权和收紧额度必须同时做，只放权不收紧等于裸奔。
• 持续：每月复盘一次日志，看有没有新的越界模式出现，把规则补上。

判断这件事做得好不好的唯一标准

不是自动化率有多高，而是出事之后多久能止损。一个设计良好的智能体系统，哪怕全自动跑，也应该能在十分钟内暂停、在半小时内定位原因、在一天内完成补救。达不到这个水平，自动化率越高越危险。

给智能体手机号和钱包是大势所趋，它确实能把人从重复确认里解放出来。但解放的前提是缰绳先系好，而不是先把马放出去再追。