SHACKLE 开源：为 AI Agent 工具调用引入可验证的运行时治理层

开发者 Dante Bullock 发布了一个名为 SHACKLE 的开源运行时治理层，并同步提出配套的 SP/1.0 一致性标准（Conformance Standard），用于在 AI 智能体调用工具时进行实时拦截。SHACKLE 已开源并附带 15 个可哈希校验的测试向量，号称任何人都可通过复现来验证运行时是否符合该标准。

SP/1.0 标准要规范什么

标准面向的是自主型 AI 智能体在每一步将要执行某个动作（调用工具、花费预算、调用另一个智能体、执行交易等）的「决策瞬间」。它明确规定，每一次被治理的动作必须被解析为三种状态之一：允许（ALLOW）、拒绝（DENY）、转人工（HITL），不存在第四种状态或模糊地带，每个判定都附带确定性的、可检视的原因。

标准的核心数学表达是 Valid(τ) ⇔ Required(τ) ⊆ Supported(τ)：一个转移是合法的，当且仅当它所需的全部能力都被系统支持。能力被建模为集合关系，而不是承诺。

标准还定下一条不变量（Invariant）：history-visible ≠ runtime-executable。一个动作即使被记录、被恢复（resume）或被回放（replay），也不能作为「它曾经被授权」的证据。也就是说，被拒绝或被推迟的动作如果再次出现，必须被再次拒绝，不能绕过护栏。

一致性套件：靠复现来证明

SP/1.0 以以下形式发布，任何人可独立验证：

• 15 个可哈希校验的一致性测试向量（fixtures/conformance.json），其中 10 个为决策核心用例，5 个为人机协同转移用例（批准、拒绝、修改、推迟升级、重复恢复）。
• 一个仅使用 Python 标准库的参考实现 shackle/conformance.py，提供 decide(config, state, call) → (verdict, reason) 接口。
• 可执行的证明脚本：pytest tests/test_conformance.py 会将所有向量跑过参考实现并断言通过。

也就是说，符合性不是靠声明，而是靠跑测试。SHACKLE 声称任何人都可以从一个干净的克隆仓库出发，在数分钟内验证某个运行时是否真的满足 SP/1.0。

认证等级划分

SHACKLE 提出三级认证：

• SP/1.0-Core（核心一致性）：运行时能为每个被治理的动作返回正确的 ALLOW/DENY/HITL 判定及正确的拒绝原因。
• SP/1.0-HITL（转移完整性）：在 Core 基础上，涵盖所有 HITL 转移，并保证被拒绝或推迟的动作不能通过回放绕过。
• SP/1.0-Sovereign（企业级运行时）：在 HITL 基础上增加原子守护进程状态、防篡改账本与审计导出，构成完整的企业可问责层。

实现细节与许可证

项目采用 AGPL 许可证发布。其运行时集成通过 @Guard 装饰器实现，把内部的 TriggerEngine 与 ExecutionState 映射到 decide() 的 (config, state, call) 契约上，并在每次工具调用和每次 LLM 调用时调用同一份参考 decide()，把判定结果记录在 state.last_decision。

需要注意的是，SHACKLE 附有一个「尽力而为」的成本核算免责声明：成本是在每次调用之后从 usage 中读取的，因此 SHACKLE 是在循环越过预算线之后停止整个循环，而不是只阻止越界的那一次调用。

作者与生态意义

SHACKLE 标准、Required ⊆ Supported 一致性模型、decide() 接口与 HITL 转移契约均由 Dante Bullock（@Fame510）单独创作，首次发布日期为 2026-06-17。

对于正在大规模部署自主智能体的团队来说，缺乏可验证的运行时治理是落地的主要障碍之一。SHACKLE 提出了一种「用复现代替信任」的认证路径，并把「动作历史 ≠ 执行授权」作为核心不变量。如果社区采纳，这种做法有可能成为 Agent 治理的一种参考实现；但目前它仍是单一作者的开源项目，缺少主流框架或厂商背书，能否被行业广泛采用仍需观察。