Open Interpreter 换成 Rust 编程代理后，重点变成了给模型换 harness

如果你对 Open Interpreter 的印象还停留在“用自然语言让 Python 操作电脑”，现在打开项目需要重新看一次身份。当前官方仓库已经是基于 Codex 的 Rust 编程代理，原 Python 项目指向另一个社区维护仓库。旧教程中的安装方式和对象，不能直接当成今天的同一产品。

这一版最值得研究的，是 harness：同一套本地工具，怎样以不同模型更熟悉的提示与调用格式呈现。对于正在做多模型编码代理的人，它给出了比“支持许多模型”更具体的改造位置。

模型看到什么，和工具在哪里执行，是两层

官方 harness 文档明确说明，它会改变模型侧的 system prompt、工具 schema、消息转换和回答处理，但保留 Open Interpreter 自己的运行时。

例如，某一种模型适合常规聊天工具调用，另一种需要特定的代码代理提示和工具定义。harness 负责组织这些输入，以及将回答转换成运行时能执行的动作。文件读取、修改或 shell 命令，仍交给本地运行时处理。

因此，选择名为 qwen-code 或 claude-code 的 harness，不是启动那个真实外部 CLI，也不是自动继承该产品的全部功能。官方在开头就把这个边界写清楚：它模拟模型面对的交互形状，实际执行由本项目完成。

当前文档列出 native、不同厂商风格的 harness 和 minimal 等模式。它们不是一串可以任意互换的标签。提供方的 wire_api 与 harness 要匹配，常见路径包括 responses、chat、messages，各自支持的组合有明确表格。

例如，文档中的 minimal 面向常规 Chat Completions 工具列表；某些厂商风格模式还组织专用系统提示、工具名称、工作目录背景或思考配置。工具调用最终都要回到运行时，不能只因为服务端“兼容聊天接口”，就推定每个模式都可用。

对于开发者，一种有意义的教学任务是保留同一个小仓库与修改目标，只改变模型接入和相应 harness，再比较执行日志中是否正确读取文件、提交工具参数、接回命令结果。这里是实验设计，不是本文已完成的模型效果比较。

README给出的交互入口是 i 或 interpreter，提供 /model 和 /harness，也支持共享 AGENTS.md、skills、MCP 与 ACP 等路径。你可以在已经拥有的开发工作方式里接入它，而不必只用某个独有配置格式。

不过，客户端开源与模型成本是不同层。当前代码采用 Apache-2.0，模型凭据、提供方权限和实际用量仍由所选服务决定；harness 调整也不能证明一个便宜模型就一定具有更好的编码效果。

我会把这一版推荐给想研究“模型请求怎样转成可靠工具动作”的开发者。先对照一个模式的提示、工具定义和返回处理，再看相同任务留下的代码差异，会比只比较模型名字更接近真实的代理工程问题。