第177章　MethodService

在 ICAI 工程体系中，Capability 解决的是“能不能做”，而 Method 解决的是“怎么做”。

第176章已经建立了 CapabilityService，使系统能够读取能力、匹配能力、验证能力并更新能力。能力匹配完成之后，系统还不能直接进入执行阶段，因为一个目标通常可能对应多个可行方法。

例如：

Goal = 获取杯子

Capability：
Move
DetectObject
Grasp

此时系统已经知道个体具有完成任务所需要的能力，但仍然需要进一步回答：

采用什么方法完成？
方法需要哪些步骤？
方法需要哪些条件？
多个方法之间如何组合？
哪个方法当前可以使用？

这就是 MethodService 的职责范围。

因此，本章将 MethodService 定义为：

MethodService 是负责方法对象读取、方法匹配、方法组合与方法更新，并协调方法状态、条件、过程、动作及实际结果的应用服务。

其核心模型为：

$MS=(R,M,C,U)MS=(R,M,C,U)$

其中：

$RR$ = Read，方法读取；
$MM$ = Match，方法匹配；
$CC$ = Compose，方法组合；
$UU$ = Update，方法更新。

完整结构为：

Goal
 ↓
Capability
 ↓
MethodService
 ├── Read
 ├── Match
 ├── Compose
 └── Update
 ↓
DecisionService
 ↓
Selected Method
 ↓
Behavior
 ↓
Action
 ↓
Execution

MethodService 位于 CapabilityService 与 DecisionService 之间，是从“拥有能力”进入“选择执行方法”的关键服务层。

一、方法读取

方法读取（Method Read）负责从持久化层读取完整 Method 对象。

前面的 Method 类已经定义：

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

其中：

$TT$ = Method Type，方法类型；
$CC$ = Condition，方法成立条件；
$PP$ = Process，方法过程；
$AA$ = Action，方法动作集合；
$RR$ = Result，方法预期或实际结果信息。

因此，一个 Method 并不是数据库中的一条简单记录。

它至少具有：

Method
 ├── Type
 ├── Condition
 ├── Process
 │    ├── Step 1
 │    ├── Step 2
 │    └── Step N
 ├── Actions
 └── Result

所以 MethodService 的读取过程应该是：

Method ID
 ↓
MethodRepository
 ↓
Method Record
 ↓
Method Conditions
 ↓
Method Process
 ↓
Method Actions
 ↓
Method Result
 ↓
Method Domain Object

例如：

Method:
Type = FetchObject

Condition:
ObjectLocated = true
MoveCapability = available
GraspCapability = available

Process:
1. Locate
2. Move
3. Align
4. Grasp
5. Confirm

Action:
LocateObject
MoveToObject
AlignGripper
GraspObject
ConfirmObject

Result:
ObjectHeld = true

读取时必须重新构造完整方法。

因此：

MethodRepository 保存的是方法持久化结构，Method 才是运行时的方法领域对象。

二、方法读取不能等于读取方法名称

例如数据库中：

id = 10
name = Fetch Object

只能说明系统存在一个名称为 Fetch Object 的记录。

不能直接说明：

方法可用
方法条件满足
方法步骤完整
方法动作有效
方法结果可靠

因此 MethodService 读取后还必须能够获得：

Method
 ↓
Condition
 ↓
Process
 ↓
Action
 ↓
Expected Result
 ↓
State

进一步可以形成：

$Read(M)→{T,C,P,A,R,S}Read(M)\rightarrow \{T,C,P,A,R,S\}$

其中 $SS$ 表示方法当前状态。

这样才能进入后续 Method Matching。

三、方法匹配

方法匹配（Method Matching）解决的问题是：

当前方法是否适合当前 Goal、Capability、Object、Condition 与 Environment？

这与 Capability Matching 不相同。

Capability Matching：

我有没有能力做？

Method Matching：

这个方法是否适合当前条件？

