第183章　DiagnosisRepairService

在 ICAI（Individual Cognitive AI，个体认知人工智能）系统中，风险与冲突处理解决的是“问题可能发生”以及“结构之间存在矛盾”的问题。

但是，当异常已经实际发生之后，系统还必须继续回答四个问题：

发生了什么？

为什么发生？

应该如何恢复？

恢复是否真的成功？

因此，在 RiskConflictService 之后，需要建立 DiagnosisRepairService。

第165章已经定义了：

Failure ≠ Risk

Diagnosis ≠ Result

Repair ≠ Protection

Repair Execution ≠ Repair Success

而第180章建立了：

Execution → Result → Feedback

第182章建立了：

Risk / Conflict → Protection / Processing → Verification

第183章则进一步建立：

Abnormality → Diagnosis → Repair → Verification

即：

异常 → 诊断 → 修复 → 验证

DiagnosisRepairService 的核心职责，就是把已经发生的异常从“事实记录”转化为“原因判断”，再从“原因判断”转化为“修复行为”，最后通过实际执行结果确认系统是否恢复。

一、DiagnosisRepairService定义

DiagnosisRepairService 是 ICAI Service 层中负责接收异常事实、组织诊断、确定修复方案、协调修复执行以及验证修复结果的应用服务。

它不是 Diagnosis 对象，也不是 Repair 对象。

其中：

Diagnosis = 诊断对象

负责描述问题及其原因判断。

Repair = 修复对象

负责描述恢复正常状态的方法和动作。

DiagnosisRepairService = 诊断与修复流程协调服务

因此可以定义：

DRS = (A,D,R,V)

其中：

A（Abnormality）：异常
D（Diagnosis）：诊断
R（Repair）：修复
V（Verification）：验证

完整流程：

Detect → Diagnose → Select Repair → Execute Repair → Verify → Recover / Re-diagnose

即：

发现异常 → 诊断 → 选择修复 → 执行修复 → 验证 → 恢复 / 重新诊断

二、异常

2.1 Abnormality定义

异常是系统当前实际状态、执行结果、行为结果或环境状态与预期条件、正常规则或允许范围发生偏离的事实。

异常可以来自：

Execution
Result
Feedback
State
Behavior
Method
Capability
Object
Relation
Environment
Resource

异常的核心是：

Actual ≠ Expected

或者：

Actual State 不满足 Normal Condition

例如：

Expected:
ObjectFound

Actual:
ObjectNotFound

则形成异常。

又例如：

Expected State:
Running

Actual State:
Failed

同样属于异常。

三、异常与Failure的关系

异常与 Failure 有关联，但不能完全等同。

Abnormality 是更大的概念。

例如：

Temperature = 55°C
Expected Range = 0~50°C

这是异常。

但是否构成 Failure，需要根据系统规则判断。

因此：

Abnormality → Evaluation → Failure / Warning / Deviation

例如：

Abnormality
↓
Evaluate
↓
Warning

或者：

Abnormality
↓
Evaluate
↓
Failure

所以 DiagnosisRepairService 不应该把所有异常都直接标记为 Failure。

四、异常结构

可以定义：

A = (O,E,X,C,S,T)

其中：

O（Object）：异常所属对象
E（Expected）：预期状态或结果
X（Actual）：实际状态或结果
C（Condition）：异常条件
S（State）：异常状态
T（Time）：异常发生时间

例如：

Object = Robot R1
Expected = Position A
Actual = Position C
Condition = MoveTo A
State = Failed
Time = T1

这构成一个完整异常事实。

五、异常接收

DiagnosisRepairService 首先接收来自执行和反馈系统的异常。

典型来源：

Execution → Result → Feedback → Abnormality

例如：

Action
↓
Execution
↓
Result = Failed
↓
Feedback
↓
Abnormality

也可能来自：

StateService
↓
Invalid State
↓
DiagnosisRepairService

或者：

RiskConflictService
↓
Unresolved Conflict
↓
DiagnosisRepairService

因此异常不是 DiagnosisRepairService 自己假定出来的。

必须有事实来源。

六、异常确认

