第193章　CapabilityEngine

在 ICAI 的认知工程体系中，能力是连接“个体当前状态”和“实际可执行方法”的重要中间层。

第159章已经定义了 Capability（能力）：

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

其中：

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

Capability 回答的是：

当前这个 Individual、Object 或系统，是否具备完成某项任务所需要的能力？

而第176章的 CapabilityService 负责能力对象的读取、匹配、验证、更新以及服务层编排。

本章进一步进入 Engine 层，建立 CapabilityEngine（能力计算引擎）。

CapabilityEngine 的核心职责不是保存能力，也不是执行行为，而是对能力进行：

$CapabilityCalculation+CapabilityMatching+CapabilityVerification\boxed{ CapabilityCalculation+ CapabilityMatching+ CapabilityVerification }$

即：

能力计算 + 能力匹配 + 能力验证。

它负责根据对象、状态、知识、条件、范围、资源和实际执行证据，计算当前能力是否成立、是否适用，以及实际执行是否证明该能力真实存在。

193.1 Capability 的基本定义

能力不是一个简单的布尔值。

不能简单定义：

can = true

因为一个能力通常具有：

类型；
成立条件；
当前状态；
适用范围；
验证依据。

因此：

$Capability=(Type,Condition,State,Range,Verification)Capability=(Type,Condition,State,Range,Verification)$

例如：

Individual A
Capability:
Process Order

Condition:
Order data is complete

State:
Available

Range:
Orders <= 1000/day

Verification:
Verified

这比：

A can process orders

具有更准确的工程含义。

因为能力可能：

存在

但：

当前不可用

也可能：

能够处理

但：

超过能力范围

因此：

$CapabilityExists≠CapabilityAvailableCapabilityExists \neq CapabilityAvailable$

同时：

$CapabilityAvailable≠CapabilityVerifiedCapabilityAvailable \neq CapabilityVerified$

193.2 CapabilityEngine 的定义

CapabilityEngine 是根据当前对象、状态、条件、知识、范围和验证证据，对能力进行确定性计算、匹配和验证的 Engine。

可以定义：

$CE=(C,O,S,K,M,R,V,D)CE=(C,O,S,K,M,R,V,D)$

其中：

$CC$ = Capability；
$OO$ = Object；
$SS$ = State；
$KK$ = Knowledge；
$MM$ = Method；
$RR$ = Range；
$VV$ = Verification；
$DD$ = Discrete Calculation。

CapabilityEngine 的基本输入：

$Input=(C,O,S,K,Co,R,E,T)Input=(C,O,S,K,Co,R,E,T)$

其中：

$CC$ = 当前能力；
$OO$ = 当前对象；
$SS$ = 当前状态；
$KK$ = 相关知识；
$CoCo$ = 能力条件；
$RR$ = 能力范围；
$EE$ = 实际证据；
$TT$ = 时间。

输出：

$CapabilityResult=(Calc,Match,Verify,State,Evidence,Change,T)CapabilityResult= (Calc,Match,Verify,State,Evidence,Change,T)$

即：

能力计算结果；
能力匹配结果；
能力验证结果；
能力状态；
验证证据；
能力变化；
计算时间。

193.3 能力计算

能力计算是 CapabilityEngine 的第一项核心职责。

它解决：

根据当前事实，能力是否具备成立的基础？

能力不能凭名称直接判断。

例如：

Capability:
Process Order

不能直接得出：

Available = true

必须计算：

Individual存在
+
Capability类型正确
+
必要条件满足
+
当前状态允许
+
能力范围覆盖目标

可以定义：

$CapabilityAvailable=T∧Co∧S∧RCapabilityAvailable= T\land Co\land S\land R$

其中：

$TT$ = 能力类型成立；
$CoCo$ = 条件成立；
$SS$ = 当前状态允许；
$RR$ = 范围覆盖。

如果还要求经过验证：

$CapabilityVerified=T∧Co∧S∧R∧VCapabilityVerified= T\land Co\land S\land R\land V$

193.4 能力计算不是能力执行

CapabilityEngine 只计算：

能不能做。

它不负责：

现在就做。

因此：

$CapabilityEngine≠BehaviorEngineCapabilityEngine\neq BehaviorEngine$

也：

$CapabilityEngine≠ActionEngineCapabilityEngine\neq ActionEngine$

例如：

Capability:
Repair Device

CapabilityEngine 可以计算：

Capability = Available

但不会执行：

Repair Device

正确链路：

$CapabilityEngine→MethodEngine→DecisionEngine→BehaviorEngine→ActionEngineCapabilityEngine \rightarrow MethodEngine \rightarrow DecisionEngine \rightarrow BehaviorEngine \rightarrow ActionEngine$

193.5 能力计算的基本输入

CapabilityEngine 的计算至少需要考虑以下信息：

