oh-my-opencode 给我的启发

在过去的几天里，我在一个真实且非简单的工程任务中对 opencode + oh-my-opencode 进行了高强度的使用。结果，我对代理系统有了非常明显的理解转变。

这个任务本身具体而毫不妥协地困难：

在 TiKV 上重新实现一个兼容 PostgreSQL 协议的 SQL 层，能够运行基本测试，例如 dvdrental 兼容性测试和 TPC-C。

实际上，这相当于重写 TiDB 的 SQL 层。

我非常清楚这有多难。即使让最小的 TPC-C 工作负载运行起来，我们也花了大约两个月的时间——而且这是团队合作的结果。

最终的结果真的让我感到震撼。

该项目在这里，我不会在这篇文章中展开细节。

让我震惊的不是它是否能完成，而是 完成的速度有多快。

不到一个下午，系统就消耗了超过一百万的 token。因为我使用了各种“Pro Max”代理订阅，这甚至没有转化为额外的支出。

那一刻我才真正意识到：

编写代码的边际成本现在接近于零。 即使是像数据库、操作系统或编译器这样复杂的系统——说实话，从 AI 的角度来看，它们并不那么复杂。

这篇文章是关于这段旅程以及它如何改变了我的思维方式。

1、上下文工程不在于堆叠提示

在切换到 opencode 之前，我已经是一个重度用户，使用过 Claude Code、Gemini Pro 和 Codex 等工具。

结构上，它们都类似： 代理循环 + 工具使用，封装在 CLI 中。

老实说，底层模型能力已经大致趋同。现在每个人都在使用顶级模型。

然而实际结果的差异却很明显。

原因不是模型。 而是 上下文工程。

有一种常见的误解，认为“包装器”是低技术含量的，不包含真正的创新。但我的经验正好相反：这才是真正的深度所在。

有效的上下文工程意味着持续、结构性地将以下内容注入系统中：

• 清晰但不过度指定的目标（人类）
• 明确的计划（代理）
• 工程边界和限制（人类）
• 历史决策和隐含假设（代理）
• 稳定的中间结构，防止模型在长上下文中漂移（代理）

在切换到 opencode + oh-my-opencode 后，模型是一样的，但行为完全不同。

同样的代理循环。 同样的工具使用。 但复杂工程任务的交付质量却达到了完全不同的水平。

我在 oh-my-opencode 中发现的一个特别优雅的设计选择是：

它并不执着于“使用最强的单个模型”。 而是协调 同一工作流中的多个顶级模型。

这不是一个新想法——三个裁缝胜过诸葛亮，这里我们有三个诸葛亮。

结果超出了我的预期。

未来上限不太可能仅来自越来越大的模型。更有可能的是：

多模型协作（在顶级）+ 上下文工程 + 稳定循环作为系统级设计。

2、不中断比“更聪明”更重要

另一个关键且常被忽视的因素是 不间断的流程。

许多代理系统会不断中断过程：

think → execute → error → wait for human confirmation

是的，上下文技术上存在，但工作流是破碎的。

我现在通过 ralph-loop 来解决这个问题，允许代理在稳定的连续循环中无限运行（消耗 token），而人类只有在真正必要时才介入——通常是最终审查的时候。

人类不再被迫充当“下一步指挥官”。

一旦中断减少，差别就非常明显：

• 工程节奏开始类似于真实的连续开发
• 人类的认知负担显著下降

此时，AI 已经足够智能。 工具也已经足够好。

瓶颈是人类。

3、人机界面同样重要

即使在 TUI 中，opencode 的体验也明显优于 Claude Code。我认为核心原因是简单的：

人类需要一种控制感。

一个好的系统确保人类始终了解：

• 系统正在做什么以及接下来要做什么（思考状态、待办事项）
• 为什么这么做
• 何时以及如何进行干预

一旦人类被简化为发出命令并等待结果，体验就会立即恶化。

一个真正优秀的代理系统将复杂性保留在代码和循环中，同时通过精心设计的界面将决策权、节奏和信任返还给人类。

4、当前最糟糕的体验：基础设施

如果我要说出当今代理体验中最薄弱的部分，那仍然是 基础设施：

• 沙盒和运行时配置
• 启动数据库和依赖服务
• 测试环境、夹具、数据准备
• 本地设置与 CI 之间的一致性

这些任务重复、上下文碎片化，并且对代理来说极其不友好。

即使模型可以“写代码”得非常好，一旦遇到基础设施摩擦，势头就会立刻停滞。

真正决定体验上限的下一阶段并不是 opencode 本身，而是：

opencode + 基础设施抽象。

当沙盒、数据库、测试和 CI/CD 成为第一级上下文对象——而不是人类必须拼接的脆弱脚本——代理才能真正从“代码写作助手”进化成持续推动工程前进的系统。

5、“Opencode for XXX” 将很快到来

程序员可能是最早感受到 AGI 到来的群体之一。

不管我们是否喜欢，专业编程工作将会消失。但这不是值得恐慌的事情。人类不再需要为了生存而狩猎，但我们仍然去健身房——为了享受、挑战和思维锻炼。

“传统编程”将作为一种技艺、一种爱好、一种思维游戏而继续存在。

话虽如此，根据最近编程代理的发展轨迹，我相信：

• 上下文工程是可转移的
• 模型能力正变得标准化
• 更多的 token 意味着更多的智能

换句话说，使用相同的原料（LLM）但不同的厨师（Claude Code、opencode），你会得到截然不同的结果——即使你的个人“初始提示”（目标）没有改变。

我们将很快看到如 opencode for XXX、opencode for YYY 的系统。

底层模型可能相同，但通过不同的上下文组织，它们的行为就像完全不同的专业系统。

到那时，“通用模型是否足够强大”的问题将不再重要。

真正的区分因素将是：

谁理解如何构建一个长期运行、稳定、可持续的上下文。

原文链接：Some thoughts after intensive use of opencode + oh-my-opencode

汇智网翻译整理，转载请标明出处