第195章 MethodEngine

195.1 MethodEngine的定义

在ICAI系统中，Method表示完成某一目标所采用的具体方法，而MethodEngine负责对方法进行计算、评价、选择准备、组合分析以及验证计算。

第160章已经定义：

$M=(T,C,P,A,R)M=(T,C,P,A,R)$

其中：

$TT$ ：Method Type，方法类型；
$CC$ ：Condition，方法条件；
$PP$ ：Process，方法过程；
$AA$ ：Action，方法动作；
$RR$ ：Result，方法结果。

Method回答：

如何完成一个目标。

而MethodEngine回答：

当前方法是什么、是否适合当前条件、多个方法中如何确定可用方法、多个方法能否组合、实际执行后该方法是否得到验证。

因此：

$MethodEngine=MethodCalculation+MethodSelection+MethodComposition+MethodVerificationMethodEngine = MethodCalculation + MethodSelection + MethodComposition + MethodVerification$

即：

MethodEngine = 方法计算 + 方法选择 + 方法组合 + 方法验证。

但这里必须特别强调：

MethodEngine中的“方法选择”不是最终业务决策的全部含义。

如果存在多个候选方法，MethodEngine可以计算方法之间的适用性、可行性、依赖关系和组合关系，并形成方法候选结果；最终涉及目标优先级、风险、资源、成本等综合决策时，仍然由DecisionEngine或DecisionService完成最终决策。

因此：

$MethodEngine≠DecisionEngineMethodEngine \neq DecisionEngine$

195.2 MethodEngine的统一模型

MethodEngine可以定义为：

$ME=(M,O,G,C,K,D,S,V,T)ME=(M,O,G,C,K,D,S,V,T)$

其中：

$MM$ ：Method，方法；
$OO$ ：Object，对象；
$GG$ ：Goal，目标；
$CC$ ：Condition，条件；
$KK$ ：Capability，能力及相关知识；
$DD$ ：Discrete Calculation，离散计算；
$SS$ ：Selection/Composition，方法选择与组合结果；
$VV$ ：Verification，验证；
$TT$ ：Time，计算时间。

其基本计算形式：

$M+G+O+C+K→MethodCalculation→MethodCandidate→Selection→Composition→VerificationM+G+O+C+K \rightarrow MethodCalculation \rightarrow MethodCandidate \rightarrow Selection \rightarrow Composition \rightarrow Verification$

形成：

Goal
 ↓
Method Candidates
 ↓
Method Calculation
 ↓
Method Matching
 ↓
Method Selection
 ↓
Method Composition
 ↓
Method Execution
 ↓
Result
 ↓
Method Verification

需要注意：

MethodEngine可以计算方法是否可选、如何组合，但不直接执行Action。

实际执行仍然属于：

$BehaviorEngine→ActionEngine→ExecutionEngineBehaviorEngine \rightarrow ActionEngine \rightarrow ExecutionEngine$

195.3 MethodEngine与Method对象

Method是领域对象。

MethodEngine是计算机制。

二者必须严格分离。

Method对象保存：

Method Type
Condition
Process
Action
Expected Result
State

MethodEngine负责：

读取Method
 ↓
分析Method
 ↓
匹配当前条件
 ↓
计算可执行性
 ↓
分析方法关系
 ↓
形成候选
 ↓
组合或验证

因此：

$Method=Data+Structure+StateMethod=Data+Structure+State$

而：

$MethodEngine=CalculationMethodEngine=Calculation$

不能将所有计算逻辑直接写进Method对象，否则会导致领域对象承担过多职责。

195.4 方法计算

195.4.1 方法计算定义

方法计算是MethodEngine最基础的功能。

它回答：

当前方法在当前对象、目标、状态和条件下，具有什么结构和可执行特征？

定义：

$Calculate(M,G,O,S,C)→MCCalculate(M,G,O,S,C)\rightarrow MC$

其中：

$MM$ ：方法；
$GG$ ：当前目标；
$OO$ ：当前对象；
$SS$ ：当前状态；
$CC$ ：当前条件；
$MCMC$ ：Method Calculation Result，方法计算结果。

195.5 方法计算内容

MethodEngine至少计算以下内容：

Method Type
Method Condition
Process
Action Sequence
Required Capability
Required Resource
Expected Result
Current State
Applicable Object
Applicable Scene
Dependency
Constraint

最终形成方法计算结果：

