把 Agent 规则变成 PR：用 gnt 在执行前检查高风险动作
让编码 Agent 读文档、改代码，通常还不至于失控；真正难的是它开始触及退款、删除数据、给客户发消息或调用内部系统时，团队怎样把“这件事需要谁批准”变成可执行的规则。把判断写在提示词里，既无法审阅，也很难说明某次操作为何被放行。
gnt 提供了另一种实现：把组织规则保存在连接仓库的 rules/ 目录中，以 Markdown 和 YAML frontmatter 表示；规则通过合并 Pull Request 生效。Agent 在执行风险动作前，经由 MCP 调用 check_action，得到 allowed、blocked 或 needs_human 之一，并能拿到命中的规则说明。这使“审批”从散落的聊天指令，变成 Git 历史里可追溯、可复审的一部分。
它不是替你判断业务是否正确的万能安全产品。更准确地说，gnt 是一层动作前的规则检索与裁决接口：当没有已批准规则、检索失败或检查不能完成时，默认返回 needs_human，把不确定性显式留给人工处理。
为什么把规则放进 Git
很多团队已经用 PR 管理代码，却把 Agent 的操作边界放在 Wiki、聊天记录或某个管理后台。这样会出现三个实际问题：规则修改有没有经过评审？当前 Agent 用的是哪个版本？一次拒绝或升级是谁的决定？
Git 原生的规则库把这些问题映射到已有流程：文件改动有 diff，合并记录承担批准动作，规则 frontmatter 可保存负责人、来源、批准人、批准时间、PR 编号和版本。比如一条退款规则可以这样表达：
--- title: 超过 500 美元的退款必须由经理确认 status: approved confidence: 0.91 owner_id: finance-team tags: [refunds, finance] version: 1 approved_by: jane@example.com approved_at: 2026-07-21T14:03:00Z pr_number: 142 --- 任何超过 500 美元的退款，在发出前需要经理确认。
这里的金额、负责人和示例邮箱只是演示数据，不是 gnt 预置策略。真正有价值的是：规则正文、审批元数据与 PR 一起版本化。团队可以把它用于退款、客户消息、数据删除等高影响动作，但必须自己定义触发条件和授权边界。
从本地规则到可调用的 MCP 检查
gnt 的 CLI 包为 @gnt-ai/cli，项目 README 要求 Node.js 版本不低于 22.13。首次连接 GitHub 仓库的典型路径如下：
node --version npm install -g @gnt-ai/cli gnt login gnt connect github gnt init gnt prebrain
gnt init 会在本地建立示例 rules/ 目录；gnt prebrain 用于扫描来源、提取候选规则并打开草稿 PR。不要把最后一步理解成自动批准：项目文档明确把“合并该 PR”定义为批准动作。因此，开始时应只给它接入低风险、可审阅的来源，先观察候选规则的准确度，再扩大范围。
规则被批准后，Agent 侧不应自行猜测是否可做，而应在动作之前调用 MCP 工具。gnt 公开列出了五个 MCP 工具：check_action、search_rules、get_rule、list_skill_packs 与 get_skill_pack。其中最关键的 check_action 会返回裁决、原因、引用规则和检索到的规则数量；返回结构类似：
{
"verdict": "blocked",
"reason": "退款金额超过阈值，且没有经理确认",
"cited_rules": [
{
"id": "refund-approval-threshold",
"title": "超过 500 美元的退款必须由经理确认"
}
],
"rules_retrieved": 3
}
集成方应把 blocked 视为停止信号，把 needs_human 视为进入人工队列的信号，而不是改写提示词、重试几次直到拿到允许结果。allowed 也不代表任意请求都安全：它只表示当前已批准规则覆盖了该动作描述。动作描述过于含糊、规则范围过宽，都会削弱这道门的意义。
设计时先解决四个边界问题
第一，规则的粒度。 不要从“Agent 可以处理财务”这种笼统声明开始。更可靠的做法是把动作、对象、阈值和所需凭据拆开，例如“退款”“金额超过某阈值”“需要经理确认”。细粒度规则更容易审核，也更容易在拒绝时解释。
更进一步，check_action 的输入应由业务层在真正调用外部接口前构造，并把关键上下文带进去：动作类型、目标对象、金额或影响范围、已有授权编号。不要只传“处理退款”这样的抽象句子，否则检索到的规则可能正确，却无法判断这一次请求是否越过阈值。反过来，也不要把完整客户资料、访问令牌或无关的原始对话直接塞进检查请求；规则判断所需的最小上下文，应由业务系统先做脱敏与裁剪。
第二，升级路径。 gnt 的 needs_human 是故障安全的默认结果，但团队仍要定义它落到哪里：工单、值班队列还是特定审批人；人工确认后如何留下新的规则或证据。没有闭环，Agent 只会从“自动执行”退化为“频繁卡住”。
一个实用做法是区分两种升级：单次例外只附着在当前业务工单中，由拥有底层权限的人完成；可复用的政策变化则必须更新 rules/ 文件并走 PR。这样不会把一次性的救火授权误写成永久放行规则，也能让 gnt gaps 列出的未覆盖查询成为补全规则库的待办，而不是绕过门控的理由。
第三，来源与隐私。 gnt prebrain 的默认提取模式是云端；README 说明源文本会直接发送到 Anthropic API，或在配置后发送到 Vercel AI Gateway 的零数据保留路径，而不是发送到 gnt 自己的服务器。若规则来源含敏感内容，应先审查这一数据流；文档还提供针对本地 Ollama 的 --mode local 选项。候选规则仍需要走 PR 审批，不能因来源“看起来可信”而跳过人工复核。
第四，自托管的现实边界。 该项目以 Apache-2.0 发布，并说明支持自托管；不过当前 gnt login 的浏览器登录页面属于托管 Web 应用，CLI 没有独立 device-code 或手工设定密钥的登录命令。准备自托管时，要先读官方自托管文档，并把这一登录链路作为部署设计的一部分，而不是等上线后才发现缺口。
把检查接入业务动作，而不是只装一个 MCP 服务
规则系统最容易失败的地方不是规则语法，而是集成位置不对：如果 Agent 已经调用退款、邮件或删除接口，再异步记录一次 check_action，它只剩审计价值。调用顺序必须是“收集必要上下文 → 检查 → 根据裁决分支 → 执行业务动作 → 记录结果”。底层服务的权限也不能因为有规则层就放宽；仍应使用最小权限账号、服务端授权和幂等键，避免同一个被批准的请求在重试中执行两次。
对每次裁决，建议将规则版本、引用规则 ID、裁决和实际结果关联到业务请求 ID。这样排查时可以区分三类问题：规则没有覆盖、规则覆盖但输入描述不足、规则允许而下游系统执行失败。前两类应回到规则库与集成代码修复；最后一类则属于业务系统的可靠性处理，不应该被误解为“规则引擎做错了”。
适合什么场景
gnt 最适合已经采用 PR 流程、且 Agent 要跨越“建议”进入“执行”的团队：例如客服 Agent 发消息前查询批准的措辞与金额规则，运维 Agent 执行危险变更前检查变更窗口，内部自动化在删除或外发数据前请求明确的授权依据。
它不适合替代权限系统、密钥管理或审计平台。实际部署中仍应让底层 API 使用最小权限凭据，把 check_action 放在业务操作之前，并记录请求、裁决和最终执行结果。规则层解决的是“按什么组织约束来决定”，不是绕过身份认证、网络隔离或服务端权限控制。
如果团队已经被散乱的 Agent 提示词和口头审批拖慢，可以先选择一个窄场景：把一类高风险动作写成两三条规则，要求所有例外经 PR 合并后才生效，再观察 gnt gaps 输出的未覆盖查询。这样既能检验规则是否可用，也能避免一开始把复杂业务政策全部自动化。