第176章　CapabilityService

Capability 是 ICAI 个体认知与执行体系中的核心对象之一。前面的 Capability 类已经定义了能力本身的结构，而 CapabilityService 则负责能力对象在系统运行过程中的读取、匹配、验证与更新。

CapabilityService 并不是 Capability 本身，也不是能力计算规则的集合。它属于应用服务层，主要负责协调能力对象、能力规则、状态、验证结果以及持久化数据之间的处理过程。

因此，本章将 CapabilityService 定义为：

CapabilityService 是负责能力对象生命周期管理，并协调能力读取、能力匹配、能力验证和能力更新的应用服务。

其核心模型可以表示为：

CS=(R,M,V,U)CS=(R,M,V,U)

其中：

• RR = Read，能力读取；
• MM = Match，能力匹配；
• VV = Verify，能力验证；
• UU = Update，能力更新。

完整关系为：

Individual
   ↓
Capability
   ↓
CapabilityService
   ├── Read
   ├── Match
   ├── Verify
   └── Update
   ↓
CapabilityEngine / VerificationService / CapabilityRepository

CapabilityService 的核心任务不是“创造一个能力”，而是让系统能够正确知道：

当前有哪些能力
        ↓
某个能力是否适用于当前目标
        ↓
该能力是否满足当前条件
        ↓
该能力是否已经被验证
        ↓
能力当前状态是否发生变化

---

一、能力读取

能力读取（Capability Read）是 CapabilityService 最基础的职责。

系统中的 Capability 不能只存在于 PHP 对象的临时内存中，还必须能够从持久化层读取，并重新构造为完整的 Capability Domain Object。

Capability 本身在前面的模型中定义为：

C=(T,Co,S,R,V)C=(T,Co,S,R,V)

其中：

• TT = Capability Type，能力类型；
• CoCo = Condition，能力成立条件；
• SS = State，能力当前状态；
• RR = Range，能力适用范围；
• VV = Verification，能力验证信息。

因此，CapabilityService 的读取不能只读取一个 capability_id。

正确的读取过程应当是：

Capability ID
    ↓
CapabilityRepository
    ↓
Capability Record
    ↓
Capability Condition
    ↓
Capability Range
    ↓
Capability State
    ↓
Capability Verification
    ↓
Capability Domain Object

例如，一个机器人具有：

Capability:
Type = Move
Condition = Battery > 20%
Range = Distance <= 100m
State = Ready
Verification = Verified

当系统读取该能力时，需要得到一个完整能力对象，而不是只有：

id = 15

因此可以定义：

class CapabilityService
{
    protected $repository;

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

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

        if (!$data) {
            return null;
        }

        return new Capability($data);
    }
}

实际工程中还需要根据系统结构继续加载：

Capability
 ├── Condition
 ├── Range
 ├── State
 └── Verification

因此更完整的读取过程为：

find Capability
    ↓
load Conditions
    ↓
load Range
    ↓
load State
    ↓
load Verification
    ↓
assemble Capability

这里必须区分：

数据库记录不是 Capability 本身。

数据库负责保存 Capability 的持久化信息，而 PHP 中的 Capability 对象才是运行过程中的领域对象。

---

二、能力匹配

能力匹配（Capability Matching）是 CapabilityService 最重要的职责之一。

能力匹配回答的问题是：

当前个体的能力，是否能够满足当前目标、任务或条件的要求？

它不是简单判断：

Capability Type 是否相同

而是需要综合考虑：

能力类型
+
能力条件
+
当前状态
+
适用范围
+
目标要求
+
验证状态

因此可以定义能力匹配函数：

Match(C,G,E)=MMatch(C,G,E)=M

其中：

• CC = 当前 Capability；
• GG = 当前 Goal 或任务要求；
• EE = 当前环境与执行条件；
• MM = 匹配结果。

匹配结果不能简单设计为 true / false，因为工程系统需要知道为什么匹配或为什么不匹配。

因此可以定义：

CapabilityMatch
    ├── capability_id
    ├── target_id
    ├── condition_result
    ├── range_result
    ├── state_result
    ├── verification_result
    ├── matched
    └── reason

例如：

目标：
MoveTo(RoomB)

能力：
Move

检查：