$MC=Type+Condition+Process+Action+Capability+Resource+ResultMC= Type+ Condition+ Process+ Action+ Capability+ Resource+ Result$

例如某个方法：

Method = DeliveryMethod
Object = Order
Required State = Ready
Required Capability = Transport
Process = Load → Transport → Deliver
Expected Result = Delivered

MethodEngine需要计算：

方法类型是否适合
当前对象是否适用
当前状态是否允许
所需能力是否存在
所需资源是否存在
动作过程是否完整
预期结果是否明确

因此：

$MethodCalculation≠MethodExecutionMethodCalculation \neq MethodExecution$

方法计算只回答：

这个方法在当前条件下是什么、需要什么、能否进入后续选择。

195.6 方法条件计算

Method本身具有条件：

$Cm={c1,c2,…,cn}C_m=\{c_1,c_2,…,c_n\}$

当前环境具有：

$Cr={r1,r2,…,rn}C_r=\{r_1,r_2,…,r_n\}$

MethodEngine需要计算：

$Evaluate(Cm,Cr)→EEvaluate(C_m,C_r)\rightarrow E$

例如：

Method Condition:
Object State = Ready
Capability = Transport
Resource = Vehicle

当前条件：

Object State = Ready
Capability = Transport
Resource = Vehicle

得到：

$E=MatchedE=Matched$

如果：

Resource = unavailable

则：

$E=BlockedE=Blocked$

因此方法条件不是简单的字符串比较，而是当前事实与方法要求之间的规则计算。

195.7 方法计算与MatchingEngine

第194章的MatchingEngine已经负责：

当前方法是否符合当前要求。

MethodEngine则进一步负责：

这个方法自身的结构、过程、依赖、能力需求和可执行条件是什么。

两者关系为：

$MethodEngine→MethodFactsMethodEngine \rightarrow MethodFacts$

然后：

$MethodFacts+Requirement→MatchingEngineMethodFacts + Requirement \rightarrow MatchingEngine$

因此：

MethodEngine
   ↓
方法计算结果
   ↓
MatchingEngine
   ↓
方法匹配结果

不能让MethodEngine重复承担统一匹配体系的全部职责。

195.8 方法候选生成

经过方法计算与匹配之后，系统可以形成方法候选集合：

$MC={M1,M2,…,Mn}MC=\{M_1,M_2,…,M_n\}$

每一个候选方法都必须保留：

$Candidate(Mi)=Method+Condition+Capability+Resource+State+ResultCandidate(M_i)= Method+ Condition+ Capability+ Resource+ State+ Result$

例如：

Method A
State = Matched
Capability = Matched
Resource = Matched

Method B
State = Matched
Capability = Partial
Resource = Matched

Method C
State = Blocked
Capability = Matched
Resource = Unavailable

因此候选集合不能简单保存方法ID。

必须保存：

方法
适用条件
匹配状态
能力要求
资源要求
阻塞原因
预期结果
证据

这为后续方法选择提供完整依据。

195.9 方法选择

195.9.1 方法选择的定义

当系统存在多个可行方法时，需要从候选集合中确定当前可以进入后续处理的方法。

定义：

$Select(MC,G,C,S)→MsSelect(MC,G,C,S)\rightarrow M_s$

其中：

$MCMC$ ：方法候选集合；
$GG$ ：目标；
$CC$ ：当前条件；
$SS$ ：当前状态；
$MsM_s$ ：方法选择结果。

方法选择必须建立在实际计算结果基础上。

不能：

随机选择

也不能：

固定选择第一个

而应：

$Candidate→Filter→Evaluate→SelectCandidate \rightarrow Filter \rightarrow Evaluate \rightarrow Select$

195.10 方法选择条件

方法选择至少需要考虑：

Goal Match
Object Match
State Match
Capability Match
Condition Match
Resource Availability
Method Validity
Expected Result
Risk
Dependency

可以定义基本可选条件：

$Selectable(M)=G∧O∧S∧C∧Capability∧Resource∧ValiditySelectable(M)= G \land O \land S \land C \land Capability \land Resource \land Validity$

只有满足必要条件的方法才能进入可选集合。

例如：

$M1=SelectableM_1=Selectable$ $M2=BlockedM_2=Blocked$ $M3=UnmatchedM_3=Unmatched$

最终：

$SelectableMethods={M1}SelectableMethods=\{M_1\}$

如果存在多个可选方法：

