它不是又一个数据库，也不是聊天记录，而是企业的“数字台账+组织说明书”：客户、合同、项目、审批——是什么、归谁管、可以对它做什么，都被一次性写清楚。AI 在这套定义之上取材、行动、留痕，而不是直接面对原始数据和原始权限。
OBJECTS · CONTEXT · ACTION · GOVERNANCE — ONE SEMANTIC LAYER FOR THE ENTERPRISE
把一个强模型接上企业数据库，再开一个聊天窗口——这是大多数“AI 落地”的真实形态。它能做漂亮的演示，却接不住真实业务：企业运行需要的不是一个会回答问题的工具，而是被授权、被审计、可复盘的行动。
把全部资料开放给 AI，它会接触到不该看的敏感信息；只给它几份孤立文件，它又看不懂业务之间的关联——比如“这家供应商对哪些合同至关重要”。没有一套统一的业务定义，企业只能在泄密风险和无效回答之间二选一。
表格和字段不会告诉 AI“客户”可以做什么、“合同”和“风险”如何关联、哪些资料归哪个部门管。这些常识散落在员工的脑子里和报表口径之间：每接入一个新系统、新员工或新 AI，都要把企业重新解释一遍。
聊天窗口给出的建议，要么靠人手工誊录进业务系统——慢、易错、无法规模化；要么让 AI 直接改数据、绕过一切审批。两种做法都回答不了同一个问题：AI 改动企业数据的边界在哪里？
AI 改了什么、为什么改、依据哪些资料、谁批准的——传统部署一项都答不上来。没有完整的动作记录，就没有责任边界，也没有让系统持续变好的依据。
Ontology 不只是一套数据模型，而是 AI 在企业里的资料调度台和操作合约：它决定 AI 能看到什么、能做什么，以及每一次行动如何被记录在案。
— DISTRIBUTED AGENT ONTOLOGY FRAMEWORK
Ontology 的第一层，相当于为企业建立一本权威台账：Object Type(对象类型)登记企业里真实存在的人与事——客户、合同、项目、设备、工单、员工、Agent、部门；Link Type(关系类型)写明它们之间的关系——员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。一次定义，全企业通用，每次修订都有版本可查。
数据库里只有表格，业务常识在人脑里：同一个“客户”在 CRM、ERP 和财务系统里是三个不一致的口径。每接入一个新系统、新员工或新 AI，都要把这套常识重新解释一遍——解释得不完整就出错，解释得太完整就泄密。
Object Type 与 Link Type 把企业现实一次性登记为带版本的台账：人、AI 和系统共用同一套对象与关系定义。跨对象的共性能力用 Interface(通用能力模板)表达——例如所有工单都可以被分配、评论、关闭——新对象一接入，就自动继承这些能力。
| 抽象 | 定义 | 企业示例 |
|---|---|---|
| Object Type | 现实世界实体或事件的类型定义 | 客户、合同、项目、设备、工单、员工、Agent、部门 |
| Link Type | 对象之间的关系定义 | 员工属于部门、项目服务客户、Agent 负责目录、风险影响合同 |
| Interface | 跨对象类型共享的能力形状 | 所有工单都可以被分配、评论、关闭 |
上面登记的对象、关系与动作，最终都落进一座标准的企业级数据库（PostgreSQL）。下图就是 AIDC Ontology 的库表结构——通用版本，不含任何客户数据：左列管「资料从哪来」，来源系统、来源文档、原始工件逐级登记，每条事实都可溯源；中间两列是台账本体，先定义对象与关系的类型，再登记一条条实例；右列管「怎么改」，动作合约写明谁可提交、是否要审批，每次执行连同审批人一起进操作台账。可以像在数据库工具里一样拖动表格、平移画布、滚轮缩放。
CreateWorkItem → 工单 W-318：创建跟进客户A 询价的工单——无需审批，写入运营域并通知负责人UpdateDecision → 合同 K-2210：提案「交付日期顺延 9 天」· 高风险 → 人工审批后受控写回（仅白名单字段）ShareContext → 客户A：把客户档案摘要授权给其他部门 · 跨部门审批 → 写引用而非复制全局视角——一套系统、三段结构：资料从左侧进来，登记成中间的对象与关系，由右侧的动作受控地改变。点 2 / 3 / 4 逐层走近。
对象视角——一组登记在册的示例对象：客户A、两份合同、一个工单、一位销售负责人。此刻它们彼此没有任何连接——只是 objects 表里的五行记录（虚线指回表）。悬停任意一张卡，展开它的全部建模维度，objects 表中对应的字段行同步点亮。（示例数据）
关系视角——同一组对象之间浮现连接：客户A 签了哪两份合同（signs · N:N）、被哪个工单跟进（serves · N:1）、归哪位负责人（responsible_for · 1:N）。悬停关系标签，上方橙框卡会展示这条连接在 links 表中的那一行——连接不是画出来的，是登记出来的。（示例数据）
动作视角——哪些动作能作用于这组对象：CreateWorkItem 生成工单 W-318；UpdateDecision 经人工审批后受控写回合同 K-2210；ShareContext 把客户A 的档案摘要授权给其他部门。光点沿动线循环演示，下方 ACTION TICKET 同步推进——对象只能经动作改变。（示例数据）
AI 接到任务时，不在全公司的资料里乱翻。它先向 Context Gateway(企业的资料分发台)说明任务意图、自己的身份、要处理的对象和打算执行的动作；分发台在台账里找到相关的对象与关系，按权限过滤掉它无权查看的内容，最后打包成一份恰好够用的资料包——既不过度暴露，也不让它盲人摸象。
聊天窗口里的资料是临时拼凑的：这次粘贴了哪些文件、漏掉了哪些背景，完全取决于操作的人。同样的问题，两个员工问出两种答案；敏感文件一旦进入对话，就再也收不回来。资料质量既不可控，也无法衡量。
资料由系统按任务、身份和权限统一配发，而不是由人临时拼凑。每个资料包都有版本号，事后可以回放检查——资料质量第一次变成可衡量、可优化的管理对象；检索与打包的规则本身，也会在使用中持续改进。
查资料有分发台，改数据有审批流。AI 需要改动业务数据时，不允许绕过流程直接改底层系统，必须通过 Action Type(受控动作)提交——创建工单、更新客户状态、发起审批、部署 Agent。每一次提交都记下发起者、Agent 版本、所用资料包版本和工具调用摘要，写入 Action Log(动作台账)，成为日后审计与复盘的依据。
ACT-0731 UpdateDecision status: committed
initiator: agent://06_operations/cell-supply
agent_version: v0.4.2
context_package: ctx-3f81 (v7)
tool_summary: ontology_query + file_diff + approval_request
approver: role://01_executive/owner # 高风险动作，人工批准“AI 的建议”和“系统的变更”之间，要么隔着一道人工誊录环节——慢、易错、无法规模化；要么干脆没有隔离——AI 拿着改库权限直接操作生产数据，出了问题既查不到原因，也分不清责任。两种形态都过不了审计。
Action Type 把“AI 可以做什么”收敛为一组白纸黑字的合约：参数、前置校验、影响范围、审批要求都写在定义里。低风险动作按既定策略自动放行，高风险动作强制人工审批。Action Log 让每一次变更都能追溯到具体的发起者、所用资料版本和批准人。
在 AIDC 的架构里，安全不是上线之后再加的一道闸，而是每一次执行都要同时通过的三道边界：基础设施层隔离运行环境，数据层管住对象与字段的访问，工具层限定 AI 能调用的能力。各部门的资料默认互相隔离，跨部门取用必须经台账中登记的关系或显式共享的对象。
| 层级 | 控制对象 | 典型机制 |
|---|---|---|
| Infrastructure | 运行环境与密钥 | AWS account / VPC / subnet / IAM role / KMS key 隔离 |
| Data | 对象、字段、关系、动作、文件 | Ontology 语义级权限，跨部门读取必须经关系或显式共享 |
| Tool | Agent 可调用的能力 | API、脚本、模型、部署动作白名单 |
传统做法把安全做成上线后的补丁：先让系统跑起来，再加网关、加审计、加合规检查。结果是安全与业务互相绕行——审计看不懂业务语义，业务为了效率绕过审计。AI 一旦进入，这种结构性矛盾被成倍放大。
权限与业务定义同源：数据层权限直接写在台账的对象、字段和关系上，审计天然读得懂业务。系统会演化，但红线不动——高权限基础设施策略、密钥管理、跨部门敏感数据共享规则、生产环境破坏性动作，永远保留人工或强策略审批。
示例场景：以下是一个虚构的演示场景，用于说明系统行为，不指向任何真实客户。设定：一家医疗设备制造商已部署 AIDC 平台，某个周一早上，其关键压力传感器供应商突然宣布停产。我们按可见性、模拟、执行、学习四个阶段，看同一套 Ontology 如何承载从发现问题到复盘改进的全过程——每个阶段对应上面概念框架的一个部分。
VISIBILITY · MAPS TO // 01 DATA
周一 08:14，采购部门的 AI 协作单元收到订阅的供应商事件：供应商 S-117 发布停产公告。没有人需要向它解释“这家供应商有多重要”——重要性早已登记在台账的关系里。它沿着关系一路核对：S-117 供应哪些组件，组件用在哪些产品上，产品被承诺在哪些带交付时限的合同里，合同又归哪条销售线负责。三十分钟后，管理层看到的不是一堆转发的群消息，而是一张完整的波及面清单。
EVENT supplier.disruption → SUPPLIER S-117 # 停产公告
S-117 ─SUPPLIES→ COMPONENT C-09 # 关键压力传感器
C-09 ─USED_IN→ PRODUCT P-03 · P-07
P-03 ─COMMITTED_IN→ CONTRACT K-2210 · K-2231 # 含 45 天交付 SLA
K-2210 ─OWNED_BY→ 10_sales / 大客户线SIMULATION · MAPS TO // 02 LOGIC
09:02，运营部门的 AI 协作单元向资料分发台申请资料：任务是“供应替代评估”，预计要执行的动作是“重排供应”(ReplanSupply)。分发台返回的资料包里有候选供应商档案、历史交付记录、受影响工单和相关合同条款摘要——没有财务密级文件，也没有与此无关的部门资料。AI 在台账上推演三个方案，每个方案的影响不是一句含糊的描述，而是“哪些合同的交付日期会移动多少天”。
| 方案 | 动作路径 | 交付影响(示例数据) | 审批要求 |
|---|---|---|---|
| A · 切换备选供应商 | 创建工单 → 资质验证 → 换源 | 2 份 SLA 合同各延后约 9 天 | 高风险 · 人工审批 |
| B · 部分设计替代 | 工程变更 → 重新认证 | 延后约 30 天，附加认证风险 | 高风险 · 人工审批 |
| C · 重排产线优先级 | 重排工单队列 | 非承诺订单延后，SLA 合同保住 | 中风险 · 策略批准 |
推演结论：方案 A 与 C 组合执行，影响最小、回旋余地最大。
EXECUTION · MAPS TO // 03 ACTION
10:40,AI 不直接修改 ERP。它提交三个受控动作：创建工单(备选供应商资质验证)、更新决策(推荐方案 A+C)、发起审批(高风险：涉及两份含交付 SLA 的合同)。审批人打开的不是一段聊天记录，而是一页结构化的决策依据：用了哪个版本的资料包、三个方案的推演对比、动作的影响范围。批准之后变更才生效，所有提交连同发起者、Agent 版本和资料版本一起写入 Action Log。
ACT-0712 CreateWorkItem status: committed
initiator: agent://06_operations/cell-supply · ctx-3f81 (v7)
ACT-0713 UpdateDecision status: committed
decision: 方案 A + C — 切换备选供应商并重排产线优先级
ACT-0714 RequestApproval status: approved (human)
reason: 影响 2 份含交付 SLA 的合同
approver: role://10_sales/owner · 决策依据: ctx-3f81 (v7)LEARNING · MAPS TO // 04 SECURITY & GOVERNANCE
三周后复盘，没有人需要凭记忆还原“当时发生了什么”。Action Log 回放显示：整个响应中等待最久的环节是人工审批(26 小时)，最大的资料缺口是备选供应商的资质文件不在系统里。演化闭环据此产出三个改进提案，经人工审批后先小范围试行：
BACKUP_FOR(备选供应商)——把口头上的“我们还有备胎”变成台账里查得到的事实；TriggerSupplierFailover(触发供应商切换)——把这次的处置路径沉淀为下次可一键发起的标准动作；下一次中断发生时，系统会比这一次更快——这正是 Ontology 与“项目制交付”的根本区别：能力沉淀在企业的台账里，而不是某个人的经验里。
自演化不是 AI 无限修改自己，而是一个受治理的改进闭环：任务失败、资料缺口、重复流程和跨部门协作需求被持续观察、诊断、提案、审批，先小范围试行并度量效果，然后才更新台账。允许演化的是提示词、检索规则、本部门的对象关系和操作手册；高权限基础设施策略、密钥管理、跨部门敏感数据共享规则和生产环境破坏性动作，永远保留人工审批。
第一阶段不需要建设全企业平台。AIDC 推荐的起步方式，是用两个部门跑通一个最小闭环——台账、权限、受控动作和审计链一个不少，但范围足够小，几周内就能看到全流程运转。七步起步清单：
例如战略与市场。范围小到几周可见效，又大到足以验证跨部门协作的真实价值。
各配一块独立的资料区(独立目录或独立存储前缀)，从第一天起就保持部门边界。
七类对象足够起步：部门、Agent、文件、工单、决策、客户/线索、动作记录。不做大一统建模。
创建工单、指派 Agent、更新决策、共享资料、发起审批——覆盖最常见的协作路径。
输入任务和身份，返回允许访问的对象、文件与动作——这就是 Context Gateway 的第一个版本。
每次执行都记录任务编号、资料包版本、动作编号、文件改动与工具摘要，从第一天起就可复盘。
市场单元发现线索，战略单元读取允许共享的摘要，生成去留决策，全程写入 Action Log。
起步阶段最常见的六类风险，在框架设计中都有对应的预案：
| 风险 | 对策 |
|---|---|
| 台账设计过重 | 从 6–8 类对象起步，不做大一统建模 |
| 权限切得过细，系统难用 | 先按部门和对象级授权，再逐步细化到字段级 |
| AI 自我演化失控 | 任何策略变更都必须有提案、审批与回滚 |
| 资料分发质量差 | 每个资料包都留档，可回放评估 |
| 成本失控 | 部门单元按需扩缩，低频任务用短生命周期执行环境 |
| 审计记录不可读 | Action Log 只记可复盘的摘要，不保存全部敏感资料 |
阅读完整的 Ontology 参考——Object Types、Link Types、Action Types、Interfaces 与 Action Log；或者直接从一次部署评估开始，让我们在你的真实流程里建立第一版企业台账。