Object Types
Object Type 是现实世界实体或事件的类型定义,是 Ontology 的最小语义单元。权限挂在对象上,上下文围绕对象组织,动作以对象为目标。本页定义 AIDC MVP 的七个核心对象类型。
什么是 Object Type
Object Type 定义一类现实世界实体或事件的语义形状:它有哪些属性、与其他对象有什么关系、可以被哪些 Action Type 改变、实现哪些 Interface。典型的 Object Type 包括客户、合同、项目、设备、工单、员工、Agent、部门。
在 AIDC 的语境里,Object Type 同时承担三重职责:
- 语义职责 — 让 Agent 用企业自己的语言理解任务:不是"一堆文件",而是"一个 WorkItem 关联三个 File,等待一个 Decision"。
- 权限职责 — 数据层权限挂在对象、属性、关系和动作上。授予 Agent 访问一个对象,就是授予一段被精确界定的上下文。
- 审计职责 — 每个对象的状态变更只能通过 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。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识,例如 dept-strategy |
name | string | 部门名称 |
file_root | string | 部门文件系统根路径(目录或 EFS/S3 prefix) |
owner_agent | ref:Agent | 负责该部门的 C-suite Agent |
status | enum | active / suspended |
created_at | timestamp | 创建时间 |
关系 — 拥有多个 Agent 与 File;是 WorkItem 的归属边界;跨部门共享必须通过显式 Link 或 ShareContext 动作。
示例场景 — MVP 选择 Strategy 和 Marketing 两个部门,各自一个 Agent Cell 与独立目录,跨部门只共享 lead 摘要。
Agent执行主体含义 — 在某个 Agent Cell 中运行、对特定目录和流程负责的 AI 执行主体。Agent 不是聊天窗口,而是有职责、有版本、有权限边界的组织成员(参见 Agent 即文件管理者)。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识,例如 agent-cmo-01 |
name | string | Agent 名称 |
department_id | ref:Department | 所属部门 |
role | string | 职责描述,对应目录的 AGENT.md |
version | string | Agent 配置版本,Action 提交时绑定 |
permission_scope | list | 可访问的对象、目录与工具范围 |
status | enum | active / paused / retired |
created_at | timestamp | 注册时间 |
关系 — 属于一个 Department;负责若干 File(目录);被 AssignAgent 动作分配到 WorkItem;所有动作提交写入 ActionLog。
示例场景 — Marketing Agent 负责 09_marketing/ 目录,发现 lead 后通过 ShareContext 把摘要共享给 Strategy Agent。
File工作记忆含义 — 部门文件系统中被纳入语义索引的文件或目录。File 对象让"文件"可以被引用、授权和审计,而不只是磁盘上的路径。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识 |
path | string | 相对部门 file_root 的路径 |
department_id | ref:Department | 归属部门,决定默认权限边界 |
owner_agent | ref:Agent | 负责该文件的 Agent |
doc_type | enum | strategy / sop / research / deliverable / log 等 |
version | string | 版本号,存储层启用版本化与备份 |
updated_at | timestamp | 最近修改时间 |
关系 — 属于一个 Department;由一个 Agent 负责;被 WorkItem 和 Decision 引用;Agent 对它的每次修改在 ActionLog 中留下 file diff。
示例场景 — 一份客户调研笔记进入 Marketing 目录后注册为 File 对象,Strategy Agent 只能读取经 ShareContext 授权的摘要版本。
WorkItem工作单元含义 — 可被分配、跟踪和关闭的工作单元:任务、工单、请求。WorkItem 是工作流语义的载体,也是 Interface 的典型示例——所有 WorkItem 都可以被分配、评论、关闭。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识,即审计链中的 task id |
title | string | 任务标题 |
type | enum | task / ticket / request |
department_id | ref:Department | 归属部门 |
assignee | ref:Agent | 当前负责的 Agent,由 AssignAgent 动作写入 |
status | enum | open / in_progress / blocked / closed |
priority | enum | low / normal / high |
created_at | timestamp | 由 CreateWorkItem 动作创建的时间 |
关系 — 由 CreateWorkItem 创建;通过 AssignAgent 分配给 Agent;引用若干 File 作为输入与产出;可以产出 Decision;全程动作记录在 ActionLog。
示例场景 — "评估某条 lead 是否值得跟进"被建为 WorkItem,分配给 Strategy Agent,关闭条件是产出一个 Decision。
Decision决策记录含义 — 一次有明确结论、依据和责任人的组织决策。Decision 把"拍板"从聊天记录里拿出来,变成可引用、可追溯、可复盘的一等对象。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识 |
title | string | 决策标题 |
outcome | enum | go / no-go / hold |
rationale | text | 决策依据摘要,引用相关 File 与对象 |
decided_by | ref:Agent | human | 决策责任主体(Agent 或人类负责人) |
context_package_id | string | 决策时使用的上下文包版本,保证可回放 |
status | enum | draft / final / superseded |
decided_at | timestamp | 决策时间 |
关系 — 由 WorkItem 产出;通过 UpdateDecision 动作变更;引用 File 作为依据;高风险决策需先经 RequestApproval;决策过程完整记录在 ActionLog。
示例场景 — Strategy Agent 读取共享的 lead 摘要后生成 go/no-go 决策,ActionLog 记录决策过程与所用上下文包。
Customer / Lead业务实体含义 — 外部客户或潜在客户。这是 MVP 中唯一的外部业务实体,用于验证跨部门共享的受控通道:Marketing 发现,Strategy 评估,共享的只是允许范围内的摘要。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 全局唯一标识 |
name | string | 客户或线索名称 |
stage | enum | lead / qualified / customer / churned |
source | string | 线索来源渠道 |
owner_department | ref:Department | 归属部门,默认 Marketing |
shared_summary | text | 允许跨部门读取的摘要字段,由 ShareContext 生成 |
status | enum | active / archived |
created_at | timestamp | 录入时间 |
关系 — 归属一个 Department;关联发现与评估两类 WorkItem;其去留由 Decision 决定;跨部门可见性由 ShareContext 动作控制。
示例场景 — Marketing Agent 发现一条制造业线索并录入为 Lead,Strategy Agent 只读取 shared_summary 字段完成评估(不虚构真实客户名)。
ActionLog审计对象含义 — 一次 Action 提交的完整记录。ActionLog 的特殊之处在于它既是日志也是对象:可以被查询、聚合和分析,是审计、复盘与 Evolution Loop 的数据基础。
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | action id,全局唯一 |
action_type | ref:ActionType | 提交的动作类型 |
actor | ref:Agent | human | 发起者 |
agent_version | string | 发起 Agent 的配置版本 |
task_id | ref:WorkItem | 关联的工作单元 |
context_package_id | string | 执行时使用的上下文包版本 |
target_object | ref | 动作的目标对象 |
file_diff | text | 文件变更摘要 |
tool_summary | text | 工具调用摘要 |
created_at | timestamp | 提交时间 |
关系 — 记录所有 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 Type | PascalCase,单数名词;复合实体可用斜线表达同义对(文档中),实现层取主名 | WorkItem、CustomerLead(文档中写作 Customer / Lead) |
| 属性 | snake_case;时间戳以 _at 结尾;引用以 _id 结尾 | created_at、department_id |
| 状态枚举 | 小写、有限集合,状态机变更只能通过 Action Type | open / in_progress / closed |
| Link Type | 小写动词短语,方向从源对象指向目标对象,详见 Link Types | belongs_to、assigned_to、owns |
| Action Type | PascalCase,动词开头,命名即意图,详见 Action Types | CreateWorkItem、RequestApproval |
| Interface | PascalCase,描述能力形状而非实体,详见 Interfaces | Assignable、Closable |
| 语义版本 | Ontology schema 整体使用 semver;破坏性变更升主版本并保留回滚路径 | ontology@1.4.0 |
相关阅读
- Ontology 总览 — 五个核心抽象与语义版本治理
- Link Types — 对象之间的关系定义
- Action Types — 改变对象状态的唯一合法路径
- Deployment MVP Playbook — 用这七个对象搭建最小闭环