第2章 为什么需要 SAI Framework
本章大纲
- 传统程序的运行方式
- 普通业务系统的局限
- 人工个体模拟的需求
- 信息输入与程序输入的区别
- 环境与场景
- 状态与行为
- 记忆与经验
- 决策与行动
- 为什么需要统一框架
- Framework 对 Individual 的意义
- SAI Framework 的应用范围
- 本章案例
2.1 传统程序的运行方式
传统程序的基本运行方式非常明确：
输入
↓
处理
↓
输出例如，一个计算程序：
输入：10 + 20
程序：
计算 10 + 20
输出：
30程序本身并不需要理解“10”和“20”是什么。
它只需要按照已经定义好的程序逻辑执行：
$result = 10 + 20;因此，传统程序的核心特点是：
程序按照预先编写的逻辑，对输入数据进行处理，然后产生输出。
可以进一步表示为：
Input
↓
Program Logic
↓
Output如果程序逻辑是：
IF temperature > 30
THEN fan = ON那么：
temperature = 35程序执行：
35 > 30条件成立：
fan = ON这仍然属于典型的程序控制。
2.2 普通业务系统的局限
现代业务系统通常比简单程序复杂得多。
例如一个订单系统：
用户
↓
提交订单
↓
订单系统
↓
检查库存
↓
计算价格
↓
生成订单
↓
支付
↓
发货系统可以包含：
用户
订单
商品
库存
支付
物流
权限
日志
数据库但是这些对象通常都是围绕业务流程建立的。
例如：
Order
Product
User
Payment
Shipping它们解决的是：
“业务应该如何运行？”
而不是：
“一个人工个体应该如何认识外部世界？”
这两者存在明显区别。
普通业务系统通常具有：
固定输入
固定流程
固定业务规则
固定输出而一个模拟人工个体面对的环境可能是：
信息不断变化
对象不断变化
状态不断变化
关系不断变化
目标不断变化
反馈不断变化因此，单纯按照传统业务流程设计，很难完整表达一个持续运行的 Individual。
2.3 人工个体模拟的需求
如果希望构建一个模拟人工个体，就必须进一步回答几个问题：
它看到了什么？
它接收到了什么？
它知道什么？
它记得什么？
它现在处于什么状态？
它如何理解当前情况？
它如何进行推理？
它为什么做出某个决定？
它准备执行什么行为？
执行之后发生了什么？
它从结果中获得了什么经验？因此，模拟人工个体至少需要：
信息
↓
感知
↓
认知
↓
记忆
↓
推理
↓
决策
↓
行为
↓
反馈
↓
经验
↓
学习这已经不再只是：
Input → Process → Output而是：
World
↓
Information
↓
Perception
↓
Cognition
↓
Memory
↓
Reasoning
↓
Decision
↓
Behavior
↓
Action
↓
Feedback
↓
Experience
↓
Learning
↓
Update这就是 SAI Framework 所要解决的工程问题。
2.4 信息输入与程序输入的区别
这是理解 SAI Framework 的一个重要区别。
传统程序中的输入通常是：
参数
变量
表单
文件
数据库记录
API 数据例如：
function add($a, $b)
{
return $a + $b;
}这里：
$a
$b是程序参数。
但是 SAI 中的“信息接收”并不只是简单接收参数。
例如一个模拟人工个体接收到：
“前方有一辆汽车，距离 20 米，正在减速。”对于程序而言，这是一段信息。
对于 SAI 而言，则需要逐步形成：
信息
↓
元素
↓
对象
↓
属性
↓
关系
↓
状态例如：
对象：
汽车
属性：
距离 = 20m
速度状态 = 减速
关系：
汽车 → 位于 → 前方
状态：
前方车辆正在减速因此：
程序输入主要解决“数据进入程序”，SAI 信息接收进一步解决“外部信息进入 Individual 的认知过程”。
2.5 环境与场景
模拟人工个体不能只面对静态数据。
它必须面对一个不断变化的环境。
因此 SAI Framework 将：
Environment与：
Scene作为重要概念。
例如机器人所在环境：
房间
├── 人
├── 桌子
├── 椅子
├── 门
├── 地面
└── 其他物体某一时刻采集到的场景：
Scene
{
time: 10:30:01,
location: room_01,
objects:
[
person,
table,
chair,
door
]
}下一时刻：
Scene
{
time: 10:30:02,
location: room_01,
objects:
[
person,
table,
chair,
door
]
}虽然对象基本相同，但状态可能已经变化：
Person
speed = 0变成：
Person
speed = 1.2
direction = forward因此场景不是一个静态数据库。
它更接近：
Environment
↓
Scene
↓
Scene Information
↓
Perception场景采集模块可以负责：
Environment
Object
Position
Motion
Distance
State
Sensor最终形成统一的场景信息。
2.6 状态与行为
一个 Individual 不仅需要知道“世界是什么”，还需要知道：
当前自己是什么状态。
例如一个机器人：
State
{
position
speed
direction
battery
temperature
task
}这些信息构成 Individual 的自身状态。
同时，外部对象也存在状态。
例如：
Door
{
state = closed
}或者：
Motor
{
state = running
speed = 100
}状态变化以后，可能产生行为。
例如：
Door.state = closed同时：
target = enter_roomIndividual 可以形成：
Decision
↓
OpenDoor
↓
Action于是：
状态
↓
判断
↓
决策
↓
行为
↓
状态变化形成一个持续循环。
这也是 SAI 与传统一次性程序的重要区别之一。
2.7 记忆与经验
如果一个 Individual 每次遇到相同情况都完全重新处理，那么它只能表现出有限的持续能力。
因此必须存在：
Memory以及：
Experience例如：
第一次遇到：
道路积水Individual 执行：
降低速度结果：
安全通过于是形成经验：
Experience
{
scene = 积水道路
action = 降低速度
result = 安全通过
}以后再次遇到类似情况：
积水道路可以从记忆中获取：
历史经验然后影响后续判断。
形成：
当前场景
↓
记忆检索
↓
历史经验
↓
推理
↓
决策因此，Memory 并不是简单的“数据存储”。
它是 Individual 持续运行过程中形成历史状态的重要组成部分。
可以建立：
Memory
├── ShortMemory
├── LongMemory
├── FactMemory
├── ExperienceMemory
└── StateMemory2.8 决策与行动
理解信息之后，Individual 还需要回答：
下一步做什么？
这就是 Decision。
例如：
当前状态：
电量 = 15%
任务：
继续执行任务可能存在几个候选行为：
Candidate A：继续任务
Candidate B：返回充电站
Candidate C：停止任务Decision 系统可以综合：
Condition
Risk
Priority
Experience
Goal
State形成：
Candidates
↓
Condition Analysis
↓
Risk Analysis
↓
Priority
↓
Decision例如：
Decision = 返回充电站然后进入：
Behavior
↓
Action最终产生实际行为：
移动
↓
返回充电站因此：
决策负责选择，行为负责执行。
这两个概念不能混为一谈。
2.9 为什么需要统一框架
如果没有统一 Framework，开发一个 Individual 时，很容易变成：
A程序
负责信息
B程序
负责识别
C程序
负责记忆
D程序
负责规则
E程序
负责决策
F程序
负责设备
G程序
负责反馈这些程序之间可能没有统一的数据结构。
最终出现：
信息格式不同
对象格式不同
状态格式不同
关系格式不同
接口不同
生命周期不同
模块调用方式不同系统越大，维护成本越高。
SAI Framework 的意义就是提供统一的基础结构。
例如统一定义：
Information
Element
Object
Property
Relation
Method
Rule
State
Memory
Experience
Decision
Behavior
Action
Feedback然后建立统一的数据流：
Information
↓
Perception
↓
Element
↓
Object
↓
Relation
↓
Cognition
↓
Memory
↓
Reasoning
↓
Decision
↓
Behavior
↓
Action
↓
Feedback这样不同 Individual 可以共享相同的基础机制。
2.10 Framework 对 Individual 的意义
SAI Framework 与 Individual 的关系可以理解为：
SAI Framework
│
↓
提供基础能力
│
↓
IndividualFramework 本身不是 Individual。
它更像是 Individual 的：
基础结构
运行机制
对象体系
信息体系
记忆体系
认知体系
推理体系
决策体系
行为体系
反馈体系
扩展机制一个 Individual 则可以根据自己的配置拥有不同的：
Identity
Ability
Memory
Knowledge
Rules
Objects
Goals
Behaviors
Devices例如：
Individual A
├── 家庭机器人
├── 室内环境
├── 清洁能力
└── 移动能力另一个：
Individual B
├── 工业设备
├── 工厂环境
├── 检测能力
└── 控制能力二者可以使用相同 Framework。
区别在于：
Identity
Object
Ability
Rule
Memory
Device
Behavior不同。
所以：
Framework 负责提供“构建 Individual 的共同基础”，Individual 负责形成具体的模拟人工个体。
2.11 SAI Framework 的应用范围
SAI Framework 不应该被限制为 Web 应用。
Web 只是 SAI 的一种应用环境。
整体可以表示为：
SAI Framework
│
┌────────┼────────┐
│ │ │
Web API CLI
│
┌─────┴─────┐
│ │
UI System同时可以连接：
SAI
│
├── Robot
├── Vehicle
├── Drone
├── Industrial Device
├── Sensor System
├── Smart Device
├── Web System
├── API System
└── Custom Device因此它可以应用于：
1. Web Individual
例如：
网站信息接收
↓
认知
↓
判断
↓
行为
↓
Web Response2. Robot Individual
传感器
↓
场景
↓
感知
↓
认知
↓
决策
↓
运动3. Vehicle Individual
道路
↓
车辆
↓
环境信息
↓
场景理解
↓
决策
↓
车辆行为4. Industrial Individual
设备状态
↓
异常检测
↓
风险判断
↓
决策
↓
设备控制
↓
反馈5. 自定义 Individual
开发者可以根据具体任务构建自己的：
Object
Rule
Memory
Ability
Behavior
Adapter从而形成不同类型的模拟人工个体。
2.12 本章案例
下面使用一个简单案例说明为什么需要 SAI Framework。
假设需要构建一个：
能够观察房间环境，并决定是否打开风扇的模拟人工个体。
2.12.1 传统程序方式
传统程序可能直接写：
if ($temperature > 30) {
$fan = 'ON';
}整个逻辑只有：
Temperature
↓
IF
↓
Fan ON它可以完成任务。
但是它没有表达：
环境
对象
状态
记忆
经验
决策
行为
反馈2.12.2 SAI 方式
SAI 可以把这个问题拆成多个对象。
环境
Room对象
TemperatureSensor
Fan
Person状态
Temperature = 32℃
Fan = OFF
Person = PRESENT信息
{
source: TemperatureSensor,
object: Room,
property: temperature,
value: 32,
time: ...
}进入：
Information
↓
Perception形成：
Element
temperature
32进一步形成：
Object
Room
Property
temperature = 322.12.3 认知
Individual 建立：
Room
└── temperature = 32℃并结合规则：
IF Room.temperature > 30
THEN cooling_required = true形成：
Understanding即：
当前房间温度较高，需要降温。这里的“理解”不是生成一段自然语言，而是形成结构化的内部认知结果。
2.12.4 推理
已有事实：
temperature = 32规则：
temperature > 30推理：
32 > 30成立。
得到：
cooling_required = true2.12.5 决策
候选行为：
Candidate 1：保持风扇关闭
Candidate 2：打开风扇
Candidate 3：提高风扇速度结合当前状态：
temperature = 32
fan = OFF最终：
Decision
= TurnOnFan2.12.6 行为
决策进入行为系统：
Decision
↓
Behavior
↓
Action形成：
Behavior
{
type: cooling
target: Fan
action: ON
}2.12.7 外部执行
Action 通过 Renderer 或 Adapter 输出：
FanAdapter
↓
Fan
↓
ON风扇状态变成：
Fan.state = ON2.12.8 反馈
系统重新采集环境：
TemperatureSensor
↓
32℃一段时间之后：
28℃产生：
Feedback
{
action: TurnOnFan,
previous_temperature: 32,
current_temperature: 28,
result: success
}2.12.9 经验
系统形成：
Experience
{
condition:
temperature > 30
action:
fan = ON
result:
temperature decreased
}以后再次遇到类似状态时：
temperature > 30历史经验就可以成为推理和决策的参考。
最终形成完整循环：
环境
↓
场景采集
↓
信息接收
↓
感知
↓
元素
↓
对象
↓
属性
↓
关系
↓
认知
↓
记忆
↓
推理
↓
决策
↓
行为
↓
行动
↓
风扇
↓
环境变化
↓
反馈
↓
经验
↓
学习
↓
更新记忆
↓
再次感知这就是 SAI Framework 与简单条件程序之间最重要的区别之一。
本章核心认识
通过本章可以得到一个基本结论：
传统程序
Input
↓
Process
↓
Output而 SAI Individual 更接近：
World
↓
Information
↓
Perception
↓
Cognition
↓
Memory
↓
Reasoning
↓
Decision
↓
Behavior
↓
Action
↓
World
↓
Feedback
↓
Experience
↓
Learning
↓
Update
↓
World因此，为什么需要 SAI Framework，并不是因为传统程序不能执行规则，而是因为构建一个持续存在、能够感知环境、形成内部状态、使用记忆和经验、进行推理决策并产生行为的 模拟人工个体，需要一套统一的工程基础。
最终可以把本章压缩成一句话：
传统程序解决的是“程序如何执行”，SAI Framework 进一步解决的是“如何用软件工程结构构建一个能够持续感知、认知、记忆、推理、决策、行动、反馈和学习的模拟人工个体”。
本章结构关系
传统程序
↓
业务系统
↓
发现局限
↓
模拟人工个体需求
↓
信息
↓
环境 / 场景
↓
状态
↓
记忆 / 经验
↓
推理
↓
决策
↓
行为 / 行动
↓
反馈
↓
学习
↓
需要统一 Framework
↓
SAI Framework
↓
Individual第2章完成。