
具身AI是AGI的核心系统范式,将智能从网络空间扩展到物理实体,是认知科学与神经科学的产物。LLMs和WMs的突破为具身AI注入活力:LLMs通过语义推理和任务分解,提供高层自然语言指令与低层动作序列,支持具身认知;WMs通过构建外部世界的内部表示和未来预测,确保交互符合物理定律。论文系统综述具身AI的历史、技术组件、硬件系统,从单模态到多模态视角剖析发展。重点探讨LLMs/多模态LLMs(MLLMs)和WMs在端到端具身认知及物理驱动交互中的应用,提出联合MLLM-WM架构以应对复杂物理任务。同时,考察服务机器人、救援无人机(UAV)和工业机器人等应用领域,并展望未来方向。该文为具身AI研究提供全面文献指南,推动从专化代理向通用物理智能演进。
引言追溯具身AI起源至1950年图灵的“具身图灵测试”,强调智能源于感知-认知-交互的动态耦合,而非抽象计算。具身AI区别于无身AI(网络空间问题求解),聚焦物理世界交互,受认知科学启发,认为智能嵌入身体与环境。核心组件包括:
硬件具身不可或缺,受实时延迟和功耗约束。发展从单模态(视觉/语言主导)向多模态演进,后者融合多源信息,提升适应性。LLMs赋能高层语义(e.g., SayCan任务分解),MLLMs桥接多模态输入与动作(e.g., RT-2),WMs提供物理预测(e.g., Dreamer-v3)。然而,MLLMs忽略物理约束,WMs缺乏语义推理。论文提出联合架构(如EvoAgent),桥接二者,实现自主长时序任务。结构概述:基础(II)、LLMs驱动(III)、WMs驱动(IV)、联合架构(V)、应用(VI)和未来(VII)。
论文结构清晰(如图2所示),分为七大节,逻辑从基础到前沿、从语义到物理融合。
Section II: 具身AI基础
Section III: LLMs/MLLMs驱动具身AI
Section IV: WMs驱动具身AI
Section V: 联合MLLM-WM架构
Section VI: 应用
Section VII: 未来方向
论文核心是具身AI的“语义-物理”融合演进路径:
论文为综述,无原创实验,但引用基准评估:
结论重申联合MLLM-WM架构将主导具身系统,桥接语义智能与物理交互,实现从专化到通用的跃迁。未来需聚焦自主性、可信性和群体协作,推动AGI落地。
主要贡献:
创新点:首次系统剖析LLMs到WMs的演进路径,强调多模态闭环与硬件协同;为研究者提供蓝图,适用于服务/工业场景。该文长度约20页,图表丰富(e.g., 架构图、比较表),适合Embodied AI入门与前沿追踪。
(资料和图片来源:arxiv.org)

4 个月前
答案不是简单地增加人手,而是将AI植入敏捷的DNA,构建“数据智能混合驱动”的敏捷2.0。

