13万人围观这条帖子:你的本地AI为什么「蠢得像石头」?答案可能跟模型无关

一条帖子，戳中了本地 AI 用户最大的痛点

Sudo su（@sudoingX）在 X 上发了一条帖子，直接把本地 AI 社区的老争论翻了个底朝天。

他说的大意是：跑本地 AI，真正值得花心思的地方在模型外面那一层——agentic harness（智能体运行框架）。

“choose your agentic harness carefully. it matters more than the model.”

「认真选你的 agentic harness，这比模型更重要。」

“the issue might not have been the model. it might have been the harness wrapping it.”

「问题可能不在模型，可能在包住模型的那个框架。」

▲ @sudoingX 的帖子引发 13 万人围观，1700+ 点赞，110+ 回复

这条帖子的互动量说明了一件事：大量本地 AI 用户正在经历同样的困惑——明明模型参数够大、量化也合理、显存也够用，跑起来就是拉胯。

“模型太笨”——这个归因可能搞错了方向

在本地 agent 场景下，失败通常长这样：

• 模型找不到工具，或者调用参数格式不对
• 跑了几十轮，任务还是完不成
• 上下文信息跑着跑着就”忘了”
• 在错误的目录执行了命令
• 没有任何确认就执行了危险操作
• 一步出错，整个任务链全崩

用户看到这些失败，第一反应都是”模型太笨”。但仔细拆解就会发现，很多失败发生在模型之外：工具的 schema 怎么呈现给模型、工具执行结果怎么回灌、调用失败后怎么重试、会话状态怎么保持、文件系统边界怎么限定——这些全都是 harness 层的职责。

回复里有位用户 @m13v_ 说得很精准：

“tool-call formatting, retry loops, and context management do most of the heavy lifting.”

「工具调用格式化、重试循环、上下文管理——这三样才是在真正干活。」

这句话的意思很清楚：模型只是 agent 系统中的一个变量，harness 才是让这个变量发挥作用的执行层。

所以 agentic harness 到底是什么？

说白了，agentic harness 就是模型外面的操作系统层。它负责把 LLM、工具、文件系统、浏览器、终端、审批机制、记忆系统、项目上下文、子代理、远端执行环境全部连接起来，形成一个可运行的整体。

帖主推荐的 Hermes Agent（Nous Research 的开源项目）恰好把 harness 的构成展示得很清楚。项目 README 列出了一张功能表：

• 真实终端界面
  
  （TUI），直接在终端操作
• 消息网关
  
  ：Telegram / Discord / Slack / WhatsApp / Signal / CLI 多入口
• 记忆系统
  
  ：跨会话的持久记忆 + 全文搜索
• 技能系统
  
  （Skills）：agent 自己创建和改进的技能
• 子代理
  
  （Subagents）：可以派出独立的子 agent 并行处理任务
• RPC 工具调用
  
  ：Python 脚本直接通过 RPC 调用 agent 工具
• 六种终端后端
  
  ：本地 / Docker / SSH / Daytona / Singularity / Modal
• 定时任务
  
  （Cron）：自动化调度

▲ Hermes Agent 的 GitHub 仓库页面

▲ Hermes Agent 官方文档，列出了从安装到高级功能的完整入口

这个功能表最有价值的地方在于：它用一个真实项目回答了”现代 agent harness 到底包含什么”。答案远远超出了”把模型接到聊天框”的范畴。

为什么本地模型更吃 harness 质量？

这里有一个容易被忽略的逻辑：云端前沿模型可以靠更强的推理和指令跟随能力，弥补 harness 的粗糙；但本地的 8B / 27B / 量化模型，在工具调用、长上下文、多轮规划方面更容易暴露格式和状态管理的问题。

换句话说，GPT-4o 或 Claude 可能在一个做工粗糙的框架里也能凑合完成任务。但你拿一个 Qwen 27B q4 或者 Nemotron q8 去跑同样的任务，harness 层的每一个毛糙之处都会被放大——工具描述不够清晰？模型直接调不对。重试机制没有？一步失败全盘崩。上下文管理缺失？跑了五轮模型就忘了前三轮在干嘛。

这也解释了帖主的那个核心经验：有人从其他框架切到 Hermes Agent 之后，同一个本地模型表现突然变好了。帖主自己称他在单张 3090 上用 Hermes 驱动 Qwen 3.6 27B dense q4，在 DGX Spark 上驱动 Nemotron Omni q8，覆盖了编程、调研、视频剪辑和自动化等任务。这些都是个人经验陈述，没有经过标准 benchmark 验证，但它指向了一个值得重视的信号：harness 的质量，对本地模型来说可能是一个放大器。

执行环境：被忽视的能力边界

讨论里还暴露了另一层问题：执行环境本身就是 agent 的能力边界。

帖主在回复中详细描述了他的本地 agent 工作方式：

“tmux is the separation layer… one per project + one per active model… own working dir + memory context.”

「tmux 做隔离层，一个项目配一个 Hermes session，各自拥有独立的工作目录和记忆上下文。」

“run hermes in a docker container or separate user account… scope it to a single project dir, watch every tool call before it fires.”

