第二十四篇 Self-Maintenance
第73章 Risk 与 Conflict
第72章建立了 Detection：
Target
↓
Detection
↓
DetectionResultDetection 发现系统、模块、行为、设备或数据存在异常以后，并不意味着系统已经知道应该如何处理。
因此需要进一步进入：
Detection
↓
Risk
↓
Conflict
↓
Decision其中：
- Risk：判断异常可能造成什么影响；
- Conflict：判断不同对象、状态、规则、行为之间是否存在无法同时满足的矛盾；
- Priority：在多个可处理对象之间确定处理顺序；
- Decision：最终选择采取什么行动。
1. Risk
1.1 Risk 定义
**Risk（风险）**是 SAI/ICAI 根据当前状态、条件、历史经验、影响范围和可能结果，对某个对象、行为、决策或事件可能产生的不利影响进行结构化描述和计算的机制。
基本关系：
Detection
↓
异常/不确定状态
↓
Risk Analysis
↓
RiskRisk 关注的是：
如果继续这样运行
可能发生什么？
发生的可能性有多大？
产生的影响有多大？
是否需要优先处理？因此：
Abnormal ≠ Risk
Risk ≠ Failure
Risk ≠ Diagnosis例如：
Motor_A.temperature = 92℃Detection：
ABNORMALRisk：
temperature_overheat
probability = 0.80
impact = 0.90
risk_score = 0.72
level = HIGH这里 Detection 发现问题，Risk 判断问题可能造成的影响。
1.2 Risk 结构
Risk
{
id
target
event
condition
probability
impact
exposure
score
level
priority
state
source
created_at
updated_at
}基本计算：
RiskScore = Probability × Impact如果增加暴露程度：
RiskScore =
Probability × Impact × Exposure所有参数都可以限制在：
0.00 ～ 1.00例如：
Probability = 0.80
Impact = 0.90则：
RiskScore = 0.80 × 0.90
= 0.721.3 Risk Level
例如：
0.00 - 0.24 → LOW
0.25 - 0.49 → MEDIUM
0.50 - 0.74 → HIGH
0.75 - 1.00 → CRITICAL具体边界可以由系统配置。
特别需要保持：
UNKNOWN ≠ LOW如果 Probability 无法确定：
Probability = UNKNOWN不能因为不知道风险大小，就自动认为：
Risk = LOW2. Conflict
2.1 Conflict 定义
**Conflict（冲突）**是 SAI/ICAI 在多个事实、状态、规则、条件、行为、目标或决策之间发现不能同时成立、不能同时执行或相互排斥的关系。
基本模型：
A
+
B
↓
Conflict Detection
↓
Conflict Result例如：
Rule_A：
IF temperature > 80
THEN Motor = STOP同时：
Rule_B：
IF production_required = TRUE
THEN Motor = RUN当前：
temperature = 90
production_required = TRUE两个规则分别要求：
STOP
RUN形成：
RUN ↔ STOP这就是规则冲突。
2.2 Conflict 不等于 Error
冲突并不一定意味着程序错误。
例如：
Rule_A → STOP
Rule_B → RUN两个规则本身都可能正确。
问题在于：
当前条件同时满足两个规则导致：
两个结果不能同时执行因此：
Conflict ≠ ErrorConflict 是一种关系状态。
2.3 Conflict 基本结构
Conflict
{
id
source_a
source_b
target
type
condition_a
condition_b
result_a
result_b
reason
priority
state
created_at
}例如：
Conflict
{
id: "C001",
source_a: "Rule_001",
source_b: "Rule_002",
target: "Motor_A",
type: "RULE_CONFLICT",
result_a: "STOP",
result_b: "RUN",
reason: "Both conditions are satisfied",
state: "DETECTED"
}3. 冲突来源
Conflict 可能来自多个层面。
3.1 信息冲突
例如：
Source_A：
temperature = 30
Source_B：
temperature = 45如果两个信息针对：
同一对象
同一属性
同一时间就可能形成：
Information Conflict3.2 事实冲突
Fact_A：
Device_A.state = ON
Fact_B：
Device_A.state = OFF如果两者同时有效：
Fact Conflict3.3 状态冲突
Expected = READY
Actual = ERROR或者两个来源分别认为：
State_A = RUNNING
State_B = STOPPED形成：
State Conflict3.4 规则冲突
Rule_A → START
Rule_B → STOP条件同时满足：
Rule Conflict3.5 行为冲突
例如两个 Behavior 同时要求：
Behavior_A → Motor_A.start()
Behavior_B → Motor_A.stop()如果两个行为在相同时间、相同对象上不能同时执行：
Behavior Conflict3.6 目标冲突
例如：
Goal_A：
最大化生产速度
Goal_B：
最小化设备风险当前设备温度已经很高时：
高速运行和：
立即停止可能形成目标冲突。
3.7 资源冲突
两个行为需要同一个不可同时占用的资源：
Process_A → Device_A
Process_B → Device_A如果 Device_A 同时只能执行一个任务：
Resource Conflict4. 状态冲突
状态冲突是最常见的 Conflict 类型之一。
4.1 同一对象的状态冲突
例如：
Device_A同时出现：
RUNNING
STOPPED如果时间和上下文相同：
RUNNING ↔ STOPPED形成：
STATE_CONFLICT4.2 状态变化不一定是冲突
例如：
READY
↓
RUNNING这是正常状态变化。
又例如：
RUNNING
↓
STOPPED如果行为要求停止，也是正常变化。
因此必须区分：
State Change和：
State Conflict关键在于：
是否属于同一时间/上下文？
是否允许这种状态变化？
是否存在两个同时有效的状态？4.3 状态冲突结构
StateConflict
{
object
state_a
state_b
time
context
source_a
source_b
state
}例如：
StateConflict
{
object: "Motor_A",
state_a: "RUNNING",
state_b: "STOPPED",
time: "2026-09-12 18:10:00",
source_a: "DeviceResponse",
source_b: "Memory",
state: "CONFLICT"
}这时系统不能直接选择其中一个。
需要进入：
Conflict
↓
Source Check
↓
Time Check
↓
State Validation
↓
Priority / Resolution5. 规则冲突
规则冲突是 RuleEngine 和 ReasoningEngine 中的重要问题。
5.1 直接冲突
Rule_001
IF
temperature > 80
THEN
Motor = STOPRule_002
IF
production = TRUE
THEN
Motor = RUN当前：
temperature = 90
production = TRUE两个条件都为 TRUE：
Rule_001 → STOP
Rule_002 → RUN形成：
STOP ↔ RUN5.2 规则优先级
如果规则定义了明确优先级：
Rule_001 priority = 100
Rule_002 priority = 50则：
Rule_001 > Rule_002可以选择：
STOP但这里需要明确：
优先级解决的是“哪个规则优先”，并不意味着低优先级规则是错误的。
5.3 无法解决的规则冲突
如果：
Rule_001 priority = 100
Rule_002 priority = 100并且没有其他解决条件：
STOP ↔ RUN则不能随意选择。
应该产生：
ConflictResult = UNRESOLVED并进入：
Risk
Decision
Diagnosis或要求外部确认。
6. 行为冲突
Behavior Conflict 发生在多个行为无法同时执行时。
例如：
Behavior_A
target = Door_A
action = OPEN同时：
Behavior_B
target = Door_A
action = CLOSE两个行为同时处于：
READY如果没有允许同时执行的条件：
OPEN ↔ CLOSE产生：
BEHAVIOR_CONFLICT6.1 行为冲突检测
可以检查：
Target
Action
Time
Condition
Resource
Priority结构：
BehaviorConflict
{
behavior_a
behavior_b
target
action_a
action_b
time
condition
state
}例如：
Behavior_A → Motor_A.START
Behavior_B → Motor_A.STOP检测：
Same Target = TRUE
Same Time = TRUE
Action Conflict = TRUE结果：
CONFLICT6.2 行为冲突不一定需要取消
如果：
Behavior_A priority = 100
Behavior_B priority = 20可以：
Behavior_A → EXECUTE
Behavior_B → WAIT而不是直接删除 Behavior_B。
因此：
Conflict Resolution可以产生：
EXECUTE
WAIT
REJECT
CANCEL
REPLAN
UNKNOWN7. 优先级解决
当系统发现多个冲突候选时，需要通过 Priority 进行解决。
基本过程：
Conflict
↓
Candidate A
Candidate B
↓
Priority Evaluation
↓
Compare
↓
Select7.1 优先级依据
可以使用：
Safety
Risk
Urgency
Importance
Rule Priority
Task Priority
Object State
Experience例如：
Candidate A
STOP Motor
Risk = LOW
Safety = HIGH
Priority = 100Candidate B
RUN Motor
Risk = HIGH
Safety = LOW
Priority = 50最终：
STOP > RUN7.2 风险优先
当安全风险较高时，可以定义：
IF
RiskLevel = CRITICAL
THEN
Priority = MAX例如：
Motor temperature = 95℃同时存在：
RUN
STOP如果：
Overheat Risk = CRITICAL则：
STOP获得更高处理优先级。
7.3 优先级不能代替冲突分析
不能简单：
Priority
↓
直接执行正确过程是：
Conflict Detection
↓
Conflict Analysis
↓
Risk Analysis
↓
Priority Evaluation
↓
Conflict Resolution因为：
Priority 是解决依据
Conflict 是需要解决的问题二者不是同一个概念。
8. Conflict Result
Conflict 处理完成以后，需要形成结构化的 Conflict Result。
8.1 ConflictResult
ConflictResult
{
id
conflict_id
type
target
source_a
source_b
result_a
result_b
resolution
selected
rejected
priority
risk
state
reason
created_at
completed_at
}例如：
ConflictResult
{
id: "CR001",
conflict_id: "C001",
type: "RULE_CONFLICT",
target: "Motor_A",
source_a: "Rule_001",
source_b: "Rule_002",
result_a: "STOP",
result_b: "RUN",
resolution: "PRIORITY",
selected: "STOP",
rejected: "RUN",
priority: {
Rule_001: 100,
Rule_002: 50
},
risk: "HIGH",
state: "RESOLVED",
reason: "Safety rule has higher priority"
}8.2 Conflict Result 状态
可以定义：
DETECTED
ANALYZING
RESOLVED
UNRESOLVED
REJECTED
IGNORED
EXPIRED
ERROR其中最重要的是：
RESOLVED表示冲突已经按照规则、优先级或其他确定机制完成处理。
而：
UNRESOLVED表示系统无法安全、确定地解决冲突。
这时不能假装已经解决。
Risk 与 Conflict 的关系
两者虽然紧密相关，但职责不同。
Detection
↓
发现异常
│
├──────────────┐
↓ ↓
Risk Conflict
↓ ↓
可能造成什么 是否存在矛盾
│ │
└──────┬───────┘
↓
Priority
↓
Decision例如：
Motor_A.temperature = 95℃Detection：
ABNORMALRisk：
Overheat
RiskScore = 0.90
CRITICAL同时：
Rule_A → RUN
Rule_B → STOPConflict：
RUN ↔ STOPPriority：
Safety > ProductionConflict Result：
STOP selected
RUN rejected最后才进入：
Decision
↓
Behavior
↓
Action本章核心模型
Detection
↓
DetectionResult
↓
┌───────────────┐
│ │
↓ ↓
Risk Conflict
│ │
│ ┌──────┼──────┐
│ ↓ ↓ ↓
│ State Rule Behavior
│ Conflict
│ │
└───────┬───────┘
↓
Priority
↓
Conflict Result
↓
Decision更完整的自我维护循环：
Detection
↓
Risk / Conflict
↓
Priority
↓
Decision
↓
Repair
↓
Verification
↓
Detection本章核心定义
Risk 是对异常、事件、行为或决策可能造成的不利影响进行判断和量化的机制；Conflict 是对事实、状态、规则、行为、目标或资源之间不能同时成立或执行的矛盾进行检测、分析和解决的机制。
核心关系：
Risk
=
Probability × ImpactConflict
=
Incompatible A + Incompatible B最终：
Conflict
↓
Analysis
↓
Risk
↓
Priority
↓
Resolution
↓
ConflictResult其中必须保持几个边界：
Detection = 发现异常
Risk = 判断潜在影响
Conflict = 发现矛盾
Priority = 确定处理顺序/优先关系
Decision = 选择行动
Repair = 执行修复
Verification = 验证修复这样第72章与第73章就形成：
Detection
↓
Detection Result
↓
Risk
↓
Conflict
↓
Priority
↓
Decision
↓
Repair
↓
Verification
↓
Detection这条链就是 ICAI 自我检测、自我保护和自我维护机制的基础闭环。