Interfaces

Interface 是跨对象类型共享的能力形状——一项能力（如“可被分配”）在公司层面只定义一次，所有业务对象按需声明实现。Agent 针对能力工作，而不是针对某个具体的对象类型工作：这让 Ontology 保持精简、Agent 逻辑保持复用、新业务对象以零改造成本接入。

// 一句话理解

Interface 定义的是“能力的形状”，不是“对象的种类”——好比企业里的通用作业规范：所有 WorkItem（工单）都可以被分配、评论、关闭，这三种能力不属于某一个对象类型，而属于实现了 Assignable、Commentable、Closable 接口的任何对象。Agent 把一项能力学会一次，就能操作所有具备该能力的对象。

什么是 Interface

在 AIDC 的 Ontology（企业共享的数字台账与组织说明书）五个核心抽象中，Object Type 回答“企业里有什么实体”，Action Type 回答“允许发生什么变更”，而 Interface 回答的是：哪些能力是跨对象通用的。它扮演的角色类似企业里的通用作业规范——规范一旦定稿，各部门、各类业务对象都按同一份规范执行，不再各写各的。

一个 Interface 由三部分组成：

共享属性Shared Properties

实现该接口的对象必须具备的属性，例如 Assignable 要求对象有 assignee 与 assigned_at 属性。属性是 Agent 读取对象状态的统一入口。

能力声明Capability Signatures

以方法签名风格声明的可执行能力，例如 assign(assignee: Agent | Employee)。能力声明只定义形状，不定义实现——实现由绑定的 Action Type 提供。

实现清单Implementing Object Types

声明哪些 Object Type 实现了该接口。实现清单由中央 Ontology 管理平面维护与版本化，部门 Cell 不能私自增删。

用伪代码表达，一个 Interface 大致是这样的形状（无需逐行阅读，关键是看到“能力与对象解耦”这件事）：

interface Assignable {
  property assignee: Agent | Employee
  property assigned_at: Timestamp

  action assign(assignee: Agent | Employee)   // bound to AssignAgent
  action unassign()                            // bound to AssignAgent (revoke)
}

object WorkItem implements Assignable, Commentable, Closable, Auditable
object Decision implements Assignable, Commentable, Closable, Auditable, Shareable

为什么需要 Interface

没有 Interface 的 Ontology 会很快出现两类退化——对企业来说，就是“同一套审批流建了三遍”和“每来一个新业务就重写一遍系统”：要么每个对象类型重复定义一套几乎相同的动作（WorkItem 有“分配工单”，Decision 有“分配决策”，Lead 有“分配线索”，语义相同、定义三份），要么 Agent 的执行逻辑与具体对象类型强耦合，新增一个对象类型就要重写一遍 Agent 的处理代码。Interface 同时解决这两个问题：

避免重复定义 — “可被分配”只定义一次。任何对象类型声明实现 Assignable，就自动获得统一的属性形状与动作入口，不需要为每个对象重新设计分配语义。
Agent 针对能力工作 — Agent 的任务逻辑可以写成“把所有分配给我的、尚未关闭的对象按优先级处理”，而不是“查询 WorkItem，再查询 Decision，再查询 Lead”。Context Gateway（受控的资料分发层）按接口检索对象，Agent 的同一段执行逻辑可以覆盖所有实现者。
新对象零成本接入 — 当 Ontology 新增一个对象类型（例如 Contract），只要它实现 Assignable 与 Commentable，现有 Agent 无需任何修改就能分配它、评论它。Ontology 的演化不会级联到每个 Agent Cell。
权限按能力授予 — 权限模型可以在接口粒度授权：“该 Agent 对本部门所有 Assignable 对象有分配权”，比逐对象类型授权更稳定、更可读，审计起来也更接近管理者真实的授权意图。

示例 Interface 参考

以下五个接口是 AIDC 建议的起步集合，覆盖了 MVP 七个对象类型的绝大多数通用能力。能力声明采用方法签名风格，括号内为输入，→ 后为提交的 Action Type。

Assignable可分配

对象可以被分配给一个 Agent 或员工，并追踪分配状态。能力：assign(assignee: Agent | Employee) → AssignAgent；unassign() → AssignAgent。共享属性：assignee、assigned_at。典型实现者：WorkItem、Decision、Customer/Lead。

Commentable可评论

对象可以挂接结构化评论，供人和 Agent 留下判断与上下文。能力：comment(body: Text, author: Agent | Employee) → AddComment；list_comments() → Comment[]。共享属性：comment_count、last_commented_at。典型实现者：WorkItem、Decision、Customer/Lead、File。

Closable可关闭

对象有明确的生命周期终点，关闭时必须给出结论。能力：close(resolution: Text) → CloseItem；reopen(reason: Text) → CloseItem (revert)。共享属性：status、closed_at、resolution。典型实现者：WorkItem、Decision。

Auditable可审计

对象的每次状态变更都写入 Action Log（全公司统一的操作台账），且历史可按时间回放。能力：history(range?: TimeRange) → ActionLogEntry[]；last_modified_by() → Agent | Employee。共享属性：version、updated_at。典型实现者：所有承担权限边界或被 Action Type 作为目标的对象——在 AIDC 框架中即全部七个 MVP 对象类型。

Shareable可共享