接收到异常之后，首先需要确认异常是否真实存在。

可以定义：

ValidAbnormality = Evidence ∧ Actual ∧ Expected ∧ Comparison

其中：

Evidence：存在证据
Actual：存在实际状态或结果
Expected：存在可比较的预期
Comparison：已经完成比较

例如：

Expected = A
Actual = B

则：

Comparison = Different

可以确认异常。

如果只有：

Expected = A

但没有实际结果，则不能直接形成实际异常。

因此：

Expected ≠ Actual

并且：

Expected alone ≠ Failure

七、诊断

7.1 Diagnosis定义

Diagnosis 是根据异常事实、执行结果、反馈、状态、历史、记忆、经验、知识、风险和冲突信息，对异常原因进行识别、定位和判断的认知过程与对象。

第165章定义：

D = (P,E,C,R,S)

其中：

P（Problem）：问题
E（Evidence）：证据
C（Cause）：原因
R（Recommendation）：处理建议
S（State）：诊断状态

Diagnosis 回答：

“为什么出现这个异常？”

而 Result 回答：

“发生了什么？”

因此：

Result = What happened

Diagnosis = Why happened

八、诊断证据

诊断不能只依据一个错误代码。

它需要综合多类证据：

Result
Feedback
State
History
Memory
Experience
Knowledge
Risk
Conflict

形成：

Diagnosis Evidence = Result + Feedback + State + History + Memory + Experience + Knowledge + Risk + Conflict

例如：

Result:
Move Failed

Feedback:
Position unchanged

State:
Running → Failed

History:
Previously successful

Experience:
Obstacle causes similar failure

Environment:
Obstacle detected

最终可以形成：

Cause = ObstacleBlockedPath

这才是结构化诊断。

九、诊断层级

Diagnosis 不应该只有一个简单的 Error Code。

可以按层级进行诊断：

Result Level

结果是否异常。

↓

State Level

当前状态是否异常。

↓

Action Level

具体操作是否出现问题。

↓

Behavior Level

行为组织是否出现问题。

↓

Method Level

采用的方法是否不适合当前条件。

↓

Capability Level

当前能力是否不足。

↓

Environment Level

外部环境是否发生变化。

例如：

Move Failed
↓
Action正常？
↓
Action正常
↓
Method是否适用？
↓
Method正常
↓
Capability是否足够？
↓
Capability正常
↓
Environment发生变化
↓
Obstacle

最终找到：

Environment Cause

这比直接把问题归因于 Action 更准确。

十、诊断状态

Diagnosis 本身也应该具有状态。

例如：

Unknown
↓
Detected
↓
Analyzing
↓
CauseFound
↓
Confirmed
↓
Resolved

如果无法确定原因：

Analyzing
↓
UnknownCause

如果多个原因都可能：

Analyzing
↓
MultipleCandidates

因此系统不应该为了强行给出答案而制造虚假原因。

Unknown Cause 是合法诊断结果。

十一、诊断与Experience

第181章形成的 Experience 可以辅助 Diagnosis。

例如过去：

Condition X
Method A
Failure
Environment Y

形成经验：

Experience E1:
Environment Y + Method A
容易产生 Failure

当前再次出现：

Condition X
Method A
Failure
Environment Y

DiagnosisService 可以将 E1 作为诊断证据。

于是：

Current Evidence + Previous Experience → Diagnosis

但是经验只能作为证据来源之一。

不能因为过去发生过一次，就直接确定当前原因。

必须仍然进行当前事实验证。

十二、修复

12.1 Repair定义

Repair 是根据 Diagnosis 确定的异常原因，通过执行修复方法和修复动作，使系统从异常状态恢复到可运行或目标允许状态的过程。

第165章定义：

Rp = (D,M,A,R,S)

其中：

D（Diagnosis）：诊断
M（Method）：修复方法
A（Action）：修复动作
R（Result）：修复结果
S（State）：修复状态

Repair 回答：

“找到原因之后，如何恢复？”

十三、Repair与Protection的区别

Protection 和 Repair 必须严格区分。

Protection：

