首页 理论 架构 工程 文档 白皮书 著作 研究 案例 下载 博客 关于 开始使用 →

第187章 ObjectEngine

第187章 ObjectEngine

187.1 ObjectEngine的定义

在ICAI统一对象体系中,Object是最基础的认知与工程计算单元之一。前面已经定义:

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

其中:

  • IDID:对象唯一标识;
  • TT:对象类型;
  • AA:对象属性集合;
  • SS:对象当前状态;
  • RR:对象关系集合。

ObjectService负责对象的创建、读取、修改、删除以及生命周期协调,而ObjectEngine不直接承担这些应用层流程。

**ObjectEngine(对象计算引擎)**是针对对象及其属性、状态、关系、条件和规则进行确定性计算的Engine组件,主要负责:

对象计算 → 对象匹配 → 对象更新判断 → 返回计算结果

因此可以定义:

ObjectEngine=Calculation+Matching+UpdateObjectEngine=Calculation+Matching+Update

其中:

  • Calculation:计算对象当前可计算结果;
  • Matching:判断对象是否满足指定条件;
  • Update:根据已验证的新事实判断对象哪些内容应该发生变化。

ObjectEngine解决的问题不是“如何保存对象”,而是:

当前对象是什么、是否符合要求、哪些内容应该更新。


187.2 ObjectEngine与ObjectService的区别

ObjectService和ObjectEngine虽然都处理Object,但职责完全不同。

可以表示为:

ObjectService=OrchestrationObjectService=Orchestration ObjectEngine=ComputationObjectEngine=Computation

ObjectService负责:

请求
→ 参数验证
→ 加载对象
→ 调用ObjectEngine
→ 接收计算结果
→ 调用StateService
→ 调用RelationService
→ 调用ObjectRepository
→ 保存结果
→ 返回服务结果

ObjectEngine负责:

Object
+ Runtime
+ Rule
+ Condition
→ Calculation
→ Matching
→ Update Evaluation
→ EngineResult

因此:

ObjectService负责“什么时候计算、调用谁、保存什么”。

ObjectEngine负责“根据当前对象和规则计算出什么”。

这一区分非常重要。

如果把对象计算全部写入ObjectService,那么Service会逐渐变成一个巨大的业务计算类,最终形成大量条件判断和重复逻辑。

ObjectEngine则把对象计算从应用流程中分离出来。


187.3 ObjectEngine的核心模型

根据前面第186章的Engine统一模型:

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

ObjectEngine可以进一步定义为:

OE=(O,R,C,D,U)OE=(O,R,C,D,U)

其中:

  • OO:Object,输入对象;
  • RR:Rule,对象计算规则;
  • CC:Condition,对象计算条件;
  • DD:Discrete Calculation,离散计算;
  • UU:Output,对象计算输出。

因此:

U=F(O,R,C)U=F(O,R,C)

这里的FF不是机器学习函数,而是确定性的程序计算过程。

例如一个对象具有:

type = product
price = 100
stock = 50
status = active

规则:

price > 0
stock > 0
status = active

则ObjectEngine可以计算:

available = true

其计算过程可以明确解释:

Object
→ Read Attributes
→ Evaluate Conditions
→ Apply Rules
→ Calculate
→ Return Result

不存在不可解释的隐藏计算过程。


187.4 一、对象计算

187.4.1 对象计算的定义

**对象计算(Object Calculation)**是指根据对象当前属性、状态、关系、上下文以及确定性规则,对对象进行派生判断或计算。

对象计算并不是简单地读取数据库字段。

例如:

price = 100
quantity = 10

数据库中保存的是两个事实:

price = 100
quantity = 10

ObjectEngine可以进一步计算:

Total=Price×QuantityTotal=Price\times Quantity

得到:

total = 1000

因此:

属性是对象已有事实,计算结果是根据事实和规则产生的新结果。


187.4.2 对象计算的输入

ObjectEngine可以读取以下输入:

Object
├── ID
├── Type
├── Attributes
├── State
└── Relations

Runtime
├── Current Time
├── Current Context
└── Current State

Rule
└── Object Calculation Rules

Condition
└── Calculation Conditions

因此:

CalculationInput=Object+Runtime+Rule+ConditionCalculationInput= Object+Runtime+Rule+Condition

计算结果必须能够追溯到这些输入。


187.4.3 对象属性计算

对象属性可以进行基本离散计算。

例如:

quantity = 20
price = 50

计算:

Amount=Quantity×PriceAmount=Quantity\times Price

得到:

amount = 1000

PHP可以表示为:

