生产 Agent 最该盯的回归，不是答案漂移，而是 authority surface 漂移

type

Post

status

Published

date

Apr 26, 2026

slug

pub_topic_20260426_agent_authority_surface_001_notion_001

summary

生产 Agent 的高危回归通常不是回答质量下降，而是委托、fallback、重试和技能安装让 authority surface 在无感中扩大。真正该治理的是权限声明、技能签名、授权感知 eval 和可见的 authority trace。

在生产系统里，错误答案通常还能被发现，权限边界的变化却很容易被忽略。一个回答错了，用户会抱怨，评测会掉分，日志里也往往能留下明显痕迹；可如果 Agent 只是多调用了一次本不该调用的工具、多读取了一段本不该继承的上下文，或者在 fallback 过程中换了一个行动路径，系统未必会立刻报警。

这也是为什么很多团队对“答案漂移”很敏感，却对“authority surface 漂移”反应迟钝。前者影响可见结果，后者影响系统权力。真正到了出事那一刻，大家才会发现：问题不是它突然变笨，而是它早就在不该扩张的地方慢慢扩张了。

多 Agent 协作经常被描述成角色分工：一个负责规划，一个负责执行，一个负责校验。这个叙事本身没有错，但它容易掩盖一个更现实的问题：委托链条里的信任，很多时候并不是协议级保证，而只是默认假设。

Agent A 把任务交给 Agent B，通常隐含着几层没有被明确验证的前提：B 会忠实执行、会如实汇报、不会顺手把上下文扩展到别的用途、也不会在工具调用时顺带继承本不该拿到的权限。只要这些前提没有被设计成可验证边界，多 Agent 协作就天然带着 authority leakage 的风险。

换句话说，委托本身不是问题，问题在于委托之后谁还能看见任务、工具、证据和预算是怎样被传递的。如果这些信息在链条里变得不可见，那么所谓协作效率，很多时候只是拿边界清晰度换出来的。

很多生产评测体系已经很重视成功率、回答质量和失败恢复，这是必要的，但还不够。因为系统的授权边界并不会只在显式权限表里变化，它还会藏在 fallback、自动重试、环境切换、本地修复这些流程细节里。

当一个任务第一次失败后，系统也许会自动换工具、换执行环境，或者先修复再继续行动。表面看，这只是为了提高完成率；可一旦这些动作没有被纳入授权感知的评测，系统就在“成功率维持不变”的幻觉里悄悄偏离了原来的边界。

所以真正成熟的 eval，不该只问“它做成了吗”，还要问“它此刻为什么仍被允许这样做”。只验证结果，不验证授权，会让很多高危回归在数据面板上显得过于平静。

Agent 生态越成熟，skill、plugin、tool package 这些扩展形式就越常见。它们看起来像功能增长的捷径，但从治理角度看，skill 从来不只是“装一个新能力”这么简单。

如果安装一个 skill，实质上等于执行一段陌生代码、接受一套陌生指令、开放一组陌生工具，那么它就已经进入了供应链安全的范畴。没有签名、没有 provenance、没有权限清单、没有审计轨迹的技能市场，本质上是在把扩展性直接兑换成不可见的攻击面。

很多团队会把这类问题拆开看：有的放到工具安全，有的放到插件审核，有的放到提示词管理。但从生产治理的视角看，这些其实都属于同一个问题：authority surface 正在通过扩展机制被不断放大，而系统却不一定知道它到底放大到了哪里。

如果把 authority surface 当成一等对象来管理，系统设计就会发生变化。技能不该只是“能不能调用”，还应该自报来源、权限和预期用途；委托不该只是“任务有没有下发”，还应该看见工具、证据和预算如何传递；评测不该只看结果，还要检查授权是否仍然成立。

这里尤其值得单独拿出来的是预算治理。healing budget 和 retry budget 不能混记，因为“按原授权再试一次”和“先修复环境再继续行动”不是同一种权力。前者更接近重复执行，后者已经带着边界变化的可能。任何一次从本地修复跨回再次行动的时刻，都应该在 trace 里可见。

这听上去像额外成本，但它其实是在给系统补上生产成熟度最容易缺失的那一层解释能力：不仅知道做了什么，也知道为什么还能做、经由哪条链路做、为此消耗了什么预算、跨过了哪些边界。

生产 Agent 的下一阶段，不该只继续追逐更高的回答质量，而应该把治理重点转向 authority quality。输出错了，通常还有机会在事后修正；边界漂了，往往要等到真正造成后果，组织才会意识到风险早就积累在那里。

一个真正成熟的 Agent 系统，不只是能力更强，而是能清楚回答几个问题：它为什么还能做这件事？是经由哪个 skill 做的？当前动作继承了哪些权限？用了多少预算？哪一次修复、重试或委托改变了它的行动边界？

当这些问题都变得可见，生产级 Agent 才算真正开始从“能跑起来”走向“值得被信任”。这也是为什么，与其把精力全压在答案漂移上，不如先盯住 authority surface 漂移——因为后者才是最容易在系统看似稳定时，悄悄积累成大问题的地方。