从感知到行动：六层连接框架，搭建以人为本的AI系统架构-平芜编程栈

“以人为本AI”不是一句口号，而是当前AI工程化落地时最值得认真对待的架构思路。这次我们直接把这个话题拆开：从感知到行动，中间到底隔了几层？为什么很多AI项目感知做得很好，一到行动层就崩？答案往往不是模型不行，而是“层与层之间的连接”没设计好。

这篇文章会把一个六层连接框架完整讲透。它不是一个具体的开源仓库，也不绑定某一种模型，而是一套可以落地到多模态大模型、Robot、Agent、自动驾驶、工业质检等场景的架构方法论。读完你可以直接用这套框架去审视自己的项目：感知层在哪、决策层在哪、反馈闭环在哪、哪里断链了。

先给一个最直接的判断：这个框架的价值在于“结构”，不在于“参数”。它不挑显卡，不依赖某个特定框架，4G 显存能跑通最小验证，也能在云端 GPU 集群里承载完整业务。核心是帮你在做 AI 系统设计时，不再把“识别出一个东西”误当成“完成一个任务”。

1. 框架核心速览

能力项	说明
框架定位	从感知到行动的 AI 系统架构方法论，非绑定单一模型或平台
核心思想	以“人”为中心，将 AI 能力拆分为感知、理解、认知、决策、行动、连接六层
涉及技术栈	多模态大模型、AI Agent、RAG、BEV感知、机器人感知算法、模型微调、API服务
适用场景	自动驾驶、服务机器人、智能助手、智慧安防、工业质检、无人机视觉感知
硬件门槛	低配可做最小验证（CPU/小显存），生产级需要按场景配置 GPU
启动方式	按模块分层启动，支持 API 服务、Agent 框架、微服务编排
是否支持 API	可以通过 FastAPI / Flask 包装各层服务
是否支持批量任务	可以在行动层设计队列，批量执行任务
主要优势	把“感知”与“行动”之间的断层显性化，便于定位问题
适合读者	架构师、算法工程师、AI产品经理、机器人开发者

这个框架回答的核心问题是：当 AI 感知到信息之后，如何转化为对人有用的行动？而大多数项目失败，是因为感知层和行动层之间直接拉了一根线，中间没有缓冲、没有推理、没有反馈校验。

2. 为什么“感知”和“行动”之间需要六层连接

先看一个真实场景。

一个服务机器人要完成“帮用户拿一杯水”这个任务。仅从感知层看，它需要识别出杯子、识别出用户、识别出桌子和路径。但“感知到杯子”和“把杯子拿给用户”之间，隔着巨大的鸿沟：它要知道用户是真的需要水，还是随口一说；要知道水杯是空的还是满的；要知道拿水杯的路径上有没有障碍物；要知道如果用户改变主意了，应该停止还是继续。

很多早期的机器人项目，恰恰是把“识别到物体的框”当成了“任务完成”。结果是感知精度做到 99%，行动依然一塌糊涂。原因就是中间少了结构化的连接层。

六层连接框架的价值就在这里：每一层只负责一件事，层与层之间通过明确的接口传递信息。这样无论出什么问题，都能快速定位是哪一层断裂，而不是在整体黑盒里瞎猜。

对于当前 AI 技术趋势来说，这也正好对应了从“大模型能力堆叠”走向“Agent 系统编排”的演变。ChatGPT 这类模型解决的是“认知”和“推理”，但要让它真正行动，还需要记忆、规划、工具调用、反馈校验这些工程化模块。六层框架恰好把这些模块全部收纳进了一个可解释的结构。

3. 六层框架总体设计

六层结构从上到下依次为：

层级	名称	核心任务	对应技术模块
第一层	多模态感知层	收集并解析环境信息	摄像头、激光雷达、麦克风、OCR、语音识别、BEV感知
第二层	情境理解层	把感知数据变成结构化场景描述	多模态大模型、时空融合、环境感知算法
第三层	认知推理层	基于场景描述做分析和推理	大语言模型、知识图谱、RAG、思维链
第四层	决策规划层	制定目标、拆解步骤、选择行动路径	AI Agent、规划算法、强化学习、搜索算法
第五层	执行行动层	调用工具、控制系统、执行动作	机械臂控制、API调用、函数调用、爬虫、自动化脚本
第六层	连接反馈层	闭环校验、经验积累、模型更新	评估指标、数据回流、日志系统、持续训练

