SHACKLE SP/1.0：为自主 AI 智能体设计的运行时熔断协议

自主 AI 智能体（agent）在生产环境中执行网页搜索、文件读写、API 调用与代码执行时，往往缺乏运行时的中间裁决环节。一旦智能体陷入重试循环（同一工具、同一错误、每次都消耗 token），框架自带的递归上限或 token 上限是唯一的护栏，而此时钱包里的余额可能已经被烧掉一大截。SHACKLE 项目的作者列举了若干已记录的真实事故：单次智能体无限循环消耗超 6000 美元的 API 费用、重复工具调用超过 50 次仍无变化、子进程挂死却持续消耗 token 等。

2026 年 6 月，Sovereign Logic 发布了 SHACKLE 的 SP/1.0 规范版本，定位为「自主 AI 智能体的运行时熔断器（Runtime Circuit Breaker）」。其核心回答一个问题：在某一刻，某个智能体是否被允许以这些参数执行这个工具。规范由 Dante Bullock 起草，参考实现托管在 GitHub 的 Fame510/SHACKLE 仓库，首次公开提交时间为 2026 年 6 月 17 日。

设计原则

SHACKLE 把决策函数 decide(state, call) → Verdict 设计为纯函数——同样的输入永远产生同样的输出，不进行任何 I/O、不引入副作用、热路径上不做内存分配。整套规范建立在六条核心原则上：

确定性核心：纯函数决策，便于审计与单元测试
守护进程即权威：SHACKLE 守护进程是时间、状态与裁决的唯一来源，智能体不被信任
仅追加审计：每条裁决使用 Ed25519 签名写入不可变审计日志，保管链可密码学验证
数学可验证：9 条不变量属性在所有输入下成立，由基于属性的测试（每条 500+ 样本）证明
优雅降级：智能体可以在本地/库模式下工作而无守护进程，分布式状态是可选升级路径
失败即拒绝：网络故障、守护进程崩溃或超时一律返回 DENY，无显式授权不得执行

部署模式

SP/1.0 规范定义了三种部署模式：

库模式（Model A）：智能体进程内集成，仅使用本地状态
Sidecar 守护进程（Model B）：智能体作为薄客户端，通过 Unix socket 或 gRPC 与 SHACKLE 守护进程通信，守护进程负责预算、计数器、熔断器与审计日志
分布式集群（Model C）：多个智能体连接到由 Redis 支撑状态、Postgres 存储日志的 SHACKLE 守护进程集群，传输层使用 gRPC/TLS

决策算法的 8 层叠加

决策函数不是单条规则，而是 8 层叠加的检查：

第 1 层：熔断器状态——若已触发则 DENY
第 2 层：Nonce 防重放——重复 nonce 直接拒绝
第 3 层：预算守卫——按 USD 预算检查，超额可触发 HITL（人在环）或直接拒绝
第 4 层：重复调用守卫——限制同一工具同一参数的最大重复次数
后 4 层规范未在摘录中完整给出，但同样基于纯函数式判断

审计与合规

每次裁决都被 Ed25519 签名并以链式结构追加到审计日志，链头可被密码学验证。规范还明确了「人在环（HITL）」的触发条件：当预算命中阈值、出现潜在破坏性操作或裁决为 DENY 时，可按配置切换到人工复核。失败策略默认 fail-closed——守护进程不可达即拒绝执行，宁可停摆也不放行。

参考实现采用 AGPLv3 开源与商业双许可，仓库中提供了 Python 与 gRPC 客户端的最小可运行示例。截至规范发布时，作者尚未提供大规模生产部署数据，社区 adoption 仍处于早期阶段。对于关注智能体成本与运行时安全、且具备基础设施运维能力的团队，SHACKLE 提供了一个可立即评估的开源选项。