零依赖、零网络、永不提交：delegate-skills 可审计信任模型与安全设计完整解析-酒店常州论坛

零依赖、零网络、永不提交：delegate-skills 可审计信任模型与安全设计完整解析

【免费下载链接】delegate-skillsDelegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.项目地址: https://gitcode.com/gh_mirrors/de/delegate-skills

一文读懂 delegate-skills 的信任模型

delegate-skills是一个委派编码技能包：它把你的编码任务委派给另一个独立的编码代理 CLI（Codex、Claude Code、Cursor、Cline 等 17 种实现者），由它编辑真实工作区，产出的 diff 交给你审查，最终由你本人提交 commit。整个包刻意做到"可审计"：零依赖、零网络、永不提交——你不需要相信作者的话，只需要读懂每一个脚本。 🛡️

为什么 AI 代理需要一套信任模型？

让 AI 代理直接操作你的代码库，有三个经典风险：

能力失控：代理执行了超出任务范围的写入或命令；
边界模糊：代理顺手提交了代码，你根本来不及审查；
不可审计：工具本身依赖不透明、会联网、会上传数据，你无法确认它到底做了什么。

delegate-skills 的安全设计，就是围绕这三点逐条给出的工程化答案。它的核心循环非常朴素：

写简报（brief）—— 自包含的任务说明，实现者没有你的对话历史；
派发—— 通过自带的relay.mjs脚本启动目标 CLI；
等待—— relay 阻塞直到进程退出，写出一份结构化result.json；
审查—— 你自己重跑测试门禁、完整读 diff；
落地（land）——你来 commit，因为提交权属于审查者。

这个"委派 → 审查 → 落地"的闭环，是所有安全机制的载体。

零依赖：Node 内置模块，逐行可审计

每个*-delegate技能只包含一个可执行文件：scripts/relay.mjs。以 skills/claude-delegate/scripts/relay.mjs 为例，它的全部导入都是 Node 内置模块：node:child_process、node:crypto、node:fs、node:path、node:os等，没有任何 npm 第三方依赖。

这意味着：

供应链风险趋近于零——你审计的不是几百个传递依赖，而是一个可以逐行读完的脚本；
单技能独立安装——测试套里的隔离安装检查会把某个技能目录单独拷到临时目录运行relay.mjs --help，持续证明它不依赖仓库其他目录；
唯一的"外部调用"是启动你已安装的实现者 CLI 和git（以及 Windows 下的进程启动器）。

README.md 的Trust and validation部分把这条信任线写死为规范：脚本不发起自己的网络调用、不读写任何凭据、不发遥测。官方甚至直接说——"运行之前，先读脚本"。

零网络：没有遥测，没有凭据，没有黑盒

配合零依赖，relay 的行为面被压缩到极致：

行为	是否发生	说明
发起网络请求	❌	relay 本身零网络；只有被启动的实现者 CLI 可能连接自己的服务端
读写凭据	❌	认证完全复用你终端里已有的登录态
发送遥测	❌	无任何上报通道
提交 commit	❌	见下一节
跨目录 import	❌	由隔离安装测试持续验证

任务简报通过stdin传递给实现者，而不是拼进命令行参数，避免敏感任务文本泄漏到进程列表；产物默认写到系统临时目录，与你的仓库物理隔离。

永不提交：提交权永远属于审查者

这是整个信任模型最硬的一条不变量：relay 永不 commit，提交属于审查者（见 CONTRIBUTING.md 的四条不变量）。工程上它被层层落实：

拒绝规则：以 claude-delegate 为例，正常权限档案用字符串规则拒绝git commit、git push及嵌套claude调用等常见直接 shell 形式，并如实注明——"别名、脚本、包装器可能绕过它们，所以它们只是减速带，真正的边界是简报里的禁提交指令加上编排者审查"；
强制禁用：Aider 是唯一默认自动提交的实现者，relay 对它永远传递--no-auto-commits和--no-dirty-commits，且不可配置（见 README.md 脚注 [^aider]）；
文档兜底：每个 relay 的失败提示里都写着"relay does not commit。审查 diff、自己重跑门禁，再从编排侧落地"（skills/claude-delegate/scripts/relay.mjs）。

注意这里的措辞精度：拒绝规则被明确定性为减速带而非安全边界。一个把"防绕过"当承诺卖的工具有问题，而如实说明自己防不住什么的设计，才配得上"可审计"三个字。

只读熔断器：readOnlyViolation 三态报告

想做纯审查/诊断而不让代理动文件？加一个--read-only。但各 CLI 的只读模式能力参差不齐，delegate-skills 的做法是用测量代替假设：

