第272章 Action API｜动作 API

一、提出背景

在 ICAI 认知运行过程中，行为（Behavior）并不是最终执行单位。

认知系统经过目标识别、场景理解、认知形成和方法选择之后，会形成一个具有目标和过程结构的行为模型：

Cognition
↓
Method
↓
Behavior
↓
Action
↓
Device
↓
World Change
↓
Feedback

其中，Behavior 表示一个面向目标的动态过程，而 Action 表示该过程中的具体执行单位。

例如，一个物体抓取行为可以表示为：

Grasp Behavior
↓
Approach
↓
Contact
↓
Apply Force
↓
Hold
↓
Lift
↓
Release

这里的 Grasp Behavior 是完整行为，而 Approach、Contact、Apply Force、Hold、Lift、Release 都属于可以被进一步执行和控制的动作。

因此，ICAI 需要在 Behavior 与 Device 之间建立标准化的动作接口，使行为能够被分解、生成、验证、调度和执行。

这就是 Action API 的工程意义。

---

二、Action API 的概念定义

Action API｜动作 API 是 ICAI 系统中用于创建、查询、更新、验证、执行和管理动作对象的标准应用程序接口（Application Programming Interface）。

Action API 的核心作用是：

Behavior
↓
Action API
↓
Action Object
↓
Action Validation
↓
Device Matching
↓
Device Execution

Action API 并不是设备本身，也不是行为本身。

它是：

Behavior → Action

之间的标准工程接口。

可以定义：

ActionAPI(B_t,S_t,P_t,D_t) → A_t

其中：

• B_t：当前行为（Behavior）
• S_t：当前状态（State）
• P_t：当前动作参数（Parameters）
• D_t：候选设备（Device）
• A_t：当前动作（Action）

因此：

A_t = F(B_t,S_t,P_t,D_t)

表示动作由当前行为、状态、参数和设备条件共同确定。

---

三、Action 的定义

Action｜动作 是行为过程中具有明确目标、对象、参数、执行条件和执行状态的最小执行单位。

动作可以表示为：

A = (
    I,
    Type,
    Target,
    Parameters,
    Device,
    State,
    Constraint,
    Time,
    Feedback
)

其中：

• I：动作 ID
• Type：动作类型
• Target：动作目标对象
• Parameters：动作参数
• Device：执行设备
• State：动作状态
• Constraint：动作约束
• Time：动作时间信息
• Feedback：动作反馈

例如：

Action
{
    Type: ApplyForce
    Target: Object_A
    Force: 10N
    Direction: Up
    Device: RobotHand
}

这表示一个明确的动作执行单元。

---

四、Action 与 Behavior 的区别

Action API 首先必须解决 Behavior 与 Action 的概念边界。

二者不能混为一体。

Behavior ≠ Action

Behavior 是过程。

Action 是过程中的执行单位。

例如：

Grasp Object

属于 Behavior。

而：

Move Hand
Touch Object
Apply Force
Hold Object
Lift Object
Release Object

属于 Action。

因此可以表示为：

Behavior
↓
Action₁
Action₂
Action₃
Action₄
...
Actionₙ

一个 Behavior 可以包含一个或多个 Action：

B = {A₁,A₂,...,Aₙ}

其中：

• B：行为
• A₁...Aₙ：行为所包含的动作序列

因此：

Method → Behavior → Action

分别表示：

Method：采用什么方法
Behavior：按照方法形成什么动态过程
Action：过程中的具体执行单位

---

五、Action 与 Method、Cognition 的关系

ICAI 的认知执行链可以进一步明确：

Cognition
↓
Method
↓
Behavior
↓
Action
↓
Device

其中：

Cognition｜认知回答：

当前世界是什么状态？
应该实现什么目标？

Method｜方法回答：

采用什么方式实现目标？

Behavior｜行为回答：

这个方法如何形成连续过程？

Action｜动作回答：

当前这一刻具体执行什么？

Device｜设备回答：

由什么执行主体完成？

因此：

Cognition ≠ Method
Method ≠ Behavior
Behavior ≠ Action
Action ≠ Device

这构成了 ICAI 从认知到物理执行的重要结构边界。

---

六、Action 类型

Action API 不应该针对某一个具体对象建立专用动作，而应该建立通用动作类型。

