Opencode on Svtter's Blog

从 claude code 转向 omp/opencode

Tue, 02 Jun 2026 09:46:55 +0800

如果你不是在使用 claude 订阅，那么我建议你转向 omp（oh-my-pi）。

为什么

原因不复杂。目前按照 claude code 发展趋势和策略，claude 会朝向专用 agent 发展。每次 claude 更新都会遇到新的问题。Anthropic 接口虽然现在几个国内的厂商是兼容的，但是总归是有一定的时效。需要一定时间去 catch up 上游 Anthropic 的更改。

现状是 Anthropic 兼容 API 是厂商提供 coding agent/coding plan 的重要标准。但是实际上厂商也在转向。作为重要的组成部分，agent harness 一定要掌握在自己的手里。

opencode

如果喜欢 opencode，可以考虑使用 opencode。目前来说比较稳定，但是新功能开发不够快。

我之前写过很多 opencode 相关的文章，可以作为参考：

高效省钱：我的 AI Agent 工作流选择 — OpenCode + Gemini 的高性价比工作流
最近发现好用的 MCP 工具 — OpenCode/Claude Code 配套工具推荐
OpenCode 配置优化 — Token 和配置优化技巧
探索 opencode 之后，我的一些思考 — 三个月使用回顾与思考
opencode-actions - 一个 coding review agent — 基于 OpenCode 的 GitHub Action

omp

但是我现在更加推荐 omp。

omp 对于 /goal、/loop 以及 workflow 的支持都非常快速。

omp commit 的迭代频率非常高，基本每天都在更新。

Multi-Review：多 Agent 并发代码审查的工程实践

Fri, 29 May 2026 10:00:00 +0800

在上一篇文章中，我介绍了 opencode-actions——一个基于 OpenCode 构建的 GitHub Action，用来做自动化的 PR 代码审查。那个版本的 review action 用的是一个模型、一个 prompt，针对整个 PR diff 做一次综合审查。

这个方案能用，但有个明显的问题：一个 prompt 要同时关注代码质量、安全漏洞、性能问题和架构设计，每一项都不够深入。 就像让一个工程师同时扮演 QA、安全审计、DBA 和架构师——每个角色都能说两句，但都不专业。

Cloudflare 在今年四月发了一篇博客，详细介绍了他们用 OpenCode 构建的多 Agent 并发代码审查系统。他们用了 7 个专业 reviewer 加 1 个 coordinator，在 5169 个仓库上跑了 13 万次审查。核心思路是：不要让一个模型什么都看，而是让多个专业模型各看各的，最后用一个 coordinator 统一汇总。

看完这篇文章，我决定在 opencode-actions 中实现类似的能力。这篇文章就是 multi-review action 的设计记录。

为什么需要多 Agent 并发审查？

单模型审查的问题不只是"不够深入"。实际使用中有几个具体的痛点：

维度冲突：安全审查要求严格（宁可误报不能漏报），性能审查要求务实（关注可测量的指标而非理论风险）。一个 prompt 很难同时表达两种截然不同的审查哲学。
上下文稀释：当 prompt 中塞了太多"你要检查 A、B、C、D、E"时，模型的注意力被分散，每个维度的审查质量都打折扣。
结果模糊：一个模型输出的"有条件合并"到底是因为安全问题还是性能问题？很难区分。

Cloudflare 的做法是把审查拆成独立的维度，每个 reviewer 只关注自己擅长的领域。他们的 security reviewer 有明确的 “What to Flag” 和 “What NOT to Flag” 指令——告诉模型什么该忽略，比告诉它什么该检查更重要。

架构：并发 Reviewer + Coordinator

multi-review 的核心架构用一句话概括：N 个专业 reviewer 并发审查，1 个 coordinator 汇总去重。

整个流程是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


PR 触发 → 获取 diff
 ↓
 启动 OpenCode Server（单实例）
 ↓
 ┌───────────┼───────────┐───────────┐
 ↓ ↓ ↓ ↓
Quality Security Performance Architecture
(reviewer) (reviewer) (reviewer) (reviewer)
 └───────────┴───────────┴───────────┘
 ↓ (Promise.all)
 Coordinator
 (去重 + 交叉验证)
 ↓
 PR Comment

关键设计选择：

单 Server 多 Session：只启动一个 OpenCode Server 实例，所有 reviewer 和 coordinator 共享。这样避免了 N 个 reviewer 各自冷启动 MCP server 的开销。
Promise.all 并发：所有 reviewer 通过 Promise.all 同时启动，不排队。实际运行时间取决于最慢的那个 reviewer，而不是所有 reviewer 的总和。
全局超时 + 自适应余量：一个全局 deadline，每个 reviewer 的剩余时间 = max(30s, deadline - now)。先完成的 reviewer 不影响后面的，后面的 reviewer 自然获得更少的时间。

四个专业 Reviewer

默认启动四个 reviewer，每个有独立的 YAML 定义：

Reviewer	关注领域	决策标签
Quality	代码质量、bug、逻辑错误、风格一致性、错误处理	可合并 / 有条件合并 / 不可合并
Security	输入验证、认证授权、注入漏洞、数据暴露、OWASP Top 10	安全无虞 / 存在风险 / 高危漏洞
Performance	算法复杂度、内存模式、N+1 查询、缓存、并发	性能良好 / 性能有疑虑 / 性能问题严重
Architecture	耦合度、模块划分、分层、接口设计、霰弹式修改	架构合理 / 架构有疑虑 / 架构有问题

每个 reviewer 的 prompt 都遵循同一个约束：第一行必须是决策标签，然后是总结、阻塞项和建议项。这让 coordinator 能结构化地解析每个 reviewer 的输出。

和 Cloudflare 的做法一样，每个 reviewer 的 prompt 都明确告诉它只看当前代码中存在的问题，不要重复早期版本的问题，不要建议修改未变更的代码。

Team 配置

reviewer 的组合通过 default-team 参数配置，格式是 persona:count：

1
2
3
4
5
6
7
8


# 默认：每种角色各一个
default-team: "quality:1,security:1,performance:1,architecture:1"

# 自定义：加强安全审查
default-team: "quality:1,security:2,performance:1"

# 极简：只看质量和安全
default-team: "quality:1,security:1"

当 count > 1 时，同角色的 reviewer 会带上编号（如 security-1、security-2），用同一个 prompt 但独立运行。相同 prompt 的多次运行可以起到交叉验证的效果——如果两个 security reviewer 都发现了同一个漏洞，可信度自然更高。

Cloudflare 有个类似的"风险分层"机制：trivial 改动（≤10 行）只跑 2 个 agent，full 改动（>100 行）跑全部 7 个。multi-review 目前靠用户手动配置 team，未来可以加入自动分层。

Coordinator：去重和交叉验证

并发审查带来的直接问题是多个 reviewer 可能发现同一个问题。比如一个 SQL 注入，quality reviewer 可能从 bug 角度报告，security reviewer 从安全角度报告。如果不处理，最终报告会有重复。

coordinator 的工作就是整合：

跨 reviewer 去重：同一问题只报告一次
交叉验证：至少 2 个 reviewer 同意的问题标记为"已确认"
冲突处理：意见不一致时取多数意见
保留领域见解：安全发现即使只有一个 reviewer 提到，也要保留
最严重决策：如果任何一个 reviewer 认为不可合并，最终决策就是不可合并

coordinator 的 prompt 模板支持自定义，通过 {{REVIEWS}} 占位符注入各 reviewer 的输出：

1
2
3
4
5
6
7
8


你是一个代码审查协调员。以下审查由独立的专家 reviewer 生成。
你的任务是整合为一个去重后的综合报告。

规则：
1. 跨 reviewer 去重（同一问题只提一次）
2. 交叉验证：至少 2 个 reviewer 同意的问题标记为"已确认"
3. 冲突时取多数意见
...

最终生成的 PR comment 包含两部分：coordinator 的综合报告在上，各 reviewer 的详细审查结果折叠在 <details> 标签中。

和 Cloudflare 方案的对比

两者使用了相同的思路——多 Agent 并发 + Coordinator 汇总——但在规模和复杂度上有明显差异：

维度	Cloudflare	multi-review
Agent 数量	7 个专业 agent + coordinator	4 个（可配置） + coordinator
并发模型	SDK 多 session，circuit breaker + failback	SDK 多 session，Promise.all + 全局超时
模型路由	按任务复杂度分配不同模型（Opus/Sonnet/Kimi）	单一模型，通过 `model` 参数指定
弹性	三级 circuit breaker，provider 级别的 failback chain	超时 + fallback comment（coordinator 失败时直接展示原始结果）
风险分层	自动（trivial/lite/full）	手动配置 team
扩展性	插件架构，7 个 plugin 组合	YAML persona 定义，内置 4 种
Token 优化	共享 context file，7x 的 MR 上下文不重复	每个 reviewer 独立接收完整 diff
适用场景	内部 GitLab，5169 仓库，企业级	GitHub/Gitea，开源项目，开箱即用

最核心的差异在弹性上。Cloudflare 的 circuit breaker 和 failback chain 是为生产环境设计的——7 个并发 AI 调用，provider 限频和宕机是必然事件。multi-review 的规模小得多，4 个并发的失败概率可控，用超时 + fallback comment 就够了。

另一个差异是 token 优化。Cloudflare 把 MR diff 写到一个共享文件，7 个 reviewer 读同一个文件而不是各拷一份。注意这里共享的是原始 diff（输入数据），而不是 reviewer 之间的审查结论。每个 reviewer 的审查过程仍然是完全独立的。这个优化在 7 个 reviewer 的情况下能省 85% 的重复 token。multi-review 目前每个 reviewer 都接收完整 diff，在 4 个 reviewer 的规模下重复还能接受，但如果 team 配置到 7+ 就需要考虑类似优化了。

Reasoning Effort 和 Thinking

multi-review 支持 reasoning-effort 和 enable-thinking 两个参数，直接传递给 OpenCode SDK 的 agent 配置：

1
2
3
4
5


- name: Run Multi-Review
 uses: sun-praise/opencode-actions/multi-review@v1
 with:
 reasoning-effort: max  # low / medium / high / max
 enable-thinking: true # 启用思维链

默认 reasoning-effort: max 和 enable-thinking: true，这意味着每个 reviewer 和 coordinator 都会用最大推理力度并输出思维链。对于代码审查这种需要深度分析的任务，这个默认值是合理的。

