// WHY ONTOLOGY

Ontology 是让企业
安全、可控、有效地使用 AI 的
中央系统。

它不是数据库，也不是聊天记录。它把企业的对象、关系、动作、权限和历史决策组织成一个可推理、可执行、可审计的语义层——模型在这个语义层之上工作，而不是直接面对原始数据和原始权限。

OBJECTS · CONTEXT · ACTION · GOVERNANCE — ONE SEMANTIC LAYER FOR THE ENTERPRISE

查看概念框架 → Ontology 参考文档
4
概念框架部分 / Data · Logic · Action · Security
3
权限层级 / Infra · Data · Tool
7
演化闭环步骤
100%
Action 审计覆盖
00问题 / THE GAP

"模型 + 数据库 + 聊天窗口"，
不构成企业 AI。

把一个强模型接上企业数据库，再开一个聊天窗口——这是大多数"AI 落地"的真实形态。它能做演示，却无法承担真实业务：因为企业运行需要的不是回答，而是被授权、被审计、被复盘的行动。

  1. 上下文的两难：过宽，或过窄

    给 Agent 全库访问，它会接触不必要的敏感资料；只给它孤立文件，它又看不到企业对象之间的关系，无法理解"这家供应商有多重要"。没有语义层，这个两难无解——你只能在泄露风险和无效回答之间选择。

  2. 数据库里没有语义

    表和外键不会告诉模型"客户"可以做什么、"合同"和"风险"如何关联、哪些字段属于哪个部门。这些语义散落在员工脑子里和 BI 口径之间，每接入一个新 Agent，都要重新解释一遍企业。

  3. 动作不受控

    聊天窗口的输出要么需要人来手工转译成系统操作，要么被直接接上写库权限、绕过一切审批。两种形态都无法回答同一个问题：AI 改变企业状态的边界在哪里?

  4. 无法审计，就无法复盘

    AI 改了什么、为什么改、基于什么上下文、谁批准的——传统部署回答不了任何一项。没有完整的动作日志，就没有责任边界，也没有让系统变好的依据。

//判断

Ontology 不只是数据模型，而是 Agent 的上下文路由器和操作合约：它决定模型能看到什么、能做什么、以及每一次行动如何被记录。

— DISTRIBUTED AGENT ONTOLOGY FRAMEWORK

01对象与关系 / DATA

先把企业现实，
建模成对象与关系。

Ontology 的第一层是对企业现实的类型化建模：Object Type 定义现实世界的实体与事件——客户、合同、项目、设备、工单、员工、Agent、部门；Link Type 定义它们之间的关系——员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。一次定义，全企业复用，语义带版本治理。

FIG. 01 — OBJECT & LINK GRAPH SIGNS DELIVERS CONTAINS AFFECTS BELONGS_TO RESOLVES OWNS_DIRECTORY ASSIGNED_TO CUSTOMER 客户 CONTRACT 合同 PROJECT 项目 RISK 风险 WORKITEM 工单 DEPARTMENT 部门 EMPLOYEE 员工 AGENT 自治执行单元
FIG. 01 — Object Type 定义实体，Link Type 定义关系。Agent 与员工、部门、工单一样，是被建模的一等对象：它的职责、权限与归属在语义层中显式可查，而不是隐含在某段提示词里。
// THE ENTERPRISE CHALLENGE

企业落地挑战

数据库里只有表和外键，语义在人脑里：同一个"客户"在 CRM、ERP 和财务系统里是三个不一致的口径。每接入一个新系统、新员工或新 Agent，都要把这套隐性语义重新解释一遍——解释得不完整，就出错；解释得太完整，就泄露。

// HOW THE SYSTEM SOLVES IT

系统如何解决

Object Type 与 Link Type 把企业现实一次性建模为带版本的语义层：人、Agent 和系统共享同一套对象定义与关系定义。跨对象的共性能力用 Interface 表达——例如所有 WorkItem 都可以被分配、评论、关闭——新对象接入即继承既有能力。

抽象定义企业示例
Object Type现实世界实体或事件的类型定义客户、合同、项目、设备、工单、员工、Agent、部门
Link Type对象之间的关系定义员工属于部门、项目服务客户、Agent 负责目录、风险影响合同
Interface跨对象类型共享的能力形状所有 WorkItem 都可以被分配、评论、关闭
02上下文 / LOGIC

上下文不是检索，
是路由。

Agent 执行任务时不做全库搜索。它向 Context Gateway 提交任务意图、身份、目标对象和预期 Action Type；Gateway 查询 Ontology 找到相关对象、关系与动作，经 Policy & Identity Plane 过滤不可访问的对象、字段、文件和工具，最终生成一个最小可用上下文包——不过宽，不过窄，刚好够用。

