黄仁勋说的“未来公司都建在这东西上“：我在 OMO 里看到了 coding agent 的刹车层
黄仁勋说的"未来公司都建在这东西上"：我在 OMO 里看到了 coding agent 的刹车层
上周刷到 Jensen Huang 在 2026 奇点智能产品大会上的 26 分钟对话，有一句话让我反复读了三遍——"相比写 Python，我的工程师更愿意造 Agent。未来公司将建立在 Harness 之上。"
注意，他没说"未来公司将建立在模型之上"。模型是引擎，Harness 是底盘和刹车。引擎再强，没有刹车你不敢上高速。
就在同一天，CSDN 首页推了 Bun 创始人用 Claude 11 天写 100 万行 Rust 的新闻，评论区一片"太强了"。还有一条——Jensen Huang 在奇点大会上那段"未来公司将建立在 Harness 之上"的 26 分钟原话。两件事放在一起看特别有意思：一边是 agent 强到 11 天替代一个团队，一边是 GPU 老板说"引擎之上还得有底盘"。
但我脑子里转的却是另一个问题：这 100 万行里，有多少行是模型"跑飞"了又重写的？有多少行是 agent 在循环里反复修改同一个文件？
没人说。因为跑飞的 token 不会出现在最终 diff 里。
一、GPT-5.6、Codex、Grok 都在做同一件事：把引擎功率拉满
7 月 9 日 OpenAI 发了 GPT-5.6 Sol，Ultra 模式能自动拆任务给多个 subagent 并行跑。官方数据很漂亮——Terminal-Bench 2.1 刷到 91.9%。同一天 Codex 用户从年初 600K 飙到 7M，一天涨 100 万。
然后呢？
然后 GitHub 上 oh-my-openagent（OMO）的 issue 区炸了。他们发了一个 v4.18.0 补丁，标题直接写："GPT-5.6 That Actually Knows When To Stop"。修复了一个真实案例——一个 Codex 任务跑了8 个小时没停下来。
8 小时。不是 8 分钟，不是 80 分钟。
OMO 团队复盘了这次 runaway 的根因链：主 agent 模型不把"停止"当默认行为 + ultrawork prompt 持续召唤 subagent + subagent 也不停 + harness 层缺乏协调机制。四个力往同一个方向推，像四台发动机同时踩油门，刹车片早就磨没了。
这不是 GPT-5.6 独有的问题。Grok Build 开源第二天，马斯克就承认"上传了用户代码"——agent 在自主执行时把不该传的文件也传了。Codex 的 computer use 也有类似反馈：agent 在浏览器里迷路，反复点同一个按钮，token 烧完了任务还没完成。
模型越强，跑飞时越远。这是 harness 层存在的根本原因。
二、OMO 是什么：它不是又一个 coding agent，它是 agent 的 agent
先澄清一个常见误解。OMO（oh-my-openagent）不是 Cursor、不是 Claude Code、不是 Codex。它不跟你抢"写代码"这件事。它做的事情是——让上面这些工具别失控。
GitHub 上 66K stars，中文文档齐全，定位叫"harness"。harness 这个词在 agent 语境里很精确：缰绳、束带、安全绳。它不替代马，它让马不跑出跑道。
OMO 的核心差异是三层 MCP 架构。这里放一张对比表，你一眼就能看懂它和 stock harness 的区别：
| 维度 | stock harness（Codex CLI / Claude Code 原生） | OMO |
|---|---|---|
| MCP 层数 | 1 层（全局常驻） | 3 层（内置 + 兼容 + Skill 按需） |
| 内置 MCP | 无 | websearch(Exa)、context7(官方文档)、grep.app(GitHub 源码搜索) |
| Skill-MCP | 无 | 按需启动 + 作用域隔离，任务完成即刻销毁 |
| AST 理解 | 无 | AST-Grep，25 种语言，语法树级代码重写 |
| LSP 集成 | 无 | lsp_rename / goto_definition / find_references / diagnostics |
| 停止控制 | 依赖模型自觉 | 协调停止边界（main + ultrawork + subagent 一致） |
| 诊断工具 | 无 | doctor 命令，15 项检查分 4 类 |
| OAuth | 基础 | PKCE + DCR（RFC 7591）完整实现 |
这张表看着是功能罗列，但核心逻辑只有一句话：stock harness 假设模型会听话，OMO 假设模型会跑飞。
这个假设差异，决定了整个架构的设计方向。看一个具体例子——OMO 的按需 MCP 配置长这样：
// opencode.jsonc - skill 配置片段 { "skills": [ { "name": "code-review", "description": "Deep code review with AST analysis", "mcpServers": { "ast-analyzer": { "command": "bunx", "args": ["@omo/ast-grep-mcp", "--lang", "ts"] } }, "hooks": { "onComplete": "shutdown:mcp" // skill 完成即销毁 } } ] }注意"onComplete": "shutdown:mcp"这一行。stock harness 里你做不到这件事——MCP server 一旦加载，全程都在。OMO 让 skill 带着自己的工具箱来，干完活把工具箱带走。
OMO 的 doctor 命令是它最像"医生"的部分。运行bunx oh-my-opencode doctor，会并行跑 15 项检查，分 4 类：System（二进制、版本、插件注册）、Config（JSONC 合法性、Zod schema）、Tools（AST-Grep、LSP、GH CLI、MCP server）、Models（缓存、解析、覆盖规则）。
我第一次跑的时候，它报了一个错：本地 LSP server 没启动，但配置文件里声明了 TypeScript 支持。这种"配置和实际不一致"的问题，平时你根本不会发现，直到 agent 试图调用 rename 失败才暴露。doctor 直接告诉你：第 3 类第 2 项挂了，去装 ts-ls。
三、三层 MCP：为什么"全局常驻"是 context 杀手
stock harness 的 MCP 模型很简单：在.mcp.json里声明一堆 server，启动时全部加载，全程常驻。
听起来合理。问题在于 context 窗口。
假设你装了 10 个 MCP server，每个暴露 5 个 tool，每个 tool 的 schema 描述平均 200 token。10 × 5 × 200 =10000 token，光 tool 定义就吃了你 context 的 1%。还没写一行代码，1% 没了。
OMO 的 Skill-MCP 架构解决了这个问题。每个 skill 自带专属 MCP，只在执行该 skill 时加载，完成即销毁。我写代码时不需要 websearch，做调研时才需要。context 窗口始终只装当前任务需要的东西。
这背后是一个设计哲学：agent 的能力边界应该是动态的，不是静态的。stock harness 假设你"可能用到所有工具"，OMO 假设你"当前任务只需要特定工具"。
AST-Grep 和 LSP 是 OMO 的另一层差异化。stock harness 让 agent 用正则表达式搜代码、用字符串替换改代码。这等于让一个编辑用 Ctrl+H 改一本小说。OMO 直接给 agent 接了 AST 级理解和 LSP 级 rename——它知道哪个foo是函数名、哪个是变量名、哪个是字符串里的巧合。
四、GPT-5.6 停止控制：OMO 怎么让"8 小时 runaway"不再发生
这是 OMO v4.18.0 的核心修复。他们给 GPT-5.6 Sol 加了一个 binding，叫WHEN——一个协调的 goal/stop 模型，跨 main agent、ultrawork、subagent 三层一致生效。
原理不复杂，但实现很细。核心思路是：harness 层维护一个"停止条件"状态机，每个 agent 节点在每次 tool call 前检查这个状态。如果状态是"该停了"，当前节点停止召唤下一个 subagent，并把结果回传给主节点。
伪代码长这样：
// OMO 协调停止边界（简化版） class CoordinatedStop { constructor() { this.shouldStop = false; this.reason = null; } // 每个 agent 节点调用 async beforeToolCall(agentId, context) { if (this.shouldStop) { return { action: 'STOP', reason: this.reason }; } // 检查是否满足停止条件 if (this.checkStopConditions(context)) { this.shouldStop = true; this.reason = 'GOAL_ACHIEVED'; return { action: 'STOP', reason: this.reason }; } return { action: 'CONTINUE' }; } checkStopConditions(context) { // 1. 目标已完成 // 2. 循环检测（同一文件连续修改 N 次） // 3. token 预算耗尽 // 4. 用户显式中断 return context.goalAchieved || context.sameFileEdits > 5 || context.tokenBudgetRemaining < 1000; } }这段代码的关键不是"怎么停"，而是"谁决定停"。stock harness 把停止决定权交给模型——但 GPT-5.6 Sol 的设计目标就是"持续工作"，你让它决定停，等于让油门踏板自己判断什么时候该松。
OMO 把停止权收到 harness 层。模型只管干活，harness 负责判断。这就像汽车的油门和刹车是两个独立系统——你永远不应该让同一个部件同时负责加速和减速。
五、我实际用了 OMO 三天，踩了两个坑
第一坑：doctor 报了一个"version mismatch"，说本地 OpenCode binary 版本低于 npm 最新版。我以为是 bug，去 issue 区翻，发现是 Windows 上 npm dist-tag 解析的已知问题。
他们已经在 PR #4960 里修了——把宽泛的catch {}改成精确判断，只对真正的 Error 降级，其他错误直接抛。这个改动很小，但说明一件事：OMO 团队把 doctor 当成产品核心在做，不是附属品。
这个改动很小，但说明一件事：OMO 团队把 doctor 当成产品核心在做，不是附属品。
第二坑：Skill-MCP 的按需加载在 Windows 上有路径问题。我装的一个 skill 声明了 MCP server 路径是~/.cargo/bin/xxx，Windows 上 ~ 展开失败。提了 issue，维护者第二天回复：建议用绝对路径，他们会在下个版本加 Windows 路径规范化。
两个坑都不大，但都指向同一个事实：harness 层是最接近操作系统底层的地方，平台差异、路径问题、版本兼容，全在这里暴露。stock harness 不管这些，OMO 得管。
六、Harness 层会是 agent 战争的终局吗？
回到 Jensen 那句话："未来公司将建立在 Harness 之上。"
我的理解是：模型能力会趋同。GPT-5.6、Claude Fable 5、Gemini 3.5 Pro、Grok 4.5，benchmark 差距在缩小。真正拉开差距的是——谁能让 agent 在企业环境里稳定跑 99 天不出事。
这 99 天里会出什么事？模型版本更新导致行为漂移、MCP server 挂了、agent 跑飞到不该去的目录、token 预算超了、subagent 泄漏了上下文。每一件事都不是模型本身能解决的，都是 harness 层的职责。
OMO 的三层 MCP、doctor 诊断、AST/LSP 集成、协调停止边界，都是在回答同一个问题：怎么让 agent 在"能跑"的基础上"跑不飞"。
这不是一个技术问题，是一个工程纪律问题。就像微服务时代我们学会了"熔断、限流、降级"，agent 时代我们得学会"停止、诊断、隔离"。
如果你现在还在几个 coding agent 之间反复横跳，我的建议是：先别急着选引擎，先看看谁的刹车片厚。
去 GitHub 搜 oh-my-opencode，跑一遍bunx oh-my-opencode doctor，看看你现在的 agent 配置能过几项。这个动作花不了 5 分钟，但会让你对"agent 到底在怎么跑"这件事有完全不一样的认知。