问题还没有发生，或者问题正在扩大，需要阻止。

Repair：

问题已经发生，需要恢复。

因此：

Risk → Protection

而：

Failure → Diagnosis → Repair

例如：

Battery Low
↓
Risk
↓
Protection
↓
Stop Movement

这是保护。

如果已经：

Movement Failed
Battery Empty

则：

Diagnosis
↓
Battery Failure
↓
Repair
↓
Recharge / Replace

这是修复。

十四、修复方法

Repair 不一定只有一种方法。

可以定义修复方法候选：

Retry
Adjustment
MethodChange
ActionReplacement
StateRecovery
ResourceReplacement
ObjectReplacement
EnvironmentRecovery

例如：

Retry

重新执行原 Action。

Failure
↓
Retry

Adjustment

修改参数后重新执行。

Failure
↓
Adjust Parameter
↓
Retry

MethodChange

原 Method 不适用，选择其他 Method。

Method A Failed
↓
Diagnosis
↓
Method B

ActionReplacement

替换具体 Action。

StateRecovery

恢复对象状态。

例如：

Running
↓
Failed
↓
Recover
↓
Ready

ResourceReplacement

当前资源不可用，切换其他资源。

十五、修复执行

Repair 对象描述的是修复方案和修复动作。

真正的修复仍然需要经过 Execution。

因此：

Repair ≠ Execution

完整流程：

Diagnosis → Repair Method → Repair Action → Execution → Result

例如：

Diagnosis:
ObjectNotFound

Repair Method:
SearchAgain

Repair Action:
ScanArea

Execution:
ScanArea

Result:
ObjectFound

RepairService 不能直接认为：

ObjectFound

必须等待实际 Execution 返回 Result。

十六、修复结果

修复结果必须来自实际执行。

可以定义：

RepairResult = ActualExecutionResult

而不能定义：

RepairResult = ExpectedRepairResult

例如：

Expected:
State = Ready

并不意味着：

Actual:
State = Ready

只有实际执行完成后：

Result:
State = Ready

才能形成成功修复。

因此：

Repair Execution ≠ Repair Success

十七、验证

17.1 Verification定义

Verification 是通过实际事实、状态、结果和规则确认诊断或修复是否达到预期条件的过程。

在本章中，Verification 是修复闭环的最终环节。

基本结构：

Repair → Execution → Result → Verification

例如：

Diagnosis
↓
Repair
↓
Execution
↓
Result
↓
Verification

如果验证成功：

Verified
↓
Recovered

如果验证失败：

Not Verified
↓
Re-diagnosis

十八、验证条件

修复验证可以定义：

V = Result ∧ State ∧ Condition ∧ Evidence

其中：

Result：实际结果
State：当前状态
Condition：恢复条件
Evidence：验证证据

例如：

Repair:
Recover Robot

Expected State:
Ready

Actual State:
Ready

Result:
Success

如果状态、结果和条件全部满足：

Verification = Passed

否则：

Verification = Failed

十九、修复失败

修复失败不是系统错误，而是合法认知结果。

例如：

Failure
↓
Diagnosis
↓
Repair A
↓
Execution
↓
Result = Failed
↓
Verification = Failed

此时不能无限重复 Repair A。

应该：

Verification Failed → Diagnosis Update → New Repair Candidate

即：

Repair A
↓
Failed
↓
Re-diagnosis
↓
Repair B

如果所有候选修复都失败：

No Valid Repair

系统可以进入：

Blocked
Unrecoverable
ManualRequired

等状态。

二十、Diagnosis与Repair的关系

Diagnosis 和 Repair 不是一对一固定关系。

一个 Diagnosis 可以对应多个 Repair Candidate：

Diagnosis D1
↓
Repair A
Repair B
Repair C

例如：

Cause = ResourceUnavailable

可以有：

Repair A = Wait
Repair B = ReplaceResource
Repair C = ChangeMethod

此时可以交给 DecisionService 选择。

因此：

Diagnosis → Repair Candidates → Decision → Selected Repair

这与普通 Method 选择逻辑是一致的。

二十一、DiagnosisRepairService与DecisionService