这六层不是简单的流水线。感知层的数据会同时流向情境理解层和反馈层；行动层的结果也必须回流到认知推理层，用于修正下一次决策。整个框架是一个闭环系统，而不是单向管道。

用代码结构来理解，这六层就像六个独立的服务模块：

# 框架层级示意（伪代码） class PerceptLayer: # 第一层：感知 def sense(self, stream): return perception_result class ContextLayer: # 第二层：情境理解 def understand(self, perception_result): return scene_graph class CognitionLayer: # 第三层：认知 def reason(self, scene_graph): return analysis class DecisionLayer: # 第四层：决策 def plan(self, analysis): return action_plan class ActionLayer: # 第五层：行动 def execute(self, action_plan): return execution_result class FeedbackLayer: # 第六层：反馈 def evaluate(self, execution_result): return feedback_for_update

每一层都可以独立开发、独立测试、独立部署。这是框架最核心的工程价值。

4. 第一层：多模态感知层

感知层是整个框架的数据入口。它的任务只有一个：最大程度完整地采集外部信息。

4.1 感知层包含什么

视觉感知：目标检测、语义分割、BEV感知、3D点云解析
听觉感知：语音识别、声纹识别、异常声音检测
文本感知：OCR识别、文档解析、多语言翻译
环境感知：温湿度、GPS、IMU、恶劣天气感知、雾感知密度评估

以无人机视觉感知为例，感知层不仅要做目标识别，还要理解“当前天气是否适合飞行”“当前地形是否有障碍物”。这些信息如果不进入感知层处理，后面所有层都无法工作。

4.2 感知层设计要点

感知层最容易犯的错误是“过度采集”。传感器堆得越多，数据量越大，但真正能被后续层利用的信息反而越少。设计感知层时，必须想清楚一个问题：哪些数据是后续决策真正需要的？

例如服务机器人的环境感知灯光交互系统，感知层只需要识别用户的位置、手势、语音指令和环境光照状态，并不需要把整条走廊的4K视频全部传给决策层。感知层要做信息压缩和筛选，而不是做无损记录。

实现上，感知层通常采用多模态模型组合的方式：

# 感知层调用示例（示意） from perception import VisualPerception, AudioPerception visual = VisualPerception(model_type="bev_transformer") audio = AudioPerception(model_type="whisper") scene_frame = visual.detect(camera_stream) voice_cmd = audio.transcribe(mic_stream) perception_package = { "visual": scene_frame, "audio": voice_cmd, "timestamp": current_time() }

这里的核心矛盾是实时性和精度。视觉感知如果跑在边缘设备上，模型就不能太大；如果跑在云端，又要考虑网络延迟。通常做法是：感知层做轻量级预筛选，复杂理解交给第二层。

5. 第二层：情境理解层

感知层输出的是“是什么”，情境理解层回答的是“发生了什么”。

同样是识别到一个人在挥手，在路边挥手可能是打车，在停车场挥手可能是求助，在室内挥手可能是打招呼。感知层只能告诉你“检测到人体+手部动作”，情境理解层需要结合周边环境、时间、人物身份来判断到底发生了什么。

5.1 情境理解的关键技术

多模态融合：把视觉、语音、文本、位置信息对齐到同一个时空坐标
场景图生成：输出“人-物-关系”的结构化描述
时序建模：判断动作变化和行为趋势
环境状态建模：光照、天气、动态障碍物等

当前最主流的实现方式是使用多模态大模型。把感知层的输出整理成结构化的提示词，让大模型生成一个场景描述，再传给认知层。这种方法的好处是灵活、不需要针对每个场景单独训练模型。

# 情境理解层示例 from multimodal_llm import SceneReasoner scene_reasoner = SceneReasoner(model_name="qwen-vl") prompt = f""" 根据以下感知数据，描述当前场景： - 视觉信息: {perception_package["visual"]} - 语音信息: {perception_package["audio"]} - 位置: 室内咖啡厅前台 - 时间: 上午10点 请输出： 1. 当前场景类型 2. 正在发生的事件 3. 可能的风险或问题 """ scene_understanding = scene_reasoner.generate(prompt)