FIG. 02 — CONTEXT GATEWAY AGENT CELL 发起上下文请求 · 任务意图 · 身份 / 部门 · 目标对象 · 预期 Action Type CONTEXT GATEWAY 上下文路由器 1 · ONTOLOGY QUERY 检索相关对象、关系、动作 2 · POLICY FILTER 过滤不可访问对象、字段、工具 3 · PACKAGE BUILD 压缩为最小可用上下文包 CONTEXT PACKAGE 最小可用上下文包 · 带版本 · 对象摘要 · 关系路径 · 相关文件 · 历史 Action Log · 可执行动作 // 被该设计排除的两种失败模式 × 全库搜索 — 上下文过宽 Agent 接触不必要的敏感资料 × 孤立文件 — 上下文过窄 看不到对象之间的企业关系
FIG. 02 — Agent 提交意图与身份，Gateway 经语义检索、权限过滤、压缩打包三步，返回带版本号的最小上下文包。Agent 在本地执行，结果写回本部门文件系统与事件总线。
// THE ENTERPRISE CHALLENGE

企业落地挑战

聊天窗口里的上下文是临时拼装的：这次粘贴了哪些文件、漏掉了哪些背景，完全取决于操作的人。同样的问题，两个员工问出两种答案；敏感文件一旦进入对话，就再也无法收回。上下文质量既不可控，也不可度量。

// HOW THE SYSTEM SOLVES IT

系统如何解决

上下文按任务、身份和权限由系统生成，而不是由人临时拼装。每个上下文包都有版本号，可以被回放和评估——上下文质量第一次成为可度量、可优化的工程对象。检索与压缩规则本身，也是演化闭环的优化对象。

Context Gateway 架构文档 →
03动作 / ACTION

改变企业状态，
必须经过受控动作。

读是路由，写是合约。Agent 需要改变企业状态时，不允许绕过审计直接改底层表，必须通过 Action Type 提交——创建工单、更新客户状态、触发审批、部署 Agent。每一次提交都绑定发起者、Agent 版本、上下文包版本和工具调用摘要，写入 Action Log，沉淀为可分析、可复盘的对象。

FIG. 03 — ACTION PIPELINE × 直接改写底层状态 — 被系统阻止 PROPOSAL Agent 生成动作提案 POLICY CHECK 策略与权限校验 ACTION TYPE 受控提交 STATE CHANGE 企业状态变更 ACTION LOG initiator · agent_version · context_package_version · tool_calls_summary · timestamp · result 每一次提交都沉淀为可分析、可复盘的对象 审计 · 复盘 · 演化闭环的输入
FIG. 03 — 动作提案经策略校验后，通过 Action Type 受控提交才能改变企业状态；绕过审计的直接写入被系统阻止。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   # 高风险动作,人工批准
// THE ENTERPRISE CHALLENGE

企业落地挑战

"AI 建议"和"系统变更"之间，要么隔着一个人肉转译环节——慢、易错、无法规模化；要么干脆没有隔离——Agent 拿着写库权限直接操作生产数据，出了问题既找不到原因，也分不清责任。两种形态都无法通过审计。

// HOW THE SYSTEM SOLVES IT

系统如何解决

Action Type 把"AI 可以做什么"收敛为一组显式声明的合约：参数、前置校验、副作用、审批要求都在定义中。低风险动作按策略自动通过，高风险动作强制人工审批。Action Log 让每一次状态变更都可回溯到具体的发起者、上下文版本和批准人。

Action Types 参考 → Action Log 参考
04治理与安全 / SECURITY

安全贯穿系统，
而不是外挂在系统上。

在 AIDC 的架构里，安全不是部署完成后再加的一层网关，而是每一次执行都必须同时穿过的三层边界：基础设施层隔离运行环境，数据层控制对象与字段访问，工具层限定 Agent 可调用的能力。部门文件系统默认隔离，跨部门读取必须通过 Ontology link 或显式共享对象。

FIG. 04 — THREE-LAYER PERMISSION MODEL
L1 · INFRASTRUCTURE
AWS account / VPC / subnet / IAM role / KMS key — 运行环境隔离
L2 · DATA
Ontology object / property / link / action / file — 语义级权限
L3 · TOOL
API / 脚本 / 模型 / 部署动作 — Agent 可调用能力边界
AGENT EXECUTION 每一次执行，都同时落在三层边界之内。
FIG. 04 — 三层权限模型：中央策略只定义能力边界，不直接操控每个部门的执行细节；Permission Adapter 把中央策略转换为各 Agent Cell 本地的文件、API 与工具权限。
层级控制对象典型机制
Infrastructure运行环境与密钥AWS account / VPC / subnet / IAM role / KMS key 隔离
Data对象、字段、关系、动作、文件Ontology 语义级权限，跨部门读取必须经 link 或显式共享
ToolAgent 可调用的能力API、脚本、模型、部署动作白名单
// THE ENTERPRISE CHALLENGE

企业落地挑战

传统做法把安全做成部署后的补丁：先让系统跑起来，再加网关、加审计、加合规检查。结果是安全与业务逻辑互相绕行——审计看不懂业务语义，业务为了效率绕过审计。AI 一旦进入，这种结构性矛盾被成倍放大。

// HOW THE SYSTEM SOLVES IT

系统如何解决

权限与语义同源：数据层权限直接定义在 Ontology 的对象、字段和关系上，审计天然理解业务语义。系统会演化，但红线不动——高权限 IAM 策略、KMS 与 secrets 管理、跨部门敏感数据共享规则、生产环境破坏性动作，永远保留人工或强策略审批。