Individual
Object
Capability
State
Condition
Range
Knowledge
Resource
Time
Evidence

可以表示：

$Ccalc=F(I,O,C,S,Co,R,K,Res,T,E)C_{calc} = F(I,O,C,S,Co,R,K,Res,T,E)$

其中：

$II$ = Individual；
$OO$ = Object；
$CC$ = Capability；
$SS$ = State；
$CoCo$ = Condition；
$RR$ = Range；
$KK$ = Knowledge；
$ResRes$ = Resource；
$TT$ = Time；
$EE$ = Evidence。

193.6 能力计算的条件

能力成立通常需要多个条件同时满足。

例如：

Capability:
Operate Machine A

Conditions:
Operator is authorized
Machine is active
Training is verified
Operating range is valid

那么：

$CanOperate=Authorization∧MachineActive∧TrainingVerified∧RangeValidCanOperate= Authorization \land MachineActive \land TrainingVerified \land RangeValid$

只要其中一个必要条件不满足：

$CanOperate=FalseCanOperate=False$

但是工程系统不能只返回：

false

还应该知道：

原因：
TrainingVerified = false

因此能力计算结果必须具有可解释性。

193.7 能力计算结果

可以定义：

$CapabilityCalculationResult=(T,Co,S,R,V,E,Reason)CapabilityCalculationResult= (T,Co,S,R,V,E,Reason)$

其中：

$TT$ = 类型结果；
$CoCo$ = 条件结果；
$SS$ = 状态结果；
$RR$ = 范围结果；
$VV$ = 验证结果；
$EE$ = 证据；
$ReasonReason$ = 计算原因。

例如：

Capability:
Process Order

Type:
Matched

Condition:
Matched

State:
Available

Range:
Matched

Verification:
Verified

Result:
Available

如果范围不满足：

Range:
Exceeded

Result:
Unavailable

Reason:
Target quantity exceeds capability range

193.8 能力状态

CapabilityEngine 需要对能力状态进行计算。

可以定义：

Unknown
Unavailable
Available
Blocked
Limited
Expired
Suspended
Verified
Unverified
Invalid

这些状态不是简单标签，而应该由事实计算得到。

例如：

Capability = Available

如果资源被占用：

Capability = Blocked

如果能力范围只有：

0–100

但目标是：

则能力本身可能仍然存在：

Capability = Available

但对于当前任务：

Capability Match = Limited / Unmatched

这说明：

能力状态与能力匹配状态不能混为一谈。

193.9 能力范围计算

Range 是 Capability 的重要组成部分。

范围可以表示：

$Range=(Min,Max,Unit,Scope)Range=(Min,Max,Unit,Scope)$

例如：

Capacity:
1000

Unit:
orders/day

Scope:
Standard Orders

目标：

800 orders/day

则：

$800≤1000800\leq1000$

范围满足。

如果：

1200 orders/day

则：

$1200>10001200>1000$

能力范围不覆盖目标。

因此：

$RangeMatch(Target,CapabilityRange)→Matched/Partial/UnmatchedRangeMatch(Target,CapabilityRange) \rightarrow Matched/Partial/Unmatched$

193.10 能力范围不只是数量

Range 不仅是数量。

还可以包括：

Object Type
Size
Distance
Time
Frequency
Capacity
Environment
Geographic Scope
Operational Scope

例如：

Capability:
Deliver Goods

Range:
Distance <= 50 km
Weight <= 500 kg
Frequency <= 20 orders/day

那么一个任务：

Distance = 30 km
Weight = 300 kg
Frequency = 10/day

属于：

Fully Matched

而：

Distance = 80 km

则：

Range Exceeded

193.11 能力匹配

Capability Matching 是 CapabilityEngine 的第二项核心职责。

它解决：

当前任务、目标或对象需要的能力，与现有能力是否匹配？

基本模型：

$Match(Capability,Requirement,Context)→MMatch(Capability,Requirement,Context) \rightarrow M$

其中：

Capability = 已有能力；
Requirement = 能力要求；
Context = 当前上下文；
M = 匹配结果。

193.12 能力要求

Goal 或 Method 可以提出 Capability Requirement。

可以定义：

$CR=(T,C,R,S)CR=(T,C,R,S)$

其中：

$TT$ = Required Type；
$CC$ = Required Condition；
$RR$ = Required Range；
$SS$ = Required State。

例如：

Goal:
Process 500 orders

Required Capability:
Order Processing

Required Range:
>= 500 orders/day

Required State:
Available

CapabilityEngine 接收这个要求后，与已有能力进行匹配。

193.13 能力匹配维度

能力匹配至少包含：

Type Match
Condition Match
State Match
Range Match
Verification Match
Object Match
Resource Match
Time Match

可以表示：