1 年前
具身智能(Embodied AI)的发展,究竟是科技革命的前奏,还是资本驱动的泡沫,取决于多个因素,包括技术进步的速度、市场应用的成熟度、以及资本市场的耐心和理性。我们可以从以下几个方面来分析这一问题: 1. 技术进步的现实性:具身智能是否具备突破性的能力? 具身智能的核心在于将人工智能与物理世界交互能力结合起来,使AI不仅能“思考”,还能“行动”。近年来,随着计算机视觉、强化学习、机器人技术、传感器等领域的突破,具身智能的基础技术正在逐步成熟。例如: 波士顿动力的机器人已经展现出稳定的运动能力; OpenAI 和 DeepMind 的AI代理在虚拟环境中学习复杂的操作技能; 具身智能在制造、物流、医疗、服务等领域的应用场景不断拓展。 但与此同时,现实中的具身智能仍然面临许多挑战,例如: 数据与学习效率问题:现有的强化学习和自监督学习方法仍然需要大量数据和计算资源,而具身智能的学习环境比纯软件环境更复杂。 硬件限制:机器人硬件的成本高昂,电池续航、灵活性、感知能力仍是瓶颈。 泛化能力不足:当前的具身智能系统难以从一个任务或环境泛化到另一个任务或环境,仍需大量的微调和训练。 2. 市场应用的成熟度:是否真的解决了实际问题? 从市场角度来看,具身智能的潜在应用场景广泛,包括: 自动化制造(如智能机器人协作装配线); 智能物流(如亚马逊仓库机器人、无人配送); 医疗护理(如康复机器人、护理助手); 服务行业(如智能客服、餐饮服务机器人)。 然而,目前真正实现大规模商业化的案例仍然有限,许多应用仍停留在试验阶段。这说明具身智能尚未完全进入成熟期,而是处于早期探索阶段。 3. 资本市场的推动:是否存在泡沫? 近年来,随着AI行业的爆发,资本对具身智能的关注度大幅提升。例如: 特斯拉Optimus(擎天柱)人形机器人,马斯克宣称其将在工厂和家庭场景落地; Agility Robotics、Figure AI、Sanctuary AI 等创业公司获得巨额投资,致力于人形机器人研发; 苹果、谷歌、亚马逊等科技巨头也在加强在具身智能上的布局。 但资本市场的热情有时会过度夸大技术的短期进展。例如,许多机器人公司在资本涌入后,最终因商业模式不清晰而失败。市场泡沫的风险在于,如果技术落地速度跟不上预期,资本会快速撤离,导致行业短期震荡。 结论:是科技革命的前奏,还是泡沫? 关于具身智能浪潮是否为科技革命的前奏或是资本驱动的泡沫,业内存在多种观点,目前尚无定论。 科技革命的前奏 技术进步加速:近年来,机器人技术、计算机视觉、传感器以及人工智能算法的飞速发展,为实现真正具身智能奠定了坚实的基础。 跨学科融合:认知科学、神经科学与机器学习的交叉研究不断推进,使得具身智能不仅在理论上,更在实践上显示出革命性的潜力。 应用场景拓展:从自动驾驶、服务机器人到工业自动化,具身智能的实际应用前景广阔,可能引发生产方式和生活方式的深刻变革。 资本驱动的泡沫风险 市场炒作:部分资本可能会过度高估技术的短期成熟度和市场前景,导致投资热潮和估值泡沫。 技术壁垒与实现难度:尽管技术进步迅速,但真正具备自主决策、实时感知和复杂环境适应能力的具身智能系统仍面临众多挑战,短期内或难以完全兑现预期。 政策与伦理问题:在技术推广过程中,监管、伦理以及安全等方面的挑战也可能限制技术的广泛落地和产业化速度。 长期来看,具身智能是科技革命的前奏: 技术的进步是不可逆的,随着深度学习、强化学习、机器人技术、计算能力的提升,具身智能的能力会逐步增强,并最终改变产业格局。 短期来看,具身智能市场可能存在资本泡沫: 一些过度炒作的概念和未成熟的商业模式可能导致泡沫破裂,但这不会影响技术的长期发展趋势。 换句话说,具身智能的“科技革命”是确定的,但短期内的泡沫和市场震荡也难以避免。真正的突破可能需要 5-10 年甚至更长的时间,但当技术、市场和资本形成合力时,它将真正迎来大规模应用。

1 年前
德国人工智能研究的高校重镇 德国作为工业强国,在人工智能领域也具有深厚的底蕴和领先地位。众多德国高校在AI研究方面投入了大量资源,取得了丰硕成果。

21 天前
AiPPT: 一句话、一分钟、一键搞定

