第209章　ICAI Cognitive Engine

209.1 ICAI Cognitive Engine概述

前面的章节已经分别建立了多个独立Engine：

ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine
CapabilityEngine
MatchingEngine
MethodEngine
DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine
FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine
MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

这些Engine并不是彼此独立运行的孤立模块。

ICAI中的认知过程必须建立在：

对象
+
状态
+
关系
+
场景
+
知识

这五类基础认知结构之上。

因此，本章定义：

CognitiveEngine=ObjectEngine+StateEngine+RelationEngine+SceneEngine+KnowledgeEngineCognitiveEngine = ObjectEngine + StateEngine + RelationEngine + SceneEngine + KnowledgeEngine

其中：

• ObjectEngine：计算对象；
• StateEngine：计算状态；
• RelationEngine：计算对象之间的关系；
• SceneEngine：根据对象、状态、关系和环境建立场景；
• KnowledgeEngine：根据事实、关系、条件和规则计算知识。

这五个Engine构成ICAI认知计算的基础层。

进一步表示：

CE=(O,S,R,Sc,K)CE=(O,S,R,Sc,K)

其中：

• O：Object，对象计算结果；
• S：State，状态计算结果；
• R：Relation，关系计算结果；
• Sc：Scene，场景计算结果；
• K：Knowledge，知识计算结果。

因此：

CognitiveEngine=Structure+State+Relation+Scene+KnowledgeCognitiveEngine = Structure + State + Relation + Scene + Knowledge

它不是一个新的独立认知对象，而是一个认知Engine组合层。

---

209.2 为什么需要Cognitive Engine组合

如果所有Engine都直接互相调用，就会产生复杂依赖：

ObjectEngine
↔
StateEngine
↔
RelationEngine
↔
SceneEngine
↔
KnowledgeEngine

进一步又可能形成：

KnowledgeEngine
→ CapabilityEngine
→ MethodEngine
→ DecisionEngine
→ BehaviorEngine
→ ActionEngine
→ ExecutionEngine

如果没有统一组合结构，系统容易出现：

Engine A调用Engine B
Engine B调用Engine C
Engine C再次调用Engine A

最终形成循环依赖。

因此需要建立明确的计算层次。

基础认知层：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

能力与行动认知层：

Knowledge
↓
Capability
↓
Method
↓
Decision

执行层：

Decision
↓
Behavior
↓
Action
↓
Execution

反馈学习层：

Execution
↓
Result
↓
Feedback
↓
Memory
↓
Experience
↓
Learning
↓
Update

因此：

CognitiveEngineCognitiveEngine

负责的是整个认知体系最基础的结构计算。

---

209.3 Cognitive Engine的基本输入

CognitiveEngine的输入不是单一数据。

定义：

CI=(I,O,S,R,Sc,K,C,T)CI=(I,O,S,R,Sc,K,C,T)

其中：

• I：Individual，当前个体；
• O：Object，对象；
• S：State，状态；
• R：Relation，关系；
• Sc：Scene，场景；
• K：Knowledge，知识；
• C：Condition，条件；
• T：Time，时间。

其中最重要的是：

当前实际事实

而不是历史数据本身。

例如：

Object-A
State=ready
Relation=A depends_on B
Scene=processing
Knowledge=A supports Method-M1

CognitiveEngine根据这些事实进行离散计算。

---

209.4 Cognitive Engine的基本输出

统一输出：

CO=(O,S,R,Sc,K,E,V,T)CO=(O,S,R,Sc,K,E,V,T)

其中：

• O：对象结果；
• S：状态结果；
• R：关系结果；
• Sc：场景结果；
• K：知识结果；
• E：Evidence，计算依据；
• V：Verification，验证结果；
• T：计算时间。

因此CognitiveEngine不应该只返回：

true
false

而应该返回：

对象是什么
↓
当前状态是什么
↓
对象之间是什么关系
↓
当前属于什么场景
↓
可以得到什么知识
↓
依据是什么
↓
是否经过验证

这也是ICAI可解释计算的重要基础。

---

209.5 Object——对象认知

对象是ICAI认知结构的基本实体。

对象模型：

O=(ID,T,A,S,R)O=(ID,T,A,S,R)

其中：

• ID：对象唯一标识；
• T：对象类型；
• A：对象属性；
• S：对象状态；
• R：对象关系。

例如：

Object-A
Type = Device
State = Ready
Power = 80
Location = Room-1

ObjectEngine负责：

对象计算
对象属性计算
对象匹配
对象更新

但是ObjectEngine本身不负责：

场景建立
知识学习
最终决策
行为执行

它只负责回答：

当前系统中有哪些对象，以及这些对象本身具有什么结构。

---

209.6 Object与Individual的关系

Individual不是Object的简单别名。

Individual表示：

具有完整认知结构的主体

而Object表示：

被认知、被管理或者参与关系的实体

因此：

Individual⊃ObjectsIndividual \supset Objects

一个Individual可以拥有：

Object-A
Object-B
Object-C

同时具有：

Knowledge
Capability
Method
Behavior
Memory
Experience

因此：

Individual
├── Objects
├── Knowledge
├── Capabilities
├── Methods
├── Behaviors
├── Memory
└── Experience

对象是个体认知结构中的组成部分。

---

209.7 State——状态认知

对象本身不能完整描述当前情况。

例如：

Object-A

只是一个对象。

还必须知道：

Object-A = Ready

因此需要StateEngine。

状态模型：

S=(O,V,T,C,R)S=(O,V,T,C,R)

其中：

• O：Owner；
• V：Value；
• T：Time；
• C：Context；
• R：Reason。

状态回答：

对象现在处于什么状态？

例如：

Device-A
State = ready

经过执行：

Device-A
State = running

执行结束：

Device-A
State = completed

因此：

Statet→Event→Statet+1State_t \rightarrow Event \rightarrow State_{t+1}

---

209.8 Object与State的组合

ObjectEngine和StateEngine不能混为一个Engine。

ObjectEngine：

Object是什么？

StateEngine：

Object现在是什么状态？

因此：

ObjectEngine≠StateEngineObjectEngine\neq StateEngine

但二者存在强依赖：

Object→StateObject \rightarrow State

对象是状态的Owner。

例如：

Object-A
↓
State-A

状态不能脱离对象独立存在。

---

209.9 Relation——关系认知

对象存在之后，还需要知道对象之间的关系。

关系模型：

R=(ID,O1,T,O2,C,S,Tm)R=(ID,O_1,T,O_2,C,S,Tm)

其中：

• ID：关系ID；
• O₁：源对象；
• T：关系类型；
• O₂：目标对象；
• C：关系条件；
• S：关系状态；
• Tm：时间。

例如：

Object-A
depends_on
Object-B

或者：

Object-A
located_in
Room-1

或者：

Method-M1
uses
Resource-R1

关系使孤立对象形成结构。

---

209.10 Object → Relation

单独对象：

A
B
C

只能形成对象集合。

增加关系后：

A → depends_on → B
A → located_in → C

才形成结构。

因此：

Structure=Object+RelationStructure = Object + Relation

关系不是对象属性的简单替代。

例如：

A.location = B

可以表达某种信息。

但：

A located_in B

是一条可以独立计算、验证、更新和追踪的关系事实。

因此ICAI采用独立Relation对象。

---

209.11 Relation与State

关系本身也具有状态。

例如：

A depends_on B

可能是：

active

也可能：

inactive
blocked
expired
conflicted

因此：

Relation+State→ValidRelationRelation + State \rightarrow ValidRelation

RelationEngine负责计算关系。

StateEngine负责计算关系状态。

例如：

A depends_on B

当B进入：

inactive

状态后，可能导致：

A → depends_on → B

的关系变成：

blocked

这里不是简单修改一个字段，而是：

Object State
↓
Relation Condition
↓
Relation State

---

209.12 Scene——场景认知

对象、状态、关系形成之后，还需要回答：

这些对象、状态和关系当前共同构成了什么环境和情境？

这就是Scene。

场景模型：

Sc=(ID,T,O,S,R,C,E,Tm)Sc=(ID,T,O,S,R,C,E,Tm)

其中：

• ID：场景ID；
• T：场景类型；
• O：场景中的对象；
• S：对象及场景状态；
• R：关系；
• C：条件；
• E：环境；
• Tm：时间。

例如：

Scene-001
Type = Processing

Objects:
Device-A
Resource-B
Operator-C

States:
Device-A = running
Resource-B = available

Relations:
Device-A uses Resource-B

Environment:
Normal

这些信息共同形成一个Scene。

---

209.13 Scene不是Object

Scene不是一个普通Object。

Object回答：

是什么？

Scene回答：

多个对象、状态、关系和环境当前共同构成什么情况？

因此：

Scene≠ObjectScene\neq Object

例如：

Device-A

是Object。

而：

Device-A running
+
Resource-B available
+
Device-A uses Resource-B
+
Environment Normal

共同构成：

Processing Scene

---

209.14 Scene不是State

Scene也不是State。

State：

Device-A = running

Scene：

Device-A running
Resource-B available
A uses B
Environment normal

因此：

Scene=Objects+States+Relations+Conditions+EnvironmentScene = Objects + States + Relations + Conditions + Environment

Scene是更高层次的结构组合。

---

209.15 SceneEngine的作用

SceneEngine主要负责：

场景建立
场景计算
场景变化

基本流程：

Object
+
State
+
Relation
+
Condition
+
Environment
↓
SceneEngine
↓
Scene

当其中任何关键事实发生变化：

Object Change
State Change
Relation Change
Environment Change

SceneEngine重新计算：

Sct+ΔF→Sct+1Sc_t+\Delta F \rightarrow Sc_{t+1}

---

209.16 Knowledge——知识认知

知识建立在事实、关系、条件和规则之上。

知识模型：

K=(S,P,O,C,St)K=(S,P,O,C,S_t)

例如：

Device-A
supports
Method-M1

是一条知识事实。

进一步：

Device-A
supports
Method-M1

Method-M1
requires
Resource-R1

Resource-R1
available

通过规则可以计算：

Device-A can use Method-M1

这就是KnowledgeEngine的作用。

---

209.17 Knowledge不是Memory

必须严格区分：

Knowledge≠MemoryKnowledge\neq Memory

Memory：

过去发生过什么

Knowledge：

当前系统确认了什么事实和规则

例如：

History:
2026-09-10 Method-M1执行失败

这是历史。

经过分析：

Method-M1 requires Resource >= 2

并经过验证后：

Knowledge

才正式成立。

因此：

History
↓
Memory
↓
Experience
↓
Learning
↓
Knowledge Update

但并不是所有Memory都自动成为Knowledge。

---

209.18 Knowledge与Relation

KnowledgeEngine与RelationEngine之间存在密切关系。

RelationEngine计算：

A → depends_on → B

KnowledgeEngine可以利用该事实形成：

A depends on B

但两者仍然不同。

Relation：

系统中的结构事实

Knowledge：

经过条件、规则和验证形成的可计算认知事实

因此：

Relation≠KnowledgeRelation\neq Knowledge

Relation可以作为Knowledge的输入。

---

209.19 Knowledge与Scene

Scene提供当前情境。

KnowledgeEngine可以根据：

Current Scene
+
Known Facts
+
Rules

进行知识计算。

例如：

Scene:
Device-A running
Resource-B available

Knowledge:
Running Device requires Resource

Rule:
Running ∧ ResourceAvailable
→ ProcessingPossible

得到：

ProcessingPossible = true

因此：

Knowledge=f(Facts,Scene,Rules,Condition)Knowledge = f(Facts,Scene,Rules,Condition)

---

209.20 五大基础Engine之间的关系

因此：

ObjectEngine
      ↓
StateEngine
      ↓
RelationEngine
      ↓
SceneEngine
      ↓
KnowledgeEngine

但这不是简单的一条单向流水线。

实际结构是：

             Object
                ↓
             State
                ↓
             Relation
                ↓
              Scene
                ↓
            Knowledge

同时：

Object ←→ State
State  ←→ Relation
Relation ←→ Scene
Scene ←→ Knowledge
Knowledge → Object/State/Relation判断

这种关系必须由明确规则控制，不能允许Engine无限互相调用。

---

209.21 Cognitive Engine组合模型

定义完整组合：

CE=OE+SE+RE+ScE+KECE = OE + SE + RE + ScE + KE

其中：

• OE：ObjectEngine；
• SE：StateEngine；
• RE：RelationEngine；
• ScE：SceneEngine；
• KE：KnowledgeEngine。