$M=T∧Co∧S∧R∧VM= T\land Co\land S\land R\land V$

但实际系统中也需要允许：

Partial

因此可以使用离散匹配状态：

Matched
Partial
Unmatched
Unknown
Blocked
Conflicted
Expired

193.14 能力匹配不是能力计算

两者虽然相关，但职责不同。

能力计算：

这个能力当前是否成立？

能力匹配：

这个能力是否适合当前需求？

例如：

Capability:
Process 1000 orders/day

能力计算结果：

Available

当前 Goal：

Process 500 orders/day

能力匹配：

Matched

如果 Goal：

Process 2000 orders/day

能力本身仍可能：

Available

但是：

Capability Match = Unmatched

因此：

$CapabilityAvailable≠CapabilityMatchedCapabilityAvailable \neq CapabilityMatched$

193.15 能力匹配的结果模型

可以定义：

$CM=(C,CR,M,D,E,T)CM=(C,CR,M,D,E,T)$

其中：

$CC$ = 当前能力；
$CRCR$ = 能力要求；
$MM$ = 匹配状态；
$DD$ = 差异；
$EE$ = 证据；
$TT$ = 时间。

例如：

array(
    'capability_id' => 10,
    'requirement_id' => 20,
    'state' => 'partial',
    'difference' => array(
        'required_capacity' => 2000,
        'actual_capacity' => 1000
    )
);

这个结果可以直接交给 MethodEngine 或 DecisionEngine。

193.16 多能力组合

某些目标不能由单一能力完成。

例如：

Goal:
完成设备维修

可能需要：

Capability A:
Diagnosis

Capability B:
Repair

Capability C:
Testing

因此：

$RequiredCapability=C1+C2+C3RequiredCapability= C_1+C_2+C_3$

CapabilityEngine 可以分别计算：

C1 = Available
C2 = Available
C3 = Unavailable

最终：

$GoalCapabilityAvailable=C1∧C2∧C3GoalCapabilityAvailable= C_1\land C_2\land C_3$

结果：

Unavailable

原因：

Testing capability unavailable

这为后续 DecisionEngine 提供了明确依据。

193.17 能力依赖

能力之间也可以存在依赖关系。

例如：

Capability A:
Advanced Repair

依赖：

Capability B:
Basic Repair

可以表示：

$A→requires→BA\rightarrow requires\rightarrow B$

如果：

$B=UnavailableB=Unavailable$

则：

$AA$

可能变成：

Blocked

但不能简单认为：

A = Invalid

因为能力本身仍然存在，只是当前依赖条件不满足。

193.18 能力验证

Capability Verification 是 CapabilityEngine 的第三项核心职责。

它解决：

这个能力是否已经被实际事实证明？

这是能力系统最重要的区别之一。

理论上定义一个能力：

Capability:
Process Order

并不能证明：

这个 Individual 真正能够完成订单处理。

只有实际执行产生证据之后，才能验证。

因此：

$CapabilityVerification=Execution+Result+Feedback+EvidenceCapabilityVerification= Execution+ Result+ Feedback+ Evidence$

193.19 能力验证模型

可以定义：

$VC=(C,E,R,F,S,T)V_C=(C,E,R,F,S,T)$

其中：

$CC$ = Capability；
$EE$ = Execution；
$RR$ = Result；
$FF$ = Feedback；
$SS$ = State；
$TT$ = Time。

验证流程：

Capability
    ↓
Method
    ↓
Behavior
    ↓
Execution
    ↓
Result
    ↓
Feedback
    ↓
Verification

只有实际执行结果满足要求时：

Capability = Verified

193.20 能力验证不是能力声明

必须区分：

Declared Capability

和：

Verified Capability

例如系统记录：

Individual A
Capability:
Repair Device

这只是：

Declared

如果实际完成：

Device Repair

并且：

Result = Success
Verification = Passed

才可以进入：

Verified

因此：

$DeclaredCapability≠VerifiedCapabilityDeclaredCapability \neq VerifiedCapability$

193.21 能力验证的证据

验证需要 Evidence。

可以定义：

$Evidence=(Source,Type,Value,Time)Evidence=(Source,Type,Value,Time)$

例如：

Source:
Execution #1001

Type:
Actual Result

Value:
Repair completed successfully

Time:
2026-09-11

CapabilityEngine 根据证据计算：

Verification = Passed

如果结果不满足：

Verification = Failed

如果证据不足：

Verification = Unknown

193.22 能力验证状态

可以定义：

Unverified
Verified
Failed
Outdated
Invalid
Conflicted
Unknown

其中：

Unverified

只有能力定义，没有实际验证证据。

Verified

实际执行结果满足要求。

Failed

实际执行证明能力不能完成要求。

Outdated

过去验证过，但验证有效期已经过去。

