Shackle：为 AI 智能体提供执行前的允许/拒绝/人工接管闸门

Shackle 是一个面向自主 AI 智能体的开源运行时治理层，并附带一套名为 SP/1.0（SHACKLE Protocol 1.0）的一致性标准。其核心思路是在每一次 agent 工具调用真正执行之前，先由一个标准化的判定层给出 ALLOW（允许）、DENY（拒绝）或 HITL（需人工介入）三种结果之一，从而阻止 token 死循环、未处理的工具级联调用和预算超支等问题。

该项目由 Dante Bullock（@Fame510）单独署名，首次发布于 2026-06-17，以 AGPL 协议开源。文章中提及的「通过第三方独立复现」「通过认证」等表述，目前均来自作者本人声明，未见独立机构或主流厂商的验证报告。

SP/1.0 标准的三项核心约定

SP/1.0 把「能否执行下一步」这件事形式化为一个可验证的契约，包含三项明确约定：

判定面（Decision Surface）：每一次被中介的动作都只能解析为 ALLOW、DENY、HITL 三种结论之一，不存在第四种状态；每种结论都附带确定性、可检视的理由。
一致性模型（Conformance Model）：以 Valid(τ) ⇔ Required(τ) ⊆ Supported(τ) 作为数学骨架，即一次转换「合法」当且仅当它所要求的一切都在系统可证明支持的范围内。
核心不变量：历史可见 ≠ 运行时可执行。仅凭动作被记录、被恢复或被重放，并不能证明它曾被授权；被拒绝或被推迟的动作若再次出现，仍会被拒绝。

15 个可哈希校验的测试向量

SP/1.0 的可验证性体现在仓库内 fixtures/conformance.json 中的 15 个测试向量：

10 个 decision-core 用例，覆盖判定面在常见场景下的解析；
5 个 HITL 转换用例，分别对应 approve、reject、modify、defer-escalate、duplicate-resume 五种状态转移。

配套的参考实现位于 shackle/conformance.py，仅依赖 Python 标准库，函数签名为 decide(config, state, call) -> (verdict, reason)。仓库内的 pytest tests/test_conformance.py 会把每个向量跑一遍。文中提到「fixture 哈希已由第三方独立复现」，但未给出具体复现方信息。

认证等级

项目将认证分为三个等级，区别在于覆盖范围与可审计深度：

SP/1.0-Core：核心一致性，保证判定面在所有中介动作上都给出正确的 verdict 与 deny 理由；
SP/1.0-HITL：在 Core 之上覆盖完整的 HITL 转换，保证被拒绝或被推迟的动作无法通过重放绕过；
SP/1.0-Sovereign：在 HITL 之上加入原子化的守护进程状态、可防篡改的账本与审计导出，面向企业与监管场景。

认证过程被作者描述为「复制即可验证」：从干净克隆开始，运行同一组公开向量即可核对声明，无私有审计或付费通道。

仓库结构与运行时集成

仓库内与标准相关的部分主要包括：

shackle/conformance.py：被认证的一致性层，即上文所述的参考实现；
fixtures/conformance.json：15 个哈希校验向量；
shackle/core.py：实际可运行的运行时集成，通过 @Guard 装饰器将 TriggerEngine 与 ExecutionState 映射到 decide() 的 (config, state, call) 契约，每次工具调用与 LLM 调用都调用同一份参考实现，并把 verdict 记录到 state.last_decision。

换言之，「SP/1.0 一致性」对应的是规范本身、向量集与被运行时实际调用的参考实现三者，而不是两套恰好一致的并行实现。运行时在每次调用后会读取使用成本作为下一轮判定的依据，可在累计越限时整体停机，而不是仅截停单次调用；不过文中说明，这是 AGPL 协议下的「尽力而为」实现。