对象（或其摘要）可以通过受控通道跨部门共享。能力：share(target: Department, scope: summary | full) → ShareContext；revoke_share(target: Department) → ShareContext (revoke)。共享属性：shared_with、share_scope。典型实现者：File、Decision、Customer/Lead。跨部门读取必须通过 Ontology link 或显式共享对象，Shareable 就是“显式共享对象”的标准形状。

接口与 MVP 对象类型的实现矩阵如下（● = 实现）：

Object Type	Assignable	Commentable	Closable	Auditable	Shareable
`WorkItem`	●	●	●	●	—
`Decision`	●	●	●	●	●
`Customer/Lead`	●	●	—	●	●
`File`	—	●	—	●	●
`Agent`	—	—	—	●	—
`Department`	—	—	—	●	—
`ActionLog`	—	—	—	●	—

// 示例场景

Marketing Agent 发现一条新 lead，提交 CreateWorkItem 创建跟进工单。因为 WorkItem 实现了 Assignable，Strategy Agent 的“处理所有分配给我的 Assignable 对象”逻辑无需任何修改即可接手该工单；因为 Customer/Lead 实现了 Shareable，Marketing 可以只共享 lead 摘要而非完整档案，供 Strategy 生成 go/no-go 决策。

Interface 与 Action Type 的关系

Interface 与 Action Type 是声明与实现的关系：Interface 声明能力的形状，Action Type 是能力的受控提交通道——前者像岗位说明书里的“职责条目”，后者像走完审批流的“正式流程”。二者的分工可以概括为一张表：

维度	Interface	Action Type
回答的问题	这类对象能做什么	这次变更如何被允许、校验与记录
定义内容	共享属性 + 能力签名	输入、目标对象、前置权限、提交后果
面向角色	Agent 的任务逻辑与上下文检索	权限校验、审计与状态变更执行
审计关系	本身不产生记录	每次提交写入 Action Log
示例	`Assignable.assign(assignee)`	`AssignAgent`（MVP 五个 Action Type 之一）

执行链路上，Agent 调用接口能力时发生三步解析：

Agent 对一个 Assignable 对象调用 assign()——它不需要知道对象的具体类型。
Ontology 把该能力解析到绑定的 Action Type（AssignAgent），并按目标对象的具体类型加载校验规则与权限前置。
Action 提交、写入 Action Log，绑定发起者、Agent 版本与上下文包版本。

// 边界提醒

Interface 不是绕过权限的捷径。“对象实现了 Shareable”只意味着它具备被共享的形状；本次共享是否被允许，仍由 Policy & Identity Plane 按发起者身份、目标部门与对象权限逐次裁决。能力形状与能力授权是两回事——就像“岗位说明书写了可以审批”不等于“这一单已经批了”。

演化时的兼容性规则

Interface 位于 Agent 逻辑与对象类型之间，它的任何变更都会同时影响两侧。因此 Interface 的演化必须走 Evolution Loop 的受治理路径，并遵守以下兼容性规则：

变更类型	兼容性	处理方式
新增一个 Interface	兼容	直接发布；已有 Agent 与对象不受影响
对象类型新增实现某 Interface	兼容	纯增量变更；现有 Agent 自动获得对新对象的操作能力
Interface 新增可选属性或可选能力	兼容	新能力须有默认行为；旧版本上下文包仍可回放
修改已有能力的签名或语义	破坏	禁止原地修改；发布新版本接口（如 `Assignable v2`），旧版进入弃用期
移除能力，或对象类型撤销实现	破坏	必须有 proposal、approval 与 rollback 方案，公告弃用期后才能移除
收紧能力的权限前置	受控	属于策略变更而非 schema 变更，走 Policy Plane 审批，不改接口版本

// 治理规则

Interface 的版本由中央 Ontology 管理平面统一治理：每个上下文包与 Action 提交都绑定语义版本，保证历史可回放；schema 更新失败时回滚到上一稳定版本。Agent 可以提案新增或修改 Interface，但不能自动批准——接口是跨部门的公共合约，破坏性变更必须保留人工审批。

实践上，判断一个能力应该进 Interface 还是留在单个对象类型上，可以用一条简单准则：至少有两个对象类型需要同样的语义，才值得抽成接口。过早抽象会让 Ontology 设计过重——这与“从 6-8 个对象类型开始，不做大一统建模”是同一条纪律。

设计检查清单：一项能力该不该抽成 Interface

落地团队最常见的设计争论，是“这个能力要不要上升为公司级接口”。把上一节的准则展开，可以得到一份五问检查清单——全部回答“是”，才值得把能力抽成 Interface：

复用 — 至少有两个对象类型需要完全相同的语义吗？只有一个实现者的接口是过早抽象，应留在该对象类型上。
可执行 — 每个能力声明都能绑定到一个明确的 Action Type 吗？只定义形状、没有受控提交通道的能力无法被治理。
权限有意义 — 管理者会希望按这项能力授权吗？例如“该 Agent 对本部门所有 Assignable 对象有分配权”。如果说不出一个真实的授权场景，接口粒度可能选错了。
可审计 — 能力的每次调用都会经 Action Type 写入 Action Log 吗？无法留痕的能力不应进入公共合约。
有归属 — 中央 Ontology 管理平面愿意把它作为跨部门公共合约长期维护与版本化吗？没有归属的接口会在演化中失控。

这份清单的另一面同样重要：没有通过五问的能力，就让它留在单个对象类型上。接口数量不是 Ontology 成熟度的指标——精简、稳定、处处复用的接口集合才是。