例如：

Move
Stop
Touch
Contact
Push
Pull
Hold
Grasp
Release
Lift
Lower
Rotate
ApplyForce
RemoveForce
Open
Close
Connect
Disconnect

这些动作不是针对某一个具体对象定义的。

例如：

Grasp(Egg)
Grasp(Glass)
Grasp(Bottle)
Grasp(Cup)

并不是四套完全不同的动作程序。

它们都可以使用：

Grasp(TargetObject,Parameters)

然后根据当前对象属性、状态、空间位置、关系和环境动态形成具体动作参数。

因此：

Generic Action
+
Current Object
+
Current State
+
Current Scene
+
Dynamic Parameters
↓
Current Action

这保证了动作模型具有一定的对象泛化能力。

---

七、Action 参数模型

动作不是只有动作名称。

真正执行动作时，还需要具体参数。

例如：

Move

可以具有：

Position
Velocity
Acceleration
Direction
Distance

而：

ApplyForce

可以具有：

Force
Direction
Duration
ContactPoint

因此：

P_t = F(A_t,S_t,R_t,Sc_t)

其中：

• P_t：当前动作参数
• A_t：当前属性
• S_t：当前状态
• R_t：当前关系
• Sc_t：当前场景

动作参数因此具有动态性。

例如：

Position_t
Velocity_t
Force_t
Pressure_t
Distance_t
Stability_t

可以组成属性向量：

X_t =
[
 Position,
 Velocity,
 Force,
 Pressure,
 Distance,
 Stability
]^T

然后：

P_t = F(X_t,S_t,R_t,Sc_t)

这样，Action 不再是一个静态命令，而成为当前认知状态下形成的动态执行单位。

---

八、Action 的动态状态

Action 本身也具有生命周期。

可以定义：

Created
↓
Ready
↓
Executing
↓
Completed

同时存在异常状态：

Executing
├→ Paused
├→ Failed
├→ Cancelled
└→ Interrupted

因此 Action 状态可以表示为：

AS_t ∈ {
    Created,
    Ready,
    Executing,
    Paused,
    Completed,
    Failed,
    Cancelled,
    Interrupted
}

动作状态随着时间变化：

AS_t → AS_{t+1}

其转换可以定义为：

AS_{t+1}
=
T(AS_t,S_t,F_t,C_t)

其中：

• AS_t：当前动作状态
• S_t：当前世界或对象状态
• F_t：当前反馈
• C_t：动作约束
• T：状态转换函数

因此 Action API 不只是创建一个动作，还需要持续管理动作状态。

---

九、Action 验证

动作进入执行阶段之前必须经过验证。

可以定义：

Valid(A)
=
Valid(B)
∧
Valid(Target)
∧
Valid(Parameters)
∧
Valid(Device)
∧
Valid(State)
∧
Valid(Constraint)

其中：

• Valid(B)：行为有效
• Valid(Target)：目标对象有效
• Valid(Parameters)：动作参数有效
• Valid(Device)：执行设备有效
• Valid(State)：当前状态允许执行
• Valid(Constraint)：约束条件满足

只有：

Valid(A)=1

时，Action 才可以进入执行阶段。

否则：

Action
↓
Validation
↓
Invalid
↓
Reject / Rebuild / Recalculate

---

十、Action 与 Device 的关系

Action 本身不应该直接承担具体设备控制逻辑。

其关系应该是：

Action
↓
Device Capability Matching
↓
Device Selection
↓
Device Execution

例如：

Action = ApplyForce
Requirement = ForceControl

系统需要寻找具有：

Capability(Device) ⊇ Requirement(Action)

的设备。

因此：

Match(A,D)=1

当：

Capability(D) ⊇ Requirement(A)

成立时，设备才具有执行该动作的能力。

进一步还需要检查：

Executable(A,D)
=
CapabilityValid
∧
Available
∧
StateValid
∧
ParameterValid
∧
ConstraintValid

这样可以将：

Action Logic

与：

Device Logic

进行分离。

---

十一、Action 的离散动态模型

动作执行不是一次性静态事件。

动作执行过程中，世界状态可能持续变化。

因此可以使用离散时间模型：

X_{t+1}=F(X_t,U_t)

