Cloudflare 这个小功能，让我看懂了 Agent 产品的新范式
我的 Agent 越来越能干了。给我写代码、部署服务、写文章、搜资料——很多以前需要人来做的事，现在Agent能自己干。
但有一个问题会一直卡我，让我觉得用的不够流畅：权限。
目前主流方案
目前主流的授权方式，基本都是”先授权，再使用”：
方式一：用户手动点击授权。 弹个窗口，用户点”同意”，Agent获得权限。这是OAuth的标准流程。
方式二：给一个API Token。 用户生成一个Token，复制给Agent，Agent拿着Token去调接口。简单粗暴，但Token泄露了就完蛋。
方式三：后台管理页面配置。 比如钉钉的机器人权限管理，用户可以在后台精确配置机器人能做什么、不能做什么，每个功能单独审批。
这三种方式有个共同点：都是前置授权。
用户必须在Agent干活之前，就把权限给出去。而且这个权限要么是全给（Token），要么是逐个点确认（OAuth/后台审批）。
前置授权的问题在于：
- 用户需要提前知道Agent要做什么。 但很多时候Agent的任务是动态的，用户自己都不知道它下一步要调什么接口。
- 授权粒度难把控。 给多了不安全，给少了Agent跑不动。
- 试错成本高。 Agent想试个新功能，用户得先去授权一次。试完发现不行，还得撤回授权。
这些在Agent能力有限的时候不是大问题。但现在Agent越来越能干，需要调用的服务越来越多，前置授权就成了瓶颈。
新的授权方案：先用再说
Cloudflare扔出了一个新思路：临时账号，我了解完之后眼前一亮，有点佩服想出这个点子的产品经理。
Cloudflare现在可以给 Agent直接分配一个临时账号和API Token，不需要提前注册、不需要提前授权、不需要任何人工干预。
这个临时账号存活60分钟。在这60分钟里，Agent可以反复修改、部署、验证。60分钟到了，账号自动销毁。
关键来了： 如果用户觉得这个项目不错，可以在到期前点一个claim链接，把临时账号变成自己的正式账号。
注意这个流程的顺序：
旧流程： 用户授权 → Agent使用 → 用户可能忘记撤回权限
新流程： Agent先用 → 用户看到结果 → 用户决定要不要认领
这是一个典型的基于 AI 的流程重构！！这套流程在我看来有一种美感。
标准的 基于 AI 的范式转移
表面上看，这只是”先用后付”和”先付后用”的区别。
但往深了想，这改变了Agent和我之间的关系。
在旧方案里，我是审批者——Agent每做一个动作，我都得先点头。但现在我的 Hermes 越来越能干，一天可能跑几十个任务的时候，我就审不过来了，我不可能一天都坐在电脑前面，不停地点确定键，所以我只能开“完全访问”模式。
新方案的思路是：把审批变成验收。
我不需要提前知道你要做什么。你先干，干完了给我看结果。我觉得行，就认领；觉得不行，就放着不管等自动销毁。
这确实跟人类社会的很多机制是类似的：
试用期：先干活，合适了再转正
临时工签：先工作，满意了再给正式身份
样品：先试用，好用了再买
安全怎么保证？
你可能会问：Agent拿着临时账号乱搞怎么办？
几个机制：
- 时间限制。 临时账号只有60分钟寿命，到期自动销毁。Agent不可能长期占用资源。
- 权限隔离。 临时账号只能操作有限的资源，不能访问用户的全部数据。
- 可认领机制。 用户看到结果后决定要不要认领。不认领，一切归零。
- 自动清理。 不认领的临时账号，所有数据和资源自动删除。
这比直接给Token安全一些。因为Token一旦泄露，攻击者可以无限期使用，直到你发现异常。而临时账号泄露了，60分钟后就失效了。
对我的启发
Cloudflare这个做法，给我指了一个方向：Agent时代的身份系统，需要重新设计。
传统身份系统是给人设计的：邮箱、密码、手机验证码、MFA。这些对Agent来说都是障碍。
Agent需要的是：
- 临时身份： 用完即销毁，不留后患
- 可验证： 用户能看到Agent做了什么，再决定要不要认领
- 低摩擦： 不需要浏览器、不需要复制粘贴Token、不需要人工干预
- 可撤销： 不认领就自动清理，不需要用户手动去后台删除
这套思路如果被更多服务采纳，Agent的能力可能会再上一个台阶。
说句实话
Cloudflare这个功能，技术上不复杂。临时账号、60分钟过期、claim链接——都不是什么高深的技术。
但这个思路很有意思：它不是在旧框架里打补丁，而是重新想了Agent应该怎么跟服务交互这个问题。
我们做Agent相关的产品，经常陷入一个思维定势：把现有的流程优化一下，让Agent能用就行了。
但有时候，正确的做法是重新想一遍：如果Agent是第一公民，这个流程应该长什么样？
Cloudflare给了一个答案。可能不是唯一的答案，但至少是一条新路。