class ObjectEngine
{
    public function calculateAmount($object)
    {
        $quantity = isset($object['quantity'])
            ? $object['quantity']
            : 0;

        $price = isset($object['price'])
            ? $object['price']
            : 0;

        return $quantity * $price;
    }
}

这里的计算完全由明确的数据和数学规则组成。


187.5 二、对象状态计算

对象不仅具有属性,还具有State。

例如:

Object:
type = product
stock = 20
status = active

可以根据规则计算对象当前是否可用。

定义:

Available=Stock>0∧Status=ActiveAvailable= Stock>0 \land Status=Active

如果:

stock > 0

且:

status = active

则:

available = true

如果库存为0,则:

available = false

ObjectEngine负责计算这个结果,但并不直接修改Object的State。

正确结构是:

Object
→ ObjectEngine
→ State Calculation
→ EngineResult
→ ObjectService
→ StateService
→ State Update

这样可以保证:

Engine负责计算,Service负责协调,StateService负责合法状态转换。


187.6 三、对象关系计算

Object不仅包含自身属性,还包含关系:

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

例如:

Product A
→ belongs_to
→ Brand B

或者:

Object A
→ contains
→ Object B

ObjectEngine可以根据关系计算对象的派生结果。

例如:

A contains BA\ contains\ B

且:

B has attribute XB\ has\ attribute\ X

可以通过确定性规则得到:

A has related XA\ has\ related\ X

这种计算不是生成内容,而是根据已经存在的对象关系进行离散推导。

因此:

Object
→ Relation
→ Rule
→ Derived Result

187.7 四、对象匹配

187.7.1 对象匹配的定义

**对象匹配(Object Matching)**是ObjectEngine根据目标条件,对一个或多个Object进行条件判断,确定对象是否满足指定要求的过程。

可以定义:

Match(O,C,R)→MMatch(O,C,R)\rightarrow M

其中:

  • OO:待匹配对象;
  • CC:匹配条件;
  • RR:匹配规则;
  • MM:匹配结果。

匹配结果不能简单限定为true或false。

建议使用:

matched
partial
unmatched
unknown
blocked

这样可以保留更多实际计算信息。


187.8 对象类型匹配

最基础的匹配是Type匹配。

例如:

Object.type = product

目标条件:

required_type = product

则:

MatchType=Type(Object)=RequiredTypeMatchType=Type(Object)=RequiredType

结果:

matched = true

如果:

Object.type = service

则:

matched = false

类型匹配是后续复杂匹配的基础。


187.9 对象属性匹配

对象可以根据多个属性进行匹配。

例如:

price <= 100
stock > 0
status = active

可以建立:

M=C1∧C2∧C3M=C_1\land C_2\land C_3

即:

M=(price≤100)∧(stock>0)∧(status=active)M= (price\le100) \land (stock>0) \land (status=active)

三个条件全部成立:

matched

如果只有两个条件成立:

partial

如果关键条件不成立:

unmatched

如果必要数据缺失:

unknown

这种多状态结果比单纯的Boolean更加适合ICAI。


187.10 对象范围匹配

对象还需要进行Range匹配。

例如对象:

weight = 20

目标范围:

10 <= weight <= 30

则:

MatchRange=10≤20≤30MatchRange= 10\le20\le30

结果:

matched

如果:

weight = 40

则:

unmatched

因此对象匹配可以进一步表示为:

Match=Type∧Attribute∧State∧Range∧RelationMatch= Type \land Attribute \land State \land Range \land Relation

这与第159章Capability中的能力范围判断可以形成连接。


187.11 对象匹配与Capability匹配

ObjectEngine本身只判断:

“这个Object是否满足给定条件?”

CapabilityEngine判断:

“这个Individual是否具备某种能力?”

例如:

Object = Machine A

ObjectEngine可以计算:

machine.type = cutting_machine
machine.status = active
machine.range = 0-100mm

CapabilityEngine进一步根据:

Machine A
+
Capability Rule

判断:

Machine A
是否具备
Cutting Capability

所以:

ObjectEngine
→ Object Facts

CapabilityEngine
→ Capability Judgment

二者不能混为一谈。


187.12 五、对象集合匹配

ObjectEngine不仅可以处理单个对象,也可以处理对象集合。

设:

O={O1,O2,…,On}O=\{O_1,O_2,\ldots,O_n\}

对于条件:

CC

逐个计算:

Mi=Match(Oi,C)M_i=Match(O_i,C)

得到:

M={M1,M2,…,Mn}M=\{M_1,M_2,\ldots,M_n\}

然后根据规则产生:

Matched Objects
Partial Objects
Unmatched Objects
Unknown Objects

例如:

Object A → matched
Object B → unmatched
Object C → matched
Object D → unknown

