之前在服务机器人、无人机视觉感知、智能助手这类项目里做技术落地时，踩过不少“单点很强、整机瘫痪”的坑。视觉模型能检测出画面里的行人和障碍物，大语言模型能流畅对话，底盘控制模块也能正常运动，可一旦把几块能力串起来，联调就频繁出问题。后来我逐渐意识到一个被很多人忽略的问题：AI系统真正落地的难点，不在于单个模型，而在于“感知—理解—推理—决策—行动—反馈”这条链路的组织方式。
所以这篇内容，我想围绕“以人为本AI：从感知到行动的6层连接框架”做一次系统梳理。如果你是做AI应用、机器人、智能体的研发工程师，或者正在搭自己的AI Agent项目，这篇文章能帮你建立一套可复用的架构思路。文章会讲清楚六层框架的定位、层间接口设计，并提供一个可以直接跑通的最小Python实现，方便你在自己的项目里对照落地。
1. 背景与核心概念：为什么AI需要“从感知到行动”的完整链路
在智能机器人、智能客服、自动驾驶、AI助手这些项目的落地过程中，我观察到一个反复出现的现象：单个AI能力已经很成熟，但产品整体效果总是差一口气。
以服务机器人为例。机器人搭载了高精度的视觉识别模型，能检测出画面中的行人、桌椅、门等物体；也接入了大语言模型，能回答用户问题；还实现了基础的导航控制模块，可以让底盘移动到指定位置。单看每个模块，似乎都没问题。可一旦联调，问题就来了：视觉模型输出的是边界框和类别ID，大语言模型无法直接理解这些数字；决策模块不知道该先执行“靠近用户”还是先执行“避障”；即便决策正确，底盘控制器也缺少把高层决策解析成运动指令的适配层。结果就是，每个环节都有Demo，但整个系统跑不起来。
这类问题的本质，是把AI系统拆成了若干个互相独立的“点”，却没有建立起从感知到行动的“链”。而“以人为本AI：从感知到行动的6层连接框架”，就是为了解决这个连接问题提出的。
1.1 感知、认知与行动的割裂问题
传统软件工程里，一个功能模块通常由“输入—处理—输出”三段式组成，AI工程其实也遵循类似的逻辑。但在具体落地时，感知、认知和行动这三类能力往往被分给不同的团队、不同的框架、不同的开发周期去完成：
- 感知团队训练视觉模型、点云模型，交付的是识别结果；
- 认知团队编写规则、接入大模型，交付的是决策建议；
- 行动团队负责机械臂控制、运动控制、UI交互，交付的是执行动作。
问题在于，每一层交付的接口格式可能完全不同。感知层输出的是置信度、边界框、类别ID；认知层需要的是结构化的逻辑事实；行动层需要的是带优先级的执行指令。如果中间缺少统一的连接方式，数据流就会断裂，系统只能停留在“各自为战”的演示状态。
这种割裂体现在工程上，就是联调时最常见的“契约冲突”：下游期待的是A格式，上游给的是B格式，中间没有适配器，也没有统一标准。拆开看每个环节都合理，合起来却无法运行。
1.2 什么是“以人为本AI”
“以人为本AI”（Human-Centered AI）有两条核心主张。
第一条，AI系统要围绕人的需求设计，而不是围绕模型能力设计。技术上再强的目标检测，如果不能在用户需要的时候给出需要的信息，对用户就没有实际价值。比如一个服务机器人能识别20种物体，但用户真正需要的是它能在1米外感知到向它招手的人，并据此调整行为。模型能力再强，不贴合人的真实需求，也是浪费。
第二条，AI系统必须保留人的参与和判断。自动决策不应该是黑盒操作，应该允许用户选择、解释、纠正和接管。尤其在服务机器人、医疗辅助、智能驾驶这类涉及人身安全的场景中，任何行动指令都应经过可审计的决策链路，并且在必要时退给人。
这两条主张恰好和“从感知到行动”框架的落地价值高度契合：框架越完整，越容易在每一层加入人工校验入口；每一层接口越清晰，越能让系统以“可解释”的方式运行。
1.3 几个容易混淆的概念
在正式介绍框架之前，先区分三组常见概念，避免后续理解偏差。
AI Agent与六层连接框架。AI Agent强调的是“智能体能够自主完成任务”，更多是目标层面；六层连接框架强调的是一套内部结构，是“如何把智能体拆开组织”。可以说，六层连接框架是一个适合从零搭建AI Agent的工程脚手架。
感知与理解的边界。感知层回答“看到了什么”，理解层回答“这意味着什么”。比如摄像头里看到一个行人，这是感知；识别出“行人在招手示意停止”，这是理解。两者经常被混为一谈，但它们的模型、输入输出和评估方式完全不同。
决策与行动的区别。决策层给出意图，行动层给出动作。决策结果是“移动到A点，避开障碍物”，行动结果是“底盘左前方电机以0.3m/s速度转动”。缺少行动适配层，高层决策无法落到真实执行器。
理解了这些区别，下面就可以正式展开六层框架了。
2. 六层连接框架总体架构
六层连接框架把从环境输入到人类反馈的完整链路划分为六个层次，每一层解决一个特定问题，同时通过标准化的数据契约与相邻层连接。
| 层级 | 中文名 | 核心问题 | 典型职责 |
|---|---|---|---|
| L1 | 感知层 | 世界发生了什么 | 多模态输入解析、目标检测、SLAM、语音识别 |
| L2 | 理解层 | 信息意味着什么 | 场景图构建、意图识别、语义解析 |
| L3 | 推理层 | 当前状态如何评价 | 风险估计、知识检索、因果分析 |
| L4 | 决策层 | 下一步做什么 | 目标分解、策略规划、动作选择 |
| L5 | 行动层 | 如何执行 | 运动控制、工具调用、回复生成 |
| L6 | 反馈层 | 如何评估与改进 | 用户反馈收集、绩效评估、持续学习 |
2.1 一条指令在框架中的传递路径
为了直观理解，我们沿着一条具体指令走一遍：用户对服务机器人说“帮我把桌子上的水杯拿过来”。
- L1感知层：麦克风采集声音，视觉模块定位水杯和桌子；
- L2理解层：语音转文字，语义解析出“取水杯”的指令意图；视觉模块识别出桌上的水杯；
- L3推理层：判断水杯是否在可抓取范围内、机器人当前位置、是否有障碍物、是否存在安全风险；
- L4决策层：规划出一条“移动到桌子→伸出机械臂→抓取水杯→返回用户位置”的序列；
- L5行动层：底盘移动指令、机械臂关节角度、夹爪开合指令具体下发；
- L6反馈层：执行过程中机器人持续感知新环境；执行结束后向用户请求确认“是否拿到了水杯”，如失败则回退调整。
从这个例子能看出，六个层不是单向流动的。反馈可以从L6回到L1、L2、L3或L4，形成不同粒度的闭环。粗粒度闭环是“用户不满意→调整行动”，细粒度闭环是“感知到环境变化→实时改变决策”，两种闭环在一个完整系统中会同时存在。
2.2 层间数据契约是关键
工程上，六层框架最大的价值并不在层的划分，而在层间接口。几乎所有联调事故，都可以归结为“层间契约不一致”。
我在实际项目中通常用“数据类（DataClass）+ JSON Schema”的方式定义层间数据契约。例如感知层的标准化输出可以设计为：
{ "scene": "office", "objects": [ {"class": "person", "id": 1, "position": [1.2, 3.4], "velocity": [0.1, 0.2]}, {"class": "cup", "id": 2, "position": [0.8, 2.1], "velocity": [0.0, 0.0]} ], "timestamp": 1735000000.123 }感知层只负责输出这种标准化结构，不关心下游；决策层只依赖这种标准化结构，不关心感知层是摄像头还是激光雷达。这样一来，团队的开发边界变得非常清晰。
2.3 与常见AI Agent框架的对应关系
很多读者可能熟悉LangChain、AutoGPT这类AI Agent框架，也用过PyTorch搭建深度学习模型。这里做一个对应关系，方便快速迁移：
- PyTorch等深度学习框架更多集中在L1、L2层，负责训练和推理感知/理解模型；
- LangChain这类Agent框架侧重提供L3、L4、L5的pipeline能力，包括工具调用、记忆、规划；
- 机器人操作系统（ROS）负责L1和L5的硬件接入与运动控制；
- 反馈闭环通常需要自己实现，常见做法是引入强化学习或人类反馈的标注体系。
也就是说，六层连接框架是一个组织视角，具体的每一层都可以选择成熟组件来实现。这里的重点是设计，而不是重复造轮子。
3. 第1层与第2层：多模态感知与语义理解
前两层解决的是“从原始世界到语义世界”的转换问题，是整个AI系统理解真实环境的基础。
3.1 第一层：感知层
感知层位于整个链路的最前方，负责把物理世界中的信号转成结构化的数据。它的输入是图像、点云、音频、IMU、GPS、雷达等原始信号，输出是带有时间戳和坐标信息的检测结果。
在机器人相关场景中，当前工程界有一个明显趋势：从“单帧目标的检测”走向“多模态、多视角的联合感知”。比如BEV（Bird’s Eye View，鸟瞰视角）感知，就是先把摄像头、激光雷达、毫米波雷达等不同传感器的特征统一转换到鸟瞰空间，再进行目标检测、跟踪和预测。这样做的好处是，下游决策层拿到的就是一致的车身或机器人坐标空间，而不是一堆各自独立的图像坐标框。类似技术在无人机视觉感知、自动驾驶、园区巡检机器人上都有广泛应用。
这里要注意，感知层虽然叫“感知”，但它并不是单纯的传感器读取，而是一整套包含深度学习推理、传感器融合、坐标变换、时间同步的工程系统。当你说“我把感知做完了”时，至少需要确认下面几件事都完成了：
- 传感器时间同步。多个传感器必须有统一时间戳，否则融合结果会错位；
- 输出标准化。感知结果必须统一坐标、统一类别体系、统一置信度阈值；
- 异常回退。当传感器不可用时，感知层要有降级策略，而不是直接让下游崩溃；
- 性能预算。感知层往往是计算最重的环节，要考虑推理延迟是否满足决策实时性。
下面是一个最小接口示例：
class PerceptionLayer: def perceive(self, sensor_data: dict) -> PerceptionResult: """把原始传感器数据转成结构化感知结果。""" raise NotImplementedError感知层不关心下游怎么理解这些结果，它只需要保证：给我合法的输入，我返回合格的标准化输出。
3.2 第二层：理解层
理解层的输入是感知层的结构化结果，输出是“语义化场景”。这是感知和认知之间的桥梁层。
一个典型误会是：目标检测模型识别出了“人”“水杯”“桌子”，系统就算理解了场景。实际上，这只是感知，不是理解。理解要求回答更高层次的问题：
- 这个人在做什么（动作、意图）；
- 水杯和桌子之间是什么空间关系；
- 当前场景处于哪种类别（开会、打扫、休闲）；
- 用户说“那个东西”指的是哪个物体。
理解层往往会用到这些技术：
- 场景图（Scene Graph）：用节点表示物体，用边表示物体间的语义关系；
- 意图识别（Intent Recognition）：把语音或行为转成用户意图；
- 空间关系推理：结合坐标和类别，推断“杯在桌上”“人在机器人左侧”等空间语义。
在工程项目里，理解层的输出也应该是标准化的。下面是一个示例：
class SceneState: def __init__(self, objects, relations, user_intent, risk_level): self.objects = objects self.relations = relations # [("cup", "on", "desk"), ...] self.user_intent = user_intent # "fetch_cup" / "unknown" self.risk_level = risk_level # "low" / "medium" / "high"理解层的实现风格可以很不一样。传统做法是写规则和知识库，现代做法是微调多模态大模型帮助构建场景语义。关键是理解层必须为推理层提供“干净、稳定、可查询”的场景状态，而不是把原始检测结果直接丢给下游。
4. 第3层与第4层：认知推理与决策规划
中间两层是整个框架的“大脑”，它们负责判断当前局面并决定下一步怎么做。
4.1 第三层：推理层
推理层在理解层的基础上做判断和评价。它不负责决定具体动作，而是回答“当前状态意味着什么”“有多紧急”“有多危险”“有哪些约束”。
以服务机器人为例：
- 理解层识别出“用户在招手”；
- 推理层调用知识库，推理出“用户在向我示意的概率高，可能希望我停住或靠近”；
- 同时结合距离信息，判断“如果继续快速移动，碰撞风险高，所以应当降低速度”。
推理层常用的技术包括：规则引擎、知识图谱、因果推理模型、贝叶斯网络，以及基于大语言模型的思维链推理。这里给出一个规则加LLM混合的示例：
class ReasoningLayer: def reason(self, scene: SceneState) -> RiskAssessment: risk = RiskAssessment() for obj in scene.objects: if obj["class"] == "person" and obj["distance"] < 0.5: risk.level = "high" risk.reasons.append("person_too_close") # 如果规则的确定性不足，可以交给LLM做补充推理 if risk.level == "low" and scene.user_intent != "unknown": risk.suggestion = self.query_llm(scene.user_intent) return risk在这个示例里，我先用规则保证确定性高的安全判断，再用大模型补充开放语义。这个模式在实际项目中非常实用，因为它兼顾了安全性和灵活性。需要强调的是，推理层最忌讳“什么都用大模型”，也不应该“完全不使用大模型”。合理的分工是：规则负责安全底线，模型负责开放语义。
推理层最容易出现的问题，是“过度推理”和“推理不可解释”。如果系统给出了一个决策，但说不清是基于什么规则得出，人就很难信任它。以人为本AI要求推理层尽量返回可解释的依据，例如“因为距离小于0.5m，所以评定为高风险”。这份依据既是给用户的解释，也是给开发者的排错线索。
4.2 第四层：决策层
决策层是“人机协同中负责选择怎么做”的层。它接收推理层的风险评估和理解层的语义场景，输出一个有序的行动计划。
决策层通常可以拆成三个部分：
- 目标解析：把用户意图转成任务目标；
- 策略规划：把任务目标拆成多步子任务；
- 动作选择：为每个子任务选择合适的动作原语。
一个典型的目标是“take_cup_to_user”，策略规划可能产出：
move_to(["table", 0.8, 2.1]) grasp("cup") move_to(["user", 1.2, 3.4]) release("cup")为了让人能够干预，决策层在设计上应该暴露“候选计划”而不是只输出“最终计划”。比如，同时给出A、B两个候选计划，并附带各自的置信度和风险说明，让人可以一键切换。
决策层的常见实现方式包括有限状态机（FSM）、行为树（Behavior Tree）、蒙特卡洛树搜索（MCTS），以及在大模型支持下进行To-Do列表式规划。工程上我更推荐行为树，因为它结构清晰、便于人工审查和热更新。如果团队更熟悉大模型开发，也可以先做简单的List式规划，再逐步引入行为树。
需要注意的是，决策层的“最优解”不一定是“安全解”。在以人为本AI中，决策必须把安全约束作为硬边界。如果推理层已经判定高风险，那么决策层无论计划多么“高效”，都必须先执行安全动作。
5. 第5层与第6层：行动执行与反馈闭环
最后两层把决策变成现实，并让系统从结果中学习。后面两层是最容易被业务方忽略的，但也是决定系统能不能长期稳定运行的关键。
5.1 第五层：行动层
行动层是真正与物理世界或外部系统交互的地方。它接收决策层的高层计划，将其翻译成低层执行指令。
以机器人为例，行动层包括：
- 底盘导航控制：把“move_to”翻译成速度控制指令；
- 机械臂控制：把“grasp”翻译成关节角度轨迹；
- 语音合成：把“回复用户”翻译成TTS语音输出；
- 工具API调用：在软件Agent场景中，把“发送邮件”翻译成邮件API调用。
行动层需要特别关注“动作的可逆性”和“失败回退”。执行一个动作前，要先判断它是否具备回退条件。比如抓取水杯失败，夹爪会不会损坏水杯？导航中途遇到新障碍，能否重新规划路径？这些问题如果在行动层不提前处理，就会在真实环境里变成不可控的事故。
行动层的接口设计建议如下：
class ActionLayer: def execute(self, action: dict) -> ActionResult: """执行一个动作，返回执行结果。""" try: # 执行前记录现场 # 执行动作 # 执行后校验结果 return ActionResult(success=True) except ActionException as e: return ActionResult(success=False, error=str(e))行动层在返回结果时，应该带有明确的成功/失败状态和失败原因。这样反馈层才能准确判断下一步是继续、重试还是回退。
5.2 第六层：反馈层
反馈层是很多人容易忽略甚至直接省略的一层，但正是它让AI系统具备持续改进能力，也让“以人为本”真正落地。
反馈层要处理三种反馈：
- 环境反馈：系统在行动后，通过感知层检测“目标是否达成”；
- 用户反馈：用户明确表达“做对了/做错了”，或通过行为间接反馈；
- 系统反馈：各模块日志、延迟、资源占用、异常率等运行指标。
其中，用户反馈在以人为本AI中最为关键。实践中可以设计成：执行结束后弹出轻量级确认“这是您要的结果吗？[是][否]”；当出现不安全动作时支持“一键撤销”和“人工接管”。
一条可持续的反馈闭环，应该形成这样的循环：
行动 → 结果评估 → 错误归因 → 模型/策略更新 → 新感知把循环落到工程上，至少需要一个“经验记录表”。这里用SQL做示例：
CREATE TABLE feedback_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scene_snapshot JSON, action_plan JSON, user_feedback TINYINT, -- 1=满意, 0=不满意, -1=强烈反对 execution_status VARCHAR(32), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );每次用户反馈都会写入这张表。后续可以基于表中数据做离线分析，找出失败频繁的场景，再针对性地补充感知模型、规则或调整决策策略。反馈层不只是记录，它应该驱动模型迭代和配置更新。
6. 从零实现：一个感知到行动的Python最小系统
理论讲了不少，下面用一个尽量简化但仍能跑通全流程的Python示例，演示六层连接框架如何落成代码。这里以“模拟服务机器人判断是否应该停下或等待”为场景。
6.1 项目结构
human_centric_ai/ ├── schemas.py # 层间数据契约 ├── perception.py # L1 感知层 ├── comprehension.py # L2 理解层 ├── reasoning.py # L3 推理层 ├── decision.py # L4 决策层 ├── action.py # L5 行动层 ├── feedback.py # L6 反馈层 └── main.py # 启动与闭环6.2 定义数据契约 schemas.py
# schemas.py from dataclasses import dataclass, field from typing import Any, Dict, List, Optional @dataclass class PerceptionResult: objects: List[Dict[str, Any]] timestamp: float @dataclass class SceneState: objects: List[Dict
