OpenShell 是什么：AI Agent 的操作边界在哪里
OpenShell 架构：一次请求经过哪些信任边界
沿 DNS 或 TCP 请求追踪 Agent、沙箱、监督进程和外部目标。
OpenShell 架构：一次请求经过哪些信任边界知识学习CN编辑简报更新 2026-10-04
你将学会
- 给组件分工
- 跟踪一个连接
- 观察故障模式
开始前需要
- 一个可丢弃任务与支持的计算运行时
- 检查策略和 Provider 配置的权限
把文档中的控制声明转化成一份范围有限、可审阅的试验报告。
先看结论
- 沙箱识别发起者，监督进程做最终决定。
- 工作负载不应有直接外网路径。
- 不同运行时需要不同的边界测试。
给组件分工
网关是控制面。计算驱动启动工作负载和独立的可信监督进程，建立受保护通道并检查围栏。沙箱进程与 Agent 同处边界内，负责持有其子进程。
沙箱侧报告动作，不自行做最终网络策略决定。文档中的 Linux 后端用 Landlock 限制文件访问，通过 seccomp user notification 暂停网络操作，等待可信侧处理。
跟踪一个连接
沙箱识别发起 TCP 或 DNS 请求的可执行程序，经认证的多路复用通道上报。监督进程核对策略、解析 DNS 或建立连接，并且只在获准的请求上附加 Provider 凭据。
外层围栏使这条调解路径不能被绕开。Docker 与 Podman 关闭工作负载网络，Kubernetes 依赖 NetworkPolicy，VM 没有客机网络设备；各机制都需要独立测试。
观察故障模式
架构文档说，启动需等待监督进程确认；通道掉线时 Agent 冻结，随后尝试重连或停止工作负载。各 TCP 连接有独立数据流和背压。
这些描述来自固定版本设计文档和部分源码。评估实际发行版时应测试通道中断、被拒绝的 DNS 请求和意外的调用程序，不能只凭架构图下结论。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
追踪 Agent 发起的 DNS 请求。
- 2
比较各运行时实现外层围栏的方式。
- 3
在目标驱动上测试出站拒绝与通道中断。
可复制示例
text
Agent TCP/DNS -> 沙箱观察与身份识别
沙箱 -> 认证通道 -> 监督进程检查策略
监督进程 -> 可选凭据 -> 外部目标常见问题
策略执行发生在哪里？
工作负载内执行文件和进程限制；可信监督进程核对受调解的网络请求与凭据使用。
监督进程不可达时会怎样？
固定版本架构描述了冻结、重连窗口和恢复失败后停止工作负载。
资料来源
- OpenShell / docs/about/architecture.mdx来源核查 2026-10-04
- OpenShell / docs/how-it-works/sandboxes/overview.mdx来源核查 2026-10-04
- OpenShell / crates/openshell-sandbox-backend/src/mediation.rs来源核查 2026-10-04