例如：

Capability：
Move
Grasp
DetectObject

可以支持“获取杯子”。

但系统可能有两个方法：

Method A：
从正面接近 → 抓取

Method B：
从侧面接近 → 抓取

两个方法都依赖：

Move
Grasp
DetectObject

但当前环境可能决定只有一个方法适合。

因此方法匹配必须综合：

Goal
+
Required Capability
+
Method Condition
+
Object State
+
Environment
+
Method State
+
Process Constraints

可以定义：

$Match(M,G,C,E)=RMatch(M,G,C,E)=R$

其中：

$MM$ = Method；
$GG$ = Goal；
$CC$ = Capability 集合；
$EE$ = Environment；
$RR$ = Matching Result。

四、方法匹配的基本条件

一个方法能够成为候选方法，至少需要经过以下检查：

Method Type
       ↓
Goal Match
       ↓
Capability Match
       ↓
Condition Match
       ↓
State Match
       ↓
Process Availability
       ↓
Action Availability
       ↓
Method Candidate

可以表示为：

$MM=T∧G∧C∧Co∧S∧P∧AMM= T\land G\land C\land Co\land S\land P\land A$

其中：

$TT$ = 方法类型匹配；
$GG$ = Goal 匹配；
$CC$ = 所需 Capability 满足；
$CoCo$ = 方法条件满足；
$SS$ = 方法状态允许；
$PP$ = 方法过程可执行；
$AA$ = 方法动作可用。

只有全部必要条件满足，方法才可以进入候选集合。

五、方法匹配与能力匹配的区别

这一边界必须保持清楚。

例如：

Goal：
把箱子移动到仓库

Capability：
Move
Lift
Carry

CapabilityService 判断：

Move  → Available
Lift  → Available
Carry → Available

但是 MethodService 还需要判断：

Method A：
Lift → Carry → Move

Method B：
Move → Lift → Carry

Method C：
UseCart → Move

如果当前箱子已经在推车上：

Method A → 可用
Method B → 不适合
Method C → 可用

因此：

CapabilityService
回答：
“有没有能力？”

MethodService
回答：
“哪些方法适合？”

DecisionService
回答：
“最终选择哪个？”

这是三个不同的工程职责。

六、方法组合

方法组合（Method Composition）是本章新增的重要职责。

一个复杂目标往往不能由单个 Method 完成。

例如：

Goal = 获取杯子

Method 1 = LocateCup
Method 2 = MoveToCup
Method 3 = GraspCup
Method 4 = ConfirmCup

这些方法可以组合成一个更高层的方法：

FetchCupMethod
    ↓
LocateCupMethod
    ↓
MoveToCupMethod
    ↓
GraspCupMethod
    ↓
ConfirmCupMethod

因此：

$MC=(M1,M2,…,Mn,R)M_C = (M_1,M_2,\ldots,M_n,R)$

其中：

$MCM_C$ = Composite Method，组合方法；
$M1\dotsMnM_1\dotsM_n$ = 子方法；
$RR$ = 方法之间的执行关系。

组合方法不是简单把几个方法放进数组。

必须定义：

顺序
条件
依赖
输入
输出
失败处理
状态

七、方法组合的顺序关系

最基本的方法组合是顺序组合：

Method A
 ↓
Method B
 ↓
Method C
 ↓
Method D

例如：

Locate
 ↓
Move
 ↓
Grasp
 ↓
Confirm

形式化：

$MC=M1→M2→M3→M4M_C=M_1\rightarrow M_2\rightarrow M_3\rightarrow M_4$

只有前一个方法达到允许进入下一方法的条件，后一个方法才能启动。

例如：

Locate
 ↓
Result = ObjectFound
 ↓
Move

如果：

Locate
 ↓
Result = ObjectNotFound

则：

Move

不能直接执行。

因此方法组合必须建立在 Result 与 Condition 之上。