进一步：

CE(Input)→CognitiveResultCE(Input) \rightarrow CognitiveResult

其中：

CognitiveResult=Object+State+Relation+Scene+KnowledgeCognitiveResult = Object + State + Relation + Scene + Knowledge

---

209.22 Cognitive Engine的计算顺序

一个完整认知计算周期可以定义为：

Load Individual
↓
Load Objects
↓
Calculate Object
↓
Load Current States
↓
Calculate State
↓
Calculate Relations
↓
Build Scene
↓
Calculate Knowledge
↓
Return Cognitive Context

形成：

I→O→S→R→Sc→KI \rightarrow O \rightarrow S \rightarrow R \rightarrow Sc \rightarrow K

最终形成：

Cognitive Context

这个Context随后交给：

CapabilityEngine

继续计算能力。

---

209.23 Cognitive Context

为了避免后续Engine分别读取数据库，可以定义统一认知上下文：

CC=(I,O,S,R,Sc,K,T)CC=(I,O,S,R,Sc,K,T)

其中：

• I：Individual；
• O：Objects；
• S：States；
• R：Relations；
• Sc：Scene；
• K：Knowledge；
• T：Time。

例如：

$context = array(
    'individual' => $individual,
    'objects' => $objects,
    'states' => $states,
    'relations' => $relations,
    'scene' => $scene,
    'knowledge' => $knowledge,
    'time' => $time
);

这个结构可以作为：

CapabilityEngine
MethodEngine
MatchingEngine
DecisionEngine
RiskEngine

的共同输入。

---

209.24 Cognitive Engine不是数据库查询器

必须明确：

CognitiveEngine

不是简单：

SELECT *
FROM objects

数据库只提供事实存储。

CognitiveEngine需要进行：

对象计算
状态判断
关系计算
场景组合
知识推导

因此：

Database=PersistenceDatabase=Persistence

而：

CognitiveEngine=ComputationCognitiveEngine=Computation

两者不能混淆。

---

209.25 Cognitive Engine与Repository

工程架构：

CognitiveService
↓
CognitiveEngine
↓
ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine
↓
Repository
↓
MySQL

Repository负责：

Load
Save
Update
Query

Engine负责：

Calculate
Match
Infer
Validate
Evaluate

因此：

Engine≠RepositoryEngine\neq Repository

---

209.26 Cognitive Engine与Service

CognitiveEngine组合层也不能替代Service。

Service负责：

什么时候计算
计算哪些Engine
按照什么顺序调用
如何组织事务
如何保存结果

CognitiveEngine负责：

具体认知计算

因此：

Service=OrchestrationService=Orchestration Engine=CalculationEngine=Calculation

例如：

CognitiveService
↓
ObjectEngine
↓
StateEngine
↓
RelationEngine
↓
SceneEngine
↓
KnowledgeEngine
↓
CognitiveContext

---

209.27 PHP CognitiveEngine组合实现

以下代码采用PHP 5.6/7兼容方式。

<?php

class CognitiveEngine
{
    protected $objectEngine;
    protected $stateEngine;
    protected $relationEngine;
    protected $sceneEngine;
    protected $knowledgeEngine;

    public function __construct(
        $objectEngine,
        $stateEngine,
        $relationEngine,
        $sceneEngine,
        $knowledgeEngine
    ) {
        $this->objectEngine = $objectEngine;
        $this->stateEngine = $stateEngine;
        $this->relationEngine = $relationEngine;
        $this->sceneEngine = $sceneEngine;
        $this->knowledgeEngine = $knowledgeEngine;
    }

    public function calculate($input)
    {
        $input = is_array($input)
            ? $input
            : array();

        $objectResult =
            $this->objectEngine->calculate(
                $input
            );

        $input['object_result'] =
            $objectResult;

        $stateResult =
            $this->stateEngine->calculate(
                $input
            );

        $input['state_result'] =
            $stateResult;

        $relationResult =
            $this->relationEngine->calculate(
                $input
            );

        $input['relation_result'] =
            $relationResult;

        $sceneResult =
            $this->sceneEngine->calculate(
                $input
            );

        $input['scene_result'] =
            $sceneResult;

        $knowledgeResult =
            $this->knowledgeEngine->calculate(
                $input
            );

        return array(
            'engine' => 'CognitiveEngine',
            'status' => 'calculated',
            'object' => $objectResult,
            'state' => $stateResult,
            'relation' => $relationResult,
            'scene' => $sceneResult,
            'knowledge' => $knowledgeResult
        );
    }
}

这里的重点是：

CognitiveEngine

只负责组合和传递认知计算上下文。

具体计算仍然由：

ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

完成。

---

209.28 Cognitive Engine计算结果

可以统一形成：

$result = array(
    'object' => $objectResult,
    'state' => $stateResult,
    'relation' => $relationResult,
    'scene' => $sceneResult,
    'knowledge' => $knowledgeResult
);

进一步构造：

CognitiveContext

供上层Engine使用。

例如：

CognitiveEngine
↓
CognitiveContext
↓
CapabilityEngine
↓
MatchingEngine
↓
MethodEngine
↓
DecisionEngine

因此CognitiveEngine成为：

基础认知事实到高级认知计算之间的桥梁。

---

209.29 Cognitive Engine中的验证

五类认知结构都必须支持验证。

对象：

Valid(O)Valid(O)

状态：

Valid(S)Valid(S)

关系：

Valid(R)Valid(R)

场景：

Valid(Sc)Valid(Sc)

知识：

Valid(K)Valid(K)

统一：

Valid(CognitiveContext)=Valid(O)∧Valid(S)∧Valid(R)∧Valid(Sc)∧Valid(K)Valid(CognitiveContext) = Valid(O) \land Valid(S) \land Valid(R) \land Valid(Sc) \land Valid(K)

如果基础结构不成立，则不能直接把结果交给：

CapabilityEngine

或者：

DecisionEngine

---

209.30 当前事实优先原则

CognitiveEngine必须遵循：

CurrentFact>HistoricalMemoryCurrentFact > HistoricalMemory

也就是说：

当前实际状态

优先于：

过去记忆

例如Memory记录：

Resource-B available

但当前State显示：

Resource-B blocked

那么CognitiveEngine必须使用：

Current State = blocked

而不能因为Memory中曾经记录：

available

就继续认为资源可用。

Memory和Experience只能作为辅助认知依据。

---

209.31 Knowledge计算中的历史辅助

虽然当前事实优先，但历史仍然具有计算价值。

例如：

Current State:
Resource = available

History:
过去10次中有7次执行失败

则KnowledgeEngine可以形成：

Historical Failure Pattern

然后交给：

RiskEngine

进一步计算风险。

因此：

Current Fact
+
Historical Knowledge
+
Experience

可以形成更完整的认知基础。

但历史不能覆盖当前事实。

---

209.32 Cognitive Engine与CapabilityEngine

CognitiveEngine完成：

Object
State
Relation
Scene
Knowledge

之后，CapabilityEngine才能计算：

当前是否具备某种能力

因此：

CognitiveContext→CapabilityEngineCognitiveContext \rightarrow CapabilityEngine

例如：

Object:
Device-A

State:
ready

Relation:
Device-A uses Resource-B

Scene:
Processing

Knowledge:
Device-A supports Method-M1

CapabilityEngine可以进一步判断：

Device-A
Capability:
execute Method-M1

---

209.33 Cognitive Engine与MethodEngine

MethodEngine需要知道：

Object
State
Scene
Knowledge
Capability

因此：

CognitiveEngine→CapabilityEngine→MethodEngineCognitiveEngine \rightarrow CapabilityEngine \rightarrow MethodEngine

例如：

Object-A
↓
State Ready
↓
Scene Processing
↓
Knowledge supports M1
↓
Capability available
↓
Method M1 becomes candidate

---

209.34 Cognitive Engine与DecisionEngine

DecisionEngine不应该自己重新构造整个认知世界。

它应该读取：

CognitiveContext
+
Capability
+
Method Candidates
+
Risk
+
Conflict

然后计算：

Candidate
↓
Condition
↓
Score
↓
Decision

因此：

Decision=f(CognitiveContext,Capability,Method,Risk,Conflict)Decision = f(CognitiveContext,Capability,Method,Risk,Conflict)

---

209.35 Cognitive Engine完整上层结构

至此，ICAI Engine层可以形成：

ICAI Cognitive Engine
│
├── ObjectEngine
│
├── StateEngine
│
├── RelationEngine
│
├── SceneEngine
│
└── KnowledgeEngine
        ↓
CapabilityEngine
        ↓
MatchingEngine
        ↓
MethodEngine
        ↓
DecisionEngine
        ↓
BehaviorEngine
        ↓
ActionEngine
        ↓
ExecutionEngine
        ↓
FeedbackEngine
        ↓
MemoryEngine
        ↓
ExperienceEngine
        ↓
LearningEngine
        ↓
UpdateEngine
        ↓
Cognitive Engine

最后重新进入新的认知计算。

这形成一个闭环。

---

209.36 Cognitive Engine的完整认知循环

完整循环：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge
↓
Capability
↓
Method
↓
Decision
↓
Behavior
↓
Action
↓
Execution
↓
Result
↓
Feedback
↓
Memory
↓
Experience
↓
Learning
↓
Update
↓
Object / State / Relation / Scene / Knowledge

因此：

Cognitivet→Action→Result→Learning→Update→Cognitivet+1Cognitive_t \rightarrow Action \rightarrow Result \rightarrow Learning \rightarrow Update \rightarrow Cognitive_{t+1}

这比简单的：

Input → Output

具有更完整的认知结构。

---

209.37 Cognitive Engine的更新闭环

UpdateEngine完成更新之后，不应该认为认知计算已经结束。

例如：

Knowledge Changed

可能影响：

Capability

进一步影响：

Method

再影响：

Decision

因此：

Update
↓
Recalculate Cognitive Context
↓
Recalculate Capability
↓
Recalculate Method
↓
Recalculate Decision

这就是：

Update→Re−CognitionUpdate \rightarrow Re-Cognition

即：

更新以后必须重新认知。

---

209.38 为什么不是“重新训练模型”

ICAI中的这种更新不能理解为神经网络重新训练。

这里没有：

Neural Network
Transformer
Embedding
Vector Search
LLM
Prompt Engineering
LLM API

而是：

事实变化
↓
规则计算
↓
状态变化
↓
知识变化
↓
能力变化
↓
结构更新
↓
重新计算

这是：

Discrete Cognitive UpdateDiscrete\ Cognitive\ Update

而不是：

Neural Model TrainingNeural\ Model\ Training

因此ICAI的“学习”与“更新”属于符号、规则、对象、关系、状态、事实和离散计算体系。

---

209.39 Cognitive Engine的工程边界

必须严格划分：

Engine	核心职责
ObjectEngine	对象计算
StateEngine	状态计算
RelationEngine	关系计算
SceneEngine	场景计算
KnowledgeEngine	知识计算
CapabilityEngine	能力计算
MatchingEngine	匹配计算
MethodEngine	方法计算
DecisionEngine	决策计算
BehaviorEngine	行为计算
ActionEngine	动作计算
ExecutionEngine	实际执行
FeedbackEngine	反馈计算
MemoryEngine	记忆计算
ExperienceEngine	经验计算
LearningEngine	学习计算
UpdateEngine	结构更新

因此：

CognitiveEngineCognitiveEngine

不是替代这些Engine，而是组合基础认知Engine。

---

209.40 Cognitive Engine与Engine层架构

最终Engine层可以分为五个区域。

第一层：基础认知Engine

ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

负责：

认知世界

---

第二层：能力与方法Engine

CapabilityEngine
MatchingEngine
MethodEngine

负责：

能做什么
什么方法可用
哪些候选匹配

---

第三层：决策与执行Engine

DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine

负责：

选择什么
如何组织行为
执行什么动作
实际发生什么

---

第四层：反馈与问题Engine

FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine

负责：

发生了什么
有什么风险
有什么冲突
为什么异常
如何保护
如何修复

---

第五层：学习与更新Engine

MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

负责：

记住什么
形成什么经验
学习什么
如何改变认知结构

由此形成：

ICAI Engine=Cognitive+Capability+Decision+Execution+LearningICAI\ Engine = Cognitive + Capability + Decision + Execution + Learning

---

209.41 Cognitive Engine完整PHP组合关系

工程中可以继续建立一个更高层的认知计算入口：

