结构化拒绝与理由链

散文式拒绝为何辜负两类受众。

散文式拒绝，是模型为解释一个"不行"而写下的一句话。它同时辜负了两类受众。用户想知道该改什么——是请求本身被禁了，还是某个参数越了界，还是这个拦截只是暂时的？——而"这个我帮不了你"对这些一个都答不上，于是他们盲目重试，最坏的情况下靠反复试错学会绕开护栏。几周后在一次事件复盘里读到同一条拒绝的调查者，想要的是那句话永远给不了的东西：一个稳定的标识，说明哪一个控制触发了，好让他们能对它计数、跨会话相互关联、并向审查者证明它当时在生效。自由文本不可查询、也不稳定——同一个拦截，会在十个会话里被表述成十种说法。

更深一层的问题是，一条模型撰写的拒绝是一个被生成的产物，而不是一份"实际发生了什么"的记录。当拒绝的决定来自工具调用边界处的一个策略引擎——就是面向智能体的策略即代码里的那套模式——模型的道歉就是对那个决策的下游旁白，而旁白会漂移：它可能把一个硬性拒绝软化成"让我给你个别的方案"，或者编造一个策略从未给过的理由。对问责而言真正要紧的那条拒绝，是执行层产出的那一条。这正是护栏入门篇讲的同一个点：一个只会拦截的护栏是半成品；一个既拦截、又吐出一个清晰可读、枚举化裁定的护栏，才是你能运营的。

枚举化的拒绝原因分类。

解法是把拒绝原因做成一个枚举化的原因码——一个来自小的、封闭的、带版本集合的值——而不是一句话。2026 年的工具链已经在出这种形状。微软的 Agent Governance Toolkit 返回一个 PolicyDecision，其 action 字段取自一套固定词汇（放行 / 拒绝 / 审计 / 阻断），其 matched_rule 点名了触发的那条确切规则；那段人类可读的 reason 只是随行的呈现，而非那个标识。OATR 运行时鉴证提案（其 2026 年 3 月的 v1.2.0 修订版）走得更远，出了一套明确的枚举化拒绝原因码，好让一次被拒的鉴证用一个机器可比对的令牌说清为何，而不是一整段话。原语是那个枚举；散文只是它的一种渲染。

你并不需要一套庞大的分类——庞大反而是负债，因为每个码都是一份下游消费者所依赖的契约。那套最小可用的集合，把用户或调查者会区别对待的类别分开：

• 策略拒绝——一条规则明确禁止了这个动作或这些参数；原样重试还会再失败。这是 matched_rule 的情形。
• 超出范围——这个动作落在了本智能体被授予的能力之外，而非一条内容规则。出路是换一个智能体或做一次上报，而不是换个说法。
• 鉴证 / 身份失败——调用方无法证明自己是谁（OATR 的拒绝情形）。请求也许是合法的，但此刻无法被核验。
• 输入被拒——请求因其自身文本触发了一个内容或安全过滤器，与它所指向的工具无关。
• 不可用 / 失败拦截——决策点无法给出一个干净的裁定，网关默认为拒绝。这是暂时且可重试的，且它必须与一次真正的策略拒绝保持可区分，否则一次宕机就藏在了看起来像一条规则的东西背后。

最后那个区分，是团队最常搞错的一个：一个用户——或一个值班工程师——若对一条永久策略规则和一次瞬时 PDP 超时看到的是同一个不透明的"不行"，就分不清一个设计决定和一起事件。让这些码保持封闭且带版本：新增一个码是兼容的，但悄悄给一个既有的码重新赋义，会静默地弄坏建立其上的每一块仪表盘和每一条告警。

理由链与日志。

一个枚举化的码告诉你哪一个控制触发了。一条理由链告诉你它为何针对这个特定输入触发——那条导向裁定的、有序的评估链：哪些规则被考虑过、它们匹配了哪些字段、哪一个是决定性的。这是"已拒绝：策略拒绝"和"已拒绝，因为路径在 /workspace/.env 处匹配了敏感路径规则，此前已批准工作区规则未能匹配"之间的差别。码是标签；理由链是推导。