$SelectableMethods={M1,M2,M3}SelectableMethods=\{M_1,M_2,M_3\}$

则交给进一步的选择计算或DecisionEngine。

195.11 方法选择与DecisionEngine的区别

这是MethodEngine中最重要的工程边界之一。

MethodEngine可以回答：

哪些方法可用？
哪些方法不可用？
哪些方法被条件阻塞？
哪些方法满足必要条件？
哪些方法存在依赖问题？
哪些方法可以组合？

DecisionEngine回答：

在这些可行方法中，最终选择哪个？

因此：

$MethodEngine→FeasibleMethodsMethodEngine \rightarrow FeasibleMethods$ $DecisionEngine→SelectedMethodDecisionEngine \rightarrow SelectedMethod$

例如：

Method A = 可用
Method B = 可用
Method C = 不可用

MethodEngine输出：

${A,B}\{A,B\}$

如果Decision规则为：

优先低资源消耗

DecisionEngine再选择：

$AA$

所以：

$MethodEngine≠FinalDecisionMethodEngine\neq FinalDecision$

195.12 方法组合

195.12.1 方法组合定义

真实任务往往无法通过一个Method完成。

因此需要将多个方法组合为一个更高层次的方法过程。

定义：

$Compose(M1,M2,…,Mn)→McCompose(M_1,M_2,…,M_n)\rightarrow M_c$

其中：

$M1\dotsMnM_1\dotsM_n$ ：基础方法；
$McM_c$ ：组合方法。

方法组合不是简单的列表拼接，而必须检查：

顺序
依赖
输入输出
条件
能力
资源
状态
冲突
结果

195.13 方法组合模型

组合方法可以表示为：

$Mc={M1,M2,…,Mn}+P+D+C+RM_c= \{M_1,M_2,…,M_n\} + P + D + C + R$

其中：

$PP$ ：Process，方法顺序；
$DD$ ：Dependency，方法依赖；
$CC$ ：Condition，组合条件；
$RR$ ：Result，组合结果。

例如：

Method A
 ↓
Method B
 ↓
Method C

形成：

$MA→MB→MCM_A\rightarrow M_B\rightarrow M_C$

如果A的输出是B的必要输入：

$Result(A)=Input(B)Result(A)=Input(B)$

则存在：

$Dependency(A,B)Dependency(A,B)$

195.14 方法组合的顺序约束

方法之间可能存在严格顺序：

Prepare
 ↓
Initialize
 ↓
Execute
 ↓
Verify

不能任意排列。

因此MethodEngine需要计算：

$Order(Mi,Mj)Order(M_i,M_j)$

如果：

$Mi→MjM_i \rightarrow M_j$

表示：

方法 $MiM_i$ 必须先于方法 $MjM_j$ 。

如果：

$Mj→MiM_j \rightarrow M_i$

则顺序相反。

如果两个方法互相要求先执行：

$Mi→MjM_i\rightarrow M_j$

同时：

$Mj→MiM_j\rightarrow M_i$

则形成循环依赖：

$Cycle(Mi,Mj)=TrueCycle(M_i,M_j)=True$

此时组合必须：

Rejected

或者进入：

Diagnosis / Conflict

而不能强行执行。

195.15 方法组合的能力约束

组合方法可能需要多个能力：

$C(Mc)=C(M1)∪C(M2)∪…∪C(Mn)C(M_c)= C(M_1)\cup C(M_2)\cup…\cup C(M_n)$

例如：

Method A requires Capability A
Method B requires Capability B
Method C requires Capability C

那么组合方法需要：

$CapabilitySet={A,B,C}CapabilitySet= \{A,B,C\}$

如果当前Individual只有：

${A,B}\{A,B\}$

则：

$CapabilityMatch=PartialCapabilityMatch=Partial$

因此组合方法不能被直接标记为可执行。

195.16 方法组合的资源约束

方法组合还需要检查资源。

定义：

$R(Mc)=R(M1)∪R(M2)∪…∪R(Mn)R(M_c)= R(M_1)\cup R(M_2)\cup…\cup R(M_n)$

如果两个方法需要同一个互斥资源：

Method A → Resource X
Method B → Resource X

而X不能同时使用，则可能形成：

$Conflict(Resource)Conflict(Resource)$

此时MethodEngine需要产生：

Resource Conflict

并将问题交给ConflictEngine或DecisionEngine处理。