class CognitiveService
{
    protected $cognitiveEngine;

    public function __construct(
        $cognitiveEngine
    ) {
        $this->cognitiveEngine =
            $cognitiveEngine;
    }

    public function buildContext(
        $individual
    ) {
        return $this->cognitiveEngine
            ->calculate(
                array(
                    'individual' =>
                        $individual
                )
            );
    }
}

其职责非常简单：

Individual
↓
CognitiveEngine
↓
CognitiveContext

然后其他Service继续使用：

CognitiveContext

例如：

$context =
    $cognitiveService
        ->buildContext($individual);

$capabilityResult =
    $capabilityEngine
        ->calculate($context);

$methodResult =
    $methodEngine
        ->calculate(
            $context
        );

这种结构可以减少各个Service重复读取和重新组织基础认知数据。

---

209.42 数据库与Cognitive Engine

CognitiveEngine不需要建立一张：

cognitive_engine

这样的超级数据库表。

基础数据仍然分别存储：

objects
object_attributes
object_relations

states
state_history

relations
relation_history

scenes
scene_objects
scene_relations
scene_history

knowledge
knowledge_conditions
knowledge_evidence
knowledge_history

Engine运行时：

Repository
↓
Load Facts
↓
CognitiveEngine
↓
Calculate
↓
CognitiveContext

这样数据库保持：

Persistence StructurePersistence\ Structure

Engine保持：

Computation StructureComputation\ Structure

二者职责清晰。

---

209.43 Cognitive Engine的运行状态

CognitiveEngine本身也可以具有生命周期：

Created
↓
Initialized
↓
Load Object
↓
Load State
↓
Load Relation
↓
Build Scene
↓
Calculate Knowledge
↓
Validate
↓
Context Ready
↓
Released

异常：

Calculation
↓
Validation Failed
↓
Diagnosis

因此：

CognitiveState=Created→Initialized→Calculated→Validated→ReadyCognitiveState = Created \rightarrow Initialized \rightarrow Calculated \rightarrow Validated \rightarrow Ready

---

209.44 Cognitive Engine失败处理

如果Object计算失败：

ObjectEngine
↓
Failure

不能直接认为：

Knowledge Invalid

必须首先进行：

Feedback
↓
DiagnosisEngine

如果State计算失败：

StateEngine
↓
Diagnosis

如果Relation计算失败：

RelationEngine
↓
Conflict / Diagnosis

如果Scene建立失败：

SceneEngine
↓
Diagnosis

如果Knowledge计算失败：

KnowledgeEngine
↓
Diagnosis

这样每个Engine保持独立责任。

---

209.45 Cognitive Engine的核心原则

本章可以归纳为八项原则。

第一，对象优先

所有认知结构必须有明确对象基础。

第二，状态真实

当前状态必须来自实际事实和合法状态计算。

第三，关系显式

对象之间的关系必须可以独立计算、验证和追踪。

第四，场景组合

场景由对象、状态、关系、条件和环境共同形成。

第五，知识可验证

知识不能因为存在于数据库中就自动认为有效。

第六，Engine分工

不同认知计算必须由不同Engine负责。

第七，组合而非混合

CognitiveEngine组合多个Engine，但不吞并它们的职责。

第八，更新后重新认知

任何正式结构更新，都可能要求重新建立CognitiveContext。

---

209.46 ICAI Cognitive Engine统一公式

最终可以建立：

CEt=F(Ot,St,Rt,Sct,Kt)CE_t = F(O_t,S_t,R_t,Sc_t,K_t)

其中：

• O_t：当前对象；
• S_t：当前状态；
• R_t：当前关系；
• Sc_t：当前场景；
• K_t：当前知识。

执行后：

Resultt=Execute(Decisiont)Result_t = Execute(Decision_t)

反馈学习：

Learningt=F(Resultt,Feedbackt,Memoryt,Experiencet)Learning_t = F(Result_t,Feedback_t,Memory_t,Experience_t)

更新：

Updatet=F(Learningt,VerifiedChanget)Update_t = F(Learning_t,VerifiedChange_t)

最终：

CEt+1=F(Updatet)CE_{t+1} = F(Update_t)

因此：

CEt→Decisiont→Executiont→Resultt→Learningt→Updatet→CEt+1CE_t \rightarrow Decision_t \rightarrow Execution_t \rightarrow Result_t \rightarrow Learning_t \rightarrow Update_t \rightarrow CE_{t+1}

这就是ICAI真正意义上的：

认知连续性。

---

209.47 本章总结

第209章建立了：

ICAI Cognitive Engine

其核心不是增加一个新的巨大Engine，而是把前面已经建立的基础认知Engine进行统一组合：

CognitiveEngine=ObjectEngine+StateEngine+RelationEngine+SceneEngine+KnowledgeEngineCognitiveEngine = ObjectEngine + StateEngine + RelationEngine + SceneEngine + KnowledgeEngine

形成：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge
↓
Cognitive Context

其中：

Object回答：

是什么？

State回答：

现在是什么状态？

Relation回答：

与什么存在什么关系？

Scene回答：

当前共同构成什么情境？

Knowledge回答：

根据已经确认的事实、关系、条件和规则，可以得到什么认知结论？

最终：

CognitiveContext=Object+State+Relation+Scene+KnowledgeCognitiveContext = Object + State + Relation + Scene + Knowledge

再向上进入：

Capability
↓
Matching
↓
Method
↓
Decision
↓
Behavior
↓
Action
↓
Execution

执行结果经过：

Feedback
↓
Memory
↓
Experience
↓
Learning
↓
Update

重新回到：

Object
State
Relation
Scene
Knowledge

因此形成：

Cognition→Decision→Execution→Feedback→Learning→Update→Re−CognitionCognition \rightarrow Decision \rightarrow Execution \rightarrow Feedback \rightarrow Learning \rightarrow Update \rightarrow Re-Cognition

这意味着WSaiOS-ICAI的Engine体系已经从单个功能计算逐渐形成了完整的认知计算闭环。

其本质仍然不是大模型推理，而是：

Object+State+Relation+Scene+Knowledge+Rule+Condition+Discrete CalculationObject + State + Relation + Scene + Knowledge + Rule + Condition + Discrete\ Calculation

构成的可计算、可验证、可追踪的个体认知工程系统。

下一阶段的核心问题就不再只是“单个Engine如何计算”，而是进一步建立：

多个认知Engine如何在同一个Runtime中协同计算、共享Context、处理依赖、控制计算顺序，并形成统一的Cognitive Runtime。

这将成为后续ICAI Engine体系向完整运行时架构发展的基础。

第209章补充　统一认知计算的依赖方向

209.48 为什么必须统一依赖方向

在ICAI中，Engine数量不断增加：

ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine
CapabilityEngine
MatchingEngine
MethodEngine
DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine
FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine
MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

如果这些Engine之间允许任意调用，就容易形成：

A → B
B → C
C → A

或者：

ObjectEngine
↔ StateEngine
↔ RelationEngine
↔ SceneEngine
↔ KnowledgeEngine

这种结构会产生三个严重问题：

1. 循环依赖；
2. 认知计算顺序不确定；
3. 一个局部更新可能导致无限级联计算。

因此必须建立：

DependencyDirectionDependencyDirection

即：

每一个Engine知道自己依赖什么，也知道哪些Engine可以依赖自己。

---

209.49 统一依赖方向的基本原则

ICAI Engine依赖必须遵循：

LowerLayer→HigherLayerLowerLayer \rightarrow HigherLayer

这里的“低层”和“高层”不是重要程度，而是计算依赖程度。

基础事实越靠前：

Object
State
Relation

组合认知越靠后：

Scene
Knowledge

行动认知继续向上：

Capability
Method
Decision
Behavior
Action
Execution

反馈学习再形成闭环：

Feedback
Memory
Experience
Learning
Update

因此整个Engine层应当形成有方向的计算图。

---

209.50 第一原则：基础事实向上依赖

最基础的方向是：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

其含义不是说StateEngine必须调用ObjectEngine，而是：

State的计算需要Object作为Owner，Relation需要Object和State，Scene需要Object、State和Relation，Knowledge需要事实、关系、场景和规则。

因此依赖集合可以表示为：

Dep(State)⊇ObjectDep(State)\supseteq Object Dep(Relation)⊇Object+StateDep(Relation)\supseteq Object+State Dep(Scene)⊇Object+State+RelationDep(Scene)\supseteq Object+State+Relation Dep(Knowledge)⊇Object+State+Relation+SceneDep(Knowledge)\supseteq Object+State+Relation+Scene

---

209.51 ObjectEngine处于基础位置

ObjectEngine负责：

对象身份
对象类型
对象属性
对象结构
对象匹配
对象变化

因此：

ObjectEngineObjectEngine

原则上不依赖：

DecisionEngine
MethodEngine
BehaviorEngine
LearningEngine

也不应该出现：

ObjectEngine → DecisionEngine

因为对象是什么，不应该由一个决策结果决定。

正确方向：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

---

209.52 StateEngine的依赖方向

StateEngine计算：

当前状态
状态转换
状态验证

它需要知道：

Object
Event
Condition
Rule

因此：

Object
↓
StateEngine

但是：

StateEngine
↓
ObjectEngine

不应该成为直接计算依赖。

例如：

Object-A
State = ready

StateEngine可以根据实际Event计算：

ready
→
running

但它不应该要求ObjectEngine再次决定：

Object-A是什么？

对象身份应当已经由上游提供。

---

209.53 RelationEngine的依赖方向

RelationEngine需要：

Source Object
Target Object
Relation Type
Condition
State

因此：

RelationEngine←Object+StateRelationEngine \leftarrow Object + State

正确方向：

Object
↓
State
↓
Relation

例如：

Object-A
Object-B

先确定两个对象。

然后：

A depends_on B

再计算关系状态：

active

因此RelationEngine不能反过来要求ObjectEngine根据关系重新创造对象。

---

209.54 SceneEngine的依赖方向

Scene是更高层的组合结构。

因此：

Scene=Object+State+Relation+Condition+EnvironmentScene = Object + State + Relation + Condition + Environment

所以：

ObjectEngine
       ↓
StateEngine
       ↓
RelationEngine
       ↓
SceneEngine

SceneEngine原则上不应该成为ObjectEngine的基础依赖。

错误：

ObjectEngine
→
SceneEngine
→
ObjectEngine

正确：

Object
+
State
+
Relation
+
Environment
↓
SceneEngine
↓
Scene

---

209.55 KnowledgeEngine的依赖方向

KnowledgeEngine是基础认知层的最后一个Engine。

它可以使用：

Object
State
Relation
Scene
Condition
Rule
Evidence

因此：

Object
State
Relation
Scene
     ↓
KnowledgeEngine

形成：

K=f(O,S,R,Sc,C,Ru)K = f(O,S,R,Sc,C,Ru)

其中：

• O：Object；
• S：State；
• R：Relation；
• Sc：Scene；
• C：Condition；
• Ru：Rule。

KnowledgeEngine不应该反向成为ObjectEngine的计算依赖。

---

209.56 第一层依赖图

因此基础认知Engine可以统一表示为：

                Object
              /   |   \
             ↓    ↓    ↓
          State Relation
             \     /
              \   /
               Scene
                 ↓
             Knowledge

更加严格地表示：

O→S→R→Sc→KO \rightarrow S \rightarrow R \rightarrow Sc \rightarrow K

但是实际允许部分并行：

O→SO \rightarrow S O+S→RO+S \rightarrow R O+S+R→ScO+S+R \rightarrow Sc O+S+R+Sc→KO+S+R+Sc \rightarrow K

这比简单线性链更加准确。

---

209.57 第二原则：能力依赖认知上下文

CapabilityEngine回答：

当前对象、状态、条件和范围下，是否具备某种能力？

因此它依赖：

Object
State
Scene
Knowledge
Condition

形成：

Object
State
Relation
Scene
Knowledge
       ↓
CapabilityEngine

即：

Capability=f(O,S,Sc,K,C)Capability = f(O,S,Sc,K,C)

因此CapabilityEngine不能成为：

ObjectEngine
StateEngine
SceneEngine

的基础依赖。

---

209.58 MatchingEngine的依赖方向

MatchingEngine负责：

对象匹配
属性匹配
状态匹配
能力匹配
方法匹配

因此它需要已有认知结构。

依赖方向：

Object
State
Relation
Scene
Knowledge
Capability
Method
        ↓
MatchingEngine

