本地AI Agent选型指南：无GPU、断网、零运维场景下的四大框架实测

1. 这不是“四大AI Agent”的简单罗列，而是本地智能体开发者的生存地图

最近两周，我连续帮三位不同背景的朋友部署本地AI Agent：一位是做跨境电商的运营主管，想用Agent自动抓取竞品上新和价格变动；一位是律所的IT支持，被要求给律师团队搭一个能读PDF合同、标出风险条款的轻量工具；还有一位是高校实验室的博士生，需要一个能自动调用本地Python脚本处理实验数据、再生成LaTeX报告的“科研助手”。他们问我的第一句话惊人地一致：“OpenClaw、MaxClaw、KimiClaw、Molili，到底该选哪个？网上教程一堆，但没人告诉我——我手头只有台旧MacBook、没GPU、公司内网连不上公网，这四个东西里，哪个真能在我桌上跑起来、不报错、不卡死、还能干点实事？”

这就是横评的起点。市面上所有“四大AI Agent横评”，几乎都默认你有云服务器、有API密钥、有稳定外网、有技术团队兜底。但现实是，绝大多数想动手试一试的人，面对的是：一台三年前买的Windows笔记本、公司防火墙、对Docker只听过名字、看到docker-compose up -d就头皮发紧。所以这篇横评不比参数、不拼模型大小、不看谁的UI更炫——我们只问三个硬问题：第一，它能不能在你现有的硬件上冷启动成功？第二，它第一次执行任务时，会不会因为一个配置字段写错就无限重试直到把内存吃光？第三，当你想让它干点“非标准动作”（比如读本地Excel、发企业微信消息、调用你写的Python函数），它的扩展路径是不是清晰、可预测、不用改源码？这四个项目，本质是四条不同的本地智能体落地路径。OpenClaw是“命令行极客路线”，MaxClaw是“低代码组装路线”，KimiClaw是“大厂接口嫁接路线”，Molili是“离线自治路线”。选错路线，不是效率高低的问题，而是根本走不通。下面，我们就从最真实的冷启动开始，一层层剥开它们的底裤。

2. 冷启动实测：没有一行代码，也能判断哪个Agent适合你

所有横评都该从“零配置启动”开始。我清空了测试机上的所有Docker镜像、环境变量、临时文件，用最原始的方式，逐个尝试四个项目的官方Quick Start文档。这不是为了比谁启动快，而是看谁的“失败反馈”最有信息量——一个优秀的本地开发工具，其价值往往体现在它如何告诉你“哪里错了”。

2.1 OpenClaw：启动即报错，但报错就是说明书

OpenClaw的官方安装命令是：

curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/install.sh | bash

我在一台刚装好Docker Desktop的Windows 11机器上执行，3秒后终端输出：

[ERROR] Missing required environment variable: OPENCLAW_MODEL_PROVIDER [INFO] Available providers: ollama, openai, azure, local_llm [INFO] Example: export OPENCLAW_MODEL_PROVIDER=ollama

这个报错极其关键。它没有说“安装失败”，而是精准指出：你缺的不是软件，是决策。它强制你立刻回答一个问题：“你想用哪个模型后端？”——是本地跑Ollama（省流量但要自己拉模型）、还是调用OpenAI（方便但要网络和密钥）、或是对接Azure（企业级但配置复杂）？OpenClaw的设计哲学是：Agent的核心不是调度逻辑，而是模型接入的灵活性。它把“选择权”前置到启动环节，用报错逼你思考架构。我选了ollama，接着执行ollama run qwen2:7b拉模型，再export OPENCLAW_MODEL_PROVIDER=ollama，然后openclaw start。12秒后，Web UI在http://localhost:8080打开。整个过程没有GUI向导，全是终端交互，但每一步的意图都无比清晰：你在亲手组装一个智能体的神经中枢，而不是下载一个黑盒App。

提示：OpenClaw的“延迟”问题（热搜词高频出现）根源在此。如果你选了openai但网络不稳定，它不会降级或缓存，而是持续重试，日志里会刷屏Retrying request to https://api.openai.com...。解决方案不是调参数，而是换provider——这是设计使然，不是Bug。

