OpenCode v1.17.4 发布 —— MCP 的成熟之路：从可用到可靠
之前：MCP 的「能用」妥协
在 v1.17.4 之前，用 opencode 跑本地 MCP server 有不少暗坑。
本地 server 启动目录不可控。 你在一个 monorepo 里配了 MCP server，它实际启动时用的是 opencode 进程的 cwd，而不是你 workspace 的根目录——意味着 server 里所有相对路径引用都可能是错的。解决方式要么在配置里写死绝对路径（不可移植），要么在启动前手动 cd 到正确目录（不可脚本化）。
认证头被静默丢弃。 MCP server 配置了 auth headers，但某些 debug 请求和认证流程中这些 headers 被无声地丢掉了。你在日志里看到「401 Unauthorized」，排查半天发现自己明明配好了 token——实际上 token 根本没发出去。
Catalog 超时形同虚设。 MCP catalog 的请求超时配置是存在的，但当 server 列出 prompts、resources 或 tools 时，这个超时并不生效。如果你的 MCP server 在 catalog 响应上特别慢（比如需要远程拉取动态工具列表），就会陷入无上限的等待。
快照创建在大仓库上如龟速。 每次创建 session 快照时，opencode 都会重新哈希仓库里的所有文件。几百个文件还好，几万个文件的 monorepo 上，一次快照能跑十几秒——如果你频繁切换 session，每天浪费在快照上的等待时间能累计到好几分钟。
内容过滤错误被吞掉。 模型因为安全策略拒绝回复时，你看到的是空白 response，没有任何错误信息。你不知道是模型崩了、网络断了、还是内容被 filter 了。排查方向一片漆黑。
现在：逐一填补，MCP 走向可靠
v1.17.4 的改进恰好对应了上面那些裂缝。
本地 MCP server 有了 cwd 支持。 现在你可以为每个 local MCP server 指定 cwd，让它从 workspace 相对目录启动。所有相对路径引用从 server 视角看都是正确的，配置也可以移植。个人觉得这是本次最有「工程味」的改进——它没有新增任何炫目功能，而是把一个隐含的假设（cwd == opencode 进程目录）改成了显式的配置项。这个假设之前是对的，但只在单项目场景下成立；一旦进入 monorepo 或多 workspace 编排，它就悄悄变成了 bug。
认证流程有了正式架构。 新增的 connector-based 认证流和 provider 凭据存储，给 MCP 认证提供了一个统一框架。之前 token 的管理方式是「各 server 自己想办法」——有写在环境变量里的、有硬编码在配置文件里的、有塞在启动脚本里的。现在 opencode 提供了存储和管理凭据的入口。同样重要的是，MCP auth headers 不再被 debug 请求丢弃——那条排查链路修通了。
Catalog 超时终于生效。 MCP catalog 请求的 timeout 配置现在会正确应用到 prompt、resource 和 tool 的列表请求上。如果你的 MCP server 在 catalog 响应上停顿，opencode 会在超时后干净地取消请求，而不是死等。这个修复和一个更隐含的问题有关：之前 timeout 配置「存在但不生效」的状态比没有 timeout 更糟糕——它会让你以为有防御机制，实际上毫无保护。
快照复用 Git 对象，大仓库不卡了。 这是本次我最欣赏的优化方向。Git 已经为每个对象算过哈希了——为什么快照还要重算一遍？v1.17.4 的做法是复用 source Git 对象，避免重复哈希。这个变化在中小仓库上几乎无感，但在几万文件的 monorepo 上，快照创建时间从十几秒降到一两秒。session 启动流程终于不再是「伸个懒腰等它好」的状态，而是「刚切过来就已经就绪」。
内容过滤错误不再沉默。 被安全策略拦截的模型响应现在会以可见的错误形式呈现，而不是静默吞掉。这个改动看着小，但对排查效率的提升很直接——之前遇到模型拒绝回复，你得怀疑模型本身、网络层、token 配额、prompt 触发 filter 四个方向，现在错误告诉你「被 content filter 拦截了」。虽然结果都一样是没输出，但至少你知道下一步该调整 prompt 而不是重启网络。
API v2 的雏形
v1.17.4 还新增了 v2 API 端点：创建和查询 session、列出 session 问题、解析 active location。表面上是给 SDK 客户端准备的，实际上这是一步基础设施搭建——openCode 之前操作 session 的能力分散在 TUI、桌面和 CLI 各自实现里，没有统一的 API 接口。v2 端点的出现意味着第三方集成（CI 流程、自定义前端、监控面板）有了正式的对接入口，不再需要绕过内部接口。
同批还修复了文件读取的 content type——API 和 SDK 客户端现在能拿到正确的原始内容和 MIME 类型，这对于在自定义前端里渲染文件内容而言是基础性修复。
Gemini 工具兼容与生态修复
v1.17.4 修复了 Gemini 工具 schema 中多类型字段导致的兼容问题。如果你在用 Gemini 模型并配置了 MCP tools，之前某些工具会因为 schema 格式不被兼容而过早崩溃。这个修复让 Gemini 用户的 MCP 工具调用回归了正常——不需要改配、不需要降级，升级即可。
升级方式
# 一键安装（推荐）
curl -fsSL https://opencode.ai/install | bash
# npm
npm i -g opencode-ai@latest
# Homebrew
brew install anomalyco/tap/opencode
# Windows
scoop install opencode
choco install opencode
# Arch Linux
sudo pacman -S opencode
# 也支持 brew 直接安装
brew install opencode
一个版本没有新增任何一个炫目功能，却可能是 MCP 在 opencode 上「真正可用」的转折点。cwd 支持、认证流集成、超时修复、快照复用、错误可见——每一条都是之前体验中的隐性摩擦。v1.17.4 没有发明新东西，它只是把这些摩擦逐个清除了。
完整更新日志：GitHub Release
📢 关注我，获取最新开源更新日志和开发者工具动态。
#OpenCode #MCP #AI编程 #快照优化 #开发者工具