“以人为本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_typebev_transformer) audio AudioPerception(model_typewhisper) 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_nameqwen-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_storechroma, indexoperation_manual) llm ChatModel(model_nameqwen-plus) def reason(scene_understanding): relevant_docs kb.search(scene_understanding, top_k5) 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 evaluation9.2 反馈层设计的最优实践这一层最容易被开发团队忽略因为在演示Demo时只要感知、决策、行动三层跑通效果看起来就够了。但在生产环境中没有反馈闭环的系统会越来越差有反馈闭环的系统会越来越好。具体落地时反馈层不一定需要在线自动更新模型——这很危险。更稳妥的方式是先记录数据、做离线评估由人工确认后再启动训练任务。10. 技术选型与实现思路了解了六层框架后就要思考如何为每一层选择具体技术。10.1 感知层视觉模型YOLOv8、RT-DETR、Grounding DINO、BEVFormer语音模型Whisper、SenseVoice、FunASROCR模型PaddleOCR、RapidOCR点云模型PointPillars、CenterPoint10.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、pgvector10.4 决策规划层Agent框架LangGraph、AutoGen、MetaGPT、CrewAI流程编排n8n、Dify工作流、Airflow规则引擎Drools10.5 行动层机器人控制ROS 2、MoveItAPI集成Requests、httpx、FastAPI浏览器自动化Playwright、Selenium任务调度Celery、Arq、APScheduler10.6 连接反馈层数据存储PostgreSQL、MongoDB、ClickHouse向量记忆Chroma、Milvus监控Prometheus GrafanaA/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.yml11.2 启动方式每一层都可以是一个独立的FastAPI服务。以感知层为例# api/main.py from fastapi import FastAPI from layers.perception import perception_router from layers.decision import decision_router app FastAPI(titleHuman-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:801411.3 环境准备基础环境需要准备操作系统Ubuntu 20.04 / 22.04 或 Windows 11WSL2Python 3.10CUDA 11.8如果使用GPU推理Docker用于容器化部署模型权重文件根据选择的模型下载如果没有GPUCPU也能跑最小演示但感知层和处理速度会明显变慢。生产环境建议至少8GB显存的GPU具体取决于模型中尺寸和并发量。12. 测试验证方法与效果评估六层框架的测试不能只做端到端联调每一层都要有独立的验证标准。12.1 感知层测试测试项测试方法通过标准目标检测给不同光照、角度、遮挡程度的图片同类目标正确识别率达标BEV感知用多视角图像生成鸟瞰图目标位置误差在可接受范围语音识别测试不同口音、噪声环境字错误率低于阈值感知层测试数据要覆盖极端情况夜晚、强光、暴雨、逆光。感知层在正常条件下表现好不算好在恶劣天气下依然可靠才是关键。12.2 决策层测试决策层测试可以分三类规则类给定明确场景判断输出任务序列是否符合人工预期推理类给定模糊场景判断系统是否主动请求更多信息而不是莽撞决策安全类给定危险场景判断系统是否做出安全优先的决策# 决策层测试示例命令 python test_decision.py \ --case 用户在厨房说想喝水 \ --expected 先确认水杯位置再执行取水流程 \ --check_safety true12.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, brokerredis://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系统设计之前先对照一遍会比直接调模型有用得多。