openai/codex: 代码执行运行时的沙箱与策略¶
Codex 及其公开组件的核心价值不在于生成代码，而在于如何安全、受控地执行 Agent 提出的代码指令。它将“推理层”与“执行层”彻底解耦，通过工作区隔离与动态钩子守住安全红线。
1. 核心模型：执行隔离链¶
任务进入系统后，不是直接调用 Shell，而是进入一套严密的隔离执行链：
- Workspace & Sandbox：为任务分配独立的临时工作空间与 Linux 沙箱。工程直觉：不要指望模型“自觉谨慎”，必须通过 OS 级别的隔离防止 Agent 删库或越权读写。
- Exec Server：将命令执行、标准流捕获与结果解析收拢为独立的子系统。
- Verification (验证门槛)：任务完成后，自动运行测试或语法检查。只有通过验证的 Patch 才被视为有效产出。
2. 治理插槽：Hooks 与 Policy¶
- ExecPolicy (执行策略)：定义哪些命令是黑名单（e.g.,
rm -rf /），哪些需要人工二次确认。 - Hooks (钩子系统)：在执行关键动作前后插入确定的业务逻辑（如审计日志写入、权限注入）。
3. 外部能力的标准化接入¶
- Connectors & MCP：将外部文档、搜索服务与三方 API 统一抽象为连接器。所有外部输入都必须经过 Policy 的二次过滤，确保不携带注入风险。
4. 常见误区与失效模式¶
- 隐式环境污染：未彻底隔离 Workspace，导致不同任务间的临时文件互相干扰。
- 忽略输出截断：Agent 跑了一个会输出几百万行日志的命令，导致 Exec Server 内存溢出或上下文被无效信息淹没。
- 同步阻塞执行：将耗时的测试任务挂在同步请求中，导致连接超时。应采用“提交任务 -> 轮询/回调结果”的异步模式。
5. 排查顺序：从环境到逻辑¶
- 查 Sandbox 状态：沙箱是否正常启动？资源配额（CPU/Memory）是否已打满？
- 校验 ExecPolicy：命令失败是因为推理错误，还是被安全策略静默拦截了？
- 分析 Verification 报告：任务产出是否通过了语法与逻辑校验？
- 查 Connector 链路：外部能力的响应是否超时？数据格式是否符合 Runtime 的预期？
结论：
Agent 的安全不是提示词写出来的，是沙箱围出来的。Codex 提供的参考架构说明了：开发型 Agent 的重心正从“代码生成”转向“受控环境下的任务执行与验证”。