Agent的权威来自上下文而非动作权限

企业级 AI 项目常把上下文当作一个提示词工程问题来对待：检索更多文档、添加更多记录，然后让模型自己理清楚。这是一种本末倒置的做法。

Agent 接收到的信息决定了它能推断什么、组合什么、披露什么。因此，Agent 的有效权限同时受两方面约束：信息范围决定了它能知道什么；操作权限决定了它能做什么。上下文管辖前者，能力控制管辖后者。

上下文并不授予调度权力、修改价格或执行交易的权限。它只是扩展了 Agent 能知道、推断和披露的内容，从而也扩展了它的实际影响力。

上下文过少也并非中立：被遗漏的约束条件、例外情况或依赖关系，可能使一条自信满满的推荐建议走向错误。因此架构层面的目标不是「最少上下文」，而是「最小充分上下文」。

我们花了大量时间定义操作权限：Agent 可以调用哪些工具、可以访问哪些系统、在变更生效前需要哪些审批流程。但信息权限同样值得同样的严谨对待。在 Agent 做出决策之前，架构必须明确它被允许看到哪些信息，以及它实际需要哪些信息来完成这个决策。

全量上下文默认方案并非中立

将每一条可用记录都发送给模型，看起来很安全——因为没有遗漏任何东西。但实际上，这会导致成本高昂、稀释相关信号、使决策更难审查，并且扩大了系统可组合的信息范围。

这并不意味着每种工作负载都需要复杂的治理层。而是说，每种工作负载都需要一个对比基准。

在 Token-Bleed R5 合成实验中，紧凑型治理筛选相比原始全量上下文填充，在固定本地配置上少用了 96.9% 到 97.9% 的 prompt token，且达到了更高的 F1 分数。公开记录包含了固定契约、预检、留存证据决策包以及哈希值。

更重要的发现是它的局限性。面对一个廉价的词法基准，治理筛选在留出集上消耗的 prompt token 是词法基准的 6.94 倍，超过了预先设定的上限三倍。词法路径在每个目录规模下 F1 分数均为 0.000，所以治理上下文在质量对比中完胜。即便如此预先注册的声明——治理以其成本赢得了对词法过滤的优势——并未成立。冻结的经济规则控制了判决结果；在采集后放松该上限会使结论失效。

这正是有用的架构证据应该做的事。它应该展示一种方法在哪里有效，以及在哪里还没有资格成为默认方案。

企业 Agent 架构需要一个上下文平面

EAA 设计应该在逻辑上分离四个职责：

连接平面：API、事件和数据服务将 Agent 与企业系统连接起来。

上下文平面：检索、分类、策略、溯源和路由，为当前决策组装最小充分且策略允许的信息集。

能力平面：权限和审批决定 Agent 接下来可以做什么。

证据平面：留存契约、来源引用、工具调用轨迹和人工决策，使结果可审查。

上下文平面不是数据库和模型之间的技术装饰品。它在 Agent 选择路径之前就决定了它知道什么。这使它成为一种权限控制。

Agent 的上下文是其权限的一部分。

一条实用的决策规则

对于每个 Agent 工作流，从满足决策质量要求且策略允许的最小复杂度上下文路径开始。

如果一个简单过滤器能捕获相关记录并产生可审查的决策，就使用它。

在以下情况下添加治理元数据：字段名含义模糊、业务定义重要、访问策略必须在模型看到数据之前执行、溯源会改变答案，或者证据链本身就是必需的。

将更丰富的路径与廉价基准进行对比。衡量质量、路由遗漏下的遗漏风险、prompt 成本、延迟以及维护治理层所需的工作量。

目标不是更多的治理。目标是决策可用的、且成本可辩护的上下文。

这改变了哪些行业工作流

在能源和公用事业领域，停电或维护异常 Agent 可能需要天气、负荷、资产、工作订单和开关约束上下文，以推荐是保持、重新安排还是升级时间窗口。它不应收到无限制的运营数据，也不应仅仅因为能组合出建议就获得调度权限——该权限必须单独授予、有明确边界并有证据支撑。

在消费品和零售领域，商业异常 Agent 可能需要门店、SKU、促销、库存、成本和服务上下文来推荐响应。它应使数据基础、置信度和所需审批人可见。除非该能力已在明确限制内单独授权，否则不应修改价格或交易条款。

这些不是通用聊天机器人问题。它们是涉及上下文、权限和证据的架构问题。

证据边界

R5 是一个合成命名端点运行时特征。它不是客户数据结果、生产 ROI 研究，也不是治理上下文总能击败简单过滤器的证明。原始报告保持私有，因为它包含主机标识符。

这条边界是结果的一部分，而不是脚注。企业 Agent 值得的证据，应该像描述其收益一样具体地描述其局限性。

---