Capability Type = Move       → 通过
State = Ready                 → 通过
Battery > 20%                 → 通过
Distance <= 100m              → 通过
Verification = Verified       → 通过

最终：
Matched = true

如果当前电量只有 10%：

Capability Type = Move       → 通过
State = Ready                 → 通过
Battery > 20%                 → 失败
Distance <= 100m              → 通过
Verification = Verified       → 通过

最终：
Matched = false
Reason = ConditionNotSatisfied

这说明：

能力存在，不等于能力当前可用。

Capability 与当前任务之间至少存在三个不同层次：

Capability Exists
        ↓
Capability Available
        ↓
Capability Matches Goal

进一步可以形成：

A(C)=T∧Co∧S∧R∧VA(C)=T\land Co\land S\land R\land V

其中：

• TT = 类型满足；
• CoCo = 条件满足；
• SS = 当前状态允许；
• RR = 范围满足；
• VV = 能力已经得到必要验证。

只有这些条件共同成立，Capability 才能够进入后续 Method Candidate 或 Decision Candidate。

---

三、能力匹配与 Method 的关系

CapabilityService 不负责选择最终执行方法。

这一点必须与前面的 MethodService、DecisionService 保持边界。

完整关系是：

Goal
 ↓
Required Capability
 ↓
CapabilityService
 ↓
Capability Matching
 ↓
Available Capability
 ↓
Method Candidates
 ↓
DecisionService
 ↓
Selected Method

因此：

CapabilityService
        ↓
回答：
“这个个体有没有适合当前目标的能力？”

而：

DecisionService
        ↓
回答：
“多个可行方案中现在选择哪一个？”

例如：

Goal = 获取杯子

Individual：
Capability 1 = Move
Capability 2 = Grasp
Capability 3 = DetectObject
Capability 4 = Speak

CapabilityService 进行匹配：

Move          → Match
DetectObject  → Match
Grasp         → Match
Speak         → Not Required

然后形成候选能力集合：

MatchedCapabilities
=
{Move, DetectObject, Grasp}

系统随后才进入：

Method Candidates
        ↓
Decision
        ↓
Method Selection

因此 CapabilityService 不应该直接执行 Method。

---

四、能力验证

能力验证（Capability Verification）用于回答：

这个能力是否已经通过实际证据证明可以成立？

Capability 的声明：

Robot can move

并不等于：

Robot has successfully moved under required conditions

因此 Capability 必须具有 Verification 信息。

能力验证可以表示为：

V(C)=E∧R∧S∧PV(C)=E\land R\land S\land P

其中：

• EE = Evidence，验证证据；
• RR = Result，实际结果；
• SS = State，验证后的状态；
• PP = Verification Procedure，验证过程。

能力验证过程：

Capability
    ↓
Verification Condition
    ↓
Verification Method
    ↓
Actual Execution
    ↓
Actual Result
    ↓
Result Comparison
    ↓
Verification
    ↓
Capability State

例如：

Capability = Move 100m

验证条件：
Battery >= 30%
Distance = 100m

执行：
Move(100m)

实际结果：
Completed
Distance = 100m

比较：
Expected = 100m
Actual = 100m

Verification = Passed

如果实际只能移动 60m：

Expected = 100m
Actual = 60m
Verification = Failed

此时不能继续认为：

Move 100m = Verified

而应该更新：

Verification = Failed
Capability State = Limited / Unverified

因此：

能力验证必须建立在实际执行结果之上，而不能仅根据能力名称、配置或预先声明确定。

---

五、能力验证与 Verification 类的关系

前面已经建立 Verification 概念，因此 CapabilityService 不应重新创造一套独立验证体系。

正确结构是：

CapabilityService
        ↓
VerificationService
        ↓
Verification
        ↓
Evidence / Result

CapabilityService 负责：

什么时候需要验证
验证哪个 Capability
验证结果如何回写 Capability

VerificationService 则负责：

验证过程
证据检查
结果比较
验证状态

因此二者职责不同：

对象	核心职责
Capability	表示能力
CapabilityService	管理能力生命周期
CapabilityEngine	能力匹配与规则计算
Verification	表示验证对象
VerificationService	执行验证逻辑
CapabilityRepository	持久化能力
StateService	管理能力状态转换

