第186章 Engine层总论

186.1 Engine层的提出

第185章已经建立了ICAI的Service统一编排体系。

其中：

IndividualService
    ↓
GoalService
    ↓
CapabilityService
    ↓
MethodService
    ↓
DecisionService
    ↓
BehaviorService
    ↓
FeedbackService
    ↓
MemoryExperienceService
    ↓
RiskConflictService
    ↓
DiagnosisRepairService
    ↓
LearningService

这些Service解决的是：

系统应该调用什么、什么时候调用、按照什么流程组织。

但是，一个完整的认知软件系统不能只有流程组织。

例如：

• CapabilityService需要判断某个能力是否满足目标；
• MethodService需要匹配可用方法；
• DecisionService需要计算候选方案；
• StateService需要判断状态是否允许转换；
• KnowledgeService需要进行知识关系推导；
• RiskConflictService需要计算风险和冲突；
• DiagnosisRepairService需要分析异常原因；
• LearningService需要判断哪些经验可以形成更新。

这些工作本质上都不是简单的Service调用。

它们需要：

规则
条件
比较
计算
匹配
推导
评分
状态转换
验证

因此，需要建立：

Engine层。

Engine是ICAI中负责领域计算与规则执行的核心计算层。

---

186.2 Engine的定义

Engine可以定义为：

Engine是ICAI中依据Domain Object、Runtime Context、Rule、Condition和Knowledge，对特定认知领域进行确定性计算、判断、匹配、推导、评分、转换和验证的计算组件。

其基本模型为：

Engine=(I,R,C,D,O)Engine=(I,R,C,D,O)

其中：

• I：Input，输入；
• R：Rule，规则；
• C：Condition，条件；
• D：Discrete Calculation，离散计算；
• O：Output，计算结果。

因此：

Engine=Input+Rule+Condition+Calculation+OutputEngine = Input + Rule + Condition + Calculation + Output

Engine的核心不是保存数据，而是：

根据明确的规则和当前运行上下文，对数据进行计算。

---

186.3 Engine不是Domain Object

这是Engine设计首先必须明确的边界。

Domain Object表示：

系统中的认知对象是什么。

Engine表示：

系统如何对这些对象进行计算。

例如：

Capability

是Domain Object。

而：

CapabilityEngine

负责判断：

Goal
+
Capability
+
Condition
+
State
+
Range
→
Capability Match Result

因此：

DomainObject≠EngineDomainObject \neq Engine

可以理解为：

Domain Object
= 被计算的对象

Engine
= 计算这些对象的机制

---

186.4 Engine不是Service

同样必须区分：

Engine≠ServiceEngine \neq Service

Service主要负责：

流程组织
Service调用
生命周期
事务协调
结果组装

Engine主要负责：

规则
计算
判断
匹配
推导
评分
转换
验证

因此：

Service
    ↓
Engine
    ↓
Calculation

而不是：

Service
    ↓
自己完成所有计算

---

186.5 Engine与Service的关系

Service和Engine属于不同抽象层。

可以定义：

Service=OrchestrationService=Orchestration Engine=ComputationEngine=Computation

因此：

Controller
    ↓
Service
    ↓
Engine
    ↓
Domain Object / Repository

例如：

CapabilityService
    ↓
CapabilityEngine

CapabilityService负责：

读取Goal
读取Individual
加载Capability
调用CapabilityEngine
保存结果
返回结果

CapabilityEngine负责：

检查Type
检查Condition
检查State
检查Range
计算Match
返回Match Result

这就是Service与Engine最基本的分工。

---

186.6 为什么不能把Engine写进Service

如果把计算全部放进Service：

class CapabilityService
{
    public function match($goal, $capability)
    {
        // Type判断
        // Condition判断
        // State判断
        // Range计算
        // Score计算
        // Verification判断
    }
}

短期看似简单。

但随着系统扩大，Service会越来越复杂：

CapabilityService
    ↓
几百个判断
几百个规则
大量条件分支
大量计算

最终形成“巨型Service”。

正确方式是：

class CapabilityService
{
    protected $engine;

    public function match($goal, $capability)
    {
        return $this->engine->match(
            $goal,
            $capability
        );
    }
}