这为后续DecisionEngine提供候选对象集合。

因此:

ObjectEngine
→ Object Matching
→ Candidate Objects
→ DecisionEngine

187.13 六、对象更新

187.13.1 对象更新的定义

**对象更新(Object Update)**不是简单地执行:

UPDATE objects ...

数据库UPDATE只是持久化操作。

ObjectEngine中的对象更新,是判断:

对象当前事实是否已经发生变化,以及哪些字段应该形成新的对象状态。

可以定义:

Ot+1=Update(Ot,ΔF)O_{t+1}=Update(O_t,\Delta F)

其中:

  • OtO_t:当前对象;
  • ΔF\Delta F:经过验证的新事实;
  • Ot+1O_{t+1}:更新后的对象。

187.14 对象更新的来源

对象更新可以来自:

Execution Result
Feedback
State Change
Relation Change
Verified Knowledge
External Fact
Manual Input
System Event

但并不是所有输入都可以直接修改Object。

正确流程:

New Fact
→ Validate
→ Compare
→ Verify
→ Update Candidate
→ ObjectEngine
→ Update Result
→ ObjectService
→ Repository

因此:

新数据不是新事实,新事实也不等于立即更新。

必须经过验证和比较。


187.15 对象差异计算

ObjectEngine首先可以计算两个对象状态之间的差异。

定义:

ΔO=Compare(Ot,Ot+1)\Delta O=Compare(O_t,O_{t+1})

例如:

旧对象:

price = 100
stock = 50
status = active

新事实:

price = 100
stock = 30
status = active

ObjectEngine计算:

price → unchanged
stock → changed
status → unchanged

于是:

ΔO={stock:50→30}\Delta O= \{stock:50\rightarrow30\}

这就是对象更新候选。


187.16 最小更新原则

ICAI对象更新必须遵循:

只更新已经被事实证明发生变化的部分。

例如:

Old:
price = 100
stock = 50
status = active

新事实只有:

stock = 30

则不能因为更新stock而同时修改:

price
status

所以:

Update(O,ΔF)Update(O,\Delta F)

只作用于:

Fields(ΔF)Fields(\Delta F)

这称为:

最小更新原则(Minimal Update Principle)

它能够避免系统因为一次局部事实变化而破坏其他已经有效的对象信息。


187.17 对象更新状态

ObjectEngine可以产生:

no_change
changed
partially_changed
invalid_update
conflicted
blocked

例如:

旧值:stock = 50
新值:stock = 30

得到:

changed

如果:

旧值:stock = 50
新值:50

得到:

no_change

如果新值违反对象规则:

stock = -10

则:

invalid_update

如果两个来源提供不同的新事实:

Source A → stock = 30
Source B → stock = 80

则可以:

conflicted

这时不能直接更新,应交给ConflictEngine、DecisionEngine或人工处理。


187.18 七、ObjectEngine的EngineResult

ObjectEngine不应只返回:

true

而应返回完整的EngineResult。

可以定义:

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

其中:

  • II:Input;
  • OO:Output;
  • CC:Calculation;
  • EE:Evidence;
  • SS:Result State;
  • TT:Time。

例如:

Input:
Object #1001

Condition:
stock > 0

Calculation:
stock = 30
30 > 0 = true

Evidence:
Object Attribute stock

Result:
matched

State:
valid

Time:
2026-09-11 12:30:00

这样任何一次对象计算都具有可追踪性。


187.19 ObjectEngine的PHP结构

在PHP 5.6/7.0兼容结构下,可以定义基础Engine:

abstract class Engine
{
    abstract public function calculate($input);
}

ObjectEngine:

class ObjectEngine extends Engine
{
    public function calculate($input)
    {
        $object = isset($input['object'])
            ? $input['object']
            : array();

        $rule = isset($input['rule'])
            ? $input['rule']
            : array();

        $condition = isset($input['condition'])
            ? $input['condition']
            : array();

        return $this->process(
            $object,
            $rule,
            $condition
        );
    }

    protected function process($object, $rule, $condition)
    {
        $calculation = array();
        $matched = true;

        if (isset($condition['type'])) {
            if (!isset($object['type']) ||
                $object['type'] != $condition['type']) {

                $matched = false;

                $calculation[] = array(
                    'field' => 'type',
                    'expected' => $condition['type'],
                    'actual' => isset($object['type'])
                        ? $object['type']
                        : null,
                    'result' => false
                );
            }
        }

        return array(
            'object' => $object,
            'matched' => $matched,
            'calculation' => $calculation
        );
    }
}

这个Engine只负责计算。

它不应该直接执行:

