第178章 DecisionService

在 ICAI 工程体系中，CapabilityService 解决“有没有能力”，MethodService 解决“有哪些可行方法”，而 DecisionService 进一步解决：

在当前条件下，多个候选方案中应该选择哪一个。

因此，DecisionService 是连接 Method、Capability、Goal 与 Behavior 的关键服务层。

前面的 MethodService 已经能够根据 Goal、Capability、Condition、State、Process 等信息形成 Method Candidates，但候选方案形成之后，并不意味着系统已经完成决策。

例如：

Goal = 获取杯子

Candidate Method A
Locate → Move → Grasp

Candidate Method B
Locate → Move → Align → Grasp

Candidate Method C
Locate → UseAlternativeGripper → Grasp

三个方法都可能满足基本目标，但当前环境、能力状态、资源、风险、历史结果和优先级可能不同。

此时系统必须进行：

Decision Conditions
        ↓
Candidate Solutions
        ↓
Rule Calculation
        ↓
Candidate Comparison
        ↓
Selection
        ↓
Decision Result

因此，本章将 DecisionService 定义为：

DecisionService 是负责建立决策条件、管理候选方案、执行规则化决策计算并形成可追溯决策结果的应用服务。

其核心模型可以表示为：

DS=(C,Ca,Cal,R)DS=(C,Ca,Cal,R)

其中：

• CC = Condition，决策条件；
• CaCa = Candidate，候选方案；
• CalCal = Calculation，决策计算；
• RR = Result，决策结果。

即：

DecisionService
 ├── Decision Condition
 ├── Candidate Management
 ├── Decision Calculation
 └── Decision Result

---

一、决策条件

决策条件（Decision Condition）是 DecisionService 的输入基础。

决策并不是脱离环境进行的。

系统必须首先知道：

当前目标是什么？
当前有哪些能力？
当前有哪些方法？
当前对象处于什么状态？
当前环境是什么？
有哪些限制？
有哪些风险？
有哪些优先级？

因此可以定义：

DC=(G,C,M,O,E,R,P)DC=(G,C,M,O,E,R,P)

其中：

• GG = Goal，目标；
• CC = Capability，能力；
• MM = Method，方法；
• OO = Object，对象；
• EE = Environment，环境；
• RR = Risk，风险；
• PP = Priority，优先级。

决策条件不是简单的一个 Boolean 值，而是一组能够影响候选方案选择的事实和规则。

例如：

Goal = 将箱子移动到仓库

Current State:
箱子重量 = 20kg
距离 = 50m
电量 = 70%

Capability:
Lift = Available
Move = Available
Carry = Available

Risk:
ManualCarryRisk = Medium

Priority:
Safety > Speed

这些信息共同形成当前 Decision Context。

---

二、决策条件与 Method Condition 的区别

这一点必须与第177章保持严格边界。

Method Condition 回答：

这个方法能不能在当前条件下执行？

Decision Condition 回答：

在多个可执行方案之间，当前应该选择哪个？

例如：

Method A:
需要 Battery > 30%

Method B:
需要 Battery > 50%

当前：

Battery = 60%

那么：

Method Condition
A → Pass
B → Pass

两个方法都可行。

这时 DecisionService 才进一步比较：

Method A
速度 = 10
风险 = 5

Method B
速度 = 8
风险 = 2

如果当前优先级是安全：

选择 Method B

因此：

Method Condition
→ 判断可执行性

Decision Condition
→ 判断选择依据

两者不能混为一个条件体系。

---

三、决策条件的类型

Decision Condition 可以分为多个层次。

1. Goal Condition

目标必须明确。

例如：

Target = Box
Destination = Warehouse

---

2. Capability Condition

候选方案所需要的能力必须存在并处于可用状态。

例如：

Move = Available
Lift = Available

---

3. Method Condition

候选 Method 自身的执行条件必须满足。

例如：

Battery > 30%
Load <= 20kg

---

4. State Condition

