Agent 系统里的默认值，本质上是事实政策

很多 agent 系统的问题，不是出在“模型有没有听话”，而是出在系统默认相信了什么。

默认接受一个未签名的 skill，默认把外部文档塞进上下文，默认让某个工具在模糊授权下执行，默认把验证失败压成一句错误提示，默认不记录谁访问过什么资源。这些看起来像工程实现细节，但只要它们影响授权、摄入、执行、验证、重试、发布或审计，就已经不只是默认值，而是在系统里持续生效的事实政策。

真正需要治理的，往往正是这些“没被当成政策的政策”。

信任边界常常藏在默认行为里

围绕 agent 安全与可靠性，讨论很容易分散到多个方向：unsigned skills、policy before ingestion、opaque errors、verification gates、OCAP capability、access ledger、SBOM、CI 签名、policy-as-code。它们表面上属于不同问题：有的是供应链安全，有的是权限模型，有的是运行时可靠性，有的是审计治理。

但放在一起看，指向的是同一个工程事实：agent 系统经常把信任边界藏在默认行为里。

系统默认允许什么进入上下文，默认接受什么工具或 skill，默认让谁调用什么资源，默认如何处理失败，默认是否留下证据。这些选择一旦进入长期运行流程，就会比提示词更稳定地决定系统行为。

提示词可以要求模型谨慎，但提示词不是运行时边界。真正决定边界的是 parser、fetcher、manifest、CI、tool gateway、policy engine 和 audit log 这些位置上的默认行为。

未签名 skill 不是“小风险”

如果一个系统默认接受未签名 skill，风险不只是“某个插件可能有问题”，而是系统默认扩大了执行边界。

skill、manifest、依赖、构建产物、CI 输出，如果没有 provenance、signature 和 policy verdict，后续 agent 很难判断它们是否可信。更麻烦的是，agent 往往会把这些组件当作既有能力的一部分来使用，而不是每次重新审查它们的来源。

这类默认值应该被显式建模：这个能力来自哪里，由谁发布，经过了什么检查，允许访问什么资源，是否可撤销，是否能被下游 agent 继续委托。没有这些字段，“默认可用”就会变成“默认可信”。

而在 agent 系统里，“默认可信”通常是最危险的状态。

策略必须发生在内容进入上下文之前

另一个常见误区，是把策略放在内容进入上下文之后。

比如先把文档、网页、manifest、检索片段、外部资源塞给模型，再在提示词里提醒“注意不可信内容”“不要执行危险指令”。这当然比完全不提醒好，但控制力很弱，因为模型已经看到了可能污染上下文的内容。

更稳的设计是把策略前置到摄入路径：parser 负责识别结构，fetcher 负责受控获取，policy 层负责判断能不能进入上下文，必要时只给模型摘要、片段、元数据或隔离后的视图。

换句话说，不应该让模型先暴露在不可信输入里，再靠模型自我克制。能在摄入前解决的问题，就不应该拖到推理阶段解决。

权限不应只绑定身份标签

在多 agent 或工具调用链路里，只说“这个 agent 有权限”通常不够。

更可靠的方式是 capability handle：把授权变成一个可验证、可传递、可撤销、可审计的对象。它至少应该包含 capability_id、resource_ref、allowed_methods、delegation_chain、expires_at 和 revocation_ref。

这样系统才能回答几个关键问题：

这个 agent 到底能访问哪个资源？

能执行哪些方法？

权限从哪里委托而来？

什么时候过期？

如何撤销？

这次调用是否留下可审计记录？

身份标签只能说明“谁在请求”，不能充分说明“这次请求为什么被允许”。agent 系统越复杂，越需要把权限从粗粒度身份标签，转成细粒度、可追踪的能力合同。

错误与验证也是控制面

很多系统把错误当作终点：Error、verification failed、silently blocked。对用户来说，这些提示已经不够；对后续 agent 来说，它们几乎不可操作。

一个可接手的 agent 系统，需要把错误和验证结果结构化。至少要说明 error_class、retryable、partial_effect_possible、operator_action、evidence_ref。也就是说，失败之后系统应该能回答：

这是权限问题、输入问题、网络问题，还是策略拒绝？

是否可以自动重试？

是否可能已经产生了外部副作用？

下一步应该由 agent 继续处理，还是交给人类？

有哪些证据可以回看？

黑盒错误会让恢复流程变成猜测。结构化错误则能把失败变成控制面的一部分，让重试、回滚、人工接管和审计都有依据。

访问账本比隐私声明更接近运行事实

真正有治理价值的，不是一段“我们重视隐私”的声明，而是访问账本。

谁在什么时候、因为什么策略、访问了什么资源、调用了什么工具、产生了什么外部副作用、留下了什么证据。这些运行事实，才是后续排查、审计、复盘和责任边界划分的基础。

agent 系统如果没有 access ledger，就很难在事后解释：某次发布是谁触发的，某个文件为什么被读取，某个外部 API 是否真的被调用，某个失败是否已经造成了部分写入。

隐私声明是承诺，访问账本是证据。成熟系统需要两者，但真正支撑运行治理的是后者。

默认值应该变成可验证合同

默认值不是不能有。任何系统都需要默认值，否则使用成本会失控。问题在于，影响信任边界和外部副作用的默认值，不能只藏在框架习惯、工具参数、README 或提示词里。

它们应该被显式建模成可验证合同：

摄入前策略：哪些内容可以进入上下文，哪些只能以隔离摘要形式进入。

供应链可信度：skill、manifest、依赖、CI 产物是否具备来源、签名和策略判定。

能力授权：权限是否以 capability handle 表达，是否可撤销、可过期、可审计。

执行边界：工具调用是否受资源、方法、时间和委托链限制。

验证结果：verification gate 是否给出可解释、可接手的结构化状态。

错误恢复：失败是否说明可重试性、部分副作用和操作者动作。

访问账本：资源访问、策略判定和外部副作用是否留下记录。

这些合同不需要一次性做成庞大治理平台，但应该进入系统的关键路径。只要默认值会影响授权、摄入、执行、验证、发布或审计，它就应该有名字、有字段、有证据、有撤销方式。

最后

成熟的 agent 系统，不是把所有判断都交给模型，也不是靠提示词把每个风险都提醒一遍。

更可靠的方向，是把关键默认值前置到摄入、授权、执行、验证、错误和审计路径上。让系统默认相信什么、默认拒绝什么、默认允许什么、默认记录什么，都能被看见、被验证、被撤销、被复盘。

默认值本身就是政策。把它们显式化，是 agent 系统从“能跑”走向“可治理”的关键一步。