因此方法组合不是“把几个方法放到一起”，而是：

$Composition=Order+Dependency+Capability+Resource+Condition+StateComposition = Order + Dependency + Capability + Resource + Condition + State$

195.17 方法组合状态

组合方法可以具有自己的状态：

Created
Analyzing
Ready
Blocked
Running
Completed
Failed
Cancelled

但是组合方法的状态不能简单等于某一个子方法状态。

例如：

A = Completed
B = Completed
C = Failed

组合方法：

$Mc=FailedM_c=Failed$

而：

A = Completed
B = Running
C = Pending

组合方法：

$Mc=RunningM_c=Running$

因此：

$State(Mc)=f(State(M1),\dots,State(Mn))State(M_c)=f(State(M_1),\dots,State(M_n))$

这种状态计算由MethodEngine与StateEngine协同完成。

195.18 方法验证

195.18.1 方法验证定义

方法验证是MethodEngine的重要功能。

它回答：

这个方法是否通过实际执行结果证明其在规定条件下有效。

定义：

$Verify(M,E,R,F,C)→VVerify(M,E,R,F,C)\rightarrow V$

其中：

$MM$ ：方法；
$EE$ ：Execution，实际执行；
$RR$ ：Result，实际结果；
$FF$ ：Feedback，反馈；
$CC$ ：验证条件；
$VV$ ：验证结果。

验证不能依据：

方法名称
方法声明
理论描述
预期结果

直接判定。

必须依赖实际证据。

195.19 方法验证模型

可以建立：

$Vm=(M,E,R,C,F,S,T)V_m= (M,E,R,C,F,S,T)$

其中：

$MM$ ：被验证的方法；
$EE$ ：实际执行记录；
$RR$ ：实际结果；
$CC$ ：验证条件；
$FF$ ：反馈；
$SS$ ：验证状态；
$TT$ ：验证时间。

验证状态可以包括：

Unverified
Verified
Failed
Outdated
Invalid
Conflicted
Unknown

195.20 方法验证的核心条件

可以定义：

$ValidMethod=Execution∧ActualResult∧Condition∧EvidenceValidMethod= Execution \land ActualResult \land Condition \land Evidence$

如果还需要反馈：

$VerifiedMethod=Execution∧ActualResult∧Condition∧Evidence∧FeedbackVerifiedMethod= Execution \land ActualResult \land Condition \land Evidence \land Feedback$

例如：

Method A
Expected Result = Success
Actual Result = Success
Condition = Valid
Evidence = Present

则：

Verified

如果：

Expected Result = Success
Actual Result = Failed

则不能继续保持：

Verified

应进入：

Failed

然后：

$Failure→DiagnosisEngine→RepairEngineFailure \rightarrow DiagnosisEngine \rightarrow RepairEngine$

195.21 方法验证不等于方法执行

必须明确：

$MethodExecution≠MethodVerificationMethodExecution \neq MethodVerification$

Execution回答：

方法是否被实际执行。

Verification回答：

方法执行后是否证明方法有效。

可能存在：

Executed = Yes
Verified = No

例如方法确实执行了，但实际结果不符合要求。

也可能：

Executed = Yes
Result = Unknown
Verified = Unknown

因此：

$Executed≠Successful≠VerifiedExecuted \neq Successful \neq Verified$

这是ICAI工程系统必须保持的事实边界。

195.22 方法有效范围

一个方法被验证有效，并不意味着它在任何条件下都有效。

定义：

$VerifiedRange(M)={C1,C2,…,Cn}VerifiedRange(M)= \{C_1,C_2,…,C_n\}$

即：

方法已经实际验证过的适用条件集合。

例如：

Method A
Temperature = 20–30
Resource = X
Object Type = A

在该范围内验证成功：

$Verified(M,C)=TrueVerified(M,C)=True$

不能直接推出：

Temperature = 50

时仍然有效。

因此：

$TheoreticalRange≠VerifiedRangeTheoreticalRange \neq VerifiedRange$

这与CapabilityEngine中的“理论能力范围”和“实际验证范围”保持一致。

195.23 方法验证后的更新

如果实际执行证明方法发生变化，可以形成：

$Mt+ΔF→Mt+1M_t+\Delta F\rightarrow M_{t+1}$

其中：

$ΔF=Verified(Evidence)\Delta F=Verified(Evidence)$

例如：

原方法：
需要 Resource A

实际执行发现：

