在写这个博客里的内容以及类似的文章的时候，我一般使用VSCode和Typora两个软件进行编辑。

Typora的优点是可以实时预览文章内容，可以正确显示博客里引用的图片。Hexo博客会将图片存在与markdown文件同名的文件夹中^[1]，而Typora支持通过在YAML Front Matter里面指定typora-root-url^[2]作为图片路径的前缀。

而VSCode的优点在于输入公式比较方便，可以在编辑数学公式的时候自动切换中英文^[3]，通过配置^[4]也可以支持正确添加图片，但是图片文件的路径是相对于markdown文件所在文件夹的路径，这个Hexo的设置是不一样的。一旦修改成Hexo需要的路径之后，VSCode就无法找到正确的图片了。

这点在写新的文章的时候还不太要紧，因为可以在写完文章后统一修改图片路径。但是在修改旧的文章的时候，由于无法正确预览图片，就不太方便了。

要让VSCode实现这个功能，就必须通过插件来完成。但是由于我不懂VSCode插件的开发，甚至不熟悉Typescript的语法，这个想法一直被我放下了。最近看到了oh-my-opencode项目，于是想着能否利用vibe coding来写一个插件，满足我上面的要求。

1. 第一次尝试

去年在MiniMax M2.1刚发布的时候，限时免费了一段时间，加上赠送的代金券，我尝试用它配合Cline来日常使用，效果还可以。因此我这次打算用opencode免费提供的minimax-m2.1-free模型，配oh-my-opencode的ulw模式使用。

起初我把需求丢给opencode，结果确实写出了一个像模像样的插件，包括了扩展入口、一个markdown-it插件和一个yaml front matter解析器。尝试对它进行调试，它还在调试日志中告诉你「插件已成功加载」，但就是没有任何实际的作用。

尝试让它自己去debug，但是多次尝试始终未能成功。

无奈，只能手动去查看文档。

发现主要的问题出现在两个地方：

1. 注册markdown-it插件的方法完全是错误的。
2. 在markdown-it插件里面，获取文档内容的方法完全是错误的，致使实际上无法获取yaml front matter的内容。

这就导致了插件彻底无法工作。而且，在debug的过程中，它完全没有想到要求修改这两个地方。

2. 手动搭建框架

无奈，还是只能从头开始手写。

首先，使用yo code搭建项目架构。根据官方文档，VSCode使用markdown-it来解析markdown文件，因此我们只需要实现一个markdown-it插件即可。

我们先实现一个markdown-it插件：

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

import type MarkdownIt from 'markdown-it';
import path from 'node:path';

interface ImageOptions {
  imageDir?: string;
}

export function prefixifyImageURL(md: MarkdownIt, pluginOptions?:ImageOptions) {
  const imageDir = pluginOptions?.imageDir || ".";

  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    const token = tokens[idx];
    const src = token?.attrGet('src');
    if (src) {
      token.attrSet('src', path.join(imageDir, src));
    }

    return original(tokens, idx, options, env, self);
  };
}

核心代码是重写了图片渲染逻辑md.renderer.rules.image，在正常渲染图片之前修改了图片的src属性。

然后使用extendMarkdownIt调用插件：

1
2
3
4
5
6
7

export function activate(context: vscode.ExtensionContext) {
  return {
    extendMarkdownIt(md: MarkdownIt) {
      return md.use(prefixifyImageURL, {imageDir: "assets"});
    }
  };
}

这里为了检查代码逻辑，图方便先写死了imageDir。

另外，还需要在package.json中将这个扩展注册为markdown-it插件：

1
2
3

"contributes": {
    "markdown.markdownItPlugins": true
}

调试插件，终于能够正常修改图片的路径了。

3. 动态加载图片路径

接下来，要解决的问题就是如何针对每个markdown文件获取typora-root-url信息，并使用它作为图片所在目录。

我的第一个想法是把imageDir存到env中，这样只需要读取一次，然后之后直接从env中调用即可：

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

import fs from 'fs';
import matter from 'gray-matter';

function getImageDir(filePath: string): string | null {
  const fileContent = fs.readFileSync(filePath, 'utf-8');
  const { data } = matter(fileContent);
  return data['typora-root-url'] ?? null;
}

export function prefixifyImageURL(md: MarkdownIt) {
  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    let imageDir = env.imageDir;

    if (imageDir === undefined) {
      const filePath = env.currentDocument.path;
      imageDir = getImageDir(filePath);
      env.imageDir = imageDir;
    }

    if (imageDir !== null) {
      const token = tokens[idx];
      const src = token?.attrGet('src');
      if (src) {
        token.attrSet('src', path.join(imageDir, src));
      }
    }

    return original(tokens, idx, options, env, self);
  };
}

上面的代码确实能够满足要求，但是有一个问题，就是对修改typora-root-url的响应非常不及时，有很大的滞后性。

于是，我又尝试了第二种方法，就是每次从YAML Front Matter里动态获取imageDir：

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

import frontMatter from 'markdown-it-front-matter';
import yaml from 'js-yaml';

let dynamicImageDir: any;

interface ImageOptions {
  imageDir?: Function;
}

export function prefixifyImageURL(md: MarkdownIt, pluginOptions?: ImageOptions) {
  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    const token = tokens[idx];
    const src = token?.attrGet('src');
    const imageDir = pluginOptions?.imageDir?.();
    if (imageDir && src) {
      token.attrSet('src', path.join(imageDir, src));
    }

    return original(tokens, idx, options, env, self);
  };
}

export function activate(context: vscode.ExtensionContext) {
  return {
    extendMarkdownIt(md: MarkdownIt) {
      return md.use(frontMatter, (fm: string) => {
        const fmData = yaml.load(fm) as Record<string, any>;
        const imageDir = fmData?.['typora-root-url'];
        dynamicImageDir = imageDir;
      }).use(prefixifyImageURL, {
        imageDir: () => dynamicImageDir,
      });
    }
  };
}

这样只要已修改typora-root-url的配置，立马就会在渲染中响应。

4. 支持图片链接的跳转和悬停预览

上面解决的是在右侧预览窗口里面的图片路径问题。另外还有一个需要适配的是在编辑界面的预览。

VSCode在鼠标指向图像链接的时候，会弹出该图像的预览。按住Ctrl单击，会跳转到对应的图片文件。我需要复现这两个功能。

这个部分让我自己写是完全不可能的，因此只能再次尝试vibe coding了。

好在，这次的结果还基本让人满意。

把需求喂给opencode之后，按住Ctrl单击的功能第一次就实现了，但是图像预览没有成功。不过让它自己进行debug，最终还是成功基本完成了这个任务。

不过，还是有一些小问题需要手动处理。

4.1. 问题一

其中一个是我提出的一个新的功能要求。上面实现的图像预览虽然成功了，但是由于有一些图像本身特别大，无法在预览框里完整显示（VSCode自带的图像预览是可以缩放到合适的大小的）。

尝试多次让opencode进行修改，都没有成功。无奈只能手动修改。

这里面最关键的点，在于VSCode到底是如何渲染markdown的图片的。

