第245章　ICAI行为MVC

245.1 提出背景

第244章建立了 ICAI 认知 MVC：

$CognitiveRequest→Controller→CognitiveService→CognitiveEngine→CognitiveResultCognitiveRequest \rightarrow Controller \rightarrow CognitiveService \rightarrow CognitiveEngine \rightarrow CognitiveResult$

认知解决的是：

机器个体如何认识对象、理解状态、分析关系并形成判断。

但是，ICAI 不能停留在认知结果。

认知形成以后，还必须根据目标、能力、方法、条件和决策形成行为，并进一步产生实际动作。

因此需要建立：

$BehaviorRequest→BehaviorService→BehaviorEngine→Action→Result\boxed{ BehaviorRequest \rightarrow BehaviorService \rightarrow BehaviorEngine \rightarrow Action \rightarrow Result }$

这一结构是 ICAI 从：

$CognitionCognition$

进入：

$BehaviorBehavior$

再进入：

$ActionAction$

的重要工程接口。

245.2 ICAI行为MVC定义

ICAI行为MVC（ICAI Behavior MVC），是将机器个体的行为形成、行为执行和行为结果映射到 MVC 工程结构中的方法。

基本结构：

行为请求
↓
Controller
↓
BehaviorService
↓
BehaviorEngine
↓
Action
↓
Result

如果行为执行需要读取或修改机器个体：

行为请求
↓
Controller
↓
BehaviorService
↓
BehaviorEngine
↓
Domain Object
↓
Action
↓
Result
↓
Repository
↓
MySQL

因此：

$BehaviorMVC=BehaviorRequest+BehaviorService+BehaviorEngine+Action+Result\boxed{ BehaviorMVC= BehaviorRequest+ BehaviorService+ BehaviorEngine+ Action+ Result }$

245.3 行为请求

**行为请求（Behavior Request）**是要求机器个体针对某一对象、目标、状态或条件执行特定行为的输入。

例如：

机器个体：
企业机器个体A

行为请求：
处理订单1001

或者：

机器个体：
设备机器个体A

行为请求：
启动设备

行为请求可以表示为：

$BR={Individual,Object,Goal,Condition,Method,Context}BR= \{ Individual, Object, Goal, Condition, Method, Context \}$

其中：

Individual：行为主体；
Object：行为对象；
Goal：行为目标；
Condition：行为条件；
Method：行为方法；
Context：行为场景。

245.4 行为请求与认知请求

认知请求：

$CognitiveRequestCognitiveRequest$

主要解决：

应该如何理解当前情况？

行为请求：

$BehaviorRequestBehaviorRequest$

主要解决：

在当前认知和决策基础上应该执行什么行为？

因此：

$Cognition→Behavior\boxed{ Cognition\rightarrow Behavior }$

例如：

认知：
订单已经超时

↓
行为请求：

处理异常订单

所以：

$CognitiveResult→BehaviorRequestCognitiveResult \rightarrow BehaviorRequest$

245.5 Controller接收行为请求

Web 环境中，行为请求首先进入 Controller。

例如：

class BehaviorController
{
    protected $service;

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

    public function execute()
    {
        $individualId =
            isset($_POST['individual_id'])
                ? (int) $_POST['individual_id']
                : 0;

        $objectId =
            isset($_POST['object_id'])
                ? (int) $_POST['object_id']
                : 0;

        return $this->service->execute(
            $individualId,
            $objectId
        );
    }
}

Controller 的任务是：

$HTTPRequest→BehaviorRequestHTTPRequest \rightarrow BehaviorRequest$

而不是直接执行动作。

245.6 Controller不负责行为计算

错误结构：

Controller
↓
判断条件
↓
选择方法
↓
执行行为
↓
修改状态
↓
保存数据库

这种结构会使 Controller 同时承担：

$Request+Business+Behavior+PersistenceRequest+ Business+ Behavior+ Persistence$

正确结构：

Controller
↓
BehaviorService
↓
BehaviorEngine
↓
Action
↓
Result

因此：

$Controller≠BehaviorEngine\boxed{ Controller\neq BehaviorEngine }$

245.7 BehaviorService

**BehaviorService（行为服务）**是行为业务流程组织层。

其位置为：

$Controller→BehaviorService→BehaviorEngineController \rightarrow BehaviorService \rightarrow BehaviorEngine$

BehaviorService 主要负责：