Resource A 无法使用
Resource B 可以完成相同过程

系统不能因为一次执行失败就直接删除方法。

而应形成：

Method Update Candidate

然后由LearningService、MethodService等完成受控更新。

因此：

$MethodEngine→VerificationResult→LearningService→MethodUpdateMethodEngine \rightarrow VerificationResult \rightarrow LearningService \rightarrow MethodUpdate$

而不是：

$MethodEngine→直接修改所有MethodMethodEngine \rightarrow 直接修改所有Method$

195.24 方法计算、选择、组合、验证的统一闭环

四项核心功能可以形成完整循环：

$Method→Calculate→Candidate→Select→Compose→Execute→Verify→UpdateMethod \rightarrow Calculate \rightarrow Candidate \rightarrow Select \rightarrow Compose \rightarrow Execute \rightarrow Verify \rightarrow Update$

进一步形成：

方法
 ↓
方法计算
 ↓
方法候选
 ↓
方法选择
 ↓
方法组合
 ↓
行为建立
 ↓
动作执行
 ↓
结果
 ↓
反馈
 ↓
方法验证
 ↓
经验
 ↓
方法更新

因此MethodEngine并不是单向计算器，而是方法认知体系中的循环节点。

195.25 MethodEngine与BehaviorEngine

Method与Behavior必须严格区分。

Method：

规定如何完成目标。

Behavior：

当前Individual实际执行的方法行为。

因此：

$Method→Behavior→Action→ExecutionMethod \rightarrow Behavior \rightarrow Action \rightarrow Execution$

MethodEngine负责方法：

计算
选择准备
组合
验证

BehaviorEngine负责：

建立实际行为
组织Action
进入Execution

因此：

$MethodEngine≠BehaviorEngineMethodEngine\neq BehaviorEngine$

195.26 MethodEngine与ActionEngine

Method中的Action只是方法定义中的动作结构：

$M=(T,C,P,A,R)M=(T,C,P,A,R)$

而ActionEngine处理实际动作计算与执行相关过程。

因此：

$Method→ActionDefinitionMethod \rightarrow ActionDefinition$

再由：

$BehaviorEngine→ActionEngine→ExecutionEngineBehaviorEngine \rightarrow ActionEngine \rightarrow ExecutionEngine$

进入实际执行。

MethodEngine不应直接替代ActionEngine。

195.27 MethodEngine与RiskEngine

方法选择和组合都可能产生风险。

例如：

Method A
需要资源X
资源X当前不稳定

MethodEngine可以计算：

Resource Condition = Unstable

但风险等级属于RiskEngine进一步计算：

$Risk=Probability×ImpactRisk= Probability\times Impact$

因此：

$MethodEngine→RiskEngineMethodEngine \rightarrow RiskEngine$

MethodEngine提供方法条件事实，RiskEngine进行风险计算。

195.28 MethodEngine与ConflictEngine

多个方法可能产生冲突：

Method A → Resource X
Method B → Resource X

如果X互斥：

$Conflict(MethodA,MethodB)Conflict(MethodA,MethodB)$

MethodEngine负责识别组合上的结构问题。

ConflictEngine负责进一步进行：

Conflict Detection
→
Evaluation
→
Resolution

因此：

$MethodEngine→ConflictEngineMethodEngine \rightarrow ConflictEngine$

形成方法组合和冲突处理之间的连接。

195.29 MethodEngine的PHP工程结构

建议Engine层保持：

app/
├── Domain/
│   └── Method.php
│
├── Engine/
│   ├── Engine.php
│   ├── MethodEngine.php
│   ├── MatchingEngine.php
│   ├── CapabilityEngine.php
│   ├── DecisionEngine.php
│   ├── BehaviorEngine.php
│   ├── ActionEngine.php
│   └── VerificationEngine.php
│
├── Service/
│   ├── MethodService.php
│   ├── DecisionService.php
│   └── BehaviorService.php
│
└── Repository/
    └── MethodRepository.php

MethodEngine内部主要负责：

calculateMethod()
selectCandidates()
composeMethods()
verifyMethod()

不负责直接访问MySQL。

195.30 MethodEngine核心PHP结构

下面使用兼容PHP 5.6/7.0的写法表达核心工程结构：

<?php