当前 Object、Individual、Method、Environment 的状态必须允许方案选择。

例如：

Robot State = Ready

---

5. Resource Condition

候选方案需要的资源必须存在。

例如：

Tool = Available
Storage = Available
Energy = Sufficient

---

6. Risk Condition

方案必须满足当前风险控制要求。

例如：

Risk Level <= AcceptableLevel

---

7. Priority Condition

不同目标之间存在优先级时，决策必须遵守优先级。

例如：

Safety > Cost > Speed

因此决策条件最终可以形成：

Goal
+
Capability
+
Method
+
State
+
Resource
+
Risk
+
Priority

---

四、候选方案

候选方案（Candidate Solution）是 DecisionService 的核心输入对象。

Candidate 在第161章 Decision 类中已经定义。

候选对象并不一定只能是 Method。

可以是：

Method
Capability
Behavior
Action
Object
Route
Strategy
Resource

但在当前 Service 层的主要流程中，DecisionService 最主要接收的是 Method Candidates。

例如：

Method Candidates
 ├── Method A
 ├── Method B
 └── Method C

DecisionService 首先必须对 Candidate 进行读取和标准化。

---

五、候选方案的状态

Candidate 必须具有状态。

例如：

unknown
available
unavailable
blocked
selected
rejected
failed

这些状态不是简单标签，而是决策计算的重要输入。

例如：

Method A → Available
Method B → Blocked
Method C → Available

则：

Candidate Set
=
{A,C}

Method B 不应进入最终选择计算。

但是：

Blocked Candidate 仍然应该保留在 Decision History 中。

因为未来 Diagnosis、Memory、Experience 可能需要知道：

为什么 Method B 没有被选择？

因此：

Candidate Rejected
≠
Candidate Deleted

---

六、候选方案的结构

可以建立 Candidate 对象：

Ca=(I,T,S,C,R,E)Ca=(I,T,S,C,R,E)

其中：

• II = Candidate ID；
• TT = Candidate Type；
• SS = Candidate State；
• CC = Candidate Conditions；
• RR = Candidate Requirements；
• EE = Evidence。

例如：

Candidate
 ├── ID
 ├── Type = Method
 ├── State = Available
 ├── Conditions
 ├── RequiredCapabilities
 ├── RequiredResources
 ├── Risk
 ├── History
 └── Evidence

这样 DecisionService 才能够对不同 Candidate 进行统一计算。

---

七、候选方案形成

候选方案主要来自 MethodService。

完整关系：

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

因此 DecisionService 不应该自己重新寻找全部 Method。

它接收：

Method Candidates
+
Decision Context

然后进行选择。

这样可以保持 Service 边界清晰。

---

八、候选方案过滤

候选方案进入决策计算之前，需要经过第一轮过滤。

例如：

Candidate A → Available
Candidate B → Blocked
Candidate C → Available
Candidate D → Condition Failed

则：

Eligible Candidates
=
{A,C}

可以定义：

E(Ca)=State∧Condition∧Capability∧ResourceE(Ca)=State\land Condition\land Capability\land Resource

其中：

• State = 候选状态允许；
• Condition = 条件满足；
• Capability = 所需能力满足；
• Resource = 所需资源满足。

如果：

E(Ca)=0E(Ca)=0

则 Candidate 不进入最终选择集合。

---

九、决策计算

决策计算（Decision Calculation）是 DecisionService 的核心计算过程。

它回答：

多个满足基本条件的 Candidate 中，哪个更适合当前目标？

决策计算必须建立在明确的规则之上。

ICAI 的 Decision Calculation 不依赖随机生成，也不是通过大模型产生结论。

它使用：

Facts
+
Conditions
+
Rules
+
Candidate Attributes
+
Priority
+
History
+
Experience
+
Risk

进行离散、可追踪的计算。

因此可以表示：

D=f(G,Ca,Co,S,R,H,E)D=f(G,Ca,Co,S,R,H,E)

其中：