权限模型文档 →
05示例场景 / SCENARIO

一次供应商中断，
四个阶段。

示例场景：以下是一个虚构的演示场景，用于说明系统行为，不指向任何真实客户。设定：一家医疗设备制造商已部署 AIDC 平台，某个周一早上，其关键压力传感器供应商突然宣布停产。我们按可见性、模拟、执行、学习四个阶段，看同一套 Ontology 如何承载从感知到复盘的全过程——每个阶段都对应上面的一个概念框架部分。

  1. VISIBILITY · MAPS TO // 01 DATA

    可见性：三十分钟，看清波及面

    08:14，采购 Agent Cell 订阅的供应商事件触发：Supplier S-117 发布停产公告。没有人需要向 Agent 解释"这家供应商有多重要"——重要性已经被建模在 Link 里。Agent 沿关系遍历：S-117 供应哪些组件，组件用在哪些产品上，产品被承诺在哪些含交付 SLA 的合同里，合同归属哪个销售线。三十分钟后，管理层看到的不是一堆转发的群消息，而是一张完整的波及面对象图。

    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 / 大客户线

  2. SIMULATION · MAPS TO // 02 LOGIC

    模拟：在对象图上推演，而不是在群里争论

    09:02，运营 Agent Cell 通过 Context Gateway 申请上下文：任务意图为"供应替代评估"，预期 Action Type 为 ReplanSupply。Gateway 返回的最小上下文包里有候选供应商对象、历史交付记录、受影响工单和相关合同条款摘要——没有财务密级文件，也没有与此无关的部门资料。Agent 在对象图上推演三个方案，每个方案的影响不是一段含糊的描述，而是"哪些合同的交付日期移动多少天"。

    方案动作路径交付影响(示例数据)审批要求
    A · 切换备选供应商CreateWorkItem → 资质验证 → 换源2 份 SLA 合同各延后约 9 天高风险 · 人工审批
    B · 部分设计替代工程变更 → 重新认证延后约 30 天，附加认证风险高风险 · 人工审批
    C · 重排产线优先级重排 WorkItem 队列非承诺订单延后，SLA 合同保住中风险 · 策略批准

    推演结论：A 与 C 组合执行，影响最小、可逆性最高。

  3. EXECUTION · MAPS TO // 03 ACTION

    执行：Agent 提交动作，人批准边界

    10:40，Agent 不直接修改 ERP。它提交三个受控动作：CreateWorkItem(备选供应商资质验证)、UpdateDecision(推荐方案 A + C)、RequestApproval(高风险：涉及两份含交付 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)

  4. LEARNING · MAPS TO // 04 SECURITY & GOVERNANCE

    学习：复盘不靠回忆，靠 Action Log 回放

    三周后复盘，没有人需要凭记忆还原"当时发生了什么"。Action Log 回放显示：整个响应中等待最久的环节是人工审批(26 小时)，最大的上下文缺口是备选供应商的资质文件不在系统里。演化闭环据此产出三个提案，经人工审批后灰度发布：

    • 新增 Link Type BACKUP_FOR — 把"备选供应商"从口头知识变成显式关系；
    • 新增 Action Type TriggerSupplierFailover — 把这次的处置路径沉淀为下次可一键发起的受控动作；
    • 更新 Context Gateway 检索规则 — 供应商中断类任务的上下文包自动附带资质文件与历史交付记录。

    下一次中断发生时，系统比这一次更快——这正是 Ontology 与"项目制交付"的根本区别：能力沉淀在语义层里，而不是沉淀在某个人的经验里。

06自演化 / EVOLUTION

Ontology 不是建模一次，
而是运行一生。

自演化不是 Agent 无限改自己，而是受治理的闭环：任务失败、上下文缺口、重复流程和跨部门协作需求被持续观察、诊断、提案、审批，灰度发布并度量之后，才更新语义层。允许演化的是 prompt、检索规则、本地对象关系和 SOP；高权限 IAM 策略、KMS 与 secrets、跨部门敏感共享规则和生产破坏性动作，永远保留人工审批。

演化闭环文档 → 自演化 Ontology 概念
FIG. 05 — EVOLUTION LOOP
S1Observation任务成功率 · 失败原因 · 上下文缺口
S2Diagnosis工具 / 权限 / 关系 / 提示 / 流程
S3ProposalAgent 或评估器生成改进提案
S4Approval人类负责人或策略规则批准
S5Deployment灰度发布到单个 Agent Cell
S6Measurement对比指标 · 确认有效后推广
S7Ontology Update更新 Object / Link / Action / Interface
FIG. 05 — 七步演化闭环：每一次更新都有 proposal、approval 和 rollback；语义层随使用持续变厚，成为无法被一次性复制的组织资产。
// NEXT

从语义层开始，
部署你的企业 AI。

阅读完整的 Ontology 参考——Object Types、Link Types、Action Types、Interfaces 与 Action Log；或者直接从一次部署评估开始，让我们在你的真实流程里建立第一版语义层。

申请部署评估 → 进入 Ontology 文档