特别需要注意：

MatchingEngine负责计算“是否匹配”，不负责最终决定“选择谁”。

因此：

MatchingEngine→DecisionEngineMatchingEngine \rightarrow DecisionEngine

而不是：

DecisionEngine→MatchingEngine→DecisionEngineDecisionEngine \rightarrow MatchingEngine \rightarrow DecisionEngine

如果需要重新匹配，应该由上层Service重新发起新的计算周期。

---

209.59 MethodEngine的依赖方向

MethodEngine需要：

Goal
Object
State
Scene
Capability
Knowledge
Resource
Condition

因此：

CognitiveContext
      ↓
CapabilityEngine
      ↓
MatchingEngine
      ↓
MethodEngine

但MethodEngine不能反向成为CapabilityEngine的直接依赖。

例如：

Capability:
can_process

可以帮助判断：

Method-M1

是否适用。

但是MethodEngine不能在计算方法过程中直接修改Capability。

如果发现能力可能变化，应产生：

Capability Update Candidate

交给：

LearningEngine / UpdateEngine

处理。

---

209.60 DecisionEngine的依赖方向

DecisionEngine位于选择层。

它可以读取：

Goal
Capability
Method Candidates
Matching Result
Risk
Conflict
Knowledge
State
Resource

因此：

Cognitive Context
        ↓
Capability
        ↓
Method
        ↓
Matching
        ↓
Risk / Conflict
        ↓
DecisionEngine

DecisionEngine输出：

Selected Candidate

但是DecisionEngine不应该反向控制：

ObjectEngine
StateEngine
RelationEngine

它可以提出：

Required State
Required Capability
Required Method

真正的状态变化仍由StateEngine和UpdateEngine负责。

---

209.61 BehaviorEngine的依赖方向

DecisionEngine完成：

选择哪个方案

BehaviorEngine负责：

如何组织选定方案的行为

因此：

Decision→BehaviorDecision \rightarrow Behavior

形成：

DecisionEngine
↓
BehaviorEngine

BehaviorEngine需要：

Selected Method
Goal
Object
Current State
Capability
Actions

但它不应该重新做最终Decision。

因此：

BehaviorEngine≠DecisionEngineBehaviorEngine \neq DecisionEngine

---

209.62 ActionEngine的依赖方向

BehaviorEngine形成：

Action Sequence

ActionEngine负责：

Action Calculation
Action Validation
Action Execution Preparation
Action Result

因此：

BehaviorEngine
↓
ActionEngine

ActionEngine不能反向修改Behavior结构。

如果Action失败：

Action Failure
↓
Result
↓
Feedback
↓
Diagnosis

而不是：

ActionEngine
→
BehaviorEngine
→
ActionEngine

---

209.63 ExecutionEngine的依赖方向

ExecutionEngine是真实运行层。

因此：

Behavior
↓
Action
↓
Execution

ExecutionEngine负责：

实际执行
运行状态
实际结果
执行证据

它不能把：

Actual Result

直接修改为：

Expected Result

实际结果必须进入：

FeedbackEngine

进行比较。

因此：

Execution→Result→FeedbackExecution \rightarrow Result \rightarrow Feedback

---

209.64 FeedbackEngine的依赖方向

FeedbackEngine接收：

Execution
Result
State
Environment
Evidence

然后计算：

Expected vs Actual
State Change
Environment Change

因此：

ExecutionEngine
↓
FeedbackEngine

FeedbackEngine产生：

Feedback

随后进入：

MemoryEngine
ExperienceEngine
RiskEngine
ConflictEngine
DiagnosisEngine

但FeedbackEngine不应该直接决定：

Repair
Method Change
Capability Invalid

这些由对应Engine负责。

---

209.65 Diagnosis与Risk、Conflict的依赖方向

RiskEngine：

未来可能发生什么问题？

ConflictEngine：

当前存在什么结构冲突？

DiagnosisEngine：

已经发生的异常为什么发生？

因此三者不能混成一个Engine。

正确关系：

Current State
      ↓
RiskEngine
      ↓
Risk

Current Structure
      ↓
ConflictEngine
      ↓
Conflict

Actual Failure
      ↓
DiagnosisEngine
      ↓
Cause

如果实际异常已经发生：

Feedback
↓
Abnormality
↓
DiagnosisEngine

Risk和Conflict可以作为DiagnosisEngine的证据输入。

---

209.66 ProtectionEngine与RepairEngine

ProtectionEngine解决：

如何避免风险扩大

RepairEngine解决：

已经出现问题后如何恢复

因此：

Risk
↓
ProtectionEngine

而：

Abnormality
↓
Diagnosis
↓
RepairEngine

两者不能反向混合。

正确结构：

RiskEngine
↓
ProtectionEngine

DiagnosisEngine
↓
RepairEngine

---

209.67 MemoryEngine与ExperienceEngine

MemoryEngine依赖实际历史：

History
↓
MemoryEngine
↓
Memory

ExperienceEngine使用：

History
+
Memory
+
Comparison
+
Relation

形成：

Experience

因此：

Memory→ExperienceMemory \rightarrow Experience

但是ExperienceEngine不能直接修改Memory。

如果产生新的Memory变化：

Experience Result
↓
Learning
↓
Update

再由UpdateEngine完成正式更新。

---

209.68 LearningEngine的依赖方向

LearningEngine使用：

Result
Feedback
History
Memory
Experience
Knowledge
Verification
Diagnosis
Repair
Risk
Conflict

计算：

Learning Candidate

因此：

Feedback
Memory
Experience
Diagnosis
Verification
       ↓
LearningEngine

LearningEngine输出：

Update Candidate

然后：

LearningEngine
↓
UpdateEngine

这是非常重要的单向边界。

---

209.69 UpdateEngine的依赖方向

UpdateEngine是结构落实层。

它接收：

Verified Change
Update Candidate
Rule
Condition

然后更新：

State
Knowledge
Capability
Individual Structure

因此：

LearningEngine
        ↓
UpdateEngine
        ↓
State / Knowledge / Capability / Individual

UpdateEngine完成后，新的结构再次进入：

CognitiveEngine

形成：

Update→ReCognitionUpdate \rightarrow ReCognition

---

209.70 完整依赖方向

综合所有Engine，可以形成：

                           Object
                             ↓
                           State
                             ↓
                          Relation
                             ↓
                           Scene
                             ↓
                         Knowledge
                             ↓
                        Capability
                             ↓
                         Matching
                             ↓
                           Method
                             ↓
                         Decision
                             ↓
                         Behavior
                             ↓
                           Action
                             ↓
                         Execution
                             ↓
                           Result
                             ↓
                         Feedback
                 ┌───────────┼────────────┐
                 ↓           ↓            ↓
               Risk       Conflict     Diagnosis
                 ↓           ↓            ↓
             Protection                Repair
                 └───────────┬────────────┘
                             ↓
                           Memory
                             ↓
                         Experience
                             ↓
                          Learning
                             ↓
                           Update
                             ↓
                 ┌───────────┼─────────────┐
                 ↓           ↓             ↓
               State      Knowledge     Capability
                 └───────────┼─────────────┘
                             ↓
                    Individual Structure
                             ↓
                      Cognitive Context
                             ↓
                     Re-Cognition

这里最重要的是：

Update之后不是直接回到Decision，而是先重新建立Cognitive Context。

---

209.71 依赖方向不是简单直线

虽然可以把系统画成一条主链：

O→S→R→Sc→K→C→M→DO \rightarrow S \rightarrow R \rightarrow Sc \rightarrow K \rightarrow C \rightarrow M \rightarrow D

但实际计算应该是一个有向无环计算图。

例如：

Object
├── State
├── Relation
└── Attribute

Object + State
↓
Relation

Object + State + Relation
↓
Scene

Object + State + Relation + Scene
↓
Knowledge

Knowledge + State + Scene
↓
Capability

因此：

DependencyGraphDependencyGraph

比简单的：

A→B→CA\rightarrow B\rightarrow C

更加准确。

---

209.72 为什么不能允许双向Engine依赖

例如：

KnowledgeEngine
↔
CapabilityEngine

看起来很方便：

Knowledge帮助能力计算
能力又帮助知识计算

但会产生：

Knowledge
↓
Capability
↓
Knowledge
↓
Capability
↓
...

因此必须把：

计算依赖

与：

更新反馈

分开。

正确结构：

Knowledge
↓
Capability Calculation
↓
Capability Result
↓
Learning
↓
Update
↓
Knowledge Update

即：

Calculate≠UpdateCalculate \neq Update

这是ICAI避免循环依赖的关键原则。

---

209.73 计算依赖与数据反馈的区别

必须明确区分：

计算依赖

表示：

A需要B的结果才能计算

例如：

Scene←RelationScene \leftarrow Relation

数据反馈

表示：

A产生结果后，
未来可能导致B更新

例如：

Execution→Feedback→Learning→Update→KnowledgeExecution \rightarrow Feedback \rightarrow Learning \rightarrow Update \rightarrow Knowledge

因此：

A→BA\rightarrow B

不一定意味着：

A必须直接调用B。

它可能只是：

A的结果成为B未来更新的依据。

---

209.74 Engine不能直接形成闭环调用

错误结构：

KnowledgeEngine
↓
CapabilityEngine
↓
MethodEngine
↓
DecisionEngine
↓
KnowledgeEngine

正确结构：

KnowledgeEngine
↓
CapabilityEngine
↓
MethodEngine
↓
DecisionEngine
↓
Execution
↓
Feedback
↓
Learning
↓
Update
↓
KnowledgeEngine

这里虽然整个系统是闭环：

Cognition→Action→Learning→CognitionCognition \rightarrow Action \rightarrow Learning \rightarrow Cognition

但单个计算周期内部仍然保持：

DAG=Directed Acyclic GraphDAG = Directed\ Acyclic\ Graph

即：

有向无环计算图。

---

209.75 Cognitive Cycle与Dependency Graph

因此ICAI同时存在两个结构。

第一个是：

DependencyGraphDependencyGraph

负责：

一次计算周期内部

第二个是：

CognitiveCycleCognitiveCycle

负责：

多个计算周期之间

可以表示为：

Cycle t

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge
↓
Capability
↓
Method
↓
Decision
↓
Execution
↓
Result

Cycle Boundary

Feedback
↓
Learning
↓
Update

Cycle t+1

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

因此：

DependencyGraph+CognitiveCycleDependencyGraph + CognitiveCycle

共同构成ICAI统一认知计算架构。

---

209.76 统一依赖层级

最终可以把Engine划分为八个依赖层。

Level 0：事实对象层

ObjectEngine

---

Level 1：状态结构层

StateEngine
RelationEngine

---

Level 2：情境认知层

SceneEngine

---

Level 3：知识认知层

KnowledgeEngine

---

Level 4：能力与方法层

CapabilityEngine
MatchingEngine
MethodEngine

---

Level 5：决策与行为层

DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine

---

Level 6：反馈与问题处理层

FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine

---

Level 7：学习与结构更新层

MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

但是Level 7更新完成之后，不是向Level 6无限反向调用，而是：

Update
↓
New Runtime State
↓
Level 0～3 Re-Cognition

重新开始新的认知周期。

---

209.77 统一依赖规则

因此可以建立ICAI Engine的七条依赖规则。

规则一：低层不能依赖高层

例如：

ObjectEngine

不能依赖：

DecisionEngine

---

规则二：同层Engine原则上不直接循环依赖

例如：

RiskEngine
↔
ConflictEngine

如果需要互相提供信息，应通过：

Context
Result
Service

传递。

---

规则三：计算Engine不直接修改其他Engine的数据

例如：

KnowledgeEngine

不能直接：

UPDATE capabilities

必须产生结果或Candidate。

---

规则四：Update统一负责正式结构更新

正式结构改变统一进入：

UpdateEngine

或者由对应Domain Service协调UpdateEngine。

---

规则五：Execution不修改认知结论

Execution只产生：

Actual Result

认知解释交给：

Feedback
Diagnosis
Learning

---

规则六：Learning不直接修改正式结构

Learning产生：

Learning Result
Update Candidate

正式修改交给：

UpdateEngine

---

规则七：Update后必须重新认知

Update→Re−CognitionUpdate \rightarrow Re-Cognition

不能直接假设旧CognitiveContext仍然有效。

---

209.78 统一依赖方向的PHP工程表达

在PHP OOP中，可以通过依赖注入保持方向。

例如：