八、方法组合的条件关系

方法之间还可以形成条件分支：

Method A
 ↓
Result
 ├── Success → Method B
 └── Failure → Method C

例如：

DetectObject
 ↓
Found?
 ├── Yes → MoveToObject
 └── No  → SearchObject

这说明 Composite Method 不只是：

M1 + M2 + M3

而是：

$MC=(M,R,C,D)M_C=(M,R,C,D)$

其中：

$MM$ = 子方法集合；
$RR$ = 方法关系；
$CC$ = 方法转换条件；
$DD$ = 方法依赖。

因此，一个复杂方法实际上可以形成方法图：

          Detect
             ↓
         Object Found?
          /          \
        Yes           No
        ↓              ↓
      Move           Search
        ↓              ↓
      Grasp ←──────────┘
        ↓
     Confirm

这里的方法组合已经成为一个结构化执行计划，但它本身仍然不是 Behavior。

九、Method 与 Behavior 的边界

Method 与 Behavior 必须严格区分。

Method 是：

完成某类目标或任务所采用的方法结构。

Behavior 是：

个体在当前运行环境中组织并执行方法与动作的实际行为。

例如：

Method：
FetchCup

Behavior：
Robot_01 当前执行 FetchCup

因此：

Method
 ↓
提供执行方案
 ↓
Decision
 ↓
Selected Method
 ↓
Behavior
 ↓
Action
 ↓
Execution

MethodService 可以负责：

读取方法
匹配方法
组合方法
更新方法

但不负责：

实际 Action 执行
实际 Behavior 执行
实际 Execution

这些属于后面的 Behavior / Action / Execution 层。

十、方法组合与 Capability 的关系

组合方法中的每一个子方法，都可能要求不同的 Capability。

例如：

FetchCup
 ├── LocateCup
 │    └── DetectObject
 │
 ├── MoveToCup
 │    └── Move
 │
 ├── GraspCup
 │    └── Grasp
 │
 └── ConfirmCup
      └── DetectObject

因此组合方法可以建立 Capability Dependency：

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

系统在匹配组合方法时，需要检查全部必要能力。

如果：

DetectObject = Available
Move = Available
Grasp = Unavailable

那么：

FetchCupMethod = NotAvailable

或者根据方法结构进入替代方法：

Grasp
 ↓
Unavailable
 ↓
Alternative Method
 ↓
Use SuctionGripper

这就把 CapabilityService 与 MethodService 连接起来。

十一、方法更新

方法更新（Method Update）负责处理方法结构、条件、过程、动作依赖以及结果信息的变化。

方法更新可以表示为：

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

其中：

$MtM_t$ = 当前方法；
$ΔF\Delta F$ = 新增事实、结果、反馈、经验或验证信息；
$Mt+1M_{t+1}$ = 更新后的方法。

方法更新来源包括：

Execution Result
Feedback
Verification
Experience
Failure
Diagnosis
Repair
Capability Change
Environment Change
Object Change
Decision History

例如：

Method A
Move → Grasp

连续执行后发现：

Move → Grasp
Failure Rate 高

进一步 Diagnosis 发现：

Grasp 前需要重新 Align

于是方法更新：

Move
 ↓
Align
 ↓
Grasp

这就是方法结构根据实际结果发生变化。

十二、方法更新不能等于覆盖原方法

如果系统直接：

UPDATE methods
SET process = 'Move,Align,Grasp'

虽然数据库数据发生变化，但系统会失去重要的历史信息。

因为 ICAI 中的方法变化本身就是认知历史的一部分。

因此应该记录：

Method Version
Method History
Update Reason
Previous Structure
New Structure
Evidence
Result
Time

可以形成：

Method v1
 ↓
Execution
 ↓
Failure
 ↓
Diagnosis
 ↓
Method Update
 ↓
Method v2
 ↓
Verification
 ↓
Method v2 Valid

所以：