5.2 情境理解层落地难点

这一层最大的坑是上下文窗口限制。感知层的数据量通常很大，一段5分钟的视频如果抽帧，可能有300帧图片。全部塞给大模型不现实。需要做关键帧筛选、摘要提取、时间窗口滑动。

工程上建议：不要试图让第二层“看全部”，而是让第一层先做任务导向的信息提取，把最重要的前N个目标、轨迹、事件送到第二层。多模态大模型只做“理解摘要”，不做“全量检索”。

6. 第三层：认知推理层

情境理解层告诉你“发生了什么”，认知推理层告诉你“这意味着什么”。

这一层是六层框架和大语言模型结合最紧密的地方。系统需要基于场景理解，结合目标、规则、历史经验，推导出当前状态对用户的意义，以及有哪些潜在的处理方向。

6.1 认知层的核心能力

意图识别：用户真正想要什么
风险判断：当前场景是否存在危险
知识检索：结合专业领域知识
多步推理：从现状推导出后续可能的发展

这里 RAG（检索增强生成）非常有用。因为大模型的参数化知识更新慢，无法覆盖特定场景的专有信息。通过 RAG 把企业知识库、历史案例、操作手册接进来，认知层才能给出有依据的推理结果。

# 认知推理层配合 RAG 示例 from rag import KnowledgeBase from llm import ChatModel kb = KnowledgeBase(vector_store="chroma", index="operation_manual") llm = ChatModel(model_name="qwen-plus") def reason(scene_understanding): relevant_docs = kb.search(scene_understanding, top_k=5) prompt = f""" 场景描述: {scene_understanding} 参考资料: {relevant_docs} 当前任务: 判断用户意图并评估风险等级。 请输出: 1. 用户意图 2. 风险等级（高/中/低） 3. 建议处理方向 """ return llm.generate(prompt)

认知层还必须具备“拒绝行动”的能力。如果场景信息不足，或者风险过高，认知层应该输出“建议不行动”，而不是硬着头皮给一个决策。这是以人为本AI和纯自动化系统的根本区别：机器要懂得说“我不确定，需要更多信息”。

7. 第四层：决策规划层

决策规划层的输入是认知推理的结果，输出是可执行的任务序列。这一层决定了AI“做什么、先做什么、后做什么”。

这一层本质上就是当前最热的 AI Agent 要解决的问题。Agent 框架里的规划模块，负责把一个大目标拆解成多个子任务，并决定调用哪些工具来完成每个子任务。

7.1 决策层常用策略

策略	适用场景	特点
规则引擎	流程固定、约束明确	可解释性强，但缺乏灵活性
思维链规划	常识推理、开放任务	灵活，但token消耗大
Tree of Thought	需要搜索多条路径	效果更好，计算成本高
强化学习	动态环境、长期收益	需要大量训练和仿真环境
混合策略	生产环境	规则兜底 + Agent决策

7.2 决策层要输出什么

决策层不能只输出一个“最终动作”，它需要输出一个完整的行动计划，包含：

目标拆解：例如“拿一杯水”拆解为“移动到桌子->识别水杯->判断水杯是否可用->抓取->移动到用户位置->递出水杯”
每个步骤的预期结果
每个步骤的备选方案
终止条件

{ "task": "为用户递上一杯水", "steps": [ {"action": "navigate", "target": "table_zone", "success_check": "到达桌子区域"}, {"action": "detect_cup", "target": "桌面", "success_check": "检测到可用水杯"}, {"action": "grasp", "target": "水杯", "success_check": "水杯被成功抓取"}, {"action": "navigate", "target": "user_position", "success_check": "到达用户面前"}, {"action": "hand_over", "target": "用户", "success_check": "水杯被用户接收"} ], "fallback": "任意一步失败则请求用户重新确认需求", "abort_condition": "用户明确表示不需要时立即停止" }

决策层设计得好不好，直接决定系统在真实环境中是否可用。很多AI项目给人“智障”的感觉，不是感知问题，也不是模型问题，而是决策规划层只做了“单步反应”，没有做“任务拆解”。

8. 第五层：执行行动层

行动层是六层框架里最容易理解，也最容易低估的一层。它的任务是把决策规划层输出的任务序列，变成真实世界的动作。

8.1 行动层对接对象