Invalid

能力定义本身已经失效。

Conflicted

存在互相冲突的验证证据。

Unknown

目前无法得出确定结论。

193.23 验证与当前状态

即使能力过去已经验证，也不能永远认为当前可用。

例如：

昨天：
Capability = Verified

今天：

Resource = Unavailable

则：

Capability State = Blocked

而不是：

Capability = permanently available

因此必须区分：

$VerificationStateVerificationState$

和：

$CurrentCapabilityStateCurrentCapabilityState$

一个表示：

过去是否被证明。

另一个表示：

当前是否可用。

193.24 能力验证范围

验证也应该具有范围。

例如：

Capability:
Process Orders

Verified Range:
<= 1000 orders/day

这并不能证明：

2000 orders/day

同样可以完成。

因此：

$VerifiedRange≠TheoreticalRangeVerifiedRange \neq TheoreticalRange$

更准确地表示：

$Capability=TheoryRange+VerifiedRangeCapability= TheoryRange+ VerifiedRange$

实际匹配时优先使用已经验证的范围。

193.25 能力验证更新

当新的执行结果产生之后，CapabilityEngine 可以计算：

$Vt+ΔE→Vt+1V_t+\Delta E\rightarrow V_{t+1}$

例如：

原验证范围：
1000/day

实际验证：

1200/day

如果证据充分：

Verified Range
→
1200/day

但不能因为一次异常结果就直接把能力范围修改成更低值。

需要根据：

Evidence
+
Condition
+
Verification
+
History

进行判断。

因此：

$CapabilityUpdate≠SimpleOverwriteCapabilityUpdate \neq SimpleOverwrite$

193.26 能力失败

如果实际执行失败：

Capability
→
Method
→
Execution
→
Failure

不能立即得出：

Capability = Invalid

因为失败可能来自：

Resource Failure
Environment Failure
Method Failure
Action Failure
Condition Failure
Capability Failure

因此需要：

Failure
→
DiagnosisEngine
→
Cause

如果 DiagnosisEngine 确认：

Capability Cause

才可以进入：

Capability Verification Failed

这体现：

$Result≠DiagnosisResult \neq Diagnosis$

以及：

$Failure≠CapabilityInvalidFailure \neq CapabilityInvalid$

193.27 CapabilityEngine 与 DiagnosisEngine

CapabilityEngine 可以发现：

Capability Verification Failed

但不能直接决定：

为什么失败？

例如：

Capability:
Operate Machine

实际失败。

原因可能：

Machine Broken

也可能：

Operator Not Authorized

也可能：

Method Incorrect

因此：

$CapabilityEngine→DiagnosisEngineCapabilityEngine \rightarrow DiagnosisEngine$

CapabilityEngine 提供证据。

DiagnosisEngine 负责原因分析。

193.28 CapabilityEngine 与 KnowledgeEngine

KnowledgeEngine 可以提供能力计算所需要的知识。

例如：

Knowledge:
Method A requires Capability B

或者：

Knowledge:
Object X supports Operation Y

CapabilityEngine 根据这些知识进一步计算：

Capability Requirement

关系：

$KnowledgeEngine→CapabilityEngineKnowledgeEngine \rightarrow CapabilityEngine$

但：

$Knowledge≠CapabilityKnowledge\neq Capability$

Knowledge 描述事实。

Capability 描述能否执行某类操作。

193.29 CapabilityEngine 与 StateEngine

StateEngine 提供当前状态。

例如：

Machine = Active

CapabilityEngine 可以计算：

Operate Machine

是否可用。

因此：

$StateEngine→CapabilityEngineStateEngine \rightarrow CapabilityEngine$

但是：

Machine Active

并不自动等于：

Operate Machine = Available

还需要：

Authorization
Condition
Range
Verification

等其他条件。

193.30 CapabilityEngine 与 MethodEngine

MethodEngine 需要能力作为方法执行前提。

关系：

$Capability→MethodCapability \rightarrow Method$

例如：

Method:
Repair Machine

要求：

Capability:
Diagnosis
Capability:
Repair
Capability:
Testing

CapabilityEngine 计算：

C1 = Available
C2 = Available
C3 = Available

MethodEngine 才能判断：

Method = Applicable

因此：

$CapabilityEngine→MethodEngineCapabilityEngine \rightarrow MethodEngine$

193.31 CapabilityEngine 与 DecisionEngine

当存在多个能力或多个个体时，DecisionEngine 可以使用 CapabilityEngine 的计算结果。

例如：

Individual A
Capability = Available

Individual B
Capability = Available

Individual C
Capability = Blocked

CapabilityEngine 输出三个候选能力状态。

DecisionEngine 再选择：

或者：

因此：

$CapabilityEngine≠DecisionEngineCapabilityEngine\neq DecisionEngine$

