Runtime

产品简介

Runtime 想做的是这样一层系统: 当编码代理不再只是某个工程师的个人玩具后，公司迟早要自己补上的那层运行基础。它把预热沙箱、skills、系统集成、策略控制、可观测性和团队界面放在一起，让代理能在公司上下文中运行，但又不至于失控或不可见。

为什么最近热度高

它最近热起来，是因为它抓住了本地试过 Claude Code 或 Codex 之后的下一道门槛: 不是能不能生成，而是怎么规模化 rollout、怎么治理。Product Hunt 和 YC 身份是放大器，更大的信号是它把 agent 基础设施定义成“公司能力”，而不是某个高手的私有工作流。

核心功能

• 可预配置沙箱环境，提前装好 CLI、MCP、密钥、skills 和护栏，让会话启动更快。
• 支持从 Slack、Linear、GitHub、Jira 等系统触发代理，并把结果返回成 PR、消息、报告或草稿。
• 提供审计日志、花费上限、allowlist、审批门和可选自托管，便于平台团队在规模化使用时治理风险。

真实使用场景

• 做一个值班排障代理，接到告警后自动查仓库、定位问题并先给出修复 PR。
• 让市场、支持、财务或产品团队拥有各自的代理，并直接在现有系统里工作。
• 把多种编码代理在多个仓库里的运行方式标准化，而不是让每个工程师自己拼一套一次性流程。

社区反馈

公开讨论里，最吸引人的点是“每个职能都能有受约束的代理”，而不是所有事情都继续排队等工程师。最关键的问题则集中在策略边界: 沙箱究竟保护什么、数据路径控制怎么做、以及哪些安全问题仍然没有解决，例如发布讨论里明确提到并不覆盖 payload 级 DLP。

限制与风险

Runtime 的强大恰恰来自它覆盖面很广，这也意味着配置和内部 owner 很重要。团队仍要认真设计权限边界、判断哪些系统适合接入，并理解“有集成级治理”并不等于“数据安全和业务正确性已经被完全解决”。

替代方案

替代方案包括 Handler、Replicas、SuperHQ、自建编排层、长驻 devbox，或基于 GitHub Actions、Slack 机器人和内部平台能力搭的更窄流程。

常见问题

• Runtime 更适合谁？ 适合希望在工程及相邻职能之间共享、治理代理基础设施，而不是每个人各玩一套的公司。
• 试点最先要证明什么？ 要证明一两个高价值代理能以清晰可审计的方式运行，并且比现有人工协作流程更省协调成本。