开头为什么“能聊天的 AI”和“能干活的 AI”之间隔着一整条产业链过去一年里我们看到了太多让人惊艳的 AI 演示它能写代码、能总结文档、能生成图片、能陪你深夜谈心。但如果你真的想让它去操作一台设备、控制一个机器人、在恶劣天气下完成巡检或者帮用户完成一个跨系统的真实任务问题马上就变了——它连“看见”都没做到怎么谈“行动”这才是当前 AI 落地最真实的断裂带模型的推理能力已经足够强但感知和行动之间的连接依然非常脆弱。以服务机器人为例。你给机器人装上一个摄像头它能识别出“前方有一把椅子”这是感知你给它接上运动控制接口它能执行“前进 0.5 米”这是行动。但“识别出椅子”和“绕开椅子”之间需要完成坐标系转换、空间定位、路径规划、避障决策、指令下发、执行反馈……这一整套链路在工程上远比训练一个大模型复杂得多。所以我这篇文章想讨论的不是某一个具体模型而是一个可以复用的架构视角从感知到行动的 6 层连接框架。这个话题在近期 AI Agent、具身智能、机器人感知算法、BEV 感知、多模态大模型的热度背后其实是同一个核心命题——AI 如何从“会思考”变成“会干活”。读完这篇文章你能收获四样东西理解“以人为本 AI”到底强调什么以及它为什么不是一句口号。掌握从感知到行动的 6 层框架知道每一层解决什么问题、依赖什么技术。看到一个可运行的最小闭环示例覆盖感知、决策、行动三个关键节点。知道真实项目里最容易踩的坑以及工程落地的推荐姿势。不管你是做 AI 应用的开发者、机器人方向的研究者还是正准备引入 AI 能力的产品经理这篇文章都值得收藏。下面我们直接进入正题。1. 这篇文章真正要解决的问题先说一个很多人容易陷入的误区总以为 AI 项目最大的难点是模型选型实际上最难的是模型之外的系统链路。举个真实的例子。你在做一个“服务机器人环境感知灯光交互系统”听起来很高级但拆开看就是三件事机器人通过摄像头感知人的位置和姿态AI 判断当前场景适合什么灯光氛围灯光系统执行响应。这三件事单独拿出来都不难。难的是摄像头数据以什么频率传给感知模块感知结果以什么数据结构交给决策模块决策结果怎么映射成灯光设备的控制指令整个链路延迟能不能控制在 200ms 以内人走到一半感知丢了一帧会不会导致灯光乱闪这些问题没有一个能靠“换个更强的模型”解决。它们全部属于连接层连接框架的范畴。而“以人为本 AI”恰恰是在强调这一点技术不是为了展示模型的极限能力而是为了在人的真实场景里稳定、安全、可解释地完成对人的服务。所以这篇文章真正要解决的问题有三个认知问题AI 系统为什么必须分层感知、认知、决策、行动之间到底是什么关系工程问题从一个想法到一个可运行的感知-行动闭环需要哪些组件和流程判断问题哪些技术方案适合你的场景哪些是过度设计2. 基础概念感知、认知、决策与行动在展开 6 层框架之前先把四个基础概念说清楚。因为这些词被用得太随意导致很多讨论根本不在一个频道上。感知Perception感知是 AI 获取外部信息的过程。视觉、语音、雷达、红外、温度传感器都属于感知层。当前感知领域有几个典型方向多模态感知把图像、语音、文本、传感器数据融合起来BEV 感知Bird‘s Eye View鸟瞰视角感知在自动驾驶和机器人领域非常热门核心是把多个摄像头或雷达的数据统一转换到俯视坐标系下方便后续路径规划和决策恶劣天气感知雨雾天气下视觉退化怎么办这是无人机和自动驾驶都绕不开的问题。感知的产出不是“一张图”而是结构化信息比如“前方 2 米处有一个人置信度 0.95”。认知与决策Cognition Decision认知是理解场景决策是选择行动。传统机器人靠规则引擎和状态机做决策现在更多是让大模型参与——但大模型输出的是文本不是控制指令所以需要中间层把决策转换成机器能执行的行动原语。行动Action行动是系统对外部环境做出的改变。对软件 AI 来说行动是一次 API 调用、一条数据库写入、一个文件操作对机器人来说行动是电机转动、机械臂抓取、灯光切换。这个框架里最容易被忽略的是行动之后还要有反馈和评估。行动成功了吗环境发生了什么变化是否需要修正这才是“闭环”的意义。2.1 什么是“以人为本 AI”“以人为本 AI”不是某个具体技术而是一组设计原则人的需求是起点系统存在的意义是服务人而不是展示技术人在回路中Human-in-the-Loop关键决策必须保留人类审核和干预的入口可解释性优先AI 做了某个行动必须能说明为什么安全边界不可突破当感知不确定或决策风险高时选择保守行动而不是冒险。这套原则听起来朴素但在落地时直接决定了架构设计。比如一个全自动的灯控系统和一个“AI 推荐、人确认”的灯控系统架构差一个层级安全等级差一个量级。3. 从感知到行动的 6 层连接框架我们常说的 AI 系统在工程上可以拆成 6 层。每一层都有明确的输入、输出、核心技术和常见坑点。表格先给全景后面逐层展开层级名称核心任务典型技术输出的关键产物L1感知层采集并理解多模态数据视觉模型、语音识别、雷达、BEV结构化环境信息L2状态层汇聚多源信息形成统一状态表示多传感器融合、状态管理当前环境状态快照L3理解层对场景进行推理和语义解释多模态大模型、知识库场景语义描述L4决策层选择下一步行动大模型 Agent、规划算法、规则引擎行动计划L5行动层执行具体动作API、机器人 SDK、工具链动作执行结果L6反馈层采集执行后的效果回写状态评估模型、监控系统效果反馈与闭环修正这 6 层看起来多实际项目中可以根据场景压缩或合并。但核心逻辑不变数据流从环境到感知从感知到状态从状态到理解从理解到决策从决策到行动从行动到反馈再回到状态更新。3.1 为什么把“状态”和“理解”分成两层这是我需要特别强调的一点也是很多人做 AI 系统时最容易犯的错。他们通常把感知和决策直接连起来摄像头拍到人 → 触发打招呼。这样在小 demo 里没问题但一旦场景复杂系统马上会崩。原因很简单你无法在“原始感知结果”上做稳定决策。感知结果可能有噪声、有延迟、有缺失。如果决策逻辑直接依赖单帧感知结果那每一帧的抖动都会造成决策抖动。正确做法是引入“状态层”维护一个随时间更新的环境状态快照决策层只跟状态层打交道。理解层则解决“语义鸿沟”问题。感知层告诉你“画面中有 3 个人”但理解层告诉你“这 3 个人正在走向出口其中 1 个人行动不便”。前者是数据后者是意义。很多高质量 AI 服务差距就产生在这一层。3.2 决策层在大模型时代的变化传统决策层是规则引擎和有限状态机行为可预测但僵化。大模型 Agent 出现后决策层开始具备开放语义理解能力——它可以根据状态层提供的结构化信息理解当前场景结合用户目标和历史上下文动态生成行动序列。但这里有一个工程红线不要让大模型直接生成底层控制指令。大模型应该生成的是“行动计划”然后由行动层把计划映射到真实的 API 或设备指令上。这样才能保证安全性和可控性。4. 感知层的技术实现与场景拆解感知层是整个框架的地基。地基不稳上面全部白搭。4.1 视觉感知视觉感知当前的主流做法是训练或调用多模态模型从图像中提取结构化信息。实践中经常用到目标检测人、车、物、障碍物目标跟踪持续追踪某个目标的位置变化姿态估计判断人的动作和姿态语义分割给每个像素打标签在机器人场景还需要把图像坐标转换到空间坐标这就要用到相机标定、深度估计或者激光雷达融合。4.2 BEV 感知为什么它这么火BEV 感知的核心思想简单说就是把多个视角的摄像头图像“拍扁”到车或机器人上方的一个俯视平面里形成统一的鸟瞰视角表示。这样做的好处非常明显所有目标的坐标都在同一个平面坐标系里不同模态摄像头、雷达的数据可以对齐路径规划和避障算法可以直接在这个平面上工作对时序融合友好能保持目标在时间上的连贯性。坏处是计算量大、工程复杂度高。对一般的服务机器人项目不一定非得用 BEV但如果场景涉及多摄像头融合和复杂避障BEV 是一个值得投入的方向。4.3 恶劣天气感知一个被低估的坑无人机和室外机器人最容易遇到的问题就是恶劣天气——雨雾天气下视觉模型的精度会断崖式下降。这里有几种工程应对思路多传感器冗余摄像头退化时靠雷达、红外或超声波兜底图像增强预处理去雾算法比如雾感知密度评估器相关的技术方向在进入模型之前先做增强训练阶段加入对抗样本在训练集里加入雨天、雾天的合成数据提升模型鲁棒性决策层设置置信度阈值感知置信度低时主动降低速度或请求人工介入。从“以人为本”的角度看最后一条尤其重要——不是所有情况都要让 AI 硬扛可以有尊严地“承认自己看不清”。下面给一个简单的感知逻辑示例它的功能是接收图像路径调用视觉模型输出结构化的检测结果。# 文件路径perception/vision_engine.py from dataclasses import dataclass, field from typing import List, Optional dataclass class DetectedObject: label: str confidence: float bbox: List[float] # [x_min, y_min, x_max, y_max] track_id: Optional[int] None dataclass class PerceptionResult: frame_id: str timestamp: float objects: List[DetectedObject] field(default_factorylist) def to_dict(self) - dict: return { frame_id: self.frame_id, timestamp: self.timestamp, objects: [ { label: obj.label, confidence: obj.confidence, bbox: obj.bbox, track_id: obj.track_id, } for obj in self.objects ] } class VisionEngine: 视觉感知引擎。 实际项目中这里的 self.model 可以换成 YOLO、RT-DETR、 或任意一个多模态大模型 API。 def __init__(self, modelNone, confidence_threshold: float 0.5): self.model model self.confidence_threshold confidence_threshold def detect(self, image_path: str, frame_id: str) - PerceptionResult: # 实际项目这里会调用模型推理例如 # result self.model.predict(image_path) # 当前只做演示所以用一个虚构结果代替。 objects [ DetectedObject(labelperson, confidence0.96, bbox[10, 20, 80, 180]), DetectedObject(labelchair, confidence0.82, bbox[150, 300, 200, 380]), ] # 过滤低置信度结果 objects [o for o in objects if o.confidence self.confidence_threshold] return PerceptionResult( frame_idframe_id, timestamptime.time(), objectsobjects )这段代码演示了感知层输出的标准姿势不返回“图像”而是返回结构化对象列表。这是整个框架里贯穿始终的原则——每一层输出的数据都要为下一层做好准备。4.4 感知层输出的约定感知层输出的字段建议至少包含frame_id帧或时刻的唯一标识timestamp时间戳用于时序对齐objects检测到的目标列表每个目标包含类别、置信度、位置框、跟踪 ID。之所以强调结构化输出是因为状态层、理解层、决策层都要基于这些字段继续工作。字段不统一越到后面越痛苦。5. 从感知到状态多源信息融合感知层输出的是“这一帧看到的东西”但真实系统需要的是“当前环境是什么样的”。这就是 L2 状态层要做的事。5.1 为什么要做状态管理试想一个场景一个服务机器人在走廊里移动摄像头有 30 帧/秒的帧率但如果每帧都直接触发决策系统会因为单帧噪声而频繁抖动。比如有人从镜头前快速走过机器人的避障算法可能会误判为障碍物逼近紧急刹车。状态层解决这个问题的方式是维护一个“环境状态快照”。它接收多帧感知结果通过滤波、追踪、融合输出一个更稳定的“当前状态”。5.2 简单状态管理实现下面是一个简化的状态快照示例用字典保存当前场景中跟踪到的目标。# 文件路径state/scene_state.py from typing import Dict, Optional from perception.vision_engine import DetectedObject class SceneStateManager: 维护当前环境状态。 1. 接收感知层的检测结果。 2. 用 track_id 关联同一个目标的历史位置。 3. 输出稳定的状态快照供决策层使用。 def __init__(self, max_history: int 30): self.max_history max_history self.tracks: Dict[int, list] {} def update(self, detected_objects: list) - Dict[str, object]: now time.time() for obj in detected_objects: if obj.track_id is None: obj.track_id hash((obj.label, round(obj.bbox[0], 1), round(obj.bbox[1], 1))) if obj.track_id not in self.tracks: self.tracks[obj.track_id] [] self.tracks[obj.track_id].append({ time: now, bbox: obj.bbox, confidence: obj.confidence, }) # 只保留最近 N 帧 if len(self.tracks[obj.track_id]) self.max_history: self.tracks[obj.track_id] self.tracks[obj.track_id][-self.max_history:] return self.build_snapshot() def build_snapshot(self) - Dict[str, object]: snapshot { timestamp: time.time(), objects: [], } for track_id, history in self.tracks.items(): latest history[-1] snapshot[objects].append({ track_id: track_id, bbox: latest[bbox], confidence: latest[confidence], last_seen: latest[time], }) return snapshot这个类做的事情本质上就是把“连续多帧感知”变成“稳定环境状态”。实际项目中可以用卡尔曼滤波或 ByteTrack 这类更成熟的跟踪方案替换这里的简单逻辑。5.3 融合的层次多传感器融合有三种层次我简单列一下融合层次做法优点缺点数据级融合直接把多个传感器原始数据拼接信息损失少计算量大、对齐复杂特征级融合先各自提取特征再融合平衡较好需要特征设计经验决策级融合每个传感器独立决策再投票或加权实现简单、鲁棒单传感器信息利用不充分推荐顺序是先做决策级融合保证系统先跑起来等稳定性问题暴露后再考虑特征级融合。6. 理解与决策从状态到行动计划状态层告诉 AI“现在环境里有什么”理解层负责回答“这意味着什么”决策层负责回答“接下来该做什么”。6.1 理解层把状态变成语义在多模态大模型时代理解层的实现方式越来越直接——把状态层的结构化数据转成自然语言描述然后让大模型去理解场景。你可能觉得绕了一圈为什么不用大模型直接看图片原因有两点成本和延迟每帧都让大模型直接处理图像成本和延迟都不可控稳定性大模型直接理解图片受光线、角度、模糊影响大而基于结构化状态的语义描述更稳定。所以推荐的架构是快速感知模型做结构化提取大模型做语义理解。两者各司其职。6.2 决策层大模型 Agent 的行动原语决策层的设计有一个关键原则模型只负责做选择不负责直接操作底层设备。具体做法是把系统能力封装成一个个“行动原语”Action Primitive决策模型只能从行动原语集合里选择并组织执行顺序。举个灯控系统的例子# 文件路径decision/action_primitives.py from dataclasses import dataclass from typing import Callable dataclass class ActionPrimitive: name: str description: str parameters: dict execute: Callable # 灯控系统支持的最小行动集 ACTION_REGISTRY { set_light_mode: ActionPrimitive( nameset_light_mode, description设置灯光模式mode 可选 reading / meeting / sleeping / movie, parameters{mode: str}, executelambda mode: set_light_mode(mode) ), set_light_brightness: ActionPrimitive( nameset_light_brightness, description设置灯光亮度范围 0-100, parameters{value: int}, executelambda value: set_light_brightness(value) ), send_message_to_user: ActionPrimitive( namesend_message_to_user, description向用户发送一条提示消息, parameters{message: str}, executelambda message: send_message(message) ), request_human_approval: ActionPrimitive( namerequest_human_approval, description请求人工确认后再继续执行, parameters{reason: str}, executelambda reason: request_approval(reason) ) }这个设计的好处非常明显安全可控大模型只能在预设的行动集合里选择不会产生系统不支持的随机动作可审核每次决策都可以追溯使用了哪个行动原语、传了什么参数可回滚行动原语的执行逻辑可以单独升级、测试、回滚而不需要重新训练模型。6.3 决策层的提示词模板参考如果使用大模型做决策提示词模板可以这样设计你是一个环境控制决策助手。系统当前的环境状态如下 {scene_context} 你可以使用的行动包括 {action_registry_description} 用户当前的需求是{user_goal} 请选择下一步行动并且只返回 JSON 格式结果例如 {actions: [{action: set_light_mode, params: {mode: reading}}], reason: 用户正在阅读}重点在于让模型输出格式化的 JSON而不是自由文本。这样后续行动层可以直接解析和执行。7. 行动层与反馈层让闭环真正闭合行动层是把决策结果“翻译”成实际动作的地方。反馈层则是很多人容易忽略但恰恰决定系统智能程度的地方。7.1 行动层设计要点行动层是把决策结果“翻译”成实际动作的地方。反馈层则是很多人容易忽略但恰恰决定系统智能程度的地方。行动层设计要点接口统一每个行动原语都接受 params 字典执行后返回统一的 ActionResult失败重试机制设备调用可能失败必须有重试和熔断幂等性重复执行同一个动作结果应该一致避免因为网络重试导致重复操作。# 文件路径action/executor.py from dataclasses import dataclass from typing import Any, Dict, Optional dataclass class ActionResult: success: bool message: str data: Optional[Dict[str, Any]] None class ActionExecutor: 行动执行器。 负责把决策结果转换成真实调用。 def __init__(self, registry: dict): self.registry registry def execute(self, action_name: str, params: dict) - ActionResult: primitive self.registry.get(action_name) if primitive is None: return ActionResult(successFalse, messagefUnknown action: {action_name}) # 参数校验 for key, expected_type in primitive.parameters.items(): if key not in params: return ActionResult(successFalse, messagefMissing param: {key}) if not isinstance(params[key], eval(expected_type)): return ActionResult(successFalse, messagefParam type error: {key}) try: result primitive.execute(**params) return ActionResult(successTrue, messageOK, dataresult) except Exception as e: return ActionResult(successFalse, messagefExecute failed: {str(e)})7.2 反馈层的闭环逻辑行动执行之后系统必须回答一个问题这次行动有效吗反馈层的做法是行动执行后重新触发感知层采集环境状态对比行动前后状态变化把“行动-状态变化”记录到历史如果不达预期进入修正循环。在灯控系统里这个闭环可能是设定了阅读模式 → 感知层再次检测用户姿态 → 发现用户还在看手机 → 适当提高亮度。在机器人巡检场景里这个闭环可能是遇到障碍物 → 执行绕行 → 再次感知 → 确认绕行成功。用代码表达反馈逻辑# 文件路径feedback/evaluator.py from typing import Callable class TaskEvaluator: 评估一次行动是否达成了目标。 这里用简单的谓词函数演示实际项目中可以叠加规则、打分模型等。 def __init__(self, predicate: Callable[[dict], bool]): self.predicate predicate def is_success(self, state_after_action: dict) - bool: return self.predicate(state_after_action) # 使用示例判断灯光是否已经处于目标模式 def light_mode_checker(target_mode: str): def _check(state: dict) - bool: return state.get(light_mode) target_mode return _check evaluator TaskEvaluator(predicatelight_mode_checker(reading)) print(evaluator.is_success({light_mode: reading})) # True7.3 最小闭环串联把前面的感知、状态、决策、行动串起来就是一个最小可运行的感知-行动闭环。伪代码如下# 主流程perception_to_action_loop.py import time # 伪代码演示真实项目需要接入具体设备的 SDK 或 API def perception_to_action_loop(): vision_engine VisionEngine() state_manager SceneStateManager() executor ActionExecutor(ACTION_REGISTRY) frame_id 0 while True: frame_id 1 # 1. 感知 perception vision_engine.detect(current_frame.jpg, fframe_{frame_id}) # 2. 状态更新 snapshot state_manager.update(perception.objects) # 3. 语义理解与决策这里用简化规则代替大模型 if any(obj[confidence] 0.85 for obj in snapshot[objects] if obj[bbox][3] 350): decision {actions: [{action: set_light_mode, params: {mode: meeting}}]} else: decision {actions: [{action: set_light_mode, params: {mode: sleeping}}]} # 4. 执行行动 for step in decision[actions]: result executor.execute(step[action], step[params]) print(fAction {step[action]} - success{result.success}) # 5. 反馈与评估示例略 time.sleep(0.5) if __name__ __main__: perception_to_action_loop()这个示例是过度简化的但它展示了 6 层框架的核心思想数据流单向向下反馈闭环回流。8. 常见问题与排查思路在真实项目里问题往往不在于某个模型不够强而在于层与层之间的衔接。下面列出高频问题问题现象可能原因排查方式解决方案感知结果准确率还行但系统整体反应很怪感知结果没有经过状态层稳定化决策直接吃单帧检测检查决策层输入是否用状态快照引入状态管理增加时间滤波或跟踪逻辑大模型生成的行动参数经常非法行动原语的参数 schema 不够明确查看失败日志中参数校验错误在提示词中更严格地约束输出格式并在行动层做参数强校验行动执行了但用户觉得“没反应”反馈层缺失系统不知道行动是否生效检查行动后是否重新触发感知增加反馈评估环节用行动前后状态对比确认效果多传感器融合后数据冲突时间戳未对齐检查各传感器时间戳是否来自同一时钟统一时间同步机制或加缓冲区做时间对齐恶劣天气下感知精度骤降单一视觉传感器缺乏冗余查看单帧检测置信度分布增加非视觉传感器或降低决策对视觉高置信度的依赖系统延迟太高感知、决策、行动被同步串行阻塞用日志打印各环节耗时对非关键路径做异步化降低模型推理频率9. 最佳实践与工程建议基于前面的框架我整理了一份可以直接拿去用的工程建议清单。9.1 分层设计与接口先行先定义每一层的输入输出数据结构再写具体实现。数据结构尽量用 dataclass 或 protobuf 定义保证跨语言、跨团队协作时不会出现“我以为你传的是这个”的问题。9.2 决策层永远不要直接碰硬件所有硬件控制必须封装在行动层原语里。大模型或规则引擎只能通过行动原语操作外部世界。这不仅仅是安全考虑也是可测试性的要求——你可以 mock 掉行动层单独测试决策层。9.3 增设“安全兜底行动”当感知置信度低、模型输出异常或执行超时的时候系统必须有一个默认的安全动作。对服务机器人来说是停止移动对灯控系统来说是保持当前状态不变。不确定时不做比做错更安全。9.4 日志规范与追踪每一层都输出结构化日志包含请求 ID 或任务 ID贯穿整个链路。这样出了问题才能快速定位是感知层、决策层还是行动层的问题。推荐日志字段{ trace_id: task_001, layer: decision, input_snapshot: {object_count: 2}, decision: {action: set_light_mode, params: {mode: reading}}, reason: user is reading, timestamp: 1710000000.123 }9.5 灰度发布和回滚行动层的能力升级应当支持按用户或按场景灰度。例如先让新方案在 10% 的设备上运行观察反馈指标后再全量。模型升级同理——不同版本的感知模型可以并行跑一段时间对比准确率和延迟。9.6 测试策略建议建立三层测试单元测试每个行动原语单独测试覆盖正常、参数异常、设备故障场景集成测试感知→状态→决策→行动全链路用录制的历史数据回放仿真测试机器人和灯控这类物理设备先用仿真环境验证再上真机。10. 总结从模型能力回归到系统能力回到文章开头的问题为什么“能聊天的 AI”和“能干活的 AI”之间隔着一整条产业链因为干活意味着要与真实世界交互而真实世界要求的不只是聪明的模型更是可靠的系统。6 层连接框架的价值是帮你把“从感知到行动”这件很宏观的事情拆解成每一层都有清晰边界和可测试标准的工程任务。无论你接下来要做 AI Agent、服务机器人、无人机感知还是智能环境控制这套分层思路都适用。如果让我给你一条最实用的起步建议那就是先不要追求模型最强先把你系统的数据接口和行动边界定义清楚。用最小的模型跑通一个闭环再用真实场景的数据不断优化每一层。感知、状态、理解、决策、行动、反馈——6 层听起来不少但真正开始搭第一版时你会发现其中一半可以先用简单规则顶住。架构不要追求一步到位但要保证每一层都能被替换和升级。这才是“以人为本”落到工程上最实在的含义系统为人的需求服务但它的每一层都必须可控、可解释、可演进。下一步你可以做的是从自己手头最熟悉的一个场景出发画一张 6 层数据流图标出每一层的输入输出找一个最小任务把它跑通。这个体量通常只需要两三天但它带给你的理解远胜过读十篇架构文章。