AI 为何无法绕过 Claude Code Harness 的护栏执行前裁决机制设计哲学【免费下载链接】claude-code-harnessClaude Code Dedicated Development Harness - Achieving High-Quality Development Through an Autonomous Plan→Work→Review Cycle项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-harnessClaude Code Harness 是一个面向 Claude Code、Codex、Cursor、Grok 的自主开发护栏框架核心是用「计划 → 执行 → 审查」的可重复闭环来保证交付质量。它真正让人安心的地方不在模型有多聪明而在于每一次工具调用在运行之前都会先被一个 Go 引擎裁决一遍——而不是等代码写完、文件 diff 出来之后才回头检查。这就是本文要拆解的「执行前裁决机制」设计哲学AI 不是被关进笼子而是被装上了一套有硬地板、有可配置护栏、有审计留痕的安全底盘。 先看清楚Claude Code Harness 到底在解决什么问题AI 自主编码最大的风险不是写不出代码而是它会在无人盯着的时候悄悄地做一些危险动作把计划写进聊天记录然后消失、为了赶进度把测试做成可选项、在代码已经合并之后才做审查、把本该在隔离工作区里的删除操作扩散到整个项目。Harness 的思路很直白先写规格只实现已批准的切片独立审查再打包证据。下面这张图是它官方的运行循环从 Spec规格到 Plan计划、Work执行、Review审查、Release发布每一步都留好给下一步用的材料。但循环本身解决的是流程真正让护栏绕不过去的是下面这套裁决引擎。️ 为什么执行前裁决是绕不开的关键大多数 AI 编码工具的审查都发生在事后代码已经跑了、网络请求已经发了、文件已经删了然后才拿着一份文件 diff 来评审。Harness 认为这条路走不通原文里写得很直接一份文件 diff看不到一次网络发送也看不到一次删除。于是它把裁决时机提前到了工具调用真正执行之前AI 每发起一次Bash、Write、Read等操作都会先经过一个纯 Go 引擎的裁决返回三种结果之一——Deny拒绝直接拦下不执行Ask确认暂停等人类点头Warn警告放行但在上下文里留下一条提醒。这个裁决入口在 go/internal/guardrail/pre_tool.go 的EvaluatePreTool执行顺序是先过硬地板、再过可配置护栏顺序本身就是安全设计的一部分。⚙️ 双层护栏一张不可覆盖的硬地板 一张可调的护栏网Harness 把安全拆成两层且故意让两层强度不同。这不是冗余而是把绝对不能碰的红线和项目可以按自己情况调的偏好分开管理。第一层运行时硬地板Runtime Action Hard Floor——不可覆盖这一层实现于 go/internal/runtimefloor/runtimefloor.go它专门拦截 Bash 命令覆盖 5 个类别且没有任何关闭开关——不是靠配置项、环境变量或权限模式能关掉的那种类别拦截什么为什么是红线资金/计费stripe、paypal、aws ce、gcloud billing涉及真实扣费绝不该由 AI 自主发起对外网络非白名单主机的curl/wget/nc/scp防数据外泄diff 根本看不到读取密钥cat .env、~/.ssh、*.pem、credentials凭据不该被 AI 随手读走生产发布npm publish、kubectl apply、gh release影响线上必须人来按越区破坏工作区之外的rm类破坏性命令防止删除操作扩散出隔离区关键细节这一层跑在一条隔离的代码路径上没有 disable 开关所以一次自主运行没法说服它放行。即便项目配置文件损坏、解析失败它也会默认拒绝fail-safe而不是默认放行。第二层可配置护栏 R01–R15——你能调的那张网这一层实现于 go/internal/policy/rules.go是一条按顺序匹配、首个命中即返回的声明式规则表。每条规则都有一个Rxx编号和明确的裁决结果部分可以按项目配置调整编号拦截什么结果R01sudo拒绝R02 / R03写保护路径 / 用 Bash 写保护路径拒绝或确认R04写项目根之外确认R05危险删除命令确认R06git push --force拒绝工作模式下也拦R10--no-verify/--no-gpg-sign拒绝不许绕过钩子R11保护分支reset --hard拒绝R12直接推保护分支拒绝 / 确认可配置R15暂存密钥文件拒绝这套设计的哲学是红线交给硬地板去死守偏好交给护栏去调两件事互不干扰谁也别想替谁松口。这里有个容易被忽略的隐藏细节整个裁决引擎是Go 原生实现的不再依赖 Node.js。好处不只是性能——而是让裁决逻辑变成一个可审计、可测试、可复现的单一可信源而不是散落在各处 shell 脚本里、容易被环境差异悄悄削弱的一段段代码。 计划时批量预批准不打断执行流也不开后门如果 AI 每遇到一个风险操作就停下来问一次自主执行会被打断得支离破碎。Harness 的解法很巧妙把确认从执行时挪到计划时一次性问清。实现见 go/internal/guardrail/plan_preapproval.go。它会在计划阶段收集这次计划需要的高风险操作一次性让你批。但这份批准不是无限通行证它自带三道锁有效期ExpiresAt过期自动失效任务作用域Scope只对当前 phase task 生效换个任务就作废使用次数上限MaxUses默认最多 10 次用满即止。一次批准永远不会变成一个永久后门。而且预批准只能压掉确认Ask这一档永远压不掉显式拒绝Deny分支也压不掉跑在它前面的运行时硬地板。换句话说批准给你的是少问几次的便利而不是随便放行的权力。 每一次拦截都被留痕你数得出到底挡了什么护栏拦了一次你凭什么知道Harness 把所有裁决结果都写进一份 JSONL 审计日志见 go/internal/auditlog/auditlog.go。它记录规则 ID、类别、裁决结果但你几乎不用担心日志本身泄露内容命令文本从不落盘只存一个 SHA256 哈希和长度对读密钥和资金/计费这两类连哈希都不写日志写入用文件锁保护失败会被静默忽略——可观测性永远不会反过来改变护栏的裁决。这意味着你可以直接数一数到底有多少次被拦、分别踩了哪条线而不是靠猜。 设计哲学让 AI 可靠的不是模型而是边界Harness 有一句点题的话它并不让模型变聪明。它固定的是流程和模型周围的那道边界——所以模型再怎么换它都照常工作。这正是执行前裁决机制的底层哲学AI 的能力会变、会漂移但边界是你可以用代码钉死的。围绕这个目标源码里还藏着几条很较真的设计都源于真实的对抗性复测源码注释里明确记录了 2026-08-11 的对抗重验证防符号链接逃逸判定文件是否在允许目录内时会同时做文本路径和解析软链后的物理路径两道检查——否则攻击者可以在状态目录里埋一个指向别处的软链把允许写状态目录变成任意写文件。防路径穿越/.claude/state/../../src/x.ts这类..穿越会在 Clean 之后被拒绝。项目根解析不认.claude只认.harness/.git且向上查找时绝不会越过用户主目录——避免一个散落子目录里的.git把整个 home 变成rm -rf的放行区。一句话它假设 AI 会想尽办法绕过然后用代码把每一条可能的缝都先焊死再让对抗测试来证明确实焊死了。 快速上手30 秒装好护栏护栏的价值要在真的跑起来时才体现。按 README.md 的路径安装只有三步claude /plugin marketplace add Chachamaru127/claude-code-harness /plugin install claude-code-harnessclaude-code-harness-marketplace然后跑一次/harness-setup初始化再丢给它一件小事试试/harness-plan 改进 README 的引导流程它会帮你起草spec.md和Plans.md。记住你的角色——不是去写计划而是在它继续执行之前去批准或纠正它。从这一刻起后面每一次写文件、发命令都会先过一遍上面那套硬地板 护栏的裁决。✅ 小结AI 绕不过护栏靠的不是运气回到标题的问题——AI 为何无法绕过 Claude Code Harness 的护栏答案是三层机制叠出来的时机提前裁决发生在工具调用执行之前而不是事后看 diff双层分离不可覆盖的运行硬地板死守 5 类红线可配置的R01–R15 护栏管理项目偏好谁也不能替谁松口便利有界计划时批量预批准减少打断但每份批准都带有效期、任务作用域和使用上限永远不会变成永久后门全程留痕每一次拦截都进审计日志你能数得出到底挡了什么且日志本身不泄露命令内容。它没有试图让 AI 变强而是把边界这件事用 Go 代码钉死——这才是执行前裁决机制真正的哲学当模型会漂移时让不漂移的那部分去兜底。【免费下载链接】claude-code-harnessClaude Code Dedicated Development Harness - Achieving High-Quality Development Through an Autonomous Plan→Work→Review Cycle项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考