方法更新是方法演化，不是简单数据库覆盖。

十三、方法状态

Method 也具有生命周期状态。

例如：

Created
 ↓
Unverified
 ↓
Ready
 ↓
Available
 ↓
Running
 ↓
Completed

异常：

Running
 ↓
Failed
 ↓
Diagnosis
 ↓
Repair / Update
 ↓
Verification
 ↓
Ready

也可能：

Available
 ↓
Blocked
 ↓
Disabled
 ↓
Archived

MethodService 可以协调状态变化，但状态转换规则仍然应该由 StateService / StateEngine 管理。

因此：

MethodService
       ↓
StateService
       ↓
StateEngine
       ↓
Method State

MethodService 不应该绕过状态规则直接修改状态。

十四、方法组合的工程对象

为了让方法组合真正成为工程对象，可以定义 MethodComposition：

class MethodComposition
{
    protected $id;
    protected $methodId;
    protected $childMethods;
    protected $relations;
    protected $conditions;

    public function addMethod($method)
    {
        $this->childMethods[] = $method;
    }

    public function addRelation($relation)
    {
        $this->relations[] = $relation;
    }

    public function addCondition($condition)
    {
        $this->conditions[] = $condition;
    }

    public function getMethods()
    {
        return $this->childMethods;
    }
}

这里的关键不是代码本身，而是明确：

Composite Method
=
Method Set
+
Method Relation
+
Condition
+
Execution Order

因此 Method 之间也可以使用 RelationService 建立关系。

例如：

Method A
    |
    | before
    ↓
Method B

或者：

Method A
    |
    | requires
    ↓
Method B

或者：

Method A
    |
    | alternative_to
    ↓
Method B

这样 Method Composition 可以与 ICAI 的统一 Relation 体系连接。

十五、MethodService 的 PHP 工程结构

在 PHP 5.6 / PHP 7.0 环境中，可以建立：

class MethodService
{
    protected $repository;
    protected $engine;
    protected $stateService;

    public function __construct(
        $repository,
        $engine,
        $stateService
    ) {
        $this->repository = $repository;
        $this->engine = $engine;
        $this->stateService = $stateService;
    }

    public function get($id)
    {
        $data = $this->repository->find($id);

        if (!$data) {
            return null;
        }

        return new Method($data);
    }

    public function match($methodId, $context)
    {
        $method = $this->get($methodId);

        if (!$method) {
            return false;
        }

        return $this->engine->match(
            $method,
            $context
        );
    }

    public function compose($methodIds, $relations)
    {
        return $this->engine->compose(
            $methodIds,
            $relations
        );
    }

    public function update($methodId, $data)
    {
        $method = $this->get($methodId);

        if (!$method) {
            return false;
        }

        $method->update($data);

        return $this->repository->save($method);
    }
}

这里保持与第176章 CapabilityService 相同的工程原则：

Service
 ↓
协调流程

Engine
 ↓
方法匹配 / 方法组合计算

Domain Object
 ↓
Method 本身

StateService
 ↓
方法状态

Repository
 ↓
MySQL

十六、MethodRepository

MethodRepository 负责方法持久化。

可以定义：

class MethodRepository
{
    protected $db;

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

    public function find($id)
    {
        // 查询方法
    }

    public function findByType($type)
    {
        // 查询方法类型
    }

    public function findByCapability($capabilityId)
    {
        // 查询依赖指定能力的方法
    }

    public function save($method)
    {
        // 保存方法
    }
}

数据库结构可以进一步拆分：

methods
method_conditions
method_processes
method_actions
method_capabilities
method_compositions
method_relations
method_results
method_history
method_versions

这样能够保存完整的方法结构。

十七、方法匹配结果

Method Matching 不应只返回：

true

而应返回结构化结果：

MethodMatchResult
    ├── method_id
    ├── goal_match
    ├── capability_match
    ├── condition_match
    ├── state_match
    ├── process_match
    ├── action_match
    ├── matched
    └── reason

