Cloudflare 给 Agent 开“临时账号”，真正重要的不是账号，而是 AI 工作流入口

Cloudflare 最近这个动作，表面看是：给 AI Agent 一个临时账号，让它能去完成某些任务。

但真正值得盯的地方，不是“临时账号”这四个字。

重点在后面：Agent 时代，很多产品的入口都得重新设计。

现在很多系统已经有 API，有权限，有自动化能力。看起来很先进。

可一旦真的让 AI Agent 去跑完整流程，你会发现它经常卡在一些很离谱的地方：

• 要登录后台
• 要点确认按钮
• 要扫二维码
• 要过人机验证
• 要复制一段 Token
• 要等邮箱验证码
• 要人工审批一个弹窗

代码它会写。配置它也能改。

结果卡在“请点击下一步”。

这事儿就很荒诞。🤦

一句话说透：Agent 缺的不是能力，是“机器能走的入口”

过去的软件，大多默认使用者是人。

所以产品设计会围绕人来做：

• 页面给人看
• 按钮给人点
• 表单给人填
• 登录态给浏览器保存
• 权限给员工账号绑定
• 审批给管理员手动确认

这套逻辑在人类时代没问题。

可 Agent 来了以后，问题就暴露了。

Agent 不是坐在电脑前的员工。它没有眼睛盯着 UI，也不适合在弹窗里“确认一下”。

它更需要的是：

• 清晰的任务入口
• 可控的临时权限
• 可追踪的操作日志
• 自动过期的身份
• 明确的失败反馈
• 能被程序调用的接口

Cloudflare 这次被关注，正是因为它把这个问题摆到了台面上。

不是让 Agent 冒充人类去操作系统，而是给 Agent 一个更适合它的工作通道。

用一个场景理解：AI 会写代码，却不会“取停车票”

你可以把 Agent 想成一辆已经能自动驾驶的车。

它能上路，会变道，会避让，还能自己规划路线。

结果到了停车场门口，麻烦来了：

• 要摇下车窗
• 要伸手取卡
• 要扫码付款
• 要按一下确认
• 要跟保安说一句“我是临停”

车不是不会开。

是停车场入口压根不是给自动驾驶车设计的。

今天很多开发流程也这样。

比如你让 Agent 修一个线上 Bug：

1. 它能读日志
2. 它能定位问题
3. 它能改代码
4. 它能写测试
5. 它能提交 PR

然后它准备部署。

卡住了。

因为部署平台要求它：

• 登录某个控制台
• 输入双因素验证码
• 选择项目
• 点击发布
• 勾选“我确认本次发布无风险”
• 等管理员审核

你看，真正拖后腿的不是模型智商。

是入口还停留在“人坐在屏幕前操作”的时代。

Cloudflare 这类设计，解决的是哪类痛点？

给 Agent 临时身份，本质上是在解决三个问题。

1. 不想给 Agent 永久权限

很多团队一听“让 AI 操作线上环境”，汗毛都竖起来了。

这很正常。

没人愿意把管理员账号、长期 API Key、数据库密码一股脑塞给 Agent。

这不是自动化，这是把家门钥匙挂小区门口。

更合理的方式是：

• 只给它当前任务需要的权限
• 权限只在短时间内有效
• 任务结束自动失效
• 所有操作都能回溯

比如：

允许这个 Agent 在 30 分钟内读取某个 Worker 的日志，并部署一次指定分支。不能改账单，不能删项目，不能访问其他服务。

这才像正常的 Agent 权限设计。

2. 不想让 Agent 伪装成人

很多自动化方案很粗暴：让机器人打开网页，模拟点击，填表，复制验证码。

能跑吗？能。

稳吗？一言难尽。

页面一改版，按钮换个位置，流程多一个确认框，自动化直接趴窝。

Agent 时代更靠谱的方式，是给它专用入口。

不是“你装成人来点按钮”。

而是“你用机器身份来完成机器任务”。

这两者差别很大。

3. 不想让人卡在每个小节点上

很多团队用 AI 工具后，嘴上说自动化，实际还是“半自动”。

Agent 写完代码，人来复制命令。

Agent 生成配置，人来登录后台。

Agent 判断要部署，人来点按钮。

Agent 发现错误，人来开权限。

这不叫智能工作流。

这叫 AI 在前面跑，人类在后面擦屁股。

临时身份、可控权限、机器入口这些东西成熟以后，Agent 才能真正把一段任务跑完。

做 AI Agent 产品时，入口设计要换脑子

如果你正在做 AI 工具、内部平台、DevOps 系统、SaaS 产品，这里有个很实用的判断标准：

你的系统，是只允许“人操作”，还是也允许“Agent 合法工作”？

别急着说自己有 API。

有 API 不等于适合 Agent。

Agent 需要的是一套完整工作条件。

你可以照着这张清单检查

任务入口

Agent 能不能通过明确指令发起任务？

比如：

部署项目 web-demo 的 preview 分支到 staging 环境。
部署成功后返回访问地址和构建日志摘要。