DiagnosisRepairService 不应该自己承担所有修复方案选择。

例如：

Diagnosis:
Resource X unavailable

Candidates:
Repair A = Wait
Repair B = Resource Y
Repair C = Method Change

此时：

DecisionService

可以根据：

Goal Priority
Resource State
Risk
Capability
Experience
Repair Cost
Expected Result

进行选择。

形成：

Diagnosis → Repair Candidates → Decision → Selected Repair

然后：

Selected Repair → Behavior / Action → Execution

因此 DiagnosisRepairService 负责提供诊断和修复候选，DecisionService 负责在多个可行修复方案之间进行选择。

二十二、DiagnosisRepairService与StateService

诊断和修复通常伴随状态变化。

例如：

Running
↓
Failed

进入：

Diagnosis

修复：

Repair
↓
Recovery

最终：

Ready

但这些状态变化必须经过 StateService。

因此：

DiagnosisRepairService → StateService → StateEngine

例如：

$this->stateService->transition(
    $object,
    'failed',
    'execution_failure'
);

修复完成后：

$this->stateService->transition(
    $object,
    'ready',
    'repair_verified'
);

具体转换是否合法，由 StateEngine 决定。

二十三、异常闭环

DiagnosisRepairService 的核心闭环：

Abnormality → Diagnosis → Repair → Execution → Result → Verification

如果成功：

Abnormality
↓
Diagnosis
↓
Repair
↓
Execution
↓
Result
↓
Verification Passed
↓
Recovered State

如果失败：

Abnormality
↓
Diagnosis
↓
Repair
↓
Execution
↓
Result
↓
Verification Failed
↓
Re-diagnosis

如果无法恢复：

Re-diagnosis
↓
No Valid Repair
↓
Blocked / Unrecoverable

这构成真正的故障恢复闭环。

二十四、异常、风险、冲突三者关系

经过第182章和本章，可以进一步区分：

Risk

表示：

问题可能发生。

Conflict

表示：

当前结构存在不能同时满足的关系。

Abnormality

表示：

实际状态已经偏离正常条件。

因此：

Risk
→ Protection

Conflict
→ Resolution

Abnormality / Failure
→ Diagnosis
→ Repair

三者不能统一成一个 Error 对象。

它们具有不同的认知意义。

二十五、诊断历史

每次诊断都应该形成历史。

例如：

diagnosis_history

可以保存：

id
diagnosis_id
problem
evidence
candidate_cause
selected_cause
reason
state
created_at

这样系统未来可以回答：

过去遇到过什么问题？

当时判断的原因是什么？

采取了什么修复？

最后是否成功？

这可以进一步进入：

History → Memory → Experience

二十六、修复历史

Repair 也应该保存实际历史：

repair_history

包括：

id
repair_id
diagnosis_id
method
action
execution_id
result_id
verification_id
state
created_at

因此未来可以形成：

Diagnosis
↓
Repair History
↓
Memory
↓
Experience

例如：

同类异常
→
Repair A
→
连续成功

最终形成经验：

Condition X
+
Diagnosis Y
→
Repair A
具有较高成功经验

这可以反过来影响下一次修复选择。

二十七、PHP工程结构

DiagnosisRepairService 可以定义：

class DiagnosisRepairService
{
    protected $abnormalityRepository;
    protected $diagnosisRepository;
    protected $repairRepository;
    protected $verificationService;
    protected $stateService;

    public function __construct(
        $abnormalityRepository,
        $diagnosisRepository,
        $repairRepository,
        $verificationService,
        $stateService
    ) {
        $this->abnormalityRepository = $abnormalityRepository;
        $this->diagnosisRepository = $diagnosisRepository;
        $this->repairRepository = $repairRepository;
        $this->verificationService = $verificationService;
        $this->stateService = $stateService;
    }

    public function receiveAbnormality($data)
    {
        // 接收异常
    }

    public function diagnose($abnormality)
    {
        // 组织诊断
    }

    public function createRepair($diagnosis)
    {
        // 建立修复方案
    }

    public function executeRepair($repair)
    {
        // 协调实际修复执行
    }