class CognitiveEngine
{
    protected $objectEngine;
    protected $stateEngine;
    protected $relationEngine;
    protected $sceneEngine;
    protected $knowledgeEngine;

    public function __construct(
        $objectEngine,
        $stateEngine,
        $relationEngine,
        $sceneEngine,
        $knowledgeEngine
    ) {
        $this->objectEngine = $objectEngine;
        $this->stateEngine = $stateEngine;
        $this->relationEngine = $relationEngine;
        $this->sceneEngine = $sceneEngine;
        $this->knowledgeEngine = $knowledgeEngine;
    }
}

这里表达：

CognitiveEngine
↓
ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

而不是：

ObjectEngine
↓
CognitiveEngine

---

209.79 禁止Engine直接依赖Controller

Engine层不应该出现：

class ObjectEngine
{
    protected $controller;
}

也不应该：

class KnowledgeEngine
{
    protected $smarty;
}

或者：

class StateEngine
{
    protected $database;
}

Engine应该依赖：

Domain Object
Rule
Condition
Runtime Context
Engine Result

而不是：

HTTP Request
Controller
Smarty
MySQL

这样才能保持Engine层独立。

---

209.80 Engine与Repository的方向

推荐：

Service
↓
Engine
↓
Domain Object

以及：

Service
↓
Repository
↓
MySQL

而不是：

Engine
↓
Repository
↓
MySQL

如果Engine直接依赖Repository，就会导致：

Calculation
+
Persistence

混合。

因此更严格的结构是：

Controller
↓
Service
├── Repository
└── Engine
       ↓
   Domain Object

Service负责把二者组合起来。

---

209.81 CognitiveService统一编排

最终可以定义：

Controller
↓
CognitiveService
↓
CognitiveEngine
├── ObjectEngine
├── StateEngine
├── RelationEngine
├── SceneEngine
└── KnowledgeEngine
↓
CognitiveContext

然后：

CognitiveContext
↓
CapabilityService
↓
CapabilityEngine
↓
MethodService
↓
MethodEngine
↓
DecisionService
↓
DecisionEngine

这样Service层和Engine层的方向也保持一致。

---

209.82 依赖方向与UpdateEngine的关系

UpdateEngine是整个体系中非常特殊的Engine。

它不是普通的“向上计算Engine”，而是：

Learning
↓
Update
↓
Structure Change

因此UpdateEngine的输出会改变：

Object
State
Relation
Knowledge
Capability
Method
Individual

这并不意味着：

UpdateEngine
→
ObjectEngine
→
UpdateEngine

而是：

UpdateEngine
↓
Persistent Structure Changed
↓
New Runtime
↓
CognitiveEngine

也就是：

Update→Runtimet+1→CognitiveEngineUpdate \rightarrow Runtime_{t+1} \rightarrow CognitiveEngine

---

209.83 最终统一依赖模型

因此ICAI可以建立最终依赖图：

                         ┌───────────────┐
                         │ ObjectEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ StateEngine   │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │RelationEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ SceneEngine   │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │KnowledgeEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │CapabilityEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │MatchingEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ MethodEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ DecisionEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ BehaviorEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │  ActionEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ExecutionEngine│
                         └───────┬───────┘
                                 ↓
                              Result
                                 ↓
                         ┌───────────────┐
                         │FeedbackEngine │
                         └───────┬───────┘
                                 ↓
                    ┌────────────┼────────────┐
                    ↓            ↓            ↓
                RiskEngine  ConflictEngine DiagnosisEngine
                    ↓                         ↓
             ProtectionEngine            RepairEngine
                    └────────────┬────────────┘
                                 ↓
                         ┌───────────────┐
                         │ MemoryEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ExperienceEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ LearningEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ UpdateEngine  │
                         └───────┬───────┘
                                 ↓
                         New Runtime State
                                 ↓
                         CognitiveEngine

其中最关键的一点是：

Engine Dependency≠Cognitive FeedbackEngine\ Dependency \neq Cognitive\ Feedback

依赖方向在一个计算周期内必须保持向前。

反馈只在一个计算周期结束之后，通过：

Feedback
→
Learning
→
Update
→
New Runtime

开启下一个计算周期。

---

209.84 本节总结

统一认知计算的核心不是让所有Engine互相调用，而是建立：

Directed Cognitive DependencyDirected\ Cognitive\ Dependency

即：

Object→State→Relation→Scene→Knowledge→Capability→Method→Decision→Behavior→Action→ExecutionObject \rightarrow State \rightarrow Relation \rightarrow Scene \rightarrow Knowledge \rightarrow Capability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution

执行之后：

Execution→Feedback→Learning→UpdateExecution \rightarrow Feedback \rightarrow Learning \rightarrow Update

再：

Update→NewRuntime→CognitiveEngineUpdate \rightarrow NewRuntime \rightarrow CognitiveEngine

因此ICAI同时具有两个层次：

DependencyGraph=DAGDependencyGraph = DAG

负责单次认知计算的有向无环依赖；

以及：

CognitiveCycleCognitiveCycle

负责跨周期的认知、执行、反馈、学习和更新闭环。

最终可以用一句话定义统一依赖方向：

ICAI的Engine在单次计算周期内必须保持由基础事实向高级认知、由认知向决策、由决策向执行的单向依赖；执行产生的反馈不得反向形成Engine调用闭环，而必须经过Feedback、Memory、Experience、Learning和Update形成新的Runtime，再重新进入CognitiveEngine。

因此：

单周期：
事实 → 认知 → 能力 → 方法 → 决策 → 行为 → 执行

跨周期：
执行 → 反馈 → 记忆 → 经验 → 学习 → 更新 → 新认知

这就把ICAI从“多个Engine的集合”进一步提升为：

DAG Cognitive Computation+Cyclic Cognitive Evolution\boxed{ DAG\ Cognitive\ Computation + Cyclic\ Cognitive\ Evolution }

即：

单周期有向无环计算，跨周期认知闭环演化。

整个结构仍然完全建立在对象、状态、关系、场景、知识、规则、条件、离散计算、历史、记忆、经验和验证之上，不需要LLM、Transformer、Embedding、Vector Search、Prompt Engineering、神经网络或LLM API。

第209章　ICAI Cognitive Engine——输入输出定义修正版

209.1 CognitiveEngine输入输出定义修正

上一版对CognitiveEngine输入输出的定义存在一个结构性问题。

原定义：

CI=(I,O,S,R,Sc,K,C,T)CI=(I,O,S,R,Sc,K,C,T)

其中已经包含：

Object
State
Relation
Scene
Knowledge

但CognitiveEngine本身又负责计算：

Object
State
Relation
Scene
Knowledge

因此会产生：

Input→CognitiveEngine→InputInput \rightarrow CognitiveEngine \rightarrow Input

的循环定义。

例如：

CognitiveEngine
输入 Scene
↓
SceneEngine
计算 Scene

这里就出现了：

Scene究竟是输入事实，还是Engine计算结果？

因此必须进行严格区分。

---

209.2 CognitiveEngine的真正输入

CognitiveEngine的输入应该定义为：

CI=(I,Of,Sf,Rf,C,Env,T,H,Ev)CI=(I,O_f,S_f,R_f,C,Env,T,H,E_v)

其中：

• I：Individual，当前个体；
• O_f：Object Facts，对象事实；
• S_f：State Facts，状态事实；
• R_f：Relation Facts，关系事实；
• C：Condition，当前条件；
• Env：Environment，当前环境；
• T：Time，当前时间；
• H：History，历史事实；
• E_v：Evidence，证据。

这里最重要的是使用：

Object Facts
State Facts
Relation Facts

而不是直接使用：

Object
State
Relation

因为Engine需要区分：

输入事实

和：

计算结果

---

209.3 Object Facts

Object Facts表示当前系统已经获得的对象事实。

例如：

Object-A
Type = Device
Power = 80
Location = Room-1

可以表示：

Of={o1,o2,…,on}O_f=\{o_1,o_2,\ldots,o_n\}

其中：

• O_f：对象事实集合；
• o_i：第 i 个对象事实；
• n：对象事实数量。

ObjectEngine读取：

OfO_f

然后计算：

Object Result

因此：

Of→ObjectEngine→OO_f \rightarrow ObjectEngine \rightarrow O

---

209.4 State Facts

State Facts表示当前已经获得的状态事实。

例如：

Device-A
State = Ready

定义：

Sf={s1,s2,…,sn}S_f=\{s_1,s_2,\ldots,s_n\}

其中：

• S_f：状态事实集合；
• s_i：第 i 个状态事实；
• n：状态事实数量。

StateEngine根据：

Object
+
State Fact
+
Event
+
Condition
+
Rule

计算当前状态。

因此：

Sf+E+C+Ru→StateEngine→SS_f + E + C + Ru \rightarrow StateEngine \rightarrow S

其中：

• E：Event，事件；
• C：Condition，条件；
• Ru：Rule，规则；
• S：状态计算结果。

---

209.5 Relation Facts

Relation Facts表示已经存在或已经获得的关系事实。

例如：

Device-A
uses
Resource-B

定义：

Rf={r1,r2,…,rn}R_f=\{r_1,r_2,\ldots,r_n\}

其中：

• R_f：关系事实集合；
• r_i：第 i 个关系事实；
• n：关系事实数量。

RelationEngine根据：

Object
+
Relation Fact
+
State
+
Condition
+
Rule

计算关系。

因此：

O+S+Rf+C+Ru→RelationEngine→RO+S+R_f+C+Ru \rightarrow RelationEngine \rightarrow R

---

209.6 Scene不作为基础输入

Scene需要特别修正。

Scene不应该作为CognitiveEngine的基础输入。

因为Scene本身是由：

Object
+
State
+
Relation
+
Condition
+
Environment
+
Time

共同计算得到的。

因此：

Sc=F(O,S,R,C,Env,T)Sc = F(O,S,R,C,Env,T)

所以正确结构是：

Object Facts
State Facts
Relation Facts
Condition
Environment
Time
↓
ObjectEngine
StateEngine
RelationEngine
↓
SceneEngine
↓
Scene

因此：

Scene∉CoreInputScene\notin CoreInput

而：

Scene∈OutputScene\in Output

这可以消除之前的循环定义。

---

209.7 Knowledge也不作为基础输入结果

Knowledge同样需要进行区分。

知识可以作为：

已有知识事实

参与计算。

但KnowledgeEngine产生的：

Calculated Knowledge

属于输出。

因此应当把输入区分为：

KfK_f

即：

Knowledge Facts，已有知识事实。

而输出为：

KK

即：

Knowledge Result，经过KnowledgeEngine计算后的知识结果。

因此：

Kf+O+S+R+Sc+C+Ru→KnowledgeEngine→KK_f + O + S + R + Sc + C + Ru \rightarrow KnowledgeEngine \rightarrow K

---

209.8 修正后的CognitiveEngine输入模型

因此，CognitiveEngine的标准输入定义为：

CI=(I,Of,Sf,Rf,Kf,C,Env,T,H,Ev,Ru)CI=(I,O_f,S_f,R_f,K_f,C,Env,T,H,E_v,Ru)

其中：

符号	名称	含义
I	Individual	当前个体
O_f	Object Facts	对象事实
S_f	State Facts	状态事实
R_f	Relation Facts	关系事实
K_f	Knowledge Facts	已有知识事实
C	Condition	当前条件
Env	Environment	当前环境
T	Time	当前时间
H	History	历史事实
E_v	Evidence	证据
Ru	Rule	当前适用规则

这里：

f=Factf = Fact

表示已经获得的事实，而不是当前Engine刚刚计算出来的结果。

---

209.9 CognitiveEngine输出模型

CognitiveEngine的输出不能只定义成：

CO=(O,S,R,Sc,K,E,V,T)CO=(O,S,R,Sc,K,E,V,T)

因为这个定义没有明确：

哪些是计算结果
哪些是验证结果
哪些是计算依据
哪些是上下文

因此修正为：

CO=(Oc,Sc,Rc,Scc,Kc,Ec,Vc,T)CO=(O_c,S_c,R_c,Sc_c,K_c,E_c,V_c,T)

其中：

• O_c：Object Calculation Result，对象计算结果；
• S_c：State Calculation Result，状态计算结果；
• R_c：Relation Calculation Result，关系计算结果；
• Sc_c：Scene Calculation Result，场景计算结果；
• K_c：Knowledge Calculation Result，知识计算结果；
• E_c：Calculation Evidence，计算依据；
• V_c：Calculation Verification，计算验证结果；
• T：Calculation Time，计算时间。