• GG = Goal；
• CaCa = Candidate；
• CoCo = Condition；
• SS = State；
• RR = Risk；
• HH = History；
• EE = Experience。

---

十、决策计算不是随机选择

如果存在三个候选：

A
B
C

系统不能简单：

$selected = $candidates[array_rand($candidates)];

这种方式没有认知依据，也无法解释为什么选择 A。

ICAI 的决策必须能够回答：

为什么选择 A？
为什么没有选择 B？
为什么 C 被排除？
使用了什么条件？
使用了什么规则？

因此决策必须产生 Decision Evidence。

---

十一、决策规则

可以建立规则：

Rule 1:
如果 Candidate Condition 不满足
→ Reject

Rule 2:
如果 Required Capability 不可用
→ Reject

Rule 3:
如果 Risk 超过允许范围
→ Reject

Rule 4:
如果 Priority = Safety
→ 优先安全性更高的 Candidate

Rule 5:
如果安全等级相同
→ 比较执行成本

Rule 6:
如果成本相同
→ 比较历史结果

这样形成：

Candidate Filter
 ↓
Rule Evaluation
 ↓
Candidate Comparison
 ↓
Selection

---

十二、候选方案比较

候选方案比较可以建立结构化指标。

例如：

Candidate A
Safety = 8
Cost = 6
SuccessHistory = 9

Candidate B
Safety = 9
Cost = 8
SuccessHistory = 8

Candidate C
Safety = 7
Cost = 5
SuccessHistory = 7

如果当前优先级：

Safety > Success > Cost

则可以按照规则进行比较。

注意：

这里的数值只是离散决策指标，不意味着系统必须使用机器学习模型。

这些值可以来自：

事实
规则
历史统计
验证结果
人工配置
经验结构

例如安全等级可以直接由规则确定：

Risk = Low
→ SafetyScore = 3

Risk = Medium
→ SafetyScore = 2

Risk = High
→ SafetyScore = 1

因此 Decision Calculation 仍然属于符号规则和离散计算体系。

---

十三、决策计算可以采用规则评分

在工程实现中，可以建立：

Score(Ci)=∑j=1nWjVijScore(C_i)= \sum_{j=1}^{n}W_jV_{ij}

其中：

• CiC_i = 第 ii 个候选方案；
• WjW_j = 第 jj 个决策因素的权重；
• VijV_{ij} = Candidate ii 在因素 jj 上的评价值。

例如：

Safety Weight = 5
Cost Weight = 3
Success Weight = 4
Speed Weight = 2

然后：

Candidate A
Safety = 3
Cost = 2
Success = 3
Speed = 2

Candidate B
Safety = 3
Cost = 3
Success = 2
Speed = 2

系统可以按照预定义规则进行计算。

但是必须明确：

权重本身也是决策规则的一部分，而不是神经网络自动学习出来的参数。

权重可以由：

人工规则
业务规则
历史统计
Experience
Goal Priority

共同形成。

---

十四、决策计算中的 History

History 可以参与决策，但 History 本身不是 Decision。

例如过去执行：

Method A
成功 8 次
失败 2 次

Method B
成功 5 次
失败 5 次

这些都是 History。

DecisionService 可以读取这些历史事实：

History
 ↓
Success Rate Calculation
 ↓
Candidate Evaluation

但必须区分：

History
= 过去发生了什么

Decision
= 当前选择什么

因此：

History→EvidenceHistory \rightarrow Evidence

而：

Evidence+Rule→DecisionEvidence + Rule \rightarrow Decision

---

十五、Experience 参与决策

Experience 比 History 更进一步。

例如系统已经形成经验：

Condition:
ObjectWeight > 20kg

Method:
ManualCarry

Pattern:
FailureRisk High

那么当前遇到同样条件时：

Current Condition
 ↓
Experience Match
 ↓
Risk Increase
 ↓
Candidate Evaluation

因此：

Memory
 ↓
Experience
 ↓
Decision Evidence
 ↓
