Link Types

Link Type 定义对象之间的关系：员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。在 AIDC Ontology——企业的数字台账加组织说明书——中，关系不只是数据库里的外键，而是一句登记在册的企业事实：AI 据此理解业务全貌，权限系统据此裁决跨部门访问，审计据此追溯每一次变更。

// 一句话理解

把「谁属于谁、谁负责什么、谁服务谁」这些关系正式登记进企业台账。登记过的关系，AI 能看懂、权限系统能校验、出了问题能追溯——跨部门协作从「靠默契」变成「有据可查」。

什么是 Link Type

孤立的对象回答不了业务问题。「这个 lead 归谁跟进」「这个决策基于哪些文件」「这个 Agent 改动会影响哪些工单」——管理者每天在问的这些问题，答案全部藏在对象之间的关系里。Link Type 把这些关系从口头默契和个人记忆，变成全公司统一的显性定义，就像把多年的「惯例」正式写进岗位说明书和台账。

参考 Palantir Foundry Ontology 的抽象，AIDC 平台中典型的关系包括：

归属关系 — 员工属于部门，Agent 属于部门 Cell，文件属于部门文件系统。
责任关系 — Agent 负责目录，工单分配给 Agent，每个根目录有唯一所有者。
服务关系 — 项目服务客户，工单跟进 lead。
影响关系 — 风险影响合同，决策引用证据文件。

每个 Object Type 的定义见 Object Types；改变对象与关系状态的受控通道见 Action Types。

属性还是关系？

这是建模评审中最常见的判断题。属性描述对象自身的特征（客户的行业、规模、信用级），Link 描述对象之间的事实（客户由哪个部署服务）——Link 不是对象的「更深一层描述」，而是独立登记的一层企业事实。判定口诀只有一句：连接的那一端如果自己有状态、有归属、需要被管理，它就是对象，连向它的就该是 Link；如果只是一个不需要被管理的数值或文字，它就是属性。最典型的错误是把负责人姓名当文字属性存下来——人一调岗这条信息就失联了；正确做法是建一条指向 Agent 对象的责任关系，每个事实只登记一处，其余地方沿关系指过去。

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 目录下的原始文件。
显式共享对象 — 对象所属部门通过 ShareContext Action 把对象（或其字段子集）共享给指定部门，可附带范围与有效期。共享本身会创建一条共享 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。

关系何时升级为对象

有些关系不只是连接，它自己就承载业务信息。工厂与供应商之间隔着一份「供货合同」：有金额、有期限、要审批——这时正确的建模不是往「供货」关系上堆字段，而是把合同立为独立对象，两端各连一条关系：工厂 ↔ 供货合同 ↔ 供应商。这与 Palantir Foundry 的 object-backed link 同构：普通 link 本身不携带属性，关系需要承载信息时升格为中间对象（官方示例：员工与项目之间的「任职记录」对象，携带角色、起始日期、投入占比）。

升级判据——满足任意一条，关系就升级为中间对象：

有生命周期或状态 — 如共享授权有生效与过期；
要被审批或追责 — 如跨部门数据共享需要审批位；
携带两个以上属性 — 如任职关系有职级、起止日期、汇报线；
要被第三方引用 — 如「供货合同」既连接工厂与供应商，又被风险登记引用。

升级后的形态是「一个中间对象 + 两条简单关系」，每一层都干净：关系只负责连接，承载信息的事交给对象——对象有完整的状态、权限与审计能力。ShareContext 产生的共享授权正是这个模式：授权本身是对象，携带范围、有效期与审批记录。反向的提醒：升级有维护成本，不触发判据就不要升级——直连是常态，中间对象是例外。

新增 Link 前的评审清单

提案新增一条 Link Type 之前，建议对照以下清单逐项确认。它把上面的设计准则变成可执行的评审动作，适合作为 Ontology 变更提案的固定附件——任何一项答不上来，就说明这条关系还没想清楚。

业务问题 — 这条 Link 回答哪个真实业务问题？回答不了问题的关系不予建模。
两端对象 — 源对象与目标对象是否都已在 Object Types 中定义？不要为一条关系临时发明对象。
基数约束 — cardinality 是否反映真实业务规则？例如「一个工单同一时刻只有一个负责 Agent」必须是 N:1，而不是图省事的 N:N。
授权语义 — 是否声明了 permission 字段：这条 Link 构不构成跨边界读取授权？范围是摘要、字段还是全量？
变更通道 — 创建与删除走哪些 Action Types？Link 不可被直接写入，没有合法变更通道的关系等于失控。
审计可答 — 变更进入 Action Log 后，能否回答「这条关系是谁、在何时、为什么建立的」？