CapabilityEngine 负责：

谁具备什么能力。

DecisionEngine 负责：

当前应该选择谁或选择哪个方案。

193.32 能力计算的确定性原则

CapabilityEngine 必须保持确定性。

对于相同输入：

$I,O,S,K,C,R,VI,O,S,K,C,R,V$

在相同规则：

$RulesRules$

下：

$F(Input,Rules)=ResultF(Input,Rules)=Result$

应该得到相同结果。

不能通过：

随机选择

或者：

生成式模型

决定能力。

CapabilityEngine 不使用：

LLM；
Transformer；
Embedding；
Vector Search；
Prompt Engineering；
Neural Network；
LLM API；
生成式大模型机制。

能力计算来源于：

Object
+
State
+
Condition
+
Range
+
Knowledge
+
Evidence
+
Rule

193.33 PHP OOP 工程实现

CapabilityEngine 可以保持 PHP 5.6 / 7.0 兼容。

基础 Engine：

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

CapabilityEngine：

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

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

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

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

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

        $calculation = $this->calculateCapability(
            $capability,
            $state,
            $condition,
            $range
        );

        $match = $this->matchCapability(
            $capability,
            isset($input['requirement'])
                ? $input['requirement']
                : array()
        );

        $verification = $this->verifyCapability(
            $capability,
            $evidence
        );

        return new EngineResult(
            true,
            array(
                'calculation' => $calculation,
                'match' => $match,
                'verification' => $verification
            ),
            'capability_calculated'
        );
    }

    protected function calculateCapability(
        $capability,
        $state,
        $condition,
        $range
    ) {
        $typeValid = !empty($capability['type']);
        $stateValid = !empty($state['available']);
        $conditionValid = !empty($condition['valid']);
        $rangeValid = !empty($range['valid']);

        return array(
            'type' => $typeValid,
            'state' => $stateValid,
            'condition' => $conditionValid,
            'range' => $rangeValid,
            'available' => (
                $typeValid &&
                $stateValid &&
                $conditionValid &&
                $rangeValid
            )
        );
    }

    protected function matchCapability(
        $capability,
        $requirement
    ) {
        if (empty($capability) || empty($requirement)) {
            return array(
                'state' => 'unknown'
            );
        }

        if (
            isset($capability['type']) &&
            isset($requirement['type']) &&
            $capability['type'] == $requirement['type']
        ) {
            return array(
                'state' => 'matched'
            );
        }

        return array(
            'state' => 'unmatched'
        );
    }

    protected function verifyCapability(
        $capability,
        $evidence
    ) {
        if (empty($evidence)) {
            return array(
                'state' => 'unverified'
            );
        }

        return array(
            'state' => 'verified'
        );
    }
}

这里的示例重点是 Engine 的职责结构：

Capability
    ↓
Calculate
    ↓
Match
    ↓
Verify
    ↓
EngineResult

实际工程中，条件计算、范围计算、验证规则应进一步拆分为独立 Rule/Engine 组件，而不是全部堆积在一个方法中。

193.34 CapabilityEngine 不负责数据库

CapabilityEngine 不应该直接执行：

mysql_query();

也不应该直接：

INSERT capabilities
UPDATE capabilities
DELETE capabilities

其职责是：

Input
→
Calculation
→
Matching
→
Verification
→
EngineResult

保存由：

CapabilityService
    ↓
CapabilityRepository

完成。

193.35 CapabilityService 与 CapabilityEngine

两者的职责可以明确划分。

CapabilityService：

接收请求
→
加载 Individual
→
加载 Capability
→
加载 State
→
加载 Requirement
→
调用 CapabilityEngine
→
处理结果
→
保存验证结果
→
返回

CapabilityEngine：

读取输入
→
计算能力
→
匹配能力
→
验证能力
→
输出结果

因此：

$CapabilityService=OrchestrationCapabilityService=Orchestration$ $CapabilityEngine=ComputationCapabilityEngine=Computation$

193.36 CapabilityRepository

Repository 负责能力持久化。

典型结构：

CapabilityService
    ↓
CapabilityRepository
    ↓
MySQL

Repository 可以负责：

find()
findByIndividual()
findByType()
save()
update()
saveVerification()
saveHistory()

但不能把复杂能力计算全部放进 Repository。

否则：

$Repository≠PersistenceOnlyRepository\neq PersistenceOnly$

就会破坏 Engine 与 Repository 的职责分离。

193.37 数据库结构

Capability 主表：

capabilities

可以包含：

id
individual_id
capability_type
state
verification_state
created_at
updated_at

能力条件：

capability_conditions

包括：

id
capability_id
condition_type
condition_value
state

能力范围：

capability_ranges

包括：

id
capability_id
range_type
min_value
max_value
unit
scope

能力验证：