Decision

但 Experience 不能直接决定结果。

最终仍然需要：

Experience
+
Current Condition
+
Rule
+
Candidate
→
Decision Calculation

这样才能保证当前事实优先于单纯历史记忆。

---

十六、风险参与决策

Risk 是 DecisionService 的重要输入。

例如：

Method A
Risk = Low

Method B
Risk = High

当前 Goal：

Priority = Safety

则 DecisionService 可以依据规则：

Safety Priority
+
Risk Evaluation
→
Method A

如果所有候选风险都超过允许范围：

Candidate A → High Risk
Candidate B → High Risk
Candidate C → High Risk

则系统不应该强制选择一个。

正确结果是：

Decision Result
=
No Suitable Candidate

这是 ICAI 中非常重要的原则：

没有满足条件的候选方案时，“不决策”本身也是合法的决策结果。

---

十七、决策结果

决策结果（Decision Result）记录本次决策到底发生了什么。

Decision Result 不能只保存：

selected = true

应该至少包含：

DecisionResult
 ├── Decision ID
 ├── Selected Candidate
 ├── Candidate State
 ├── Decision Status
 ├── Reason
 ├── Conditions
 ├── Calculation
 ├── Evidence
 └── Time

例如：

Decision ID = 1001

Selected Candidate = Method B

Status = Selected

Reason =
Safety Priority

Evidence =
Method B Risk = Low

Rejected:
Method A = Higher Risk
Method C = Capability Unavailable

这样以后可以回答：

为什么选择 B？

系统能够从 Decision Result 和 Decision History 中恢复完整过程。

---

十八、决策结果状态

Decision Result 可以具有：

pending
selected
rejected
failed
cancelled
blocked
no_candidate

例如：

Candidate Exists
 ↓
Condition Evaluation
 ↓
No Candidate
 ↓
Decision Result = no_candidate

或者：

Candidate A
Candidate B
 ↓
Calculation
 ↓
B Selected
 ↓
Decision Result = selected

如果后续执行失败：

Decision
 ↓
Selected Method
 ↓
Execution
 ↓
Failure

此时不能把原来的 Decision Result 修改成“从未选择”。

应该保留：

Decision Result
= Selected

Execution Result
= Failed

因为：

决策失败与执行失败是两个不同事实。

---

十九、Decision 与 Method 执行的边界

DecisionService 负责：

选择 Method

不负责：

执行 Method

完整链路：

DecisionService
 ↓
Selected Method
 ↓
BehaviorService
 ↓
Behavior
 ↓
Action
 ↓
Execution

因此：

Decision
≠
Execution

Decision 只产生：

Selected Candidate

真正执行必须进入 Behavior / Action / Execution 层。

---

二十、决策结果与 Decision History

每一次 Decision 都应该产生 History。

例如：

Decision #1001
Goal = FetchCup
Candidates = A,B,C
Selected = B
Reason = Safety Priority
Time = T1

下一次：

Decision #1002
Goal = FetchCup
Candidates = A,B
Selected = A
Reason = B Blocked
Time = T2

这些历史可以形成：

HD={D1,D2,…,Dn}H_D=\{D_1,D_2,\ldots,D_n\}

Decision History 不是 Memory，也不是 Experience。

区别为：

Decision History
= 过去做过哪些选择

Memory
= 保存过去有价值的信息

Experience
= 从过去事实中形成的结构化经验

三者可以形成：

Decision
 ↓
Decision History
 ↓
Memory
 ↓
Experience
 ↓
Future Decision

---

二十一、DecisionService 的工程结构

DecisionService 应继续遵守 ICAI Service / Engine / Repository 分层。

Controller
    ↓
DecisionService
    ├── DecisionEngine
    ├── DecisionRepository
    ├── StateService
    ├── Risk / Conflict
    └── Experience / History

其中：

DecisionService

负责：

创建决策上下文
读取候选方案
组织决策过程
调用 DecisionEngine
保存 Decision Result
保存 Decision History