INSERT
UPDATE
DELETE

数据库操作属于Repository。


187.20 ObjectEngine与Repository

正确结构:

ObjectService
        ↓
ObjectEngine
        ↓
EngineResult
        ↓
ObjectService
        ↓
ObjectRepository
        ↓
MySQL

而不是:

ObjectEngine
        ↓
MySQL

原因在于Engine应保持计算职责。

如果ObjectEngine直接操作MySQL,则:

Calculation
+
Persistence
+
Transaction
+
Business Process

会被混合到一起。

这会破坏前面建立的:

Service+Engine+DomainObject+RepositoryService+Engine+DomainObject+Repository

四层结构。


187.21 ObjectEngine与StateEngine

Object和State之间也必须保持职责分离。

ObjectEngine:

计算对象当前应该得到什么结果

StateEngine:

判断状态是否允许从S1转换到S2

例如ObjectEngine计算:

stock = 0

得到:

available = false

然后ObjectService根据这个结果调用StateService:

Current State
→ StateEngine
→ Transition Rule
→ New State

所以:

ObjectEngine
→ Object Fact Calculation

StateEngine
→ State Transition Calculation

ObjectEngine不能绕过StateEngine直接修改状态。


187.22 ObjectEngine与RelationEngine

对象关系同样如此。

ObjectEngine可以发现:

Object A
需要关联
Object B

但它不应该直接修改关系。

正确流程:

ObjectEngine
→ Relation Candidate
→ RelationService
→ RelationEngine
→ Relation Validation
→ RelationRepository

因此:

ObjectEngine可以产生关系计算结果,但RelationEngine负责关系合法性计算。


187.23 ObjectEngine完整计算流程

完整对象计算流程可以定义为:

Load Object
→ Load Runtime
→ Load Rules
→ Load Conditions
→ Read Attributes
→ Read State
→ Read Relations
→ Calculate
→ Match
→ Compare
→ Generate Update Candidate
→ Validate
→ EngineResult

进一步进入Service层:

ObjectEngine
→ EngineResult
→ ObjectService
→ StateService / RelationService
→ ObjectRepository
→ MySQL

187.24 ObjectEngine异常处理

对象计算过程中可能出现:

Object Missing
Type Missing
Attribute Missing
Invalid Value
Condition Missing
Rule Conflict
Relation Invalid
State Invalid
Update Conflict

ObjectEngine不能简单返回:

false

而应该返回明确状态。

例如:

status = invalid_input
reason = required_attribute_missing
field = stock

或者:

status = conflict
reason = multiple_update_sources

这样DiagnosisEngine才能进一步处理。

形成:

ObjectEngine
→ Error Result
→ Abnormality
→ DiagnosisEngine
→ RepairEngine

187.25 ObjectEngine与DiagnosisEngine

ObjectEngine发现:

stock = -10

只能判断:

invalid

它不负责回答:

为什么stock会变成-10?

这个问题属于DiagnosisEngine。

因此:

ObjectEngine
→ Detect / Calculate

而:

DiagnosisEngine
→ Analyze Cause

二者保持严格分离。


187.26 ObjectEngine与LearningEngine

ObjectEngine也不负责学习。

例如ObjectEngine连续计算:

Object A → matched
Object A → matched
Object A → unmatched

这些只是计算历史。

MemoryExperienceService可以保存这些事实。

LearningEngine则可以根据经过验证的历史事实产生:

Knowledge Update
Capability Update
Method Update

所以完整关系:

ObjectEngine
→ Calculation
→ Result
→ Feedback
→ History
→ Memory
→ Experience
→ LearningEngine
→ Knowledge / Capability / Method Update

这保证了“计算”和“学习”不被混淆。


187.27 ObjectEngine在ICAI中的位置

经过前面章节的Engine体系建立,ObjectEngine位于基础对象计算层。

可以形成:

                    Engine
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   ObjectEngine   StateEngine   RelationEngine
        │             │             │
        └─────────────┼─────────────┘
                      │
                基础计算层
                      │
        ┌─────────────┼─────────────┐
        │             │             │
 KnowledgeEngine  GoalEngine   CapabilityEngine
        │             │             │
 MethodEngine    DecisionEngine
        │             │
 BehaviorEngine  ExecutionEngine
        │             │
 FeedbackEngine  LearningEngine
        │             │
 DiagnosisEngine RepairEngine

ObjectEngine不是最高层Engine。

它是大量高级认知Engine的基础。

因为:

没有对象,就没有对象属性;没有对象属性,就无法形成状态、关系、能力、方法和决策计算。


187.28 ObjectEngine与ICAI整体闭环

