SHACKLE 发布 SP/1.0 标准：为 AI Agent 工具调用引入运行时治理

SHACKLE 项目及其 SP/1.0 一致性标准近日在 Hacker News 发布，针对自主 AI Agent 的工具调用过程提供确定性运行时治理。项目由开发者 Dante Bullock（@Fame510）独立完成，首次公开发布日期为 2026 年 6 月 17 日，采用 AGPL 开源协议。

项目定位与运行方式

SHACKLE 并非简单的运行时熔断器，而是一套可被独立验证的运行时治理层。它会实时拦截每一次 Agent 工具调用：当出现 token 循环失控、工具调用级联未处理或预算超支时，系统能在下一次调用执行前中止整个循环，而非仅拦截越过阈值的那一次调用。成本信息在每次调用后读取，因此治理动作针对循环而非单次调用。

项目强调其参考实现已通过自身的一致性测试套件，并声明"这不是提案或原型，而是一份可以运行、验证并据其认证的工作标准"。

SP/1.0 标准的核心定义

SP/1.0（SHACKLE Protocol 1.0）是面向自主 AI Agent 行为运行时治理的一致性标准，规范了三项其他 Agent 框架未能以可验证合约形式固定下来的要素：

• 决策面：ALLOW / DENY / HITL。每次被治理的动作必须解析为这三种结果之一，每种结果附带确定且可检视的原因，不存在第四种状态。
• 一致性模型：Valid(τ) ⇔ Required(τ) ⊆ Supported(τ)。一个状态转换是否有效，取决于其所需能力是否完全落在系统已证明支持的能力集合之内，能力被建模为集合关系而非承诺。
• 核心不变式：history-visible ≠ runtime-executable。动作被记录、可恢复或可重放，并不等同于其在运行时已被授权；被拒绝或延后的动作即便再次回到流程，仍会被拒绝而非放行。

标准随附 15 个哈希可验证的一致性向量（fixtures/conformance.json），其中包含 10 个决策核心用例与 5 个人机协同（HITL）转换用例，覆盖 approve、reject、modify、defer-escalate、duplicate-resume 五种场景。参考实现 shackle/conformance.py 仅依赖 Python 标准库，提供 decide(config, state, call) → (verdict, reason) 接口。运行 pytest tests/test_conformance.py 可对每个向量进行核对。

一致性的实现分层

项目将一致性切分为两层：shackle/conformance.py 与 fixtures/conformance.json 构成"一致性验证层"，即规范文本及其 15 个哈希可验证向量；shackle/core.py 则是"运行时集成层"，通过 @Guard 装饰器将真实的 TriggerEngine 与 ExecutionState 映射到 decide(config, state, call) 合约，并在每一次工具调用与 LLM 调用时调用同一份参考决定函数，把判定结果写入 state.last_decision。换言之，所谓"SP/1.0 一致"指的是规范、向量与运行时实际调用的参考实现构成同一决策面，而非两套恰好一致的实现。

三档认证等级

SHACKLE 认证以公开的哈希可验证向量作为唯一衡量依据，认证方式即复现，不存在私有审计或付费通道：

• SP/1.0-Core（核心一致）：保证运行时对每次被治理动作返回正确的 ALLOW / DENY / HITL 判断及对应的拒绝原因，决策面可靠。
• SP/1.0-HITL（转换完整）：在核心级之上保证五种 HITL 转换全部正确处理，被拒绝与被延后的动作被证明无法通过重放执行。
• SP/1.0-Sovereign（企业运行时）：在 HITL 之上叠加原子守护进程状态、防篡改账本与审计导出，面向企业与收购方的完整问责需求。

按作者描述，第三方已独立复现向量哈希。任何希望声明 SP/1.0 一致的运行时，只需从干净克隆开始运行测试套件即可获得可核查的证据。