Cloudflare 也有类似的分层：coordinator 用 Opus（最强推理），code quality 和 security 用 Sonnet（平衡速度和能力），文档审查用 Kimi（便宜）。multi-review 暂时没有按角色分配不同模型的能力，但这是一个明确的优化方向。

使用方式

在 .github/workflows/ 中添加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


name: Multi Review

on:
 issue_comment:
 types: [created]

jobs:
 multi-review:
 if: |
 github.event.issue.pull_request &&
 contains(fromJSON('["/multi-review", "/mr"]'), github.event.comment.body)
 runs-on: ubuntu-latest
 steps:
 - uses: sun-praise/opencode-actions/multi-review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 # 可选配置
 default-team: "quality:1,security:1,performance:1,architecture:1"
 reasoning-effort: max
 enable-thinking: true

这段配置的效果是：在 PR 中评论 /multi-review 或 /mr，就会触发多 Agent 并发审查。

代码实现

核心实现在 orchestrator.ts 中的两个函数。

并发审查——runParallelReviewers：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


const promises = reviewers.map(async (reviewer) => {
 let sessionId: string | undefined;
 try {
 const remaining = () => Math.max(30_000, deadline - Date.now());

 // 1. 创建独立 session
 const sessionResult = await withTimeout(
 client.session.create({ throwOnError: true }),
 remaining(), reviewer.name,
 );
 sessionId = sessionResult.data.id;

 // 2. 发送 persona + diff
 await withTimeout(
 client.session.prompt({
 path: { id: sessionId },
 body: {
 parts: [{ type: "text", text: reviewer.prompt + "\n\nPR Diff:\n```\n" + prDiff + "\n```" }],
 },
 }),
 remaining(), reviewer.name,
 );

 // 3. 提取结果
 const messages = await withTimeout(
 client.session.messages({ path: { id: sessionId } }),
 remaining(), reviewer.name,
 );
 return { reviewer: reviewer.name, content: extractText(messages.data), success: true };
 } catch (err) {
 return { reviewer: reviewer.name, content: "", success: false, error: err.message };
 } finally {
 // 4. 清理 session
 if (sessionId) await client.session.delete({ path: { id: sessionId } });
 }
});

return Promise.all(promises);

Coordinator 汇总——runCoordinator：

1
2
3
4
5
6
7


// 把各 reviewer 的结果拼接成 {{REVIEWS}}
const reviewsText = reviews
 .map(r => `## ${r.reviewer}\n${r.success ? r.content : `（失败: ${r.error}）`}`)
 .join("\n\n---\n\n");

const fullPrompt = coordinatorPrompt.split("{{REVIEWS}}").join(reviewsText);
// 创建 session、发送 prompt、提取结果...

如果 coordinator 本身失败了，还有个 fallback：

1
2
3
4


export function buildFallbackComment(reviews: ReviewResult[]): string {
 // coordinator 挂了，直接把各 reviewer 的原始输出拼起来
 return "**Multi-Review (fallback — coordinator failed)**\n\n" + parts.join("\n\n---\n\n");
}

这确保了即使汇总环节出问题，审查结果也不会丢失。

和单模型 Review 的关系

multi-review 和之前单模型 review action 不是替代关系，而是互补：

	review	multi-review
定位	快速审查，适合每次 PR 都跑	深度审查，适合关键 PR 或手动触发
模型数	1 个	4+ 个（可配置）
耗时	1-3 分钟	3-8 分钟
Token 消耗	低	中（N 倍于单模型）
触发方式	PR 创建/更新自动触发	手动评论触发
适合场景	日常迭代，快速反馈	重要功能、安全相关、大型重构

日常开发用 review 做快速检查，关键 PR 用 multi-review 做深度审查。两个 action 可以共存于同一个仓库。

未来优化方向

参考 Cloudflare 的经验和当前实现的局限，有几个明确的优化方向：

自动风险分层：根据 diff 行数和文件类型自动决定跑几个 reviewer。typo 修改变动不需要 4 个 agent 并发审查。
共享上下文：把 diff 写到文件而不是每个 reviewer 都拷贝一份，减少 token 消耗。但需要注意一个微妙的问题：共享的边界在哪里？ 共享原始 diff（输入数据）是安全的，但如果过早共享 reviewer 之间的中间结论，会导致严重的偏差问题——确认偏差、锚定效应、同质化审查。正确的设计是：reviewer 阶段完全隔离，只共享输入；coordinator 阶段才汇总结论。这不仅是 token 优化的问题，更是一个审查独立性的架构决策。
模型路由：coordinator 用强模型，文档审查用轻量模型，按角色分配不同 provider。
增量审查：push 新 commit 后，只审查变更的部分，不从头开始。

总结

multi-review 的核心思路来自 Cloudflare 的文章：把一个复杂任务拆成多个专业子任务，并发执行后统一汇总。这比一个全能模型覆盖所有维度更有效，因为每个子任务的 prompt 更聚焦，模型的注意力更集中。

实现上，multi-review 用 OpenCode SDK 的多 session 能力做并发，用 Promise.all 做编排，用全局超时做兜底，用 coordinator 做去重和交叉验证。这是一个在开源项目规模下足够实用的架构——没有 circuit breaker 和 failback chain 的复杂度，但覆盖了并发审查的核心需求。

opencode-actions — GitHub Action 仓库
Cloudflare: Orchestrating AI Code Review at Scale — 设计灵感的来源
opencode-actions - 一个 coding review agent — 单模型 review action 的介绍
OpenCode 配置之外的优化 — opencode-review 插件的设计，session 内的代码审查

Kimi Code 对 kimi-k2.6 的专用处理：与 OpenCode 的对比

Wed, 27 May 2026 10:30:00 +0800

最近 kimi code 从 python 迁移到了 ts 版本。于是做了个简单的分析。

根据对 kimi-code 源代码（特别是 packages/kosong/src/providers/kimi.ts、kimi-schema.ts、kimi-files.ts 等）以及 OpenCode 相关兼容性 Issue 的分析，以下是 kimi-code 针对 kimi-k2.6（及 Kimi 系列模型）做的专用处理，以及相对于 OpenCode 的关键差异。

1. 原生 Kimi Provider（非通用 OpenAI 兼容层）

kimi-code 没有直接把 Kimi 当"又一个 OpenAI 兼容接口"处理，而是实现了专门的 kimi provider 类型：

特性	kimi-code	OpenCode
Provider 类型	专门的 `'kimi'` 类型，独立适配	通过 OpenAI/Anthropic 通用 bridge 访问
专有字段	原生处理 `reasoning_content`、`thinking`、`generationKwargs`	bridge 层常丢失 `reasoning_content`
认证头	支持 `kimiRequestHeaders` 和 `X-Msh-Tool-Call-Id` 等 Moonshot 专有 header	通用 header 转发

2. `reasoning_content` 的全生命周期处理

kimi-k2.6 默认开启 thinking，且要求多轮对话历史中保留 reasoning_content，否则工具调用后会报 400 错误。

kimi-code 的处理：

convertMessage：将内部 think 类型的 content part 提取并序列化为 reasoning_content 字段，确保历史消息中 thinking 内容不丢失
流式解析：在 _convertStreamResponse 和 _convertNonStreamResponse 中都专门提取 delta.reasoning_content / message.reasoning_content
TUI 渲染：有专门的 ThinkingComponent 组件实时显示 thinking 内容，支持展开/收起和 spinner 动画

OpenCode 的问题：

OpenCode Go 的 bridge 在第二轮对话时丢失 reasoning_content，导致 Moonshot API 返回：

1

thinking is enabled but reasoning_content is missing in assistant tool call message

3. JSON Schema 专用规范化（`kimi-schema.ts`）

Moonshot 的工具参数验证器对 JSON Schema 有严格且特殊的要求，这是 OpenCode 与 kimi-k2.6 不兼容的主要来源之一。

kimi-code 的 normalizeKimiToolSchema 做了：

解引用 $ref：将 $defs / definitions 中的定义内联展开，消除外部引用
补全缺失的 type：Kimi 验证器会拒绝省略 type 的嵌套属性（比如 MCP 产生的 enum-only schema），kimi-code 会推断并补全 type: string/object/array 等
循环引用检测：遇到循环引用时保留原始 $ref，避免无限递归

OpenCode 的问题：

生成 schema 使用 #/definitions/ 而非 Moonshot 要求的 #/$defs/，且没有为 Kimi 做 schema 类型推断和补全，导致复杂工具调用直接 400。

4. Thinking 模式的原生配置体系

kimi-code 从配置层到 UI 层都内置了对 Kimi thinking 模式的支持：

配置解析：ThinkingConfigSchema 支持 mode: auto/on/off 和 effort: low/medium/high/xhigh/max
模型能力标注：ModelAlias 支持 capabilities: ['thinking', 'always_thinking']
模型选择器 UI：按 ←→ 键可切换 thinking on/off，always-on 模型不可关闭

Provider 方法：withThinking(effort) 会正确生成：

1
2
3
4


{
 "reasoning_effort": "high",
 "extra_body": { "thinking": { "type": "enabled" } }
}

token 预算：自动将 legacy max_tokens 规范化为 Kimi 偏好的 max_completion_tokens

OpenCode 的问题：

通过 Anthropic bridge 时硬编码发送 thinking content blocks，但 Kimi API 只支持 text/image_url/video_url/video，导致：

1

Invalid value: thinking. Supported values are: 'text','image_url','video_url' and 'video'.

5. Moonshot 原生服务集成

kimi-code 内置了 Moonshot 专属服务，而非使用通用本地实现：

MoonshotFetchURLProvider：优先调用 Moonshot 的 coding-fetch 服务（已做页面文本提取），失败才 fallback 到本地
MoonshotWebSearchProvider：直接调用 Moonshot 搜索 API，支持 enable_page_crawling
KimiFiles：视频上传到 Moonshot 文件服务，生成 ms://<file-id> 格式的 video_url

6. 工具调用层细节

内置函数：以 $ 开头的工具名会被识别为 Kimi builtin function，序列化为 type: 'builtin_function'
Usage 提取：支持 Moonshot 特有的 choices[0].usage 位置，以及 cached_tokens 等字段
Finish Reason 映射：将 OpenAI 格式的 stop/tool_calls/length 等映射到内部统一枚举

7. CLI 核心与 LLM SDK 的架构隔离

这是一个容易被忽视但很重要的架构差异。

