devo：把本地代码搜索和多模型 agent 放进一个桌面运行时
AI 编程工具越多，另一个问题越明显：每个 agent 都想成为你的主入口，但代码搜索、模型配置、MCP server、prompt preset、任务记录和本地上下文经常分散在不同工具里。
你可以让一个工具负责聊天，一个工具负责代码搜索，一个工具负责 MCP，一个工具负责本地工作区。但当模型需要在同一个项目里来回切换、调用工具、查上下文、保存任务状态时，这种拼装会变得很脆。尤其是团队里既有 OpenAI-compatible endpoint，也有 Anthropic-compatible endpoint，甚至还在试 DeepSeek、Qwen、Kimi、GLM 这类模型时，工具链很容易被某一个 provider 绑死。
今天记录的 7df-lab/devo 试图把这些东西收在一个私有的 agent desktop/runtime 里。它不是一个单纯 chat UI，而是把 model-neutral API、MCP、skills、本地代码搜索、prompt preset、agent chain、任务管理和 TUI/桌面体验放到同一个 Rust 项目中。
按 GitHub repository page、README、Releases page、Tags page、LICENSE、Cargo.toml 和本地 git clone 在 2026-07-17 能核验的公开信息，7df-lab/devo 当前有 309 stars、130 forks。仓库主语言是 Rust，GitHub language breakdown 显示 Rust 72.2%、TypeScript 23.8%、SCSS 3.0%、JavaScript 0.7%、CSS 0.2%。许可证是 MIT。由于匿名 GitHub REST API 已触发 rate limit，本文没有臆造 repository created_at，而是使用公开 Git 历史起点：首个提交是 8ca7321，提交时间 2026-04-01 00:40:39 +08:00。候选抓取时记录的最近 push 是 2026-07-16 04:13:00 UTC；默认分支 main 的最新提交是 3b5d9e7，提交时间 2026-07-16 12:12:42 +08:00，提交信息为 chore: upgrade to v0.1.30。GitHub Releases 当前 latest release 是 v0.1.30，Cargo.toml 中的 workspace version 也是 0.1.30。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | 7df-lab/devo |
| 定位 | model-neutral agent desktop/runtime，本地代码搜索和 MCP 工作台 |
| Stars | 309 |
| Forks | 130 |
| 主语言 | Rust |
| 语言占比 | Rust 72.2%、TypeScript 23.8%、SCSS 3.0%、JavaScript 0.7%、CSS 0.2% |
| 许可证 | MIT |
| 公开 Git 历史起点 | 2026-04-01 00:40:39 +08:00，首个提交 8ca7321 |
| 最近 push | 2026-07-16 04:13:00 UTC |
| 最新 main 提交 | 3b5d9e7，2026-07-16 12:12:42 +08:00 |
| Latest GitHub release | v0.1.30 |
| 当前版本 | 0.1.30 |
| 关键词 | Rust、coding agent、MCP、local code search、skills、model-neutral |
不把 agent 绑定到单一模型
devo 最值得看的第一点，是它从 README 一开始就把自己放在 model-neutral 的位置。
很多 AI 编程工具其实绑定了某个默认模型或某家 API。短期内这很省事，长期则会变成迁移成本：你想试另一个 provider，要么等工具官方支持，要么用一堆兼容层和环境变量绕过去。devo 的 README 明确提到 OpenAI-compatible、Anthropic-compatible、DeepSeek、Qwen、Kimi、GLM 等模型 API，这意味着它更像一个 agent runtime，而不是单一模型客户端。
这对个人开发者未必每天都重要，但对经常试模型、在公司内网接私有 endpoint、或者需要把不同任务分配给不同模型的团队来说，入口层保持中立很有价值。模型会换，agent 工作台最好不要跟着重写。
本地代码搜索和 MCP 放在同一张桌子上
第二个角度，是 devo 把本地代码搜索、MCP、skills 和 agent chain 放在同一个上下文里。
AI coding 的实际痛点不是“能不能发一句 prompt”，而是 agent 在做事时能不能拿到足够稳定的项目上下文。代码搜索如果在一个工具里，MCP server 配置在另一个工具里，技能和任务链又放在第三个地方，agent 的每一步都会增加上下文搬运成本。
devo 的方向更像是把这些基础能力变成同一个 runtime 的内部模块：agent 可以查本地代码，可以连接 MCP 工具，可以使用 skills，可以围绕 preset 和 chain 组织任务。对经常在多个仓库之间切换的人，这种集成比单独一个漂亮 chat box 更实用。
这里的重点不是说 devo 已经替代成熟 IDE，而是它承认了一个事实：coding agent 的底座不只是模型，还包括代码索引、工具协议、技能目录和可恢复的任务上下文。
Rust 桌面/runtime 的取舍
项目用 Rust 写，这也影响了它的气质。
从仓库结构和依赖看，devo 不是一个只靠前端堆起来的聊天页。它有 TUI、任务、工具、配置、keyring、network proxy、MCP client、update check 等模块，也有 TypeScript/SCSS 组成的界面部分。Rust 占比 72.2%，说明核心 runtime 主要在本地侧。
这类架构适合处理本地状态、密钥、代理、代码索引和工具调用，也更容易做成跨平台的桌面/终端工作台。代价是项目复杂度会比一个 Web UI 高，用户也需要接受它有自己的 runtime 习惯和配置体系。
适合什么人试
第一类人，是正在比较多个模型的开发者。你不想因为换模型就换整套 agent 工作流，devo 这种 provider-neutral 的入口值得看。
第二类人，是需要 MCP 和本地代码搜索的人。只聊天不够，你希望 agent 能围绕本地仓库、工具和技能做事。
第三类人，是对私有化更敏感的团队。devo 不是安全边界本身，但它把 agent runtime 放回本地机器或私有环境中，比完全依赖云端工作台更容易控制数据流。
第四类人，是喜欢 TUI/桌面混合工作流的程序员。它不是纯浏览器产品，适合愿意折腾本地工具链的人。
需要注意的地方
第一，项目还年轻。公开 Git 历史从 2026-04-01 开始，版本已经到 v0.1.30，迭代很快，也意味着接口和体验可能还会变。
第二，它的范围比较大。model runtime、代码搜索、MCP、skills、UI、任务链都放进来，很容易产生配置和认知成本。第一次尝试时，最好只拿一个非关键仓库验证本地代码搜索和模型配置。
第三，README 里的多模型支持不等于每个 provider 都有同样稳定的体验。不同 OpenAI-compatible endpoint 对 tool call、streaming、上下文长度和错误格式的兼容程度不同，实际使用前需要测试。
第四，GitHub REST API 匿名访问在这次核验中已限流，所以本文没有写 GitHub repository created_at。这里使用的是可从 git history 复核的公开历史起点；如果你要做供应链审计，仍应在有 token 的环境里复查 GitHub API 元数据。
总结
devo 有意思的地方，不是又做了一个 AI chat 客户端，而是把 coding agent 真正需要的几个底座放到一起：模型中立、本地代码搜索、MCP、skills、任务链和私有 runtime。
如果你的 AI 编程工作流已经开始在多个模型、多个仓库、多个 MCP server 之间切换，7df-lab/devo 值得放进观察列表。它适合的不是“打开网页问一句代码”的轻场景，而是想把 agent 变成本地开发工作台一部分的人。