而计算放入：

class CapabilityEngine
{
    public function match($goal, $capability)
    {
        // Capability计算规则
    }
}

这样职责清晰。

---

186.7 Engine与Domain Object的关系

Domain Object提供计算所需要的数据结构。

例如：

Goal
Capability
Method
Decision
State
Object
Knowledge
Behavior
Risk
Diagnosis

Engine读取这些对象：

Domain Object
      ↓
Engine
      ↓
Calculation Result

例如：

CapabilityEngine(Goal,Capability,State)→MatchResultCapabilityEngine(Goal,Capability,State) \rightarrow MatchResult

又例如：

DecisionEngine(Candidates,Conditions)→DecisionResultDecisionEngine(Candidates,Conditions) \rightarrow DecisionResult

因此Engine并不拥有这些对象。

它只是使用这些对象进行计算。

---

186.8 Engine与Runtime

Engine还必须区别于Runtime。

Runtime表示：

系统当前正在运行的实际环境、上下文、状态和时间。

可以定义：

Runtime=(I,O,S,C,T,E)Runtime=(I,O,S,C,T,E)

其中：

• I：当前Individual；
• O：当前Objects；
• S：当前State；
• C：当前Context；
• T：当前Time；
• E：当前Execution。

Engine则：

Engine(Runtime,Rule)→ResultEngine(Runtime,Rule) \rightarrow Result

即：

Engine使用当前Runtime和规则进行计算。

因此：

Runtime≠EngineRuntime \neq Engine

Runtime是：

当前发生了什么。

Engine是：

根据当前发生的事情应该如何计算。

---

186.9 Runtime Context

Runtime可以进一步定义为：

RC=(O,S,G,C,M,D,E,R,T)RC=(O,S,G,C,M,D,E,R,T)

其中：

• O：Object；
• S：State；
• G：Goal；
• C：Capability；
• M：Method；
• D：Decision；
• E：Execution；
• R：Result；
• T：Time。

Runtime不是永久知识。

例如：

Current State = Running

只代表：

当前运行状态是Running。

当运行结束后：

Running
→ Completed

Runtime就发生变化。

---

186.10 Engine的输入

Engine通常需要以下输入：

Domain Object
+
Current State
+
Condition
+
Rule
+
Context
+
History / Experience
+
Time

但是不同Engine所需输入不同。

例如CapabilityEngine：

Goal
Capability
State
Condition
Range
Verification

DecisionEngine：

Goal
Candidates
Conditions
Capabilities
Resources
Rules

KnowledgeEngine：

Knowledge
Object
Relation
Condition
State

LearningEngine：

History
Memory
Experience
Feedback
Verification

因此：

Engine不是一个统一的大计算器，而是一组领域计算引擎。

---

186.11 Engine的输出

Engine输出应该是明确的计算结果，而不是直接修改大量系统数据。

可以定义：

EngineResult=(I,O,C,E,S,T)EngineResult=(I,O,C,E,S,T)

其中：

• I：Input；
• O：Output；
• C：Calculation；
• E：Evidence；
• S：Result State；
• T：Time。

例如CapabilityEngine：

CapabilityMatchResult

DecisionEngine：

DecisionCalculationResult

KnowledgeEngine：

KnowledgeCalculationResult

RiskEngine：

RiskEvaluationResult

这些结果再由Service决定是否保存、更新或继续调用下一个Service。

---

186.12 Engine不应该直接承担完整业务流程

例如错误设计：

class DecisionEngine
{
    public function run()
    {
        $this->loadGoal();
        $this->loadCapability();
        $this->saveMethod();
        $this->executeBehavior();
        $this->saveResult();
    }
}

这是错误的。

因为DecisionEngine本应该负责：

Decision Calculation。

而不是：

完整Individual流程。

正确结构：

IndividualService
    ↓
DecisionService
    ↓
DecisionEngine
    ↓
DecisionResult

Engine只完成自己的计算任务。

---

186.13 Engine的确定性原则

ICAI Engine必须坚持确定性计算原则。

对于相同输入：

Input+Rule+Context→OutputInput+Rule+Context \rightarrow Output