例如：

Method = FetchCup

Goal Match        = true
Capability Match  = true
Condition Match   = true
State Match       = true
Process Match     = true
Action Match      = true

Matched = true

如果 Grasp 能力不可用：

Goal Match        = true
Capability Match  = false
Condition Match   = true
State Match       = true

Matched = false
Reason = REQUIRED_CAPABILITY_UNAVAILABLE

这种结构可以直接提供给 DecisionService。

十八、MethodService 与 DecisionService

MethodService 的最终输出不是“执行”。

而是：

Method Candidates

完整流程：

Goal
 ↓
CapabilityService
 ↓
Available Capabilities
 ↓
MethodService
 ↓
Method Matching
 ↓
Method Composition
 ↓
Method Candidates
 ↓
DecisionService
 ↓
Selected Method

DecisionService 再根据：

Goal Priority
Method Conditions
Capability Availability
Risk
Conflict
History
Experience
Method Result History

进行选择。

因此：

MethodService 负责形成可行方法集合，DecisionService 负责从可行方法中进行选择。

这是 Service 层必须保持的关键边界。

十九、方法更新与 Experience

方法更新还可以与 Experience 建立关系。

例如：

Method A
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
History
 ↓
Experience

Experience 发现：

Condition X
+
Method A
+
Result Pattern Y

长期成立。

系统可以形成：

Experience
 ↓
Method Evaluation
 ↓
Method Update

因此：

$Experience→MethodUpdateExperience \rightarrow MethodUpdate$

但 Experience 不应该直接覆盖 Method。

正确过程仍然是：

Experience
 ↓
Method Update Candidate
 ↓
Method Verification
 ↓
Method Update
 ↓
New Method Version

这样能够避免未经验证的经验直接改变正式方法。

二十、方法失败与更新

方法失败不能简单理解为：

Method = Invalid

因为失败可能来自：

Capability 不足
Condition 不满足
Environment 改变
Object State 改变
Action 失败
Resource 不足
Method 本身存在缺陷

因此方法失败后的处理流程应当是：

Method
 ↓
Execution
 ↓
Result
 ↓
Failure
 ↓
Diagnosis
 ↓
Cause
 ├── Capability Problem
 ├── Condition Problem
 ├── Action Problem
 ├── Environment Problem
 └── Method Problem

只有 Diagnosis 判断：

Cause = Method Problem

才进入：

Method Update
 ↓
New Version
 ↓
Verification

这与第165章 Risk / Diagnosis / Repair 体系保持一致。

二十一、MethodService 的完整闭环

MethodService 的完整运行过程可以表示为：

Goal
 ↓
Required Capability
 ↓
Capability Matching
 ↓
Method Read
 ↓
Method Matching
 ↓
Method Composition
 ↓
Method Candidates
 ↓
Decision
 ↓
Selected Method
 ↓
Behavior
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Diagnosis / Experience
 ↓
Method Update
 ↓
Verification
 ↓
New Method Version

形式化为：

$Mt→Matcht→Decisiont→Executiont→Resultt→Feedbackt→Updatet→Mt+1M_t \rightarrow Match_t \rightarrow Decision_t \rightarrow Execution_t \rightarrow Result_t \rightarrow Feedback_t \rightarrow Update_t \rightarrow M_{t+1}$

这使 Method 成为一种能够通过实际运行结果不断修正的工程对象。

二十二、MethodService 与其他 Service 的统一边界

到目前为止，Service 层已经形成较清晰的对象管理体系：

IndividualService
        ↓
Individual

ObjectService
        ↓
Object

StateService
        ↓
State

RelationService
        ↓
Relation

KnowledgeService
        ↓
Knowledge

GoalService
        ↓
Goal

CapabilityService
        ↓
Capability

MethodService
        ↓
Method