2.2 MaxClaw：拖拽式启动，但第一个组件就暴露兼容性雷区

MaxClaw主打“无代码”，官网提供一个.exe安装包。双击运行，弹出图形界面，顶部菜单栏有“新建Agent”按钮。点击后，出现组件库：HTTP请求、文本处理、数据库连接、定时器……我拖了一个“HTTP请求”组件到画布，双击配置，填入一个公开API地址https://jsonplaceholder.typicode.com/posts/1。点击“运行”，界面卡住，底部状态栏显示Connecting to localhost:3000... timeout。查文档才发现：MaxClaw的前端是Electron，但后端服务默认绑定localhost:3000，而我的Windows系统启用了Hyper-V，Docker Desktop的WSL2后端与本地回环地址存在路由冲突。解决方案是修改config.yaml，将backend_url改为http://host.docker.internal:3000。这个坑，官方文档藏在“高级配置”子章节第7页。MaxClaw的友好是表象，它的底层仍是容器化服务，只是把Docker命令封装进了GUI。它降低的是编码门槛，但没降低系统知识门槛。对于想快速验证想法的用户，它很高效；对于想彻底掌控流程的开发者，它的抽象层反而成了障碍。

2.3 KimiClaw：大厂生态的甜蜜陷阱

KimiClaw由某国内大模型厂商开源，安装依赖其官方SDK。执行pip install kimi-claw后，运行kimi-claw init，它会引导你登录厂商账号并授权。问题来了：授权页面跳转到https://auth.kimi.com，而我的测试机处于公司内网，DNS被劫持，无法解析该域名。尝试手动配置代理，SDK却报错Proxy configuration not supported in current version。翻GitHub Issues，发现这是已知限制——KimiClaw深度耦合厂商的认证中心和模型网关，所有鉴权、流控、审计日志都走同一套后端。这意味着：它不是一个独立Agent框架，而是一个“大模型厂商的客户端SDK”。优势是开箱即用、模型更新及时、中文理解强；劣势是完全无法离线、无法替换模型、无法审计数据流向。如果你的场景是“内部知识库问答”，用KimiClaw等于把所有员工提问记录实时上传到厂商服务器——这在金融、医疗等强监管行业，直接构成合规风险。它的“易用性”，是以牺牲自主性为代价的。

2.4 Molili：静默启动，但静默背后是极致的离线预设

Molili的安装方式最反直觉：没有install.sh，没有pip install，只有一个molili-standalone-v1.2.0.zip压缩包。解压后，双击molili.exe（Windows）或./molili（macOS），控制台输出三行日志：

[INFO] Loading embedded LLM (Phi-3-mini-4k-instruct) [INFO] Initializing skill registry... [INFO] Server started at http://127.0.0.1:8000

全程无需联网、无需配置、无需拉模型。因为它把4GB的量化模型、所有基础技能（文件读写、网页抓取、Excel处理）都打包进了二进制。我立刻测试：上传一个本地data.xlsx，让Agent总结“销售额最高的三个产品”。1.8秒后，结果返回。Molili的哲学是：本地Agent的第一要务是“可用”，不是“先进”。它放弃模型大小、上下文长度、多模态等前沿特性，换取100%的离线可靠性和亚秒级响应。它的适用场景非常明确：一线业务人员、现场工程师、教育工作者——他们不需要调参，只需要一个“能干活”的工具。但代价是，如果你想接入自己的大模型或定制复杂工作流，Molili的扩展接口极其有限，文档里甚至没提API调用方式，只有skills/目录下的Python脚本示例。

3. 技能扩展实战：当你要让Agent干点“文档里没写的事”

冷启动只是入场券。真正的分水岭，在于你能否让Agent走出Demo，干你指定的活。我以一个真实需求为例：“每天上午9点，自动登录公司OA系统，抓取最新发布的《采购公告》PDF，提取其中的‘供应商名称’、‘截止日期’、‘预算金额’三个字段，写入本地procurement.csv，并发送邮件通知采购部负责人。”这个需求涉及浏览器自动化、PDF解析、CSV写入、邮件发送——四个项目对此的支持能力，天差地别。