在规则和上下文不发生变化的情况下，应产生可解释的结果。

例如：

State = Available
Condition = Satisfied
Range = Valid
Capability = Verified

则：

CapabilityMatch = TRUE

计算过程可以追溯：

Type Match
Condition Match
State Match
Range Match
Verification Match

因此：

Engine结果必须能够说明“为什么得到这个结果”。

---

186.14 Engine与规则

Engine不是规则本身。

规则可以独立存在：

Rule

Engine负责执行规则：

Rule
↓
Engine
↓
Result

例如：

R1:State=Available∧Condition=True→Executable=TrueR_1: State=Available \land Condition=True \rightarrow Executable=True

Engine执行：

CapabilityEngine
+
R1
+
Current Capability
→
Executable

这样可以进一步形成：

Rule
RuleSet
RuleEngine
DomainEngine

---

186.15 Engine与Condition

Condition是Engine计算的重要输入。

例如：

Capability
Condition
State

Engine判断：

Match=Capability∧Condition∧StateMatch = Capability \land Condition \land State

Condition不是Engine。

Condition描述：

什么条件成立。

Engine负责：

判断条件是否成立，以及条件成立后产生什么计算结果。

---

186.16 Engine与StateEngine

StateEngine是Engine体系中的特殊Engine。

第172章已经建立StateService。

现在可以进一步形成：

StateService
    ↓
StateEngine
    ↓
State Transition

StateEngine负责：

T(S1,E,C)→S2T(S_1,E,C)\rightarrow S_2

其中：

• S1：当前状态；
• E：事件；
• C：条件；
• S2：新状态。

例如：

Ready
→ Execute
→ Running

然后：

Running
→ Success
→ Completed

或者：

Running
→ Failure
→ Failed

StateService负责协调和保存。

StateEngine负责状态转换计算。

---

186.17 Engine的分类

ICAI可以建立多个领域Engine。

第一类：基础计算Engine。

StateEngine
RelationEngine
ConditionEngine
ValidationEngine

第二类：认知Engine。

KnowledgeEngine
GoalEngine
CapabilityEngine
MethodEngine
DecisionEngine

第三类：运行Engine。

BehaviorEngine
ActionEngine
ExecutionEngine
FeedbackEngine

第四类：问题处理Engine。

RiskEngine
ConflictEngine
DiagnosisEngine
RepairEngine

第五类：学习Engine。

MemoryEngine
ExperienceEngine
LearningEngine

这些Engine共同组成ICAI计算层。

---

186.18 Engine层结构

可以形成：

                         Engine Layer
                              │
        ┌─────────────────────┼─────────────────────┐
        ↓                     ↓                     ↓
   Basic Engines        Cognitive Engines      Runtime Engines
        │                     │                     │
 StateEngine             GoalEngine          BehaviorEngine
 RelationEngine          CapabilityEngine    ActionEngine
 ConditionEngine         MethodEngine        ExecutionEngine
 ValidationEngine        DecisionEngine      FeedbackEngine
        │                     │                     │
        └─────────────────────┼─────────────────────┘
                              ↓
                    Problem / Learning Engines
                              │
             ┌────────────────┼────────────────┐
             ↓                ↓                ↓
         RiskEngine      DiagnosisEngine   LearningEngine
         ConflictEngine  RepairEngine      ExperienceEngine

这就是Engine层的基本总架构。

---

186.19 Engine与Repository

Engine与Repository也必须分离。

Repository负责：

从数据库读取和保存数据。

Engine负责：

对读取的数据进行计算。

正确结构：

Service
   ↓
Repository → Load Data
   ↓
Engine → Calculate
   ↓
Service → Decide / Save
   ↓
Repository → Persist

而不是：

Engine
   ↓
SQL
   ↓
Calculation

Engine直接大量操作SQL会使计算层与数据库强耦合。

---

186.20 Engine的PHP基础结构

可以建立统一Engine基础类：

abstract class Engine
{
    protected $rules;

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

    public function getRules()
    {
        return $this->rules;
    }

    abstract public function calculate($input);
}

然后：