软件系统：调用API接口、数据库操作、发送消息、操作浏览器、执行Python脚本
硬件系统：机械臂控制、移动底盘、无人机飞控、灯光控制、屏幕显示
文本动作：生成回复、撰写报告、发送邮件
自动化流水线：触发CI/CD、调度数据处理任务、启动训练任务

行动层需要一套统一的接口协议。决策层输出的是语义化的动作描述，行动层要把这些描述翻译成具体的函数调用。这里推荐使用 Function Calling 的方式，让大模型从预定义函数列表中挑选合适的函数来执行。

# 行动层函数调用示例 actions = { "navigate": robot_control.move_to, "grasp": arm_control.grasp_object, "send_message": messaging_service.send, "generate_report": report_writer.run, "start_batch_task": task_scheduler.submit } def execute(plan_step): action_name = plan_step["action"] target = plan_step["target"] if action_name in actions: result = actions[action_name](target) return {"success": True, "result": result} else: return {"success": False, "error": f"未知动作: {action_name}"}

8.2 行动层的关键设计

超时处理：每个动作必须设置超时阈值，机械臂卡死、API无响应都不能无限等待
重试机制：网络抖动导致的失败可以重试，机械故障不能盲目重试
安全检查：执行前检查当前状态是否满足安全条件
可中断性：用户随时可以叫停AI的执行动作

行动层是六层中唯一直接与现实物理世界交互的层级，这里的可靠性要求往往比模型精度重要得多。

9. 第六层：连接反馈层

最后一层是一个闭环系统的关键：反馈。没有反馈层的AI系统，本质上只是“一次性指令执行器”，它不是“学习型系统”。

9.1 反馈层要做什么

结果评估：行动是否达到了预期目标
误差归因：失败是感知层问题、决策层问题还是行动层问题
数据回流：把失败案例和成功案例存入经验库
模型更新：定期用新数据微调感知模型或更新RAG知识库
行为优化：调整决策策略，避免同样的错误

# 反馈与复盘示例 def feedback_loop(task_plan, execution_results, final_status): evaluation = { "task_id": task_plan["task"], "status": final_status, "step_success": [execution_results], "error_layer": identify_failure_layer(execution_results), "improvement": generate_corrective_suggestion(task_plan, execution_results) } save_to_experience_base(evaluation) return evaluation

9.2 反馈层设计的最优实践

这一层最容易被开发团队忽略，因为在演示Demo时，只要感知、决策、行动三层跑通，效果看起来就够了。但在生产环境中，没有反馈闭环的系统会越来越差，有反馈闭环的系统会越来越好。

具体落地时，反馈层不一定需要在线自动更新模型——这很危险。更稳妥的方式是：先记录数据、做离线评估，由人工确认后再启动训练任务。

10. 技术选型与实现思路

了解了六层框架后，就要思考如何为每一层选择具体技术。

10.1 感知层

视觉模型：YOLOv8、RT-DETR、Grounding DINO、BEVFormer
语音模型：Whisper、SenseVoice、FunASR
OCR模型：PaddleOCR、RapidOCR
点云模型：PointPillars、CenterPoint

10.2 情境理解层

多模态大模型：Qwen-VL、LLaVA、InternVL
视频理解：Video-LLaVA、TimeSformer
场景图生成：Scene Graph Generation模型

10.3 认知推理层

大语言模型：Qwen、DeepSeek、ChatGLM、Llama系列
RAG框架：LangChain、LlamaIndex、Dify、FastGPT
向量数据库：Chroma、Milvus、Qdrant、pgvector

10.4 决策规划层

Agent框架：LangGraph、AutoGen、MetaGPT、CrewAI
流程编排：n8n、Dify工作流、Airflow
规则引擎：Drools

10.5 行动层

机器人控制：ROS 2、MoveIt
API集成：Requests、httpx、FastAPI
浏览器自动化：Playwright、Selenium
任务调度：Celery、Arq、APScheduler

10.6 连接反馈层

数据存储：PostgreSQL、MongoDB、ClickHouse
向量记忆：Chroma、Milvus
监控：Prometheus + Grafana
A/B测试：自建实验平台

这一整套选型并不是固定答案。不同团队、不同项目可以灵活替换，但层与层之间的接口边界要保持稳定。