其中：

• X_t：当前系统状态
• U_t：当前动作输入
• X_{t+1}：下一时刻状态
• F：状态变化函数

例如位置变化：

P_{t+1}=P_t+V_tΔt

其中：

• P_t：当前的位置
• V_t：当前速度
• Δt：离散时间间隔

速度变化：

V_{t+1}=V_t+A_tΔt

其中：

• A_t：当前加速度

力与加速度之间可以表示为：

F_t=mA_t

其中：

• F_t：作用力
• m：物体质量
• A_t：加速度

这些关系并不是 Action API 本身，而是 Action 参数和执行状态所依赖的动态计算基础。

---

十二、Action 与反馈

Action 执行之后，系统不会立即结束认知过程。

完整过程是：

Action
↓
Device
↓
World Change
↓
Feedback
↓
State Update
↓
Scene Update
↓
Cognition Update

因此：

F_t
→
S_{t+1}
→
Sc_{t+1}
→
C_{t+1}
→
M_{t+1}
→
B_{t+1}
→
A_{t+1}

新的动作由新的世界状态决定。

因此 Action API 不是单向接口，而是认知闭环中的一个动态节点。

---

十三、Action API 接口

Action API 可以建立如下标准接口：

/api/action/create
/api/action/get
/api/action/update
/api/action/delete
/api/action/list
/api/action/query
/api/action/execute
/api/action/validate
/api/action/cancel
/api/action/pause
/api/action/resume
/api/action/history

也可以采用对象资源方式：

/api/behaviors/{behavior_id}/actions
/api/actions/{action_id}

其中：

POST   /create
GET    /get
PUT    /update
DELETE /delete
POST   /execute
POST   /validate
POST   /pause
POST   /resume
POST   /cancel
GET    /history

形成统一动作生命周期接口。

---

十四、Action API 数据结构

Action API 的数据可以结构化为：

{
    "id": "A001",
    "type": "Grasp",
    "target": "Object001",
    "parameters": {
        "force": 10,
        "direction": "up",
        "duration": 2
    },
    "device": "Device001",
    "state": "Executing",
    "constraint": {
        "max_force": 20
    },
    "time": "2026-09-04T10:00:00"
}

这里 JSON 只是 Action 数据的通信表示。

因此：

Action Object
↓
Action Data
↓
JSON
↓
API Communication

而不是：

JSON
↓
Cognition

认知仍然发生在 ICAI Runtime 内部。

---

十五、PHP OOP 工程映射

Action API 可以采用 MVC + Service + Engine + Model + Repository 的结构。

ActionApiController
        ↓
ActionService
        ↓
ActionEngine
        ↓
ActionModel
        ↓
ActionRepository
        ↓
MySQL

核心类可以定义为：

class ActionApiController
{
    public function create($request)
    {
        return $this->actionService->create($request);
    }

    public function execute($request)
    {
        return $this->actionService->execute($request);
    }

    public function validate($request)
    {
        return $this->actionService->validate($request);
    }
}

Service 负责业务接口：

class ActionService
{
    public function create($data)
    {
        return $this->engine->createAction($data);
    }

    public function execute($data)
    {
        return $this->engine->executeAction($data);
    }
}

Engine 负责动作逻辑：

class ActionEngine
{
    public function createAction($data)
    {
        // Action formation
    }

    public function validateAction($action)
    {
        // Action validation
    }

    public function executeAction($action)
    {
        // Action execution preparation
    }
}

Model 表示 Action 对象：

class ActionModel
{
    public $id;
    public $type;
    public $target;
    public $parameters;
    public $device;
    public $state;
    public $constraint;
    public $time;
    public $feedback;
}

Repository 负责数据持久化：

class ActionRepository
{
    public function save($action)
    {
        // Save Action
    }

    public function find($id)
    {
        // Find Action
    }

    public function update($action)
    {
        // Update Action
    }
}

这样就形成：

API
↓
Controller
↓
Service
↓
Engine
↓
Model
↓
Repository
↓
Database

---

十六、数据库模型

Action 可以使用独立的数据表保存。

例如：

cognitive_actions

主要字段可以包括：

id
behavior_id
action_type
target_object_id
parameters
device_id
state
constraint_data
created_at
updated_at