    public function verifyRepair($repair, $result)
    {
        // 验证修复结果
    }
}

这里需要特别注意：

executeRepair() 不应该自己重新实现完整的 ExecutionEngine。

它应该协调：

Repair → Action → ExecutionService → Execution → Result

因此：

DiagnosisRepairService = 流程协调

而不是：

DiagnosisRepairService = 所有功能集中类

二十八、工程层分工

可以进一步形成：

DiagnosisRepairService
        ↓
AbnormalityEngine
        ↓
DiagnosisEngine
        ↓
RepairEngine
        ↓
VerificationService
        ↓
StateService

各层职责：

AbnormalityEngine

判断实际状态是否异常。

DiagnosisEngine

根据证据和规则寻找原因。

RepairEngine

生成或匹配修复方案。

VerificationService

验证修复结果。

StateService

管理状态转换。

DiagnosisRepairService

协调整个流程。

二十九、数据库结构

29.1 abnormalities

id
object_id
source_type
source_id
expected_value
actual_value
condition
state
severity
created_at

29.2 diagnoses

id
abnormality_id
problem
evidence
cause
recommendation
state
created_at
updated_at

29.3 diagnosis_evidence

id
diagnosis_id
source_type
source_id
evidence_type
value
weight
created_at

用于保存诊断证据来源。

29.4 repairs

id
diagnosis_id
method
action
expected_result
state
created_at
updated_at

29.5 repair_results

id
repair_id
execution_id
expected_result
actual_result
comparison
state
created_at

29.6 repair_verifications

id
repair_id
result_id
condition
verification_result
state
reason
created_at

这样可以保持：

Diagnosis → Repair → Result → Verification

完整可追溯。

三十、验证后的状态恢复

验证通过后，系统才能进入恢复状态。

例如：

Failed
↓
Diagnosis
↓
Repair
↓
Execution
↓
Result
↓
Verification Passed
↓
Ready

如果验证失败：

Failed
↓
Diagnosis
↓
Repair
↓
Execution
↓
Result
↓
Verification Failed
↓
Failed / Diagnosing

状态转换仍然必须经过 StateEngine。

因此：

Verification Passed ≠ 自动修改所有对象状态

而是：

Verification Passed → State Transition Request → StateEngine → New State

三十一、完整ICAI异常恢复链

结合前面所有 Service，可以建立：

ExecutionService

↓

ResultService

↓

FeedbackService

↓

RiskConflictService

↓

DiagnosisRepairService

↓

VerificationService

↓

StateService

↓

MemoryExperienceService

↓

DecisionService

完整异常路径：

Execution
↓
Result
↓
Feedback
↓
Abnormality
↓
Risk / Conflict Analysis
↓
Diagnosis
↓
Repair Candidate
↓
Decision
↓
Selected Repair
↓
Action
↓
Execution
↓
Result
↓
Feedback
↓
Verification
↓
State Recovery
↓
History
↓
Memory
↓
Experience

这已经形成一个完整的异常认知闭环。

三十二、修复经验反馈

修复成功之后，并不意味着认知循环结束。

例如：

Diagnosis:
ObjectNotFound

Repair:
SearchAgain

Result:
ObjectFound

Verification:
Passed

这组事实可以进入：

History

然后形成：

Memory

进一步形成：

Experience

最终：

Experience:
ObjectNotFound
→ SearchAgain
→ Success

未来再次出现相同异常时，系统可以直接获得修复候选。

因此：

Diagnosis → Repair → Verification → Experience

是 ICAI 中非常重要的一条学习路径。

三十三、修复经验与未来决策

假设过去有：

Diagnosis D1
Repair A
Success = 8
Failure = 1

而：

Repair B
Success = 3
Failure = 5

Learning Data 可以形成：

D1 + Repair A
SuccessRate = 8 / 9

D1 + Repair B
SuccessRate = 3 / 8

未来再次出现 D1：

Diagnosis D1
↓
Repair A / Repair B
↓
DecisionService
↓
Repair A

这里仍然属于离散统计与规则计算。

不需要任何大模型训练。