kimi-code 的核心 CLI（apps/kimi-code）本身不直接依赖任何 OpenAI 或 Anthropic 的 TypeScript SDK。 查看其 package.json，核心依赖只有 TUI 渲染（pi-tui）、命令行解析（commander）、语法高亮（cli-highlight）等通用库。所有与 LLM provider 的交互都被隔离在自研的 kosong 包中。

packages/kosong 虽然内部使用了 openai 和 @anthropic-ai/sdk 作为实现细节（因为 Kimi API 是 OpenAI-compatible 的），但对外提供的是统一的 LLM 抽象接口。CLI 核心只依赖 kosong，不感知底层 vendor SDK。

OpenCode 则不同。 其 packages/opencode 核心包直接依赖了大量 vendor SDK：

@ai-sdk/openai
@ai-sdk/anthropic
@ai-sdk/google
@ai-sdk/azure
@openrouter/ai-sdk-provider
……（共计十余个 provider-specific 包）

这意味着 OpenCode 的核心代码与各个 vendor 的 SDK 深度耦合，而 kimi-code 的核心 CLI 保持干净，模型交互完全通过自研抽象层隔离。

8. Commit 历史揭示的演进路径

以上的代码结构差异只是静态结果。更有意思的是看两边的 commit 历史——动态演进方向完全不同。

kimi-code：原生设计，持续消除配置负担

842e699 — “Kimi For Coding”（初始提交）

这是整个项目的起点。初始代码就包含了：

packages/kosong/src/providers/kimi.ts：专用 Kimi provider
packages/kosong/src/providers/kimi-schema.ts：专用 JSON Schema 规范化器
packages/kosong/src/providers/kimi-files.ts：专用文件上传服务

结论：kimi-code 从一开始就把 Kimi API 当作一等公民设计，不是后期打补丁适配。