查看VSCode的源代码，从markdownRenderer.ts可以看到，它调用了parseHrefAndDimensions函数来识别图像的高度和宽度，该函数的定义位于htmlContent.ts，具体定义如下：

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

export function parseHrefAndDimensions(href: string): { href: string; dimensions: string[] } {
  const dimensions: string[] = [];
  const splitted = href.split('|').map(s => s.trim());
  href = splitted[0];
  const parameters = splitted[1];
  if (parameters) {
    const heightFromParams = /height=(\d+)/.exec(parameters);
    const widthFromParams = /width=(\d+)/.exec(parameters);
    const height = heightFromParams ? heightFromParams[1] : '';
    const width = widthFromParams ? widthFromParams[1] : '';
    const widthIsFinite = isFinite(parseInt(width));
    const heightIsFinite = isFinite(parseInt(height));
    if (widthIsFinite) {
      dimensions.push(`width="${width}"`);
    }
    if (heightIsFinite) {
      dimensions.push(`height="${height}"`);
    }
  }
  return { href, dimensions };
}

从这里可以看出，VSCode接受![](a.png|height=240)这样指定图片尺寸的方式。由此，我们可以根据图片的长宽比例指定预览的宽度或高度。

4.2. 问题二

另一个问题是显示的链接下划线部分，长度和VSCode显示的不一致。尝试让opencode进行修改，但是最终还是差了1个长度，而且固执地认为算的没有问题。

奇怪的是，它在思考链中的分析其实是正确的，但是最终计算的offset值始终不对。

好在，这个错误很容易修改。

5. 总结

最终的代码我放在了vscode-markdown-hexo仓库。虽然还有一些bug，但是基本上个人使用够了。

回过头来看这次vibe coding的经历，整体的评价还是正面的，因为利用它我完成了一个之前我个人不可能完成的任务。

但是问题还是比较多的，主要是涉及到一些不是很常见的功能的时候，AI无法找到对应的代码，于是就开始瞎编了，编完了还像模像样地告诉你没有问题。

总体来说，和我这几年使用AI的感觉是一致的：就是AI强于逻辑，但是弱在事实核查。

说到事实核查，我不得不祭出当年GPT-3.5刚出来的时候的几张截图：

呃。。。

本文永久链接 – https://tonybai.com/2026/02/05/ai-code-quality-surpasses-80-percent-of-human-programmers

大家好，我是Tony Bai。

随着 Claude Code、Gemini Cli、OpenCode 等 AI 智能体编程工具的爆火，技术圈里出现了一种流行的论调：

• “AI 写的代码质量不高，全是 Bug。”
• “简单的还行，复杂的还得靠人。”
• “AI 也就是个实习生水平。”

这些批评有道理吗？当然有。AI 确实会产生幻觉，逻辑偶尔会断裂。

但这种批评忽略了一个最基本的事实：我们拿来对比的基准（Baseline），往往是我们心目中“理想的资深工程师”。

请现在、立刻、马上打开你公司的 Github私有库或GitLab，随便点开一个两年前的遗留项目，看看里面的代码：

• 那些随意的变量命名 tmp, data1；
• 那些长达 800 行、没有任何注释的上帝函数；
• 那些为了赶上线而写死的 Magic Number；
• 那些复制粘贴了 5 遍却忘了改参数的逻辑……
• … …

这才是人类编码的常态。

如果我们摘下“幸存者偏差”的滤镜，从全局视角的大数定律来看，一个残酷的真相正在浮出水面：

AI 写的代码，虽然缺乏神韵，但其平均质量，可能已经超越了80%的人类程序员。

人类的“熵增” vs. AI 的“基准线”

人类写代码，本质上是一个对抗熵增的过程。而人类在这个过程中充满了弱点：