capability_verifications

包括：

id
capability_id
execution_id
result_id
evidence
verification_state
verified_range
verified_at

能力历史：

capability_history

包括：

id
capability_id
old_state
new_state
change_type
reason
evidence_id
created_at

193.38 能力计算记录

为了实现可审计性，可以增加：

capability_calculations

保存：

id
capability_id
input_context
condition_result
range_result
state_result
calculation_result
created_at

这样可以追踪：

为什么系统认为这个能力当前可用？

答案可以沿着：

Capability
↓
State
↓
Condition
↓
Range
↓
Rule
↓
Evidence
↓
Calculation

逐层追溯。

193.39 能力变化

CapabilityEngine 还应该计算能力变化。

可以定义：

$ΔC=Compare(Ct,Ct+1)\Delta C= Compare(C_t,C_{t+1})$

变化类型包括：

Created
Activated
Deactivated
Blocked
Unblocked
Expanded
Reduced
Verified
VerificationFailed
Expired
Invalidated
Recovered
NoChange

例如：

Capacity:
1000/day

变成：

Capacity:
1500/day

则：

Range Expanded

如果：

Verification:
Verified → Failed

则：

VerificationFailed

193.40 能力变化与能力更新

必须区分：

Capability Change

和：

Capability Update

Capability Change 表示：

计算发现能力发生了变化。

Capability Update 表示：

经过验证之后，系统实际保存了能力的新状态。

因此：

$CalculatedChange≠PersistedUpdateCalculatedChange \neq PersistedUpdate$

正确流程：

Capability
    ↓
Calculate
    ↓
Change Candidate
    ↓
Validate
    ↓
Verify
    ↓
Capability Update

193.41 能力验证的闭环

完整能力验证链为：

Capability
    ↓
Capability Requirement
    ↓
Capability Matching
    ↓
Method
    ↓
Decision
    ↓
Behavior
    ↓
Action
    ↓
Execution
    ↓
Result
    ↓
Feedback
    ↓
Capability Verification

验证结果之后：

Verification
    ↓
Capability State Update
    ↓
Capability History
    ↓
Memory
    ↓
Experience
    ↓
Learning

最终：

Learning
    ↓
Capability Update

形成闭环。

193.42 能力验证不是一次性永久结论

能力具有时间属性。

可以定义：

$Vt≠Vt+1V_t\neq V_{t+1}$

因为：

Individual changed
Object changed
Resource changed
Environment changed
Condition changed
Range changed
Time changed

都可能使原能力失效。

因此：

过去验证通过

不能直接推出：

现在永久有效

CapabilityEngine 必须结合当前状态重新计算。

193.43 能力与场景

第190章 SceneEngine 已经建立当前场景。

CapabilityEngine 可以根据当前场景计算能力适用性：

$Scene+Capability+Condition→CapabilityStateScene + Capability + Condition \rightarrow CapabilityState$

例如：

Scene:
Machine Active
Temperature Normal
Operator Present
Resource Available

则：

Capability:
Operate Machine

可以计算为：

Available

如果场景变化：

Machine = Offline

则：

Capability:
Operate Machine

变成：

Blocked

因此：

$SceneChange→CapabilityRecalculationSceneChange \rightarrow CapabilityRecalculation$

193.44 能力与知识

KnowledgeEngine 输出的知识可以作为 CapabilityEngine 的计算依据。

例如：

Knowledge:
Operation A requires Skill B

CapabilityEngine 检查：

Individual A
has Skill B

然后继续判断：

Skill B
State = Verified

最终：

Capability A = Available

所以：

$Knowledge→CapabilityCalculationKnowledge \rightarrow CapabilityCalculation$

但知识不能直接替代能力。

193.45 能力与风险

能力不足可能成为 Risk。

例如：

Required Capability:
Testing

Current Capability:
Unavailable

则：

Risk:
Testing cannot be completed

CapabilityEngine 提供：

Capability State
Capability Match
Capability Range
Verification State

RiskEngine 再计算：

$RiskScore=Probability×ImpactRiskScore= Probability\times Impact$

因此：

$CapabilityEngine→RiskEngineCapabilityEngine \rightarrow RiskEngine$

193.46 能力与冲突

如果 Goal 要求：

Capability A

而当前 Individual：

Capability A = Blocked

则可能产生：

Capability Conflict

CapabilityEngine 提供事实：

Required = Available
Current = Blocked

ConflictEngine 再判断：

Goal vs Capability Conflict

因此：

$CapabilityConflict≠CapabilityEngineCapabilityConflict \neq CapabilityEngine$

CapabilityEngine 负责计算事实。

ConflictEngine 负责冲突判断。

193.47 能力与决策

DecisionEngine 可以使用多个 CapabilityEngine 结果。

例如：

