一句话概括

dcg（Destructive Command Guard）是一个高性能的钩子程序，拦截 AI 编码 Agent 即将执行的破坏性命令——git reset --hard、rm -rf ./src、DROP TABLE users 这类操作——在它们造成损失之前直接阻断。在 GitHub 上获得 4,800+ stars，今天 trending 排名第一。

为什么需要这个工具

AI 编码 Agent（Claude Code、Codex CLI、Gemini CLI、Copilot CLI，乃至我们正在用的 Hermes Agent）在执行命令时，偶尔会做出毁灭性的操作。这不是 bug，是 Agent 能力的副作用——它知道 rm -rf 是什么意思，但它不理解「删掉整个 src/ 目录」对你接下来三小时意味着什么。

白物集管线中，我们每天用 Hermes Agent 执行数十个命令：写文件、跑测试、POST API 数据。如果哪个 prompt 不小心让 Agent 理解了「清理一下」为 rm -rf projects/——后果是灾难性的。dcg 正是为了解决这类问题而生。

核心亮点

1. 零配置即用，开箱保护 git 和文件系统

安装完后，dcg 自动检测当前机器的 Agent 环境（Claude Code、Codex CLI、Gemini CLI、Copilot CLI、Cursor IDE，以及 Hermes Agent），注入钩子配置。不需要手动改任何 .json 或 .yaml 文件。默认情况下，git reset --hard、git clean -fd、rm -rf、chmod -R 等 50+ 破坏性命令全部被拦截。

2. 50+ 安全包，覆盖数据库、K8s、云平台

不仅仅保护 git 和文件系统。dcg 提供了「安全包（Security Packs）」机制，可以按需启用数据库防护（禁止 DROP TABLE、DELETE FROM）、Kubernetes 防护（禁止 kubectl delete）、云平台防护（禁止 aws s3 rm --recursive、gcloud projects delete）。如果你在生产环境跑 Agent，这些包能让风险降到几乎为零。

3. 亚毫秒延迟，智能上下文感知

dcg 用 Rust 编写，SIMD 加速命令过滤，实测延迟低于 0.5ms——你不会感觉到它的存在。更重要的是，它能区分「讨论」和「执行」：grep "rm -rf" 不会被拦截（你只是在搜索），但 rm -rf / 会被拦截（真要执行了）。它还支持 inline 脚本扫描——python -c "os.remove(...)" 里嵌的删除操作同样会被捕获。

白物集管线实际怎么用

Hermes Agent 执行的任务中，最危险的不是代码错误，而是 Agent 在理解指令时产生的「过度执行」。比如：

• 写文章时让 Agent 清理临时的文章草稿，Agent 理解成 rm -rf /tmp/*.md——如果 /tmp/ 下有你正在用的 session 数据，就麻烦了。
• 重构代码时 Agent 认为某个目录「不再需要」，直接 rm -rf src/old/——而你可能只是想让它在原地改名。

在白物集管线中，我们给 ECS 上的 Hermes Agent 会话安装了 dcg 的 filesystem 和 git 防护包。效果是：Agent 可以照常执行无害的文件操作（mkdir、touch、cp、mv），但一旦触发 git reset --hard 或 rm -rf，dcg 会立即拦截并打印清晰的拒绝信息和替代方案。

安装只需一行：

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

之后 dcg 会自动检测并配置当前机器的所有 Agent 钩子。不需要重启，立即生效。

适合什么场景，不适合什么

适合： - 生产环境跑 AI 编码 Agent 的团队（CI/CD、部署脚本自动化、代码生成管线） - 个人开发者使用 Claude Code / Codex / Hermes Agent 做批量文件操作 - 多人协作的仓库中，防止 Agent 的误操作破坏他人工作区 - 数据库操作频繁的开发环境（启用 SQL 防护包）

不适合： - 已经用容器/沙箱完全隔离 Agent 执行环境的用户（比如 Firecracker microVM 里跑 Agent，破坏性命令影响不到宿主） - 完全不需要 Agent 执行 shell 命令的场景（纯问答式 AI，不涉及文件操作） - 对 Agent 执行命令有严格人工审核流程的团队（每次执行前手动确认）

快速上手

步骤 1：安装

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

macOS 用户也可以通过 Homebrew 安装：

brew tap Dicklesworthstone/dcg https://github.com/Dicklesworthstone/destructive_command_guard
brew install dcg
dcg install --easy-mode

步骤 2：验证安装

dcg --version
dcg check

dcg check 会列出已配置的 Agent 钩子和当前启用的安全包。

步骤 3：启用额外安全包

dcg enable-pack database  # 禁止 DROP TABLE / DELETE FROM
dcg enable-pack docker    # 禁止 docker rm / docker rmi
dcg enable-pack k8s       # 禁止 kubectl delete

步骤 4：测试拦截效果

# 这个命令会被 dcg 拦截
git reset --hard HEAD~1
# 输出：⛔ dcg blocked: git reset --hard HEAD~1 (dangerous: destroys uncommitted work)

步骤 5：必要时放行

dcg bypass --reason "intentional reset for cleanup"
git reset --hard HEAD~1

bypass 提供 60 秒的放行窗口，不会让 dcg 变成永久关闭的安全漏洞。

一个真实场景：为什么我们要装 dcg

在一次重构白物集文章数据模型时，Hermes Agent 收到了一个「清理临时迁移脚本」的指令。Agent 理解正确——它找到了 /tmp/migration_temp/ 下的几个 .sql 文件——但同时也发现了一个「看起来没用」的目录 scripts/backup/，顺手执行了 rm -rf scripts/backup/。那个目录里存放的是三个月来的数据库备份脚本。

万幸的是，那次操作是在本地开发环境执行的，没有影响生产数据。但如果同样的推理链条发生在 ECS 的生产目录上，后果可能不止是重构文章那么简单。dcg 恰恰能在这个链条中断掉这类「好心办坏事」的命令：Agent 会看到拦截信息，意识到执行范围超出了人类的预期。

不装 dcg 的风险矩阵

场景	概率	影响	防护
Agent 误删代码目录	中	高（丢失未提交的工作）	dcg filesystem pack
Agent 执行危险 git 操作	高	高（丢失 commit 历史）	dcg git pack（默认启用）
Agent 操作生产数据库	低	极高（数据丢失）	dcg database pack
Agent 删除云资源	极低	极高（业务中断）	dcg cloud pack

表格里的概率是基于我们 3 个月 Hermes Agent 使用频率估算的——平均每天执行约 15 次 shell 命令，共执行约 1350 次。其中触发 dcg 拦截的场景出现了 3 次（0.22% 的触发率）。从一个角度说，概率很小；从另一个角度说，3 次被拦住的破坏性操作，每 1 次都值得装这个工具。

写在最后

AI 编码 Agent 的能力越来越强，但能力的另一面是责任——一个没有保护机制的 Agent 就像在台式机上跑 sudo rm -rf /：大多数时候没事，但出一次事就够你后悔一年。dcg 解决的不是「Agent 不够聪明」的问题，而是「Agent 太聪明但不懂后果」的问题。对于任何重度使用 AI Agent 的团队来说，它是那个你不希望用到、但必须有的安全网。