28 天前
Ralph 就是一个让 AI "自己干活直到做完"的循环机制,特别适合复杂的编程任务,解放人力。这里介绍具体怎么搭建和使用 Ralph 循环。 📋 前置准备 你需要准备以下内容: 工具 用途 Claude Code Anthropic 的 AI 编程助手 CLI Docker Desktop 提供隔离的沙盒环境 Anthropic API Key 调用 Claude API 🛠️ 搭建步骤 方法一:使用 Claude Code 插件(推荐) Step 1: 安装 Claude Code # 安装 Claude Code CLI npm install -g @anthropic-ai/claude-code Step 2: 初始化项目 mkdir my-ralph-project cd my-ralph-project claude init Step 3: 添加插件市场 claude plugins add-marketplace Step 4: 安装 Ralph Wiggum 插件 claude plugins install ralph-wiggum Step 5: 配置 Stop Hook 在 .claude/hooks/ 目录下创建 stop-hook.json: { "hook_type": "stop", "decision": "block", "conditions": { "check_tests": true, "check_type_errors": true, "check_git_changes": true }, "max_iterations": 20, "prompt": "任务未完成,请继续迭代修复问题" } 方法二:手动搭建(完全控制) Step 1: 创建项目结构 my-ralph-project/ ├── .claude/ │ ├── hooks/ │ │ └── stop-hook.sh │ ├── skills/ │ │ └── ralph-loop.json │ └── config.json ├── prd/ │ └── requirements.json └── workspace/ Step 2: 配置核心文件 config.json - 核心配置 { "max_iterations": 15, "auto_commit": true, "run_tests_after_each_iteration": true, "stop_conditions": { "all_tests_pass": true, "no_type_errors": true, "prd_completed": true } } skills/ralph-loop.json - 技能定义 { "name": "ralph-loop", "description": "自主迭代循环实现 PRD 任务", "trigger": "when_task_incomplete", "actions": [ "analyze_current_state", "identify_blockers", "fix_issues", "run_tests", "commit_if_passing" ] } hooks/stop-hook.sh - Stop Hook 脚本 #!/bin/bash # 检查测试是否通过 TESTS_PASS=$(npm test 2>&1 | grep -c "passed") # 检查是否有类型错误 TYPE_ERRORS=$(npx tsc --noEmit 2>&1 | grep -c "error") # 检查 PRD 是否完成 PRD_COMPLETE=$(node check-prd.js) if [ "$TESTS_PASS" -eq 0 ] || [ "$TYPE_ERRORS" -gt 0 ] || [ "$PRD_COMPLETE" = "false" ]; then echo "BLOCK: 任务未完成,继续迭代" exit 1 else echo "ALLOW: 任务已完成" exit 0 fi Step 3: 准备 PRD 文件 prd/requirements.json { "project_name": "My Feature", "tasks": [ { "id": 1, "description": "创建用户登录页面", "criteria": ["表单验证正常", "API 调用成功", "错误处理完善"], "status": "pending" }, { "id": 2, "description": "实现用户注册功能", "criteria": ["邮箱验证", "密码强度检查", "重复密码确认"], "status": "pending" } ] } 🚀 使用方法 启动 RALPH 循环 # 方法一:插件方式 claude run --skill ralph-loop --prd ./prd/requirements.json # 方法二:Docker 隔离环境 docker run -it \ -v $(pwd):/workspace \ -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \ claude-ralph:latest 监控循环状态 # 查看当前迭代次数 cat .ralph/iteration_count # 查看任务完成状态 cat .ralph/task_status.json # 查看日志 tail -f .ralph/loop.log 🔧 高级配置 1. 自定义 Stop Hook 规则 { "stop_conditions": { "all_tests_pass": { "enabled": true, "command": "npm test", "success_pattern": "all tests passed" }, "no_lint_errors": { "enabled": true, "command": "npm run lint", "success_pattern": "no problems" }, "coverage_threshold": { "enabled": true, "threshold": 80 } } } 2. 添加代码审查步骤 { "after_each_iteration": [ "run_tests", "run_linter", "code_review", "commit_if_passing" ], "code_review_prompt": "审查代码质量、安全性、性能问题" } 3. 设置成本控制 { "cost_limits": { "max_tokens_per_iteration": 50000, "max_total_cost": 50, "alert_at_cost": 30 } } 📊 典型工作流程 ┌─────────────────────────────────────────────┐ │ 1. Claude 读取 PRD 任务列表 │ └─────────────────┬───────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ 2. 选择下一个待完成任务 │ └─────────────────┬───────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ 3. 实现代码、编写测试 │ └─────────────────┬───────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ 4. 运行测试套件 │ └─────────────────┬───────────────────────────┘ ↓ ┌─────────────────────────────────────────────┐ │ 5. Stop Hook 检查是否完成 │ │ • 测试通过? │ │ • 无类型错误? │ │ • PRD 要求满足? │ └─────────────────┬───────────────────────────┘ ↓ ┌───────┴───────┐ ↓ ↓ 未完成 完成 ↓ ↓ 返回步骤 2 结束循环 💡 最佳实践 建议 说明 PRD 要清晰 任务描述具体、可验证,避免模糊需求 设置最大迭代 防止无限循环消耗过多成本 使用 Docker 隔离环境,避免污染本地系统 定期检查 每 10 轮查看一次进度和日志 成本监控 设置预算警报,避免超支 ⚠️ 注意事项 成本控制:每次迭代消耗 tokens,长时间运行成本较高 质量检查:AI 可能"认为"完成但实际有 bug,需要严格测试 安全边界:在沙盒环境运行,避免 AI 误删重要文件 人工介入:复杂任务仍需人工审查结果

28 天前
Ralph Loop 是一种让 AI 自主迭代的机制,主要用于解决 AI 编程助手"半途而废"的问题。

1 个月前
OpenClaw 本质是“开发者基础设施”,而非面向大众的 SaaS 产品。