接收行为请求；
组织行为上下文；
获取机器个体；
获取行为对象；
调用 BehaviorEngine；
接收行为计算结果；
组织行为执行流程；
返回最终结果。

因此：

$BehaviorService=BehaviorFlow\boxed{ BehaviorService=BehaviorFlow }$

245.8 BehaviorService与CognitiveService

两者职责不同。

认知：

$CognitiveService→CognitiveEngineCognitiveService \rightarrow CognitiveEngine$

行为：

$BehaviorService→BehaviorEngineBehaviorService \rightarrow BehaviorEngine$

认知结果可以成为行为输入：

$CognitiveResult→BehaviorRequestCognitiveResult \rightarrow BehaviorRequest$

例如：

CognitiveEngine
↓
判断：订单异常
↓
CognitiveResult
↓
BehaviorService
↓
BehaviorRequest
↓
BehaviorEngine

因此形成：

$Cognition→Behavior\boxed{ Cognition\rightarrow Behavior }$

245.9 BehaviorEngine

**BehaviorEngine（行为引擎）**是执行行为形成与行为计算的核心工程对象。

它负责根据：

行为主体；
行为对象；
目标；
能力；
方法；
当前状态；
条件；
风险；
决策；

确定可以执行的行为。

可以定义：

$Behavior=F(Individual,Object,Goal,Capability,Method,State,Condition,Decision)\boxed{ Behavior= F( Individual, Object, Goal, Capability, Method, State, Condition, Decision ) }$

因此：

$BehaviorEngine≠ActionBehaviorEngine \neq Action$

BehaviorEngine 负责：

形成和组织行为。

Action 负责：

执行具体动作。

245.10 行为形成

前面的 ICAI 理论已经建立：

$Decision→Behavior→Action→ResultDecision \rightarrow Behavior \rightarrow Action \rightarrow Result$

因此 BehaviorEngine 的核心过程是：

目标
↓
能力
↓
方法
↓
条件
↓
决策
↓
行为

形成：

$Behavior=Goal+Capability+Method+Condition+Decision\boxed{ Behavior= Goal+ Capability+ Method+ Condition+ Decision }$

行为是一个结构化的执行意图，而不是某一个最小操作。

245.11 Behavior与Action的区别

这是 ICAI 行为工程中的重要边界。

$Behavior≠Action\boxed{ Behavior\neq Action }$

Behavior 表示机器个体准备执行的整体行为。

Action 表示行为中的具体执行动作。

例如：

Behavior：
处理订单1001

Action：
读取订单
Action：
修改订单状态
Action：
记录处理结果

因此：

$Behavior→Action1→Action2→Action3Behavior \rightarrow Action_1 \rightarrow Action_2 \rightarrow Action_3$

245.12 Behavior对象

行为可以建立独立的 Domain Object。

例如：

class Behavior
{
    protected $id;
    protected $individualId;
    protected $objectId;
    protected $goal;
    protected $method;
    protected $status;

    public function setStatus($status)
    {
        $this->status = $status;
    }

    public function getStatus()
    {
        return $this->status;
    }
}

行为对象可以保存：

$Behavior={Subject,Object,Goal,Method,Condition,Action,Result,Status}Behavior= \{ Subject, Object, Goal, Method, Condition, Action, Result, Status \}$

245.13 BehaviorEngine输入

BehaviorEngine 不应该只接收一个简单字符串。

例如：

“处理订单”

这样的信息不足以形成完整行为。

更完整的输入应该包括：

Individual
Object
Goal
Capability
Method
Condition
State
Decision

因此：

$BehaviorInput={I,O,G,C,M,Condition,S,D}BehaviorInput= \{ I,O,G,C,M,Condition,S,D \}$

其中：

$II$ ：Individual；
$OO$ ：Object；
$GG$ ：Goal；
$CC$ ：Capability；
$MM$ ：Method；
$SS$ ：State；
$DD$ ：Decision。

245.14 BehaviorEngine行为检查

行为形成以后，并不能立即执行。

首先需要检查：

$ConditionCondition$

例如：

对象存在
↓
状态允许
↓
能力存在
↓
方法存在
↓
权限允许
↓
风险可接受
↓
可以执行

因此：

$Execute(Behavior) ⟺ ConditionSatisfiedExecute(Behavior) \iff ConditionSatisfied$

如果条件不满足：