「把 Hermes 跑在 Docker 容器或独立用户账号里，限定到单个项目目录，每次工具调用前都观察审批。」

这就是很多人忽略的地方——本地 agent 不是”下载模型就开干”。它是模型、显存、容器、工作目录、文件权限、工具集共同组成的系统工程。模型只占其中一个位置。

Hermes README 列出的六种终端后端（本地 / Docker / SSH / Daytona / Singularity / Modal）也印证了这一点：执行环境的选择和隔离，是 harness 层面的核心能力。

行业信号：OpenAI 也在把 agent runtime 当基础设施建

这个趋势还有一个重要的参照系：OpenAI 的 Agents SDK 文档。

OpenAI 把 Agents SDK 定义为构建 agentic AI 应用的轻量级框架，核心 primitives 包括：

• Agent loop
  
  ：内置的 agent 循环，处理工具调用、把结果回传 LLM、持续运行直到任务完成
• Tools
  
  ：hosted tools、function tools、MCP server 调用、agents-as-tools
• Sessions
  
  ：跨会话的状态管理
• Sandbox agents
  
  ：隔离运行环境
• Guardrails
  
  ：输入/输出验证和安全检查
• Tracing
  
  ：可观测性和调试

▲ OpenAI Agents SDK 文档将 loop、tools、sessions、sandbox、guardrails 列为 agent runtime 的核心组件

OpenAI 还在 MCP 文档中引用了一个类比：MCP 是”AI 应用的 USB-C 接口”——一个标准化的协议，让应用可以统一向 LLM 提供工具和上下文。

更值得注意的是，OpenAI 文档明确区分了Responses API 和 Agents SDK 的适用场景：前者适合短流程、自己管 loop 和工具调度；后者用于 runtime 管理 turns、tool execution、guardrails、handoffs、sessions 和 real workspace。这种区分本身就说明：agent 应用的关键层已经被行业文档系统化为 loop、工具执行、会话管理、沙箱和安全防护——讨论的焦点早就不只是”用哪个模型”了。

争议和限制：harness 能做的也有天花板

帖子的回复区并不是一边倒的吹捧。社区的真实反馈暴露了明确的限制：

硬件仍然是硬门槛。多条回复指出 24GB VRAM 和 8GB / 10GB VRAM 的体验差异巨大。有人直言：低显存下跑 agent，体验就是”dumb as a rock”（蠢得像石头）。harness 做得再好，显存不够、上下文放不下、模型本身工具调用能力弱，agent 体验照样崩。

平台适配差异明显。有用户反馈 Mac / MLX 上部分 Qwen 变体和 Hermes 的工具不匹配。不同 runtime、不同 backend、不同模型变体之间的兼容性问题依然存在。

学习曲线不低。有人表示 Hermes 想法有趣但还不够好用，需要投入不少时间学习。也有人抱怨 TUI 不支持 LaTeX、web UI 太基础。

安全问题不会因为”本地”二字消失。本地运行减少了数据外发风险，但 agent 一旦拥有 shell、浏览器、文件系统和 API key 的访问权限，仍可能误删文件、泄露密钥或触碰私人数据。回复里有人提出密码管理器和加密钱包同机运行的担忧——帖主的建议是 Docker 隔离 + 独立账号 + 单项目目录 + 工具调用审批，但这只是经验层面的建议。

框架之间也有取舍。用户 @zltnxyz 提供了一个平衡的视角：OpenClaw 的 gateway-first 架构在某些场景帮到了 Hermes 起初吃力的问题，但在简单 workflow 中 Hermes 更可靠。这说明 harness 领域本身还在早期演化，没有一个方案通吃所有场景。

一个正在成形的共识

回到最初的问题：你的本地 AI 为什么看起来”很蠢”？

这组讨论给出的答案是：本地 AI 的体验正在从”模型选择问题”扩展为”harness 与执行环境问题”。社区已经开始用 Hermes、OpenClaw 等工具的对比来讨论这个方向的变化。

把这些碎片拼在一起，一个更完整的图景正在浮现——本地 agent 的控制平面至少包含六个层：

• 工具协议层
  
  ：把浏览器、shell、代码执行、文件编辑、MCP server 呈现给模型，约束输入输出格式
• 执行环境层
  
  ：决定工具在本机、Docker、SSH 远端还是 serverless 容器中运行
• 状态与记忆层
  
  ：哪些信息放进 LLM 的上下文窗口，哪些作为本地状态保存
• 编排层
  
  ：单 agent、子代理、handoff、agents-as-tools、RPC 脚本如何协作
• 安全层
  
  ：哪些命令需要审批，是否隔离账号，是否允许访问密钥
• 可观测性与恢复层
  
  ：工具调用失败后是重试、回滚、暂停等待用户，还是让模型继续猜

这六层，全都在模型之外。全都是 harness 的职责。

harness 做不到让弱模型无限越级，显存、平台适配和用户工程能力仍然是硬约束。但如果你的本地模型在 benchmark 上看起来还行，实际跑任务却一塌糊涂——也许值得先看看模型外面那层”壳”。

— END —