Object Types

Object Type 是现实世界实体或事件的类型定义,是 Ontology 的最小语义单元。权限挂在对象上,上下文围绕对象组织,动作以对象为目标。本页定义 AIDC MVP 的七个核心对象类型。

什么是 Object Type

Object Type 定义一类现实世界实体或事件的语义形状:它有哪些属性、与其他对象有什么关系、可以被哪些 Action Type 改变、实现哪些 Interface。典型的 Object Type 包括客户、合同、项目、设备、工单、员工、Agent、部门。

在 AIDC 的语境里,Object Type 同时承担三重职责:

  1. 语义职责 — 让 Agent 用企业自己的语言理解任务:不是"一堆文件",而是"一个 WorkItem 关联三个 File,等待一个 Decision"。
  2. 权限职责 — 数据层权限挂在对象、属性、关系和动作上。授予 Agent 访问一个对象,就是授予一段被精确界定的上下文。
  3. 审计职责 — 每个对象的状态变更只能通过 Action Type 发生,因此对象的完整历史都可以在 Action Log 中回放。
// 与文件系统的关系

Object Type 不替代文件系统,而是为文件系统提供语义索引。文件仍然是组织的工作记忆(参见 Company Harness),对象层让 Agent 能沿关系路径定位、引用和授权这些文件。File 本身就是七个核心对象之一。

MVP 七个核心对象类型

AIDC 建议的最小 Ontology 从七个对象类型开始。它们覆盖一个最小闭环所需的全部语义:组织结构(Department、Agent)、工作记忆(File)、工作流(WorkItem、Decision)、业务实体(Customer/Lead)和审计(ActionLog)。以下属性表为参考实现,字段可按部署裁剪,但 id、所有权与时间戳字段不应省略。

Department组织单元

含义 — 拥有独立 Agent Cell、独立文件目录和权限边界的部门。Department 是部署的基本颗粒:每个部门一个 Agent Cell,一个独立文件目录或 EFS/S3 prefix。

属性类型说明
idstring全局唯一标识,例如 dept-strategy
namestring部门名称
file_rootstring部门文件系统根路径(目录或 EFS/S3 prefix)
owner_agentref:Agent负责该部门的 C-suite Agent
statusenumactive / suspended
created_attimestamp创建时间

关系 — 拥有多个 Agent 与 File;是 WorkItem 的归属边界;跨部门共享必须通过显式 Link 或 ShareContext 动作。

示例场景 — MVP 选择 Strategy 和 Marketing 两个部门,各自一个 Agent Cell 与独立目录,跨部门只共享 lead 摘要。

Agent执行主体

含义 — 在某个 Agent Cell 中运行、对特定目录和流程负责的 AI 执行主体。Agent 不是聊天窗口,而是有职责、有版本、有权限边界的组织成员(参见 Agent 即文件管理者)。

属性类型说明
idstring全局唯一标识,例如 agent-cmo-01
namestringAgent 名称
department_idref:Department所属部门
rolestring职责描述,对应目录的 AGENT.md
versionstringAgent 配置版本,Action 提交时绑定
permission_scopelist可访问的对象、目录与工具范围
statusenumactive / paused / retired
created_attimestamp注册时间

关系 — 属于一个 Department;负责若干 File(目录);被 AssignAgent 动作分配到 WorkItem;所有动作提交写入 ActionLog。

示例场景 — Marketing Agent 负责 09_marketing/ 目录,发现 lead 后通过 ShareContext 把摘要共享给 Strategy Agent。

File工作记忆

含义 — 部门文件系统中被纳入语义索引的文件或目录。File 对象让"文件"可以被引用、授权和审计,而不只是磁盘上的路径。

属性类型说明
idstring全局唯一标识
pathstring相对部门 file_root 的路径
department_idref:Department归属部门,决定默认权限边界
owner_agentref:Agent负责该文件的 Agent
doc_typeenumstrategy / sop / research / deliverable / log 等
versionstring版本号,存储层启用版本化与备份
updated_attimestamp最近修改时间

关系 — 属于一个 Department;由一个 Agent 负责;被 WorkItem 和 Decision 引用;Agent 对它的每次修改在 ActionLog 中留下 file diff。

示例场景 — 一份客户调研笔记进入 Marketing 目录后注册为 File 对象,Strategy Agent 只能读取经 ShareContext 授权的摘要版本。

WorkItem工作单元

含义 — 可被分配、跟踪和关闭的工作单元:任务、工单、请求。WorkItem 是工作流语义的载体,也是 Interface 的典型示例——所有 WorkItem 都可以被分配、评论、关闭。

属性类型说明
idstring全局唯一标识,即审计链中的 task id
titlestring任务标题
typeenumtask / ticket / request
department_idref:Department归属部门
assigneeref:Agent当前负责的 Agent,由 AssignAgent 动作写入
statusenumopen / in_progress / blocked / closed
priorityenumlow / normal / high
created_attimestamp由 CreateWorkItem 动作创建的时间

关系 — 由 CreateWorkItem 创建;通过 AssignAgent 分配给 Agent;引用若干 File 作为输入与产出;可以产出 Decision;全程动作记录在 ActionLog。