Candidate A
Capability Match = Full

Candidate B
Capability Match = Partial

Candidate C
Capability Match = Blocked

DecisionEngine 可以依据确定性规则：

$Score(Ci)=∑WjVijScore(C_i)= \sum W_jV_{ij}$

进行候选选择。

因此：

CapabilityEngine
    ↓
Capability Evidence
    ↓
DecisionEngine
    ↓
Selected Candidate

CapabilityEngine 不直接进行最终方案选择。

193.48 能力计算中的“未知”

ICAI 必须允许：

Unknown

不能把：

没有证据

直接解释成：

没有能力

例如：

Capability:
Operate Device

但系统没有验证记录。

正确：

Verification = Unknown / Unverified

而不是：

Capability = Invalid

同样：

Current State Unknown

也不能直接：

Capability = Unavailable

因此：

$Unknown≠FalseUnknown\neq False$

这是 CapabilityEngine 的重要逻辑原则。

193.49 能力计算中的“不可用”

Unavailable 必须有原因。

例如：

State Blocked

或者：

Condition Failed

或者：

Range Exceeded

或者：

Verification Failed

因此：

$Unavailable=Reason+EvidenceUnavailable= Reason + Evidence$

而不是简单：

available = 0

193.50 CapabilityEngine 的完整架构

CapabilityEngine 在 ICAI 中的位置可以表示为：

Individual
    ↓
Object
    ↓
State
    ↓
Scene
    ↓
Knowledge
    ↓
CapabilityEngine
    ├── Capability Calculation
    ├── Capability Matching
    └── Capability Verification
    ↓
MethodEngine
    ↓
DecisionEngine
    ↓
BehaviorEngine

其中：

Knowledge

提供认知事实；

Scene

提供当前环境；

State

提供当前状态；

Capability

提供可执行能力；

Method

提供实现路径；

Decision

选择当前方案。

193.51 CapabilityEngine 的完整工作流程

可以统一表示为：

Load Individual
    ↓
Load Object
    ↓
Load Current State
    ↓
Load Scene
    ↓
Load Knowledge
    ↓
Load Capability
    ↓
Load Requirement
    ↓
Calculate Conditions
    ↓
Calculate Range
    ↓
Calculate Current Capability
    ↓
Match Requirement
    ↓
Load Verification Evidence
    ↓
Verify Capability
    ↓
Calculate Capability Change
    ↓
Return EngineResult

如果验证失败：

Verification Failed
    ↓
DiagnosisEngine

如果能力阻塞：

Blocked
    ↓
RiskEngine / ConflictEngine

如果能力满足：

Matched
    ↓
MethodEngine

193.52 CapabilityResult

最终可以定义：

$CR=(I,O,C,Co,S,R,M,V,E,D,T)CR= (I,O,C,Co,S,R,M,V,E,D,T)$

其中：

$II$ = Individual；
$OO$ = Object；
$CC$ = Capability；
$CoCo$ = Condition；
$SS$ = Current State；
$RR$ = Range；
$MM$ = Match；
$VV$ = Verification；
$EE$ = Evidence；
$DD$ = Difference；
$TT$ = Time。

例如：

array(
    'capability_id' => 101,

    'calculation' => array(
        'available' => true,
        'condition' => true,
        'range' => true,
        'state' => true
    ),

    'match' => array(
        'state' => 'matched'
    ),

    'verification' => array(
        'state' => 'verified'
    ),

    'change' => array(
        'type' => 'no_change'
    )
);

这个结果可以作为 MethodEngine 的输入。

193.53 CapabilityEngine 的确定性闭环

CapabilityEngine 的核心循环可以表示为：

$Ct→Calculate→Match→Verify→Compare→Ct+1C_t \rightarrow Calculate \rightarrow Match \rightarrow Verify \rightarrow Compare \rightarrow C_{t+1}$

其中：

$CtC_t$ = 当前能力；
Calculate = 能力计算；
Match = 能力匹配；
Verify = 能力验证；
Compare = 能力比较；
$Ct+1C_{t+1}$ = 新能力状态。

如果：

$ΔC=0\Delta C=0$

则：

No Change

如果：

$ΔC≠0\Delta C\neq0$

则产生：

Capability Change Candidate

然后交由 Service 层处理实际更新。

193.54 CapabilityEngine 在 ICAI Engine 体系中的意义

经过前面的 Engine：

$ObjectEngine→StateEngine→RelationEngine→SceneEngine→KnowledgeEngineObjectEngine \rightarrow StateEngine \rightarrow RelationEngine \rightarrow SceneEngine \rightarrow KnowledgeEngine$

系统已经具备：

对象事实
状态事实
关系事实
场景事实
知识事实

CapabilityEngine 在此基础上进一步回答：

在当前对象、当前状态、当前场景和当前知识条件下，当前个体或系统到底具备什么能力？