这里的下标：

c=Calculatedc=Calculated

表示这些是Engine计算产生的结果。

---

209.10 Output中的Object

输出：

OcO_c

表示ObjectEngine完成对象计算后的结果。

例如：

Object-A
Type = Device
Power = 80
StateOwner = true

ObjectEngine可能进一步得到：

Object-A
Type = Device
Valid = true
Range = Normal

因此：

Of→ObjectEngine→OcO_f \rightarrow ObjectEngine \rightarrow O_c

---

209.11 Output中的State

输出：

ScS_c

表示StateEngine计算得到的候选或计算状态。

例如：

Current State Fact:
Device-A = ready

Event:
start

Condition:
resource_available = true

计算：

Transition(St,E,C,Ru)→ScTransition(S_t,E,C,Ru) \rightarrow S_c

得到：

Device-A = running

注意：

Sc≠St+1S_c\neq S_{t+1}

S_c只是计算得到的候选状态。

只有经过验证并由StateService/Update流程正式应用之后，才能形成：

St+1S_{t+1}

---

209.12 Output中的Relation

输出：

RcR_c

表示RelationEngine计算出的关系结果。

例如：

Object-A
uses
Resource-B

RelationEngine可以计算：

Relation = active

或者：

Relation = blocked

因此：

Rf+Oc+Sc→RelationEngine→RcR_f + O_c + S_c \rightarrow RelationEngine \rightarrow R_c

---

209.13 Output中的Scene

输出：

SccSc_c

表示SceneEngine根据前面的计算结果形成的场景。

定义：

Scc=F(Oc,Sc,Rc,C,Env,T)Sc_c = F(O_c,S_c,R_c,C,Env,T)

例如：

Object:
Device-A
Resource-B

State:
Device-A = running
Resource-B = available

Relation:
Device-A uses Resource-B

Environment:
Normal

计算：

Scene = Processing

因此：

Scc=ProcessingSc_c = Processing

---

209.14 Output中的Knowledge

输出：

KcK_c

表示KnowledgeEngine根据当前认知事实计算得到的知识结果。

例如：

Device-A supports Method-M1

结合：

Method-M1 requires Resource-B
Resource-B available
Device-A ready

可以计算：

Device-A can_use Method-M1

因此：

Kc=F(Oc,Sc,Rc,Scc,Kf,C,Ru)K_c = F(O_c,S_c,R_c,Sc_c,K_f,C,Ru)

---

209.15 CognitiveEngine内部数据流

因此CognitiveEngine内部真正的计算顺序应定义为：

Input Facts
│
├── Object Facts
├── State Facts
├── Relation Facts
├── Knowledge Facts
├── Condition
├── Environment
├── Time
├── History
├── Evidence
└── Rules
        ↓
ObjectEngine
        ↓
Object Result
        ↓
StateEngine
        ↓
State Result
        ↓
RelationEngine
        ↓
Relation Result
        ↓
SceneEngine
        ↓
Scene Result
        ↓
KnowledgeEngine
        ↓
Knowledge Result
        ↓
CognitiveContext

因此：

CI→OE→Oc→SE→Sc→RE→Rc→ScE→Scc→KE→Kc→COCI \rightarrow OE \rightarrow O_c \rightarrow SE \rightarrow S_c \rightarrow RE \rightarrow R_c \rightarrow ScE \rightarrow Sc_c \rightarrow KE \rightarrow K_c \rightarrow CO

---

209.16 修正后的完整输入输出公式

最终定义：

CI=(I,Of,Sf,Rf,Kf,C,Env,T,H,Ev,Ru)CI=(I,O_f,S_f,R_f,K_f,C,Env,T,H,E_v,Ru)

经过：

CE(CI)CE(CI)

得到：

CO=(Oc,Sc,Rc,Scc,Kc,Ec,Vc,T)CO=(O_c,S_c,R_c,Sc_c,K_c,E_c,V_c,T)

因此：

CE:(I,Of,Sf,Rf,Kf,C,Env,T,H,Ev,Ru)→(Oc,Sc,Rc,Scc,Kc,Ec,Vc,T)\boxed{ CE: (I,O_f,S_f,R_f,K_f,C,Env,T,H,E_v,Ru) \rightarrow (O_c,S_c,R_c,Sc_c,K_c,E_c,V_c,T) }

这才是CognitiveEngine的完整输入输出定义。

---

209.17 CognitiveContext的定义

CognitiveEngine输出的五类计算结果还需要形成统一上下文。

因此定义：

CC=(I,O,S,R,Sc,K,C,Env,T,V)CC=(I,O,S,R,Sc,K,C,Env,T,V)

其中：

• I：Individual；
• O：经过ObjectEngine确认的对象结果；
• S：经过StateEngine计算和验证的状态结果；
• R：经过RelationEngine计算和验证的关系结果；
• Sc：经过SceneEngine形成的场景；
• K：经过KnowledgeEngine计算的知识；
• C：当前条件；
• Env：当前环境；
• T：当前时间；
• V：整体验证状态。

因此：

CO→CognitiveContextCO \rightarrow CognitiveContext

---

209.18 CognitiveContext不是CognitiveEngine输入

这里必须再次强调：

CognitiveContext≠CognitiveEngineInputCognitiveContext \neq CognitiveEngineInput

在一个新的认知周期中：

上一周期 CognitiveContext

可以成为下一周期的：

事实来源

但必须经过重新读取、验证和转换。

即：

CognitiveContext_t
↓
Fact Extraction
↓
Current Fact Validation
↓
CognitiveEngine Input_{t+1}
↓
CognitiveContext_{t+1}

而不能简单：

CognitiveContext
↓
直接作为下一次输入

否则过去计算结果可能被错误地当成当前事实。

---

209.19 Current Fact与Calculated Result

因此ICAI必须严格区分四类数据：

Fact
Candidate
Calculated Result
Verified Result

例如：

State Fact
↓
State Candidate
↓
Calculated State
↓
Verified State

同样：

Knowledge Fact
↓
Knowledge Candidate
↓
Calculated Knowledge
↓
Verified Knowledge

因此：

Fact≠Candidate≠Calculated≠VerifiedFact \neq Candidate \neq Calculated \neq Verified

这是CognitiveEngine避免认知错误的重要机制。

---

209.20 CognitiveEngine不直接修改输入事实

CognitiveEngine原则上执行：

Input→Calculation→OutputInput \rightarrow Calculation \rightarrow Output

而不是：

Input→Calculation→直接修改数据库Input \rightarrow Calculation \rightarrow 直接修改数据库

例如：

State Fact:
ready

经过StateEngine计算：

Candidate:
running

CognitiveEngine输出：

StateCandidate = running

然后由：

StateService

负责正式状态转换和保存。

因此：

CognitiveEngine≠UpdateEngineCognitiveEngine \neq UpdateEngine

---

209.21 CognitiveEngine与UpdateEngine

两者关系可以严格定义为：

CognitiveEngine
负责：
“现在认知到什么？”

UpdateEngine负责：

“确认后的变化如何正式应用？”

因此：

CognitiveEngine→CognitiveContextCognitiveEngine \rightarrow CognitiveContext

而：

LearningEngine→UpdateCandidateLearningEngine \rightarrow UpdateCandidate

最后：

UpdateEngine→Updated StructureUpdateEngine \rightarrow Updated\ Structure

更新后：

Updated Structure→CognitiveEngineUpdated\ Structure \rightarrow CognitiveEngine

重新建立新的CognitiveContext。

---

209.22 修正后的PHP输入结构

PHP中不应该直接把已经计算好的：

'scene'
'knowledge'

作为基础输入。

正确输入应该接近：

$input = array(
    'individual' => $individual,

    'object_facts' => $objectFacts,

    'state_facts' => $stateFacts,

    'relation_facts' => $relationFacts,

    'knowledge_facts' => $knowledgeFacts,

    'condition' => $condition,

    'environment' => $environment,

    'time' => $time,

    'history' => $history,

    'evidence' => $evidence,

    'rules' => $rules
);

然后CognitiveEngine内部逐步生成：

$objectResult
$stateResult
$relationResult
$sceneResult
$knowledgeResult

---

209.23 修正后的PHP输出结构

最终输出：

$result = array(
    'engine' => 'CognitiveEngine',

    'object' => $objectResult,

    'state' => $stateResult,

    'relation' => $relationResult,

    'scene' => $sceneResult,

    'knowledge' => $knowledgeResult,

    'evidence' => $evidenceResult,

    'verification' => $verificationResult,

    'time' => $time
);

因此：

Input
=
Facts + Context + Rules

而：

Output
=
Calculated Cognitive Structure + Evidence + Verification

---

209.24 最终输入输出边界

最终可以用下面的结构固定CognitiveEngine边界：

┌──────────────────────────────┐
│ CognitiveEngine Input        │
│                              │
│ Individual                   │
│ Object Facts                 │
│ State Facts                  │
│ Relation Facts               │
│ Knowledge Facts              │
│ Condition                    │
│ Environment                  │
│ Time                         │
│ History                      │
│ Evidence                     │
│ Rules                        │
└──────────────┬───────────────┘
               ↓
        CognitiveEngine
               ↓
┌──────────────┴───────────────┐
│                              │
│ ObjectEngine                 │
│ StateEngine                  │
│ RelationEngine               │
│ SceneEngine                  │
│ KnowledgeEngine              │
│                              │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ CognitiveEngine Output       │
│                              │
│ Object Result                │
│ State Result                 │
│ Relation Result              │
│ Scene Result                 │
│ Knowledge Result             │
│ Evidence                     │
│ Verification                │
│ Time                         │
└──────────────┬───────────────┘
               ↓
        CognitiveContext

---

209.25 最终统一定义

因此，本章最终采用以下定义。

CognitiveEngine输入

CI=(I,Of,Sf,Rf,Kf,C,Env,T,H,Ev,Ru)\boxed{ CI=(I,O_f,S_f,R_f,K_f,C,Env,T,H,E_v,Ru) }

其中：

• I = Individual；
• O_f = Object Facts；
• S_f = State Facts；
• R_f = Relation Facts；
• K_f = Knowledge Facts；
• C = Condition；
• Env = Environment；
• T = Time；
• H = History；
• E_v = Evidence；
• Ru = Rule。

CognitiveEngine输出

CO=(Oc,Sc,Rc,Scc,Kc,Ec,Vc,T)\boxed{ CO=(O_c,S_c,R_c,Sc_c,K_c,E_c,V_c,T) }

其中：

• O_c = Object Calculation Result；
• S_c = State Calculation Result；
• R_c = Relation Calculation Result；
• Sc_c = Scene Calculation Result；
• K_c = Knowledge Calculation Result；
• E_c = Calculation Evidence；
• V_c = Calculation Verification；
• T = Calculation Time。

CognitiveContext

CC=(I,O,S,R,Sc,K,C,Env,T,V)\boxed{ CC=(I,O,S,R,Sc,K,C,Env,T,V) }

因此完整关系为：

Input Facts→CognitiveEngine→Calculated Results→CognitiveContext\boxed{ Input\ Facts \rightarrow CognitiveEngine \rightarrow Calculated\ Results \rightarrow CognitiveContext }

---

209.26 本次修正后的核心原则

由此，CognitiveEngine的概念边界可以严格确定：

CognitiveEngine不把自己将要计算出来的Scene和Knowledge直接作为基础输入，而是以当前可验证事实、条件、环境、时间、历史、证据和规则作为输入，依次调用ObjectEngine、StateEngine、RelationEngine、SceneEngine和KnowledgeEngine，形成对象、状态、关系、场景和知识计算结果，并最终构造CognitiveContext。

因此：

Facts+Context+Rules→Cognitive Calculation→Cognitive Context\boxed{ Facts+Context+Rules \rightarrow Cognitive\ Calculation \rightarrow Cognitive\ Context }

而不是：

Object+State+Relation+Scene+Knowledge→CognitiveEngine\boxed{ Object+State+Relation+Scene+Knowledge \rightarrow CognitiveEngine }

后者把“认知结果”错误地同时定义成“认知输入”。

修正之后，ICAI的认知计算链变成：

当前事实
↓
对象计算
↓
状态计算
↓
关系计算
↓
场景计算
↓
知识计算
↓
CognitiveContext
↓
Capability
↓
Matching
↓
Method
↓
Decision