class MethodEngine extends Engine
{
    public function calculate($input)
    {
        $methods = $input['methods'];
        $context = $input['context'];

        $calculated = array();

        foreach ($methods as $method) {
            $calculated[] = $this->calculateMethod(
                $method,
                $context
            );
        }

        return array(
            'methods' => $calculated
        );
    }

    protected function calculateMethod($method, $context)
    {
        $condition = $this->evaluateCondition(
            $method,
            $context
        );

        $capability = $this->checkCapability(
            $method,
            $context
        );

        $resource = $this->checkResource(
            $method,
            $context
        );

        $state = $this->checkState(
            $method,
            $context
        );

        $status = 'Unmatched';

        if (
            $condition &&
            $capability &&
            $resource &&
            $state
        ) {
            $status = 'Matched';
        }

        return array(
            'method_id' => $method['id'],
            'condition' => $condition,
            'capability' => $capability,
            'resource' => $resource,
            'state' => $state,
            'status' => $status
        );
    }

    protected function evaluateCondition($method, $context)
    {
        if (!isset($method['conditions'])) {
            return true;
        }

        return true;
    }

    protected function checkCapability($method, $context)
    {
        return true;
    }

    protected function checkResource($method, $context)
    {
        return true;
    }

    protected function checkState($method, $context)
    {
        return true;
    }

    public function compose($methods)
    {
        $result = array(
            'methods' => array(),
            'dependencies' => array(),
            'status' => 'Ready'
        );

        foreach ($methods as $method) {
            $result['methods'][] = $method;
        }

        return $result;
    }

    public function verify($method, $execution, $result)
    {
        if (!$execution || !$result) {
            return array(
                'status' => 'Unknown'
            );
        }

        if ($result['success']) {
            return array(
                'status' => 'Verified'
            );
        }

        return array(
            'status' => 'Failed'
        );
    }
}

这里的代码表达的是MethodEngine的计算边界。

真实工程中：

ConditionEngine
CapabilityEngine
StateEngine
VerificationService

可以分别提供对应计算结果，再由MethodEngine进行组合。

195.31 方法组合的工程对象

为了避免将组合方法直接当成普通Method，可以建立：

Method
MethodStep
MethodDependency
MethodCondition
MethodRequirement
MethodComposition
MethodVerification

其中：

Method

定义一个独立方法。

MethodStep

表示组合方法中的一个步骤。

MethodDependency

表示方法之间的依赖关系。

MethodCondition

表示方法执行条件。

MethodRequirement

表示方法需要的能力、资源、对象和状态。

MethodComposition

保存多个Method形成的组合结构。

MethodVerification

保存方法实际验证结果。

这样可以形成：

$MethodComposition=Method+Step+Dependency+Condition+RequirementMethodComposition= Method + Step + Dependency + Condition + Requirement$

195.32 方法组合数据库

可以建立：

methods

id
type
name
description
state
created_at
updated_at

method_conditions

id
method_id
condition_type
condition_value
operator
required

method_processes

id
method_id
step_no
process_type
description

method_actions

id
method_id
action_id
step_no
required

method_compositions

id
parent_method_id
child_method_id
step_no
condition
state

method_dependencies

id
method_id
depends_on_method_id
dependency_type
condition

method_verifications

id
method_id
execution_id
result_id
status
evidence
verified_at

数据库保存事实和历史。

MethodEngine负责计算这些事实之间的关系。

195.33 方法选择结果

MethodEngine的选择计算结果可以定义为：

$MS=(M,C,S,R,E,T)MS=(M,C,S,R,E,T)$

其中：

$MM$ ：候选方法；
$CC$ ：条件；
$SS$ ：状态；
$RR$ ：选择依据；
$EE$ ：证据；
$TT$ ：时间。

例如：

Candidate Method A
Condition = Matched
Capability = Matched
Resource = Matched
State = Ready
Risk = Acceptable

可以形成：

Selectable

但如果同时存在Method B：

Candidate Method B
Condition = Matched
Capability = Matched
Resource = Matched
State = Ready
Risk = Acceptable

则MethodEngine可以返回：

${A,B}\{A,B\}$

最终选择仍可进入DecisionEngine。

195.34 方法验证结果

方法验证结果可以定义：

$MV=(M,E,R,F,C,S,T)MV=(M,E,R,F,C,S,T)$

其中：

$MM$ ：方法；
$EE$ ：实际执行；
$RR$ ：实际结果；
$FF$ ：反馈；
$CC$ ：验证条件；
$SS$ ：验证状态；
$TT$ ：验证时间。