class CapabilityEngine extends Engine
{
    public function calculate($input)
    {
        $result = array();

        $result['type'] = $this->matchType($input);
        $result['condition'] = $this->matchCondition($input);
        $result['state'] = $this->matchState($input);
        $result['range'] = $this->matchRange($input);

        $result['matched'] =
            $result['type'] &&
            $result['condition'] &&
            $result['state'] &&
            $result['range'];

        return $result;
    }

    protected function matchType($input)
    {
        return true;
    }

    protected function matchCondition($input)
    {
        return true;
    }

    protected function matchState($input)
    {
        return true;
    }

    protected function matchRange($input)
    {
        return true;
    }
}

这里使用的是普通PHP OOP结构，不依赖任何生成式模型。

---

186.21 EngineResult对象

为了避免Engine直接返回混乱数组，可以建立：

class EngineResult
{
    protected $success;
    protected $data;
    protected $reason;
    protected $evidence;

    public function __construct()
    {
        $this->success = false;
        $this->data = array();
        $this->reason = '';
        $this->evidence = array();
    }

    public function setSuccess($value)
    {
        $this->success = $value;
    }

    public function getSuccess()
    {
        return $this->success;
    }

    public function setData($data)
    {
        $this->data = $data;
    }

    public function getData()
    {
        return $this->data;
    }
}

Engine输出统一结果对象后，Service可以根据结果进行后续流程控制。

---

186.22 Engine与Runtime Context

Engine真正运行时不能只依赖静态Domain Object。

它还需要当前Runtime。

例如：

Capability

本身可能表示：

Range = 100
State = Available

但是Runtime可能是：

Current Object State = Maintenance

那么Engine判断：

Capability本身存在
+
Runtime条件不满足
=
当前不可用

因此：

EngineResult=f(DomainObject,Runtime,Rule)EngineResult = f(DomainObject,Runtime,Rule)

这是ICAI Engine设计中的核心公式之一。

---

186.23 Runtime是动态的

Runtime具有时间性：

Runtimet≠Runtimet+1Runtime_t \neq Runtime_{t+1}

例如：

t1:
State = Ready

t2:
State = Running

t3:
State = Completed

同一个Engine面对不同Runtime可能产生不同结果。

例如：

Decisiont=f(Candidates,Runtimet,Rules)Decision_t=f(Candidates,Runtime_t,Rules)

而：

Decisiont+1=f(Candidates,Runtimet+1,Rules)Decision_{t+1}=f(Candidates,Runtime_{t+1},Rules)

所以：

Engine不是固定输出器，而是基于当前Runtime进行动态计算的确定性组件。

---

186.24 Runtime与Memory的区别

Runtime：

当前发生什么。

Memory：

过去保留什么。

例如：

Runtime:
Object A = Available

Memory：

Object A
过去曾经在Condition C下成功执行Method M

Engine可以同时使用：

Current Runtime
+
Relevant Memory
+
Experience
+
Rules

但是：

过去记忆不能直接覆盖当前事实。

当前Runtime优先描述当前状态。

Memory用于辅助判断。

---

186.25 Runtime与Experience的关系

Experience不是Runtime。

Experience：

过去形成的结构化模式

Runtime：

当前实际上下文

因此：

Decision=f(Runtime,Experience,Knowledge,Rules)Decision = f(Runtime,Experience,Knowledge,Rules)

而不是：

Decision=f(Experience)Decision=f(Experience)

这保证ICAI不会因为过去经验而忽略当前实际状态。

---

186.26 Engine中的证据机制

Engine计算最好保留Evidence。

例如DecisionEngine：

Candidate A
Score = 82

Evidence:
Capability = Available
Condition = Valid
Risk = Low
History = Verified

最终：

Selected Candidate = A

这样Decision可以解释：

为什么选择A。

同样KnowledgeEngine可以说明：

Fact A → Relation B

来自哪些对象、状态和关系。

因此Engine输出不仅应该有：

result

还应该尽量包含：

calculation
evidence
reason

---

186.27 Engine计算的可追溯性

ICAI Engine应当支持：

Input→Rule→Calculation→ResultInput \rightarrow Rule \rightarrow Calculation \rightarrow Result

例如：

Input:
Goal G1
Capability C1