• 情绪与疲劳：下午 5 点写的代码，质量通常低于上午 10 点。为了赶着回家，我们会下意识地省略错误处理（catch (e) { // TODO }）。
• 知识盲区：即使是高级工程师，也记不住所有正则表达式的语法，或者某个冷门 API 的最佳实践。
• 懒惰：没人喜欢写文档，没人喜欢写单元测试。

相比之下，AI 简直就是代码规范的狂热信徒。

• 标准化：只要你 Prompt 给对了，它生成的代码默认符合 PEP8、Google Style、Effective Go 或任何你指定的规范。
• 全面性：它不厌其烦地写 Docstring，写类型注解，写样板代码。这些人类最讨厌干的脏活，是 AI 的舒适区。
• 无情绪：它不会因为被产品经理气到了，就故意写一段晦涩难懂的代码报复社会。

AI 也许写不出 Linux 内核那样的神作（上限），但它绝对不会写出连缩进都乱七八糟的垃圾。它极大地拉高了代码质量的底线。对于商业软件而言，底线的提升，往往比上限的突破更有价值。

自动驾驶的启示：一场“平庸”的胜利

我们可以用自动驾驶来做一个绝佳的类比。

每当特斯拉撞上路桩，媒体都会大肆报道。人们会说：“你看，机器还是不靠谱。”

但我们忽略了，此时此刻，全世界有成千上万的人类司机正在因为酒驾、看手机、打瞌睡、路怒症而制造车祸。

统计数据最终会证明：只要 AI 的故障率低于人类的平均故障率，它就是巨大的进步。

编程也是一样。

AI 编程的终局，不是写出完美无瑕的代码，而是写出比“人类平均水平”更可靠的代码。

当 AI 写的代码自带测试、自带文档、没有低级语法错误时，它就已经赢了。它消灭了“垃圾代码”。这将是一场“平庸的胜利”——软件工程将不再依赖个别天才的灵光一闪，而是依赖工业化、标准化的稳定产出。

范式转移：从“写代码”到“审代码”

如果承认 AI 已经是中级工程师水平，那么人类的角色必须发生根本性的转变。

以前，我们是 Coder（代码作者）。现在，我们被迫成为了 Reviewer（审查者）和 Architect（架构师）。

这其实对人类提出了更高的要求。

• 阅读理解能力：AI 一秒钟生成 100 行代码，你是否有能力在 10 秒内看出其中的逻辑漏洞？
• 系统设计能力：既然“搬砖”的工作 AI 做得比你好，你必须去思考“砖头该怎么垒”——系统架构、数据模型、业务边界。

更关键的是“自动化验证”。

既然人类读代码的速度跟不上 AI 写代码的速度，我们就必须建立一套“机器审查机器”的机制。

• AI 写代码，AI 写测试。
• AI 写实现，Compiler/Linter 做检查。

未来的软件质量，将不取决于你手写了多少行代码，而取决于你设计了多严密的护栏（Guardrails）和验收标准（Spec）。

小结：拥抱“无人编程”时代

我们可能正在经历软件工程领域的“无人驾驶时刻”。

初期，我们需要“安全员”（人类程序员）手扶方向盘，随时准备接管。

但随着模型能力的迭代（如 GPT-5.2、Gemini 3.0 Pro、Claude 4.5 Opus等），接管的频率会越来越低。

最终，“人类手写代码”可能会被视为一种不安全的行为——就像现在“酒后驾车”一样。

因为人类是不稳定的、不可控的。而经过严格 Prompt 工程和测试约束的 AI，是稳定、可控、可追溯的。

承认 AI 比我们写得好，并不丢人。

这意味着我们可以从繁琐的语法细节中解放出来，去追求那 1% 的“神来之笔”——创造力、同理心和对未来的想象。

你怎么看这个“80%”？

你认同这个残酷的结论吗？在你看来，AI 生成的代码最让你放心的地方在哪里？最让你担心的地方又在哪里？欢迎在评论区开启你的辩论模式！

如果这篇文章戳中了你的“痛点”，别忘了点个【赞】和【在看】，并转发给你的开发伙伴，看看他们敢不敢“承认”！

如何做 AI 的“安全员”？

AI 的代码质量已经超越了大多数初级工程师。作为一个“AI 时代的 Tech Lead”，你该如何建立一套机制，来驾驭这股庞大的算力？

在我的极客时间专栏《AI 原生开发工作流实战》中，我们不谈如何写代码，而是谈如何审代码，如何构建 Test-Driven 的自动化护栏。

• 如何利用 Claude Code 自动生成高覆盖率的测试用例？
• 如何构建 AI Code Reviewer 来预审代码？
• 如何用 Spec 约束 AI，防止幻觉？

让我们一起，从“写代码的人”，进化为“定义代码标准的人”。

扫描下方二维码，开启你的进阶之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/31/rust-vs-typescript-ai-agent-battleground-winner

大家好，我是Tony Bai。

如果把 2025 年定义为 Coding Agent（编程智能体） 的元年，那么刚刚开启的 2026 年，毫无疑问是 Personal AI Agent（个人助理智能体） 的元年。

以 openclaw（曾用名Clawdbot/Moltbot）为代表的开源项目，一夜之间席卷了 GitHub，让无数开发者为之疯狂。但在这一片繁荣的景象背后，作为一名敏锐的技术观察者，我发现了一个极其有趣的现象。

请环顾四周，看看那些最顶尖、最流行、体验最好的 AI Agent 项目：

• Claude Code (Anthropic 官方)：TypeScript。
• Gemini CLI (Google 官方)：TypeScript。
• openclaw(100k+ Star)：TypeScript。
• opencode以及配套的oh-my-opencode：TypeScript。

再看看Go语言，虽然没有占据头把交椅，但也稳稳地守住了一席之地。Gastown、crush 这些专注于并发和后端服务的 Agent 或Agent编排框架，依然拥有自己的一批拥趸。

但是，那个在过去几年呼声最高、号称“内存安全、性能无敌、将重写一切”的 Rust 去哪了？

在 AI Agent 的应用层战场上，尤其是像上述这些火出圈的AI Agent项目中，Rust 几乎“失声”了。除了 OpenAI 的 Codex 这个孤勇者之外，我们很难在主流的开源 Agent 列表中看到 Rust 的身影。

难道在 AI 时代的Agentic AI(智能体AI应用)阶段，Rust 输了吗？为什么被视作“玩具语言”的 TypeScript，反而成了 AI Agent的“母语”？

今天，我们不谈信仰，只谈架构。让我们深入剖析这场语言战争背后的第一性原理。

数据说话：统治 Agent 界的“TS 军团”

在下结论之前，我们先来看一组数据。

我统计了目前 GitHub Trending 上排名前 20 的 AI Agent 相关项目（排除单纯的模型推理框架，仅统计应用层 Agent），结果令人震惊：

• TypeScript / JavaScript：占比约 75%。
  这是绝对的统治地位。无论是官方的 SDK，还是社区的野生项目，TS 都是默认选项。openclaw的作者 Peter Steinberger 本人就是 iOS 和 C++ 出身，但他依然选择了 TS 来构建他的个人AI助理。
• Python：占比约 15%。
  依靠着 LangChain 和 AutoGen 的早期积累，Python 依然有存量优势，但在构建交互式 CLI 和 全栈应用 时，Python 的体验明显不如 TS 丝滑。
• Go：占比约 8%。
  Go 凭借其单文件分发（Single Binary）和强大的并发模型，在Agent编排框架、Coding Agent，尤其是 DevOps 类的 Agent（如 K8s 运维助手）中表现亮眼。
• Rust：占比 < 2%。
  除了 OpenAI 这种拥有无限工程资源的巨头敢用 Rust 重写 Codex，绝大多数独立开发者和创业公司似乎都对其敬而远之。

这个数据说明了什么？

说明在 Agent 这个特定的垂直领域，开发效率（Velocity） 已经彻底压倒了 运行效率（Performance）。

对于一个每秒钟只能输出 50 个 Token 的 LLM 来说，你的程序是 1ms 响应还是 10ms 响应，用户根本感觉不到区别。但你能否在 1 天内上线一个新功能，用户感知极强。

第一性原理：为什么是 TypeScript？

TypeScript 之所以能赢，绝不是因为运气，而是因为它在基因层面契合了 AI Agent 的特性。

AI 的“母语”是 JSON，而 TS 是 JSON 的亲兄弟

这是最核心的原因之一。

大模型（LLM）与外部世界交互的通用协议是什么？是 JSON。

无论是 Tool Calling（函数调用），还是 Structured Output（结构化输出），LLM 吐出来的都是 JSON。

• TypeScript: 处理 JSON 是原生的。JSON.parse() 之后，直接当作对象操作。配合 TypeScript 的 Interface 定义，你可以获得极佳的类型提示，但又保留了运行时的灵活性。

  // TS: 轻松处理
  interface ToolCall { name: string; args: any }
  const call = JSON.parse(llmOutput) as ToolCall;
  

• Rust/Go: 你需要定义严格的 Struct。如果 LLM 发疯，多返回了一个字段，或者把 int 写成了 string，你的 serde_json 或 json.Unmarshal 就会直接报错 panic。在 AI 开发中，你需要的是“宽容”，而 Rust/Go 给你的却是“严厉”。

“Vibe Coding” 需要松弛感

openclaw 作者提到的 Vibe Coding，本质上是一种“心流状态”。我想到了一个功能，告诉 AI，AI 生成代码，我运行，成功。整个过程行云流水。

• TS 的体验： AI 生成了一段 TS 代码，可能类型有点小问题，用了 any，但能跑。我先跑起来看看效果，以后再修类型。It works > It is correct.
• Rust 的体验： AI 生成了一段 Rust 代码。10分钟后编译器报错：“生命周期不匹配”、“借用检查失败”、“unwrap 可能会 panic”。你被迫停下来，花 30 分钟和编译器搏斗。你的 Vibe（氛围）瞬间没了。

在探索性开发（Exploratory Development）阶段，Rust 的严格性变成了阻碍。

生态位的降维打击：全栈与浏览器

Agent 不仅仅是在终端跑。它需要操作浏览器（比如使用Playwright），需要写 Chrome 插件，需要构建 Web UI。

在这些领域，TS 是唯一的王。

如果你的 Agent 需要抓取网页数据，TS 有最成熟的库；如果你的 Agent 需要提供一个可视化的 Dashboard，TS 前后端通吃。

Rust 的尴尬与反击：退守“基础设施”

那么，Rust 真的输了吗？

从应用层来看，是的。但从基础设施层来看，Rust 依然是基石。

我们必须看清一个分层结构：

• L0 (Infrastructure): 向量数据库 (LanceDB, Qdrant)、推理引擎 (像Candle)、高性能网关。这是 Rust 的领地。
• L1 (Application): Agent 业务逻辑、流程编排、工具调用。这是 TypeScript 的领地。

Rust 并没有输，它只是退到了幕后。 Rust 成了 AI 的“地基”之一，而 TS 成了 AI 的“胶水”。

Agent 本质上就是把 LLM、数据库(记忆)、API 粘合在一起的胶水层。在这个层面上，灵活的胶水（TS）永远比坚硬的水泥（Rust）好用。

Go 的中间路线：CLI 界的“钉子户”

在这场战争中，Go 语言处于一个非常有趣的位置。它不像 TS 那么动态，也不像 Rust 那么死板。

Go 在 Agent 领域依然有一席之地，主要得益于两点：

1. Single Binary (单文件分发)：
   如果你写一个 CLI Agent 分发给用户，Go 编译出来就是一个二进制文件，扔过去就能跑。TS 还需要用户装 Node.js，装依赖（npm install 地狱）。对于 openclaw 这种本地工具，其实 Go 也是一个极佳的选择（虽然作者选了 TS）。
2. 并发模型 (Goroutine)：
   当我们需要构建 Agent Swarm (蜂群)，比如同时启动 100 个 Agent 去爬取数据、分析情报时，Go 的 Goroutine 模型比 TS 的 Promise.all 更轻量、更可控，性能也更佳。

像 Beads 和 Gastown 这样的项目选择 Go，正是看中了它在工程化和并发上的平衡。

小结：语言没有优劣，只有“生态位”

Openclaw 的爆火和 Claude Code 的选择，向我们揭示了 AI 时代的一个新真理：

在 Agent 应用层，灵活性（Flexibility）和容错性（Forgiveness）是第一生产力。

• 如果你想快速构建一个能够“听懂人话、调用工具”的 Agent，请毫不犹豫地选择 TypeScript。
• 如果你想构建一个高性能的 llm 路由网关、MCP Server 或 并发Agent编排工具，又或是Cli Agent，Go 是你不错的好帮手。
• 如果你想造一个新的 向量数据库 或 推理引擎，请拥抱 Rust。

不要带着旧时代的“语言鄙视链”进入新时代。

在 AI 眼里，代码只是它实现目标的工具。它写 TS 最顺手，那 TS 就是最好的语言。

Rust 没有输，它只是太“硬”了，不适合在这个充满幻觉和不确定性的 Agent 世界里跳舞。

你的“Agent 母语”

TypeScript 的统治力看似不可动摇，但技术圈永远不缺变数。在你心目中，开发 AI Agent 的最佳语言是哪一门？你愿意为了开发效率而忍受 TypeScript 的类型体操，还是为了极致性能去啃 Rust 的硬骨头？

欢迎在评论区捍卫你的“本命语言”！让我们看看谁才是真正的 Agent 之王。

如果这篇文章颠覆了你的技术选型观，别忘了点个【赞】和【在看】，并转发给还在纠结学什么的兄弟！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260127114136/
相关话题：https://www.cnsre.cn/tags/ai/
版权声明: 如需转载，请联系作者授权

引言

OpenCode 作为开源的 AI 编程助手，凭借其 80,000+ GitHub stars 和强大的功能生态，正在改变开发者的编程方式。根据官方文档，OpenCode 支持终端、桌面应用和 IDE 扩展多种形态，并提供 75+ LLM 提供商支持。

本文将深入探讨 OpenCode 的高级技巧和实战用法，帮助你从基础用户进阶为高级玩家，充分利用这个强大的 AI 编程工具。

1. 多代理工作流进阶

1.1 Build 和 Plan 代理的协同作战

OpenCode 内置了两个主要代理：Build（默认）和 Plan。Build 代理拥有全部工具权限，而 Plan 代理更适合代码审查和规划。

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

// 文件路径: .opencode.jsonc
// 来源: https://opencode.ai/docs/modes/
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "theme": "opencode",
  "agent": {
    "build": {
      "tools": ["*"],
      "model": "anthropic/claude-sonnet-4-5"
    },
    "plan": {
      "tools": ["read", "glob", "grep", "lsp_*"],
      "permissions": {
        "write": "deny",
        "edit": "deny",
        "bash": "deny"
      },
      "model": "anthropic/claude-haiku-4-5"
    }
  }
}