验证状态：

$S∈{Verified,Failed,Unknown,Outdated,Invalid,Conflicted}S\in \{ Verified, Failed, Unknown, Outdated, Invalid, Conflicted \}$

这样，未来系统不会出现：

Method = Verified

但完全无法说明：

什么时候验证
谁执行
执行了什么
实际结果是什么
为什么认为有效

的情况。

195.35 方法生命周期

MethodEngine可以参与方法生命周期管理：

$Created→Calculated→Matched→Candidate→Selected→Composed→Executed→VerifiedCreated \rightarrow Calculated \rightarrow Matched \rightarrow Candidate \rightarrow Selected \rightarrow Composed \rightarrow Executed \rightarrow Verified$

异常路径：

$Executed→Failed→Diagnosis→Repair→Re−execution→VerificationExecuted \rightarrow Failed \rightarrow Diagnosis \rightarrow Repair \rightarrow Re-execution \rightarrow Verification$

如果方法长期没有被验证：

$Verified→OutdatedVerified \rightarrow Outdated$

如果实际证据证明原方法失效：

$Verified→InvalidVerified \rightarrow Invalid$

因此方法不是静态代码，而是具有生命周期的认知对象。

195.36 方法学习闭环

MethodEngine产生的验证结果可以进入LearningService：

$Method→Execution→Result→Feedback→Verification→LearningMethod \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow Verification \rightarrow Learning$

LearningService再根据经过验证的事实形成：

$Mt+ΔF→Mt+1M_t+\Delta F \rightarrow M_{t+1}$

例如实际执行长期表明：

Method A
在Condition X下成功
在Condition Y下失败

系统可以逐渐形成：

$Applicable(MethodA)=XApplicable(MethodA)=X$

以及：

$Restricted(MethodA)=YRestricted(MethodA)=Y$

这种学习不是神经网络训练，而是：

基于实际事实、比较、验证和规则的数据结构更新。

195.37 MethodEngine完整工程流程

完整流程可以表示为：

Goal
 ↓
Load Method
 ↓
Method Calculation
 ↓
Condition Evaluation
 ↓
Capability Check
 ↓
State Check
 ↓
Resource Check
 ↓
Matching
 ↓
Method Candidates
 ↓
Candidate Evaluation
 ↓
Method Selection
 ↓
Method Composition
 ↓
Behavior Build
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Method Verification
 ↓
Learning
 ↓
Method Update

形成：

$Goal→Method→Calculate→Match→Select→Compose→Execute→Verify→LearnGoal \rightarrow Method \rightarrow Calculate \rightarrow Match \rightarrow Select \rightarrow Compose \rightarrow Execute \rightarrow Verify \rightarrow Learn$

195.38 MethodEngine在ICAI中的位置

综合前面的Engine体系，可以形成：

$ObjectEngine→StateEngine→RelationEngine→SceneEngineObjectEngine \rightarrow StateEngine \rightarrow RelationEngine \rightarrow SceneEngine$

↓

$KnowledgeEngine→CapabilityEngine→MethodEngineKnowledgeEngine \rightarrow CapabilityEngine \rightarrow MethodEngine$

↓

$MatchingEngine→DecisionEngineMatchingEngine \rightarrow DecisionEngine$

↓

$BehaviorEngine→ActionEngine→ExecutionEngineBehaviorEngine \rightarrow ActionEngine \rightarrow ExecutionEngine$

↓

$FeedbackEngine→MemoryEngine→ExperienceEngine→LearningEngineFeedbackEngine \rightarrow MemoryEngine \rightarrow ExperienceEngine \rightarrow LearningEngine$

↓

$Knowledge/Capability/MethodKnowledge/Capability/Method$

形成完整认知闭环。

其中MethodEngine位于：

$Capability→Method→Matching→DecisionCapability \rightarrow Method \rightarrow Matching \rightarrow Decision$

这一核心链路中。

195.39 MethodEngine的四项核心能力

因此，本章四项功能可以统一为：

第一，方法计算

回答：

当前方法具有什么结构、条件、过程、动作、能力要求和结果要求？

形式：

$Calculate(M,G,O,C)→MCCalculate(M,G,O,C)\rightarrow MC$

第二，方法选择

回答：

哪些方法满足当前必要条件，可以进入候选集合？

形式：

$Select(MC,C)→CandidatesSelect(MC,C)\rightarrow Candidates$