在完整ICAI运行过程中:

Individual
→ Object
→ ObjectEngine
→ Object Matching
→ Capability
→ Method
→ Decision
→ Behavior
→ Action
→ Execution
→ Result
→ Feedback
→ Memory
→ Experience
→ Learning
→ Object Update
→ ObjectEngine

这里形成了一个重要闭环:

Objectt→Execution→Result→Feedback→Learning→Objectt+1Object_t \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow Learning \rightarrow Object_{t+1}

也就是说,对象不是永远静态存在的。

对象会随着经过验证的新事实而发生离散更新:

Ot+1=Update(Ot,ΔF)O_{t+1}=Update(O_t,\Delta F)

然后新的Object再次进入ObjectEngine计算。

由此形成:

对象
→ 计算
→ 行为
→ 结果
→ 反馈
→ 新事实
→ 对象更新
→ 再计算

187.29 ObjectEngine的工程边界

为了保持ICAI架构稳定,ObjectEngine必须遵守以下边界。

第一,不负责对象持久化

ObjectEngine ≠ Repository

第二,不负责完整业务流程

ObjectEngine ≠ Service

第三,不负责状态最终保存

ObjectEngine ≠ StateService

第四,不负责关系最终保存

ObjectEngine ≠ RelationService

第五,不负责原因诊断

ObjectEngine ≠ DiagnosisEngine

第六,不负责经验形成

ObjectEngine ≠ ExperienceEngine

第七,不负责学习更新策略的整体编排

ObjectEngine ≠ LearningEngine

ObjectEngine的核心职责始终保持为:

ObjectEngine=Calculation+Matching+UpdateEvaluationObjectEngine= Calculation+ Matching+ UpdateEvaluation


187.30 ObjectEngine统一模型

最终可以将ObjectEngine定义为:

OE=(O,R,C,D,M,U,V,T)OE=(O,R,C,D,M,U,V,T)

其中:

  • OO:Object;
  • RR:Rule;
  • CC:Condition;
  • DD:Calculation;
  • MM:Matching;
  • UU:Update;
  • VV:Verification;
  • TT:Time。

完整过程:

(O,R,C)→D→M→U→V→Result(O,R,C) \rightarrow D \rightarrow M \rightarrow U \rightarrow V \rightarrow Result

其中Update并不是无条件执行,而是:

UpdateCandidate→Validation→Verification→ObjectService→RepositoryUpdateCandidate \rightarrow Validation \rightarrow Verification \rightarrow ObjectService \rightarrow Repository

因此最终工程链为:

Object
→ ObjectEngine
→ Calculation
→ Matching
→ Update Candidate
→ Validation
→ Verification
→ ObjectService
→ ObjectRepository
→ MySQL

187.31 本章总结

ObjectEngine是ICAI Engine体系中的基础对象计算Engine,其核心不是数据库CRUD,而是对Object进行确定性的计算、匹配和更新判断。

对象计算解决:

当前对象可以计算出什么。

对象匹配解决:

当前对象是否满足指定条件。

对象更新解决:

当前对象哪些事实已经发生变化。

三者形成:

ObjectEngine=ObjectCalculation+ObjectMatching+ObjectUpdateEvaluationObjectEngine= ObjectCalculation+ ObjectMatching+ ObjectUpdateEvaluation

进一步形成:

Ot→Calculate→Match→Compare→UpdateCandidate→Verify→Ot+1O_t \rightarrow Calculate \rightarrow Match \rightarrow Compare \rightarrow UpdateCandidate \rightarrow Verify \rightarrow O_{t+1}

ObjectService负责调用和编排,ObjectEngine负责计算,StateEngine负责状态转换,RelationEngine负责关系合法性,ObjectRepository负责持久化。

最终形成:

Object
   ↓
ObjectEngine
   ├── Object Calculation
   ├── Object Matching
   └── Object Update Evaluation
   ↓
EngineResult
   ↓
ObjectService
   ├── StateService
   ├── RelationService
   └── ObjectRepository
   ↓
MySQL

由此,ICAI的Object不再只是数据库中的一条记录,而成为可以被计算、被匹配、被验证、被更新,并能够进入后续Capability、Method、Decision和Learning计算链的运行时认知对象

这也进一步确定了ICAI的一个基本工程原则:

对象负责表达事实,Engine负责计算事实,Service负责组织过程,Repository负责保存事实。

并且整个体系仍然建立在明确规则、条件、对象、关系、离散计算、历史和验证机制之上,不依赖LLM、Transformer、Embedding、Vector Search、Prompt Engineering、神经网络或LLM API。

Leave a Reply

Your email address will not be published. Required fields are marked *