opencode-rust
用 Rust 重写的开源 AI 编码代理，提供 CLI、TUI 与 HTTP 服务，无需 Docker。
- Star 数
- ★ 52
- 最近更新
- 2 天前
- License
- MIT
- 主语言
- Rust
- FA 评分
- 46/100 · 缺口较多
30 秒速览
- 可在哪里用
- 兼容但需适配OpenAI API · Claude API
- 开始前需要
- 典型场景
- 需要在本地终端里做仓库级代码阅读、修改与分析的开发者，希望用 TUI 而不是网页聊天。
- 主要局限
- run 从未在付费提供商上端到端验证，README 明言免费 OpenRouter 模型拒绝工具 schema、付费模型无额度返回 402。
- 源码审查
- 46/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
opencode-rust 是 OpenCode 的 Rust 实现，由一个包含 20 个 crate 的 Cargo workspace 组成，核心组件包括 opencode-cli（二进制 opencode 与代理别名）、opencode-server（HTTP/SSE/WebSocket 服务与 MCP 加载器）、opencode-session（会话提示循环）、opencode-agent、opencode-tool（22 个内置工具与注册表）、opencode-provider、opencode-mcp、opencode-plugin、opencode-lsp、opencode-storage（SQLite）与 opencode-tui。它通过 npm、Homebrew 或 install.sh 安装，统一以 opr 命令暴露交互式 TUI、单次执行的 run 子命令、serve HTTP 服务器、web、acp 等交互模式。设计动机是用 Rust 替换 TypeScript 引擎以解决内存与实例状态泄漏：对话历史写入 SQLite，工具 schema 按 (model, tool-set) 缓存，实例状态按配置哈希做 LRU+TTL 回收，因此不需要容器运行时。部署边界是本机进程：引擎会启动 Node 子进程运行插件桥、通过 npx 拉起 MCP 服务器，因此无论何种安装方式都要求 Node 18+，并需要自备模型提供商密钥。
引擎以 opr 命令启动：opr 进入交互式 TUI，opr run "..." 驱动与 HTTP 服务器相同的 SessionPrompt 循环，opr serve --port 3000 启动 HTTP/SSE/WebSocket 服务。会话循环把请求发给 opencode-provider 中的提供商适配器，解析流式工具调用，在 opencode-tool 注册表中解析并执行 22 个内置工具与 MCP 工具，权限按路径范围判定、最后匹配规则生效。工具侧通过 opencode-mcp 以换行分隔 JSON 的 stdio 或 HTTP 连接 MCP 服务器，通过 opencode-lsp 连接语言服务器，通过 opencode-plugin 以 Node 子进程承载 TypeScript 插件桥（sendNotification 反向通道按 params.requestId 关联）。会话、消息与分片存入 SQLite（sessions、messages、parts）。run 子命令会等待会话 idle、等待父 SQLite 中记录的子代理任务静止，并读取 .omo/run-continuation/<session>.json 的后台任务状态，超时默认 120 秒、失败时放行而非挂死。
- 需要在本地终端里做仓库级代码阅读、修改与分析的开发者，希望用 TUI 而不是网页聊天。
- 想要把编码代理作为 HTTP 服务嵌入自有工具链的团队，使用 opr serve 与 ACP/Web 模式。
- 对 Docker 运行时开销敏感、希望以单一本机二进制运行代理的工程师。
- 已经维护 OpenCode / oh-my-opencode 配置（opencode.json、~/.omo/omo.jsonc）并希望复用代理定义与模型的用户。
- 需要通过 MCP 服务器与 LSP 把外部工具与语言服务接入编码代理的场景。
如何安装或部署这个 Agent？
npm 方式（Linux、macOS、Windows，安装器不编译，按平台拉取预编译包）：
npm install -g opencode-rustHomebrew 方式（macOS 与 Linux，从源码构建，首次会拉取 Rust 工具链）：
brew install vakandi/tap/opencode-rust源码方式：
git clone https://github.com/vakandi/opencode-rust.git
cd opencode-rust
./install.sh # 构建 release 二进制并安装 opr；--force 强制重建运行前需 Node 18+，并设置提供商密钥：
export ANTHROPIC_API_KEY=sk-ant-...如何使用这个 Agent？
最简首次运行：
opr # 交互式 TUI
opr run "check this repo for risks" # 单条提示，运行到完成
opr serve --port 3000 # HTTP 服务器通过 npm 安装时 opr 是分发脚本，opr --some-flag 会被改写为 opencode tui --some-flag；通过 Homebrew 或 install.sh 安装时 opr 就是引擎二进制，需要写出子命令：
opr tui --some-flag查看数据位置与运行测试：
opr db path
cargo test --workspace这个 Agent 有哪些优点和局限？
- 单一本机二进制运行，不需要 Docker、cgroup 或容器运行时。
- 多提供商适配器（opencode-provider）加 MCP、LSP、TypeScript 插件桥，扩展面完整。
- MCP 修复后有实测数据：3 个服务器约 4 秒启动、77 个工具暴露给代理。
- 会话持久化在 SQLite，工具 schema 按 (model, tool-set) 缓存，实例状态按配置哈希 LRU+TTL 回收。
- run 子命令会等待子代理与后台任务结束，失败时放行而不是挂死。
- run 从未在付费提供商上端到端验证，README 明言免费 OpenRouter 模型拒绝工具 schema、付费模型无额度返回 402。
- 无论安装方式都依赖 Node 18+（插件桥与 npx 启动 MCP）。
- opr 的语义随安装渠道不同（npm 下是分发脚本，Homebrew/install.sh 下是引擎本体），容易误用。
- Homebrew 与源码安装需要 Rust 工具链，首次构建成本高。
- 20 个 crate 的 workspace 结构意味着上手需要理解多个组件与配置合并路径。
这个 Agent 与同类方案有什么区别？
README 将其定位为 OpenCode（原 TypeScript 引擎）的 Rust 实现，并直接对比两者：TypeScript 版本把对话历史放在内存、每个 LLM 步骤重算工具 schema、按目录维护不回收的实例状态，并用 Docker 运行时来容纳这些开销；Rust 版本改用 SQLite 持久化、schema 缓存与 LRU+TTL 回收，从而去掉容器。它声明与 OpenCode 团队无关联。
与相关度最高的同类 agent 并排比较关键指标。
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README 提到 opencode-permission 提供按路径作用域、最后匹配规则生效的权限层，docs/opencode-permission.md 也描述了 allow/deny/ask 与 PermissionAsk 钩子，但仅有设计描述，未见默认策略、确认流程或敏感数据（API key、会话内容）处理的具体实现证据，故 least_privilege、user_confirmation、sensitive_data_handling 均只给 1。数据流方面 README 说明会话落 SQLite、插件为 Node 子进程、MCP 经 npx 启动，但未说明数据外发边界，data_flow_transparency 给 1。依赖安全方面 Cargo.toml 固定了部分版本（nucleo-matcher、syntect、similar），但无审计或漏洞说明，dependency_security 给 1。外部效应与回滚：install.sh/clean.sh 有防误删与 --force 说明，但工具执行本身无回滚机制，external_effects 与 rollback 各给 1。source_attribution 有 LICENSE 与对 OpenCode 上游的明确致谢及非关联声明，给 2。
README 对 run 的排空逻辑、MCP 修复、TUI 缺陷有较细描述，但存在自相矛盾：README 称 npm 使用按平台拆分的二进制包，而 publish.yml 注释明确说平台包方案已被放弃、改为 release 资产由 install.js 拉取，self_consistency 扣至 1。依赖可用性方面要求 Node 18+ 与 npx，且 Homebrew 需 Rust 工具链，依赖链较重且未给出离线方案，dependency_availability 给 1。失败信息方面 README 描述了安装无匹配平台时打印替代方案并干净退出、drain 失败开放不挂起、TUI 显示 API 错误，failure_messages 给 2。
README 明确区分 TUI、run、serve、web、acp 多种场景与 build/plan 内置 agent，audience_and_scenarios 给 2。capability_boundaries 有 build 全权限与 plan 只读的区分，并说明 run 与 TUI 行为差异，给 2。trigger_precision 方面 opr 在不同安装方式下语义不同（npm 为 dispatcher、Homebrew 为引擎本体），同一命令行为不一致，扣至 1。environment_fit 覆盖 Linux/macOS/Windows 与多架构，给 2。
README 结构清晰、有仓库结构与 docs 索引，information_architecture 给 2。install_notes 详述 npm/Homebrew/源码三种方式及差异，给 2。naming_stability 存在 opr/opencode 双名与安装方式差异，扣至 1。examples_and_faq 有少量命令示例但无 FAQ，给 1。known_limitations 明确写出 run 未在真实付费 provider 上端到端验证，给 2。license 为 MIT 且文件完整，给 2。versioning_changelog 仅有 workspace 0.1.0 与 v* 标签发布，无 CHANGELOG，给 1。maintenance_responsibility 发布者未经验证，LICENSE 版权方与仓库 owner 不一致（opencode/ChrisFeldmeier 对 vakandi），维护责任不清，给 1。
output_usability 有 CLI 命令表、run 参数与配置路径，给 2。marginal_value 作为 OpenCode 的 Rust 重写，价值主张（无 Docker、SQLite 持久化）有说明但缺乏与上游的量化对比，给 1。cost_benefit 需 Node 运行时、Rust 工具链（Homebrew）与 provider key，成本不低而收益证据有限，给 1。
claim_traceability 方面 README 的修复叙述（MCP 三缺陷、TUI 宽度）指向具体代码但未给出提交或测试链接，给 1。cross_source_corroboration 仅 README、docs 与 workflow 相互印证部分内容，且 npm 打包方式存在矛盾，给 1。fact_inference_separation 较好，README 明确区分已测量与未验证（known limitation），给 2。
- README 与 publish.yml 对 npm 分发方式（按平台拆分包 vs release 资产）描述矛盾，安装行为需自行核实。
- opr 在 npm、Homebrew、install.sh 下语义不同，同一命令可能被拒绝或转发，脚本化调用前需确认安装方式。
- 权限层仅有设计文档，未见默认策略与确认流程的实现证据，高风险工具操作前应人工审查配置。
- LICENSE 版权方与仓库 owner 不一致且发布者未经验证，供应链与维护归属需谨慎对待。
- run 未在真实付费 provider 上端到端验证，工具执行与子代理排空的实际效果未经证实。