DashClaw 审批门禁与审计策略

问题：Agent 的动作不该是隐式的

一个能调用 bash、写文件、访问云 API 的 agent，一旦它决定执行写库、rm、改生产配置这类外部操作，你其实只有两种选择：完全信任它，或者等它已经执行完再去救火。而很多 agent 默认行为是：模型觉得该这么做，就直接做了。中间没有"这一步风险有多大、谁应该拍板、出了事能不能复盘"的环节。

更麻烦的是事后：审计问"这个删库动作谁批准的、依据哪条规则"，你拿不出结构化证据，只能回答"大概是模型自己决定的"。

它怎么工作

DashClaw 的思路是在 agent 发出动作和外部系统执行动作之间插一层可编程的检查点：服务先拦截请求，按声明式策略评估，再决定放行、请求人工审批还是拒绝。

核心能力有三项：

• Enforce：策略用声明式规则描述，包括 risk thresholds、deploy gates、capability access rules 和 semantic checks，对每个动作执行，不依赖模型自觉。
• Approve：高风险操作可以卡在人工审批上，而不是直接执行。
• Audit：决策证据被保留成可重放形式，事后能回答"当时按哪条规则、基于什么上下文放行"。

集成方式是作为服务挂进你已有的框架：文档称可接入 Claude Code、Codex、Hermes Agent、OpenClaw、Claude Desktop 和 Claude Managed Agents，并提供 LangChain、CrewAI、AutoGen、LangGraph、OpenAI Agents 等框架集成，对 MCP 客户端同样支持。

适用边界

这套方案解决的是"动作发生之前的治理与事后证据"，它不是：

• 替代你的安全模型：策略本身要自己设计好，风险阈值、语义检查这些规则的质量直接决定效果。
• 自动纠错或回滚：证据可重放用于复盘，但恢复动作仍需你自己的工程。
• 对绕过 DashClaw 直接调用外部系统的代码有效：拦截发生在请求路径上，直连路径不受覆盖。

官方文档（dashclaw.io/docs）提供了完整参考；demo 仓库用于快速验证。接入前值得先想清楚：你要拦哪些动作、哪些值得人工审批、证据要留多久。