$Behavior→RejectedBehavior\rightarrow Rejected$

245.15 行为能力检查

机器个体必须拥有执行行为所需要的能力。

例如：

$Capability(I)Capability(I)$

如果行为需要：

$CapabilityRequiredCapabilityRequired$

则：

$Execute ⟺ Capability(I)⊇CapabilityRequiredExecute \iff Capability(I)\supseteq CapabilityRequired$

因此：

行为请求
↓
能力检查
↓
能力满足
↓
继续

否则：

能力不足
↓
行为不能执行

245.16 行为方法检查

能力存在并不代表已经确定具体执行方法。

因此：

$Capability→MethodCapability \rightarrow Method$

例如：

能力：
订单处理能力

方法：
订单异常处理方法A
订单异常处理方法B

BehaviorEngine 需要根据条件选择具体方法。

因此：

$MethodSelection=F(Goal,Condition,Capability,Risk)MethodSelection = F( Goal, Condition, Capability, Risk )$

245.17 行为与决策

行为通常来源于决策。

因此：

$Decision→BehaviorDecision \rightarrow Behavior$

例如：

认知：
订单超时

↓
决策：
执行异常订单处理

↓
行为：
处理订单1001

因此：

$Behavior=F(Decision,Goal,Capability,Method,Condition)Behavior= F(Decision,Goal,Capability,Method,Condition)$

行为不是脱离决策随机产生的。

245.18 Action

**Action（动作）**是行为实际执行过程中可以独立识别的具体操作。

定义：

$Action=Subject+Object+Operation+Condition+ResultAction= Subject+ Object+ Operation+ Condition+ Result$

例如：

Subject = MachineIndividual
Object = Order
Operation = UpdateStatus
Condition = StatusPending

形成：

$Action=UpdateOrderStatusAction= UpdateOrderStatus$

245.19 Action执行

BehaviorEngine 确定行为以后，将行为转换成一个或多个 Action。

例如：

Behavior：
处理订单1001

↓

Action 1：
读取订单

↓

Action 2：
检查订单状态

↓

Action 3：
修改订单状态

↓

Action 4：
保存处理结果

因此：

$Behavior→Action1→Action2→…→Actionn\boxed{ Behavior \rightarrow Action_1 \rightarrow Action_2 \rightarrow … \rightarrow Action_n }$

245.20 Action执行器

在工程上，可以建立 ActionExecutor。

例如：

class ActionExecutor
{
    public function execute(
        $action
    ) {
        return array(
            'success' => true,
            'action' => $action
        );
    }
}

BehaviorEngine 可以调用：

$action =
    $this->createAction(
        $behavior
    );

$result =
    $this->executor
        ->execute($action);

因此：

$BehaviorEngine→ActionExecutor→ActionBehaviorEngine \rightarrow ActionExecutor \rightarrow Action$

245.21 Action与Domain Object

Action 执行可能改变 Domain Object 状态。

例如：

Domain Object
状态：pending

↓

Action：
updateStatus(completed)

↓

Domain Object
状态：completed

形成：

$Statet→ActionStatet+1State_t \xrightarrow{Action} State_{t+1}$

因此：

$Action→DomainStateChange\boxed{ Action \rightarrow DomainStateChange }$

245.22 Action与Repository

Action 本身不应该直接负责数据库访问。

正确结构：

Action
↓
Domain Object
↓
Repository
↓
MySQL

例如：

$individual->setStatus(
    'completed'
);

$repository->update(
    $individual
);

因此：

$Action→DomainObject→Repository→MySQLAction \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL$

而不是：

$Action→MySQLAction \rightarrow MySQL$

245.23 Result

**Result（结果）**是 Action 执行以后形成的实际执行结果。

定义：

$Result=ActionResult+State+Condition+TimeResult= ActionResult+ State+ Condition+ Time$

例如：

array(
    'success' => true,
    'action' => 'update_status',
    'old_state' => 'pending',
    'new_state' => 'completed'
);

因此：

$Action→ResultAction \rightarrow Result$

245.24 BehaviorResult与ActionResult

必须区分：

$BehaviorResultBehaviorResult$

与：

$ActionResultActionResult$

行为可能包含多个 Action。

例如：

$Behavior→Action1→Result1Behavior \rightarrow Action_1 \rightarrow Result_1$ $Behavior→Action2→Result2Behavior \rightarrow Action_2 \rightarrow Result_2$

