当云平台开始把 Agent 当成用户

云平台一直把人当用户。控制台里有表单、图表和确认框，部署失败时亮一条红色提示，等工程师点进去处理。

Agent 不看这些界面。它拿到一个任务，修改代码，运行命令，读日志，再决定下一步。Railway 把这种变化叫作 Agent-native cloud：云平台面对的不再只是写代码的人，也包括会连续操作软件的模型。

路足够清楚，来的人不必先学会看地图。

Agent 讨厌控制台里的暗门

人可以在文档和控制台之间来回找。Agent 更依赖一条连续、可读的路径：执行一个命令，得到结构化结果，失败原因能直接进入下一轮判断。

一项部署如果必须先打开网页创建项目，再从另一个页面复制 ID，最后去设置页勾选权限，对人只是麻烦，对 Agent 是三次上下文切换和一串脆弱的界面操作。

Agent-native 不是给控制台加一个聊天框，而是把部署动作变成稳定的接口：

• 输入和输出明确，失败时返回真实错误；
• 环境可以快速创建、销毁和恢复；
• 日志、资源状态和部署结果能被机器读取；
• 每一步都有边界，不靠操作者“应该知道”。

这套要求听起来像普通的平台工程，只是 Agent 把那些过去能靠经验绕过的毛边全照了出来。

每个任务都需要一间临时工作室

背景 Agent 不该直接在长期运行的生产环境里试错。更合适的做法是给每个任务一间临时工作室：独立文件系统、限定算力、短期凭证，以及可以随时丢弃的预览部署。

任务开始时从快照恢复，完成后留下代码、日志和验证结果，环境本身销毁。一个 Agent 把依赖装乱了，不会拖累另一项任务；一枚凭证过期，也不会变成遗留在某台机器里的钥匙。

这里的关键不是“上云”，而是让计算环境跟任务拥有相同的生命周期。 人离开工位时不会拆掉电脑，Agent 的工位却应该用完就拆。

自动化越多，权限越要短

Railway 访谈里提到的未来，是同时运行成百上千个 Agent。数量一上去，过去给工程师账户配置的长期权限会迅速失控。

Agent 需要的是刚好完成当前任务的权限：能推送当前分支，不能覆盖主分支；能访问预览数据库，不能碰生产数据；能读某个服务的日志，不能顺手浏览整个组织的密钥。

权限之外还要有可追溯性。谁创建了环境、执行过哪些命令、使用了什么凭证、在哪一步退出，都要能从一条时间线上还原。否则并行 Agent 带来的不是吞吐量，而是一座同时响起很多警报的控制室。

这个站点的部署很小，却有同样的边界：构建、预览、发布是三件不同的事。Agent 可以自由修改和本地构建；真正发布到外部，需要明确的凭证和授权。规模不同，门锁的逻辑没有变。

原始材料：Railway: The Agent-Native Cloud。

一朵为 Agent 准备的云，首先要让每次动作都能被读懂、限制和收回。