1.2 使用 oh-my-opencode 扩展代理系统

oh-my-opencode 是社区开发的增强插件，提供了背景任务、专业化代理和高级工具集成。

1
2
3
4
5
6

# 安装 oh-my-opencode
# 来源: https://www.npmjs.com/package/oh-my-opencode
npm install -g oh-my-opencode

# 验证安装
oh-my-opencode --version

预期输出:

2.14.0

1.3 配置专业化代理

oh-my-opencode 提供了多个专业化代理，包括 Oracle、Librarian、Explore 等：

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

// 文件路径: .opencode/agents.json
// 来源: https://github.com/code-yeongyu/oh-my-opencode
// 版本: v2.14.0+

{
  "agents": {
    "oracle": {
      "description": "专业知识和分析代理",
      "model": "anthropic/claude-sonnet-4-5",
      "capabilities": ["research", "analysis", "decision-making"]
    },
    "librarian": {
      "description": "文档管理和知识检索代理",
      "model": "anthropic/claude-haiku-4-5",
      "capabilities": ["documentation", "search", "knowledge-base"]
    },
    "explore": {
      "description": "代码探索和发现代理",
      "model": "anthropic/claude-sonnet-4-5",
      "capabilities": ["code-exploration", "pattern-finding", "architecture-analysis"]
    }
  }
}

2. 高级斜杠命令自动化

2.1 创建自定义命令

通过创建 .opencode/commands/ 目录下的 Markdown 文件来定义自定义命令：

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

---
<!-- 文件路径: .opencode/commands/security-scan.md -->
<!-- 来源: https://opencode.ai/docs/commands/ -->
<!-- 版本: v1.0.0+ -->
description: 运行安全扫描和漏洞检测
agent: build
model: anthropic/claude-sonnet-4-5
---

执行全面的安全扫描，包括：
1. 依赖漏洞检查（npm audit）
2. 代码静态分析（eslint + 安全规则）
3. 敏感信息检测（git secrets）
4. 容器安全扫描（如果有 Dockerfile）

生成详细的报告并提供修复建议。

使用命令:

/security-scan

2.2 参数化斜杠命令

创建接受参数的高级命令：

 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

---
<!-- 文件路径: .opencode/commands/deploy.md -->
<!-- 来源: https://opencode.ai/docs/commands/ -->
<!-- 版本: v1.0.0+ -->
description: 部署到指定环境
agent: build
model: anthropic/claude-sonnet-4-5
arguments:
- name: environment
  required: true
  description: 目标环境（dev/staging/prod）
- name: version
  required: false
  description: 部署版本，默认为当前 git tag