这样可以避免 CapabilityService 最终变成一个包含所有逻辑的巨大类。

---

六、能力更新

能力更新（Capability Update）用于处理能力在运行过程中发生的变化。

能力并不是永久不变的对象。

例如：

初始：
Battery > 20%
Range = 100m
State = Ready
Verification = Verified

经过多次运行以后可能变成：

Battery > 30%
Range = 60m
State = Limited
Verification = Verified

或者由于维修：

Range = 100m
State = Ready
Verification = Re-verified

因此能力更新可以表示为：

Ct+ΔF→Ct+1C_t+\Delta F\rightarrow C_{t+1}

其中：

• CtC_t = 当前能力；
• ΔF\Delta F = 新增事实、结果、反馈或验证信息；
• Ct+1C_{t+1} = 更新后的能力。

能力更新来源可以包括：

Execution Result
Feedback
Verification
State Change
Environment Change
Object Update
Memory
Experience
Diagnosis
Repair

完整过程：

Capability
      ↓
New Fact / Result / Feedback
      ↓
Capability Evaluation
      ↓
Change Detection
      ↓
Capability Update
      ↓
Verification
      ↓
New Capability State
      ↓
Memory / Experience

---

七、能力更新不能直接覆盖

能力更新不是简单：

$capability->range = 60;

然后直接保存数据库。

因为能力变化可能影响：

Method
Decision
Behavior
Risk
Experience
Knowledge

例如：

Move Range
100m
↓
实际执行失败
↓
Diagnosis
↓
发现电机性能下降
↓
Capability Range
100m → 60m

此时系统应该产生更新链：

Execution
 ↓
Result
 ↓
Feedback
 ↓
Diagnosis
 ↓
Capability Update
 ↓
Verification
 ↓
Method Availability Update
 ↓
Decision Candidate Update

所以 Capability Update 必须是一个受规则约束的过程。

---

八、能力更新的状态管理

Capability 本身具有 State。

例如：

created
unverified
ready
available
limited
blocked
failed
disabled
archived

状态转换必须通过 StateService 或相应 StateEngine 进行。

例如：

Created
   ↓
Unverified
   ↓
Verification Passed
   ↓
Ready
   ↓
Available

发生异常：

Available
   ↓
Execution Failure
   ↓
Diagnosis
   ↓
Limited

如果能力已经无法使用：

Limited
   ↓
Verification Failed
   ↓
Blocked

修复之后：

Blocked
   ↓
Repair
   ↓
Verification
   ↓
Ready

因此：

Capability Update 不等于 Capability State Update，但能力状态是能力更新的重要组成部分。

---

九、CapabilityService 的工程结构

按照 ICAI 的 Service / Domain / Engine / Repository 分层，可以形成：

Controller
    ↓
CapabilityService
    ├── CapabilityRepository
    ├── CapabilityEngine
    ├── VerificationService
    └── StateService

其中：

CapabilityService

负责：

读取
匹配协调
验证协调
更新协调
生命周期协调

CapabilityEngine

负责：

能力条件计算
能力范围计算
能力匹配
能力可用性判断

VerificationService

负责：

能力验证
证据检查
实际结果比较
验证状态

StateService

负责：

状态读取
状态判断
状态转换
状态保存
状态历史

CapabilityRepository

负责：

Capability 持久化
Capability 查询
Capability 更新
Capability 删除

因此：

Service = 协调
Engine = 计算
Domain Object = 业务对象
Verification = 验证
StateService = 状态管理
Repository = 持久化

---

十、CapabilityService 的 PHP 工程对象

在 PHP 5.6 / PHP 7.0 环境中，可以建立如下结构：

class CapabilityService
{
    protected $repository;
    protected $engine;
    protected $verificationService;
    protected $stateService;

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

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

        if (!$data) {
            return null;
        }

