当 AI agent 只会读写本地代码仓库时，执行环境几乎不是问题。但只要系统开始接浏览器自动化、企业内网服务、移动端验证或客户自有 VPC，执行环境就不再是“去哪跑都一样”的实现细节，而会直接决定安全边界、延迟、可用性和观测成本。
很多系统的问题不在“没有 runner”，而在所有任务默认进同一个 runner。结果就是：轻任务被重环境拖慢，高敏任务跑进不该去的地方，浏览器验证和代码执行互相污染，出了问题还很难说明“为什么这次任务会被放到这里执行”。
更稳的做法，是把 execution placement 设计成明确的路由决策。建议先结合 AI agent 模型路由与回退链设计、AI agent Orchestrator 与 Sandbox 解耦、AI agent Handoff Contract 设计 和 AI agent 多租户隔离与 Workspace 供给 一起看。
不是所有任务都该进同一个 runner
最常见的 4 类执行环境可以先这样分：
| 环境 | 适合什么 | 最主要的限制 |
|---|---|---|
| local workspace | 轻量文件编辑、静态分析、仓库读写 | 不适合访问客户私网 |
| remote VPC runner | 客户内部系统、受控私网资源 | provision 与观测成本更高 |
| browser runner | 真实网页操作、截图、端到端验证 | UI 波动大、耗时更高 |
| device runner | 真机交互、移动端兼容验证 | 资源稀缺、并发低 |
如果没有这层显式分类，系统最终会默认“有环境就能跑”，而不是“这个任务该去哪跑”。
路由决策最好结构化，不要靠 prompt 猜环境
执行环境路由最怕的，是让模型根据自然语言自己猜。例如“需要登录后台并验证页面展示”到底该去 local shell 还是 browser runner？如果只靠 prompt，系统每一轮都可能做出不同选择。
更稳的方式是先生成 execution envelope：
{
"taskType": "ui_verification",
"dataSensitivity": "medium",
"networkRequirement": "public_web",
"interactionMode": ["browser", "screenshot"],
"latencyTier": "standard"
}
然后由 orchestrator 根据明确规则路由到 runner，而不是让模型直接写“我觉得应该打开浏览器试一下”。
失败案例：把浏览器验证任务丢进本地 shell，结果看似成功，实际根本没验证用户路径
某个网页发布 agent 在发布后需要验证“从首页进入产品页再提交表单”的完整路径。系统没有 browser runner 路由，只是让 agent 在本地 shell 里检查静态 HTML 和接口返回，于是任务被标记为成功。
上线第二天，团队才发现真实页面里的前端埋点脚本冲突导致按钮失效。根因非常直接：系统验证的是文件和接口，不是真实用户路径。
这类事故说明，runner routing 不是性能优化问题，而是验证对象是否正确的问题。选错环境，系统可能不是变慢，而是验证了错误的东西。
路由时要把“能做什么”和“做这件事值不值得”分开
一个环境可用，不代表当前任务就应该去那里。更稳的判断通常同时看 4 个变量：
- 是否必须触达某类资源
- 是否需要某种交互能力
- 这类环境的 provision 成本和值不值得付
- 如果环境失败，系统能否安全降级
例如：
- 只做 repo 内文本修复，优先 local workspace
- 需要访问客户私网 API，必须 remote VPC
- 需要真实页面交互和截图，必须 browser runner
- 只是低价值 smoke test，不一定值得排队真机
Multi-environment Routing Checklist
- local workspace、remote VPC、browser、device 是否是明确的 runner 类型
- 执行环境是否由结构化 envelope 决定，而不是由 prompt 临时猜测
- 是否区分“能力上可行”和“系统上值得”两个维度
- 高敏数据是否不会误入低隔离环境
- 环境失败后是否有降级或重路由策略
- 观测系统是否记录了本次任务为什么选择这个 runner
该留下的判断
多执行环境路由的核心，不是把更多 runner 接进来，而是让系统明确：每一种执行环境都代表一种成本、风险和验证边界。环境选错了，agent 不一定报错，但很可能在错误的地方做了正确的事，最后依然把结果做错。
延伸阅读：