DecisionEngine

负责：

条件计算
候选过滤
规则计算
候选比较
选择

DecisionRepository

负责：

Decision
Candidate
Condition
Result
History

的持久化。

StateService

负责：

Decision State
Candidate State

的合法状态转换。

---

二十二、DecisionService 的 PHP 工程结构

按照 PHP 5.6 / PHP 7.0 的兼容要求，可以建立：

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

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

    public function create($goalId, $candidates, $conditions)
    {
        $decision = new Decision();

        $decision->setGoalId($goalId);
        $decision->setCandidates($candidates);
        $decision->setConditions($conditions);

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

    public function calculate($decision)
    {
        return $this->engine->calculate($decision);
    }

    public function getResult($decisionId)
    {
        return $this->repository->findResult($decisionId);
    }
}

这里 DecisionService 不直接写：

复杂比较算法
随机选择
SQL

而是将：

决策计算

交给 DecisionEngine。

---

二十三、DecisionEngine

DecisionEngine 是决策计算核心。

例如：

class DecisionEngine
{
    public function calculate($decision)
    {
        $candidates = $decision->getCandidates();
        $valid = array();

        foreach ($candidates as $candidate) {

            if (!$this->checkCondition($candidate, $decision)) {
                continue;
            }

            if (!$this->checkState($candidate)) {
                continue;
            }

            if (!$this->checkCapability($candidate)) {
                continue;
            }

            $candidate->setScore(
                $this->calculateScore($candidate, $decision)
            );

            $valid[] = $candidate;
        }

        if (empty($valid)) {
            return $this->noCandidateResult($decision);
        }

        return $this->select($valid);
    }
}

这里的 calculateScore() 只是规则计算接口。

实际项目中可以根据具体领域建立：

PriorityRule
RiskRule
CostRule
HistoryRule
ExperienceRule
CapabilityRule
ConditionRule

再由 DecisionEngine 统一执行。

---

二十四、候选方案的数据结构

数据库可以建立：

decisions
decision_candidates
decision_conditions
decision_results
decision_history
decision_rules

例如：

decisions

id
goal_id
state
created_at
updated_at

decision_candidates

id
decision_id
candidate_type
candidate_id
state
score
reason
created_at

decision_conditions

id
decision_id
condition_type
condition_value
result
created_at

decision_results

id
decision_id
selected_candidate_id
status
reason
calculation_data
created_at

decision_history

id
decision_id
action
candidate_id
old_state
new_state
reason
created_at

这样可以完整保存一次决策的产生、计算、选择和结果。

---

二十五、决策计算的完整工程流程

一次完整决策可以表示为：

Goal
 ↓
Create Decision Context
 ↓
Load Candidates
 ↓
Load Conditions
 ↓
Check Candidate State
 ↓
Check Capability
 ↓
Check Method Conditions
 ↓
Check Resource
 ↓
Check Risk
 ↓
Filter Invalid Candidates
 ↓
Calculate Candidate Values
 ↓
Compare Candidates
 ↓
Select Candidate
 ↓
Create Decision Result
 ↓
Save Decision History
 ↓
Return Selected Candidate

如果没有候选方案：

Goal
 ↓
Candidate Loading
 ↓
Candidate Filtering
 ↓
No Valid Candidate
 ↓
Decision Result = NO_CANDIDATE
 ↓
Diagnosis / Method Update / Goal Update

这比强行选择一个方案更加符合 ICAI 的工程逻辑。

---

二十六、无候选方案也是决策结果

这是 DecisionService 必须具备的能力。

例如：

Goal = Move Heavy Box

Candidate A = Lift
Candidate B = Carry
Candidate C = Cart

当前：

Lift = Unavailable
Carry = Unavailable
Cart = Unavailable

正确结果不是：

Selected = A

而是：

Decision Status = NO_CANDIDATE

随后系统可以进入：

No Candidate
 ↓
Diagnosis
 ↓