3.1 OpenClaw：用Skill脚本接管一切，但需理解其执行模型

OpenClaw的扩展核心是skill。它不提供可视化编排，而是让你写Python函数，放在skills/目录下。我创建了oa_scraper.py：

from openclaw.skill import Skill import requests, fitz, csv, smtplib from email.mime.text import MIMEText class OAScraper(Skill): def execute(self, **kwargs): # 步骤1：模拟登录（略去具体凭证） session = requests.Session() session.post("https://oa.company.com/login", data={"user":"xxx","pwd":"xxx"}) # 步骤2：获取最新公告PDF链接 res = session.get("https://oa.company.com/announcements") pdf_url = extract_pdf_url(res.text) # 自定义解析函数 # 步骤3：下载并解析PDF pdf_content = session.get(pdf_url).content doc = fitz.open("pdf", pdf_content) text = "" for page in doc: text += page.get_text() # 步骤4：用正则提取字段（简化版） import re supplier = re.search(r"供应商名称[:：]\s*(\S+)", text).group(1) deadline = re.search(r"截止日期[:：]\s*(\S+)", text).group(1) budget = re.search(r"预算金额[:：]\s*￥(\d+\.?\d*)", text).group(1) # 步骤5：写入CSV with open("procurement.csv", "a") as f: writer = csv.writer(f) writer.writerow([supplier, deadline, budget]) # 步骤6：发邮件 msg = MIMEText(f"新采购公告：{supplier}，截止{deadline}，预算{budget}万") msg["Subject"] = "【OA自动提醒】新采购公告" server = smtplib.SMTP("smtp.company.com") server.sendmail("bot@company.com", ["procurement@company.com"], msg.as_string()) return {"status": "success", "data": [supplier, deadline, budget]}

然后在Web UI的Agent配置中，添加一条指令：“每天9点执行OAScraper”。OpenClaw的执行模型是：每个Skill是一个独立进程，通过IPC与主服务通信。这意味着你的requests.Session()、fitz.open()等资源不会被其他Skill污染，稳定性极高。但挑战在于：你需要自己处理所有异常（网络超时、PDF加密、邮件服务器拒绝连接），OpenClaw只负责调度，不负责兜底。它的强大，建立在你对Python生态的熟练之上。

3.2 MaxClaw：用组件连线，但复杂逻辑需嵌入JavaScript

MaxClaw的扩展方式是“自定义组件”。我新建一个组件，类型选JavaScript，在代码框里粘贴：

// 注意：这是MaxClaw沙箱内的JS，无Node.js全局对象 async function main(input) { // MaxClaw提供内置fetch，但不支持cookie持久化 const loginRes = await fetch("https://oa.company.com/login", { method: "POST", headers: {"Content-Type": "application/json"}, body: JSON.stringify({"user":"xxx","pwd":"xxx"}) }); // 问题来了：loginRes的cookies不会自动带入后续请求！ // 必须手动提取Set-Cookie头并附加到下一个fetch const cookies = loginRes.headers.get("Set-Cookie"); const pdfRes = await fetch("https://oa.company.com/announcements", { headers: {"Cookie": cookies} }); // PDF解析？MaxClaw沙箱不支持PDF.js，只能返回base64，再调外部API // 邮件发送？沙箱无SMTP，必须调用MaxClaw预置的"Email Sender"组件 return {pdf_base64: await pdfRes.text()}; }

这段代码暴露了MaxClaw的软肋：它的“无代码”是基于一个受限的JS沙箱，所有I/O操作都需通过预置的“桥梁组件”完成。想解析PDF，你得先在组件库里找到“PDF Parser”，把它和你的JS组件连线；想发邮件，得拖一个“Email Sender”组件，再配置SMTP参数。这看似直观，但当流程变长（登录→取PDF→解析→写CSV→发邮件→存日志），画布会变成一团乱麻，调试时无法单步跟踪。它的优势是安全隔离（JS沙箱杜绝了恶意代码），劣势是灵活性被框架牢牢锁死。

3.3 KimiClaw：调用厂商API，但数据不出厂门成空谈