11. 本地部署与工程化落地

六层框架不是只能在大厂超大算力平台上运行。相反，它的每一层都可以独立部署、独立扩展。下面给出一套适合中小团队落地的工程思路。

11.1 最小可运行架构

# 目录结构示例 human-centric-ai/ ├── layers/ │ ├── perception/ # 感知层服务 │ ├── context/ # 情境理解服务 │ ├── cognition/ # 认知推理服务 │ ├── decision/ # 决策规划服务 │ ├── action/ # 行动执行服务 │ └── feedback/ # 反馈评估服务 ├── api/ │ ├── main.py # FastAPI 主入口 │ └── routers/ ├── models/ # 模型权重目录 ├── configs/ # 配置文件 ├── data/ │ ├── inputs/ # 输入素材 │ ├── outputs/ # 输出结果 │ └── logs/ # 运行日志 └── docker-compose.yml

11.2 启动方式

每一层都可以是一个独立的FastAPI服务。以感知层为例：

# api/main.py from fastapi import FastAPI from layers.perception import perception_router from layers.decision import decision_router app = FastAPI(title="Human-Centric AI Framework") app.include_router(perception_router, prefix="/perception") app.include_router(decision_router, prefix="/decision")

逐个起服务：

# 启动感知层服务 uvicorn layers.perception:app --host 0.0.0.0 --port 8011 # 启动认知层服务 uvicorn layers.cognition:app --host 0.0.0.0 --port 8013 # 启动行动层服务 uvicorn layers.action:app --host 0.0.0.0 --port 8015

如果只是想做一个最小验证，可以用Docker Compose统一编排：

version: "3.8" services: perception: build: ./layers/perception ports: - "8011:8011" cognition: build: ./layers/cognition ports: - "8013:8013" decision: build: ./layers/decision ports: - "8014:8014"

11.3 环境准备

基础环境需要准备：

操作系统：Ubuntu 20.04 / 22.04 或 Windows 11（WSL2）
Python 3.10+
CUDA 11.8+（如果使用GPU推理）
Docker（用于容器化部署）
模型权重文件（根据选择的模型下载）

如果没有GPU，CPU也能跑最小演示，但感知层和处理速度会明显变慢。生产环境建议至少8GB显存的GPU，具体取决于模型中尺寸和并发量。

12. 测试验证方法与效果评估

六层框架的测试不能只做端到端联调，每一层都要有独立的验证标准。

12.1 感知层测试

测试项	测试方法	通过标准
目标检测	给不同光照、角度、遮挡程度的图片	同类目标正确识别率达标
BEV感知	用多视角图像生成鸟瞰图	目标位置误差在可接受范围
语音识别	测试不同口音、噪声环境	字错误率低于阈值

感知层测试数据要覆盖极端情况：夜晚、强光、暴雨、逆光。感知层在正常条件下表现好不算好，在恶劣天气下依然可靠才是关键。

12.2 决策层测试

决策层测试可以分三类：

规则类：给定明确场景，判断输出任务序列是否符合人工预期
推理类：给定模糊场景，判断系统是否主动请求更多信息而不是莽撞决策
安全类：给定危险场景，判断系统是否做出安全优先的决策

# 决策层测试示例命令 python test_decision.py \ --case "用户在厨房说想喝水" \ --expected "先确认水杯位置，再执行取水流程" \ --check_safety true

12.3 端到端测试

端到端测试的目标是验证闭环链路：感知→理解→认知→决策→行动→反馈。建议用模拟环境先跑通，再上真实物理环境。

测试时要记录每个环节的耗时、失败率、错误类型，用于分析瓶颈。比如一个任务端到端耗时2秒，其中感知占0.5秒，推理占1.2秒，行动占0.3秒，那优化重点就在认知推理层。

13. 资源占用与性能观察

用这套框架搭建系统后，性能观察主要看四类指标：

13.1 各层服务耗时

层级	耗时占比	优化方向
感知层	中等	模型轻量化、帧率控制、边缘计算
情境理解层	高	多模态模型裁剪、摘要长度控制
认知推理层	高	减少无关RAG检索、限制输出长度
行动层	低（软件）/ 高（硬件）	接口缓存、并发控制、硬件优化

13.2 显存与内存占用

观察方法：