如果它必须打开 5 个页面、点 8 个按钮，这入口就不够友好。

权限边界

Agent 拿到的权限是否足够小？

好的权限应该像这样：

{
  "agent_id": "deploy-agent-001",
  "scope": [
    "read:logs:web-demo",
    "deploy:staging:web-demo"
  ],
  "expires_in": "30m",
  "max_actions": 3
}

不要上来就给：

admin 全权限，永久有效。

这玩意儿不是方便，是埋雷。

过程反馈

Agent 失败时，系统能不能告诉它为什么失败？

别只返回：

操作失败。

这对 Agent 没用，对人也没用。

更好的反馈是：

{
  "status": "failed",
  "reason": "missing_permission",
  "required_scope": "deploy:staging:web-demo",
  "suggestion": "request_temporary_permission"
}

Agent 才能继续下一步：申请权限、换路径、提醒人类处理。

审计日志

Agent 做过什么，必须能查。

建议记录：

• 哪个 Agent 操作的
• 谁授权的
• 什么时间操作的
• 操作了哪个资源
• 输入是什么
• 输出是什么
• 是否成功
• 权限什么时候过期

别等线上炸了，才发现日志里只写着“system updated”。

这跟没写差不多。

一个可落地的 Agent 工作流模板

咱们拿“AI 自动修复并部署一个小 Bug”举例。

一个更合理的流程可以这样设计。

场景：线上页面报错，需要 Agent 修复

用户反馈：订单页面打开报错。

Agent 的任务是：定位问题、提交修复、部署到测试环境。

推荐流程

1. 人类发起任务：修复订单页面报错
2. 系统创建 Agent 临时身份
3. 授权范围：读取日志、读取仓库、创建分支、提交 PR、部署 staging
4. Agent 读取错误日志
5. Agent 修改代码并补测试
6. Agent 提交 PR
7. CI 自动运行
8. Agent 根据 CI 结果修正问题
9. Agent 部署到 staging
10. 系统生成报告，人类确认是否上线 production
11. 临时身份过期

注意这里的边界。

Agent 可以部署测试环境。

生产环境上线仍然需要人确认。

这不是保守，是清醒。

让 Agent 承担重复、明确、可回滚的任务。把高风险决策留给人。

这套分工很舒服。

普通开发者现在能做什么？

你不一定要等大厂把全套基础设施搭好。

现在就能改自己的工作流。

给 Agent 单独建账号

别把自己的主账号丢给 AI 工具。

可以给它单独准备：

• GitHub bot 账号
• 独立 API Token
• 只读日志权限
• 单独的测试环境部署权限
• 有效期较短的访问密钥

权限能小就小。

Agent 越聪明，越不能随便给全权限。

把“点按钮流程”改成命令或 API

如果你每天都在重复做一件事，比如部署、清缓存、拉日志、生成报告。

尽量把它变成：

npm run deploy:staging

或者：

curl -X POST https://api.example.com/deploy \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"env":"staging","branch":"fix-order-page"}'

Agent 最喜欢这种明确入口。

别让它去猜网页按钮在哪。

给每个自动化任务加“刹车”

Agent 工作流里一定要有刹车点。

比如：

• 删除数据前必须人工确认
• 生产部署前必须人工确认
• 涉及账单变更必须人工确认
• 权限申请超过范围必须人工确认
• 连续失败 3 次自动停止

自动化不是一路狂奔。

能停下来，才敢放心跑。

避坑清单：别把 Agent 入口做成新灾难

坑 1：直接给管理员权限

为了省事给 admin，短期很爽，长期很慌。

正确做法：按任务授权，过期回收。

坑 2：只做网页自动化

模拟点击适合临时救急，不适合长期工作流。

正确做法：提供 API、CLI、Webhook、事件回调。

坑 3：没有日志

Agent 操作不可追踪，出了问题根本查不清。

正确做法：每个动作都记录身份、资源、时间、结果。

坑 4：错误信息太含糊

“失败了”这种提示，只会让 Agent 原地转圈。

正确做法：返回明确原因和下一步建议。

坑 5：所有决策都交给 Agent

别一上来就让 Agent 改生产库、改账单、删资源。

正确做法：低风险自动，高风险确认。

真正的变化：软件入口要从“人类优先”变成“人机协作”

Cloudflare 这类动作会越来越多。

因为 Agent 真要干活，不能永远挤在人类入口里。

未来好用的系统，大概率会同时准备两套入口：

• 给人的界面：看得懂、点得顺、能审批
• 给 Agent 的入口：权限清楚、调用稳定、反馈明确、自动过期

谁先把这些东西做好，谁就更容易接住下一波 AI 工作流。

别只盯着模型会不会写代码。

更关键的问题是：

当 AI 写完代码、想调试、想部署、想查日志、想修复线上问题时，你的系统愿不愿意给它一扇能走的门？

这扇门，才是 Agent 真正开始干活的地方。