核心用法
OpenExec是一个受控确定性执行服务，定位为"执行层"而非智能体。它通过两种模式运行：
- Demo模式：零配置即可运行，内置重放保护、确定性执行和收据生成
- ClawShield模式：生产级部署，需配置Ed25519公钥，离线验证签名后方可执行
核心流程：接收结构化请求 → 验证签名/权限（离线）→ 确定性执行 → 生成可验证收据。所有验证完全离线，不发起任何HTTP/RPC/治理调用。
显著优点
| 维度 | 特性 |
|------|------|
安全架构 | 应用层强制边界+零出站网络，攻击面极小 |
| **合规性** | 签名验证+收据链，满足审计追溯要求 |
| **确定性** | 相同输入必得相同输出，消除非预期副作用 |
| **部署灵活** | SQLite默认零依赖，也可外接数据库 |
| **分层解耦** | 执行/治理/见证三层可独立替换 |
潜在局限
- 无OS级隔离：需配合容器/VM沙箱使用，仅提供应用层边界
- 非自主决策：纯执行器，无策略引擎，需外部治理系统（ClawShield）签发批准
- 动作白名单：
OPENEXEC_ALLOWED_ACTIONS需手动维护，动态扩展能力有限 - Python运行时：受GIL限制，超高并发场景需横向扩展
适合人群
- 需要人-机分离授权的金融机构（交易执行需多签批准）
- 追求可审计自动化的DevOps/SRE团队
- 构建可信执行链的区块链/DID基础设施开发者
- 需最小权限原则落地的零信任架构实施者
常规风险
| 风险 | 缓解措施 |
|------|---------|
| 私钥泄露 | 公钥通过环境变量注入，私钥永不触碰OpenExec |
| 重放攻击 | 内置nonce唯一性校验 |
| 收据伪造 | Ed25519签名+哈希链，可第三方验证 |
| 容器逃逸 | 需叠加gVisor/Kata等强隔离运行时 |
| 依赖供应链 | 建议锁定`requirements.txt`哈希 |
关键设计原则
> "OpenExec is not an agent. It is not a policy engine. It does not self-authorize."
这三个否定定义了其安全哲学：绝对被动、绝对透明、绝对可验证。