Rule:
Capability Type must match Goal Type

Calculation:
TypeMatch = TRUE

Result:
Capability Candidate = Valid

这样任何一个结果都能够回溯。

这对于：

• 调试；
• 审计；
• 诊断；
• 学习；
• 经验形成；
• 方法更新；

都非常重要。

---

186.28 Engine的无副作用原则

Engine最好遵循：

计算与持久化分离。

例如：

Engine
→ Calculate
→ Return Result

而不是：

Engine
→ Calculate
→ UPDATE database
→ DELETE data
→ CREATE data

数据库更新应由Service协调Repository完成。

因此：

Engine→ResultEngine \rightarrow Result

而：

Service→Engine→Result→RepositoryService \rightarrow Engine \rightarrow Result \rightarrow Repository

这样可以降低Engine的副作用。

---

186.29 Engine与事务的关系

Engine本身一般不应该控制业务事务。

事务属于Service/Application层。

正确关系：

IndividualService
    ↓
Begin Transaction
    ↓
DecisionService
    ↓
DecisionEngine
    ↓
Result
    ↓
DecisionRepository
    ↓
Commit

Engine只是计算。

因此：

Transaction∈ServiceTransaction \in Service

而不是：

Transaction∈EngineTransaction \in Engine

特殊情况下，Engine内部可能需要一致性读取，但业务事务边界仍由上层Service管理。

---

186.30 Engine层的完整调用模型

最终可以定义：

Controller
      ↓
IndividualService
      ↓
Domain Service
      ↓
Engine
      ↓
Domain Object / Runtime Context
      ↓
EngineResult
      ↓
Domain Service
      ↓
Repository
      ↓
MySQL

其中：

Controller
= 请求入口

IndividualService
= 总体编排

Domain Service
= 领域流程

Engine
= 领域计算

Domain Object
= 认知对象

Runtime
= 当前运行环境

Repository
= 数据持久化

---

186.31 Engine层与完整ICAI架构

现在可以将ICAI整体架构进一步明确：

                         ICAI
                          │
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
   Presentation      Application        Persistence
        │                 │                 │
   Controller       IndividualService    Repository
                         │
                  Domain Services
                         │
                         ↓
                      Engines
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     Domain Object    Runtime         Rules

因此Engine位于：

Application与Domain Object之间的核心计算位置。

---

186.32 Engine层的核心原则

第186章可以将Engine层归纳为以下原则。

原则一：Engine负责计算

Rule
+
Condition
+
Context
→
Calculation

原则二：Service负责编排

Process
→
Service Calls
→
Transaction

原则三：Domain Object负责对象

Object
State
Relation
Data

原则四：Runtime负责当前运行状态

Current Object
+
Current State
+
Current Context
+
Current Time

原则五：Repository负责持久化

Load
Save
Update
Delete

原则六：Engine尽量无持久化副作用

Input
→
Calculate
→
Result

原则七：计算必须可解释

Input
→
Rule
→
Calculation
→
Evidence
→
Result

原则八：不使用大模型机制

Engine建立在：

符号对象
+
规则
+
条件
+
关系
+
离散计算
+
状态
+
历史
+
经验

基础上。

---

186.33 Engine层与ICAI非大模型体系

ICAI的Engine不是一个隐藏的大模型。

它不需要：

LLM
Transformer
Embedding
Vector Search
Prompt Engineering
Neural Network
LLM API

它使用的是：

Object
Relation
Rule
Condition
State
Knowledge
History
Memory
Experience
Calculation
Verification

因此可以定义：

ICAI Engine=Symbolic Object+Rule+Discrete Calculation+RuntimeICAI\ Engine = Symbolic\ Object + Rule + Discrete\ Calculation + Runtime

其核心目标不是生成不可解释的结果，而是：

根据明确的数据、关系、条件和规则，产生可追溯的计算结果。

---

186.34 Engine层的完整生命周期

Engine本身也具有生命周期。

可以定义：

Created
    ↓
Initialized
    ↓
Loaded Rules
    ↓
Ready
    ↓
Receive Runtime
    ↓
Calculate
    ↓
Validate Result
    ↓
Return Result
    ↓
