本文内容
Ramp Inspect 架构 2026：后台编码 Agent 如何安全扩展
Ramp Inspect 真正有意思的地方，是它把 Coding Agent 当作一种执行负载，而不是更聪明的代码补全。 每个后台 Session 都拥有独立的开发环境、应用服务、浏览器、日志与工具。Agent 可以修改代码、启动产品、运行测试、检查 Telemetry、验证 UI，然后创建 Pull Request。
这套架构比采用率数字更值得研究。Ramp 是 Fintech 公司，因此一个能触碰代码和内部系统的后台 Agent，不能只按写了多少代码来衡量。真正的问题是：怎样给 Agent 接近本地开发环境的完整上下文，同时让执行保持隔离、可复现、可审查？
Ramp 最初的 Inspect 工程文章描述了一个能够用 Ramp 工程师工具验证自身工作的内部后台 Agent。2026 年 1 月，Ramp 报告约 30% 的 Frontend 与 Backend Merge PR 由 Inspect 发起。Ramp Inspect 不是 Wavect 产品，本页是架构分析。
后台 Coding Agent 与本地 Coding Assistant 有什么不同？
本地 Coding Assistant 会继承工程师已经准备好的开发环境。后台 Agent 没有这个优势。如果每个 Session 都要重新 Clone Repo、安装依赖、Build 服务、初始化数据库并找到 Credentials，异步执行很快会比打开本地终端更慢。
因此问题分成两层：
- Agent Harness：模型、Prompt、Tools、Policy、Context、Retry 与验证逻辑。
- Execution Environment：Filesystem、Services、Browser、Network、Credentials、Processes 与 Compute。
我们的 Agent Harness Engineering 指南负责第一层。本页专注第二层。
核心模式：一个 Session 对应一个隔离 Sandbox
Modal 的 Ramp Inspect 架构案例描述了每个 Session 独立运行在 Modal Sandbox 中，并包含完整开发栈：Postgres、Redis、Temporal、RabbitMQ、Ramp 内部服务、OpenCode、VS Code Server、Web Terminal、VNC 与 Chromium，同时连接 GitHub、Buildkite 和 Observability。
一个 Agent Session = 一个可丢弃 Execution Environment
每个 Task 都拥有自己的 Process、Filesystem 与 Service State。多个 Agent 不需要争抢同一台工程师笔记本或同一个可变 Dev Environment。
为什么 Filesystem Snapshot 是关键？
隔离本身不能解决启动时间。Ramp 把昂贵 Setup 提前做。Modal 的案例显示，一个周期任务大约每 30 分钟刷新 Repository、安装依赖、执行 Initial Build，并保存 Filesystem Snapshot。新 Session 从最近的准备状态恢复，然后只同步剩余的 Repo Drift。
当前 Modal Sandbox API 提供 Filesystem Snapshot 能力，可从运行中的 Sandbox 生成可复用 Image。通用模式是：
- 在 Prompt 到来前构建 Known-good 开发环境。
- 持久化昂贵的 Filesystem State。
- 每个 Session 恢复一个新的隔离副本。
- 恢复后同步最新 Repo Drift。
- 任务完成后丢弃 Session。
这样 Cold Start 变成后台维护问题，而 Snapshot Freshness 变成明确的工程参数。
Sandbox 里应该有什么？
- 目标 Repository 与 Dependencies；
- Database、Queue 与本地 Services；
- Coding Agent Runtime 与 Shell Tools；
- 用于视觉验证的 Browser 或 Desktop；
- Tests、Linter、Type Checker 与 Build Tools；
- 受控访问 Logs、Feature Flags 与 CI；
- 生成可 Review Git Diff 或 Pull Request 的明确路径。
目标是 Environment Fidelity。如果 Agent 只能写出看起来合理的 Patch，却无法运行产品，它仍然在猜 Integration Behavior。
什么应该留在 Sandbox 外？
Ramp 的设计把 Execution 与 Coordination 分开。Prompt Routing、Session Lock、Shared Metadata 与 Lifecycle Scheduling 留在外部。即使某个 Sandbox 重启，Session Identity 也不会消失。
Slack / Web / Extension → Queue + Session State → Prepared Snapshot → Isolated Sandbox → Tests + Browser + Telemetry → Pull Request
对 Fintech 来说，Sandbox 必要但不充分
隔离运行 Agent 代码可以降低一类风险，但不会自动决定它能访问什么。Modal 当前的 Sandbox Networking 与 Security 文档描述了基于 gVisor 的隔离，以及 Block Network、Outbound Allowlist 和 Inbound 限制等控制。它们是安全 Primitive，不是完整 Policy。
- Credentials：Session-specific、短生命周期、Least Privilege。
- Egress：只允许真正需要的 Services。
- Data：优先 Synthetic 或 Scrubbed，而不是 Production Dump。
- GitHub：默认只允许 Branch 与 PR，不给 Merge/Admin。
- Internal Systems：Logs、Flags 与 Queues 默认 Read-only。
- Audit：能够重建 Tool Call、Command 与外部 Side Effect。
最重要的能力是验证，不是生成代码
Inspect 与简单 Prompt-to-Patch Bot 的差异在于 Feedback Loop。Agent 可以启动应用、跑 Test、读 Failure、改 Code、看 Browser，再继续修。执行环境因此成为 Agent Reasoning System 的一部分。
AI Code 的验收单位仍然应该是 Evidence。我们的 AI 生成代码 QA 指南负责质量层，而 Agent Sandbox Security Checklist负责更细的执行控制。
采用率继续上升，但瓶颈会向 Review 移动
公开数字应该按时间线理解。Ramp 1 月说约 30%，Modal 2 月说超过一半。更新的 Linear Ramp 案例写到 Inspect 已经完成四分之三的 Merge PR，并指出瓶颈正在转向 Code Review。
这比具体百分比更重要。当 Agent Execution 变得廉价且可并行，Human Review、CI Capacity、Test Reliability、Architecture Judgment 与 Release Coordination 就会成为稀缺资源。
不要优化每天创建多少 PR。要优化每分钟 Review 成本和风险单位带来的 Accepted Change。
一个 Sandbox 一个 Session 如何改变并行经济性？
本地 Agent 的上限是工程师 Laptop。共享 Remote Dev Box 的上限是环境互相冲突。Per-session Sandbox 把 Concurrency 变成 Infrastructure Scheduling 问题。Modal 当前的 Coding Agent Infrastructure 页面宣称可以支持非常高的并发 Sandbox 数量。这是 Vendor Capability Claim，不代表每个团队都应该运行数千 Agent。
真正的商业价值更简单：同一位工程师可以启动多个互不干扰的任务，而平台可以统一限制 CPU、Memory、Lifetime 与 Concurrency。
Ramp Inspect、OpenSandbox、通用 Harness 与本地 Agent
| 方案 | 解决什么 | 仍由你负责 |
|---|---|---|
| 本地 Coding Agent | 交互式开发效率 | Local Setup、Laptop Resource 与并行限制 |
| 通用 Agent Harness | Model、Tools、Context、Policy 与 Loop | Execution Environment |
| OpenSandbox 类 Runtime | 可移植隔离执行 API | Harness、Image、Snapshot、Credential 与 Integration |
| Inspect 类内部平台 | 深度集成的后台工程 Workflow | Product、Context、Permission、Eval、Review 与 Operations |
如果你是在选择 Sandbox Runtime，请看我们的 OpenSandbox 评测。
哪些应该买，哪些应该自建？
| Layer | 默认选择 | 原因 |
|---|---|---|
| Compute Scheduling 与 Disposable Sandbox | 先买 | 通常是 Commodity Infrastructure |
| Base Image 与 Snapshot | 自己掌握 | 编码你的 Dev Environment |
| Agent Harness | 自建或深度定制 | Workflow 与 Tool 才是差异化 |
| Repo 与 Product Context | 自己掌握 | 内部 Context 是自研 Agent 优势 |
| Permission 与 Approval Policy | 自己掌握 | 风险不能交给模型决定 |
| Observability 与 Eval | 掌握自己的指标 | 只有你的团队知道什么算 Accepted Outcome |
Autonomy 越高，Permission Model 越重要
OWASP 的 Excessive Agency 指南把 Excessive Functionality、Excessive Permissions 与 Excessive Autonomy 列为核心风险。对拥有 Shell、Database、GitHub 与内部 Service 的 Coding Agent，这个模型非常直接。
- 只提供必要 Tools；
- Write 权限比 Read 更窄；
- Production Action 用独立 Tool，而不是 Ambient Shell Privilege；
- 不可逆动作要求 Human Approval；
- 在 Downstream System 中真正执行 Permission；
- Session 结束时一起过期 Credentials。
30 天 Inspect-style Pilot
- 选一个 Repository。测试完善且环境可复现。
- 冻结 30 个真实 Task。Backend、UI、Tests 与小型 Cross-service Change。
- 构建一个 Sandbox Image。只放需要的 Services 与 Tools。
- 测 Cold Start。Clone、Install、Build 与 Service Ready 时间。
- 加入 Snapshot Refresh。测 Restore、Repo Drift 与 Staleness Failure。
- 收紧 Permission。Read-heavy、PR-only、无 Production Write。
- Instrumentation。Tool Call、Model Cost、Sandbox Minutes、Tests、Retries 与 Review Time。
- 测试并行。证明 Isolation 与 Concurrency Limit。
- 主动破坏环境。Kill Sandbox、Rotate Credential、让 Snapshot 变旧。
- 比较 Accepted Work。Merge Rate、Reviewer Minutes、Escaped Defect 与 Total Cost。
Wavect 能做什么
Wavect 的 AI Enablement 覆盖 Agent Harness、Repo 与 Tool Context、Sandbox Architecture、Eval Set、Permission Boundary、Observability 与 Rollout。我们的 Twinsoft AI Case Study体现同一个原则：模型只有在周围系统可运行、可验证时才真正有生产价值。
先构建 Execution Layer，再扩展 Agent
想在自己的 Repository 上测试 Inspect-style 后台编码 Agent？Wavect 可以围绕 Accepted Engineering Outcome 设计 Sandbox、Snapshot Strategy、Permissions、Eval Set 与 Rollout。
查看相关服务：
结论
Ramp Inspect 最值得复制的想法，是把完整而可丢弃的 Development Environment 变成 Agent 的 Execution Unit。
Snapshot 让它启动足够快，Isolation 让并行可控，深度 Tools 让 Agent 能验证而不是只生成，外部 Coordination 让 Session 不依赖某个终端。
对 Fintech 与其他受监管团队来说，Permission、Data Access、Egress、Auditability 与 Review Capacity 必须和 Agent 数量一起扩展。