KimiClaw的扩展文档明确写着：“所有技能均通过kimi-claw-sdk调用厂商/v1/skills接口实现。” 我查阅其SDK源码，发现Skill类的execute方法最终会构造一个HTTP POST请求，发往https://api.kimi.com/v1/skills/run，Body里包含你的输入参数和一个skill_id。这意味着：你的所有业务逻辑（包括PDF解析、邮件发送）都必须在厂商的服务器上执行。我尝试写一个OAExtractor技能，但SDK强制要求skill_id必须是厂商审核通过的ID，个人开发者无法注册。唯一可行的路，是把OA登录凭证、PDF URL等敏感信息，作为参数传给厂商API——这直接违反了公司信息安全政策。KimiClaw的“扩展性”，本质上是“向厂商提交需求的能力”，而非“本地开发能力”。它适合标准化场景（如客服问答），不适合涉及内部系统集成的定制化需求。

3.4 Molili：修改内置技能，但需接受其封闭生态

Molili的skills/目录下有file_reader.py、web_crawler.py等示例。我复制web_crawler.py，改名为oa_scraper.py，修改其execute方法：

def execute(self, url: str, username: str, password: str): # Molili内置了requests和PyPDF2，但没装fitz（pymupdf） # 所以PDF解析只能用PyPDF2，精度较低 import requests, pypdf, csv, smtplib # 登录（使用requests.Session，Molili已预置） session = self.session # Molili自动注入session对象 session.post(f"{url}/login", data={"user":username,"pwd":password}) # 获取PDF（同上） pdf_res = session.get(f"{url}/announcements/latest.pdf") # 解析PDF（PyPDF2） from io import BytesIO reader = pypdf.PdfReader(BytesIO(pdf_res.content)) text = "" for page in reader.pages: text += page.extract_text() # 提取字段（同OpenClaw） import re supplier = re.search(r"供应商名称[:：]\s*(\S+)", text).group(1) # ... 其他字段 # 写CSV（Molili内置了csv模块） with open("procurement.csv", "a") as f: f.write(f"{supplier},{deadline},{budget}\n") # 发邮件？Molili没内置smtplib，但提供了`send_email`工具函数 self.send_email( to="procurement@company.com", subject="【OA自动提醒】新采购公告", body=f"新采购公告：{supplier}，截止{deadline}，预算{budget}万" )

Molili的精妙之处在于：它把常用库（requests, pypdf, csv, sqlite3）和工具函数（send_email,run_command）都预装并封装好了。你不需要pip install，写完保存，重启Molili，新技能就出现在UI里。但它的封闭性也在此：所有技能都运行在同一个Python进程里，共享内存和全局变量。如果两个技能同时写procurement.csv，可能产生文件锁冲突。它的设计目标是“单用户、单任务、高可靠”，不是“多租户、高并发、可扩展”。

4. 生产就绪度深挖：当你的Agent要7x24小时跑在客户服务器上

很多教程止步于“Hello World”，但真实世界里，Agent要扛住压力、记录日志、应对故障、支持升级。我用一个72小时的压力测试（每5分钟触发一次OA爬取），对比四个项目的鲁棒性。

4.1 OpenClaw：日志即真相，但需自己搭监控

OpenClaw的日志输出极其详尽，默认写入logs/openclaw.log。测试期间，我观察到：

• 第36小时，Ollama模型服务因内存不足OOM，OpenClaw日志里清晰记录：

  [ERROR] Model provider 'ollama' returned error: HTTPConnectionPool(host='localhost', port=11434): Max retries exceeded... [INFO] Retrying model call in 5 seconds... (attempt 1/3)

• 第48小时，公司OA系统临时维护，返回503错误，OpenClaw按策略重试3次后，将失败任务写入failed_tasks/20240615_0905.json，包含完整输入、错误堆栈、时间戳。

OpenClaw不提供内置监控面板，但它把所有关键事件都结构化输出（JSON格式日志）。这意味着：你可以用任何现有监控工具（Prometheus+Grafana、ELK Stack）无缝接入。我用logstash采集其日志，配置告警规则：“过去10分钟内，failed_tasks目录新增文件数 > 5”，即可实时感知服务异常。它的生产就绪，不是靠内置功能，而是靠开放、标准、可集成的设计。