d95b013 fix(catalog): preserve reasoning fields in custom model (#70)

这个 commit 修复了一个很隐蔽的问题。models.dev 用 interleaved 字段标记 reasoning 支持，但早期代码把 interleaved=true 当作 undefined 处理，导致通过 /connect 选择的模型静默丢失 reasoning 能力。

修复内容：

interleaved=true 映射为默认的 reasoning_content
update-catalog.mjs 的 allowlist 加入 interleaved，否则 release build 的离线 catalog 会再次丢失该字段

61f7d0e fix(kosong): make openai-compatible thinking work without reasoning_key (#78)

这是 reasoning 处理的核心 commit，展示了 kimi-code 对兼容性的深层思考。diff 显示了三层关键设计：

Inbound 自动扫描（响应解析）

1
2


const KNOWN_REASONING_KEYS = ['reasoning_content', 'reasoning_details', 'reasoning'] as const;
// 自动扫描三个字段，第一个字符串值获胜

Outbound 默认回写（请求序列化）

1
2


const DEFAULT_OUTBOUND_REASONING_KEY = KNOWN_REASONING_KEYS[0]; // 'reasoning_content'
// 默认以 reasoning_content 回传，无需用户配置

自动注入 reasoning_effort（历史连续性）

1
2


// 当历史中有 ThinkPart 但 caller 未显式设置 reasoning_effort 时，
// 自动注入 'medium'，避免 One API / DeepSeek 等严格网关返回 400

边界情况也处理得很细：blank reasoning_key（""）被 normalize 为 undefined；caller 通过 withGenerationKwargs 显式设置的值不会被自动注入覆盖。

验证目标明确写的是：

Manually verified end-to-end against the real DeepSeek API with a hand-written config.toml that does not set reasoning_key: thinking content renders, no 400, multi-turn conversations work.

OpenCode：通用层设计，OpenAI-centric

eb84f46 fix(llm): split OpenAI reasoning summary blocks (#29000)

这个 commit 展示了 OpenCode 处理 reasoning 的完全不同思路——围绕 OpenAI Responses API 设计：

维护 encrypted_content 和 item_reference 的状态机
按 item_id + summary_index 折叠多个 summary parts
store:false 时过滤缺少 encrypted_content 的 reasoning items

这与 Kimi 的 reasoning_content 机制完全不同。 Kimi 不需要 encrypted_content 或 item_reference，而是直接在 message 上附加 reasoning_content 字段。

一个残酷的事实

OpenCode Issue #26331 “Bug: OpenCode Go bridge layer incompatible with kimi-k2.6 tool calls” — 状态：至今仍是 open
OpenCode Issue #27054 “KIMI K2.6 showing error in Opencode GO” — 状态：closed，但关闭方式是禁用 MCP（workaround）

#27054 的最后一个 comment：

The workaround is to disable your MCP and then initiate the session

这不是修复，这是回避问题。

Commit 历史对比总结

维度	kimi-code	OpenCode
初始设计	初始提交即包含完整 Kimi provider + schema 规范化 + 文件服务	通用多模型架构，后期通过 bridge 适配
reasoning 机制	围绕 `reasoning_content` 字段设计，自动扫描/回写/注入 effort	围绕 OpenAI Responses 的 `encrypted_content` + `item_reference` 设计
schema 处理	专用 `normalizeKimiToolSchema`，解引用 `$ref` + 补全 `type`	通用 schema 验证，友好错误提示为主
配置哲学	让 OpenAI-compatible 网关"零配置工作"，自动推断所有字段	依赖用户通过 bridge/config 手动适配
issue 状态	持续发布 reasoning 相关 patch（#70, #78）	kimi-k2.6 兼容性问题 #26331 至今 open

总结：核心差异

维度	kimi-code	OpenCode
架构定位	原生为 Kimi/Moonshot 设计，专用 provider	通用多模型代理，通过 bridge 适配
Thinking/Reasoning	原生支持，全链路保留 `reasoning_content`	bridge 层易丢失，导致 400
JSON Schema	专用 `normalizeKimiToolSchema` 做解引用和类型补全	通用 schema 生成，不符合 Kimi 验证器要求
API 格式	直接生成 Moonshot 原生格式（含 `thinking` 配置、`$defs` 规范等）	经 OpenAI/Anthropic 协议转换，产生格式不匹配
服务集成	内置 Moonshot fetch/search/file 服务	使用通用本地工具
核心依赖	CLI 核心不直接依赖 vendor SDK，通过自研 kosong 包隔离	核心包直接耦合 `@ai-sdk/openai` 等十余个 vendor SDK

从 commit 历史看，kimi-code 的演进方向是持续消除用户配置负担（reasoning_key 从必填 → 可选覆盖 → 自动推断；interleaved 从被过滤 → 正确映射），而 OpenCode 的演进方向是持续深化 OpenAI 生态集成（Responses API、encrypted reasoning、item reference），对 Kimi 的适配停留在通用 bridge 层。

这就是 commit 层面的真相：一个是原生演进，一个是 bridge 间隙。

OpenCode LLM Provider 层的三连修：从图片序列化到错误信息丢失

Sat, 23 May 2026 10:00:00 +0800

16 万 star 的 opencode 项目最近连续合并了三个 LLM provider 层的 bug 修复 PR，都是核心维护者 kitlangton 提交的。这三个 bug 不是某次重构引入的回归问题，而是从协议层初始设计就存在的缺陷——只是在最近使用量增长后才暴露出来。

这篇文章分析这三个 bug 的根因、修复方式，以及对开发 AI 工具的启示。

背景：opencode 的 LLM 协议层

opencode 支持多个 LLM provider（OpenAI、Anthropic 等），每个 provider 有自己的协议实现文件，负责把统一的内部格式转换成各 provider 的 API 格式。比如 openai-responses.ts 处理 OpenAI Responses API，anthropic-messages.ts 处理 Anthropic Messages API。

这些协议层有两个核心工作：

下行（lowering）：把 opencode 内部的消息格式转成 provider 的请求格式
上行（parsing）：把 provider 返回的流式响应解析成 opencode 内部的消息格式

三个 bug 分别出在这两个方向上。

Bug 1：Tool Result 中的图片被字符串化

相关 PR：#28754（OpenAI，关闭 #28859）、#28755（Anthropic，关闭 #28861）

问题

当 LLM 调用一个工具（比如截图工具），工具返回的结果可能包含图片（base64 编码）。opencode 的协议层在处理这种 tool result 时，统一调用了 ProviderShared.toolResultText(part)，这个函数把整个 tool result——包括图片——JSON.stringify 成一个字符串。

对于 OpenAI Responses API，这意味着：

1
2


// 修复前：所有 tool result 都变成字符串
{ type: "function_call_output", call_id: "...", output: '{"type":"image","data":"base64..."}' }

一个包含 base64 图片的 tool result 被序列化成字符串塞进了 function_call_output.output。对于 Anthropic Messages API 同样：图片被 JSON.stringify 后塞进了 tool_result.content。

修复

OpenAI 端：新增 lowerToolResultOutput 函数，判断 tool result 的类型：

文本/json/error → 保持原来的字符串行为（向后兼容）
图片 → 以 input_image 结构化块发送

1
2
3
4


// 修复后：图片以结构化格式发送
{ type: "function_call_output", call_id: "...", output: [
 { type: "input_image", image_url: "data:image/png;base64,..." }
]}

Anthropic 端做了类似的处理，图片以 Anthropic 原生的 image 块发送。同时 function_call_output.output 的 schema 从 Schema.String 改成了 Schema.Union([Schema.String, Schema.Array(...)])，既支持旧的字符串格式，也支持新的结构化数组。

根因

这不是某次重构搞坏的，而是初始设计就没考虑到 tool result 会返回非文本内容。toolResultText() 作为一个通用函数，把所有内容都当文本处理——在只有文本 tool result 的世界里这是对的，但世界变了。

Bug 2：Stream Error 信息被吞掉

相关 PR：#28757（关闭 #28860）

问题

LLM provider 的流式响应可能在中途出错（rate limit、context overflow、model overload 等）。opencode 的错误处理代码把这些错误全部压成了通用字符串：

1
2


// 修复前
event.message ?? event.code ?? "OpenAI Responses stream error"

所有错误都变成了 "OpenAI Responses stream error" 这一句话。维护者在 PR 描述里提到，这使得某个 session 的诊断变得极其痛苦——底层原因（base64 图片过大）完全不可见。

OpenAI 的 response.failed 事件更惨：错误信息在 response.error 下面，但代码读的是 event.message 和 event.code（顶层字段），永远是 undefined。

修复

OpenAI 端：先读顶层 event.{code, message, param}，再回退到嵌套的 event.response.error.{code, message, param}。当 code 和 message 同时存在时，用 code 做前缀：

1
2


rate_limit_exceeded: Slow down
server_error: Upstream model unavailable

Anthropic 端：用 error.type 做前缀：

1

overloaded_error: Overloaded

根因

错误处理的代码写得太"乐观"了——假设错误信息总在预期的位置。但 OpenAI 的 API 在不同错误场景下把信息放在不同的嵌套层级，代码没有覆盖所有情况。

Bug 3：Anthropic Tool Result 类型检查不稳定

相关 PR：#28909

问题

这个 PR 在前两个修复合并后才出现。修复了图片 tool result 的结构化发送后，Anthropic 端的类型检查变得不稳定——某些边缘情况下 tool result 的类型推断会失败。

具体来说，tool_result.content 的类型从 string 扩展成了 string | ContentItem[]，但下游代码没有完全适配这个联合类型。

修复

稳定了 Anthropic tool result 的类型检查逻辑，确保联合类型的所有分支都被正确处理。

根因

这是 Bug 1 修复的连锁反应。把 schema 从 Schema.String 改成 Schema.Union 后，类型系统变复杂了，之前不需要处理的分支现在必须处理。

三个 Bug 的关系

1
2
3
4
5
6
7
8


初始设计缺陷
├── tool result 只考虑文本场景
│ ├── Bug 1a: OpenAI 图片被字符串化 (#28754)
│ └── Bug 1b: Anthropic 图片被字符串化 (#28755)
├── error handler 只覆盖理想情况
│ └── Bug 2: stream error 信息丢失 (#28757)
└── Bug 1 修复后类型变复杂
 └── Bug 3: 类型检查不稳定 (#28909)

Bug 1 和 Bug 2 是独立的初始设计缺陷。Bug 3 是 Bug 1 修复的副作用。

对 AI 工具开发的启示

1. 协议层的"够用就行"是最危险的

toolResultText() 在只有文本 tool result 的时候完全够用。但协议层的抽象一旦固定下来，后续扩展就很难——因为所有调用方都依赖当前行为。opencode 的修复保持了向后兼容（文本场景仍然用字符串），但代价是类型变复杂了（Bug 3）。

如果初始设计就把 tool result 分成文本/结构化两条路径，就不会有后面的问题。当然，这是事后诸葛亮——没有人能在第一天就预见到 tool result 会包含图片。

2. 错误处理要假设最坏情况

“错误信息总在预期位置"这个假设在 LLM API 上尤其不成立。各家 provider 的错误格式不一致，同一家 provider 的不同错误类型格式也不一致。写错误处理代码时，应该假设错误信息可能在任何嵌套层级，甚至完全缺失。

3. 修一个 bug 可能暴露下一个

opencode 的三个 PR 形成了一条修复链。修了图片序列化后，类型变复杂了，暴露了类型检查的漏洞。在提交修复时应该考虑到类型变更的下游影响。

4. 观察 bug 的方式决定了修复速度

kitlangton 在 #28757 的 PR 描述里提到，stream error 信息丢失使得某个 session 极其难诊断。如果错误信息是可见的，可能早就发现了。让错误可见是基础设施类代码的重要原则——宁可多输出一点，也不要吞掉信息。

总结

opencode 的这三个 LLM provider bug 都源自初始设计对复杂场景的简化处理。随着 AI 工具能力边界的扩展（从纯文本到多模态），早期"够用就行"的抽象开始出现裂缝。修复的方式是务实的：保持向后兼容的同时扩展新能力。对 AI 工具开发者来说，这是一个提醒——协议层的设计要为未知的变化留余地，错误处理要假设最坏的情况。

OpenCode 的 GitHub Actions 自动化体系：27 个 Workflow 背后的工程实践

Fri, 22 May 2026 10:00:00 +0800

opencode 是一个 16 万 star 的 AI 编码工具，它的 .github/workflows/ 目录下有 27 个 workflow 文件。这个数量在开源项目里不算少，但真正有意思的不是数量，而是这些 workflow 覆盖的范围：从常规的 CI/CD 到 AI 驱动的社区治理，几乎把 GitHub Actions 能做的事情都做了一遍。

这篇文章逐类分析这些 workflow 的设计，讨论这种自动化程度的利弊，以及对我们自己项目的启示。

总览

27 个 workflow 可以分成四类：

类别	数量	作用
CI/测试	4	typecheck、单元测试、e2e、Nix 构建
发布/交付	5	CLI 发布、容器构建、VS Code 插件、GitHub Action 发布
自动化/Bot	16	issue 治理、PR 合规、AI code review、文档更新
文档/其他	2	统计、Discord 通知

16 个自动化 workflow 占了总数的 60%。opencode 不只是用 Actions 来跑测试和发布，而是把社区治理和代码质量审查也交给了自动化系统。

CI/测试：扎实但克制

四个测试相关的 workflow：

typecheck.yml — PR 和 push 到 dev 时跑 bun typecheck。简单直接，没有多余动作。

test.yml — 跨平台测试矩阵（Linux + Windows），跑单元测试和 Playwright e2e。有 concurrency 控制，同一个 PR 的新 commit 会取消旧运行。测试结果生成 JUnit 报告上传为 artifact。

nix-eval.yml — 验证 Nix flake 在四种架构（x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin）下的构建。必选包失败会阻断，可选包失败只是警告。

storybook.yml — UI 组件的 Storybook 构建，只在 storybook/ui 相关文件变更时触发。路径触发避免了不必要的运行。

几个值得注意的设计选择：

concurrency group + cancel-in-progress：多个 workflow 都用了这个模式，同一个 PR 不会堆叠多次运行。对于一个接受大量社区 PR 的项目，这能省下不少 CI 资源。
路径触发：containers.yml 只在容器文件变更时运行，storybook.yml 只在 UI 变更时运行。不是所有东西都全量跑。
混合 Runner 策略：大部分 workflow 使用 Blacksmith 提供的第三方托管 runner（blacksmith-4vcpu-ubuntu-2404、blacksmith-4vcpu-windows-2025）。Blacksmith 是一个兼容 GitHub Actions API 的加速 runner 服务，底层用自建基础设施，比 GitHub 免费 runner 快不少。只有轻量级 bot 任务（close-issues、close-prs、compliance-close、pr-standards、deploy）留在 GitHub 原生的 ubuntu-latest 上。计算密集的编译、测试、发布全走 Blacksmith，简单的脚本任务用 GitHub 原生 runner，按任务负载分配资源。

发布/交付：全平台覆盖

publish.yml 是最复杂的 workflow，一个文件处理了完整的发布流程：

版本号计算
CLI 构建矩阵（多平台多架构）
Windows 代码签名（Azure Signing）
macOS 代码签名（Apple Developer）
Electron 应用构建
npm 发布
GitHub Release 创建
AUR（Arch Linux）发布

一个 workflow 覆盖了 CLI、桌面应用、npm 包、Linux 包的分发。这种"全平台一次发布"的模式对用户友好——无论什么平台都能在同一天拿到新版本。

其他发布 workflow 按产物类型拆分：

publish-github-action.yml — 监听 github-v* tag，发布 GitHub Action 到 Marketplace
publish-vscode.yml — 监听 vscode-v* tag，同时发布到 VS Code Marketplace 和 Open VSX
containers.yml — 多架构容器镜像构建，推送到 GHCR
release-github-action.yml — dev 分支有 github 目录变更时创建预发布

tag 触发是一个好的实践：发布是显式动作，不会因为误推代码就触发。publish.yml 会在 push 到 ci/dev/beta/fix 分支时自动构建 snapshot，但正式发布需要手动 dispatch 或 tag。

自动化/Bot：AI 驱动的社区治理

这是 opencode 最有特色的部分。16 个自动化 workflow 中，多个直接调用了 opencode 自己的 AI 能力来处理社区事务。

Issue 管理

triage.yml — 新 issue 创建时，用 opencode AI 自动分流，添加标签和分类。

duplicate-issues.yml — 新 issue 创建/编辑时，用 opencode AI 分析是否与已有 issue 重复。同时检查是否遵循了三种 issue 模板之一，是否包含 AI 生成内容。不合规的会被加上 needs:compliance 标签。

compliance-close.yml — 每 30 分钟检查一次，带有 needs:compliance 标签的 issue/PR 如果 2 小时内没有修正，自动关闭。关闭时会根据是 issue 还是 PR 给出不同的提示信息。

close-issues.yml — 每天凌晨 2 点 UTC 关闭过期的 stale issue。

这四层形成了完整的 issue 生命周期管理：

1

新 issue → AI 分流(triage) → 重复/合规检查(duplicate) → 合规宽限期(compliance) → 过期清理(close)

PR 管理

pr-standards.yml 是最长的 workflow 之一，做了两件事：

标题格式检查：强制 conventional commits 格式（feat/fix/refactor/…）
模板合规检查：PR 描述必须包含 issue 引用、变更类型、验证方法等必要章节

不合规的 PR 会被加上 needs:compliance 标签，2 小时后自动关闭。team 成员和 bot 豁免。

pr-management.yml — PR 创建时查重，并为社区贡献者添加标签。

close-prs.yml — 每天晚上 10 点 UTC 关闭超过 1 个月且点赞数不够的 PR。默认阈值是 2 个 reaction，可配置。

AI Code Review

review.yml — 在 PR 评论中输入 /review，opencode AI 会分析代码并在具体的行上留下 review 评论。只对 repo owner/member 开放。

opencode.yml — 在 issue 或 PR 评论中输入 /oc 或 /opencode，触发 opencode AI 进行更通用的交互。

这两个 workflow 展示了"AI 作为协作者"的思路：不是全自动的 code review，而是按需触发，人在回路中做最终决定。

文档与维护

docs-update.yml — 每 12 小时检查最近的 commit，用 opencode AI 判断是否需要更新文档。

generate.yml — push 到 dev 时运行代码生成脚本，自动提交变更。

beta.yml — 每小时同步 beta 分支。

stats.yml — 每天更新下载统计到 STATS.md。

值得借鉴的设计模式

1. 分层治理

opencode 没有把所有自动化塞进一个 workflow，而是按职责拆分。issue 从创建到关闭经过了四个 workflow 的接力处理。每个 workflow 只做一件事，组合起来形成完整的治理链。

这种设计的好处是：

单个 workflow 可以独立修改、禁用，不影响其他环节
每个 workflow 的触发条件、权限范围都是最小化的
出问题时容易定位是哪个环节

2. 合规宽限期

compliance-close.yml 不是检测到不合规就立即关闭，而是给 2 小时的宽限期。这对全球不同时区的贡献者来说是合理的——你可能正好在睡觉的时候提交了一个 issue，醒来发现有时间修正。

3. AI 用在决策点而不是执行点

triage、duplicate 检测、code review 这些都是 AI 做初步判断，人做最终决定。而代码构建、发布这些执行层面的事情完全不用 AI。这是一个务实的分工：AI 擅长模式识别和初步分类，但不擅长精确执行。

4. 显式触发 vs 自动触发

发布用 tag 触发，日常维护用 schedule 触发，社区治理用事件触发。三种触发方式对应三种不同的自动化信任等级：发布需要人工确认，维护可以定时自动，治理需要即时响应。

过度自动化的风险

opencode 的自动化体系很完善，但也有需要注意的地方：

社区门槛：新贡献者提交 issue 需要遵循特定模板，PR 需要符合 conventional commits，否则 2 小时后自动关闭。对于一个 16 万 star 的项目，这种严格是合理的——它能过滤掉大量低质量贡献。但对于小项目，这种程度的自动化会吓跑潜在贡献者。

维护成本：27 个 workflow 意味着 27 个需要维护的自动化脚本。opencode 有专门的自定义 runner 和专用脚本。如果某个 workflow 的逻辑需要调整，维护者需要在 GitHub Actions 的 YAML + 自定义脚本之间来回切换。

AI 的不确定性：duplicate-issues 和 triage 用 AI 做判断，但 AI 可能误判。一个合理的 issue 被标记为 duplicate 并关闭，对贡献者的体验是负面的。opencode 用宽限期和人工复核来缓解这个问题，但风险依然存在。

对我们项目的启示

不是每个项目都需要 27 个 workflow。但 opencode 的分层治理和"AI 在决策点"的思路值得参考：

从 issue 模板开始：如果项目开始收到大量重复或低质量 issue，先加模板和 duplicate 检查，而不是手动处理每一个。
合规检查用宽限期：自动关闭不合规贡献时，始终给一个宽限期。
AI 用于分类不用于执行：让 AI 帮你分流 issue、检查 PR 格式，但不要让 AI 自动合并代码或发布版本。
发布用 tag 触发：这是最安全的做法。自动发布的 snapshot 可以接受，正式版本需要人工确认。
按需添加：先有痛点再加自动化。opencode 的 27 个 workflow 不是一天建成的，是随着社区规模增长逐步增加的。

总结

opencode 的 GitHub Actions 体系展示了大型开源项目的自动化实践：CI/CD 覆盖全平台发布，社区治理用多层 workflow 接力处理，AI 被用在分流和审查等决策环节。这套系统的核心不是技术复杂度，而是"分层、宽限、显式触发"这三个原则。对于自己的项目，不需要照搬 27 个 workflow，但这些原则可以直接用上。

OpenCode 配置之外的优化 — 基于插件的优化

Tue, 19 May 2026 10:00:00 +0800

之前我写过一篇 OpenCode 配置优化记录，解决的是 token 消耗和上下文管理的问题。但配置优化管的是"模型怎么跑"，而"代码写到一半质量怎么样"——这件事配置管不了。这篇文章从我开发 opencode-review 插件的过程出发，聊聊 opencode-review 如何在一个 session 内帮助 agent 审查并改进自己的代码，让最终进入 PR 的代码质量更高。

问题：session 内的代码质量谁来把关？

用 OpenCode 写代码时，一个典型的工作流是：agent 在一个 session 内完成编码，然后我 review diff、创建 PR。但我发现一个反复出现的问题：agent 写完的代码经常带着"第一次草稿"的质量问题就进入 PR 了。

这些问题包括：缺少错误处理、安全漏洞、性能不佳的查询、缺失的测试。如果能在 session 内——也就是代码还没提交到 PR 之前——让 agent 自行审查一轮，很多问题在 PR 阶段就不存在了。

这和 CI 阶段的 code review 是不同层次的事情。CI 审查我已经通过 opencode-actions（之前写过一篇介绍文章）实现了——它发生在 PR 创建之后，由 GitHub Actions 触发。后来 Cloudflare 也在工程博客中分享了类似思路：用 OpenCode 构建大规模 AI code review。而 opencode-review 要解决的是更早的阶段：在 session 内、在 PR 之前，让 agent 在写完代码后主动审查并修复问题。两者互补：opencode-review 提升进入 PR 的代码质量基线，opencode-actions 则作为最后一道关卡。

具体来说，有三个需要解决的子问题：

审查覆盖不全：agent 生成的代码可能引入安全漏洞、性能问题，但它自己不会主动检查这些
缺乏系统性的审查框架：没有结构化的维度来评估代码，容易只关注功能正确性而忽略安全和性能
发现问题和修复之间缺乏闭环：即使 agent 发现了问题，也需要一个机制来自动修复，而不是等人来指出

opencode-review 的设计

基于这三个问题，我设计了 opencode-review：一个结构化的代码审查插件。

多维度分析

第一个设计决策是为什么分五个维度，而不是一个笼统的"好不好"的评价。

代码质量不是一个单一维度。一段代码可能功能正确、性能优秀，但存在 SQL 注入漏洞；也可能安全无害，但缺少测试覆盖。把它们混在一起评估，结果必然模糊。

学术上，Modern Code Review (MCR) Survey 收集了 2013-2025 年间的代码审查研究，提出了一个分类体系，涵盖缺陷检测、安全审查、性能分析、可维护性评估等多个任务维度。Ericsson 的研究团队在 Automated Code Review Using Large Language Models at Ericsson 中也验证了：按维度拆分的审查比笼统审查在工业场景中更有效。

opencode-review 的五个维度——code-quality、security、performance、testing、documentation——对应的就是这些研究中识别出的核心审查维度。每个维度可以独立开关，因为不同项目关注的重点不同：一个内部工具可能不需要文档审查，但一个安全敏感的服务不能跳过 security 维度。

严重性分级

第二个设计决策是为什么分三级严重性（critical / suggestion / highlight）。

这来自静态分析工具领域的经验教训。安全工具和 linter 长期面临一个问题：alert fatigue（告警疲劳）。当所有问题都被标记为同等重要时，开发者会开始忽略它们。Veracode 的研究指出，告警疲劳导致的直接后果是真正的严重问题被淹没在噪音中。

分三级的逻辑是：

critical：必须修复（安全漏洞、逻辑错误、资源泄漏）
suggestion：建议改进（代码可读性、性能优化、更好的实践）
highlight：值得注意（风格一致性、潜在的改进空间）

这样开发者可以优先处理 critical，而不会在一堆 “consider refactoring” 中错过一个 SQL 注入。

自动修复链

第三个设计决策是为什么 critical 问题要自动触发修复，而不是仅仅报告。

这是一个有争议的设计。传统的审查工具通常是"只报告不修复"，把修复留给开发者。但 opencode-review 的场景不同——它审查的代码本身就是 AI agent 刚写完的，让另一个 agent 去修复合情合理。

学术上这属于 Automated Program Repair (APR) 的范畴。A Survey of LLM-based Automated Program Repair (arXiv 2506.23749) 综述了 2022-2025 年间的 63 个 LLM-based APR 系统，分为四种范式。其中"分析增强"（analysis-augmented）范式——先用静态分析定位问题，再用 LLM 生成修复——被证明是最有效的。opencode-review 的 auto-fix chain 本质上就是这个范式：reviewer 发现 critical issue → 定位问题位置 → spawn fixer sub-agent → 生成最小化修复。

ICSE 2025 的一篇论文也指出，LLM 在 APR 中的关键挑战是目标对齐（objective alignment）——修复的目标不是"生成看起来合理的代码"，而是"精确解决报告的问题"。这也是为什么 opencode-review 的 fixer 被设计为 minimal fix——只做最小的修改来解决问题，不重写、不重构、不"顺手"做其他改动。

自动审查的隐性收益：代码质量基线的持续提升

上面三个设计解决的是"发现问题"和"修复问题"。但自动审查还有一个容易被忽略的好处：它在不经意间持续提升了代码质量的基线。

这个效果来自两个机制：

第一，审查反馈对写代码者的塑造。 FSE 2022 的研究在两年的工业实践中发现，当开发者知道自己的代码会被自动审查时，他们会在写代码阶段就更有意识地遵循规范——因为事后被指出来的成本变低了，提前写好的收益变高了。这是一种 nudge effect（助推效应）。在 AI agent 的场景下，这个效应更强：agent 在一个 session 中写了代码、被 review 指出问题、修复、再次被审查——这个循环在同一 session 内就能完成多轮。每一轮反馈都在修正 agent 的输出倾向，相当于一个隐式的 fine-tuning 过程。

第二，自动修复的直接质量累积。 critical issue 被自动修复意味着每一轮提交的代码质量都比没有审查时更高。这不是一次性的改进，而是持续的。就像代码库中的 lint 规则一样——一开始只是禁止明显错误，但随着规则积累，代码库的整体风格和质量在不知不觉中被拉高了。auto-fix chain 做的事情类似：安全漏洞被自动堵上、资源泄漏被自动修复、缺失的测试被自动补充。时间一长，代码库的质量基线自然高于没有自动审查的情况。

简单说：审查不是目的，质量提升才是。自动审查把"事后检查"变成了"过程中提升"。

Cooldown 机制

还有一个小的设计细节：cooldown_seconds。

auto-review 在 session idle 时触发，但 idle 事件可能频繁触发（比如 agent 在等待用户确认时也会 idle）。没有 cooldown 的话，同一份代码可能被审查好几次，浪费 token。120 秒的默认冷却期是一个经验值——足够让一轮修改完成，又不会等太久。

opencode-froggy：另一种思路

opencode-froggy（85 Stars，昨天刚发 0.12.0）提供了另一种思路。它不做结构化的多维度审查，而是提供 6 个专用 agent（architect、code-reviewer、code-simplifier、doc-writer、partner、rubber-duck）和一套灵活的 hooks 系统。

Froggy 的 code-reviewer 是一个通用的只读审查 agent，不区分维度和严重性。但它的 hooks 系统很强——你可以配置 session.idle 事件自动跑 lint、自动格式化、甚至在写入敏感文件时拦截：

1
2
3
4
5
6
7
8


---
hooks:
 - event: session.idle
 conditions: [hasCodeChange, isMainSession]
 actions:
 - bash: "npm run lint --fix"
 - command: simplify-changes
---

这是一种"开发者自己编排流程"的思路，和 opencode-review 的"开箱即用的结构化审查"形成互补。

对比

	opencode-review	opencode-froggy
审查方式	结构化多维度分析	通用 code-reviewer agent
严重性分级	critical / suggestion / highlight	无
自动修复	critical issue → fixer sub-agent	code-simplifier，需手动触发
触发方式	session idle + cooldown	hooks 配置
自定义规则	custom_rules 支持项目规范	无
其他功能	无	6 agent + hooks + gitingest + 区块链

两个不冲突，可以一起装。我的建议是：opencode-review 做日常自动审查，froggy 的 hooks 做流程编排。

插件安装

两个插件的安装方式不同。

opencode-froggy 支持通过 npm 直接安装，在 opencode.json 中添加即可：

1
2
3


{
 "plugin": ["opencode-froggy"]
}

opencode-review 目前 npm 安装尚未上线，需要 clone 后本地链接：

1
2
3
4
5
6
7
8
9


# clone 到任意位置
git clone https://github.com/sun-praise/opencode-review.git /path/to/opencode-review

# 项目级安装（推荐）
mkdir -p .opencode/plugins
ln -s /path/to/opencode-review/src/index.ts .opencode/plugins/opencode-review.ts

# 或全局安装
ln -s /path/to/opencode-review/src/index.ts ~/.config/opencode/plugins/opencode-review.ts

opencode-review 还需要创建 .opencode/review.json 来配置审查行为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "language": "zh",
 "dimensions": ["code-quality", "security", "performance", "testing", "documentation"],
 "trigger": {
 "auto_on_idle": true,
 "cooldown_seconds": 120
 },
 "custom_rules": [
 "All API endpoints must have error handling",
 "Database queries must use parameterized statements"
 ]
}

其他值得关注的插件

生态已经超过 70 个插件了，再推荐几个：

opencode-worktree：零摩擦的 git worktree 管理
opencode-notify：任务完成时发送系统通知
dynamic-context-pruning：自动裁剪过时的工具输出，优化 token 使用
envsitter-guard：阻止 agent 读取 .env 敏感文件

完整列表见 awesome-opencode。

参考文献

Modern Code Review (MCR) Survey — 2013-2025 代码审查研究综述
Automated Code Review Using LLMs at Ericsson — LLM 辅助代码审查的工业实践
A Survey of LLM-based Automated Program Repair — LLM 自动修复综述，覆盖 63 个系统
Aligning the Objective of LLM-Based Program Repair (ICSE 2025) — LLM 修复的目标对齐问题
Understanding Automated Code Review Process (FSE 2022) — 两年工业环境自动审查的经验总结
AI-Assisted Assessment in Modern Code Review (AIware 2024) — AutoCommenter 的部署与评估
Code Review Agent Benchmark (c-CRAB) — AI agent 代码审查基准测试
opencode-actions - 一个 coding review agent — 基于 OpenCode 构建的 GitHub Action，CI 阶段的 code review
Cloudflare: Orchestrating AI Code Review at Scale — Cloudflare 用 OpenCode 构建大规模 AI 审查

如何解决 opencode 中 deepseek 模型的 reasoning 问题

Fri, 24 Apr 2026 12:23:58 +0800

当我们使用 deepseek-reasoner 的时候，往往会遇到这个问题：

1

The reasoning_content' in the thinking mode must be passed back to the API.

更新

现在两个问题都已经被 opencode 官方解决。用户只需要安装最新的 opencode，通过 deepseek provider 即可使用，无需额外配置。

1
2
3
4
5
6


问题1
The reasoning_content' in the thinking mode must be passed back to the API.

问题2
Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the
API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

这两个问题已经被官方解决。安装 1.14.29 以及以上版本即可。

以下旧的解决方法：

怎么解决呢？也容易。

如何配置

添加 provider 信息到配置中：

.config/opencode/opencode.json 或者 .config/opencode/opencode.jsonc

修改 provider 部分为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


{
 "provider": {
 "deepseek": {
 "npm": "@ai-sdk/anthropic",
 "name": "DeepSeek",
 "options": {
 "baseURL": "https://api.deepseek.com/anthropic",
 "apiKey": "<apikey>"
 },
 "models": {
 "deepseek-v4-pro": {
 "name": "DeepSeek-V4-Pro",
 "limit": {
 "context": 1048576,
 "output": 262144
 },
 "options": {
 "thinking": {
 "type": "enabled",
 "budgetTokens": 8192
 }
 }
 },
 "deepseek-v4-flash": {
 "name": "DeepSeek-V4-Flash",
 "limit": {
 "context": 1048576,
 "output": 262144
 },
 "options": {
 "thinking": {
 "type": "enabled",
 "budgetTokens": 8192
 }
 }
 }
 }
 }
 }
}

如何使用

选择 deepseek 模型。

效果。

补充

这个方式无法解决问题

Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

如果你遇到这个问题，还需要等待 opencode 去修复。

相关文章：DeepSeek + Claude Code: Thinking Block 兼容性问题分析 — 分析了 Claude Code 使用 DeepSeek 时 extended thinking 模式下多轮对话触发 400 错误的根因，以及社区解决方案。

opencode-actions - 一个 coding review agent

Thu, 23 Apr 2026 11:36:34 +0800

为了方便引入 opencode 来做 code review，我构建了一个 github action repo。和 opencode 一起编程来做这个事情不难。

目前主要提供两个功能，一个是 review，另一个是借助 runner 来执行 opencode （也就是直接用 runner 跑 opencode 的 prompt），来跑一下其他的功能。例如改代码，创建新的 issue，根据 issue 创建 PR 等。

稳定性怎么样？

这个 repo 已经经过多个项目的验证，release 的版本是可靠的。
但是要注意 main 分支的版本是快速迭代版本。

如何引入？

在你的 .github/workflows/opencode-review.yml 下添加：

1
2
3
4
5
6
7
8


- name: Run OpenCode review
 uses: sun-praise/opencode-actions/review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}

 # only one is enough.
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 opencode-go-api-key: ${{ secrets.OPENCODE_GO_API_KEY }}

现在，这个 actions 主要支持的是 Z.AI，ZHIPU，以及 OPENCODE GO 订阅。因此，如果用 ZHIPU，那么在项目中的 secrets 加上自己的 ZHIPU_API_KEY 即可。如果用的是 opencode go 订阅，则需要加上 OPENCODE_GO_API_KEY。

其他的都可以根据默认配置来。默认模型是 zhipuai-coding-plan/glm-5-turbo。如果有更多的配置要求，建议去看原仓库的 README。

我之前在代码审查文章中也有讲过，这个快速地 review 脚本。

差异性

实际上 opencode 自己也有 actions，那么为什么我要再做一个呢？

与官方的差异主要体现在几个方面：

功能	上游状态	本仓库
Model 默认值 fallback	仅 required input	三级 fallback（input → MODEL_NAME → 硬编码默认）
Provider 便捷字段	无	`zhipu-api-key`、`opencode-go-api-key` 等
Review prompt 模板	无	中文格式化 review（可合并/有条件合并/不可合并）
Retry 逻辑	无	attempts / retry-profile / retry-on-regex / retry-delay
执行超时	无	timeout-seconds
版本检查	无	OPENCODE_MIN_VERSION
安装重试	无	install-attempts
XDG cache 缓存	仅缓存 bin	同时缓存 bin + XDG cache

在 sun-praise/opencode-actions#29 中有详细的说明。

review 效果

可以从 repo 本身的 PR 看到 opencode-actions#30

大概是这个效果：

未来

尝试集成 gemini cli。现在 google 的 GEM 3.1 PRO 模型性价比很高，单位智能是最高的。
集成 MCP 插件功能。opencode review 的时候 MCP 如果有，可能会带来更好的 review 效果。
商业化的插件功能集成

探索 opencode 之后，我的一些思考

Tue, 31 Mar 2026 11:30:00 +0800

一个开源工具，让我看清了"不被绑定"的价值，也让我重新理解了《大教堂与集市》

缘起：选择 opencode 作为编程工具

之前我写了一篇博客——《高效省钱：我的 AI Agent 工作流选择》，分享了自己用 opencode + Gemini 3 Flash + 智谱免费 GLM 4.7 构建"省钱又不妥协"的 AI 编程助手的经验。

当时我正想找一个性价比高的方案。Claude Code 的 Pro 计划一个月 20 美元，Max 计划则要 100 美元，对个人开发者来说确实不算便宜。而智谱的 Coding Plan Lite 套餐 20 元/月，加上 opencode 这个开源终端工具，正好组合成了一套"省钱"方案。

真正打动我的，是 opencode 的一个核心特性：它支持 75 种以上的模型供应商——OpenAI、Anthropic、Google Gemini、智谱，甚至本地 Ollama。这意味着我随时可以换模型：用智谱的套餐日常开发，想尝鲜某家新模型时也能快速接入，不会被任何一家绑定。

这正是我想要的：没有 vendor lock-in，不被"花钱的工具"绑架。我用谁家的模型，应该取决于模型能力，而不是因为工具只支持那一家。

从 1 月开始，我就这样用起了 opencode + 智谱 Coding Plan。三个月下来，跑得很熟，体验也一直很稳定。

转折：GitHub 上的"积压"让我心里一沉

直到最近，我随手翻了一下 opencode 的 GitHub 仓库。我看到了大量无人处理的 issue，还有堆了几周甚至几个月的 pull request，没人合并，没人回复。

我心里"嘶"了一下：“这项目是不是没人维护了？”

后来我才知道，2026 年 3 月，Anthropic 向 opencode 发来了正式的法律要求，要求移除所有 Claude 相关的集成。项目方在 1.3.0 版本中执行了这件事，创始人 Dax Raad 公开回应：“我们尽力说服 Anthropic 支持开发者的选择权，但他们派了律师来。”

但说实话，这个法律事件本身我并不太担心。我只是一个用户，用 opencode 跑智谱的套餐，不涉及法律风险。真正让我在意的，是另一个问题——项目的工程治理能力。

opencode 发展很快，功能越做越多，社区贡献者也越来越多。但从 GitHub 上的积压来看，核心团队对 issue 的分类、triage、PR review 的流程，明显没跟上项目膨胀的速度。PR 堆在那里，有人愿意贡献，但没人有精力、有流程去接住这些贡献。说白了就是：项目膨胀了，治理能力没跟上，积压是早晚的事。

一个开源项目，长期没人处理贡献，社区慢慢就凉了。这跟"厂商锁定"是另一种层面的风险：开源工具也会因为没人维护而变得没法用。

开源的安全垫：历史版本可以继续用

但转念一想，我又释然了。

“因为是开源软件，所以 opencode 实际上就算是暂时不维护，我也可以使用历史版本。”

这个想法一下子点醒了我。开源软件和商业 SaaS 的区别就在这：商业工具一旦公司倒闭或停服，你就真的没了；开源项目，哪怕 GitHub 上再也没人合并 PR，我手上那个跑得很顺的版本，照样能用。

模型 API 可能会升级，但那通常有缓冲期，而且 opencode 的 provider 抽象层是独立的，即使官方不更新，社区或我自己也可以 fork 改一下适配层。安全漏洞也许是个问题，但 coding agent 这类工具的风险主要在于代码执行权限，自己注意控制就好。

所以，最坏情况我也能继续用现在的版本，不用急着迁移。但我会保持观察——如果几个月后积压依然严重，可能就要考虑备选方案了。

大教堂与集市：Linus 为什么是大师

积压这个问题，让我想到了《大教堂与集市》。

Eric S. Raymond 把开源开发模式分成两种：大教堂模式（少数人精心设计、封闭开发）和集市模式（开放、迭代快、靠"足够多的眼睛"来捉 bug）。Linux 内核是集市模式的代表。Linus Torvalds 写的代码其实不算多，但他建立了一套让人放心的流程和权威——这才是重点。

集市模式能成功，关键在于有一个清晰的、被信任的维护者来合并代码、建立规范、保持方向。即便 Linus 某段时间回复慢，大家也知道规范在那里，最终会被处理。Linux 活到现在，靠的是大家相信"好代码最终会被合进去"，不是靠 PR 响应速度。

用这个框架看 opencode，它一开始确实带着集市的气质：多模型支持、插件化、社区驱动、快速迭代。但最近积压的 issue 和 PR 暴露了一个问题：集市模式要运转，前提是有一只"看似松散但始终在运作的手"在合并代码。这只手忙不过来了，集市也就乱了。

opencode 缺的是机制，不缺热心人。

我现在的态度：继续用，但保持关注

我现在依然用着 opencode + 智谱 Coding Plan，日常开发没有任何问题。对于项目的未来，我的打算很简单：继续用，但不指望它一定会变好。现有版本够用，哪怕不再更新，我也能撑一段时间。我会关注积压的处理情况——如果两三个月后 PR 开始被清理、核心团队恢复沟通，说明扛过去了；如果还是没人管，就开始看别的方案。好在我选的就是开源方案，代码和数据都不会被锁死，这正是当初选它的原因。

一点最后的想法

这件事让我重新理解了"开源工具 vs 商业 SaaS"。商业 SaaS 省心，但你被绑着。开源工具自由，但项目健康不健康得自己盯着。我还是倾向于开源——我不喜欢把命脉交给一家公司。不过这次也提醒了我：自由不是免费的，得自己盯生态、评风险、想好退路。

Linus 早就说明白了，一个好的开源项目，光靠热情撑不住，得有一套让人信任的规则，还有源源不断愿意维护的人。我希望 opencode 能走过这段波折，继续做那个"不被任何一家模型绑架"的工具。

好工具值得多一点耐心。但耐心也不是无限的。

Codex 和 OpenCode 的上下文压缩

Thu, 19 Mar 2026 11:30:00 +0800

上下文压缩是 coding agent 必备的特性。

最近翻 Codex 文档，看到一个点：它明确提到了 server-side compaction。

我觉得这个点挺有意思。不是说"压缩上下文"这件事本身有多新鲜，而是它把这件事放在服务端做，并且写进了文档。也就是说，上下文管理不是用户自己在提示词层面想办法，而是产品本身就内建了一套机制。

顺手我又去看了一下 OpenCode 的 compaction。两边都叫 compaction，但不是一回事。

Codex 这边强调的是：服务端在上下文达到阈值时，会把前面的交互压缩成一个更短的表示，后续请求继续带着这个压缩后的状态跑。文档里写得很清楚，server-side compaction 会用更少的 tokens 携带之前的关键状态。

OpenCode 这边，我看了一下源码，它也有 compaction，但更像应用层的会话压缩：上下文快满时，调用一个隐藏的 compaction agent 生成 summary，后续请求不再带完整旧历史，而是保留这段 summary 继续。还有 prune 会把旧的工具输出清掉，只保留占位文本。

所以两边虽然名字一样，但关注点不一样：

Codex：服务端的上下文管理能力
OpenCode：应用层的会话状态续写

这个区分我觉得值得记一下。很多人看到同一个词，就默认是同一种机制，其实不是。与其急着比较谁更省、谁更好，不如先把机制边界看清楚。

参考

OpenCode 配置优化记录

Wed, 28 Jan 2026 00:00:00 +0000

不知道大家是否意识到，实际上使用 MCP 等服务的时候，会大量消耗 token。这是由于一次提交的上下文数量过多，导致 token 消耗较大。

那么在使用 opencode 的时候，可以进行哪些优化呢？

我已经进行的优化

1. 启用 Compaction (自动压缩)

1
2
3
4


"compaction": {
 "auto": true, // 上下文满时自动压缩
 "prune": true // 移除旧的工具输出以节省空间
}

效果: 预估节省 20-30% token

2. 配置 Watcher 忽略模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


"watcher": {
 "ignore": [
 "node_modules/**",
 "dist/**",
 ".git/**",
 "*.lock",
 "**/*.log",
 ".cache/**",
 "build/**",
 "__pycache__/**",
 ".venv/**",
 "venv/**"
 ]
}

效果: 减少不必要的文件监控，预估节省 5-10% token

3. 配置 Small Model

1

"small_model": "anthropic/claude-haiku-4-5"

效果: 轻量任务自动使用便宜模型，预估节省 10-20% token

我没有采用的优化项

这里的优化项是我认为暂时没有必要采用的。

5. 减少 MCP 服务 (高优先级)

MCP 工具描述可消耗 6000+ tokens。建议禁用不常用的：

1
2
3
4


"playwright_headless": { "enabled": false },
"zai-mcp-server": { "enabled": false },
"tmux-mcp": { "enabled": false },
"sentry": { "enabled": false }

预估节省: 30-50% token

6. 创建项目级 .ignore 文件

在项目根目录创建 .ignore:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


node_modules/
dist/
build/
*.lock
*.log
coverage/
.next/
__pycache__/
*.pyc
.venv/

7. 使用技巧

使用 /compact 手动压缩长对话
使用 /clear 清理历史
完成任务后开始新会话，避免"上下文腐烂"

不能采用的优化项

这些优化项会导致风控

启用 Anthropic 缓存

1
2
3
4
5
6
7
8


"provider": {
 "anthropic": {
 "options": {
 "setCacheKey": true,
 "timeout": 600000
 }
 }
}

配置文件位置

主配置: ~/.config/opencode/opencode.json
Oh-My-OpenCode: ~/.config/opencode/oh-my-opencode.json
Memory 插件: ~/.config/opencode/opencode-mem.jsonc

参考资料

使用 OpenCode + GLM-5 实现 GitHub PR 自动代码审查

Mon, 26 Jan 2026 00:00:00 +0000

大模型会磨洋工，需要另一个 agent 或 AI 来监督。

最近在项目中集成了 OpenCode 的 AI 代码审查功能，使用智谱 AI 的 GLM-5 模型自动 review PR 代码。本文记录完整的集成过程和踩过的坑。

背景

项目需要一个自动化的代码审查机制：

当 PR 创建或更新时，自动触发 AI 审查
AI 只提供 review 建议，不修改代码
将审查结果以 comment 形式添加到 PR 中

技术选型

OpenCode

OpenCode 是一个开源的 AI coding agent，支持：

多种 LLM 提供商（OpenAI、Anthropic、智谱等）
GitHub/GitLab 集成
在 CI 环境中运行

GLM-5 Coding Plan

选择智谱 AI 的 GLM Coding Plan 原因：

专为 AI 编程优化，支持 OpenCode
价格实惠（$3/月起）
国内访问稳定

TL;DR

如果只是想快速引入 code review，不需要处理权限、凭据等配置，可以直接使用封装好的 action。这是最快引入 code review 的方法，review 结果是中文：

1
2
3
4
5
6
7
8


- name: Run OpenCode review
 uses: Svtter/opencode-actions/review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}

 # only one is enough.
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 opencode-go-api-key: ${{ secrets.OPENCODE_GO_API_KEY }}

只需要配置对应的 secret 即可使用。

配置详解

1. 确定模型格式

OpenCode 的模型格式为 provider_id/model_id。对于智谱 GLM-5：

配置项	值
环境变量	`ZHIPU_API_KEY`
Model 格式	`zhipuai-coding-plan/glm-5`

2. 创建 Workflow 文件

创建 .github/workflows/opencode-review.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


name: OpenCode PR Review

on:
 pull_request:
 types: [opened, synchronize, reopened, ready_for_review]

jobs:
 review:
 name: AI Code Review
 # 仅在 PR 准备就绪时运行（跳过 draft PR）
 if: github.event.pull_request.draft == false
 runs-on: self-hosted
 permissions:
 id-token: write
 contents: read
 pull-requests: write
 issues: write
 steps:
 - name: Checkout repository
 uses: actions/checkout@v6
 with:
 persist-credentials: true
 token: ${{ secrets.GITHUB_TOKEN }}

 - name: Run OpenCode Review
 uses: anomalyco/opencode/github@latest
 env:
 ZHIPU_API_KEY: ${{ secrets.ZHIPU_API_KEY }}
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 with:
 model: zhipuai-coding-plan/glm-5
 use_github_token: true
 prompt: |
 Review this pull request (read-only mode, DO NOT modify any code):

 Please check:
 - Code quality issues
 - Potential bugs or logic errors
 - Code style consistency
 - Security concerns
 - Performance issues
 - Suggest improvements

 Please respond in Chinese. DO NOT modify any code, only provide review comments.

3. 配置 GitHub Secrets

在仓库 Settings → Secrets and variables → Actions 中添加：

ZHIPU_API_KEY: 从 Z.AI Console 获取

踩坑记录

坑 1: 权限不足 (403 Forbidden)

错误信息：

1

Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment

原因：permissions 配置为 read，无法写入 PR comment。

解决：将权限改为 write：

1
2
3


permissions:
 pull-requests: write  # 不是 read
 issues: write  # 不是 read

坑 2: Git 凭据问题

错误信息：

1

fatal: could not read Username for 'https://github.com': No such device or address

原因：checkout 时 persist-credentials: false 导致后续 git 操作无法认证。

解决：

1
2
3
4


- uses: actions/checkout@v6
 with:
 persist-credentials: true # 不是 false
 token: ${{ secrets.GITHUB_TOKEN }}

坑 3: Draft PR 不应触发审查

Draft PR 还在开发中，不需要 AI 审查，浪费资源。

解决：添加条件判断：

1
2
3


jobs:
 review:
 if: github.event.pull_request.draft == false

工作流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


PR opened/updated
 ↓
检查是否为 Draft PR
 ↓ (非 Draft)
GitHub Actions 触发
 ↓
OpenCode 下载并分析 diff
 ↓
GLM-5 生成审查意见
 ↓
自动添加 PR comment
 ↓
开发者查看建议，手动决定是否采纳

效果展示

配置完成后，每次 PR 更新都会自动触发 AI 审查，审查结果会以 comment 形式出现在 PR 页面。

审查内容包括：

代码质量问题
潜在 bug
风格一致性
安全隐患
性能问题
改进建议

成本估算

使用 GLM Coding Plan：

基础套餐 $3/月
中等项目每月约 10-20 次 PR，成本可控

总结

通过 OpenCode + GLM-5 实现自动代码审查：

配置简单：一个 workflow 文件即可
成本低：GLM Coding Plan 价格友好
效果好：GLM-5 在编程任务上表现优秀
安全：只读模式，不会修改代码

参考链接

最近发现好用的 MCP 工具 - OpenCode/Claude Code 配套工具推荐
高效省钱：我的 AI Agent 工作流选择 - OpenCode + Gemini 的高性价比工作流
在虚拟机上运行 Claude Code 实现自动化测试与开发 - 使用 VM + Playwright MCP 实现自动化测试
Git MCP Tools - 让大模型操作 Git 的 MCP 服务

最近发现好用的 MCP 工具

Sat, 17 Jan 2026 22:18:33 +0800

近期大量使用 opencode/claude code 组合来开发，探索了三个比较有用的工具。

他们分别解决了几个问题:

在单服务器上并行开发；控制 tmux： tmux 和 tmux-mcp
让 claude code 不在无意义的位置上停止 ralph-loop
端到端自动化测试 playwright mcp

工具列表

tmux mcp

先让 opencode 配置 Linux 环境的 tmux，然后让 opencode 安装 https://github.com/rinadelph/tmux-mcp.git ；安装完成后即可使用 oc 来控制 tmux 的内容。

可以通过这种方式来重新激活的停止的 opencode session。例如，可以开多个 tmux，然后让其中一个 opencode 通过 tmux 工具来监控，启停任务。

ralph-loop

Ralph 是一个自主 AI 代理循环，它会反复运行 Amp，直到所有 PRD 项都完成。每次迭代都会创建一个全新的 Amp 实例，并具有干净的上下文。

Ralph 最早可能来自这里 https://github.com/snarktank/ralph

因为其卓有成效（实际上是在模型性能进一步提升之后发生的），也被引入了 claude code。

Ralph-loop 是一个 Claude Code 插件，可以让 Claude Code 在完成任务时自动重新启动，形成一个循环执行任务的机制。这对于需要持续改进或迭代的任务特别有用。

安装方法

通过 Claude Code 官方插件市场安装：
- /plugin install ralph-wiggum@claude-plugins-official 或者 cc '/plugin install ralph-wiggum@claude-plugins-official'
配置使用：
- 安装完成后，在 Claude Code 中可以通过 /ralph-loop 命令来启动
- 设置任务和终止条件，Claude Code 会在每次停止时自动重新启动
- 这对于需要多次迭代改进代码、调试或测试的场景特别有用

使用场景

代码重构：让 Claude Code 持续改进代码质量
测试驱动开发：编写测试，然后让 Claude Code 不断改进实现
调试循环：自动重新启动调试会话
持续集成：在本地模拟 CI/CD 流程

这个插件的缺点是非常烧 token；如果没有 max20 订阅，还是不要订阅比较好。但对于需要高质量输出的任务，这个工具可以显著提高工作效率。

playwright mcp

这个插件可以启动浏览器来完成端到端测试，或者编写端到端测试代码。可以更好的形成 loop，来让 cc 或者 oc 改进代码。

安装方法 claude '帮我安装 playwright mcp'

改写成 agents

我建议直接通过 opencode 或者 claude code 将这些工具和 mcp 改写成 agent。

相比于 skills command，这些工具，更适合通过 agent 来调用。agent 上下文很干净，对工具调用几乎是必然的事情。

总结

随着 LLM 越来越强，大量的 mcp，依赖于 LLM 能力的 MCP 自然而然的获得了提升。原本不怎么好用的工具变得更好用了。这也正是迎合了那句话：不要做大模型能力增强之后没有意义的东西。大模型的能力仍然在增强，并且价格在不断下降。

我认为下一步打通不同模态和工具之间的交互，以及给工具赋予大模型的能力，是 agent engineer 必然的发展方向之一。

高效省钱：我的 AI Agent 工作流选择

Mon, 05 Jan 2026 16:00:00 +0800

Claude Code 一个月 $100 费用有些高，很多朋友都有点扛不住。为了解决问题，我实践了一套工作流。

模型方面，我的建议是，选择 Gemini 3 Flash 的按需用量作为替代。

原因：Gemini 3 Flash 性价比极高；响应速度快、处理效率高，价格仅为 Opus 和 Sonnet 的几分之一。对于大多数任务，Flash 版本已经足够使用。

省钱的 Workflow

一个经济实惠的工作流：

制定计划：使用 Gemini 3 Flash
执行构建：使用 OpenCode 提供的免费 GLM 4.7（或 MiniMax M2.1）。亦或者你已经购买了 Zhipu Coding Plan。

提到 Gemini 3 就不能不提 GPT-5.2。

首先，部分工程师不使用 coding agent，而是使用直接使用 ChatGPT.com。这种使用方式且不论是否高效，可靠性就令人担忧。从实际体验来看，GPT-5.2 的回复语气做了拟人化微调，过于迎合用户。虽然可以调整语气，但对于专业开发者来说可能不是最佳选择。

此外，尽管 GPT-5.2 在 SWE-bench veried 上得到了较好的性能，但是我实际体验不好。这就不得不说一下 SWE-bench 的历史：

SWE-bench 最初由普林斯顿大学团队提出（ICLR 2024），用于评估语言模型解决真实 GitHub 问题的能力。

但问题在于：2024年8月，OpenAI 的 Preparedness 团队与原作者合作，推出了 SWE-bench Verified（500个经过人工验证的问题子集）。由于 OpenAI 参与了这个新版本 benchmark 的设计，因此在这个 benchmark 下测试的 OpenAI 模型性能值得怀疑。这并不一定是主观引入性能优化，但是 Bias 在这种情况下，极有可能存在。

还是那句话：从实际使用上来看，codex 总不能带来特别理想的结果。

一些 opencode 技巧

通过 OpenCode 使用 Agent

OpenCode 支持启动 SubAgent。调试前后端代码时，可以让 OpenCode 在不同目录启动 Agent，有效避免权限问题。

OpenSpec：跨 Agent 共享规范

1
2
3
4


1. OpenCode + Gemini 3 Flash → 生成 proposal
2. Codex → 代码审查
3. Claude Code → 再次审查
4. OpenSpec Apply → 最终执行

OpenSpec 生成 spec 是靠谱的，但是有时候便宜模型代码质量不行。这个时候可以多生成几次，使用 spec 生成多次，从中挑选最好的结果。

最后，如果从 PR 看到确实不行，仍可以继续采用 sonnet 4.5 来实现代码。

思考

作为 Agent 工程师，我们需要基于以下趋势做决策：

模型会越来越聪明
执行速度会越来越快
价格会越来越便宜

虽然这是大趋势，但在实际任务中仍需平衡计算速度、成本和最终效果。也许很快就会出现能够自动平衡这些因素的 Agent 系统，但是现阶段考虑这些问题，没错。

Opencode on Svtter's Blog

从 claude code 转向 omp/opencode

为什么

opencode

omp

Multi-Review：多 Agent 并发代码审查的工程实践

为什么需要多 Agent 并发审查？

架构：并发 Reviewer + Coordinator

四个专业 Reviewer

Team 配置

Coordinator：去重和交叉验证

和 Cloudflare 方案的对比

Reasoning Effort 和 Thinking

使用方式

代码实现

和单模型 Review 的关系

未来优化方向

总结

Kimi Code 对 kimi-k2.6 的专用处理：与 OpenCode 的对比

1. 原生 Kimi Provider（非通用 OpenAI 兼容层）

2. reasoning_content 的全生命周期处理

3. JSON Schema 专用规范化（kimi-schema.ts）

4. Thinking 模式的原生配置体系

5. Moonshot 原生服务集成

6. 工具调用层细节

7. CLI 核心与 LLM SDK 的架构隔离

8. Commit 历史揭示的演进路径

kimi-code：原生设计，持续消除配置负担

OpenCode：通用层设计，OpenAI-centric

一个残酷的事实

Commit 历史对比总结

总结：核心差异

OpenCode LLM Provider 层的三连修：从图片序列化到错误信息丢失

背景：opencode 的 LLM 协议层

Bug 1：Tool Result 中的图片被字符串化

问题

修复

根因

Bug 2：Stream Error 信息被吞掉

问题

修复

根因

Bug 3：Anthropic Tool Result 类型检查不稳定

问题

修复

根因

三个 Bug 的关系

对 AI 工具开发的启示

1. 协议层的"够用就行"是最危险的

2. 错误处理要假设最坏情况

3. 修一个 bug 可能暴露下一个

4. 观察 bug 的方式决定了修复速度

总结

OpenCode 的 GitHub Actions 自动化体系：27 个 Workflow 背后的工程实践

总览

CI/测试：扎实但克制

发布/交付：全平台覆盖

自动化/Bot：AI 驱动的社区治理

Issue 管理

PR 管理

AI Code Review

文档与维护

值得借鉴的设计模式

1. 分层治理

2. 合规宽限期

3. AI 用在决策点而不是执行点

4. 显式触发 vs 自动触发

过度自动化的风险

对我们项目的启示

总结

OpenCode 配置之外的优化 — 基于插件的优化

问题：session 内的代码质量谁来把关？

opencode-review 的设计

多维度分析

严重性分级

自动修复链

自动审查的隐性收益：代码质量基线的持续提升

Cooldown 机制

opencode-froggy：另一种思路

对比

2. `reasoning_content` 的全生命周期处理

3. JSON Schema 专用规范化（`kimi-schema.ts`）