Context Gateway
Context Gateway 是 Agent 获取上下文的唯一受控入口——可以把它理解为企业的“机要档案室”：Agent 先说明“我是谁、要对哪个对象办什么事”，档案室按任务意图、身份与权限配发一份刚好够用的资料包。不过宽、不过窄，每一次发放都有版本号，可记录、可回放、可审计。
不要让 AI 在全公司资料里自由翻找。AIDC 在企业资料与 AI 之间设了一道受控的“发放窗口”：按任务和身份配发刚好够用的材料，多一页不给、少一页不行，且每一次发放都登记在案——资料不外泄，任务不缺料，事后随时可复盘。
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。改变企业状态必须走这条通道，不允许绕过审计直接改底层表。
示例场景：一次合同续约的资料发放
以下用一个典型任务把六步流程串起来（示例场景，非真实客户数据）：销售部的 Agent 接到任务——为客户 A 的年度合同准备续约建议草案。
- 声明任务 — Agent 提交结构化请求：“我是销售部续约 Agent，目标对象是客户 A 的合同，预期动作是生成续约建议草案。”
- 圈定相关 — Gateway 查询 Ontology，沿“客户—签订—合同—关联—项目”的关系链路圈出候选资料：合同条款摘要、历史服务记录、该合同上的过往动作。
- 裁掉不可见 — 策略平面逐项过滤：其他客户的合同、财务部的成本明细、任何薪酬信息都不在该身份的可见范围内，整体移除。
- 发包执行 — Agent 拿到带版本号的资料包，在销售部 Cell 本地起草建议；草案落在部门私有文件系统，不直接改任何企业记录。
- 受控提交 — 草案确认后，以一次 Action Type 提交进入审批，绑定 Agent 版本与资料包版本，写入 Action Log——审计链就此闭合。
在这个示例里，Agent 自始至终“看不见”其他客户的合同与任何敏感财务数据——不是被提醒“不要看”，而是这些内容从未进入它的上下文。越权在资料层面就被消除，而不是依赖 Agent 的自觉。
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 与策略平面恢复。可用性永远不以越权为代价。
完整的冗余设计与各层故障的降级策略，见可靠性与降级。
上线前检查清单
在把任何 Agent 接入企业资料之前，决策者可以用下面五个问题检验“资料入口”是否真正受控。任何一项答不上来，都意味着授权与审计还停留在口头承诺：
- 唯一入口 — Agent 获取企业资料是否只有 Gateway 一条通道？有没有绕开入口的“旁路检索”？
- 请求留痕 — 每一次资料请求是否记录了任务意图、身份与目标对象？
- 包可回溯 — 对任意一次 AI 动作，能否回答“它当时基于哪个版本的资料包”？
- 权限先于检索 — 资料范围由权限模型裁剪决定，还是由相似度排序决定？
- 降级有边界 — 中央组件故障时，是否仍能保证“可用性不以越权为代价”？
相关阅读
- 六层架构总览 — Gateway 在整体架构中的位置（L3）
- Agent Cell — 上下文请求的发起方与执行方
- 权限模型 — 过滤步骤所依据的三层权限
- Ontology 总览 — Gateway 查询的企业语义层
- Action Log — 包版本与动作绑定形成的审计链