尧图网站建设 
之前在服务机器人、无人机视觉感知、智能助手这类项目里做技术落地时踩过不少“单点很强、整机瘫痪”的坑。视觉模型能检测出画面里的行人和障碍物大语言模型能流畅对话底盘控制模块也能正常运动可一旦把几块能力串起来联调就频繁出问题。后来我逐渐意识到一个被很多人忽略的问题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、雷达等原始信号输出是带有时间戳和坐标信息的检测结果。在机器人相关场景中当前工程界有一个明显趋势从“单帧目标的检测”走向“多模态、多视角的联合感知”。比如BEVBird’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(successTrue) except ActionException as e: return ActionResult(successFalse, errorstr(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 以人为本AI：从感知到行动的6层连接框架详解
之前在服务机器人、无人机视觉感知、智能助手这类项目里做技术落地时踩过不少“单点很强、整机瘫痪”的坑。视觉模型能检测出画面里的行人和障碍物大语言模型能流畅对话底盘控制模块也能正常运动可一旦把几块能力串起来联调就频繁出问题。后来我逐渐意识到一个被很多人忽略的问题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、雷达等原始信号输出是带有时间戳和坐标信息的检测结果。在机器人相关场景中当前工程界有一个明显趋势从“单帧目标的检测”走向“多模态、多视角的联合感知”。比如BEVBird’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(successTrue) except ActionException as e: return ActionResult(successFalse, errorstr(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