它们并不是彼此孤立的 CRUD 服务，而是围绕 ICAI Domain Object 建立的应用服务。

其中：

GoalService
→ 形成目标

CapabilityService
→ 判断能力

MethodService
→ 形成可行方法

DecisionService
→ 选择方法

BehaviorService
→ 组织行为

ActionService
→ 组织动作

ExecutionService
→ 产生实际执行

ResultService
→ 形成实际结果

FeedbackService
→ 返回执行反馈

由此逐渐形成完整认知执行链。

二十三、MethodService 的最终模型

本章可以将 MethodService 正式定义为：

$MS=(R,M,C,U)MS=(R,M,C,U)$

其中：

$R=Method ReadR=Method\ Read$

负责读取完整方法结构；

$M=Method MatchM=Method\ Match$

负责判断方法是否满足当前 Goal、Capability、Condition、State 和 Process 要求；

$C=Method ComposeC=Method\ Compose$

负责将多个方法按照顺序、条件、依赖和关系组织为组合方法；

$U=Method UpdateU=Method\ Update$

负责根据 Execution Result、Feedback、Diagnosis、Experience、Capability Change 等信息更新方法。

因此：

MethodService
=
Read
+
Match
+
Compose
+
Update

最终形成：

Capability
 ↓
Method Read
 ↓
Method Match
 ↓
Method Compose
 ↓
Method Candidates
 ↓
Decision
 ↓
Selected Method
 ↓
Behavior
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Diagnosis / Experience
 ↓
Method Update
 ↓
Verification
 ↓
New Method

二十四、本章总结

MethodService 是 ICAI Service 层中承接 Capability 与 Decision 的核心服务。

本章建立了四项主要职责：

方法读取
方法匹配
方法组合
方法更新

其核心模型为：

$MethodService=(Read,Match,Compose,Update)MethodService=(Read,Match,Compose,Update)$

其中，方法读取保证系统能够获得完整 Method 对象；方法匹配判断当前方法是否适合当前目标、能力和环境；方法组合把多个方法按照关系、条件和顺序组织成更高层的方法结构；方法更新则依据真实执行结果、反馈、诊断和经验对方法进行版本化调整。

最重要的工程边界是：

CapabilityService
回答：
“有没有能力？”

MethodService
回答：
“有哪些可行的方法？”

DecisionService
回答：
“现在选择哪个方法？”

BehaviorService
回答：
“如何组织当前行为？”

Execution
回答：
“实际发生了什么？”

因此，ICAI 的方法体系形成：

$Capability→Method→Decision→Behavior→Action→ExecutionCapability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution$

而方法本身又能够通过实际运行形成：

$Method→Execution→Result→Feedback→Diagnosis/Experience→MethodUpdateMethod \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow Diagnosis/Experience \rightarrow MethodUpdate$

最终形成：

方法读取 → 方法匹配 → 方法组合 → 方法选择 → 方法执行 → 方法反馈 → 方法更新

这一闭环，使 Method 从静态的“操作方案”成为能够被组合、验证、修正和持续演化的 ICAI 工程对象。

第177章 MethodService

第177章 MethodService

一、方法读取

二、方法读取不能等于读取方法名称

三、方法匹配

四、方法匹配的基本条件

五、方法匹配与能力匹配的区别

六、方法组合

七、方法组合的顺序关系

八、方法组合的条件关系

九、Method 与 Behavior 的边界

十、方法组合与 Capability 的关系

十一、方法更新

十二、方法更新不能等于覆盖原方法

十三、方法状态

十四、方法组合的工程对象

十五、MethodService 的 PHP 工程结构

十六、MethodRepository

十七、方法匹配结果

十八、MethodService 与 DecisionService

十九、方法更新与 Experience

二十、方法失败与更新

二十一、MethodService 的完整闭环

二十二、MethodService 与其他 Service 的统一边界

二十三、MethodService 的最终模型

二十四、本章总结