2 个月前
用 OpenClaw 搭建一个本地 Agent 中枢(完整方案) 不是再做一个 ChatGPT,而是建立一个真正“可控、可组合、可扩展”的本地 AI Agent 中枢。 当越来越多团队开始意识到: 云端 LLM 成本不可控 数据隐私存在风险 单一 Agent 无法解决真实业务 “本地 Agent 中枢” 正在成为一个更现实的选择。 本文将完整讲清楚: 👉 如何用 OpenClaw 搭建一个真正可用的本地 Agent 中枢 👉 它适合谁,不适合谁 👉 与 LangGraph / CrewAI 的核心差异 什么是「本地 Agent 中枢」? 先明确一个概念,避免误解。 ❌ 不是: 一个本地 ChatGPT 一个简单的 Prompt 管理器 ✅ 而是: 一个能够统一管理多个 Agent、模型、工具和任务流程的本地系统 一个合格的本地 Agent 中枢,至少要解决 5 件事: 多 Agent 协作(不是单轮对话) 任务调度与状态管理 模型可替换(本地 / API) 工具调用(搜索、代码、文件等) 可长期运行、可追溯 OpenClaw 的定位,正是这个“中枢层”。 为什么选择 OpenClaw? 在进入部署前,必须先回答一个现实问题: 为什么不是 LangGraph / CrewAI / AutoGen? 简要结论(非常重要) 框架 更适合 LangGraph 开发者写 Agent 流程 CrewAI 小规模角色协作 AutoGen 对话驱动实验 OpenClaw 长期运行的 Agent 中枢 OpenClaw 的核心优势 1️⃣ 架构清晰,不是“脚本拼装” 有明确的 Agent 管理层 有任务执行与状态机制 不是写完一次就丢的 Demo 2️⃣ 原生支持多模型策略 本地模型 云 API fallback / 优先级策略 3️⃣ 更接近“生产环境思维” 可持续运行 可复用 Agent 可演进 如果你的目标是: “做一个长期使用的 AI 中枢,而不是一段实验代码” 那 OpenClaw 是目前更合理的选择之一。 整体架构:OpenClaw 本地 Agent 中枢怎么搭? 这是一个最小可用但可扩展的架构方案。 🧩 架构拆解 ┌─────────────────────────┐ │ 用户 / 系统 │ └──────────┬──────────────┘ │ ┌──────────▼──────────┐ │ OpenClaw 中枢层 │ │ - Agent Registry │ │ - Task Orchestrator│ │ - Memory / State │ └──────────┬──────────┘ │ ┌─────────▼─────────┐ │ Agent 集群 │ │ - Research Agent │ │ - Coding Agent │ │ - Planning Agent │ │ - Tool Agent │ └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ 模型 & 工具层 │ │ - 本地 LLM │ │ - API LLM │ │ - Search / FS / DB │ └───────────────────┘ 部署准备(实战级) 1️⃣ 基础环境 推荐环境(已验证): Linux / WSL / macOS Docker + Docker Compose Python 3.10+ 2️⃣ 模型选择建议(非常现实) 场景 推荐 本地推理 Qwen / LLaMA 稳定输出 GPT / Claude API 混合方案 本地 + API fallback 👉 关键不是模型多,而是“可切换” 核心步骤:搭建 OpenClaw 本地 Agent 中枢 Step 1:部署 OpenClaw 核心 git clone https://github.com/xxx/openclaw cd openclaw docker compose up -d 启动后,你将拥有: Agent 管理入口 任务调度服务 统一配置中心 Step 2:定义你的第一个 Agent 一个 Agent ≠ 一个 Prompt 而是一个职责明确的“角色” 示例: agent: name: research_agent role: 信息调研 model: local_llm tools: - web_search - file_reader 建议起步 Agent: Research Agent(信息收集) Planner Agent(任务拆解) Executor Agent(执行) Step 3:建立 Agent 协作流程 例如一个典型任务: “调研某行业 → 输出分析 → 给出建议” 流程是: Planner 拆解任务 Research Agent 收集信息 Executor Agent 输出结果 中枢保存状态与结果 👉 这一步,才是“中枢”的价值所在 一个真实可用的示例场景 🎯 场景:AI 工具评估中枢 你可以搭一个 Agent 中枢来做: 自动收集 AI 工具信息 对比功能 / 定价 输出结构化报告 长期更新 这类系统: 人工成本极高 用 Agent 非常合适 总结:什么时候该用 OpenClaw? 当你意识到:AI 不再是“一次性回答”,而是“持续协作的系统” 那你就已经走在 OpenClaw 这条路上了。 OpenClaw 不是让你“更快用 AI”,而是让你“真正拥有 AI 能力”。
Minimax(海螺AI)已由大模型名Minimax替换原海螺AI。现海螺AI为Minimax视频生成产品名。
海螺AI