OpenCode 2.0：后台子智能体加代码模式，Agent 开始自己编排 MCP 调用

OpenCode 2.0 发布，开源代码智能体的重大更新，主要三块：后台子智能体、代码模式（模型可编排 MCP 调用）、以及配套的 JS 与 Effect 客户端。

后台子智能体解决什么

单智能体做复杂任务时，上下文很容易被中间过程塞满：读文件、跑测试、看日志，全是噪声。子智能体把子任务隔离到独立上下文里，只把结论回传主线程。

这个模式在工程上很实用。主线程保持干净，子任务可以并行，失败也不污染主流程。

代码模式是更大的变化

过去 MCP 调用是一次一次的工具调用，模型逐个决策。代码模式让模型生成一段代码来编排多次调用，循环、条件、并发都在代码里表达。

好处是效率：十次调用可以用一段循环完成，不用十轮往返。坏处是可控性：一段代码里可能藏着危险操作，审核粒度从单次调用变成整段代码。

Effect 客户端

Effect 是 TypeScript 的函数式效果系统，处理错误、并发、资源释放。给它配客户端，说明项目在往工程化方向走，不只是个 CLI 玩具。

要小心的

代码模式意味着模型生成的代码会被执行。沙箱隔离、文件系统权限、网络出口白名单，这三样缺一不可。开源项目默认配置通常很宽松，上生产前必须收窄。

对比

这类工具现在很多，差别主要在上下文管理与权限模型。选型时先看它怎么处理「模型要删一个文件」这种请求，答案能说明很多问题。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

后台子智能体的价值在上下文隔离，主线程保持干净。代码模式效率高，但审核粒度从单次调用变成整段代码，沙箱和文件权限必须先收窄再上。

代码模式编排 MCP 确实比逐个工具调用省事，一次生成一串调用能把往返砍掉很多。代价是可审计性变差，中间步骤藏在生成代码里不好定位，我的做法是强制把每次调用的入参出参先落日志再执行。

子智能体隔离上下文这个思路对，主线程被读文件和测试日志塞满是最常见的问题。代码模式那块我还没想通，模型自己编排调用链，出错时怎么定位是哪一步返回值有问题，是不是得有完整轨迹落盘。