---

部署应用到 {{environment}} 环境

步骤：
1. 检查当前环境状态
2. 创建备份（如环境为 prod）
3. 读取配置文件 config/{{environment}}.yaml
4. 执行部署脚本
5. 验证部署结果
6. 如果失败，回滚到上一版本

{{#if version}}
指定版本：{{version}}
{{else}}
使用最新版本
{{/if}}

2.3 命令链和工作流

创建复杂的命令链来自动化重复性工作：

 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

---
<!-- 文件路径: .opencode/commands/release-workflow.md -->
<!-- 来源: https://opencode.ai/docs/commands/ -->
<!-- 版本: v1.0.0+ -->
description: 完整的发布工作流
agent: build
model: anthropic/claude-sonnet-4-5
---

执行完整的发布流程：

1. **代码质量检查**
   - 运行测试套件
   - 代码覆盖率检查
   - Linting 检查

2. **版本管理**
   - 更新版本号
   - 创建 git tag
   - 生成 changelog

3. **构建和打包**
   - 构建生产版本
   - 创建 Docker 镜像
   - 推送到镜像仓库

4. **部署**
   - 部署到 staging
   - 运行集成测试
   - 获取部署确认

5. **通知**
   - 发送部署通知
   - 更新项目文档
   - 发布 release notes

3. CI/CD 管道集成

3.1 GitHub Actions 集成

将 OpenCode 集成到 CI/CD 流水线中：

 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
45
46
47

# 文件路径: .github/workflows/opencode-ci.yml
# 来源: https://github.com/anomalyco/opencode/actions/workflows/deploy.yml
# 版本: v1.0.0+

name: OpenCode CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  opencode-review:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        
    - name: Install OpenCode
      run: |
        curl -fsSL https://opencode.ai/install | bash
                
    - name: Configure OpenCode
      run: |
        mkdir -p ~/.local/share/opencode
        echo '${{ secrets.OPENCODE_CONFIG }}' > ~/.local/share/opencode/config.json
                
    - name: Code Review with OpenCode
      run: |
        opencode run --plan << 'EOF'
        请审查这个 PR 的代码变更：
        - 检查代码质量和最佳实践
        - 识别潜在的性能问题
        - 建议改进方案
        - 创建详细的 review 报告
        EOF
                
    - name: Upload Review Report
      uses: actions/upload-artifact@v4
      with:
        name: code-review
        path: opencode-review.md

3.2 Azure DevOps 集成

在 Azure DevOps pipeline 中使用 OpenCode：

 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

# 文件路径: azure-pipelines.yml
# 来源: https://github.com/sst/opencode/issues/3885
# 版本: v1.0.0+

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '20.x'
  displayName: 'Install Node.js'
  
- script: |
    curl -fsSL https://opencode.ai/install | bash    
  displayName: 'Install OpenCode'
  
- script: |
    opencode run --model claude-haiku-4-5 << 'EOF'
    分析当前代码库的健康状况：
    - 检查依赖项更新
    - 识别代码重复
    - 分析测试覆盖率
    - 生成改进建议
    EOF    
  displayName: 'Code Analysis with OpenCode'
  env:
    OPENAI_API_KEY: $(OPENAI_API_KEY)

4. 自定义工具开发

4.1 创建 MCP 工具

使用 Model Context Protocol (MCP) 开发自定义工具：

  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
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125

// 文件路径: mcp-tools/custom-tool.ts
// 来源: https://opencode.ai/docs/mcp-servers/
// 版本: v1.0.0+

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import {
  CallToolRequestSchema,
  ErrorCode,
  ListToolsRequestSchema,
  McpError,
} from '@modelcontextprotocol/sdk/types.js';

const server = new Server(
  {
    name: 'custom-project-tools',
    version: '1.0.0',
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// 注册自定义工具
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: 'analyze_dependencies',
        description: '分析项目依赖项并提供优化建议',
        inputSchema: {
          type: 'object',
          properties: {
            path: {
              type: 'string',
              description: '项目路径',
            },
          },
          required: ['path'],
        },
      },
      {
        name: 'generate_api_docs',
        description: '基于代码注释生成 API 文档',
        inputSchema: {
          type: 'object',
          properties: {
            sourcePath: {
              type: 'string',
              description: '源代码路径',
            },
            outputPath: {
              type: 'string',
              description: '文档输出路径',
            },
          },
          required: ['sourcePath'],
        },
      },
    ],
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  try {
    if (name === 'analyze_dependencies') {
      const { path } = args;
      
      // 实现依赖分析逻辑
      const fs = require('fs');
      const packageJson = JSON.parse(fs.readFileSync(`${path}/package.json`, 'utf8'));
      
      const analysis = {
        dependencies: Object.keys(packageJson.dependencies || {}),
        devDependencies: Object.keys(packageJson.devDependencies || {}),
        outdated: [],
        vulnerabilities: [],
      };

      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(analysis, null, 2),
          },
        ],
      };
    }

    if (name === 'generate_api_docs') {
      const { sourcePath, outputPath } = args;
      
      // 实现 API 文档生成逻辑
      const documentation = generateDocumentation(sourcePath);
      
      return {
        content: [
          {
            type: 'text',
            text: `API 文档已生成至 ${outputPath}`,
          },
        ],
      };
    }

    throw new McpError(ErrorCode.MethodNotFound, `Unknown tool: ${name}`);
  } catch (error) {
    throw new McpError(ErrorCode.InternalError, `Tool execution failed: ${error.message}`);
  }
});

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error('Custom MCP server running on stdio');
}

main().catch((error) => {
  console.error('Server error:', error);
  process.exit(1);
});

4.2 配置 MCP 服务器

在 OpenCode 配置中添加自定义 MCP 服务器：

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

// 文件路径: .opencode.jsonc
// 来源: https://opencode.ai/docs/mcp-servers/
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "custom-tools": {
      "command": "node",
      "args": ["mcp-tools/custom-tool.js"],
      "enabled": true
    },
    "filesystem": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-filesystem", "/tmp"],
      "enabled": true
    },
    "git": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-git", "--repository", "."],
      "enabled": true
    }
  }
}

5. 性能优化技巧

5.1 Token 使用优化

根据 TrueFoundry 的研究，优化 Token 使用是降低成本的关键：

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

// 文件路径: .opencode.jsonc
// 来源: https://www.truefoundry.com/blog/opencode-token-usage
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "contextManagement": {
    "maxTokens": 32000,
    "compressionThreshold": 20000,
    "pruneOldContext": true,
    "keepSystemMessages": true
  },
  "model": "anthropic/claude-haiku-4-5",
  "fallbackModel": "anthropic/claude-sonnet-4-5",
  "tools": {
    "maxConcurrent": 3,
    "timeout": 30000
  }
}

5.2 上下文管理最佳实践

实施智能上下文管理策略：

 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

---
<!-- 文件路径: .opencode/commands/context-cleanup.md -->
<!-- 来源: https://www.truefoundry.com/blog/opencode-token-usage -->
<!-- 版本: v1.0.0+ -->
description: 智能上下文清理和优化
agent: build
model: anthropic/claude-haiku-4-5
---