因此形成：

$Knowledge+Scene+State+Condition+Range→CapabilityKnowledge + Scene + State + Condition + Range \rightarrow Capability$

这使 Capability 不再是静态配置，而成为一个可以持续计算和验证的动态认知对象。

193.55 本章小结

CapabilityEngine 是 ICAI Engine 层中负责能力计算的核心组件。

其基本能力模型：

$Capability=(Type,Condition,State,Range,Verification)\boxed{ Capability=(Type,Condition,State,Range,Verification) }$

其三个核心职责：

$CapabilityCalculation+CapabilityMatching+CapabilityVerification\boxed{ CapabilityCalculation+ CapabilityMatching+ CapabilityVerification }$

能力计算解决：

当前能力是否具备成立条件？

能力匹配解决：

当前能力是否满足当前 Goal、Method 或任务的能力要求？

能力验证解决：

这个能力是否已经被实际执行结果和证据证明？

三者不能混为一谈：

$CapabilityExists≠CapabilityAvailableCapabilityExists \neq CapabilityAvailable$ $CapabilityAvailable≠CapabilityMatchedCapabilityAvailable \neq CapabilityMatched$ $CapabilityMatched≠CapabilityVerifiedCapabilityMatched \neq CapabilityVerified$

因此，一个完整的能力判断必须经历：

Capability
    ↓
Condition
    ↓
State
    ↓
Range
    ↓
Calculation
    ↓
Matching
    ↓
Actual Execution
    ↓
Result
    ↓
Evidence
    ↓
Verification

最终形成：

$Capabilityt→Calculate→Match→Verify→Compare→Capabilityt+1\boxed{ Capability_t \rightarrow Calculate \rightarrow Match \rightarrow Verify \rightarrow Compare \rightarrow Capability_{t+1} }$

CapabilityEngine 不执行任务，不负责方法选择，不负责行为执行，也不负责数据库持久化。

其工程职责严格限定为：

$Engine=Capability Calculation+Matching+Verification\boxed{ Engine=Capability\ Calculation+Matching+Verification }$

最终在 ICAI 总体结构中形成：

$Object→State→Relation→Scene→Knowledge→Capability→Method→Decision→Behavior→Action→Execution\boxed{ Object \rightarrow State \rightarrow Relation \rightarrow Scene \rightarrow Knowledge \rightarrow Capability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution }$

由此，ICAI 从“知道当前环境是什么”，进一步进入“知道当前能够做什么”的阶段。

整个过程仍然建立在对象、状态、关系、场景、知识、条件、范围、规则、证据和实际执行结果之上，不需要 LLM、Transformer、Embedding、Vector Search、Prompt Engineering、神经网络或其他生成式大模型机制。

第193章 CapabilityEngine

第193章 CapabilityEngine

193.1 Capability 的基本定义

193.2 CapabilityEngine 的定义

193.3 能力计算

193.4 能力计算不是能力执行

193.5 能力计算的基本输入

193.6 能力计算的条件

193.7 能力计算结果

193.8 能力状态

193.9 能力范围计算

193.10 能力范围不只是数量

193.11 能力匹配

193.12 能力要求

193.13 能力匹配维度

193.14 能力匹配不是能力计算

193.15 能力匹配的结果模型

193.16 多能力组合

193.17 能力依赖

193.18 能力验证

193.19 能力验证模型

193.20 能力验证不是能力声明

193.21 能力验证的证据

193.22 能力验证状态

193.23 验证与当前状态

193.24 能力验证范围

193.25 能力验证更新

193.26 能力失败

193.27 CapabilityEngine 与 DiagnosisEngine

193.28 CapabilityEngine 与 KnowledgeEngine

193.29 CapabilityEngine 与 StateEngine

193.30 CapabilityEngine 与 MethodEngine

193.31 CapabilityEngine 与 DecisionEngine

193.32 能力计算的确定性原则

193.33 PHP OOP 工程实现

193.34 CapabilityEngine 不负责数据库

193.35 CapabilityService 与 CapabilityEngine

193.36 CapabilityRepository

193.37 数据库结构

193.38 能力计算记录

193.39 能力变化

193.40 能力变化与能力更新

193.41 能力验证的闭环

193.42 能力验证不是一次性永久结论

193.43 能力与场景

193.44 能力与知识

193.45 能力与风险

193.46 能力与冲突

193.47 能力与决策

193.48 能力计算中的“未知”

193.49 能力计算中的“不可用”

193.50 CapabilityEngine 的完整架构

193.51 CapabilityEngine 的完整工作流程

193.52 CapabilityResult

193.53 CapabilityEngine 的确定性闭环

193.54 CapabilityEngine 在 ICAI Engine 体系中的意义

193.55 本章小结