Moltbot Linux部署指南：构建可审计的AI智能体运行时环境

1. 这不是“装个软件”Hermes Agent OpenClaw 在 Linux 上的真实定位与价值锚点很多人看到标题里的“保姆级教程”第一反应是“哦又一个装软件的步骤清单”。但如果你真这么想接下来的操作大概率会在第3步就卡住然后在社区里发帖问“为什么 openclaw 命令无法识别”最后被回复一句“请先看文档”。这不是态度问题而是对这套工具链底层逻辑的误判。Hermes Agent 和 OpenClaw现名 Moltbot根本不是传统意义上的“应用软件”它们是一套可编程的、面向任务的本地智能体运行时环境。你可以把它理解成 Linux 系统里的一个“AI内核”——就像 systemd 管理服务、bash 解释命令一样Moltbot 负责接收自然语言指令、解析意图、调度技能Skills、调用模型、执行动作并把结果结构化返回。它不提供图形界面不内置大模型也不直接处理飞书消息它只提供一套标准化的协议和插件机制让开发者能像写 shell 脚本一样用 YAML 和 JavaScript 编排 AI 工作流。这解释了为什么所有热词里反复出现“agent skill”“openclaw配置”“hermes desktop下载”却极少有人提“openclaw.exe安装包”。因为它压根没有“一键双击安装”的路径。它的部署本质是构建一个受控的 Node.js 运行沙盒并注入可信的模型接入凭证与通信通道。而阿里云的角色不是给你一个打包好的“AI盒子”而是提供了两个关键基础设施一是百炼平台作为稳定、合规、可计费的模型 API 供应方二是轻量应用服务器作为开箱即用的、预装了必要依赖Node.js 22、curl、git、systemd的 Linux 托管环境。你买的不是软件是“可验证的执行上下文”。这也是为什么标题强调“2026年”——这个时间戳不是营销噱头。2026年1月27日项目正式从 Clawdbot 迁移至 MoltbotCLI 命令、配置文件路径、默认端口、甚至错误提示文案都发生了不可逆变更。网上90%的“OpenClaw 教程”如果发布于2026年1月前其核心命令如clawdbot dashboard在今天执行只会返回zsh: command not found。这不是版本兼容问题而是项目主体已切换。你看到的openclaw命令本质上是一个指向moltbot的软链接或别名真正的二进制文件叫moltbot它由 npm 全局安装其生命周期由systemd管理而非用户终端会话。所以这篇教程的起点不是“怎么敲命令”而是“如何建立一个能长期、稳定、安全运行 AI 智能体的 Linux 环境”。它要求你放弃 Windows 用户惯用的“图形化向导”思维转而接受 Linux 的哲学一切皆文件一切皆服务一切配置都有迹可循。你会频繁编辑~/.moltbot/moltbot.json会检查/etc/systemd/system/moltbot-gateway.service会用journalctl -u moltbot-gateway -f实时追踪日志。这不是增加复杂度而是把控制权交还给你——当飞书消息没收到时你能精准定位是飞书 Webhook 配置错误、还是 Moltbot 的 Skill 插件未启用、或是防火墙拦截了 18789 端口的入站请求。这种可追溯性正是企业级自动化不可替代的价值。提示本文所有操作均基于Rocky Linux 9.4阿里云轻量应用服务器默认镜像和Node.js v22.14.0。若你使用 Ubuntu 或 CentOS Stream请自行将dnf命令替换为apt或yum并将systemd服务文件路径中的rocky字样忽略。核心逻辑不变变的只是发行版的包管理语法。2. 从零构建可信执行环境Linux 系统层的硬性准备与避坑清单在 Linux 上部署任何需要长期运行的服务第一步永远不是下载脚本而是确认系统处于一个干净、可控、可复现的状态。很多“保姆级教程”跳过这一步直接让你curl | bash结果在生产环境踩坑时才发现问题根源是系统自带的旧版 OpenSSL 或冲突的 Python 环境。对于 Hermes Agent 这类深度依赖 Node.js 生态的项目这一步的严谨性直接决定了后续90%的问题是否会出现。2.1 系统初始化重置源、升级内核、校准时钟阿里云轻量应用服务器创建后默认使用的是官方 Rocky Linux 镜像其软件源mirror指向国际节点国内访问极慢且不稳定。必须第一时间切换为阿里云官方镜像源。这不是可选项是强制前置条件。# 备份原配置 sudo cp /etc/yum.repos.d/rocky.repo /etc/yum.repos.d/rocky.repo.bak # 替换 baseurl 为阿里云镜像 sudo sed -i s/mirrorlist/#mirrorlist/g /etc/yum.repos.d/rocky.repo sudo sed -i s|#baseurlhttps://dl.rockylinux.org|baseurlhttps://mirrors.aliyun.com|g /etc/yum.repos.d/rocky.repo # 清理缓存并生成新缓存 sudo dnf clean all sudo dnf makecache完成源切换后执行一次完整的系统升级。注意这里不是dnf update -y而是dnf distro-sync --allowerasing。后者会强制同步所有包到最新稳定版并自动解决依赖冲突这是 Rocky Linux 推荐的升级方式能避免因小版本差异导致的glibc兼容性问题。sudo dnf distro-sync --allowerasing -y升级完成后重启系统。这不是为了“仪式感”而是因为内核更新kernel-core必须重启才能生效。一个未重启的系统其uname -r显示的仍是旧内核而新版 Node.js v22 对io_uring的支持高度依赖较新的内核特性。实测中未重启的机器在运行moltbot gateway start时journalctl日志中会高频出现io_uring_setup failed: Operation not supported错误导致 Gateway 服务反复崩溃。此外务必校准系统时钟。AI 服务与飞书、百炼等外部 API 的通信大量依赖 HTTPS 证书的有效期验证。如果服务器时间偏差超过5分钟curl请求会直接失败并抛出SSL certificate problem: clock skew。使用chronyRocky 9 默认时间同步服务进行强制校准sudo chronyc makestep sudo chronyc tracking # 查看同步状态Stratum 应为 2 或 32.2 Node.js 环境为什么必须用 nvm以及如何绕过 npm 的“全球锁”OpenClaw/Moltbot 官方明确要求 Node.js ≥22。但 Rocky Linux 9.4 的dnf仓库中nodejs包的最高版本是 18.x。强行dnf install nodejs不仅无法满足要求还会与后续通过 nvm 安装的 Node.js 产生 PATH 冲突。因此必须使用版本管理器nvmNode Version Manager。但这里有个关键陷阱nvm的安装脚本curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash在 Rocky Linux 上默认会失败。原因是其检测逻辑依赖lsb_release命令而 Rocky 9 默认不安装redhat-lsb-core包。直接运行会卡在nvm is not compatible with the npm config prefix的错误上。解决方案是手动安装nvm并规避 npm 配置冲突# 1. 安装 lsb_release sudo dnf install -y redhat-lsb-core # 2. 下载并手动安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 3. 将 nvm 初始化代码添加到 ~/.bashrc注意Rocky 9 默认 Shell 是 bash非 zsh export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # This loads nvm [ -s $NVM_DIR/bash_completion ] \. $NVM_DIR/bash_completion # This loads nvm bash_completion # 4. 重新加载配置 source ~/.bashrc # 5. 安装 Node.js v22 并设为默认 nvm install 22 nvm alias default 22 nvm use default # 6. 验证 node -v # 应输出 v22.14.0 npm -v # 应输出 10.9.2最关键的一步在第6步之后禁用 npm 的全局 prefix 配置。nvm的设计哲学是每个 Node.js 版本拥有独立的全局模块空间。但npm默认会将全局模块安装到/usr/lib/node_modules这与nvm的~/.nvm/versions/node/v22.14.0/lib/node_modules冲突。执行以下命令彻底解除绑定npm config delete prefix npm config set cache ~/.npm这确保了npm install -g moltbot安装的moltbot二进制文件其所有依赖都严格限定在nvm管理的 v22 环境内不会污染系统级 Node.js。这是后续moltbot doctor能正确诊断环境问题的基石。2.3 网络与安全基线防火墙、SELinux 与端口策略的协同Moltbot Gateway 默认监听127.0.0.1:18789这是一个典型的“本地回环”地址意味着它默认只接受本机进程的连接。但飞书 Webhook 和外部浏览器访问都需要它暴露在0.0.0.0:18789。这就涉及三个层面的安全策略协同firewalld防火墙必须放行 18789 端口的 TCP 入站流量。SELinux安全增强型 Linux默认策略禁止非标准端口的网络绑定需为 18789 端口打上http_port_t标签。Moltbot 配置必须显式修改其监听地址否则即使防火墙和 SELinux 全开服务仍只绑在127.0.0.1。三者缺一不可。漏掉任何一个都会导致“服务明明在运行但就是连不上”的玄学问题。firewalld 配置# 添加永久规则 sudo firewall-cmd --permanent --add-port18789/tcp # 重载防火墙 sudo firewall-cmd --reload # 验证 sudo firewall-cmd --list-ports | grep 18789SELinux 配置# 查询当前 http_port_t 允许的端口范围 sudo semanage port -l | grep http_port_t # 将 18789 添加到 http_port_t 范围如果不在其中 sudo semanage port -a -t http_port_t -p tcp 18789 # 验证 sudo semanage port -l | grep http_port_t | grep 18789Moltbot 监听地址配置此配置不能在 Web UI 中设置必须手动编辑~/.moltbot/moltbot.json。在gateway节点下添加host和port字段{ gateway: { host: 0.0.0.0, port: 18789, cors: { origin: * } } }注意cors.origin: *是开发阶段的便捷配置生产环境应替换为具体的飞书域名如https://open.feishu.cn以符合最小权限原则。host字段必须是0.0.0.0而非localhost或127.0.0.1后者在容器或远程访问场景下无效。完成以上三步后用ss -tuln | grep 18789命令验证输出应为tcp LISTEN 0 128 0.0.0.0:18789 0.0.0.0:*。如果显示的是127.0.0.1:18789说明 Moltbot 配置未生效如果无输出说明服务未启动或被 SELinux 阻止如果输出但无法curl http://your-server-ip:18789/health则一定是防火墙未放行。3. 核心服务部署Moltbot 的安装、配置与百炼 API 的安全接入当 Linux 系统基线稳固后真正的部署才开始。这一步的核心矛盾在于如何在保证安全性API Key 不泄露的前提下实现配置的可维护性与可审计性。网上流传的“一键脚本”之所以危险是因为它往往将 API Key 直接硬编码在配置文件中一旦该文件被意外提交到 Git 仓库后果不堪设想。我们必须采用分层配置策略。3.1 安装 Moltbot为什么curl | bash是双刃剑以及如何安全地“抄作业”官方推荐的一键安装脚本curl -fsSL https://molt.bot/install.sh | bash其内部逻辑是检测系统架构x86_64 / aarch64下载预编译的moltbot二进制文件到/usr/local/bin创建~/.moltbot目录并初始化默认配置注册systemd服务单元文件。这个流程本身是可靠的但风险点在于第2步预编译二进制文件的来源可信度。molt.bot域名并非阿里云官方域名其 SSL 证书由 Lets Encrypt 签发这本身没问题但缺乏阿里云的强背书。对于企业环境更稳妥的方式是从源码构建虽然耗时稍长但能完全掌控二进制文件的生成过程。以下是经过验证的、安全的源码构建流程# 1. 克隆官方仓库注意2026年后的主仓库是 github.com/moltbot/moltbot git clone https://github.com/moltbot/moltbot.git cd moltbot # 2. 检出稳定发布标签避免使用 main 分支的不稳定代码 git checkout v2.3.1 # 此为2026年4月的最新稳定版 # 3. 安装依赖此时 nvm 已激活 v22 npm ci # 使用 package-lock.json 确保依赖版本一致比 npm install 更可靠 # 4. 构建生产环境包 npm run build:prod # 5. 全局链接使 moltbot 命令可用 sudo npm link # 6. 验证 moltbot --version # 应输出 2.3.1npm ci是关键。它会完全删除node_modules并严格按照package-lock.json重新安装杜绝了npm install可能引入的、^或~版本号导致的间接依赖升级。这是保障构建可重现性的黄金法则。3.2 百炼 API Key 的获取与注入环境变量的“双重保险”机制阿里云百炼平台的 API Key 获取流程是标准的但其注入方式决定了整个系统的安全水位。我们采用“环境变量 配置文件引用”的双重保险机制。第一步在百炼平台创建 Key登录 阿里云百炼控制台 进入“密钥管理”点击“创建API-Key”重要在创建时务必勾选“限制调用 IP”并填入你的阿里云服务器公网 IP。这是第一道防线即使 Key 泄露也无法从其他 IP 调用。第二步在服务器上安全存储 Key不要用echo export DASHSCOPE_API_KEYxxx ~/.bashrc。这种方式有两大缺陷一是 Key 明文存在于.bashrc文件中任何能读取该文件的用户都能获取二是.bashrc是交互式 Shell 的配置而systemd服务启动时并不加载它。正确的做法是创建一个专用的、权限严格的环境变量文件# 创建环境变量文件 sudo tee /etc/moltbot/env.sh EOF #!/bin/bash export DASHSCOPE_API_KEYyour_actual_api_key_here export DASHSCOPE_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 EOF # 设置权限仅 root 可读写 sudo chmod 600 /etc/moltbot/env.sh # 验证内容root 用户执行 sudo cat /etc/moltbot/env.sh第三步修改 systemd 服务文件注入环境变量moltbot的systemd服务文件通常位于/etc/systemd/system/moltbot-gateway.service。我们需要编辑它使其在启动时加载上述环境变量sudo systemctl edit moltbot-gateway在打开的编辑器中输入以下内容[Service] EnvironmentFile/etc/moltbot/env.sh保存并退出。这行配置告诉systemd在启动moltbot-gateway服务前先读取/etc/moltbot/env.sh中定义的所有环境变量。EnvironmentFile是systemd提供的、最安全的环境变量注入方式它比ExecStartPre执行source命令更可靠也比在ExecStart中拼接env命令更简洁。最后重载systemd配置并重启服务sudo systemctl daemon-reload sudo systemctl restart moltbot-gateway sudo systemctl status moltbot-gateway # 确认状态为 active (running)3.3 配置文件详解moltbot.json中每一个字段的实战意义~/.moltbot/moltbot.json是 Moltbot 的“大脑”其结构远比表面看起来复杂。下面是对核心区块的逐字段解读全部基于真实故障排查经验。models区块为什么mode: merge是唯一安全的选择models: { mode: merge, providers: { ... } }mode有replace和merge两种。replace会完全覆盖内置模型列表风险极高——一旦你配置错误Moltbot 就失去了所有默认模型连moltbot models list都会报错。merge则是增量合并它会保留内置的local模型用于离线测试只将你配置的bailian模型加入列表。这是生产环境的绝对首选。providers.bailian区块api字段的陷阱bailian: { baseUrl: ..., apiKey: ${DASHSCOPE_API_KEY}, api: openai-completions, // 关键 models: [ ... ] }api字段决定了 Moltbot 如何与百炼通信。openai-completions对应的是 OpenAI 兼容的/v1/chat/completions接口这是通义千问系列模型的标准接口。但如果你错误地填了openai-chatMoltbot 会尝试调用/v1/chat而百炼并不提供此路径导致所有请求返回404 Not Found。这个错误在moltbot doctor的日志中表现为Error: Request failed with status code 404非常隐蔽。agents.defaults.model区块primary字段的“软链接”本质agents: { defaults: { model: { primary: bailian/qwen3-max-2026-01-23 } } }primary并不是一个硬编码的模型 ID而是一个“模型别名引用”。它的值bailian/qwen3-max-2026-01-23必须与models.providers.bailian.models数组中某个对象的id字段完全匹配注意是id不是name。如果id是qwen3-max而你写了bailian/qwen3-max-2026-01-23就会导致moltbot agent命令启动时找不到模型报错Model not found: bailian/qwen3-max-2026-01-23。gateway.cors区块生产环境的最小权限配置gateway: { cors: { origin: [https://open.feishu.cn, https://your-company-dashboard.com] } }开发时用*很方便但上线后必须明确列出所有合法的origin。飞书 Webhook 的回调 URL 固定为https://open.feishu.cn这是你必须添加的第一个条目。如果遗漏飞书发送的消息会被浏览器的 CORS 策略拦截Moltbot 根本收不到请求。4. 飞书对接实战从 Webhook 创建到 Skill 编排的全链路打通飞书对接是本教程的“临门一脚”也是最容易功亏一篑的环节。其难点不在于技术而在于飞书开放平台、Moltbot Skill 机制、Linux 网络环境三者之间的状态同步。一个常见的失败模式是飞书后台显示 Webhook “已启用”Moltbot 日志里却没有任何请求记录。这通常意味着三者中至少有一个环节的“状态”是假的。4.1 飞书开放平台配置Webhook 的“心跳”与“签名”验证在飞书开放平台创建 Bot 后进入“事件订阅”页面添加一个 Webhook。关键配置项如下请求 URL:https://your-server-public-ip:18789/webhook/feishu注意必须是https且端口为18789。Moltbot 的飞书 Skill 默认监听此路径。如果你修改了 Gateway 端口此处 URL 必须同步更新。加密密钥Verification Token: 随机生成一串 32 位字符串例如FeiShuToken20260428。此密钥必须与 Moltbot 配置文件中的skills.feishu.verificationToken字段完全一致。这是飞书验证请求来源合法性的唯一凭证。App ID 与 App Secret: 这两个值在飞书 Bot 的“凭证与基础信息”页面获取。它们的作用是让 Moltbot 能够调用飞书的message/v4API 来发送回复消息。它们不需要填入 Moltbot 配置文件而是由飞书 Skill 插件在运行时自动读取。事件类型: 至少勾选message普通消息和p2p_chat_create私聊创建。前者是接收用户消息后者是让 Bot 能在用户首次私聊时自动回复欢迎语。配置完成后点击“启用”按钮。飞书会立即向你的 URL 发送一个GET请求进行验证其 URL 形如https://your-url/webhook/feishu?challengexxxxtokenyyyy。Moltbot 的飞书 Skill 会自动处理此请求计算sha256签名并返回challenge参数。如果这一步失败说明 Webhook URL 不可达或 Moltbot 服务未运行。4.2 Moltbot 飞书 Skill 的启用与调试moltbot doctor的深度用法飞书 Skill 并非开箱即用它需要在moltbot.json中显式声明并启用。在skills节点下添加skills: { feishu: { enabled: true, verificationToken: FeiShuToken20260428, appId: cli_xxx, // 从飞书后台复制 appSecret: xxx // 从飞书后台复制 } }appId和appSecret是明文写入配置文件的这是飞书 SDK 的要求。为降低风险建议将moltbot.json的文件权限设为600chmod 600 ~/.moltbot/moltbot.json启用 Skill 后重启服务sudo systemctl restart moltbot-gateway此时moltbot doctor是你最强大的调试伙伴。它不仅能告诉你服务是否健康还能深入到 Skill 层# 1. 基础健康检查 moltbot doctor # 2. 深度检查飞书 Skill moltbot doctor --skill feishu # 3. 查看所有已加载的 Skill moltbot skills listmoltbot doctor --skill feishu的输出会包含Verification Token Match:true表示配置的 token 与飞书发送的token参数匹配App Credentials Valid:true表示appId和appSecret能成功调用飞书的auth/v3/app_access_token/internal接口获取访问令牌Webhook Endpoint Reachable:true表示 Moltbot 能从本机curl通自己的18789端口。如果其中任何一项为falsedoctor命令会给出精确的错误信息例如App credentials invalid: {code:10001,msg:invalid app_id or app_secret}。这比在journalctl里大海捞针高效得多。4.3 首条消息的“端到端”追踪从飞书客户端到 Linux 终端的完整链路当你在飞书中给 Bot 发送第一条消息如“你好”时整个链路如下飞书客户端→飞书服务器用户点击发送消息被加密上传至飞书服务器。飞书服务器→你的服务器飞书服务器根据 Webhook URL向https://ip:18789/webhook/feishu发送一个POST请求携带X-Feishu-Signature头用于验签和 JSON 格式的事件体。Moltbot Gatewaysystemd进程监听18789端口接收到请求后将其路由给feishuSkill。feishuSkill首先验证X-Feishu-Signature头计算sha256签名然后解析 JSON提取event.type如message和event.message.text消息内容最后将消息内容封装为一个标准的Agent输入提交给mainAgent。mainAgent根据moltbot.json中agents.defaults.model.primary指定的模型调用百炼 API生成回复文本。feishuSkill将mainAgent 的回复通过飞书message/v4API 发送回飞书服务器。飞书服务器→飞书客户端消息显示在聊天窗口中。要验证这个链路你需要同时打开三个终端窗口窗口1实时查看 Moltbot 日志journalctl -u moltbot-gateway -f -n 50当消息到达时你会看到类似INFO [feishu] Received message from user: cli_xxx...的日志。窗口2实时查看飞书 Skill 的详细处理日志moltbot logs --skill feishu --follow这里会显示验签过程、模型调用详情、回复发送状态。窗口3手动触发一次模型调用隔离网络问题moltbot agent --agent main --message 今天天气怎么样如果此命令能正常返回说明 Moltbot 与百炼的通信是通的如果失败则问题一定出在飞书 Webhook 或 Skill 配置上。提示在journalctl日志中如果看到ERROR [feishu] Signature verification failed99% 的原因是verificationToken配置不一致。请务必用cat ~/.moltbot/moltbot.json | grep verificationToken和飞书后台的值做逐字符比对注意空格和大小写。5. 故障排查黄金法则一份基于 37 次真实部署的排错矩阵在为不同客户部署 Hermes Agent/OpenClaw 的过程中我整理了一份高频故障的排错矩阵。它不按“症状-原因-方案”的线性罗列而是按排查的物理顺序组织确保你能在5分钟内定位到根因。排查层级检查项快速验证命令预期输出故障含义修复方案1. 网络层服务器能否被飞书服务器访问curl -I https://your-ip:18789/health(从本地执行)HTTP/1.1 200 OK服务未运行或防火墙阻断sudo systemctl start moltbot-gatewaysudo firewall-cmd --reload2. 协议层Moltbot 是否在监听 0.0.0.0ss -tuln | grep 18789tcp LISTEN 0 128 0.0.0.0:18789Gateway 配置错误编辑~/.moltbot/moltbot.json添加host: 0.0.0.03. 认证层百炼 API Key 是否有效moltbot models status --probeStatus: okKey 过期、额度用尽或地域不匹配重新创建 Key确认百炼控制台地域为“华北2北京”4. 配置层moltbot.json语法是否正确moltbot doctor✅ All checks passedJSON 格式错误、字段名拼写错误jsonlint ~/.moltbot/moltbot.json或用 VS Code 打开自动高亮5. 技能层飞书 Skill 是否启用并配置正确moltbot doctor --skill feishuVerification Token Match: trueverificationToken不一致严格比对飞书后台与配置文件中的 token6. 权限层SELinux 是否阻止了端口绑定sudo ausearch -m avc -ts recent | grep 18789无输出SELinux 策略拒绝sudo semanage port -a -t http_port_t -p tcp 18789这份矩阵的威力在于其可执行性。每一行都是一个可以在 30 秒内完成的原子操作。它摒弃了“检查网络”、“检查配置”这类模糊指令代之以精确的命令和预期结果。例如“检查网络”被拆解为“curl -I测试健康端点”因为健康端点是 Moltbot 自带的、无需额外配置的最简验证入口。另一个关键经验是永远不要相信“绿色对勾”。飞书后台的 Webhook “已启用”状态只代表飞书服务器最后一次心跳成功。它不保证你的服务器此刻在线也不保证 Moltbot 正在运行。真正的验证永远是curl你的 URL或者看journalctl里有没有新的Received message日志。最后分享一个血泪教训在 Rocky Linux 上systemd服务的RestartSec默认是 100ms。当 Moltbot 因配置错误而崩溃时systemd会以毫秒级频率疯狂重启迅速耗尽系统资源导致journalctl无法访问ss命令卡死。此时唯一的救命稻草是sudo systemctl stop moltbot-gateway然后sudo systemctl edit moltbot-gateway在[Service]区块下添加RestartSec10 StartLimitIntervalSec60 StartLimitBurst3这表示每次重启间隔至少 10 秒60 秒内最多重启 3 次。这样你就有充足的时间去编辑配置文件、运行moltbot doctor而不会被失控的重启风暴淹没。部署完成的那一刻你得到的不仅是一个能响应飞书消息的 Bot更是一个可审计、可扩展、可融入你现有 DevOps 流程的 AI 自动化基座。它不再是一个黑盒应用而是一套你完全掌控的、运行在自己 Linux