模型已经启动，不代表 Agent 已经可用

本地部署大模型时，最容易被误判的成功标准是：服务能启动，聊天能返回，IDE 或终端也能连上。可一旦任务需要读写文件、执行命令、保留多轮状态，决定成败的就不再只是模型本身，而是夹在模型与工具之间的 Harness。它负责执行工具、保存状态、控制权限，再把工具结果和历史上下文重新喂回模型。只要其中一环没有对上，系统就可能停在“看起来像 Agent”的阶段。

这也是这份榜单最值得技术负责人注意的变化。它评估了 11 个开源 Harness，但依据是 OSI 认可的许可证、本地运行时文档、维护状态和安全控制，而不是现场成功率或延迟。换句话说，排名回答的是“哪些项目更容易被核查和部署”，并没有回答“哪个项目在你的代码库里最可靠”。本地 Agent 的问题因此从换一个更大的模型，转向确认整条工具调用链是否形成了契约。

兼容性其实是四个条件同时成立

第一道门是上下文预算。材料引用 Ollama 的文档指出，在低于 24 GiB 显存时，默认上下文可能只有 4k，24 到 48 GiB 时为 32k，48 GiB 以上才到 256k，而 Agent 和编码工具应至少获得 64,000 tokens。把 OLLAMA_CONTEXT_LENGTH 设置为 64000 是简单的配置动作，却不是免费的优化。更长的上下文会把显存、内存和推理成本提前暴露出来，设备预算不足时，所谓的“支持长上下文”只停留在配置文件里。

第二道门是工具调用协议，第三道门是消息模板，第四道门是服务 API。没有工具调用能力的模型只能完成聊天式补全。使用 llama.cpp 时，Pi 的文档还要求通过 --jinja 启用兼容的聊天模板，否则模型即使理解任务，也可能无法按 Harness 期待的格式返回工具调用。Codex CLI 则只接受 Responses API 的 /v1/responses 路径。于是，“支持 Ollama”并不等于“支持所有 Ollama 模型”，能启动也不等于能稳定执行工具。

榜单里的差异，实际是运行方式的差异

OpenCode 排在首位，材料显示它同时记录了 Ollama、LM Studio 和 llama.cpp 的路径，并提供较直接的启动方式。对需要在多种本地运行时之间切换的开发团队，这种覆盖比单一模型推荐更有价值。Goose 排名第三，优势在于本地运行文档最完整，覆盖 Ollama、LM Studio、Docker Model Runner、Ramalama 和 vLLM。Cline 则把人工审批放在默认流程中，并建议本地推理开启 Compact Prompt，适合不愿把文件和命令权限完全交给模型的团队。

Pi 代表了另一种取舍。它只保留 read、write、edit、bash 四个核心工具，减少了小模型需要理解的工具面，也支持 llama.cpp router 和 Ollama。但它没有内置权限系统，默认以用户权限运行，隔离要由部署者通过 Docker、微虚拟机或策略沙箱补上。Aider 又是不同路线：模型返回的是文本形式的编辑，而不是函数调用，因此它减少了对工具协议的依赖，却牺牲了一部分通用 Agent 的执行方式。OpenHands 对本地硬件的要求更明确，材料建议使用 Qwen3.6-35B-A3B，并指出需要 24GB 显存或 64GB 统一内存，最低上下文为 22,000、推荐 32,768。

真正该写进架构评审的是权限，而不是星数

这份材料中的星数很容易制造错误的确定感。OpenClaw 以 390,026 颗星位列榜单末位，Hermes Agent 有 246,697 颗星，Codex CLI 也超过 125,000 颗星，但星数没有提供工具调用成功率、延迟或安全性的证据。相反，一个项目在本地运行时上的文档是否清晰、许可证是否可接受、权限控制是否存在，才更接近企业部署的实际约束。即便是榜首项目，也不能仅凭排名替代目标代码库中的验证。

实际选型可以先做两轮筛选。第一轮固定模型、上下文、模板和 API，验证一次完整的读取、修改、执行、回传闭环，排除“能装但不能用”的组合。第二轮按风险决定权限：只读分析可以接受更轻的控制，写文件和执行 shell 则应要求人工审批或沙箱隔离，尤其不能因为本地运行就默认安全。Harness 的价值不在于把一个模型包装成 Agent，而在于把它的能力边界、状态变化和工具权限变成团队能够检查、复现和撤销的运行时规则。