自演化 Ontology
Self-evolving Ontology 指由节点内 Agent 维护的企业语义层：对象、关系、动作、接口和 Action Log 会随着任务失败、上下文缺口、重复流程和跨节点协作需求逐步演化。语义层不再依赖一次性建模，而是在真实使用中持续修正自己。
自演化不能理解为 Agent 自己无限改自己，而是一个受治理的闭环：每一次改动都从观察出发，经过诊断、提案、审批、灰度发布和指标验证，稳定后才写回 Ontology。演化速度来自 Agent，演化边界来自治理。
为什么 Ontology 必须自演化
传统的企业建模方式是"先设计、后使用"：顾问花数月画出一张大而全的语义模型，上线那天就开始过时。AIDC 的判断相反——企业语义层无法被一次性设计正确，只能在运行中逐步逼近正确。原因有三：
- 真实流程只在失败中暴露 — 任务失败原因、人工接管点和上下文缺口，是设计阶段无法预知的信号。只有运行中的系统才能采集它们。
- 组织本身在变化 — 部门、职责、客户结构和工具链都会变。静态 Ontology 的维护成本随时间上升，自演化 Ontology 的质量随时间上升。
- Agent 是最密集的使用者 — Agent 每天通过 Context Gateway 消费语义层，它比任何人更早发现哪个对象缺关系、哪个动作缺定义。让使用者参与维护，是唯一可扩展的维护方式。
因此 AIDC 把 Ontology 的维护权下放到每个 Agent Cell：节点内 Agent 管理本地 Ontology 片段，通过 proposal-first 流程演化，中央只治理 schema 版本、审批策略和审计标准。
七步演化机制
每一轮演化都走完同一个闭环，从信号采集到语义更新，任何一步不通过都不会进入下一步：
ObservationStep 01 · 观察系统持续记录任务成功率、失败原因、上下文缺口和人工接管点。这些信号来自 Action Log、Context Gateway 的上下文包记录和 Agent 的执行日志——观察不靠主观汇报，靠可回放的数据。
DiagnosisStep 02 · 诊断判断问题的归属：是工具缺失、权限过窄、Ontology 关系缺失、提示策略不佳，还是流程设计问题。诊断决定后续提案的类型——把权限问题误诊为提示问题，会让演化在错误的层面空转。
ProposalStep 03 · 提案Agent 或评估器生成结构化的 OntologyProposal，声明要改什么(对象、关系、动作、接口、SOP 或检索规则)、为什么改、预期改善哪个指标。提案是演化的最小单元——没有提案，就没有改动。
ApprovalStep 04 · 审批低风险的本地改动可以由策略规则自动批准;高风险改动必须由人类负责人或强策略审批。审批粒度由 权限模型 定义，与下文的演化边界一致。
DeploymentStep 05 · 灰度发布通过审批的改动先灰度发布到单个部门 Cell，而不是全企业推开。单节点试运行把演化失败的爆炸半径限制在一个部门之内——这是分布式架构对演化安全的直接贡献。
MeasurementStep 06 · 度量对比改动前后的指标：任务成功率是否提升、人工接管是否减少、上下文缺口是否闭合。指标确认有效后才推广到其他节点;无效或恶化，则回滚到上一稳定版本。
Ontology UpdateStep 07 · 语义更新所有策略变更必须具备 proposal、approval 和 rollback 三件套。没有提案记录的改动不允许部署;没有回滚路径的改动不允许审批。这是防止"Agent 自演化失控"的第一条防线。
演化边界：允许与禁止
自演化的范围是被显式划定的。边界的设计原则很简单：影响半径在节点内、可回滚、可度量的改动允许自演化;触及权限根基、密钥和生产安全的改动永远保留人工或强策略审批。
| 允许自演化 | 禁止自动演化 |
|---|---|
| Agent prompt 和工具选择策略 | 高权限 IAM 策略 |
| Context Gateway 的检索和压缩规则 | KMS 和 secrets 管理 |
| 本地对象、关系与 action proposal | 跨部门敏感数据共享规则 |
| 部门文件结构和 SOP | 生产环境破坏性动作 |
| 自动化任务编排 | 审计标准与日志保留策略 |
右列的五类对象——高权限 IAM 策略、KMS 与 secrets 管理、跨部门敏感数据共享规则、生产环境破坏性动作、审计标准与日志保留策略——在任何情况下都不允许 Agent 自动演化。它们必须保留人工批准或强策略审批，且每一次变更都进入 Action Log。原因是这些对象一旦被错误修改，损害不可逆且会跨越节点边界：权限失守意味着所有上层治理同时失效。
演化如何被审计
自演化系统最大的质疑是"如何证明它没有失控"。AIDC 的回答是：让演化本身成为可审计对象。
- 提案即对象 — 每个 OntologyProposal 都是 Ontology 中的对象，绑定发起 Agent、触发信号和目标改动，可以被查询和回放。
- 审批即动作 — 批准或驳回通过受控 Action Type 提交，写入 Action Log，绑定审批者身份与策略版本。
- 版本即历史 — 每次 Ontology Update 产生新的语义版本，schema 更新失败可回滚到上一稳定版本;任意时点的 Agent 行为都能对应到当时的语义版本。
- 上下文包即证据 — 每次任务的 context package 被记录，演化前后的对比可以用评估器回放验证，而不是凭印象判断"变好了"。
完整的闭环实现见 Evolution Loop 架构文档。
为什么这是长期护城河
模型能力是公共品——任何竞争者三个月后都能用上同一代模型。AIDC 的长期护城河不在模型，而在自演化 Ontology 累积的三类资产：
| 累积资产 | 内容 | 为什么难以复制 |
|---|---|---|
| 客户组织语义 | 对象、关系、动作和接口随客户真实流程持续修正 | 语义是从该组织的失败和接管点中学出来的，换一家供应商等于从零开始观察 |
| Agent 行为资产 | prompt、工具选择策略、检索规则在该组织语境下被反复调优 | 每一条策略都绑定该组织的指标验证历史，无法脱离语境迁移 |
| 交付资产 | SOP、文件结构、节点模板在交付中沉淀并被复用 | 沉淀写在客户的 Harness 与 Service Node 里，随使用增值而非随项目结束归档 |
这三类资产共同构成一条复利曲线：部署运行得越久，语义层越准确，Agent 越可靠，下一次演化的起点越高。竞争者可以复制架构，但复制不了一个组织运行两年所累积的语义版本史——这正是 AIDC Operating Thesis 的第五条判断：长期护城河来自自演化 Ontology，客户组织语义、Agent 行为和交付资产会持续积累。
某制造企业的采购节点连续三次在"供应商资质核验"任务上人工接管。Observation 捕捉到接管点，Diagnosis 判定为 Ontology 缺失"供应商—资质文件"的 Link Type。Agent 生成 proposal，因属本地关系新增被策略自动批准，灰度发布到采购 Cell;两周后该任务人工接管率显著下降，Link Type 正式进入语义版本。整个过程无人手工建模，但每一步都可在 Action Log 中回放。
相关阅读
- Evolution Loop — 七步闭环在平台架构中的完整实现
- Ontology 概览 — 对象、关系、动作与接口的基础定义
- Service Node — 自演化机制在服务单元中的落地形态
- 去中心化 Agent 组织 — 为什么演化发生在节点而不是中央