4 天前
西门子Xcelerator开放式数字商业平台作为正式发布生态合作伙伴"繁星计划"，旨在发挥平台网络效应，与生态伙伴共享知识与技术资源，共创面向客户的解决方案，共赢数字化与低碳化新机遇。
10 天前
AI 研发已从单点 Prompt 优化迭代至Harness 工程底座 + Loop 自治闭环 + SDD 标准化规范的三位一体体系，通过重构人机协作模式，解决大模型落地不稳定、难规模化的痛点，实现企业级 AI 从原型试用走向工程化、自动化、体系化落地。
14 天前
WorkBuddy有望拿下国内独立桌面自动化办公智能体细分第一。但受企业协同生态、移动端能力等短板限制，无法成为全域企业及全球办公AI赛道第一名，将与钉钉悟空、WPS AI形成差异化竞争格局。
22 天前
OpenClaw工具与生态完整生命周期判断 本文尝试分短期、中期、长期三段，结合项目现状、风险、护城河客观测算OpenClaw这款智能体工具或者相似工具的发展趋势。 一、短期生命力（1～3年，2026–2029）：完全安全、高速增长，是黄金运营窗口期 支撑理由 赛道刚需独一无二，差异化壁垒极强 OpenClaw是极少数本地系统级执行、模型无关、纯自托管的终端Agent运行框架，定位“能操作电脑文件、软件、桌面的AI助手”，区别于LangGraph/CrewAI这类后端开发框架、AutoGPT纯实验型智能体。普通办公、个人自动化、小微企业没有替代同类成熟开源工具，C端+中小企业需求持续释放。 社区与生态飞轮已经跑通 GitHub 30万+星标、近千名全球持续贡献者，日均数百条PR/Issue迭代，更新频率行业第一；创始人Peter全职维护，大厂（英伟达、Kimi、MiniMax）主动适配接入； ClawHub官方技能仓库沉淀数千标准化Skill，国内衍生生态（xia345、各类中文技能站、私有化二次改版）持续扩容，形成标准锁定； MIT宽松开源协议，允许企业二次改造、搭建托管服务，大量服务商入局完善配套生态（部署、安全加固、私有化定制）。 行业周期红利：本地终端Agent处于普及早期 2026被行业定义为桌面Agent落地元年，云端大模型成本持续下行、本地Ollama离线模型普及，完美匹配OpenClaw“本地优先”架构；未来3年，个人自动化、企业内网办公自动化需求只会扩张。 短期仅有的可控风险 Token调用成本偏高、频繁更新易出现版本兼容bug、本地高权限带来安全隐患； 以上问题官方正在持续迭代修复，企业级备份、权限沙箱、日志审计功能已逐步补齐，属于可优化痛点，不会动摇存续根基。 结论：未来1–3年是生态最繁荣、流量最大、变现最顺畅的阶段。 二、中期生命力（3～7年，2029–2033）：稳定存续，但竞争加剧、增速放缓 存续核心逻辑 标准化生态具备长期锁定效应 SKILL.md、ClawHub统一技能规范、openclaw CLI命令行已经形成行业事实标准。就算出现竞品，开发者、存量数万套技能、企业定制项目迁移成本极高，生态不会短时间崩塌，会维持稳定使用人群。 分层商业模式支撑项目持续维护 原生项目开源免费，但周边商业化闭环成型：企业私有化部署服务、安全审计、托管云服务、垂直行业技能付费、模型渠道分销，持续产生现金流反哺社区开发，不会出现“没人维护停更”的局面。 使用人群分层留存 C端极客、办公自动化爱好者会长期使用； 中小企业内网自动化、数据处理场景高度依赖本地执行Agent，大厂SaaS Agent无法满足内网隐私需求； 开发者持续基于OpenClaw做二次分支、私有化改版，衍生生态会持续分流、延续整个“龙虾生态”的热度。 中期衰减变量（会降低增速，但不会淘汰项目） 微软、苹果、国产操作系统推出原生系统级AI助手，抢占普通小白用户； 新轻量化终端Agent开源框架分流开发者； 各国监管对本地高权限AI自动化工具出台更严格合规要求，提高企业落地门槛； 结论：3–7年不会消亡，但行业从爆发期进入存量竞争，流量红利收窄，平台需要深耕私有化、企业定制、垂直细分赛道才能持续盈利。 三、长期生命力（7年以上，2033之后）：分两种极端走向 走向1：长期持续存活（概率60%），变成基础设施级工具 如果行业发展符合以下趋势，OpenClaw会像现在的Python、Git一样长期存续： 终端自主Agent成为电脑标配生产力工具，本地执行、离线隐私是永久刚需； OpenClaw持续完成企业级、合规化改造，成为政企内网自动化标准选型； 社区形成基金会/商业公司承接维护，摆脱单一创始人依赖，实现长久开源运营。 走向2：逐步边缘化、被新一代架构替代（概率40%） 触发条件： 操作系统底层内置标准化Agent执行层，统一API，第三方独立运行框架失去生存空间； 多模态、具身智能技术迭代，全新架构完全替代“技能+本地脚本执行”模式； 全球监管全面限制本地高权限自主AI工具，商用落地基本锁死，仅小众极客圈子留存。 即便被边缘化，存量存量技能、配套站点、私有部署项目仍会维持5–10年长尾生命周期，不会瞬间彻底消失。 四、关键风险：会大幅缩短生命周期的致命隐患 安全重大事故 若出现大规模Skill供应链投毒、批量本地数据泄露事件，企业端市场会快速萎缩，仅保留个人玩家生态；官方正在完善自动病毒扫描、技能审核机制，风险持续降低。 创始人断更、无承接主体 当前项目由Peter单人主导，若后续精力转移、无商业公司接手维护，迭代速度断崖式下滑，竞争力快速落后竞品；目前已有多家AI服务商、模型厂商深度合作，存在接手预期。 算力成本长期居高不下 如果大模型API按量价格无法大幅下降，普通用户长期使用成本过高，会劝退大众用户，仅留存企业付费群体。 国内政策监管收紧 国内针对本地自主自动化工具出台限制，国内衍生生态、配套导航平台流量大幅下滑，但海外生态不受影响。 五、综合最终总结 0–3年（黄金期）：放心投入建站、填充内容、运营变现，生态高速扩张，流量红利充足； 3–7年（平稳期）：生态稳定存在，竞争变多，需要走差异化（私有化、离线、海外双语）路线维持竞争力； 7年以上（分化期）：要么成为长期基础设施永续存在，要么逐步小众长尾，即便衰退也有数年缓冲时间； 整体安全底线：至少拥有5年以上稳定商业运营周期，足够覆盖站点开发、回本、盈利完整周期；中长期只要避开通用综合赛道，主打本地离线私有化细分，生命周期会进一步拉长。
2 个月前
马斯克旗下 xAI 静默上线 Grok 4.3，API 价格下调约 60%，引发行业连锁降价，大模型商业化进入 “低价普惠” 阶段。
3 个月前
AiPPT: 一句话、一分钟、一键搞定
3 个月前
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 || || ; 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": , "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 误删重要文件 人工介入：复杂任务仍需人工审查结果
3 个月前
Ralph Loop 是一种让 AI 自主迭代的机制，主要用于解决 AI 编程助手"半途而废"的问题。
4 个月前
OpenClaw 本质是“开发者基础设施”，而非面向大众的 SaaS 产品。
5 个月前
用 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 能力”。
5 个月前
Asking User Question Tool（AI智能体版） 这是AI智能体必备的交互式工具，让Agent在执行任务时主动向用户提问、澄清需求、收集信息，避免瞎猜、减少返工、提升准确率。 一、核心定位 本质：Agent的“人在回路”交互接口，让AI在模糊/信息不足时暂停执行，向用户要明确输入。 作用：把“模糊指令→AI瞎做→反复修改”变成“AI提问→用户明确→一次做对”。 常见名称： AskUserQuestion 、 AskUserQuestionTool 、 ask_user_question 。 二、核心工作流（极简） 1. Agent判断信息不足：发现需求模糊、缺少参数、需要决策 2. 调用工具生成结构化问题：单选/多选+自定义输入+说明 3. 用户作答：在聊天/弹窗/终端选择或输入 4. Agent接收答案：解析结构化结果，补全上下文 5. 继续执行任务：基于完整信息推进，不再猜 三、关键能力（标配） 结构化提问：标题+问题+2–4个选项+单选/多选+ Other 自定义输入 上下文澄清：自动追问，直到需求完全明确 结构化返回：输出JSON，方便前端渲染（按钮/表单/弹窗） 人在回路：强制用户确认，避免AI自主决策风险 多轮交互：可连续提问，形成“需求访谈”流程 四、主流实现（你会遇到的版本） Claude Code（Anthropic） 原生内置，最成熟 支持多轮、单选/多选、自定义输入 常用于代码生成、需求梳理 Qwen-Agent（通义千问） 开源工具： qwen_agent/tools/ask_user_question.py 支持参数： question / options / explanations / multiSelect / allowFreeform Spring AI AskUserQuestionTool ，Java生态 模型无关，可对接GPT/Claude/Gemini OpenClaw / EasyClaw 集成到本地智能体，用于任务执行前确认 本地运行，隐私优先 五、典型使用场景（高频） 需求澄清：“做一个登录页”→AI问：技术栈？风格？是否第三方登录？ 偏好收集：“写报告”→AI问：正式/ casual？长度？受众？ 决策点确认：“部署服务”→AI问：云厂商？实例规格？环境？ 复杂任务拆解：多轮提问，把模糊需求变成可执行步骤 六、与普通聊天的区别 普通聊天：用户主动说，AI被动答；信息靠用户自己补全 AskUserQuestion：AI主动问、结构化问、按任务节点问；用户只需点选/填空，效率高、歧义少 七、为什么要用（价值） 减少返工：一次做对，节省时间与Token 提升准确率：AI不瞎猜，结果更贴合需求 降低门槛：用户不用写长Prompt，点选即可 安全可控：关键决策必须用户确认，避免误操作 八、一句话总结 Asking User Question Tool = AI智能体的“需求访谈官”，让Agent从“猜着做”变成“问清楚再做”，是构建可靠、实用AI助手的核心工具。
5 个月前
部署本地 OpenClaw 主要有两种主流且资料详尽的方式，你可以根据自己的技术背景和需求来选择。 我把这两种方式的流程整理成了一个概览表格，方便你快速对比和决策： 特性 方案一：Docker 部署（推荐新手） 方案二：Node.js 源码部署（适合开发者） 核心依赖 Docker, Docker Compose, Git Node.js (≥22), npm, Git 优点 环境隔离，部署和卸载干净，失败率低，适合快速体验 配置灵活，方便二次开发和调试，可直接运行最新源码 缺点 需要了解基本的 Docker 命令 对系统环境要求较高，可能遇到依赖冲突 适用人群 希望快速、稳定运行OpenClaw的用户 开发者、希望修改源码或深度定制OpenClaw的用户 方案一：使用 Docker 部署（推荐） 这种方法将 OpenClaw 运行在容器中，与你的系统环境隔离，最为稳妥。 第1步：准备工作与环境检查 在开始之前，请确保你的电脑满足最低要求：CPU ≥ 2核，内存 ≥ 4GB，磁盘空间 ≥ 20GB 。 第2步：安装通用依赖 你需要安装 Docker、Git 等工具。以下是 Linux (Ubuntu/Debian) 的示例命令，Windows 用户请手动下载安装 Docker Desktop 和 Git 。 # 1. 安装 Docker (使用阿里云镜像加速) curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun # 2. 启动 Docker 并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 3. 验证 Docker 安装 docker --version && docker compose version # 4. 安装 Git sudo apt update && sudo apt install git -y git --version 第3步：获取 OpenClaw 源码与镜像 创建工作目录，并拉取汉化版的源码和预构建的 Docker 镜像 。 # 1. 创建并进入部署目录 mkdir -p /opt/openclaw && cd /opt/openclaw # 2. 拉取2026版OpenClaw源码（汉化版） git clone https://github.com/openclaw-community/openclaw-zh.git . # 3. 拉取OpenClaw核心镜像（国内加速源） docker pull registry.cn-hangzhou.aliyuncs.com/openclaw/openclaw-core:2026-zh docker pull registry.cn-hangzhou.aliyuncs.com/openclaw/openclaw-web:2026-zh # 4. 验证镜像拉取结果 docker images | grep openclaw 第4步：初始化配置文件 复制配置文件模板并进行修改，填入你的 API Key 等重要信息 。 # 1. 复制默认配置文件 cp config/example.yaml config/config.yaml # 2. 编辑配置文件 (这里使用nano，你也可以用vim) nano config/config.yaml 找到文件中的对应部分，修改为以下内容。请务必将 你的阿里云百炼API-Key 替换为你自己的密钥 。 # ① 模型配置（替换为你的API-Key） models: providers: bailian: apiKey: "你的阿里云百炼API-Key" # <-- 在这里填入你的Key model: "bailian/qwen3-max-2026-01-23" # ② 服务端口配置 server: port: 18789 host: "0.0.0.0" # 监听所有网络接口，方便局域网内访问 # ③ 数据存储配置（本地路径） storage: local: path: "/opt/openclaw/data" 保存文件 (nano 中按 Ctrl+X，然后按 Y 确认，再按 Enter)。 第5步：启动 OpenClaw 服务 使用 Docker Compose 启动服务，并检查运行状态 。 # 1. 启动服务（后台运行） docker compose up -d # 2. 查看服务启动状态（所有容器应为 "Up" 状态） docker compose ps # 3. （可选）查看启动日志，确保无错误 docker compose logs -f 第6步：访问并完成初始化 打开浏览器，访问 http://127.0.0.1:18789 (如果在本机) 或 http://你的局域网IP:18789。首次访问时，页面会引导你设置管理员密码，之后就可以开始使用你的 OpenClaw 了 。 方案二：使用 Node.js 从源码部署 这种方式更贴近开发环境，适合需要定制功能的用户。 第1步：安装 Node.js 环境 OpenClaw 需要 Node.js 22 或更高版本 。推荐使用 NodeSource 仓库进行安装。 # 1. 添加 NodeSource 仓库 (以 Node.js 22 为例) curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - # 2. 安装 Node.js sudo apt install -y nodejs # 3. 验证安装 node -v # 应显示 v22.x.x 或更高 npm -v # 4. (可选) 配置 npm 国内镜像加速 npm config set registry https://registry.npmmirror.com 第2步：安装 OpenClaw 官方提供了一个一键安装脚本，会自动完成全局安装 。 # macOS / Linux 系统执行 curl -fsSL https://openclaw.ai/install.sh | bash 安装脚本执行完成后，会自动进入一个名为 onboard 的交互式设置向导。如果向导中断，你可以随时通过 openclaw onboard --install-daemon 命令重新启动 。 第3步：处理可能遇到的问题 command not found 错误: 安装后如果找不到 openclaw 命令，通常是因为 npm 的全局安装目录不在系统的 PATH 环境变量中。你可以通过 npm prefix -g 找到该目录（例如 /usr/local），然后将 export PATH="$(npm prefix -g)/bin:$PATH" 添加到你的 ~/.bashrc 或 ~/.zshrc 文件中，并执行 source ~/.bashrc 使其生效 。 sharp 模块安装失败: 在某些系统上，可能会遇到图像处理库 sharp 的安装错误。可以尝试设置环境变量绕过本地编译：SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install -g openclaw@latest 。 第4步：运行 OpenClaw 完成配置后，你可以通过以下命令启动 OpenClaw 的 Gateway 核心服务 ： openclaw gateway 然后，打开浏览器访问 http://127.0.0.1:18789 即可看到 Web 控制台界面 。 总的来说，对于大多数想要本地尝鲜的朋友，我强烈建议使用 Docker 方案，它足够简单且不容易把系统环境弄乱。如果你是个喜欢折腾的开发者，希望深入定制 OpenClaw 的能力，那么 Node.js 源码部署会更适合你。
5 个月前
2026年2月，维也纳这座古典音乐之都意外成为AI开源社区的焦点。继旧金山ClawCon之后，OpenClaw（中文社区昵称“小龙虾”或“龙虾”）的欧洲首场线下盛会——ClawCon Vienna顺利举办，吸引了约500名开发者、创业者、AI爱好者和非技术背景的“蟹教徒”齐聚一堂。现场能量爆棚，原定场地直接爆满，主办方紧急加开直播点，线上线下同步狂欢。这场聚会不仅是技术分享，更是“养龙虾”亚文化的一次集体高光。 Peter Steinberger：家乡英雄的“衣锦还乡” OpenClaw创始人Peter Steinberger（中文圈常称“虾爸”或“龙虾之父”）是奥地利本地人，曾就读维也纳工业大学，早年创办PSPDFKit（移动PDF解决方案公司），2021年以高价出售大部分股份后一度“退休”。2025年底，他重出江湖推出Clawdbot（后更名为OpenClaw），一个完全本地运行、开源的自主AI Agent框架，支持多模型调用、工具集成和复杂任务执行。 在维也纳大会上，Peter以“回家”姿态登台，分享了项目从车库原型到全球现象的历程。他强调OpenClaw的核心理念：让普通人也能轻松拥有强大AI能力，无需编程门槛，就能让Agent完成从酿啤酒配方生成到模拟小型公司运营的各种任务。现场开发者分享真实案例，有人用它自动化职场周报，有人构建个人知识库，还有人让它24小时监控市场情报。企业家和开发者一致认为，“Agent经济”已在悄然成型，而OpenClaw正成为这场革命的先锋。 从聊天框“逃离”：3D可视化与具身进化 大会最亮眼的Demo之一来自开发者Dominik Scholz。他基于OpenClaw打造了一个3D交互界面（使用Three.js + Electron），将Agent的推理过程从线性文本“解放”到三维空间：思考路径如星云扩散、决策节点如能量流，用户可以从“驾驶舱视角”直观观察AI内部逻辑，避免传统黑盒体验。 这一展示呼应了社区共识：未来的AI Agent不应永远困在对话框里，而应向更沉浸、更具情绪价值的形态进化。有人开玩笑说，早期的“soul.md”文件被删是为了“净化灵魂”，但也反映出大家对AI具身化、元宇宙式交互的热情探索。 史上首款“龙虾手机”亮相：25美元实现廉价具身AI 另一个重磅炸场的是开发者Marshall的ClawPhone项目。他在一台仅售25美元的廉价手机上安装OpenClaw，并授予完整硬件权限。Agent可直接调用麦克风、摄像头、短信、打印机等，实现实时TTS（语音合成）、浏览器自动化、短信预约、设备远程控制等功能。 现场演示中，ClawPhone通过打印机错误音“哔哔”反馈任务状态、WhatsApp审批流程、甚至自主预约日程。Marshall认为，这种极客玩具预示未来：每个房间、实验室或小型机器人可能都配备类似廉价“龙虾终端”——断网也能运行，极端情况下“一锤砸掉”即可关停，形成分布式、去中心化的具身AI节点。 全球“养龙虾”浪潮：从旧金山到维也纳，再到亚洲 ClawCon Vienna是OpenClaw全球化扩张的又一里程碑。上周旧金山首场ClawCon已吸引超1000人，韩国AI女友项目Clawra上线后一夜爆火。全球开发者正围绕OpenClaw构建技能市场、Prompt库、多Agent协作系统，从单一工具演变为活跃开源生态。 维也纳的狂欢证明：OpenClaw已超越技术本身，成为一种社区文化现象。“蟹教徒”“虾粮”“蜕皮进化”“龙虾大逃杀”等梗在中文圈刷屏，英文社区也同步玩梗。项目从本地运行到硬件具身、从聊天框到3D空间，正在以惊人速度进化。 结语：小龙虾的下一个蜕皮 维也纳ClawCon不是终点，而是OpenClaw“征服全世界”叙事的又一章。Peter Steinberger的回归、社区的狂热、硬件的创新，都在告诉我们：开源AI Agent的春天来了，而“小龙虾”正以最意想不到的方式，搅动整个行业。
5 个月前
Xiaomi-Robotics-0 预训练了大量跨身体机器人轨迹和视觉语言数据，使其能够获得广泛且可推广的动作生成知识，同时保持强大的VLM能力。
5 个月前
在2026年开发AI产品时，搭建一个生产级（production-grade）RAG系统已经不再是“简单接个向量数据库就行”，而是需要系统性工程化思维。以下是从0到1再到生产可用的完整路径，按实际优先级和踩坑顺序组织。 一、生产级RAG ≠ Demo级RAG 的本质区别（2025-2026共识） 维度 Demo级（常见教程） 生产级（真正能上线赚钱） 为什么重要 文档量 几MB ~ 几百页 几万 ~ 几百万文档 / 多模态 / 每天增量更新 决定了分块、索引、召回策略完全不同 召回准确率 60-75% 目标88-95%+（视场景） 差10%召回率，用户体验天差地别 延迟 2-8秒随便 <1.5秒（p95），理想<800ms 用户流失率与延迟呈指数关系 幻觉控制 看运气 需要多重机制把幻觉率压到<5% 企业客户最怕胡说八道 可维护性 脚本跑一遍就行 需要数据质量pipeline、版本控制、监控告警 半年后没人敢碰代码 成本 不care embedding + LLM + vectorDB 每月几千到几十万刀 直接影响商业模式能否跑通 二、2026年主流生产级RAG搭建完整路径（推荐路线） Phase 0：先别写代码，先做这两件事（很多人跳过直接失败） 明确业务成功标准（最重要一步） 准确率目标：≥88%（RAGAS faithfulness & answer relevancy） 幻觉率：<5% 响应时间：p95 < 2秒（或按产品定位） 支持的文档类型：PDF/Word/Excel/网页/Markdown/扫描件/表格/图片？ 更新频率：实时 / 每天 / 每周？ 用户问题类型：单轮 / 多轮 / 带表格 / 需要推理？ 准备评估集（金标准） 至少200-500条 真实用户问题 + 人工标注的完美答案 后续所有优化都拿这个集子打分 Phase 1：数据摄入与预处理（决定天花板，占60%工作量） 现代顺序（2025-2026主流做法）： 文档清洗与质量分级（最被低估的一步） 运行一个轻量文档质量打分模型（或规则+小型LLM） 分三类：Clean / Decent / Garbage Garbage类直接人工干预或低权重处理 结构化解析（别直接喂Unstructured） PDF：用Marker / PyMuPDF + table detection（Marker 2025年后很强） Word/Excel：python-docx / pandas 保留层级：标题 → 段落 → 表格 → 图片说明 → 元数据 高级Chunk策略（2026年最核心差异化点） 策略 Chunk大小 适用场景 召回提升 Fixed-size 512 token 快速验证 baseline Semantic 200-800 主流生产 +15-25% Hierarchical 父子chunk 长文档、合同、手册 +20-35% Proposition-based 小粒度命题 法律/医疗/技术文档 +30%+ 推荐起步组合：Semantic + 父子索引 + 100-200 token重叠 Phase 2：Embedding 与 向量存储（2026主流选型） Embedding模型推荐（2026.2月时点性价比排序）： bge-m3 / Snowflake Arctic Embed（开源王者） voyage-3-large / Cohere embed-v4（闭源但效果顶尖） text-embedding-3-large（稳定但已被超越） 向量数据库主流选择： 场景 首选数据库 次选 备注 < 100万向量 Chroma / Qdrant本地 PGVector 开发快 100万-1亿 Qdrant / Milvus Weaviate Qdrant 2025-2026口碑最佳 亿级 + 高并发 Pinecone serverless Zilliz Cloud 省心但贵 极致私有化 pgvector + pgvectorscale Milvus standalone 强烈建议：hybrid search（dense + sparse / BM25）几乎成为2026标配。 Phase 3：检索与后处理（拉开差距的关键层） 现代检索流水线（2026主流）： 用户问题 ↓ Query分类与改写（是否需要检索？多意图拆分？） ↓ 多路召回（vector + BM25 + 知识图谱等） ↓ 初筛 top-30~100 ↓ 重排序（Cohere Rerank3 / bge-reranker-v2 / flashrank） ↓ 上下文压缩 / 抽取（LLM summarize top-8） ↓ 最终给LLM的上下文（带清晰source引用） Phase 4：生成与防幻觉 Prompt工程模板（必须有）： 强制要求：只用提供的内容回答 / 不知道就说不知道 / 标注来源 结构化输出（JSON）便于下游解析 防幻觉组合拳： Self-Check / Self-RAG Corrective RAG Groundedness check（RAGAS / TruLens） 后置事实核查（小模型或规则） Phase 5：评估、监控、迭代闭环（生产级灵魂） 必须上的指标： Retrieval：Recall@K, MRR, NDCG Generation：Faithfulness, Answer Relevancy, Context Precision/Recall End-to-End：用户打分 / A/B测试 / 业务指标（解决率、CSAT） 推荐工具组合（2026主流）： 评估：RAGAS / DeepEval / TruLens / Phoenix 监控：LangSmith / Helicone / Phoenix / PromptLayer Orchestration：LangGraph / LlamaIndex Workflows / Haystack / Flowise（低代码） 三、2026年推荐最小可用生产技术栈（性价比最高） 极简但能上线（适合小团队） 解析 → Marker / LlamaParse 向量化 → bge-m3 或 voyage-3 向量库 → Qdrant (docker) 召回+重排 → Qdrant + bge-reranker-v2 框架 → LlamaIndex 或 LangGraph LLM → DeepSeek-R1 / Qwen2.5-72B-Instruct / Claude-3.5-Sonnet (根据预算) 评估 → RAGAS + 人工golden set 进阶企业级（已验证可支撑十万+文档） 加：混合检索 + 父子索引 + query分解 + 多路召回 + 上下文压缩 + corrective RAG + 在线监控 一句话总结2026年RAG哲学： “70%的效果提升来自于数据质量、切块策略和检索后处理；20%来自embedding和重排序模型；只有10%靠换个更强的LLM。” 先把前70%做好，后面自然水到渠成。 （ Grok ）
5 个月前
AI越来越像古希腊的“神谕”（Oracle）——权威、神秘、能给出惊人准确的答案，但如果我们把探索的过程完全交给它，就等于主动放弃了人类心智最宝贵的那部分自由与创造性。
5 个月前
Node.js 和 Git 是支持 AI Agent 开发、依赖管理和协作的基础工具。
5 个月前
AI Agent 的真正智能，来自于知识获取（RAG） + 协作协议（MCP） + 执行能力（SKILLS）的统一协同，而不是单一大模型孤立输出。
5 个月前
作者： Augusto Marietti（Kong CEO & 联合创始人）、YJ Lu（Teachers’ Venture Growth 总监）、Yiran Wu（Teachers’ Venture Growth 投资分析师） 背景：上下文是新的算力 过去几年，AI 以史无前例的速度发展。从传统机器学习系统跃迁到能写作、编程、推理的生成式 AI 模型，这一变化彻底改变了我们与 AI 的互动方式。但旅程并未结束。 我们正进入一个新的阶段：具备上下文理解与自主行动能力的 Agentic AI（代理式 AI）。它们能自主设定目标、执行任务，并且几乎不需要人工干预。 支撑这一转变的核心是 Model Context Protocol（MCP）模型上下文协议 —— 一个新兴标准，用于将基于提示的生成式 AI 模型连接到真实世界的数据、工具与操作。 上一阶段的问题：缺失的上下文（404） 直到最近，大多数前沿大模型都运行在“围墙花园”中： 它们能理解用户提示并生成文本，但无法标准化地访问个人或企业数据、内部工具、API 或其他关键上下文来源。 企业若想让模型具备上下文能力，只能构建昂贵、脆弱且难以维护的定制集成（“胶水代码”）。 2024 年 11 月，Anthropic 推出开源框架 MCP，旨在通过通用协议将上下文引入 LLM，使其能发现、调用并认证外部系统的 API。 MCP 很快成为行业标准，被 OpenAI、Google 等巨头采用。 随着生态成熟，AI 系统将能在不同工具之间保持上下文，实现可持续的架构。 MCP 如何工作？ 在 MCP 之前，每个 LLM 都有自己的插件格式，需要为每个工具写独立的集成代码，形成 N × M 的复杂矩阵。 MCP 将这一矩阵折叠为一个供应商中立的系统，通过定义清晰的角色（host、client、server），让工具能以一致方式被发现与调用。 只需为每个上下文源构建一个 MCP server，任何兼容 MCP 的 AI 助手都能像使用工具箱一样使用它。 流程如下： 用户输入提示 模型解析意图 模型不再“猜测”，而是向 真实上下文 请求信息 MCP client 将意图转为标准化请求 MCP server 执行 API 调用并返回结构化结果 模型基于真实数据生成上下文感知的输出 最重要的是：不再需要 N × M 的胶水代码。 承API之踵，拓更阔之路 科技行业并非第一次需要通用标准来实现规模化。 API 曾是软件互联的关键： 它定义了软件之间如何交流、返回什么、如何安全交换信息。 API 真正爆发是在 REST、JSON、OAuth 等标准化之后，开发者终于能以可移植、可预测的方式构建软件。 这催生了 Stripe、Twilio、Plaid 等“API 即业务”的公司。 MCP 正在走类似的道路： 标准化模型访问工具与数据的方式。 随着 MCP 采用率提升，我们将看到 API 生态曾经出现的配套设施： 注册表、可观测性、审批系统、策略引擎、更好的工具链等。 我们的判断：上下文 + API + 工作流 = Agentic AI 我们押注两个方向： Anthropic 的 MCP 正成为连接 LLM 与工具/数据的行业标准，为代理式工作流与多代理系统（A2A）奠定基础。 Kong 将其在 API 管理领域的领先地位扩展到 AI 连接层，成为企业系统与新一代 AI 代理之间的“连接组织”。 Anthropic Anthropic 推出 MCP，是因为 AI 的未来不仅在于更大的模型，还在于将模型连接到正确的上下文。 2025 年 5 月，Anthropic 发布 Integrations，将 MCP 支持扩展到 Claude API，使 Claude 能无代码连接任何远程 MCP server。 未来路线图从单一代理转向多代理协作（A2A）： 一个代理获取客户数据 一个代理做投资组合分析 一个代理生成合规报告 全部通过 MCP 与 A2A 无缝协调 AI 将从单一助手变成专业代理网络。 Kong Kong 正将其 API 管理平台扩展到 AI 连接层，推出： AI Gateway：将 LLM/MCP/API 调用视为 API 流量进行路由、安全、监控与优化 MCP Server for Konnect：将企业系统（API、服务、分析等）通过 MCP 暴露给 AI 代理，使其能用自然语言查询并获取洞察 Kong 的愿景是： “没有 API，就没有 AI。” MCP 的下一章：Linux 基金会托管 2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux 基金会旗下的新机构 Agentic AI Foundation（AAIF）。 AAIF 由 Anthropic、Block、OpenAI 共同创立，并获得 Google、Microsoft、AWS、Cloudflare、Bloomberg 支持。 MCP 的开源治理模式类似 Linux、Kubernetes、Node.js、PyTorch 等项目，预计将加速其采用。 目前 MCP 已实现： 每月 9700 万+ SDK 下载 1 万+ 活跃服务器 深度集成到 Claude、ChatGPT、Gemini 等产品 MCP 正从开发者框架走向下一代 AI 工作流的关键基础设施。 未来的机会 MCP 通过提供一个中立、通用的语言，让模型能访问工具、数据与系统，从而降低摩擦、提升互操作性。 随着采用率提升，我们将看到类似 API 生态的爆发： 新商业模式 新工具链 新应用类别 但机会伴随风险： 工具滥用 数据暴露 安全治理需求 生态必须在开放与安全之间取得平衡。 标准本身不会改变世界，生态系统才会。 如果成功，MCP 将成为未来几十年 AI 智能如何被封装、共享与扩展的基础设施。 (文章来源otpp.com )
5 个月前
Agent是具备自主决策、工具调用与状态感知的智能体概念，LangGraph则是LangChain生态下的图驱动有状态Agent编排框架，专门解决复杂Agent的状态管理、循环分支与持久执行问题，是构建生产级Agent的核心基础设施。二者是“概念-实现”的强绑定关系，LangGraph为Agent提供图建模、状态持久化、人机协作等关键能力，适配ReAct、多智能体协作等复杂场景。 核心关联逻辑：概念与实现的分层 层级 定位 核心内容 概念层（Agent） 自主决策执行单元 LLM+Tools+自主循环（Thought→Action→Observation），解决非预定义复杂任务 实现层（LangGraph） 图驱动Agent框架 以有向图建模Agent流程，通过State/Nodes/Edges/Checkpointing支撑复杂逻辑 生态层 LangChain全家桶 LangGraph无缝集成LangChain的LLM/Tools/Prompt与LangSmith调试能力，降低开发门槛 LangGraph为Agent解决的核心痛点 有状态执行：用State统一管理对话历史、工具输出、中间结果，支持跨轮次上下文与长期记忆，避免“失忆”。 复杂流程编排：将Agent步骤拆为Nodes（LLM调用、工具执行、决策判断），用Edges（含条件分支）定义路径，原生支持循环（如ReAct迭代）与并行执行。 持久化与容错：Checkpointing自动保存每步状态，任务中断后可恢复，适配长时间运行场景（如多轮调研、项目管理）。 人机协作可控：支持执行中人工干预状态、审批工具调用，解决Agent“黑盒操作”风险。 多Agent协同：将不同功能Agent作为节点，通过图结构实现任务拆分与结果聚合，适配复杂团队协作流程。 典型实现范式：ReAct Agent的图建模 定义State：封装消息、工具结果、思考记录等，用TypedDict/Pydantic统一管理。 配置Nodes：LLM节点（推理决策）、工具节点（执行调用）、路由节点（判断是否继续）。 连接Edges：按条件分支（如“有工具调用则执行工具，否则结束”）构建循环路径。 启用Checkpointing：保存每步状态，支持断点恢复与调试追踪。 部署与监控：用LangSmith可视化执行路径，快速定位逻辑问题。 与传统Agent实现的差异 对比项 LangGraph驱动Agent LangChain基础Pipe 普通云端Agent 状态管理 原生持久化，跨轮次记忆 无内置状态，需手动维护 依赖会话缓存，易丢失 复杂逻辑 支持循环、条件分支、并行 线性流程，扩展有限 多为单步/固定链，灵活度低 容错能力 Checkpointing断点恢复 无容错，中断需重跑 云端依赖，故障难恢复 可控性 执行中人工干预 固定流程，干预困难 操作透明性差 关键使用场景 单Agent复杂任务：市场调研（搜索→数据清洗→报告生成）、财务对账（多系统数据拉取→交叉校验→异常告警）。 多Agent协作：产品开发（需求Agent→设计Agent→开发Agent→测试Agent）、跨境电商（选品→翻译→投放→售后）。 长期运行任务：客户成功跟进（多轮问题诊断→方案生成→效果复盘）、内容系列创作（选题→素材→撰写→发布）。 快速上手建议 用create_react_agent快速搭建基础Agent，绑定LLM与Tools，验证核心流程。 自定义State结构，覆盖任务类型、工具结果、历史对话等关键字段。 拆分Nodes与Edges，添加条件判断（如“金额>1000需审批”），提升流程可控性。 启用Checkpointing并接入LangSmith，监控执行路径与状态变化。
5 个月前
命令优先，而非图形界面。
6 个月前
原名 Clawdbot 的灵感来自 Claude 模型加载时出现的那个“Clawd”小龙虾/爪子吉祥物。
6 个月前
奥地利最知名的独立开发者 Steinberger 是全球最热的“一人公司”/“vibe-coding”代表人物之一。
6 个月前
简要结论：物理AI（Physical AI）正在成为人工智能发展的新方向，它的现实性在于能否真正理解并遵循物理规律。目前已有测试框架和硬件架构推动落地，但仍存在显著差距，现实应用需要长期迭代。 ? 什么是“物理AI” 定义：物理AI强调让人工智能不仅能生成文本或图像，还要能在现实世界中遵循物理定律，具备“具身智能”（Embodied AI）的能力。 目标：解决 AI 在仿真到现实（Sim-to-Real）转化中的落地难题，让机器人、自动驾驶、数字孪生等应用更可靠。 ? 当前研究进展 PAI-Bench 测试框架：佐治亚理工学院与卡内基梅隆大学团队提出的标准，用于评估 AI 是否理解物理规律。测试包含 2808 个真实案例，涵盖自动驾驶预测、机器人操作等场景。结果显示：人类准确率约 93.2%，而最佳 AI 模型仅 64.7%。 英伟达“物理AI”战略：在 CES 2026 提出，基于 Vera Rubin 超算平台 + Omniverse 仿真环境 + Jetson T4000 边缘硬件，构建闭环架构，强调“不要只生成像素，要生成行动”。 ✅ 现实性分析 优势： 技术驱动：硬件（GPU、边缘计算）和仿真平台（Omniverse）已具备支撑条件。 应用需求强烈：自动驾驶、机器人、工业制造等都需要 AI 遵循物理规律。 研究路径明确：已有标准化测试框架（PAI-Bench），为模型改进提供方向。 局限： 理解不足：现有模型在物理推理上的表现远低于人类水平。 数据难题：物理规律涉及连续性和复杂交互，难以通过大规模数据直接学习。 落地成本高：需要强算力、精细仿真和高性能硬件，短期内难以普及。 ⚠️ 风险与挑战 幻觉问题：AI可能生成视觉效果逼真但违反物理规律的结果。 安全性：在自动驾驶或机器人场景中，错误的物理推理可能导致事故。 标准缺失：虽然有 PAI-Bench，但行业尚未形成统一的评估体系。 ? 综合评价 物理AI的现实性在于“方向明确、路径清晰，但短期难以完全落地”。 它更像是未来十年 AI 的关键突破口：从“生成像素”走向“生成行动”。目前仍处于探索阶段，但随着硬件、仿真和测试框架的成熟，物理AI有望逐步应用于自动驾驶、机器人和工业场景。
