OpenCode 中的 Jev
OpenCode 说 MCP,而 Jev 提供一个开源 MCP server —— 所以把两者接起来只需一条命令。你的 OpenCode agent 会获得一个类型化决策工具:可在任务中调用的校准 choice / score / noul。
每个示例都需要一个 jv_live_ key。在 pricing 页领一个,导出为 JEV_API_KEY,就可以开始了。 获取 key →
OpenCode 是一个开源编码 agent,和每个 agent 一样,它在循环里花了惊人多的时间做小而结构化的决策:这是不是对的文件、这次工具调用安不安全、这个测试失败要不要紧、这几种方案哪个胜出。用自由文本推理来做又慢又不一致。Jev 给 OpenCode 一个可以毫秒级调用并直接分支的类型化决策工具,于是 agent 把模型预算留给真正的编码。
加上 Jev MCP server
jev-mcp 用 npx 直接从 GitHub 运行 —— 无需 clone、无需 build。把 OpenCode 的 MCP 配置指向它,并设好你的 key。
{
"mcp": {
"jev": {
"type": "local",
"command": ["npx", "-y", "github:codaaiteam/jev-mcp"],
"environment": { "JEV_API_KEY": "jv_live_..." }
}
}
}这就是全部配置 —— jev-mcp 会把 jv_live_ key 自动路由到托管网关,所以没有 endpoint 或模型要配。重启 OpenCode,Jev 工具就会出现在 agent 的工具集里。
它给 agent 带来什么
加载后,agent 每当需要一个可编程据以行动的决策时,就能把 Jev 当工具调用:
- classify —— 把一个输入归入你的某个类别
- score —— 在你定义的有序刻度上打分
- check —— 一个带概率的校准是/否(noul)
- gate —— 在有风险的操作运行前 allow / confirm / block
因为答案是类型化、校准过的,agent 依据一个概率分支,而不是重读自己的散文 —— 循环更快、格式错误更少。一个校准过的 score 还让你能设真实阈值:只在置信度确实低时才上报给人,置信度高时自动继续,并在底层模型更换时保持这一行为稳定。
为什么类型化决策胜过第二次 LLM 调用
一个常见替代做法是让 agent 再调用另一个 LLM 来"决定"。这行得通,但它慢(数秒)、贵(每百万输出 token 数美元),而且返回你仍得解析的散文 —— 还可能把格式幻觉出来。Jev 在 70–500ms 内作答,约每次决策 $0.001,输出免费,而且物理上无法产出无效类型:一个 choice 只返回你的某个 key,别无其他。对于 agent 循环里的高频决策,这一差距会迅速累积。
说明
同一个 jev-mcp server 在 Claude Code、Cursor、Codex 和任何 MCP 客户端里都能用 —— 那个变体见 Claude Code 指南,或看 agent-skill 页了解与客户端无关的安装。
常见问题
我怎么把 Jev 加进 OpenCode?
把 jev-mcp 加进 OpenCode 的 MCP 配置,作为一个本地命令(npx -y github:codaaiteam/jev-mcp),并在环境里带上 JEV_API_KEY,然后重启。Jev 的 classify/score/check/gate 工具就会出现在 agent 的工具集里。
我需要自己托管什么吗?
不需要。jev-mcp 通过 npx 在本地运行并调用托管的 Jev 网关;模型本身留在 TypeSafe 的基础设施上。你只需要一个 jv_live_ key。
为什么用 Jev 而不是在循环里再做一次模型调用?
速度、成本和可靠性。Jev 在 70–500ms 内作答,约每次决策 $0.001,输出免费,并返回一个不会格式错乱的类型化值 —— 而不是一次慢速、更贵、返回你还得重新解析的散文的 LLM 调用。
这在其他 agent 里能用吗?
能 —— jev-mcp 是标准 MCP server,所以在 Claude Code、Cursor、Codex 和任何 MCP 客户端里都能用。只是配置文件格式不同。