最终选择可以由DecisionEngine完成。

第三，方法组合

回答：

多个方法能否按照依赖、顺序、能力、资源和状态约束组合起来？

形式：

$Compose(M1,…,Mn)→McCompose(M_1,…,M_n)\rightarrow M_c$

第四，方法验证

回答：

实际执行结果是否证明该方法在规定条件下有效？

形式：

$Verify(M,E,R,F,C)→VVerify(M,E,R,F,C)\rightarrow V$

四者形成：

$Calculate→Select→Compose→Verify\boxed{ Calculate \rightarrow Select \rightarrow Compose \rightarrow Verify }$

195.40 本章总结

MethodEngine是ICAI中连接“能力”和“行为”的核心Engine。

Capability回答：

能不能做。

Method回答：

怎么做。

Matching回答：

当前方法是否符合要求。

MethodEngine回答：

方法本身如何计算、如何形成候选、如何组合以及如何通过实际结果验证。

其核心模型为：

$ME=(M,O,G,C,K,D,S,V,T)ME=(M,O,G,C,K,D,S,V,T)$

核心流程为：

$Method→Calculate→Match→Candidate→Select→Compose→Execute→VerifyMethod \rightarrow Calculate \rightarrow Match \rightarrow Candidate \rightarrow Select \rightarrow Compose \rightarrow Execute \rightarrow Verify$

最终形成：

$Capability→Method→Matching→Decision→Behavior→Action→Execution→Result→Feedback→Verification→Learning\boxed{ Capability \rightarrow Method \rightarrow Matching \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow Verification \rightarrow Learning }$

MethodEngine不直接替代DecisionEngine，不直接替代BehaviorEngine，也不直接承担数据库持久化。

它的核心职责始终保持为：

$MethodEngine=方法计算+方法候选+方法选择计算+方法组合+方法验证\boxed{ MethodEngine = 方法计算 + 方法候选 + 方法选择计算 + 方法组合 + 方法验证 }$

通过这一Engine，ICAI中的“方法”从静态的数据记录进一步成为可以被计算、比较、组合、验证和持续更新的工程对象。

最终：

$Methodt→Calculate→Select→Compose→Execute→Verify→Methodt+1\boxed{ Method_t \rightarrow Calculate \rightarrow Select \rightarrow Compose \rightarrow Execute \rightarrow Verify \rightarrow Method_{t+1} }$

这构成了ICAI方法认知与方法演化的基本工程闭环。

第195章 MethodEngine

第195章 MethodEngine

195.1 MethodEngine的定义

195.2 MethodEngine的统一模型

195.3 MethodEngine与Method对象

195.4 方法计算

195.4.1 方法计算定义

195.5 方法计算内容

195.6 方法条件计算

195.7 方法计算与MatchingEngine

195.8 方法候选生成

195.9 方法选择

195.9.1 方法选择的定义

195.10 方法选择条件

195.11 方法选择与DecisionEngine的区别

195.12 方法组合

195.12.1 方法组合定义

195.13 方法组合模型

195.14 方法组合的顺序约束

195.15 方法组合的能力约束

195.16 方法组合的资源约束

195.17 方法组合状态

195.18 方法验证

195.18.1 方法验证定义

195.19 方法验证模型

195.20 方法验证的核心条件

195.21 方法验证不等于方法执行

195.22 方法有效范围

195.23 方法验证后的更新

195.24 方法计算、选择、组合、验证的统一闭环

195.25 MethodEngine与BehaviorEngine

195.26 MethodEngine与ActionEngine

195.27 MethodEngine与RiskEngine

195.28 MethodEngine与ConflictEngine

195.29 MethodEngine的PHP工程结构

195.30 MethodEngine核心PHP结构

195.31 方法组合的工程对象

Method

MethodStep

MethodDependency

MethodCondition

MethodRequirement

MethodComposition

MethodVerification

195.32 方法组合数据库

methods

method_conditions

method_processes

method_actions

method_compositions

method_dependencies

method_verifications

195.33 方法选择结果

195.34 方法验证结果

195.35 方法生命周期

195.36 方法学习闭环

195.37 MethodEngine完整工程流程

195.38 MethodEngine在ICAI中的位置

195.39 MethodEngine的四项核心能力

第一，方法计算

第二，方法选择

第三，方法组合

第四，方法验证

195.40 本章总结

Leave a Reply Cancel reply