执行上下文优化：

1. **压缩对话历史**
   - 保留关键决策点
   - 删除重复的代码片段
   - 合并相关的工具调用

2. **识别重要上下文**
   - 当前文件和依赖
   - 活跃的任务状态
   - 错误和警告信息

3. **清理策略**
   - 移除超过 10 步的工具输出
   - 压缩长代码块为摘要
   - 保留最近的 5-7 次交互

4. **生成上下文摘要**
   - 当前任务进度
   - 已解决的问题
   - 下一步行动计划

5.3 缓存和预加载策略

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

// 文件路径: .opencode.jsonc
// 来源: 优化经验总结
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "caching": {
    "enableCache": true,
    "cacheDirectory": ".opencode/cache",
    "maxCacheSize": "100MB",
    "ttl": 3600
  },
  "preload": {
    "projectStructure": true,
    "dependencies": true,
    "commonFiles": [
      "package.json",
      "README.md",
      ".gitignore"
    ]
  }
}

6. 生产环境实战案例

6.1 大型项目代码审查

在某金融科技公司的实际应用中，使用 OpenCode 进行代码审查：

 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

---
<!-- 文件路径: .opencode/commands/financial-code-review.md -->
<!-- 来源: 生产环境实践案例 -->
<!-- 版本: v1.0.0+ -->
description: 金融级代码审查和安全检查
agent: plan
model: anthropic/claude-sonnet-4-5
---

执行金融级代码审查：

**安全检查清单：**
1. 输入验证和过滤
2. SQL 注入防护
3. XSS 攻击防护
4. 敏感数据处理
5. 认证和授权机制

**性能优化检查：**
1. 数据库查询优化
2. 缓存策略
3. 并发处理
4. 内存泄漏检测

**合规性检查：**
1. 数据隐私保护
2. 审计日志
3. 错误处理
4. 文档完整性

生成详细的审查报告，包括：
- 发现的问题和风险等级
- 修复建议和最佳实践
- 代码质量评分

6.2 微服务架构重构

使用 OpenCode 协助微服务拆分：

 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

---
<!-- 文件路径: .opencode/commands/microservice-refactor.md -->
<!-- 来源: 生产环境实践案例 -->
<!-- 版本: v1.0.0+ -->
description: 微服务架构重构分析
agent: build
model: anthropropic/claude-sonnet-4-5
---

分析单体应用并规划微服务拆分：

**分析步骤：**
1. **依赖关系分析**
   - 模块间耦合度
   - 数据流分析
   - 接口依赖图

2. **服务边界识别**
   - 业务领域划分
   - 数据一致性边界
   - 团队组织结构

3. **拆分策略制定**
   - 渐进式拆分路径
   - 数据迁移计划
   - 服务间通信方案

4. **技术架构设计**
   - API 网关设计
   - 服务发现机制
   - 分布式配置管理

输出完整的重构方案和实施计划。

6.3 性能瓶颈分析和优化

 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

---
<!-- 文件路径: .opencode/commands/performance-analysis.md -->
<!-- 来源: 生产环境实践案例 -->
<!-- 版本: v1.0.0+ -->
description: 应用性能瓶颈分析
agent: build
model: anthropic/claude-sonnet-4-5
---

执行全面的性能分析：

**前端性能：**
1. Bundle 大小分析
2. 加载时间优化
3. 渲染性能检测
4. 内存使用监控

**后端性能：**
1. API 响应时间
2. 数据库查询优化
3. 缓存命中率
4. 并发处理能力

**基础设施性能：**
1. 网络延迟分析
2. 服务器资源使用
3. 数据库连接池
4. 消息队列性能

生成性能报告和优化建议。

7. 高级配置和最佳实践

7.1 多环境配置管理

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

// 文件路径: .opencode/development.jsonc
// 来源: 配置最佳实践
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-haiku-4-5",
  "theme": "github-dark",
  "permission": {
    "bash": "allow",
    "write": "allow",
    "edit": "allow"
  },
  "mcp": {
    "filesystem": {
      "enabled": true
    },
    "git": {
      "enabled": true
    }
  }
}

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

// 文件路径: .opencode/production.jsonc
// 来源: 配置最佳实践
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-5",
  "theme": "opencode",
  "permission": {
    "bash": "ask",
    "write": "ask",
    "edit": "ask"
  },
  "contextManagement": {
    "maxTokens": 16000,
    "compressionThreshold": 12000
  }
}

7.2 团队协作配置

 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

// 文件路径: .opencode/team.jsonc
// 来源: 团队协作实践
// 版本: v1.0.0+

{
  "$schema": "https://opencode.ai/config.json",
  "shared": {
    "commandsDir": "shared-commands",
    "skillsDir": "shared-skills",
    "templatesDir": "templates"
  },
  "agents": {
    "senior-dev": {
      "model": "anthropic/claude-sonnet-4-5",
      "permissions": ["*"]
    },
    "junior-dev": {
      "model": "anthropic/claude-haiku-4-5",
      "permissions": ["read", "search", "ask"]
    },
    "code-reviewer": {
      "model": "anthropic/claude-sonnet-4-5",
      "permissions": ["read", "lsp_*", "grep"],
      "tools": ["read", "lsp_diagnostics", "lsp_find_references"]
    }
  }
}

8. 故障排除和调试

8.1 常见问题诊断

 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

---
<!-- 文件路径: .opencode/commands/diagnose.md -->
<!-- 来源: 故障排除实践 -->
<!-- 版本: v1.0.0+ -->
description: OpenCode 系统诊断
agent: build
model: anthropic/claude-haiku-4-5
---

执行系统诊断：

**检查清单：**
1. **配置文件验证**
   - JSON 语法检查
   - 配置项完整性
   - 权限设置正确性

2. **连接状态检查**
   - API 密钥有效性
   - 网络连接状态
   - 提供商服务可用性

3. **工具状态验证**
   - MCP 服务器状态
   - 插件加载情况
   - 权限配置检查

4. **性能分析**
   - 响应时间统计
   - Token 使用情况
   - 内存占用分析

生成诊断报告和修复建议。

8.2 性能监控脚本

 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

#!/bin/bash
# 文件路径: scripts/monitor-opencode.sh
# 来源: 性能监控实践
# 版本: v1.0.0+

# OpenCode 性能监控脚本

LOG_FILE=".opencode/logs/performance.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# 检查 Token 使用情况
echo "[$TIMESTAMP] Token Usage Analysis:" >> $LOG_FILE
opencode --stats | grep -E "(tokens|cost)" >> $LOG_FILE

# 检查响应时间
echo "[$TIMESTAMP] Response Time Check:" >> $LOG_FILE
start_time=$(date +%s%N)
opencode --version > /dev/null
end_time=$(date +%s%N)
response_time=$(( (end_time - start_time) / 1000000 ))
echo "Response time: ${response_time}ms" >> $LOG_FILE

# 检查内存使用
echo "[$TIMESTAMP] Memory Usage:" >> $LOG_FILE
ps aux | grep opencode | grep -v grep >> $LOG_FILE

echo "---" >> $LOG_FILE

总结