这使得 输入事实、计算结果、候选结果、验证结果、正式更新结构 五者能够严格分离，也为后续Cognitive Runtime、CognitiveService以及整个ICAI运行时体系提供了稳定的数据边界。

第209章补充　统一认知计算的依赖方向

209.48 为什么必须统一依赖方向

在ICAI中，Engine数量不断增加：

ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine
CapabilityEngine
MatchingEngine
MethodEngine
DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine
FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine
MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

如果这些Engine之间允许任意调用，就容易形成：

A → B
B → C
C → A

或者：

ObjectEngine
↔ StateEngine
↔ RelationEngine
↔ SceneEngine
↔ KnowledgeEngine

这种结构会产生三个严重问题：

1. 循环依赖；
2. 认知计算顺序不确定；
3. 一个局部更新可能导致无限级联计算。

因此必须建立：

DependencyDirectionDependencyDirection

即：

每一个Engine知道自己依赖什么，也知道哪些Engine可以依赖自己。

---

209.49 统一依赖方向的基本原则

ICAI Engine依赖必须遵循：

LowerLayer→HigherLayerLowerLayer \rightarrow HigherLayer

这里的“低层”和“高层”不是重要程度，而是计算依赖程度。

基础事实越靠前：

Object
State
Relation

组合认知越靠后：

Scene
Knowledge

行动认知继续向上：

Capability
Method
Decision
Behavior
Action
Execution

反馈学习再形成闭环：

Feedback
Memory
Experience
Learning
Update

因此整个Engine层应当形成有方向的计算图。

---

209.50 第一原则：基础事实向上依赖

最基础的方向是：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

其含义不是说StateEngine必须调用ObjectEngine，而是：

State的计算需要Object作为Owner，Relation需要Object和State，Scene需要Object、State和Relation，Knowledge需要事实、关系、场景和规则。

因此依赖集合可以表示为：

Dep(State)⊇ObjectDep(State)\supseteq Object Dep(Relation)⊇Object+StateDep(Relation)\supseteq Object+State Dep(Scene)⊇Object+State+RelationDep(Scene)\supseteq Object+State+Relation Dep(Knowledge)⊇Object+State+Relation+SceneDep(Knowledge)\supseteq Object+State+Relation+Scene

---

209.51 ObjectEngine处于基础位置

ObjectEngine负责：

对象身份
对象类型
对象属性
对象结构
对象匹配
对象变化

因此：

ObjectEngineObjectEngine

原则上不依赖：

DecisionEngine
MethodEngine
BehaviorEngine
LearningEngine

也不应该出现：

ObjectEngine → DecisionEngine

因为对象是什么，不应该由一个决策结果决定。

正确方向：

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

---

209.52 StateEngine的依赖方向

StateEngine计算：

当前状态
状态转换
状态验证

它需要知道：

Object
Event
Condition
Rule

因此：

Object
↓
StateEngine

但是：

StateEngine
↓
ObjectEngine

不应该成为直接计算依赖。

例如：

Object-A
State = ready

StateEngine可以根据实际Event计算：

ready
→
running

但它不应该要求ObjectEngine再次决定：

Object-A是什么？

对象身份应当已经由上游提供。

---

209.53 RelationEngine的依赖方向

RelationEngine需要：

Source Object
Target Object
Relation Type
Condition
State

因此：

RelationEngine←Object+StateRelationEngine \leftarrow Object + State

正确方向：

Object
↓
State
↓
Relation

例如：

Object-A
Object-B

先确定两个对象。

然后：

A depends_on B

再计算关系状态：

active

因此RelationEngine不能反过来要求ObjectEngine根据关系重新创造对象。

---

209.54 SceneEngine的依赖方向

Scene是更高层的组合结构。

因此：

Scene=Object+State+Relation+Condition+EnvironmentScene = Object + State + Relation + Condition + Environment

所以：

ObjectEngine
       ↓
StateEngine
       ↓
RelationEngine
       ↓
SceneEngine

SceneEngine原则上不应该成为ObjectEngine的基础依赖。

错误：

ObjectEngine
→
SceneEngine
→
ObjectEngine

正确：

Object
+
State
+
Relation
+
Environment
↓
SceneEngine
↓
Scene

---

209.55 KnowledgeEngine的依赖方向

KnowledgeEngine是基础认知层的最后一个Engine。

它可以使用：

Object
State
Relation
Scene
Condition
Rule
Evidence

因此：

Object
State
Relation
Scene
     ↓
KnowledgeEngine

形成：

K=f(O,S,R,Sc,C,Ru)K = f(O,S,R,Sc,C,Ru)

其中：

• O：Object；
• S：State；
• R：Relation；
• Sc：Scene；
• C：Condition；
• Ru：Rule。

KnowledgeEngine不应该反向成为ObjectEngine的计算依赖。

---

209.56 第一层依赖图

因此基础认知Engine可以统一表示为：

                Object
              /   |   \
             ↓    ↓    ↓
          State Relation
             \     /
              \   /
               Scene
                 ↓
             Knowledge

更加严格地表示：

O→S→R→Sc→KO \rightarrow S \rightarrow R \rightarrow Sc \rightarrow K

但是实际允许部分并行：

O→SO \rightarrow S O+S→RO+S \rightarrow R O+S+R→ScO+S+R \rightarrow Sc O+S+R+Sc→KO+S+R+Sc \rightarrow K

这比简单线性链更加准确。

---

209.57 第二原则：能力依赖认知上下文

CapabilityEngine回答：

当前对象、状态、条件和范围下，是否具备某种能力？

因此它依赖：

Object
State
Scene
Knowledge
Condition

形成：

Object
State
Relation
Scene
Knowledge
       ↓
CapabilityEngine

即：

Capability=f(O,S,Sc,K,C)Capability = f(O,S,Sc,K,C)

因此CapabilityEngine不能成为：

ObjectEngine
StateEngine
SceneEngine

的基础依赖。

---

209.58 MatchingEngine的依赖方向

MatchingEngine负责：

对象匹配
属性匹配
状态匹配
能力匹配
方法匹配

因此它需要已有认知结构。

依赖方向：

Object
State
Relation
Scene
Knowledge
Capability
Method
        ↓
MatchingEngine

特别需要注意：

MatchingEngine负责计算“是否匹配”，不负责最终决定“选择谁”。

因此：

MatchingEngine→DecisionEngineMatchingEngine \rightarrow DecisionEngine

而不是：

DecisionEngine→MatchingEngine→DecisionEngineDecisionEngine \rightarrow MatchingEngine \rightarrow DecisionEngine

如果需要重新匹配，应该由上层Service重新发起新的计算周期。

---

209.59 MethodEngine的依赖方向

MethodEngine需要：

Goal
Object
State
Scene
Capability
Knowledge
Resource
Condition

因此：

CognitiveContext
      ↓
CapabilityEngine
      ↓
MatchingEngine
      ↓
MethodEngine

但MethodEngine不能反向成为CapabilityEngine的直接依赖。

例如：

Capability:
can_process

可以帮助判断：

Method-M1

是否适用。

但是MethodEngine不能在计算方法过程中直接修改Capability。

如果发现能力可能变化，应产生：

Capability Update Candidate

交给：

LearningEngine / UpdateEngine

处理。

---

209.60 DecisionEngine的依赖方向

DecisionEngine位于选择层。

它可以读取：

Goal
Capability
Method Candidates
Matching Result
Risk
Conflict
Knowledge
State
Resource

因此：

Cognitive Context
        ↓
Capability
        ↓
Method
        ↓
Matching
        ↓
Risk / Conflict
        ↓
DecisionEngine

DecisionEngine输出：

Selected Candidate

但是DecisionEngine不应该反向控制：

ObjectEngine
StateEngine
RelationEngine

它可以提出：

Required State
Required Capability
Required Method

真正的状态变化仍由StateEngine和UpdateEngine负责。

---

209.61 BehaviorEngine的依赖方向

DecisionEngine完成：

选择哪个方案

BehaviorEngine负责：

如何组织选定方案的行为

因此：

Decision→BehaviorDecision \rightarrow Behavior

形成：

DecisionEngine
↓
BehaviorEngine

BehaviorEngine需要：

Selected Method
Goal
Object
Current State
Capability
Actions

但它不应该重新做最终Decision。

因此：

BehaviorEngine≠DecisionEngineBehaviorEngine \neq DecisionEngine

---

209.62 ActionEngine的依赖方向

BehaviorEngine形成：

Action Sequence

ActionEngine负责：

Action Calculation
Action Validation
Action Execution Preparation
Action Result

因此：

BehaviorEngine
↓
ActionEngine

ActionEngine不能反向修改Behavior结构。

如果Action失败：

Action Failure
↓
Result
↓
Feedback
↓
Diagnosis

而不是：

ActionEngine
→
BehaviorEngine
→
ActionEngine

---

209.63 ExecutionEngine的依赖方向

ExecutionEngine是真实运行层。

因此：

Behavior
↓
Action
↓
Execution

ExecutionEngine负责：

实际执行
运行状态
实际结果
执行证据

它不能把：

Actual Result

直接修改为：

Expected Result

实际结果必须进入：

FeedbackEngine

进行比较。

因此：

Execution→Result→FeedbackExecution \rightarrow Result \rightarrow Feedback

---

209.64 FeedbackEngine的依赖方向

FeedbackEngine接收：

Execution
Result
State
Environment
Evidence

然后计算：

Expected vs Actual
State Change
Environment Change

因此：

ExecutionEngine
↓
FeedbackEngine

FeedbackEngine产生：

Feedback

随后进入：

MemoryEngine
ExperienceEngine
RiskEngine
ConflictEngine
DiagnosisEngine

但FeedbackEngine不应该直接决定：

Repair
Method Change
Capability Invalid

这些由对应Engine负责。

---

209.65 Diagnosis与Risk、Conflict的依赖方向

RiskEngine：

未来可能发生什么问题？

ConflictEngine：

当前存在什么结构冲突？

DiagnosisEngine：

已经发生的异常为什么发生？

因此三者不能混成一个Engine。

正确关系：

Current State
      ↓
RiskEngine
      ↓
Risk

Current Structure
      ↓
ConflictEngine
      ↓
Conflict

Actual Failure
      ↓
DiagnosisEngine
      ↓
Cause

如果实际异常已经发生：

Feedback
↓
Abnormality
↓
DiagnosisEngine

Risk和Conflict可以作为DiagnosisEngine的证据输入。

---

209.66 ProtectionEngine与RepairEngine

ProtectionEngine解决：

如何避免风险扩大

RepairEngine解决：

已经出现问题后如何恢复

因此：

Risk
↓
ProtectionEngine

而：

Abnormality
↓
Diagnosis
↓
RepairEngine

两者不能反向混合。

正确结构：

RiskEngine
↓
ProtectionEngine

DiagnosisEngine
↓
RepairEngine

---

209.67 MemoryEngine与ExperienceEngine

MemoryEngine依赖实际历史：

History
↓
MemoryEngine
↓
Memory

ExperienceEngine使用：

History
+
Memory
+
Comparison
+
Relation

形成：

Experience

因此：

Memory→ExperienceMemory \rightarrow Experience

但是ExperienceEngine不能直接修改Memory。

如果产生新的Memory变化：

Experience Result
↓
Learning
↓
Update

再由UpdateEngine完成正式更新。

---

209.68 LearningEngine的依赖方向

LearningEngine使用：

Result
Feedback
History
Memory
Experience
Knowledge
Verification
Diagnosis
Repair
Risk
Conflict

计算：

Learning Candidate

因此：

Feedback
Memory
Experience
Diagnosis
Verification
       ↓
LearningEngine

LearningEngine输出：

Update Candidate

然后：

LearningEngine
↓
UpdateEngine

这是非常重要的单向边界。

---

209.69 UpdateEngine的依赖方向

UpdateEngine是结构落实层。

它接收：

Verified Change
Update Candidate
Rule
Condition

然后更新：

State
Knowledge
Capability
Individual Structure

因此：

LearningEngine
        ↓
UpdateEngine
        ↓
State / Knowledge / Capability / Individual

UpdateEngine完成后，新的结构再次进入：

CognitiveEngine

形成：

Update→ReCognitionUpdate \rightarrow ReCognition

---

209.70 完整依赖方向