# GPU 实时显存占用 nvidia-smi -l 1 # 内存占用 htop

显存占用和具体模型强相关，无法通用于所有系统。需要以实际模型版本和推理参数为准。降低显存占用的通用思路：

使用量化版本模型（如 INT8、FP16）
限制上下文长度
减少并发数
使用流式输出替代一次性生成

13.3 并发与批量任务

行动层是批量任务最直接的入口。比如一个内容生成系统，可以同时启动多个行动任务：

from celery import Celery app = Celery("action_tasks", broker="redis://localhost:6379/0") @app.task def process_action(plan_step): result = execute(plan_step) return result

批量任务要设计好队列、失败重试、超时处理和结果回收。建议每个任务都带上唯一ID，方便追踪链路。

14. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
系统“看到了”目标但没有任何行动	决策层未生成行动计划	检查认知层输出结果、决策层日志	给决策层补充明确的任务目标和规则
行动执行力与决策不一致	行动层函数映射错误	检查函数调用日志	核对函数命名和参数映射
感知层偶尔返回空结果	画面模糊、光线不足、模型阈值过高	查看感知层原始输出	调整置信度阈值，增加低光增强模型
推理耗时过长	大模型输出太长、RAG检索太多	查看各层耗时分布	限制输出长度、优化向量索引
批量任务积压	行动层并发上限太低	检查任务队列长度	增加Worker数，优化任务拆解粒度
反馈数据无法回流	日志没有结构化	检查日志字段	统一JSON日志格式，写入数据仓库
模型升级后效果退步	感知/推理版本不匹配	检查模型版本和输出格式	做好模型版本兼容测试
API 调用超时	服务资源不足或网络阻塞	查看API响应日志	增加超时时间、升级服务配额、增加缓存

15. 最佳实践与合规边界

既然是“以人为本”，这层边界必须单独说清楚。

从技术实践角度，有以下几条建议：

先做最小闭环，再扩展能力。不要同时做六层的高精度版本，先用廉价模型把循环跑通。
每一层都要有自己的评估集。没有评估集的层，在真实环境里就是黑盒。
接口要稳定，模型要可替换。感知层换了模型，后面的层不应该感知到变化。
反馈闭环初期不要自动更新模型。先用人工审核数据，再定期离线训练。
日志和数据必须结构化存储，这是后续优化和问题追踪的基础。

从合规和伦理边界来看，涉及真实人脸、声音、位置、行为数据的项目，必须遵守以下红线：

采集用户数据前必须获得明确授权，并遵循最小必要原则
涉及人脸识别、行为分析的系统，要评估是否触犯隐私保护相关规定
行动层涉及机械控制、自动驾驶等场景，必须通过安全测试和备案流程才能上线
任何使用AI生成内容、克隆音色、生成虚拟形象的功能，只能在取得权利人授权后用于指定场景
系统必须具备人工接管和紧急停止机制，不能完全脱离人控制

AI系统的能力边界应该由人来定义，而不是由模型自己摸索。这也是“以人为本”四个字在工程上的真实含义。

16. 总结与下一步

六层连接框架最大的价值，是为AI系统设计提供了一个可拆解、可评估、可追溯的结构。它把“感知-行动”的宏大话题分解成了六个边界清晰的工程问题：如何感知、如何理解、如何推理、如何决策、如何执行、如何反馈。每一层都能独立优化，每一层都能单独测试，断点可以被快速定位。

拿到这套框架后，建议先做三件事：

第一，画出你自己项目的“六层现状图”，标清楚哪些层已经存在，哪些层是空的，哪些层之间是断的。

第二，找一个最简单的任务，用最小模型把六层全部打通，哪怕效果粗糙也没关系，先让数据流完整地走一遍。

第三，给每一层建立一个评估指标和日志记录，让系统有“可解释的失败”。

最容易踩的坑是：试图一次性把每一层都做到完美。正确的做法是让每一层先达到及格线，然后根据真实场景的失效模式，把资源集中投入最薄弱的一层。

这套框架未来的扩展方向也很清晰：感知层可以接入更多传感器，决策层可以引入强化学习做长期规划，反馈层可以发展成完整的AutoML训练管线。但底座始终是那六个稳定的接口。

建议把框架图收藏起来，做AI系统设计之前先对照一遍，会比直接调模型有用得多。