        return new Capability($data);
    }

    public function match($capabilityId, $context)
    {
        $capability = $this->get($capabilityId);

        if (!$capability) {
            return false;
        }

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

    public function verify($capabilityId, $evidence)
    {
        $capability = $this->get($capabilityId);

        if (!$capability) {
            return false;
        }

        return $this->verificationService->verify(
            $capability,
            $evidence
        );
    }

    public function update($capabilityId, $data)
    {
        $capability = $this->get($capabilityId);

        if (!$capability) {
            return false;
        }

        $capability->update($data);

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

这里最重要的不是代码数量，而是职责边界。

CapabilityService 不应该自己完成：

SQL
复杂匹配算法
状态转换规则
验证规则

这些工作分别由：

Repository
Engine
StateService
VerificationService

承担。

---

十一、CapabilityRepository

CapabilityRepository 负责 Capability 的持久化。

例如：

class CapabilityRepository
{
    protected $db;

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

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

    public function save($capability)
    {
        // 保存 capability
    }

    public function findByIndividual($individualId)
    {
        // 查询 Individual 的全部能力
    }
}

数据库可以建立：

capabilities

核心字段：

id
individual_id
type
state
range_value
range_unit
verification_state
created_at
updated_at

条件可以独立：

capability_conditions

验证信息：

capability_verifications

状态历史：

capability_state_history

这样 Capability 的结构不会被强行压缩到一张表中。

---

十二、能力匹配的工程计算过程

能力匹配可以进一步形成标准计算流程：

读取 Capability
      ↓
读取当前 State
      ↓
读取 Condition
      ↓
读取 Range
      ↓
读取 Verification
      ↓
读取 Goal / Requirement
      ↓
构造 Match Context
      ↓
CapabilityEngine
      ↓
条件计算
      ↓
范围计算
      ↓
状态计算
      ↓
验证状态计算
      ↓
生成 Match Result

可以定义：

M(C,G,E)=T(C,G)∧Co(C,E)∧S(C)∧R(C,G,E)∧V(C)M(C,G,E)= T(C,G) \land Co(C,E) \land S(C) \land R(C,G,E) \land V(C)

其中：

• T(C,G)T(C,G) = Capability Type 是否满足 Goal；
• Co(C,E)Co(C,E) = Capability Condition 是否满足当前环境；
• S(C)S(C) = Capability State 是否允许使用；
• R(C,G,E)R(C,G,E) = Capability Range 是否满足目标与环境；
• V(C)V(C) = Capability 是否通过必要验证。

最终：

M=1M=1

表示当前能力可以进入候选集合。

M=0M=0

表示当前能力不能进入候选集合。

但是工程系统仍应保存失败原因，例如：

TYPE_NOT_MATCH
CONDITION_NOT_SATISFIED
STATE_NOT_AVAILABLE
RANGE_EXCEEDED
VERIFICATION_REQUIRED
VERIFICATION_FAILED

这样后面的 Diagnosis、Memory、Experience 才能够使用这些事实。

---

十三、能力读取、匹配、验证、更新形成闭环

四项能力服务职责并不是孤立的。

完整循环为：

Capability Read
      ↓
Capability Match
      ↓
Capability Use
      ↓
Execution
      ↓
Result
      ↓
Feedback
      ↓
Capability Verification
      ↓
Capability Update
      ↓
Capability Read
      ↓
Capability Match

可以进一步形成：

Ct→Matcht→Executiont→Resultt→Feedbackt→Verificationt→Ct+1C_t \rightarrow Match_t \rightarrow Execution_t \rightarrow Result_t \rightarrow Feedback_t \rightarrow Verification_t \rightarrow C_{t+1}

这意味着 CapabilityService 并不是简单的 CRUD Service。

它实际上连接了：

当前能力
    ↓
当前任务
    ↓
实际执行
    ↓
实际结果
    ↓
验证
    ↓
能力状态变化
    ↓
下一次能力匹配

因此 CapabilityService 是 Individual 从“拥有某项能力”走向“能够依据当前条件正确使用能力”的重要服务层。

---

十四、CapabilityService 与前后章节的连接

CapabilityService 需要与已经建立的 ICAI Service 体系保持清晰关系。

IndividualService
        ↓
Individual
        ↓
CapabilityService
        ↓
Capability

目标产生：

GoalService
    ↓
Goal
    ↓
Required Capability
    ↓
CapabilityService
    ↓
Capability Matching

能力匹配成功：

Capability
    ↓
Method Candidates
    ↓
DecisionService
    ↓
Decision
    ↓
Method

实际执行：

Method
    ↓
Behavior
    ↓
Action
    ↓
Execution
    ↓
Result
    ↓
Feedback

反馈返回：

Feedback
    ↓
Verification
    ↓
Capability Update
    ↓
Experience

因此完整认知工程链可以表示为：

Need
 ↓
Goal
 ↓
Required Capability
 ↓
CapabilityService
 ↓
Capability Matching
 ↓
Method Candidates
 ↓
DecisionService
 ↓
Method
 ↓
Behavior
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Verification
 ↓
Capability Update
 ↓
Memory
 ↓
Experience
 ↓
Next Decision

---

十五、CapabilityService 与 Capability 类的边界

必须再次强调 Domain Object 与 Service 的区别。

Capability

回答：

我具有什么能力？

它保存：

Type
Condition
State
Range
Verification

CapabilityService

回答：

系统现在如何读取、判断、验证和更新这个能力？

它负责：

Read
Match
Verify
Update

因此：

Capability = 能力对象
CapabilityService = 能力管理过程
CapabilityEngine = 能力计算
Verification = 能力验证对象
VerificationService = 验证过程
Repository = 能力持久化
StateService = 能力状态管理

如果把这些职责全部放入 Capability 类，就会导致：

Capability
 ├── SQL
 ├── Matching
 ├── Verification
 ├── State
 ├── Persistence
 ├── Decision
 └── Execution

最终形成巨型 Domain Object。

这与前面建立的 ICAI OOP 架构是不一致的。

正确结构应当坚持：

Domain Object
+
Service
+
Engine
+
Repository
+
State
+
Verification

---

十六、CapabilityService 的最终模型

经过以上定义，可以将 CapabilityService 正式定义为：

CS=(R,M,V,U)CS=(R,M,V,U)

其中：

R=Capability ReadR=Capability\ Read

负责读取完整 Capability 对象；

M=Capability MatchM=Capability\ Match

负责判断当前 Capability 是否满足 Goal、Condition、Range、State 与 Verification 要求；

V=Capability VerifyV=Capability\ Verify

负责协调实际执行证据、结果比较和能力验证；

U=Capability UpdateU=Capability\ Update

负责根据新的事实、结果、反馈、诊断、修复和验证信息更新 Capability。

四者形成：

Read
 ↓
Match
 ↓
Use
 ↓
Result
 ↓
Verify
 ↓
Update
 ↓
Read

进一步形成 ICAI 能力闭环：

Goal
 ↓
Required Capability
 ↓
Capability Read
 ↓
Capability Match
 ↓
Capability Available
 ↓
Method Candidate
 ↓
Decision
 ↓
Behavior
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Verification
 ↓
Capability Update
 ↓
Experience
 ↓
Future Capability Matching

---

十七、本章总结

CapabilityService 是 ICAI Service 层中连接“能力对象”和“实际任务执行”的核心服务。

本章建立了四项基本职责：

能力读取
能力匹配
能力验证
能力更新

其核心关系为：

CapabilityService=Read+Match+Verify+UpdateCapabilityService = Read + Match + Verify + Update

其中，能力读取保证系统获得完整 Capability 对象；能力匹配判断当前能力是否适合当前 Goal 和执行条件；能力验证通过实际执行结果确认能力是否真实成立；能力更新则根据新的事实、结果、反馈、诊断和验证信息调整能力状态与能力范围。

最终形成：

Capability
    ↓
Read
    ↓
Match
    ↓
Execution
    ↓
Result
    ↓
Feedback
    ↓
Verify
    ↓
Update
    ↓
New Capability State

由此，Capability 不再只是一个静态的“能力标签”，而成为一个能够被读取、判断、验证、修正并持续参与后续 Decision 的动态认知工程对象。

在整个 ICAI OOP 与 Service 架构中，可以最终明确：

Capability
= 能力领域对象

CapabilityService
= 能力生命周期协调服务

CapabilityEngine
= 能力匹配与规则计算

VerificationService
= 能力验证

StateService
= 能力状态管理

CapabilityRepository
= 能力持久化

DecisionService
= 从可用能力与方法候选中进行选择

因此，CapabilityService 的真正作用不是简单管理“能力数据”，而是建立：

能力存在 → 能力可用 → 能力匹配 → 能力执行 → 能力验证 → 能力更新

这一完整工程闭环，为后续 MethodService、DecisionService、BehaviorService 等服务提供可靠的能力基础。