三十四、本章核心模型

DiagnosisRepairService 最终可以定义为：

DRS = Abnormality + Diagnosis + Repair + Verification

进一步：

DRS = Detect + Diagnose + Repair + Verify

完整流程：

Actual Result → Abnormality → Diagnosis → Repair Candidate → Decision → Repair Execution → Result → Verification → State Recovery

如果验证失败：

Verification Failed → Re-diagnosis → New Repair

如果无法恢复：

No Valid Repair → Blocked / Unrecoverable

三十五、本章总结

DiagnosisRepairService 完成的是 ICAI 从“发现异常”到“恢复正常”的工程闭环。

它首先接收实际执行产生的异常事实。

然后通过 Result、Feedback、State、History、Memory、Experience、Knowledge、Risk 和 Conflict 等信息进行诊断。

诊断回答：

“为什么发生？”

修复回答：

“如何恢复？”

验证回答：

“是否真的恢复？”

因此：

Abnormality = 实际偏离

Diagnosis = 原因判断

Repair = 恢复行为

Verification = 实际确认

完整过程：

异常 → 诊断 → 修复 → 执行 → 结果 → 验证 → 状态恢复

如果成功：

Abnormality → Diagnosis → Repair → Verification → Recovered

如果失败：

Abnormality → Diagnosis → Repair → Verification Failed → Re-diagnosis

如果无法恢复：

Diagnosis → No Valid Repair → Blocked / Unrecoverable

最终再进入：

History → Memory → Experience → Learning Data

从而影响未来的：

Risk Evaluation → Diagnosis → Repair Selection → Decision

至此，ICAI 已经形成从正常执行、反馈、风险控制，到异常诊断、修复和验证的连续工程闭环：

Need → Goal → Capability → Method → Decision → Behavior → Action → Execution → Result → Feedback → Risk / Conflict → Diagnosis → Repair → Verification → State → History → Memory → Experience → Learning Data → Decision

整个过程仍然建立在：

事实 + 对象 + 状态 + 关系 + 规则 + 历史 + 经验 + 离散计算

之上。

这里的“诊断”不是生成式模型猜测原因，“修复”也不是自动编造方案，而是根据已有事实、状态、关系、规则、历史和经验形成可追溯的候选处理路径，并通过实际 Execution 和 Verification 确认结果。

因此，DiagnosisRepairService 在 WSaiOS-ICAI 中的核心定位可以最终概括为：

让系统不仅能够发现“出了问题”，还能够说明“为什么出问题、准备怎样处理、实际处理后发生了什么，以及系统是否真正恢复”。

第183章 DiagnosisRepairService

第183章 DiagnosisRepairService

一、DiagnosisRepairService定义

二、异常

2.1 Abnormality定义

三、异常与Failure的关系

四、异常结构

五、异常接收

六、异常确认

七、诊断

7.1 Diagnosis定义

八、诊断证据

九、诊断层级

十、诊断状态

十一、诊断与Experience

十二、修复

12.1 Repair定义

十三、Repair与Protection的区别

十四、修复方法

Retry

Adjustment

MethodChange

ActionReplacement

StateRecovery

ResourceReplacement

十五、修复执行

十六、修复结果

十七、验证

17.1 Verification定义

十八、验证条件

十九、修复失败

二十、Diagnosis与Repair的关系

二十一、DiagnosisRepairService与DecisionService

二十二、DiagnosisRepairService与StateService

二十三、异常闭环

二十四、异常、风险、冲突三者关系

二十五、诊断历史

二十六、修复历史

二十七、PHP工程结构

二十八、工程层分工

AbnormalityEngine

DiagnosisEngine

RepairEngine

VerificationService

StateService

DiagnosisRepairService

二十九、数据库结构

29.1 abnormalities

29.2 diagnoses

29.3 diagnosis_evidence

29.4 repairs

29.5 repair_results

29.6 repair_verifications

三十、验证后的状态恢复

三十一、完整ICAI异常恢复链

三十二、修复经验反馈

三十三、修复经验与未来决策

三十四、本章核心模型

三十五、本章总结