原因判断
 ├── Capability Missing
 ├── Resource Missing
 ├── Method Blocked
 ├── Condition Failure
 └── Goal Conflict

然后根据原因进入：

Capability Update
Method Update
Repair
Protection
Goal Update

这样 DecisionService 就能够与前面已经建立的 Risk、Conflict、Diagnosis、Repair 体系连接。

---

二十七、决策结果与反馈

决策本身也可以接受后续执行反馈。

完整过程：

Decision
 ↓
Selected Candidate
 ↓
Behavior
 ↓
Execution
 ↓
Result
 ↓
Feedback

如果结果符合预期：

Decision
 ↓
Success
 ↓
Decision History
 ↓
Experience

如果结果失败：

Decision
 ↓
Selected Candidate
 ↓
Execution
 ↓
Failure
 ↓
Diagnosis
 ↓
Decision Evaluation

这时系统可以发现：

Candidate selection itself may be correct

也可能发现：

Candidate selection was inappropriate

两者必须区分。

---

二十八、决策失败与方法失败

例如：

Decision:
选择 Method A

之后：

Method A
 ↓
Execution
 ↓
Failure

不能立即得出：

Decision = Wrong

因为失败可能发生在：

Method A 本身
Action
Execution Environment
Resource
Object State
Capability

因此 Diagnosis 必须分析：

Decision
 ↓
Selected Candidate
 ↓
Execution Failure
 ↓
Diagnosis
 ↓
Cause

如果：

Cause = Method A defective

则 MethodService 更新。

如果：

Cause = Capability unavailable

则 CapabilityService 更新。

如果：

Cause = Decision Rule inappropriate

则 Decision Rule 本身需要更新。

因此：

执行失败不能未经 Diagnosis 就直接归因于 Decision。

---

二十九、DecisionService 与 Experience 的闭环

Decision History 可以经过 Memory 和 Experience 形成后续决策依据：

Decision
 ↓
Result
 ↓
History
 ↓
Memory
 ↓
Experience
 ↓
Future Decision

例如：

Condition:
Battery < 30%

Method A:
Long-distance movement

历史：
3 次执行
3 次失败

形成 Experience：

LowBattery
+
LongDistanceMethod
→
HighFailureRisk

下一次：

Decision Context
 ↓
Experience Match
 ↓
Risk Evaluation
 ↓
Candidate Evaluation
 ↓
Alternative Method

这构成 ICAI 的经验辅助决策机制。

它仍然不是神经网络训练，而是：

History
+
Memory
+
Experience
+
Rules
+
Current Facts
→
Decision

属于离散、可解释、可追踪的认知计算过程。

---

三十、DecisionService 的最终闭环

DecisionService 的完整闭环为：

Decision Condition
        ↓
Candidate Solutions
        ↓
Candidate Filtering
        ↓
Rule Calculation
        ↓
Candidate Comparison
        ↓
Candidate Selection
        ↓
Decision Result
        ↓
Decision History
        ↓
Execution
        ↓
Feedback
        ↓
Experience
        ↓
Future Decision

形式化为：

Dt=f(G,Ca,Co,S,R,H,E)D_t= f(G,Ca,Co,S,R,H,E)

然后：

Dt→Candidatet→Selectiont→Executiont→Resultt→Feedbackt→HistorytD_t \rightarrow Candidate_t \rightarrow Selection_t \rightarrow Execution_t \rightarrow Result_t \rightarrow Feedback_t \rightarrow History_t

再进入：

Historyt→Memory→Experience→Dt+1History_t \rightarrow Memory \rightarrow Experience \rightarrow D_{t+1}

由此形成：

Current Facts
 ↓
Decision
 ↓
Actual Execution
 ↓
Actual Result
 ↓
History
 ↓
Experience
 ↓
Next Decision

---

三十一、DecisionService 与前后 Service 的完整关系

目前 Service 层已经形成连续结构：

NeedService
    ↓
Need

GoalService
    ↓
Goal

