1.5万内部应用一夜打通：Cloudflare让AI代理学会"自己敲门"

Cloudflare内部有数千个应用。从全员使用的核心业务系统，到工程师的业余项目，全部藏在Access防护墙后。这个设计对人很友好——扫码、登录、进系统。但AI代理来了之后，集体撞墙：它们只会看到重定向到登录页的指令，然后卡住。

这家公司今天放出的新功能，用一次点击解决了这个矛盾。不是修修补补，而是把OAuth 2.0做成了基础设施层。更值得玩味的是，他们去年12月才给自家代理写的临时补丁，现在直接退役了——因为通用方案已经跑通。

从"人过门"到"代理过门"：同一套墙，两套钥匙

Cloudflare Access的工作逻辑很直白：应用前面架一道网关，未认证用户统一送到登录页，选身份提供商、验身份、发令牌（JWT）。这套流程服务了几年，直到生成式AI的工具链开始深入企业内部。

问题出在交互范式。人类看到登录页会主动操作，代理看到HTTP 302重定向只能报错。Cloudflare的工程师最初给OpenCode的网页抓取工具打补丁：遇到特定域名就触发cloudflared CLI，走一遍授权流拿JWT，再拼到请求头里。

这个方案只活了不到半年。2025年4月，托管OAuth（Managed OAuth）进入公开测试，核心变化是把Access本身变成授权服务器。

开启方式极简：管理员在Access应用设置里点一次按钮。之后，未授权代理收到的不再是重定向，而是标准的WWW-Authenticate响应头，指向/.well-known/oauth-authorization-server端点。代理按图索骥，完成三步：动态客户端注册（RFC 7591）、PKCE授权码流程（RFC 7636）、用户授权后拿令牌。

同一个应用，人类走登录页，代理走OAuth流，底层令牌格式完全一致。Cloudflare的免费 tier 直接覆盖这个功能，没有额外收费层。

为什么偏偏是OAuth 2.0？MCP的"基础设施下沉"

这个授权流程看起来眼熟，是因为它直接复用了模型上下文协议（MCP）的认证层。Cloudflare去年推出的MCP服务器门户（MCP Server Portals）已经跑通了这套机制——代理发现服务、动态注册、用户授权、令牌代持。

现在他们把同一套能力从MCP场景泛化到所有Access保护的应用。这不是功能叠加，是架构层的收敛：企业不需要为AI代理单独建一套身份体系，现有的Access策略直接兼容。

更隐蔽的伏笔是Organizations功能。测试版已支持跨Cloudflare账户桥接身份提供商，这意味着集团架构下的多租户场景、并购后的系统整合，代理都能以统一身份穿行。身份层的碎片化，正在被协议层的标准化吃掉。

临时方案退役背后的产品哲学

Cloudflare自己吃狗粮的速度值得注意。从发现代理卡墙，到内部补丁上线，再到通用方案取代补丁，整个周期压缩在半年内。这种"先自救再普适"的路径，和某些公司先画PPT再招客户的打法形成对照。

临时方案的设计也透露技术判断：他们没选API Key或长期令牌，而是坚持短期JWT+用户授权。这牺牲了"一键永久开通"的便利性，但守住了安全底线——代理的权限边界始终绑定具体用户，而非变成系统级后门。

托管OAuth的完整流程现在标准化为：代理发现授权端点→动态注册→引导用户授权→获取带作用域的令牌→代表用户发起请求。每一步都有RFC背书，意味着这不是Cloudflare的私有协议，而是任何兼容OAuth 2.0的代理都能对接的开放接口。

代理经济的身份层正在硬化

这个更新的真正冲击在生态位。当代理需要访问企业系统时，身份验证一直是摩擦最高的环节。要么给代理开超级账号（安全风险），要么让每个应用单独对接（集成成本），要么让人类全程陪同（丧失自动化价值）。

Cloudflare的选择是把身份层做成网络基础设施——就像SSL/TLS把加密做成默认层一样。Access的托管OAuth不解决"代理能做什么"的业务逻辑问题，但消灭"代理怎么证明它是谁"的通用障碍。

这对AI Agent的落地节奏有直接影响。Gartner预测到2028年15%的日常工作决策将由代理自主完成，但身份和权限一直是企业POC阶段的最大卡点。一个点击即用的OAuth层，可能把"能不能跑通"的验证周期从周级压缩到小时级。

更长期的变量是协议竞争。MCP、A2A（Agent-to-Agent）、ANP（Agent Network Protocol）都在争夺代理互操作的标准定义权。Cloudflare这次把MCP的认证机制泛化为基础设施能力，相当于用工程实现给协议路线投票。其他云厂商跟不跟、怎么跟，会是2025年下半年值得盯的指标。

开放提问

当企业应用的准入门槛从"人类登录"变成"代理协商"，身份管理的边界正在从"人"滑向"行为"。Cloudflare用OAuth 2.0打了个样，但真正的考验还没到来：当代理开始跨组织、跨云、跨协议地调用服务，谁来定义那张全局信任图谱？以及，当代理的权限可以像代码一样被版本控制和自动分发，合规审计的颗粒度要细化到什么程度——是按用户、按代理实例、还是按每一次工具调用？