黄仁勋说的未来公司都建在这东西上我在 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 SolUltra 模式能自动拆任务给多个 subagent 并行跑。官方数据很漂亮——Terminal-Bench 2.1 刷到 91.9%。同一天 Codex 用户从年初 600K 飙到 7M一天涨 100 万。然后呢然后 GitHub 上 oh-my-openagentOMO的 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先澄清一个常见误解。OMOoh-my-openagent不是 Cursor、不是 Claude Code、不是 Codex。它不跟你抢写代码这件事。它做的事情是——让上面这些工具别失控。GitHub 上 66K stars中文文档齐全定位叫harness。harness 这个词在 agent 语境里很精确缰绳、束带、安全绳。它不替代马它让马不跑出跑道。OMO 的核心差异是三层 MCP 架构。这里放一张对比表你一眼就能看懂它和 stock harness 的区别维度stock harnessCodex CLI / Claude Code 原生OMOMCP 层数1 层全局常驻3 层内置 兼容 Skill 按需内置 MCP无websearch(Exa)、context7(官方文档)、grep.app(GitHub 源码搜索)Skill-MCP无按需启动 作用域隔离任务完成即刻销毁AST 理解无AST-Grep25 种语言语法树级代码重写LSP 集成无lsp_rename / goto_definition / find_references / diagnostics停止控制依赖模型自觉协调停止边界main ultrawork subagent 一致诊断工具无doctor 命令15 项检查分 4 类OAuth基础PKCE DCRRFC 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二进制、版本、插件注册、ConfigJSONC 合法性、Zod schema、ToolsAST-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 用正则表达式搜代码、用字符串替换改代码。这等于让一个编辑用 CtrlH 改一本小说。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/xxxWindows 上 ~ 展开失败。提了 issue维护者第二天回复建议用绝对路径他们会在下个版本加 Windows 路径规范化。两个坑都不大但都指向同一个事实harness 层是最接近操作系统底层的地方平台差异、路径问题、版本兼容全在这里暴露。stock harness 不管这些OMO 得管。六、Harness 层会是 agent 战争的终局吗回到 Jensen 那句话未来公司将建立在 Harness 之上。我的理解是模型能力会趋同。GPT-5.6、Claude Fable 5、Gemini 3.5 Pro、Grok 4.5benchmark 差距在缩小。真正拉开差距的是——谁能让 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 到底在怎么跑这件事有完全不一样的认知。