动作历史可以使用：

cognitive_action_history

保存：

action_id
state
parameters
feedback
timestamp

形成：

Action
↓
Current State
+
Action History

从而支持动作状态追踪。

---

十七、Action API 与 ICAI Runtime

Action API 不独立于 ICAI Runtime。

完整运行关系为：

Real-Time Data
↓
Element
↓
Object
↓
Attribute
↓
Relation
↓
State
↓
Scene
↓
Cognition
↓
Method
↓
Behavior
↓
Action API
↓
Action
↓
Device
↓
World Change
↓
Feedback
↓
Element Update

因此：

Action API

实际上是 ICAI Runtime 向执行层延伸的重要接口。

它把认知系统产生的行为过程转换成标准动作对象，再交给设备执行系统。

---

十八、Action 的重新生成

动作不是永久固定的。

当世界状态发生变化时，当前动作可能需要重新计算。

例如：

Action₁
↓
Device
↓
World Change
↓
Feedback
↓
State Change

如果：

S_t ≠ S_{t+1}

那么原来的 Action 参数可能不再有效。

因此：

A_{t+1}
=
F(B_{t+1},S_{t+1},P_{t+1},D_{t+1})

也就是说：

新状态
↓
重新计算行为
↓
重新生成动作

这使 Action 成为动态认知系统的一部分，而不是固定脚本。

---

十九、通用动作模型

ICAI 的动作模型最终可以抽象为：

Goal
↓
Cognition
↓
Method
↓
Behavior
↓
Action
↓
Target
+
Parameters
+
Constraint
+
Device
↓
Execution
↓
Feedback

对于不同对象：

Egg
Glass
Bottle
Cup
Tool
Machine

系统并不需要分别建立：

GrabEgg()
GrabGlass()
GrabBottle()
GrabCup()

而是建立：

Grasp(Object,State,Parameters)

当前对象的差异通过：

Object
+
Attribute
+
Relation
+
State
+
Scene

进入动作参数计算。

因此：

Generic Action
+
Dynamic World Structure
↓
Current Action

这进一步体现了 ICAI 的结构化认知思想。

---

二十、Action API 的完整闭环

至此，动作 API 的完整运行模型可以表示为：

Cognition
↓
Method
↓
Behavior
↓
Action API
↓
Action Formation
↓
Action Validation
↓
Device Capability Matching
↓
Device
↓
Physical Execution
↓
World Change
↓
Feedback
↓
State Update
↓
Scene Update
↓
Re-Cognition

数学上可以表示为：

A_t=F(B_t,S_t,P_t,D_t)

执行后：

W_{t+1}=F(W_t,A_t)

其中：

• A_t：当前动作
• B_t：当前行为
• S_t：当前状态
• P_t：当前参数
• D_t：执行设备
• W_t：当前世界状态
• W_{t+1}：动作执行后的世界状态

随后：

W_{t+1}
→
Real-Time Data
→
Element
→
Object
→
State
→
Scene
→
Cognition

从而形成：

Action
→
World Change
→
Re-Cognition

这一闭环。

---

二十一、本章总结

Action API 建立了 ICAI 中：

Behavior → Action

之间的标准工程接口。

Action 是行为过程中的具体执行单位，具有：

Identity
+
Type
+
Target
+
Parameters
+
Device
+
State
+
Constraint
+
Time
+
Feedback

等基本结构。

其核心模型为：

ActionAPI(B_t,S_t,P_t,D_t) → A_t

并通过：

A_t=F(B_t,S_t,P_t,D_t)

形成当前动作。

Action 与前面的认知层次保持严格边界：

Cognition
↓
Method
↓
Behavior
↓
Action
↓
Device

其中：

Cognition = 认知
Method = 方法
Behavior = 行为
Action = 动作
Device = 设备

Action API 完成后，Part 24 的核心执行链进一步形成：

Element API
→
Object API
→
Attribute API
→
Relation API
→
State API
→
Scene API
→
Cognition API
→
Method API
→
Behavior API
→
Action API

至此，ICAI 已经从世界结构的数据接口逐步进入行为执行接口。

下一层自然进入：

Action
↓
Device API
↓
Device

因此下一章为：

第273章 Device API｜设备 API