CapabilityService
    ↓
Capability

MethodService
    ↓
Method

DecisionService
    ↓
Decision

BehaviorService
    ↓
Behavior

ActionService
    ↓
Action

ExecutionService
    ↓
Execution

ResultService
    ↓
Result

FeedbackService
    ↓
Feedback

MemoryService
    ↓
Memory

ExperienceService
    ↓
Experience

其核心执行关系为：

Need
 ↓
Goal
 ↓
Capability
 ↓
Method
 ↓
Decision
 ↓
Behavior
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Memory
 ↓
Experience

DecisionService 位于其中的关键位置：

MethodCandidates→Decision→SelectedMethodMethodCandidates \rightarrow Decision \rightarrow SelectedMethod

因此它既不能提前执行，也不能绕过 Method。

---

三十二、DecisionService 的最终模型

经过本章定义，可以将 DecisionService 正式表示为：

DS=(C,Ca,Cal,R)DS=(C,Ca,Cal,R)

其中：

C=Decision ConditionsC=Decision\ Conditions

表示当前决策所依据的目标、能力、状态、资源、风险、优先级等条件；

Ca=Candidate SolutionsCa=Candidate\ Solutions

表示当前可参与决策的候选方案；

Cal=Decision CalculationCal=Decision\ Calculation

表示通过事实、条件、规则、权重、历史与经验进行候选过滤和比较；

R=Decision ResultR=Decision\ Result

表示最终选择、未选择、无候选、失败或其他决策状态及其原因。

因此：

DecisionService
=
Decision Conditions
+
Candidate Solutions
+
Decision Calculation
+
Decision Result

---

三十三、本章总结

DecisionService 是 ICAI Service 层中真正负责“选择”的服务。

它不负责创造 Goal，不负责声明 Capability，不负责设计 Method，也不负责执行 Behavior。

它的职责是：

条件
 ↓
候选
 ↓
计算
 ↓
选择
 ↓
结果

即：

决策条件 → 候选方案 → 决策计算 → 决策结果

其中，决策条件提供当前事实和约束；候选方案提供可选择对象；决策计算通过明确的规则、条件、优先级、风险、历史和经验进行比较；决策结果则记录最终选择及其理由。

完整关系可以表示为：

Goal
 ↓
Capability
 ↓
Method Candidates
 ↓
Decision Conditions
 ↓
Candidate Filtering
 ↓
Decision Calculation
 ↓
Candidate Comparison
 ↓
Decision Result
 ↓
Selected Method
 ↓
Behavior
 ↓
Action
 ↓
Execution
 ↓
Result
 ↓
Feedback
 ↓
Decision History
 ↓
Memory
 ↓
Experience
 ↓
Future Decision

最重要的工程边界为：

CapabilityService
→ 有没有能力

MethodService
→ 有哪些可行方法

DecisionService
→ 当前选择哪个方案

BehaviorService
→ 如何组织选定方案的行为

Execution
→ 实际发生了什么

Result
→ 实际产生了什么结果

因此，DecisionService 最终建立的是一个可解释、可追踪、可验证、可回溯的离散决策工程机制：

CurrentFacts+Conditions+Candidates+Rules+History+Experience→DecisionCurrentFacts + Conditions + Candidates + Rules + History + Experience \rightarrow Decision

而 Decision 并不在选择完成后结束，它还会通过：

Decision→Execution→Result→Feedback→History→Experience→NextDecisionDecision \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow History \rightarrow Experience \rightarrow NextDecision

形成持续的认知决策闭环。

由此，ICAI 的核心执行链进一步完整化：

Need→Goal→Capability→Method→Decision→Behavior→Action→Execution→Result→Feedback→Memory→ExperienceNeed \rightarrow Goal \rightarrow Capability \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Execution \rightarrow Result \rightarrow Feedback \rightarrow Memory \rightarrow Experience

DecisionService 正是这条链中负责把“可行方案”转化为“当前选择”的核心服务层。