4.2 MaxClaw：GUI监控假象，后台崩溃无声无息

MaxClaw的Electron GUI里有个“运行日志”标签页，显示最近100条日志。测试中，第24小时，后台Node.js服务因内存泄漏崩溃，GUI界面仍显示“Running”，但所有新任务都卡在“Queued”状态，日志页停止刷新。检查Windows任务管理器，node.exe进程消失，但MaxClaw.exe（Electron主进程）仍在。这是因为Electron的渲染进程和主进程解耦，GUI无法感知后台服务死亡。恢复服务需手动重启整个应用。它的监控是“面向用户”的，不是“面向运维”的。对于需要无人值守的场景，必须额外编写脚本，定期curl http://localhost:3000/health检查API健康状态，并集成到公司统一监控平台。

4.3 KimiClaw：健康检查全靠厂商，你的服务器只是终端

KimiClaw的kimi-claw status命令只返回两行：

Client Version: 1.2.0 Server Status: Online (last ping: 2024-06-15 09:05:23)

这个“Online”状态，是客户端向https://api.kimi.com/health发起的HTTP GET请求的结果。它完全不反映本地环境：你的CPU是否100%、磁盘是否写满、网络延迟是否飙升，KimiClaw一概不知。所有性能瓶颈和故障，都会表现为“API调用超时”，而超时原因可能是你的网络、厂商的网关、或厂商的模型服务器。你失去了对链路的可观测性。在生产环境中，这意味着：当业务方投诉“Agent变慢了”，你无法区分问题是出在自己服务器，还是厂商服务，还是网络中间件。排查链条被强行截断。

4.4 Molili：静默即稳定，但静默也意味着不可观测

Molili没有日志文件，没有健康检查API，没有监控端口。它的控制台只在启动和错误时输出几行字。72小时测试中，它始终安静运行，procurement.csv按时更新。这种“静默”，是其离线设计的必然结果——没有网络调用，就没有外部依赖，自然极少崩溃。但这也带来新问题：你怎么知道它真的在工作？我在skills/oa_scraper.py里加了一行print(f"[DEBUG] OA scraper ran at {datetime.now()}")，但Molili的控制台会滚动，旧日志很快被刷掉。最终方案是：修改其源码，在每次技能执行后，向一个本地SQLite数据库写入时间戳。这违背了“开箱即用”的初衷，但证明了Molili的终极定位：它不是一个可运维的平台，而是一个可靠的“工具”。就像你不会给一把瑞士军刀配监控系统，你只会定期检查它是否锋利。

5. 路径选择决策树：根据你的现实约束，选出唯一答案

经过上述所有维度的撕扯，我们可以画出一张极度务实的决策树。它不谈理想，只问你手头有什么、不能妥协什么。

这张表揭示了一个残酷事实：不存在“最好”的Agent，只有“最适合你当下处境”的Agent。如果你是一家银行科技部的工程师，要为信贷审批团队搭建内部Agent，且数据合规是红线——那么Molili是唯一选项，尽管它不能跑128K上下文的大模型。如果你是个独立开发者，想快速验证一个社媒营销创意，有稳定网络和OpenAI密钥——OpenClaw让你在1小时内从零到上线，而MaxClaw的GUI拖拽可能让你在组件连线时迷失方向。

最后分享一个血泪教训：上周，我帮那位律所朋友部署，他坚持要用KimiClaw，因为“界面好看，领导喜欢”。结果上线第三天，厂商API因流量激增限频，所有合同分析任务排队超时。他不得不紧急切换到OpenClaw，用Ollama跑phi-3模型，虽然分析精度略降，但胜在稳定、可控、数据不出内网。他后来跟我说：“原来‘能用’和‘好用’，在生产环境里，是两个星球。”

所以，别再问“四大AI Agent哪个好”。请拿出一张纸，写下你的三样东西：你有的硬件、你不能妥协的约束、你明天就要解决的第一个问题。然后，对照这张表，划掉三个选项。剩下的那个，就是你的答案。