Released

异常：

Calculate
    ↓
Calculation Error
    ↓
Diagnosis
    ↓
Repair / Rule Correction
    ↓
Ready

Engine本身不应该因为一次计算失败就直接删除。

应当保留：

Calculation Error
Calculation Context
Rule
Input
Reason
Time

供Diagnosis和Learning使用。

---

186.35 Engine、Service、Domain Object、Runtime四者统一模型

最终可以建立一个四元架构：

Architecture=Service+Engine+DomainObject+RuntimeArchitecture = Service + Engine + DomainObject + Runtime

四者分别回答：

层	核心问题
Service	应该调用什么？
Engine	应该如何计算？
Domain Object	计算的对象是什么？
Runtime	当前实际情况是什么？

进一步：

Service
    ↓
选择和组织Engine

Engine
    ↓
读取Domain Object + Runtime

Domain Object
    ↓
提供结构化对象数据

Runtime
    ↓
提供当前动态事实

Engine
    ↓
返回Calculation Result

Service
    ↓
决定后续流程与持久化

这四者共同构成ICAI的核心软件运行结构。

---

186.36 完整运行示例

假设Individual需要完成Goal：

Goal = G1

IndividualService调用：

CapabilityService

CapabilityService调用：

CapabilityEngine

输入：

Goal = G1
Capability = C1
Runtime State = Ready
Condition = C1

Engine计算：

Type Match = TRUE
Condition Match = TRUE
State Match = TRUE
Range Match = TRUE
Verification = TRUE

返回：

CapabilityMatch = TRUE

然后MethodService调用MethodEngine：

Goal
+
Capability
+
Runtime
→
Method Candidates

DecisionService调用DecisionEngine：

Candidates
+
Conditions
+
Risk
+
Experience
→
Decision

BehaviorService再根据Decision建立Behavior。

最终：

Behavior
→
Execution
→
Result

FeedbackService处理结果。

LearningService再调用LearningEngine：

History
+
Experience
+
Verification
→
Learning Result

于是形成：

Knowledge Update
Capability Update
Method Update

整个流程中：

Service负责“串起来”，Engine负责“算出来”。

---

186.37 本章小结

第186章建立了ICAI的Engine层总论。

Engine的核心定义为：

Engine=(Input,Rule,Condition,Calculation,Output)Engine=(Input,Rule,Condition,Calculation,Output)

其主要职责是：

规则执行
条件判断
对象匹配
关系推导
离散计算
评分
状态转换
验证

而Service负责：

流程组织
Service调用
事务
生命周期
结果组装

Domain Object负责：

对象
属性
状态
关系

Runtime负责：

当前状态
当前对象
当前环境
当前时间
当前执行

最终形成：

Controller
    ↓
IndividualService
    ↓
Domain Service
    ↓
Engine
    ↓
Domain Object + Runtime + Rule
    ↓
Engine Result
    ↓
Domain Service
    ↓
Repository
    ↓
MySQL

因此可以得到ICAI Engine层的核心公式：

EngineResult=f(DomainObject,Runtime,Rule,Condition)EngineResult = f(DomainObject,Runtime,Rule,Condition)

而整个应用架构可以进一步概括为：

ICAI=Service+Engine+DomainObject+Runtime+RepositoryICAI = Service + Engine + DomainObject + Runtime + Repository

其中：

Service负责组织，Engine负责计算，Domain Object负责表达认知对象，Runtime负责表达当前实际运行状态，Repository负责保存事实。

这标志着ICAI的软件工程架构从前面的Service层统一编排，进一步进入了计算层正式分离阶段。

从此以后，Capability、Method、Decision、Knowledge、State、Risk、Diagnosis、Repair、Learning等领域，都可以在统一的Engine架构下建立自己的计算引擎，而不再把核心计算逻辑混杂在Service之中。

最终形成：

Individual
    ↓
Service Orchestration
    ↓
Domain Service
    ↓
Domain Engine
    ↓
Rule + Condition + Runtime
    ↓
Deterministic Calculation
    ↓
Engine Result
    ↓
State / Knowledge / Decision / Learning Update

这就是ICAI Engine层的基本工程基础。