因此最终：

$BehaviorResult=F(Result1,Result2,…,Resultn)BehaviorResult= F(Result_1,Result_2,\ldots,Result_n)$

245.25 行为成功与目标完成

行为执行成功并不一定意味着目标已经完成。

例如：

Behavior：
处理订单

Action：
发送通知

Result：
通知发送成功

但是：

订单最终状态
仍然 = pending

因此：

$ActionSuccess≠GoalCompletedActionSuccess\neq GoalCompleted$

同样：

$BehaviorCompleted≠GoalCompletedBehaviorCompleted\neq GoalCompleted$

必须通过目标状态判断目标是否真正完成。

245.26 行为结果验证

行为完成以后需要进行结果验证。

例如：

$ExpectedStateExpectedState$

与：

$ActualStateActualState$

进行比较。

定义：

$ResultVerification=Compare(ExpectedState,ActualState)ResultVerification= Compare(ExpectedState,ActualState)$

例如：

目标状态：
completed

实际状态：
completed

则：

$GoalStateVerified=trueGoalStateVerified=true$

如果：

目标状态：
completed

实际状态：
pending

则：

$GoalStateVerified=falseGoalStateVerified=false$

245.27 BehaviorService处理Action结果

BehaviorEngine 完成动作以后：

$Action→ResultAction \rightarrow Result$

然后返回 BehaviorService。

例如：

$result =
    $this->engine
        ->execute($request);

if (
    !$result['success']
) {
    return array(
        'success' => false,
        'result' => $result
    );
}

return array(
    'success' => true,
    'result' => $result
);

因此：

$Result→BehaviorServiceResult \rightarrow BehaviorService$

245.28 BehaviorService返回Controller

BehaviorService 最终将结果返回 Controller：

$BehaviorService→ControllerBehaviorService \rightarrow Controller$

Controller 再决定：

HTML
JSON
Redirect
API Response

例如：

$result =
    $this->behaviorService
        ->execute($request);

return array(
    'success' => true,
    'data' => $result
);

245.29 行为MVC完整数据流

完整行为请求：

行为请求
↓
Controller
↓
BehaviorService
↓
BehaviorEngine
↓
Behavior
↓
Action
↓
Domain Object
↓
Repository
↓
MySQL

执行结果返回：

MySQL
↓
Repository
↓
Domain Object
↓
Action Result
↓
BehaviorEngine
↓
BehaviorService
↓
Controller
↓
Result

因此：

$BehaviorRequest→BehaviorService→BehaviorEngine→Action→Result\boxed{ BehaviorRequest \rightarrow BehaviorService \rightarrow BehaviorEngine \rightarrow Action \rightarrow Result }$

245.30 行为MVC与认知MVC

第244章：

$CognitiveRequest→CognitiveService→CognitiveEngine→CognitiveResultCognitiveRequest \rightarrow CognitiveService \rightarrow CognitiveEngine \rightarrow CognitiveResult$

第245章：

$BehaviorRequest→BehaviorService→BehaviorEngine→Action→ResultBehaviorRequest \rightarrow BehaviorService \rightarrow BehaviorEngine \rightarrow Action \rightarrow Result$

两者可以连接：

$CognitiveResult→BehaviorRequest\boxed{ CognitiveResult \rightarrow BehaviorRequest }$

于是形成：

认知请求
↓
CognitiveService
↓
CognitiveEngine
↓
CognitiveResult
↓
BehaviorRequest
↓
BehaviorService
↓
BehaviorEngine
↓
Action
↓
Result

这就是 ICAI 从认知进入行为的工程链。

245.31 行为MVC与决策

完整 ICAI 行为过程可以表示为：

$Cognition→Need→Goal→Capability→Matching→Method→Decision→Behavior→Action→ResultCognition \rightarrow Need \rightarrow Goal \rightarrow Capability \rightarrow Matching \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Result$

其中本章主要负责：

$Decision→Behavior→Action→ResultDecision \rightarrow Behavior \rightarrow Action \rightarrow Result$

因此 BehaviorMVC 是 ICAI 决策之后的执行工程层。

245.32 行为MVC与状态变化

动作执行可能导致状态变化：

$Statet→ActionStatet+1State_t \xrightarrow{Action} State_{t+1}$

例如：

订单
pending
↓
Action：完成处理
↓
completed

如果需要持久化：

