第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。