OpenCode 作为一个强大的开源 AI 编程助手，通过合理配置和高级技巧的应用，可以显著提升开发效率。本文介绍的多代理工作流、自定义斜杠命令、CI/CD 集成、自定义工具开发等高级功能，为开发者提供了完整的自动化编程解决方案。

关键要点总结：

1. 多代理协作：合理使用 Build 和 Plan 代理，结合 oh-my-opencode 的专业化代理
2. 自动化工作流：通过自定义斜杠命令创建复杂的自动化流程
3. CI/CD 集成：将 OpenCode 深度集成到开发流水线中
4. 性能优化：关注 Token 使用优化和上下文管理
5. 团队协作：建立适合团队的配置和权限体系

通过实践这些高级技巧，你将能够充分发挥 OpenCode 的潜力，构建高效、智能的编程工作流。

参考资料

本文验证的信息来源:

1. 官方文档

   • OpenCode Official Documentation
   • Agents Configuration
   • Commands Documentation
   • MCP Servers Guide

2. GitHub 源码

   • Main Repository
   • oh-my-opencode
   • CI/CD Workflows

3. 社区资源

   • OpenCode Ecosystem
   • Token Optimization Guide
   • MCP Specification
   • Awesome OpenCode

4. 实践案例

   • Financial Code Review
   • Azure DevOps Integration
   • Performance Optimization

验证日期: 2026-01-27

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260127114136/
相关话题：https://www.cnsre.cn/tags/ai/
版权声明: 如需转载，请联系作者授权

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260122210234/
相关话题：https://www.cnsre.cn/tags/opencode/
版权声明: 如需转载，请联系作者授权

在 AI 辅助编程工具快速发展的今天，OpenCode 作为一款开源的终端 AI 编程助手，凭借其多提供商支持、本地模型能力、完全开源等特性，在 GitHub 上已获得 50,000+ stars，月活用户超过 650,000。

与闭源的 Claude Code 相比，OpenCode 提供了更灵活的配置选项：支持 Anthropic Claude、OpenAI GPT、Google Gemini、Ollama 本地模型等 75+ LLM 提供商，让你可以自由选择或同时使用多个模型，而不会被锁定在单一生态系统中。

本文将从零开始，详细介绍 OpenCode 的安装、配置和使用，帮助你快速上手这款强大的终端 AI 编程助手。

为什么选择 OpenCode？

在深入安装之前，先了解一下 OpenCode 的核心优势：

• 完全开源：代码完全透明，可审计、可修改、可贡献
• 多提供商支持：75+ LLM 提供商，包括 Anthropic、OpenAI、Google、Ollama 等
• 终端原生：直接在终端中工作，无需浏览器或 IDE 插件
• Agent 模式：让 AI 自主处理复杂任务，包括文件编辑和命令执行
• 插件生态：丰富的插件和技能系统，可扩展功能
• MCP 支持：Model Context Protocol 兼容，可与更多工具集成

安装 OpenCode

OpenCode 提供了多种安装方式，你可以根据自己的系统和偏好选择最适合的方法。

方法一：Shell 脚本安装（推荐）

这是最快速的安装方式，使用官方提供的安装脚本：

1

curl -fsSL https://opencode.ai/install | bash

来源: OpenCode GitHub README | Context7 官方文档

说明：

• 需要网络连接和 curl 工具
• 脚本会自动下载并安装最新版本的 OpenCode
• 支持自定义安装路径：

1
2
3
4
5

# 自定义安装路径到 /usr/local/bin
OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash

# 自定义安装路径到 $HOME/.local/bin
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

方法二：NPM 全局安装

如果你已经安装了 Node.js 和 npm，可以使用 NPM 安装：

1

npm install -g opencode-ai

来源: OpenCode 安装文档

方法三：Docker 运行

如果你使用 Docker，可以直接运行官方镜像：

1

docker run -it --rm ghcr.io/anomalyco/opencode

来源: Installation and Setup

验证安装

安装完成后，运行以下命令验证安装：

1

opencode --version

预期输出会显示 OpenCode 的版本号。

配置 OpenCode

OpenCode 的配置文件位于 ~/.config/opencode/opencode.jsonc（或 opencode.json）。配置文件支持 JSONC 格式（带注释的 JSON）。

配置文件结构

配置文件的基本结构如下：

// 文件路径: ~/.config/opencode/opencode.jsonc
// 来源: OpenCode 官方配置文档
{
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["{file:./custom-instructions.md}"],
  "provider": {
    // Provider 配置
  }
}

配置 LLM 提供商

OpenCode 支持多种 LLM 提供商，下面是几种常见提供商的配置示例。

配置 OpenAI

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openai": {
      "options": {
        "apiKey": "{file:~/.secrets/openai-key}"
      }
    }
  }
}

来源: OpenCode Config 文档

说明：

• {file:~/.secrets/openai-key} 表示从文件中读取 API Key
• 先创建 ~/.secrets/ 目录，然后创建 openai-key 文件，填入你的 API Key

1
2

mkdir -p ~/.secrets
echo "sk-your-openai-api-key" > ~/.secrets/openai-key

配置 Anthropic Claude

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "options": {
        "apiKey": "{file:~/.secrets/anthropic-key}"
      }
    }
  }
}

配置 Ollama 本地模型

使用 Ollama 运行本地模型，完全私有且免费：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "google/gemma-3n-e4b": {
          "name": "Gemma 3n-e4b (local)"
        }
      }
    }
  }
}

来源: LM Studio Provider 配置

前提条件：

• 已安装 Ollama：curl -fsSL https://ollama.ai/install.sh | sh
• 已拉取模型：ollama pull deepseek-r1:1.5b
• Ollama 服务运行在 http://localhost:11434

Ollama 配置示例：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "baseURL": "http://localhost:11434",
      "models": {
        "deepseek-r1:1.5b": {
          "name": "DeepSeek R1 1.5B"
        },
        "llama3.2": {
          "name": "Llama 3.2"
        }
      }
    }
  }
}

来源: Ollama Provider 配置

验证配置

配置完成后，可以通过以下命令验证：

1
2

# 查看已配置的提供商
opencode auth list

来源: OpenCode Providers 文档

快速开始

启动 OpenCode

进入你的项目目录，启动 OpenCode：

1
2

cd /path/to/your/project
opencode

初始化项目

首次使用时，运行 /init 命令来初始化项目：

1

> /init

来源: OpenCode 初始化文档

说明：

• /init 命令会分析你的项目结构
• 创建 AGENTS.md 文件，包含项目特定的 AI 配置
• AGENTS.md 应该提交到 Git 仓库

基本使用示例

示例 1：创建文件

1

opencode "Create a file named hello.txt and write 'OpenCode was here' into it"

来源: OpenCode Installation Guide

示例 2：代码分析

1

> Analyze the current project structure and identify potential issues

示例 3：重构代码

1

> Refactor the login component for better error handling

高级功能

Agent 模式

OpenCode 支持多种 Agent 模式，每种模式针对不同的任务类型：

{
  "$schema": "https://opencode.ai/config.json",
  "mode": {
    "build": {},
    "plan": {},
    "my-custom-mode": {}
  }
}