$Statet+1→Repository→MySQLState_{t+1} \rightarrow Repository \rightarrow MySQL$

因此：

$Behavior→Action→StateChange→Persistence\boxed{ Behavior \rightarrow Action \rightarrow StateChange \rightarrow Persistence }$

245.33 行为MVC与记忆

行为执行产生的结果还可以进入 ICAI 记忆。

形成：

$Action→Result→Feedback→MemoryAction \rightarrow Result \rightarrow Feedback \rightarrow Memory$

例如：

行为：
处理异常订单

↓

动作：
修改订单状态

↓

结果：
修改成功

↓

反馈：
目标状态已达到

↓

记忆：
本次行为经验

因此：

$BehaviorResult→Memory\boxed{ BehaviorResult \rightarrow Memory }$

这为后续经验和学习提供基础。

245.34 行为失败

行为执行可能失败。

例如：

行为请求
↓
BehaviorEngine
↓
能力不足

或者：

Action
↓
条件不满足

或者：

Action
↓
Repository
↓
MySQL失败

因此行为失败需要分类：

$BehaviorFailureBehaviorFailure$ $ActionFailureActionFailure$ $PersistenceFailurePersistenceFailure$

三者不能混为一谈。

245.35 行为异常处理

例如：

BehaviorEngine
↓
Action
↓
执行失败
↓
Result
↓
BehaviorService
↓
Controller

如果属于可恢复问题，可以：

$RetryRetry$

如果属于条件不满足：

$RejectReject$

如果属于严重异常：

$StopStop$

如果属于系统故障：

$DiagnosisDiagnosis$

因此：

$BehaviorResult→Feedback→NextBehaviorBehaviorResult \rightarrow Feedback \rightarrow NextBehavior$

245.36 行为与自我维护

ICAI 的行为还可能是维护自身。

例如：

检测异常
↓
形成维护行为
↓
执行诊断动作
↓
执行修复动作
↓
验证结果

形成：

$Detection→Behavior→Action→Repair→VerificationDetection \rightarrow Behavior \rightarrow Action \rightarrow Repair \rightarrow Verification$

因此：

$BehaviorMVCBehaviorMVC$

不仅可以用于普通业务行为，也可以用于：

自我保护；
冲突处理；
异常处理；
自我诊断；
自我修复。

245.37 行为MVC完整工程模型

最终：

                    Behavior Request
                           ↓
                    ┌──────────────┐
                    │  Controller  │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │BehaviorService│
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │ BehaviorEngine│
                    └──────┬───────┘
                           ↓
                       Behavior
                           ↓
                        Action
                           ↓
                    Domain Object
                           ↓
                      Repository
                           ↓
                         MySQL
                           ↓
                       Result
                           ↓
                    BehaviorService
                           ↓
                      Controller
                           ↓
                         View

245.38 ICAI行为MVC统一模型

本章最终建立：

$BehaviorMVC=BehaviorRequest+BehaviorService+BehaviorEngine+Behavior+Action+Result\boxed{ BehaviorMVC= BehaviorRequest+ BehaviorService+ BehaviorEngine+ Behavior+ Action+ Result }$

其完整运行链：

$BehaviorRequest→Controller→BehaviorService→BehaviorEngine→Behavior→Action→DomainObject→Repository→MySQL\boxed{ BehaviorRequest \rightarrow Controller \rightarrow BehaviorService \rightarrow BehaviorEngine \rightarrow Behavior \rightarrow Action \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL }$

结果返回：

$MySQL→Repository→DomainObject→ActionResult→BehaviorEngine→BehaviorService→Controller→View\boxed{ MySQL \rightarrow Repository \rightarrow DomainObject \rightarrow ActionResult \rightarrow BehaviorEngine \rightarrow BehaviorService \rightarrow Controller \rightarrow View }$

245.39 ICAI认知—行为MVC连接

将第244章与本章连接：

Cognitive Request
        ↓
CognitiveController
        ↓
CognitiveService
        ↓
CognitiveEngine
        ↓
CognitiveResult
        ↓
BehaviorRequest
        ↓
BehaviorController
        ↓
BehaviorService
        ↓
BehaviorEngine
        ↓
Behavior
        ↓
Action
        ↓
Result

数学形式：

$CognitiveResult→BehaviorRequest→Behavior→Action→Result\boxed{ CognitiveResult \rightarrow BehaviorRequest \rightarrow Behavior \rightarrow Action \rightarrow Result }$