综合所有Engine，可以形成：

                           Object
                             ↓
                           State
                             ↓
                          Relation
                             ↓
                           Scene
                             ↓
                         Knowledge
                             ↓
                        Capability
                             ↓
                         Matching
                             ↓
                           Method
                             ↓
                         Decision
                             ↓
                         Behavior
                             ↓
                           Action
                             ↓
                         Execution
                             ↓
                           Result
                             ↓
                         Feedback
                 ┌───────────┼────────────┐
                 ↓           ↓            ↓
               Risk       Conflict     Diagnosis
                 ↓           ↓            ↓
             Protection                Repair
                 └───────────┬────────────┘
                             ↓
                           Memory
                             ↓
                         Experience
                             ↓
                          Learning
                             ↓
                           Update
                             ↓
                 ┌───────────┼─────────────┐
                 ↓           ↓             ↓
               State      Knowledge     Capability
                 └───────────┼─────────────┘
                             ↓
                    Individual Structure
                             ↓
                      Cognitive Context
                             ↓
                     Re-Cognition

这里最重要的是：

Update之后不是直接回到Decision，而是先重新建立Cognitive Context。

---

209.71 依赖方向不是简单直线

虽然可以把系统画成一条主链：

O→S→R→Sc→K→C→M→DO \rightarrow S \rightarrow R \rightarrow Sc \rightarrow K \rightarrow C \rightarrow M \rightarrow D

但实际计算应该是一个有向无环计算图。

例如：

Object
├── State
├── Relation
└── Attribute

Object + State
↓
Relation

Object + State + Relation
↓
Scene

Object + State + Relation + Scene
↓
Knowledge

Knowledge + State + Scene
↓
Capability

因此：

DependencyGraphDependencyGraph

比简单的：

A→B→CA\rightarrow B\rightarrow C

更加准确。

---

209.72 为什么不能允许双向Engine依赖

例如：

KnowledgeEngine
↔
CapabilityEngine

看起来很方便：

Knowledge帮助能力计算
能力又帮助知识计算

但会产生：

Knowledge
↓
Capability
↓
Knowledge
↓
Capability
↓
...

因此必须把：

计算依赖

与：

更新反馈

分开。

正确结构：

Knowledge
↓
Capability Calculation
↓
Capability Result
↓
Learning
↓
Update
↓
Knowledge Update

即：

Calculate≠UpdateCalculate \neq Update

这是ICAI避免循环依赖的关键原则。

---

209.73 计算依赖与数据反馈的区别

必须明确区分：

计算依赖

表示：

A需要B的结果才能计算

例如：

Scene←RelationScene \leftarrow Relation

数据反馈

表示：

A产生结果后，
未来可能导致B更新

例如：

Execution→Feedback→Learning→Update→KnowledgeExecution \rightarrow Feedback \rightarrow Learning \rightarrow Update \rightarrow Knowledge

因此：

A→BA\rightarrow B

不一定意味着：

A必须直接调用B。

它可能只是：

A的结果成为B未来更新的依据。

---

209.74 Engine不能直接形成闭环调用

错误结构：

KnowledgeEngine
↓
CapabilityEngine
↓
MethodEngine
↓
DecisionEngine
↓
KnowledgeEngine

正确结构：

KnowledgeEngine
↓
CapabilityEngine
↓
MethodEngine
↓
DecisionEngine
↓
Execution
↓
Feedback
↓
Learning
↓
Update
↓
KnowledgeEngine

这里虽然整个系统是闭环：

Cognition→Action→Learning→CognitionCognition \rightarrow Action \rightarrow Learning \rightarrow Cognition

但单个计算周期内部仍然保持：

DAG=Directed Acyclic GraphDAG = Directed\ Acyclic\ Graph

即：

有向无环计算图。

---

209.75 Cognitive Cycle与Dependency Graph

因此ICAI同时存在两个结构。

第一个是：

DependencyGraphDependencyGraph

负责：

一次计算周期内部

第二个是：

CognitiveCycleCognitiveCycle

负责：

多个计算周期之间

可以表示为：

Cycle t

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge
↓
Capability
↓
Method
↓
Decision
↓
Execution
↓
Result

Cycle Boundary

Feedback
↓
Learning
↓
Update

Cycle t+1

Object
↓
State
↓
Relation
↓
Scene
↓
Knowledge

因此：

DependencyGraph+CognitiveCycleDependencyGraph + CognitiveCycle

共同构成ICAI统一认知计算架构。

---

209.76 统一依赖层级

最终可以把Engine划分为八个依赖层。

Level 0：事实对象层

ObjectEngine

---

Level 1：状态结构层

StateEngine
RelationEngine

---

Level 2：情境认知层

SceneEngine

---

Level 3：知识认知层

KnowledgeEngine

---

Level 4：能力与方法层

CapabilityEngine
MatchingEngine
MethodEngine

---

Level 5：决策与行为层

DecisionEngine
BehaviorEngine
ActionEngine
ExecutionEngine

---

Level 6：反馈与问题处理层

FeedbackEngine
RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine

---

Level 7：学习与结构更新层

MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

但是Level 7更新完成之后，不是向Level 6无限反向调用，而是：

Update
↓
New Runtime State
↓
Level 0～3 Re-Cognition

重新开始新的认知周期。

---

209.77 统一依赖规则

因此可以建立ICAI Engine的七条依赖规则。

规则一：低层不能依赖高层

例如：

ObjectEngine

不能依赖：

DecisionEngine

---

规则二：同层Engine原则上不直接循环依赖

例如：

RiskEngine
↔
ConflictEngine

如果需要互相提供信息，应通过：

Context
Result
Service

传递。

---

规则三：计算Engine不直接修改其他Engine的数据

例如：

KnowledgeEngine

不能直接：

UPDATE capabilities

必须产生结果或Candidate。

---

规则四：Update统一负责正式结构更新

正式结构改变统一进入：

UpdateEngine

或者由对应Domain Service协调UpdateEngine。

---

规则五：Execution不修改认知结论

Execution只产生：

Actual Result

认知解释交给：

Feedback
Diagnosis
Learning

---

规则六：Learning不直接修改正式结构

Learning产生：

Learning Result
Update Candidate

正式修改交给：

UpdateEngine

---

规则七：Update后必须重新认知

Update→Re−CognitionUpdate \rightarrow Re-Cognition

不能直接假设旧CognitiveContext仍然有效。

---

209.78 统一依赖方向的PHP工程表达

在PHP OOP中，可以通过依赖注入保持方向。

例如：

class CognitiveEngine
{
    protected $objectEngine;
    protected $stateEngine;
    protected $relationEngine;
    protected $sceneEngine;
    protected $knowledgeEngine;

    public function __construct(
        $objectEngine,
        $stateEngine,
        $relationEngine,
        $sceneEngine,
        $knowledgeEngine
    ) {
        $this->objectEngine = $objectEngine;
        $this->stateEngine = $stateEngine;
        $this->relationEngine = $relationEngine;
        $this->sceneEngine = $sceneEngine;
        $this->knowledgeEngine = $knowledgeEngine;
    }
}

这里表达：

CognitiveEngine
↓
ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

而不是：

ObjectEngine
↓
CognitiveEngine

---

209.79 禁止Engine直接依赖Controller

Engine层不应该出现：

class ObjectEngine
{
    protected $controller;
}

也不应该：

class KnowledgeEngine
{
    protected $smarty;
}

或者：

class StateEngine
{
    protected $database;
}

Engine应该依赖：

Domain Object
Rule
Condition
Runtime Context
Engine Result

而不是：

HTTP Request
Controller
Smarty
MySQL

这样才能保持Engine层独立。

---

209.80 Engine与Repository的方向

推荐：

Service
↓
Engine
↓
Domain Object

以及：

Service
↓
Repository
↓
MySQL

而不是：

Engine
↓
Repository
↓
MySQL

如果Engine直接依赖Repository，就会导致：

Calculation
+
Persistence

混合。

因此更严格的结构是：

Controller
↓
Service
├── Repository
└── Engine
       ↓
   Domain Object

Service负责把二者组合起来。

---

209.81 CognitiveService统一编排

最终可以定义：

Controller
↓
CognitiveService
↓
CognitiveEngine
├── ObjectEngine
├── StateEngine
├── RelationEngine
├── SceneEngine
└── KnowledgeEngine
↓
CognitiveContext

然后：

CognitiveContext
↓
CapabilityService
↓
CapabilityEngine
↓
MethodService
↓
MethodEngine
↓
DecisionService
↓
DecisionEngine

这样Service层和Engine层的方向也保持一致。

---

209.82 依赖方向与UpdateEngine的关系

UpdateEngine是整个体系中非常特殊的Engine。

它不是普通的“向上计算Engine”，而是：

Learning
↓
Update
↓
Structure Change

因此UpdateEngine的输出会改变：

Object
State
Relation
Knowledge
Capability
Method
Individual

这并不意味着：

UpdateEngine
→
ObjectEngine
→
UpdateEngine

而是：

UpdateEngine
↓
Persistent Structure Changed
↓
New Runtime
↓
CognitiveEngine

也就是：

Update→Runtimet+1→CognitiveEngineUpdate \rightarrow Runtime_{t+1} \rightarrow CognitiveEngine

---

209.83 最终统一依赖模型

因此ICAI可以建立最终依赖图：

                         ┌───────────────┐
                         │ ObjectEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ StateEngine   │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │RelationEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ SceneEngine   │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │KnowledgeEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │CapabilityEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │MatchingEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ MethodEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ DecisionEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ BehaviorEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │  ActionEngine │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ExecutionEngine│
                         └───────┬───────┘
                                 ↓
                              Result
                                 ↓
                         ┌───────────────┐
                         │FeedbackEngine │
                         └───────┬───────┘
                                 ↓
                    ┌────────────┼────────────┐
                    ↓            ↓            ↓
                RiskEngine  ConflictEngine DiagnosisEngine
                    ↓                         ↓
             ProtectionEngine            RepairEngine
                    └────────────┬────────────┘
                                 ↓
                         ┌───────────────┐
                         │ MemoryEngine  │
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ExperienceEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ LearningEngine│
                         └───────┬───────┘
                                 ↓
                         ┌───────────────┐
                         │ UpdateEngine  │
                         └───────┬───────┘
                                 ↓
                         New Runtime State
                                 ↓
                         CognitiveEngine

其中最关键的一点是：

Engine Dependency≠Cognitive FeedbackEngine\ Dependency \neq Cognitive\ Feedback

依赖方向在一个计算周期内必须保持向前。

反馈只在一个计算周期结束之后，通过：

Feedback
→
Learning
→
Update
→
New Runtime

开启下一个计算周期。

---

209.84 本节总结

统一认知计算的核心不是让所有Engine互相调用，而是建立：

Directed Cognitive DependencyDirected\ Cognitive\ Dependency

即：

Object→State→Relation→Scene→Knowledge→Capability→Method→Decision→Behavior→Action→ExecutionObject \rightarrow State \rightarrow Relation \rightarrow Scene \rightarrow Knowledge \rightarrow Capability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution

执行之后：

Execution→Feedback→Learning→UpdateExecution \rightarrow Feedback \rightarrow Learning \rightarrow Update

再：

Update→NewRuntime→CognitiveEngineUpdate \rightarrow NewRuntime \rightarrow CognitiveEngine

因此ICAI同时具有两个层次：

DependencyGraph=DAGDependencyGraph = DAG

负责单次认知计算的有向无环依赖；

以及：

CognitiveCycleCognitiveCycle

负责跨周期的认知、执行、反馈、学习和更新闭环。

最终可以用一句话定义统一依赖方向：

ICAI的Engine在单次计算周期内必须保持由基础事实向高级认知、由认知向决策、由决策向执行的单向依赖；执行产生的反馈不得反向形成Engine调用闭环，而必须经过Feedback、Memory、Experience、Learning和Update形成新的Runtime，再重新进入CognitiveEngine。

因此：

单周期：
事实 → 认知 → 能力 → 方法 → 决策 → 行为 → 执行

跨周期：
执行 → 反馈 → 记忆 → 经验 → 学习 → 更新 → 新认知

这就把ICAI从“多个Engine的集合”进一步提升为：

DAG Cognitive Computation+Cyclic Cognitive Evolution\boxed{ DAG\ Cognitive\ Computation + Cyclic\ Cognitive\ Evolution }

即：

单周期有向无环计算，跨周期认知闭环演化。

整个结构仍然完全建立在对象、状态、关系、场景、知识、规则、条件、离散计算、历史、记忆、经验和验证之上，不需要LLM、Transformer、Embedding、Vector Search、Prompt Engineering、神经网络或LLM API。