Context Gateway
Context Gateway 是 Agent 获取上下文的唯一受控入口。Agent 不做全库搜索，而是按任务意图、身份、部门、目标对象和预期 Action Type 请求最小可用上下文包——不过宽，不过窄，每个包可记录、可回放、可审计。
Context Gateway 位于六层架构的 L3，在 Policy & Identity Plane（L2）之上、Department Agent Cells（L4）之下。它根据任务、身份、权限和 Ontology 查询生成最小可用上下文：Ontology 决定"什么相关"，策略平面决定"什么可见"，Gateway 把两者组装成一个带版本号的 context package 交给 Agent。
为什么 Agent 不能全库搜索
企业 AI 落地最直觉的做法，是把全部企业数据灌进一个向量库，让 Agent 自由检索。这个做法在演示里成立，在组织里不成立——因为它必然落入两难之一：
上下文过宽：Agent 获得不必要的敏感资料，授权无法成立，任何一次检索都是一次潜在的越权。上下文过窄：Agent 只看到孤立文件，无法理解企业对象之间的关系，任务质量随之崩塌。两个方向上的失败，根因相同——检索范围由相似度决定，而不是由语义和权限决定。
| 失败方向 | 典型表现 | 直接后果 |
|---|---|---|
| 上下文过宽 | 全库向量检索把合同金额、薪酬、客户明细等无关敏感内容召回进 prompt | 权限边界形同虚设，无法对 Agent 做任何有意义的授权与审计 |
| 上下文过窄 | Agent 只拿到关键词命中的孤立文件，看不到"项目—客户—合同"这类关系链路 | Agent 无法理解对象在企业语义中的位置，输出不可靠，人工接管率升高 |
Context Gateway 的答案是把"检索"换成"路由"：Agent 声明它要做什么、以什么身份做、对哪个对象做，由 Gateway 依据 Ontology 找到相关语义子图，再由策略平面按三层权限裁剪，最后生成刚好够用的上下文包。范围由语义和权限决定，而不是由 embedding 相似度决定。
六步流程
一次完整的上下文请求—执行—提交闭环分为六步。前四步发生在中央（Gateway 与策略平面），后两步发生在部门 Agent Cell 本地：
-
Agent 提交上下文请求
输入：任务意图、身份、部门、目标对象和预期 Action Type。输出：一次结构化的上下文请求。Agent 必须先声明"我是谁、我要对哪个对象做什么"，而不是抛出一个自由文本检索词——预期 Action Type 让 Gateway 能提前判断这次任务需要哪些上下文、将触发哪些权限检查。
-
Policy & Identity Plane 过滤
输入：候选集合，加上请求者的身份与策略。输出：裁剪后的可访问集合——不可访问的对象、字段、文件和工具被逐项移除。过滤依据是权限模型的 Data 层与 Tool 层：对象级、字段级、关系级、文件级、工具级，逐层收窄。
-
Gateway 生成 context package
输入：裁剪后的可访问集合。输出：一个带版本号的最小上下文包，内容包括对象摘要、关系路径、相关文件、历史 action log 和可执行动作（详见下节）。版本号让这个包成为可审计对象：之后任何动作都能回溯到"基于哪个版本的上下文"。
-
Agent 在本地执行
输入：context package。输出：执行结果写回本部门文件系统与事件总线——而不是直接写企业状态。Cell 在自己的隔离环境里完成思考与产出，过程产物落在部门私有文件系统，结果通过 Event Producer 发布。
-
受控 Action 提交
输入：执行结果中需要改变企业状态的部分。输出：一次 Action Type 提交，绑定发起者、Agent 版本和上下文包版本，写入 Action Log。改变企业状态必须走这条通道，不允许绕过审计直接改底层表。
Context Package 里有什么
Context package 不是一堆检索片段的拼接，而是一个有固定结构的合约对象。五个组成部分各自回答 Agent 执行任务所需的一个问题：
| 组成部分 | 内容 | 回答的问题 |
|---|---|---|
| 对象摘要 | 目标对象及相关对象的受控摘要：类型、关键属性、当前状态——经过字段级裁剪，而非完整记录 | 我在操作什么 |
| 关系路径 | 目标对象在 Ontology 中的关系链路，如"项目—服务—客户—签订—合同" | 它在企业语义中处于什么位置 |
| 相关文件 | 按权限裁剪后与任务相关的文件引用与片段，范围由策略决定而非检索器决定 | 我可以依据哪些材料 |
| 历史 action log | 与目标对象相关的历史动作摘要：谁在何时对它做过什么 | 之前发生过什么，我会不会重复或冲突 |
| 可执行动作 | 该身份在该对象上被允许提交的 Action Type 清单 | 我被允许做什么 |
每个 context package 都有版本号。Agent 之后提交的任何 Action 都必须绑定上下文包版本——审计因此能回答"这个决定是基于哪个版本的上下文做出的"，而不只是"做了什么"。
注意第五项：可执行动作清单把"能做什么"显式化为操作合约。Agent 不需要猜测自己的权限边界，越权动作在上下文层面就不存在，而不是提交后才被拒绝。
质量评估：记录每一个包，用评估器回放
上下文路由质量差是这套架构的关键风险之一：Gateway 给的包过宽是安全问题，过窄是质量问题。对应的缓解手段只有一个——让每一次路由决策本身变成可评估的数据：
- 记录 — 每次生成的 context package 连同请求参数一起带版本号持久化，Cell 侧在本地缓存（如
context/packages/目录），中央侧归档。 - 回放 — 评估器用相同的请求参数重放历史路由，对比包内容与最终任务结果：任务失败时，是材料缺失（过窄）还是噪声过多（过宽）？
- 度量 — 持续收集任务成功率、失败原因、上下文缺口和人工接管点，把"包的质量"变成可观测指标，进入 L6 Observability 层。
- 演化 — Gateway 的检索和压缩规则属于允许自演化的对象，但每次变更必须走演化闭环：proposal、approval、灰度发布到单个部门 Cell、对比指标后再推广，且保留 rollback。
同时为了让审计可读，Action Log 只记录可复盘的上下文摘要与包版本号，不保存全部敏感上下文——回放时按版本号重建，而不是把敏感内容复制进日志。
失败模式与降级
Gateway 是中央组件，但它的短暂故障不应让全公司停摆。降级策略的原则是：本地低风险任务继续，跨部门读取与高风险动作暂停，审计链永不中断：
| 失败模式 | 降级行为 |
|---|---|
| 中央 Context Gateway 短暂不可用 | Cell 基于本部门 Context Index 处理低风险本地任务，高风险动作暂停等待恢复 |
| Ontology schema 更新失败 | 回滚到上一稳定版本，Gateway 继续以稳定版本提供路由 |
| Event Bus 延迟 | 本地 action buffer 保留状态，恢复后补发，消费端幂等 |
| 中央日志短暂不可用 | Local Audit Buffer 保留本地审计链，恢复后异步汇入 Action Log，不产生审计缺口 |
| 上下文包质量退化（过宽 / 过窄） | 通过包记录与评估器回放定位问题，经演化闭环修正检索与压缩规则后灰度发布 |
降级期间，Cell 只能依赖本部门 Context Index——这个索引本身被权限边界裁剪过，天然不会越权。任何跨部门读取与企业状态变更都必须等待 Gateway 与策略平面恢复。可用性永远不以越权为代价。
完整的冗余设计与各层故障的降级策略，见可靠性与降级。
相关阅读
- 六层架构总览 — Gateway 在整体架构中的位置（L3）
- Agent Cell — 上下文请求的发起方与执行方
- 权限模型 — 过滤步骤所依据的三层权限
- Ontology 总览 — Gateway 查询的企业语义层
- Action Log — 包版本与动作绑定形成的审计链