Runtime：让整个团队安全使用 Coding Agent 的沙箱平台
YC P26 批次的 Runtime 在 HN 上获得 100 分——一个让工程、产品、市场等所有角色都能安全使用 coding agent 的团队基础设施。
核心问题：Coding Agent 个人用很好，推广到团队就崩了。
团队用 Agent 的三大痛点
1. 环境配置散落在个人脑中
你的 Claude Code 配置了完美的 CLAUDE.md、MCP 服务器、系统指令。但新同事怎么复用？产品经理想跑个简单任务怎么办？
2. 安全风险无法控制
Agent 能访问代码库、执行命令、调用 API。非工程人员使用时：
- 密钥泄露：Agent 把 .env 内容打印到日志
- 误部署：Agent 执行了 git push --force
- 数据泄露：Agent 读取了敏感文件并发送到外部
3. 成本不可追踪
10 个人各自跑 Agent，月底收到一张天价账单，不知道钱花在哪、效果如何。
Runtime 怎么解决
沙箱快照
工程师一次性定义环境：系统指令、skills、CLI 工具、Docker Compose 多服务。Runtime 将完整运行态快照，后续每个 session 毫秒级启动。
效果：产品经理打开 Slack 输入需求，Runtime 在已配好的沙箱中启动 Agent 执行，无需任何环境配置。
沙箱编排层
不绑定单一沙箱供应商，可调度： - E2B（轻量级） - Daytona（开发环境） - EC2（算力密集） - 自托管 K8s（合规需求）
安全层
- 密钥代理注入：密钥通过托管代理传入沙箱，永不直接暴露给 Agent
- 命令白/黑名单：限制 Agent 能执行哪些命令
- 网络出口控制：限制 Agent 能访问哪些外部服务
- RBAC：按人和 Agent 分级权限
协作
- 每个 session 生成分享预览 URL
- 实时协作、session 接力
- 非工程师发起 PR 后，工程师可回到同一沙箱修改
可观测性
全局 dashboard：所有 session 的工具调用、思维链、文件变更、每人/每 Agent 成本。
与 E2B / Daytona 的区别
| 维度 | Runtime | E2B / Daytona |
|---|---|---|
| 定位 | 团队 Agent 运行平台 | 底层沙箱 SDK |
| 沙箱 | 编排层（调度多种沙箱） | 自身即沙箱 |
| 协作 | 多人实时 + Slack/Linear 触发 | 无 |
| 治理 | 花费上限、审批门、审计日志 | 无 |
| Agent 兼容 | Claude Code/Codex/Copilot/Gemini CLI/Devin | 通用 |
简单说：E2B 是发动机，Runtime 是整车。
定价
| 层级 | 价格 | 关键能力 |
|---|---|---|
| Free | $0 | 500 credits，1 session |
| Builder | $29/月 | 10 并行 session，BYOK |
| Teams | $99/seat/月 | 无限 session，RBAC，花费控制 |
| Enterprise | 自定义 | 自托管，SSO/SCIM，审计日志 |
与 Context Engineering 的关系
Runtime 的核心设计——将系统指令、skills、环境上下文一次性定义并快照——本质上是 Context Engineering 在团队级的工程化实践。
Context Engineering 的核心思想：Agent 的性能不取决于模型大小，而取决于你给它的上下文质量。Runtime 把这个概念从"个人 prompt 技巧"提升为"可复用、可共享、可审计的团队基础设施"。
对谁有价值
- 10+ 人的工程团队：需要统一 Agent 配置和安全治理
- 有非工程角色参与开发的组织：PM、设计师、客服想用 Agent 修改代码/配置
- 合规要求高的企业：金融、医疗等需要审计日志和密钥隔离的场景
- 多 Agent 探索期的团队：想同时评估 Claude Code、Codex、Copilot，不想为每个配一套环境
总结
Coding Agent 从"个人工具"到"团队基础设施"的跨越，需要的不是更好的模型，而是更好的运行时环境。Runtime 瞄准的正是这个空白——让 Agent 在组织中安全、可控、可追踪地规模化运行。