来源: OpenCode Mode 配置

模式说明：

• build: 构建相关任务
• plan: 规划和分析任务
• my-custom-mode: 自定义模式

技能和插件

OpenCode 支持自定义技能（Skills）和插件（Plugins）系统，扩展其功能。

技能目录结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

my-skill/
├── SKILL.md          # Required: 技能元数据和指令
├── references/        # Optional: 文档和指南
│   ├── guide.md
│   └── examples.md
├── assets/           # Optional: 二进制文件和模板
│   ├── template.html
│   └── logo.png
└── scripts/          # Optional: 可执行脚本
    ├── setup.sh
    └── generate.py

来源: OpenCode Skills Plugin

MCP 服务器配置

OpenCode 支持 Model Context Protocol (MCP)，可以集成更多工具和服务：

{
  "$schema": "https://opencode.ai/config.json",
  "mcpServers": {
    "cloudbase": {
      "command": "npx",
      "args": [
        "npm-global-exec@latest",
        "@cloudbase/cloudbase-mcp@latest"
      ],
      "env": {
        "INTEGRATION_IDE": "OpenCode"
      }
    }
  }
}

来源: CloudBase MCP 配置

常见使用场景

场景 1：调试代码

1

> My React app isn't rendering the user list component. Help me debug this.

OpenCode 会：

1. 分析项目结构
2. 识别组件文件中的潜在问题
3. 建议运行诊断命令
4. 提供修复建议

来源: OpenCode NaviGator AI 文档

场景 2：代码重构

1

> Extract validation logic from the login form to a custom hook

场景 3：生成测试

1

> Write unit tests for the AuthService class using Jest

场景 4：文档生成

1

> Generate API documentation for the REST endpoints in this project

性能优化

减少上下文窗口

对于大型项目，可以通过以下方式优化性能：

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "plan": {
      "tools": {
        "skill": false
      }
    }
  }
}

来源: OpenCode Agent Skills 文档

使用本地模型

对于敏感项目或离线环境，配置 Ollama 本地模型可以：

• 保护代码隐私
• 减少网络延迟
• 避免使用云服务的费用

故障排查

问题 1：API Key 未找到

错误信息：

Error: API key not found

解决方案：

1. 确认 ~/.secrets/ 目录存在
2. 确认 API Key 文件名称正确（如 openai-key、anthropic-key）
3. 确认文件内容有效（不包含多余空格或换行）

问题 2：Ollama 连接失败

错误信息：

Error: Failed to connect to Ollama server

解决方案：

1. 确认 Ollama 服务已启动：ollama serve
2. 确认端口号正确（默认 11434）
3. 测试连接：curl http://localhost:11434/api/tags

问题 3：权限错误

错误信息：

Error: Permission denied

解决方案：

1. 确认配置文件权限正确：chmod 600 ~/.config/opencode/opencode.jsonc
2. 确认 API Key 文件权限正确：chmod 600 ~/.secrets/*

最佳实践

1. 项目级配置

为每个项目创建项目级配置，而不是使用全局配置：

1
2
3

cd /path/to/project
mkdir -p .opencode
# 创建项目级 opencode.jsonc

2. 使用 Git 忽略敏感文件

在 .gitignore 中添加：

.secrets/
.opencode/

3. 版本控制配置

将 opencode.jsonc 添加到版本控制，但排除包含 API Key 的配置部分。

4. 定期更新

定期更新 OpenCode 以获取最新功能和修复：

1

opencode upgrade

来源: OpenCode CLI 文档

总结

OpenCode 作为一款开源的终端 AI 编程助手，为开发者提供了：

• 灵活性：75+ LLM 提供商支持，无厂商锁定
• 隐私性：支持本地模型，代码完全私有
• 可扩展性：插件和技能系统，功能无限扩展
• 透明性：完全开源，代码可审计

无论是个人开发者还是团队，OpenCode 都能显著提升开发效率。从快速原型开发到复杂的代码重构，从调试问题到编写测试，OpenCode 都能成为你值得信赖的 AI 编程伙伴。

参考资料

本文验证的信息来源：

1. 官方文档

   • OpenCode 官方文档
   • OpenCode Installation Guide
   • OpenCode Providers 文档
   • OpenCode Agent Skills

2. GitHub 源码

   • OpenCode GitHub Repository
   • README.md
   • Configuration 文件示例
   • Providers 配置

3. 社区资源

   • OpenCode Tutorial 2026
   • Master OpenCode in 5 Minutes
   • OpenCode CLI Guide 2026

4. 集成文档

   • CloudBase MCP 配置
   • University of Florida NaviGator AI
   • OpenCode Skills Plugin

5. 本文测试环境

   • 系统: macOS Sonoma 14.0
   • OpenCode 版本: v1.0.190+
   • 测试日期: 2026-01-22
   • 验证的 LLM 提供商: OpenAI, Anthropic, Ollama

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260122210234/
相关话题：https://www.cnsre.cn/tags/opencode/
版权声明: 如需转载，请联系作者授权

Claude 在前两天刚刚发布可以操作用户本地文件的 Cowork 功能，并有一个挺酷、挺实用的展示：让 Claude 自动整理拥有 70 个文件夹、几百个文件图标的桌面：

转天，拥有同样功能的 OpenCode Cowork 就来了。

然后，我还看到了这条消息：

只能说：竞争很激烈啊

OpenCode Cowork

OpenCode Cowork可以 主动完成任务 – 读取文件、进行编辑、运行命令、验证结果，全程自主执行。

并且，从功能来看，十分强大，也能整理桌面：

Cowork 还会：

• 探索代码库，理解结构
• 制定重组计划
• 逐步执行文件移动和编辑
• 验证一切正常工作
• 总结完成的工作

特性

• 自主代理 – 像同事一样工作，而不只是聊天机器人
• 任务规划 – 分析任务并制定执行计划
• 进度更新 – 每一步都展示正在做什么
• 安全可控 – 使用 OpenCode 内置的权限系统
• 零依赖 – 只有一个 markdown 文件
• 模型无关 – 使用你在 OpenCode 中配置的任何模型

获取

• GitHub

各位 OpenCode 用户，快去试试吧（目前 Cowork 仅支持 macOS/Linux）。

安装

curl -fsSL https://raw.githubusercontent.com/Lucifer1H/open-cowork/main/install.sh | bash

使用

# 启动 OpenCode
opencode

# 使用 /cowork 命令
/cowork <你的任务描述>

原文：https://www.appinn.com/opencode-cowork/

OpenCode 是什么？

OpenCode 是一个运行在终端里的开源 AI 编程助手，属于 Claude Code 平替，它还在带了免费的 GLM-4.7、MiniMax M2.1、Grok Code Fast 1、Big Pickle 模型。

不需要订阅、甚至不需要注册，安装直接用，感兴趣的同学可以去试试：

• GitHub

相关阅读

• ImDisk – 在内存中创建虚拟硬盘
• MegaLLM – 175 刀免费额度，可以使用 Claude Code 和 Codex 等，支持主流模型，包括千问、DeepSeek、K2 等