这表示 ICAI 不仅能够认识，而且能够将认知结果转换为行为执行。

245.40 行为MVC的核心边界

必须明确以下关系：

$Controller≠BehaviorServiceController\neq BehaviorService$ $BehaviorService≠BehaviorEngineBehaviorService\neq BehaviorEngine$ $BehaviorEngine≠ActionBehaviorEngine\neq Action$ $Behavior≠ActionBehavior\neq Action$ $Action≠ResultAction\neq Result$ $Result≠GoalResult\neq Goal$ $ActionResult≠GoalCompletedActionResult\neq GoalCompleted$ $Repository≠ActionRepository\neq Action$ $Action≠MySQLAction\neq MySQL$

这些边界保证 ICAI 行为工程具有明确的层次结构。

245.41 本章总结

第245章建立了 ICAI 的行为 MVC。

行为请求进入系统以后：

$BehaviorRequest→Controller→BehaviorService→BehaviorEngine\boxed{ BehaviorRequest \rightarrow Controller \rightarrow BehaviorService \rightarrow BehaviorEngine }$

BehaviorEngine 根据：

$Goal+Capability+Method+Condition+DecisionGoal+ Capability+ Method+ Condition+ Decision$

形成：

$BehaviorBehavior$

再将行为分解为一个或多个具体动作：

$Behavior→Action\boxed{ Behavior \rightarrow Action }$

动作执行以后产生：

$Action→Result\boxed{ Action \rightarrow Result }$

如果动作改变机器个体状态，则：

$Action→DomainStatet+1\boxed{ Action \rightarrow DomainState_{t+1} }$

需要长期保存时：

$DomainObject→Repository→MySQL\boxed{ DomainObject \rightarrow Repository \rightarrow MySQL }$

最终形成完整行为链：

$BehaviorRequest→Controller→BehaviorService→BehaviorEngine→Behavior→Action→Result\boxed{ BehaviorRequest \rightarrow Controller \rightarrow BehaviorService \rightarrow BehaviorEngine \rightarrow Behavior \rightarrow Action \rightarrow Result }$

并与前面的认知 MVC 形成：

$Cognition→CognitiveResult→Behavior→Action→Result\boxed{ Cognition \rightarrow CognitiveResult \rightarrow Behavior \rightarrow Action \rightarrow Result }$

由此，ICAI 的 MVC 工程已经从单纯的 Web 请求处理进一步进入机器个体自身的认知—行为执行链。

其核心关系可以最终归纳为：

$认知产生判断→决策产生行为→行为产生动作→动作产生结果→结果产生反馈\boxed{ 认知产生判断 \rightarrow 决策产生行为 \rightarrow 行为产生动作 \rightarrow 动作产生结果 \rightarrow 结果产生反馈 }$

这为后续 ICAI 的行为反馈、记忆、经验、学习以及行为自我维护建立了直接的工程入口。

第245章 ICAI行为MVC

第245章 ICAI行为MVC

245.1 提出背景

245.2 ICAI行为MVC定义

245.3 行为请求

245.4 行为请求与认知请求

245.5 Controller接收行为请求

245.6 Controller不负责行为计算

245.7 BehaviorService

245.8 BehaviorService与CognitiveService

245.9 BehaviorEngine

245.10 行为形成

245.11 Behavior与Action的区别

245.12 Behavior对象

245.13 BehaviorEngine输入

245.14 BehaviorEngine行为检查

245.15 行为能力检查

245.16 行为方法检查

245.17 行为与决策

245.18 Action

245.19 Action执行

245.20 Action执行器

245.21 Action与Domain Object

245.22 Action与Repository

245.23 Result

245.24 BehaviorResult与ActionResult

245.25 行为成功与目标完成

245.26 行为结果验证

245.27 BehaviorService处理Action结果

245.28 BehaviorService返回Controller

245.29 行为MVC完整数据流

245.30 行为MVC与认知MVC

245.31 行为MVC与决策

245.32 行为MVC与状态变化

245.33 行为MVC与记忆

245.34 行为失败

245.35 行为异常处理

245.36 行为与自我维护

245.37 行为MVC完整工程模型

245.38 ICAI行为MVC统一模型

245.39 ICAI认知—行为MVC连接

245.40 行为MVC的核心边界

245.41 本章总结