relay 对比 git porcelain 解析结果，并对原本就脏的可见路径做指纹比对；
readOnlyViolation是三态的：true（探测到变更，硬警告）、false（覆盖完整且未检出变更）、null（覆盖不完整，无法下结论）；
官方反复强调：这是报告型熔断器，不是操作系统边界——被忽略的路径、完美还原、本地钩子写入、并发变更都不在其合同之内（见 skills/claude-delegate/SKILL.mdPermission profiles一节）。

这个三态设计值得借鉴：它拒绝用"false 就等于绝对安全"的假象糊弄审查者，而是把"我能证明什么、不能证明什么"讲清楚。

快速失败：项目配置的内容绑定审批

用 delegate-setup 配置"车队"（fleet lanes）时，项目级配置采用内容绑定审批：

只有经过你显式批准的config.mjs write --scope project才会把审批哈希写入该工作区的 Git 元数据；
relay 应用项目 lane 前，校验当前配置内容与审批哈希是否精确匹配；
克隆下来的仓库、事后被编辑过的配置，一律快速失败（fail closed），必须重新走一遍审查与写入。

换句话说，一个来路不明的项目.delegate/config.json无法替你"静默"切换实现者或权限参数。完整路径与覆盖规则见 skills/delegate-setup/references/schema.md。

诚实边界：能力用 CLI 自己的术语声明

AGENTS.md 为每种实现者维护了一张受控词汇表，并立下一条硬规矩：能力必须用 CLI 自己的术语陈述，凡 CLI 强制不了的，必须直说。例如：

Grok 无法在 headless 下被阻止写入，所以 relay 只报告readOnlyViolation熔断器，"不强制、不归因"；
Command Code 的 headless 模式只有两档——扣住写工具，或--yolo全量信任，中间没有沙箱，于是 README 直接建议：不可接受树外写入时，请用容器或 OS 级沙箱；
某 CLI 没有只读模式？这样的实现者可以合并，但暗示它有只读模式的技能不能合并。

这种"把不能做到的事写进文档"的文化，本身就是信任的一部分。

用运行而非假设做验证

delegate-skills 的Verification status章节（README.md）是罕见的"证据清单"：每个技能都记录在什么平台、什么 CLI 版本、跑了什么用例，比如：

在一次性仓库上的真实编辑运行中，HEAD未被触碰——relay 没提交，代理也没提交；
401 认证失败时 relay 正确报告failed而非假成功；
拒绝规则实测拦截了git commit、git push、嵌套调用与$HOME写入。

"仅合同测试、真实运行待验证"是被允许的合并答案，"没跑过却写 verified"则不是。配套机制还有：

超时/中止矩阵：超时或捕获信号时终止整个实现者进程树，并保留结果产物（test/harness/constants.mjs 强制每个 relay 入矩阵，漏一个整套测试就失败）；
只读熔断器场景矩阵：脏子模块、大小写别名产物、非法 UTF-8 文件名、符号链接等边界场景逐一覆盖（test/relay/read-only-tripwire.mjs）；
字节级一致性门禁：各 relay 共享的辅助函数必须字节相同，test/relay-parity.mjs毫秒级跑完即证明，漂移根本无法合入（设计动机见 docs/plans/relay-core-dedup.md）。

审查侧同样有纪律

安全不止在 relay 里。skills/claude-delegate/references/review-and-land.md 定义了审查者的操作手册：先看测试改动再信门禁（新增跳过、弱化断言先视为失败）、自己重跑真实门禁、touchedFiles只是最终 git 状态而非归因、超时后不要反射性git reset销毁未审查的工作树……把"AI 产出"当待证主张而非事实来对待。

总结：把"信任"变成"可验证"

delegate-skills 的信任模型可以浓缩成四句：

原则	落地方式
零依赖	Node 内置模块 + 单脚本，逐行可审计，供应链面≈0
零网络	无遥测、无凭据、简报走 stdin、产物进临时目录
永不提交	拒绝规则 + 强制禁用 + 失败提示，提交权永远在审查者
证据化声明	三态熔断器、fail-closed 配置审批、"跑了什么"逐条记录

它的哲学不是造一堵更高的墙，而是让每一道墙能被你看清、被证据验证、在失效时大声失败。对于任何打算把 AI 代理放进自己代码库的开发者，这套"先审后信"的设计都值得一读。 📖

延伸阅读：README.md（完整信任与验证章节）、CONTRIBUTING.md（四条不变量）、AGENTS.md（受控词汇与发布前检查单）。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析