Link Types
Link Type 定义对象之间的关系：员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。在 AIDC Ontology 中，Link 不只是数据建模的外键——它既是企业语义的事实陈述，也是跨部门授权与上下文遍历的依据。
Link Type 是两个 Object Type 之间关系的类型定义。每条 Link 实例都是一句可被 Agent 推理、可被权限系统校验的企业事实：谁属于谁，谁负责什么，谁服务谁。
什么是 Link Type
孤立的对象回答不了业务问题。"这个 lead 归谁跟进""这个决策基于哪些文件""这个 Agent 改动会影响哪些工单"——这些问题的答案全部存在于对象之间的关系里。Link Type 把这些关系从隐性约定变成显性定义。
参考 Palantir Foundry Ontology 的抽象，AIDC 平台中典型的关系包括：
- 归属关系 — 员工属于部门，Agent 属于部门 Cell，文件属于部门文件系统。
- 责任关系 — Agent 负责目录，工单分配给 Agent，每个根目录有唯一所有者。
- 服务关系 — 项目服务客户，工单跟进 lead。
- 影响关系 — 风险影响合同，决策引用证据文件。
每个 Object Type 的定义见 Object Types；改变对象与关系状态的受控通道见 Action Types。
Link Type 的结构
定义一个 Link Type 至少需要声明以下字段。和对象一样，Link 定义随 Ontology schema 一起做版本治理，由中央管理平面统一发布与回滚。
| 字段 | 说明 |
|---|---|
name | Link 的唯一标识，使用小写连字符命名，如 workitem-assigned-to-agent |
source | 源 Object Type，关系陈述的主语 |
target | 目标 Object Type，关系陈述的宾语 |
cardinality | 基数：1:1、1:N、N:1 或 N:N，决定关系的唯一性约束 |
properties | Link 自身携带的属性，如共享范围、生效时间、有效期 |
permission | 该 Link 是否构成跨边界读取授权，以及读取范围（摘要 / 字段 / 全量） |
mutation | 允许创建或删除此类 Link 的 Action Type 列表——Link 不可被直接写入 |
Link 实例的创建与删除只能通过 Action Type 提交（如 AssignAgent 建立工单与 Agent 的责任绑定），每次变更都进入 Action Log。这保证关系图谱本身也是可审计的。
核心 Link 参考（MVP）
基于 MVP 最小对象集（Department、Agent、File、WorkItem、Decision、Customer / Lead、ActionLog），第一阶段部署定义以下十个核心 Link Type。它们刚好覆盖一个跨部门任务闭环所需的全部关系。
| 名称 | 源对象 | 目标对象 | 基数 | 说明 |
|---|---|---|---|---|
agent-belongs-to-department | Agent | Department | N:1 | 每个 Agent 隶属唯一的部门 Cell，由此继承默认权限边界、文件系统范围与事件队列 |
agent-owns-file | Agent | File | 1:N | Agent 即文件管理者：一个 Agent 对一组目录与文件的结构、质量和更新负全责 |
file-belongs-to-department | File | Department | N:1 | 文件归属唯一部门文件系统（EFS 卷或 S3 prefix），是部门级隔离的物理基础 |
workitem-belongs-to-department | WorkItem | Department | N:1 | 工单创建于某个部门之下，决定谁能读取它、谁有资格被分配执行 |
workitem-assigned-to-agent | WorkItem | Agent | N:1 | 责任绑定：一个工单在同一时刻只有一个负责 Agent，通过 AssignAgent 建立或转移 |
workitem-serves-lead | WorkItem | Customer / Lead | N:N | 项目服务客户：一个工单可跟进多个 lead，一个 lead 也可被多个工单服务 |
decision-resolves-workitem | Decision | WorkItem | 1:1 | 工单的判断结果（go / no-go / hold）沉淀为 Decision 对象，工单由决策关闭 |
decision-references-file | Decision | File | N:N | 决策引用证据文件，保证每个判断都能追溯到具体材料而非"凭感觉" |
lead-owned-by-department | Customer / Lead | Department | N:1 | lead 由发现它的部门拥有；其他部门读取必须经过显式共享 |
actionlog-initiated-by-agent | ActionLog | Agent | N:1 | 每条审计记录绑定发起 Agent 及其版本，责任链可完整回溯 |
完整平台形态会引入更多对象（员工、合同、风险、设备等）及相应的 Link（员工属于部门、风险影响合同），但 MVP 阶段刻意保持关系图谱的稀疏——每条 Link 都必须能回答至少一个真实业务问题，否则不予建模。
Link 与权限
在三层权限模型（基础设施层 / 数据层 / 工具层）中，Link 属于数据层权限的核心机制。部门文件系统默认相互隔离：Marketing 的 Agent 默认看不到 Strategy 的任何对象与文件，反之亦然。打破隔离只有两条受控通道。
跨部门读取必须通过 Ontology Link 或显式共享对象。不存在第三条通道——没有"临时给个全局只读权限"，也没有"先拷一份过去"。任何不经过这两条通道的跨部门数据流动都视为越权。
两条通道的工作方式不同：
- 沿 Link 读取 — 当对象之间存在带授权语义的 Link 时，对端部门可以沿 Link 读取目标对象的摘要。例如 Strategy 的工单通过
workitem-serves-lead连接到 Marketing 的 lead，Strategy Agent 即可读取该 lead 的摘要视图，但读不到 Marketing 目录下的原始文件。 - 显式共享对象 — 对象所属部门通过
ShareContextAction 把对象（或其字段子集）共享给指定部门，可附带范围与有效期。共享本身会创建一条共享 Link 并写入 Action Log，因此"谁把什么共享给了谁"永远可查。
无论哪条通道，Policy & Identity Plane 都会在上下文生成时逐条过滤：不可访问的对象、字段、文件和工具不会出现在 Agent 的上下文包里。Agent 不是"被告知不要看"，而是"根本看不到"。详见 权限模型。
Link 的遍历与上下文路径
Agent 执行任务时不做全库搜索。Context Gateway 接到任务意图后，从目标对象出发沿 Link 遍历，生成最小上下文包中的"关系路径"——告诉 Agent 这个对象在企业语义中的位置，而不只是丢给它一堆孤立文件。
WorkItem#W-318 "评估 lead L-2041 合作价值"
├─ workitem-belongs-to-department ──► Department#strategy
├─ workitem-assigned-to-agent ─────► Agent#strategy-analyst-01
└─ workitem-serves-lead ───────────► Lead#L-2041
└─ lead-owned-by-department ──► Department#marketing
（跨部门：仅返回 ShareContext 授权的摘要视图）遍历遵循三条规则：
- 每一跳重新校验权限 — 关系路径不是授权的传递闭包。能看到 Link 的存在，不等于能看到 Link 另一端对象的全部内容；每跨一条 Link，策略平面都重新裁决可见范围。
- 深度受限 — 默认遍历两到三跳。更深的路径几乎总是意味着上下文过宽，Gateway 会截断并在上下文包中标注截断位置，由 Agent 按需追加请求。
- 返回摘要而非原始数据 — 路径上的对象以摘要形式进入上下文包；只有 Agent 对该文件有直接权限时，才会附带文件内容。
示例场景：Marketing Agent 在调研中发现一个新 lead，提交 CreateWorkItem 创建跟进工单，并通过 ShareContext 把 lead 摘要共享给 Strategy 部门。Strategy Agent 领取评估任务时，Context Gateway 沿上图路径生成上下文包；评估完成后通过 UpdateDecision 写入 go / no-go 决策，decision-references-file 把决策与证据文件连接起来。整个跨部门闭环中，没有任何一方获得对方文件系统的直接访问权。
设计准则
Link 建模最常见的失败模式是"过重"：试图一次性画出全企业关系大图，结果维护成本压垮使用价值。MVP 阶段遵循三条准则：
- 从问题出发，不从模型出发 — 每条 Link 必须对应至少一个真实业务问题（"这个 lead 归谁""这个决策基于什么"）。回答不了问题的 Link 是负债。
- 先对象级，后字段级 — 权限先按部门和对象粒度生效，字段级共享（
ShareContext的 field-list 范围）随实际需要逐步启用，避免权限过细导致系统不可用。 - 让 Link 进入演化闭环 — 当 Agent 反复因"关系缺失"而上下文不足时，这本身就是 Ontology 演化的信号：经过提案与审批后新增 Link Type，灰度验证后推广。参见 Evolution Loop。
相关阅读
- Object Types — Link 两端的对象类型定义
- Action Types — 创建与删除 Link 的唯一合法通道
- Action Log — 关系变更的完整审计记录
- Context Gateway — 基于 Link 遍历的最小上下文生成
- 权限模型 — 三层权限与跨部门边界的完整定义