示例场景 — "评估某条 lead 是否值得跟进"被建为 WorkItem,分配给 Strategy Agent,关闭条件是产出一个 Decision。

Decision决策记录

含义 — 一次有明确结论、依据和责任人的组织决策。Decision 把"拍板"从聊天记录里拿出来,变成可引用、可追溯、可复盘的一等对象。

属性类型说明
idstring全局唯一标识
titlestring决策标题
outcomeenumgo / no-go / hold
rationaletext决策依据摘要,引用相关 File 与对象
decided_byref:Agent | human决策责任主体(Agent 或人类负责人)
context_package_idstring决策时使用的上下文包版本,保证可回放
statusenumdraft / final / superseded
decided_attimestamp决策时间

关系 — 由 WorkItem 产出;通过 UpdateDecision 动作变更;引用 File 作为依据;高风险决策需先经 RequestApproval;决策过程完整记录在 ActionLog。

示例场景 — Strategy Agent 读取共享的 lead 摘要后生成 go/no-go 决策,ActionLog 记录决策过程与所用上下文包。

Customer / Lead业务实体

含义 — 外部客户或潜在客户。这是 MVP 中唯一的外部业务实体,用于验证跨部门共享的受控通道:Marketing 发现,Strategy 评估,共享的只是允许范围内的摘要。

属性类型说明
idstring全局唯一标识
namestring客户或线索名称
stageenumlead / qualified / customer / churned
sourcestring线索来源渠道
owner_departmentref:Department归属部门,默认 Marketing
shared_summarytext允许跨部门读取的摘要字段,由 ShareContext 生成
statusenumactive / archived
created_attimestamp录入时间

关系 — 归属一个 Department;关联发现与评估两类 WorkItem;其去留由 Decision 决定;跨部门可见性由 ShareContext 动作控制。

示例场景 — Marketing Agent 发现一条制造业线索并录入为 Lead,Strategy Agent 只读取 shared_summary 字段完成评估(不虚构真实客户名)。

ActionLog审计对象

含义 — 一次 Action 提交的完整记录。ActionLog 的特殊之处在于它既是日志也是对象:可以被查询、聚合和分析,是审计、复盘与 Evolution Loop 的数据基础。

属性类型说明
idstringaction id,全局唯一
action_typeref:ActionType提交的动作类型
actorref:Agent | human发起者
agent_versionstring发起 Agent 的配置版本
task_idref:WorkItem关联的工作单元
context_package_idstring执行时使用的上下文包版本
target_objectref动作的目标对象
file_difftext文件变更摘要
tool_summarytext工具调用摘要
created_attimestamp提交时间

关系 — 记录所有 Action Type 的提交;绑定 Agent、WorkItem、目标对象与上下文包版本;中央日志短暂不可用时先写入本地审计缓冲,恢复后补发。

示例场景 — 上述 go/no-go 决策对应一条 ActionLog:action_type 为 UpdateDecision,附带 file diff 与工具调用摘要,可在复盘时完整回放。

// 审计可读性规则

ActionLog 只记录可复盘的摘要,不保存全部敏感上下文。审计链的目标是回答"谁、基于什么、做了什么",而不是复制一份完整数据库。

对象建模准则

Ontology 设计过重是最常见的风险,缓解方式是从 6-8 个对象类型开始,不做大一统建模。判断一个概念是否应该成为 Object Type,用下表对照:

该建对象不该建对象
会被某个 Action Type 作为目标的实体(如 WorkItem、Decision)只在单次任务中出现的一次性中间产物
承担权限边界的实体(如 Department、File)一个枚举属性就能表达的概念(如"优先级"应是 WorkItem 的属性)
需要被跨部门引用或共享的实体(如 Customer/Lead)纯展示用途的聚合视图(应由查询生成,不建对象)
需要审计历史和状态回放的实体(如 ActionLog)字段级即可表达的细节(先按部门和对象级权限,逐步再扩展字段级)
与其他对象存在稳定关系、需要沿关系路径检索的实体外部系统已是权威源、且不需要本地语义的实体(先以引用接入)
// 反模式

不要把数据库 ER 图整体搬进 Ontology。Ontology 服务的是 Agent 的上下文路由与操作合约,每个对象都应该对应一个真实的权限边界或动作目标;纯报表型实体留在数据仓库里。

命名规范

统一命名让 Agent 与人类读到同一套语义。AIDC 采用如下约定:

元素规范示例
Object TypePascalCase,单数名词;复合实体可用斜线表达同义对(文档中),实现层取主名WorkItemCustomerLead(文档中写作 Customer / Lead)
属性snake_case;时间戳以 _at 结尾;引用以 _id 结尾created_atdepartment_id
状态枚举小写、有限集合,状态机变更只能通过 Action Typeopen / in_progress / closed
Link Type小写动词短语,方向从源对象指向目标对象,详见 Link Typesbelongs_toassigned_toowns
Action TypePascalCase,动词开头,命名即意图,详见 Action TypesCreateWorkItemRequestApproval
InterfacePascalCase,描述能力形状而非实体,详见 InterfacesAssignableClosable
语义版本Ontology schema 整体使用 semver;破坏性变更升主版本并保留回滚路径ontology@1.4.0

相关阅读