这与日志不是一回事，而这个区分是承重的。日志是一串为重构"发生了什么"而写下的事件——为体量、为回答"系统在 14:07 做了什么"而优化。理由链则为一个不同的问题而优化："你能不能向一个审视它的人证成这一个决策。"日志回答发生了什么；理由链回答这为何被拒绝。那句值得记住的话，出自命名了这个模式的从业者：日志服务于取证；理由链服务于受审视之下的问责。你可以拥有详尽的日志，却仍无法为哪怕一条拒绝辩护，因为日志记下了结果、却没有记下产出它的那份推理。

具体地说，理由链是一个附在决策上的小型结构化对象：那个枚举化的原因码、那条决定性规则、它匹配的输入字段（按名称和类别，见第 4 步）、当时在生效的策略版本、以及一个时间戳。它是有界的——一个决策、一条链——而日志是无界的，而正是这份有界让它可审视：审计人员读的是一条拒绝所产出的那一条链，而不是你的整份日志。这条链也是上一层的天然载荷。什么东西会被签名并哈希链接进一份防篡改的记录——好让它事后无法被悄悄编辑——是本组讲决策回执与审计那一篇的主题；这一篇止步于产出这条链，而不封存它。

可审计而不泄露。

理由链天生带着一个张力：要有用，它就得记下输入是什么，可输入或许恰恰就是这条拒绝存在所要保护的那个敏感之物。把触发了一条机密外泄规则的原始值记下来，你的问责记录就成了那个机密的第二份副本，如今就躺在一个更大范围的人能读到的审计存储里。把它整个抹掉，这条链又不可审视：审计人员分不清一次正确的拒绝和一次过宽的拒绝。解法是记下规则和输入的类别，而不是原始的敏感内容。

实践中：记下那条决定性规则是 sensitive_path、它匹配的是 args.path 字段、且该字段的类别是"凭证文件路径"——但用一个脱敏令牌或一个加盐哈希顶替字面的 /workspace/.env。这足够让审计人员确认正确的规则针对正确种类的输入触发了，也足够把同一类别的两次出现相互关联，而不至于让这条链本身成为一处泄露。那个检验是：一个对理由链存储有读取权限的人，能不能重构出这条拒绝所保护的那个机密？若能，你就是把暴露挪了个地方、而非把它关上了。

把整个论点放进一帧里——同一次被拒的写入，一边渲染成散文式拒绝（左），一边渲染成带一条脱敏理由链的结构化拒绝（右）：

PROSE REFUSAL (model-authored)     STRUCTURED REFUSAL + WHY-TRAIL
--------------------------------   --------------------------------
"I'm sorry, I can't help with      { "action": "deny",
 that request. Writing to that       "reason_code": "policy-denied",
 file isn't something I'm able       "matched_rule": "sensitive_path",
 to do. Let me know if there's       "why_trail": [
 another way I can assist!"            {"rule": "approved_workspace",
                                         "matched": false},
  -> not queryable                      {"rule": "sensitive_path",
  -> not stable across sessions           "matched": true,
  -> may drift from the real              "field": "args.path",
     policy decision                      "field_class": "credential-file",
  -> tells an auditor nothing             "value": "<redacted:sha256:9f2a…>"}],
                                       "policy_version": "v3",
                                       "decided_at": "2026-05-02T14:07:22Z" }

左边是用户看到的，作为呈现它没问题。右边是问责层保存的：枚举化的、可查询的、稳定的、可审视的、且不含它所保护的那个机密。留意结构化拒绝在这里不做什么——它不决定策略（那是策略引擎的活儿），也不签名或存储那份记录（那是回执层的活儿）。它只拥有一件事：把一个"不行"变成一个机器能读、审查者能信的原因和一条链。那道接缝又小又利——这正是重点。把那个枚举化的码和那条脱敏理由链做对，下游的一切，从一块运营护栏仪表盘到一份签名的审计日志，就都有了实实在在可读之物。