Building Cloud Agent Infrastructure 核心总结
一句话总结
云端 Agent 不是“把桌面 Agent 放到服务器上跑”，而是需要重新设计运行时、状态持久化、密钥管理、触发管线和安全边界。
核心问题
桌面 Agent 默认拥有很多隐含条件：
- 一个用户
- 一台机器
- 一个本地进程
- 本地文件系统
- 环境变量里的 API key
- 用户手动重试
- 相对可信的执行边界
云端 Agent 没有这些条件。它运行在临时 sandbox、共享硬件、无人值守触发环境中，代码可能由 LLM 生成并带有攻击性。因此，持久化、身份、网络信任、重试和密钥管理都必须显式设计。
经验 1：分离慢变状态和快变代码
用户环境和平台 runner 的变化频率不同：
- 用户环境：包、文件、脚本、配置，变化慢，由用户控制
- 平台 runner：执行 harness、调度逻辑、平台代码，变化快，由平台控制
正确做法：
- 将用户环境冻结成 sandbox snapshot
- 每次运行从同一个 snapshot 启动，保证复现性
- 平台 runner 不和用户环境强绑定
- runner 更新时只热替换 runner，不丢弃用户 snapshot
- 成功运行后再把新 runner 写回 snapshot
关键原则：
持久化的 artifact 要按“谁控制变化节奏”来切分边界。
经验 2：密钥不能进入执行边界
云端 Agent 的安全假设应该是：
sandbox 内部代码已经不可信。
因此：
- 长期凭证不能放进 sandbox
- 不能依赖环境变量保存 API key
- Agent 访问 GitHub、Slack、用户 API 时，不直接拿 token
- 请求应通过 sandbox 外部的 API bridge 转发
- API bridge 在宿主侧附加真实 OAuth token
安全校验包括：
- 内部 IP allowlist
- 每次运行签发的短期 JWT
- JWT 绑定 user、app、session、run
- token 只在本次运行窗口内有效
这样即使 prompt injection 让 Agent 泄露环境变量，攻击者也拿不到长期凭证。
统一执行管线
文章强调所有触发方式都应该走同一个执行入口：
- 用户点击 Run
- 定时任务
- HTTP API 调用
- 另一个 Agent 触发
这些都应进入同一个 executeAgent 管线。
好处：
- 计费统一
- 日志统一
- 指标统一
- 权限模型统一
- 新增触发方式只是路由变化，不是架构重写
文章的架构抽象
云端 Agent 可以理解为：
一个带自然语言接口的函数。
其中：
- Agent 的实现属于用户
- 运行时属于平台
- 触发面属于平台
- 安全边界属于平台
- 状态和代码应该按所有权分层演进
对工程实践的启发
构建云端 Agent 平台时，需要重点设计：
- sandbox snapshot 机制
- runner 热更新机制
- 用户状态与平台代码解耦
- host-side secret bridge
- 短期凭证与调用授权
- 统一执行入口
- 失败重试与半升级状态处理
- 日志、计费、指标的一致性
需要注意的风险
文章方案仍有一些工程风险需要补强：
chattr +i不是强安全边界- IP allowlist 不能防内部横向移动
- runner 热替换需要兼容性协议
- snapshot 冻结也会冻结漏洞
- API bridge 返回的数据同样需要脱敏和访问控制
- prompt injection 防护不能只依赖“密钥不进 sandbox”
最核心的设计原则
- 用户状态要可复现、可冻结。
- 平台代码要可独立升级。
- 长期密钥不能进入 sandbox。
- 所有触发方式走统一执行管线。
- 边界按照所有权、变化频率和信任级别来划分。