竞争已经转移了。
上个月，OpenAI 发布了文章 Harness engineering: leveraging Codex in an agent-first world。文中的核心结果是：3 名工程师（后来扩展到 7 名）在 5 个月内交付了一个真实产品，而其中没有一行代码是手写的。总计一百万行代码，大约 1,500 个 Pull Request，全部由 Agent 驱动完成。
差不多同一时间，Stripe、Ramp 和 Coinbase 也公开分享了各自编码 Agent 系统的内部实现。
这个信号非常明确：竞争优势已经从“模型能力”本身，转移到了模型之外的一切——也就是 Harness Engineering。
什么是 Harness Engineering？先看一个简单类比：
- Model = CPU（原始算力）
- Context Window = RAM（有限的工作内存）
- Agent Harness = Operating System（管理上下文、启动流程、标准驱动）
- Agent = Application（运行在操作系统上的应用）
Harness 位于 Agent Framework 之上。Framework 提供的是构件，比如工具调用、Agentic 循环。而 Harness 提供的是剩下的那部分：Prompt 预设、标准化工具调用、生命周期钩子，以及你在生产环境中真正需要的能力：规划、文件系统访问、子 Agent 协同、验证闭环。
Harness Engineering = 面向 AI Agent 的控制系统设计。
它的目标是：构建一套基础设施，让 Agent 能在长时间、多轮迭代中持续地产出正确代码，并且这一过程可审计、可回滚、可扩展。
行业现在处于什么阶段
Harness Engineering 已经在顶尖工程组织中进入生产环境：
- Stripe fork 了 Block 开源的 Agent Goose，并构建了 Blueprint，一个在确定性节点与 Agentic 任务节点之间交替运行的状态机。现在他们每周合并 1,300+ 个完全由 Agent 编写的 PR。
- Shopify 开源了 Roast，一个把 AI 步骤与确定性代码交织在一起的工作流框架。
- Ramp 基于 OpenCode 构建了 Inspect，在 Modal 沙箱中运行 session，并支持并行执行。现在他们 30% 的已合并 PR 由 Agent 编写。
- Coinbase 从零构建了 Cloudbot，把 PR 审查周期从 150 小时压缩到 15 小时。
- OpenAI 则把“零手写代码”推进到百万行规模，使用 Codex 驱动完整产品迭代。
这些团队都解决了真实问题：沙箱隔离、上下文预填充（context pre-hydration）、确定性编排。但它们有一个共同的结构性约束：Agent 仍然是单体的。
也就是说：一个模型实例，一个上下文窗口，一条执行路径，从头跑到尾。
单 Agent Harness 的五个结构性限制
随着任务复杂度上升，会出现五个限制：
1. Context Window 是零和博弈
研究、编码、测试、审查，这些上下文全都在争抢同一个窗口。任务越复杂，信息密度就越低。
2. 角色切换带来的认知开销
一个 Agent 不断在架构研究、实现、测试执行之间切换，就像让一个人同时扮演 Tech Lead、SWE、QA 和 Code Reviewer。实践中效果并不好。
3. 长执行链中的漂移
任务链越长，偏离原始目标的概率就越高。没有外部检查点时，错误会传播并叠加。
4. 缺失功能正确性验证
当前实践更关注内部质量与一致性，却对“产品到底能不能正常工作”投入不足。一个代码库可以架构整洁、lint 全绿、文档完备，但业务逻辑仍然可能是错的，用户流程也可能已经坏掉。
5. 终端执行风险
当 Agent 运行 shell 命令时，一条错误命令就可能造成不可逆损害。大多数 Harness 系统依赖黑名单或确认弹窗。黑名单很容易被绕过；确认弹窗会打断流程，而用户往往会习惯性点掉。
如果 Harness Engineering 的定义是“从期望行为反向设计系统”，那么当我们希望 Agent 像工程团队一样协作时，Harness 就必须从“包裹一个单模型”，进化为“组织一个团队”。
我们构建 Experts Mode，就是为了解决这五个问题。在内部基准测试中，它的得分比单 Agent 模式高 67% ，而成本不到后者的 三分之二。这篇文章接下来要讲的，就是这个数字背后的架构。
Qoder 的 Harness Engineering：Experts Mode
上面这五个问题，在 Qoder Experts Mode 中分别对应五种机制。
除此之外，我们还在两个方向上继续推进：
一是 跨模型调度，为每个专家匹配最优模型；
二是 自我进化，让系统从每一次执行中积累经验。
1. 协调与执行分离
Leader 负责协调。它永远不负责实现。
它接收用户需求，拆解任务，管理依赖，跟踪进度，并汇报结果。你可以把它理解成 Tech Lead + 各领域工程师 的组合。
从 Harness Engineering 的角度看，Leader 是一个元 Harness（meta-Harness） ：它管理一组专门化的 Agent Harness，而每个 Harness 都有自己独立的工具集、上下文策略和执行约束。
2. 异步并行：DAG 驱动的任务编排
所有 SWE Agent 默认都以异步并行方式运行。
当 Leader 创建一个专家任务时，系统不会阻塞等待。任务依赖关系形成一个轻量级 DAG：
“实现后端 API”和“构建前端页面”可以并行运行；
“集成测试”则等待两者都完成。
每个专家都在自己独立的上下文窗口里工作，因此零和问题自然消失了。
3. 星型拓扑：集中式协调
SWE Agent 之间不直接通信。所有协调都必须通过 Leader 路由。
我们早期考虑过点对点通信，但最终否决了。因为一旦 Agent 相互直接交谈，就没有谁能掌握全局。两个专家可能做出互相矛盾的决定，而无人察觉。随着团队规模增长，要追踪所有两两连接之间的状态，复杂度会指数级上升。
而以 Leader 为中心的星型拓扑避免了这些问题。
用户本身也处在协调路径中：他们可以随时插入新的指令，而 Leader 会在下一轮调度中接收并处理。
4. 专门化角色：每个专家都是自己的 Harness
这是对最终输出质量影响最大的设计选择。
每个专家都是一个独立 Harness，并且针对特定任务类型进行调优。
它们拥有不同的工具集、不同的上下文注入策略、不同的执行约束。
我们做的不是简单替换 system prompt。
整个 Harness 都不一样。
每个专家的上下文窗口里，只包含与它角色相关的信息。这正是我们处理 Context Rot（上下文腐化） 的方式。角色隔离从源头上消除了上下文竞争，而事实证明，这比我们尝试过的任何压缩策略都更有效。
5. 跨模型调度：Harness 层的模型编排
单 Agent 系统意味着你只能用一个模型做所有事。
但研究需要强推理。
编码需要强代码生成。
浏览器验证需要视觉理解。
这些能力在不同模型之间差异很大。
因为每个专家是独立运行的，所以它们各自可以使用不同模型：
- Researcher expert：使用最强推理模型，用于在搜索结果中做判断与综合
- Dev expert：使用最强代码生成模型
- Browser expert：使用多模态模型，并为简单验证任务准备轻量级 fallback
- Reviewer expert：使用对安全与性能问题最敏感的模型
Leader 会把任务类型与模型能力做匹配，并为整体结果做优化。
这也是为什么质量与成本可以同时优化：
精确的“模型—任务匹配”避免了在不需要某种能力的子任务上，为昂贵能力付费。
在我们的内部基准中：
- 相比 Agent Mode，质量提升 67%
- 相比 Claude Code Agent Teams，质量提升 16%
- 而成本不到它们的 2/3
6. 功能正确性验证：补上行业空白
大多数 Harness 系统能告诉你：代码干不干净。
但更少有系统能告诉你：产品到底能不能正常工作。
我们专门为此构建了三个验证专家：
Browser expert
在真实浏览器里针对真实用户流程运行 E2E 验证。
它检查交互流程、页面渲染以及视觉回归，这些都是静态分析和单元测试覆盖不到的。
QA expert
采用 change-aware context（变更感知上下文） 机制，把验证范围限定在“当前改动实际影响到的代码”，而不是机械地把所有测试都跑一遍。
Code Reviewer expert
运行 语义 diff + 调用链分析，捕捉这样一种情况：某段代码单独看没有问题，但它在调用图的其他地方引入了副作用。
Leader 会把这三种验证嵌入执行链中。验证会在编码完成后立即触发，因此错误能在扩散到下游任务之前被截住。
7. 自我进化：从静态 Harness 到动态学习系统
传统 Harness 系统是静态的。配置一次之后，它就一直那样运行，除非有人手动更新。
我们想要的是一种越用越强的系统。
Qoder Experts 引入了任务级技能提取（task-level skill extraction） 。
当系统检测到一次修正、一次被成功恢复的失败，或者一次明确的用户指令时，Leader 与每个 SWE Agent 都会独立地从自己的领域中提取可复用技能：
- 编码专家提取实现模式
- 验证专家提取检查策略
- 审查专家提取审查启发式规则
这些技能会持久化进入一个记忆系统，并在未来出现相似任务时被自动召回。随着时间推移，系统会停止重复犯那些它已经学会避免的错误。
这个闭环——任务完成 → 技能提取 → 记忆固化 → 技能召回 → 直接成功——才真正把一个静态 Harness 变成了一个会持续改进的系统。
8. 终端执行安全：多平台沙箱与智能拦截
写代码只完成了一半工作。真正的风险存在于执行代码的时候。
第一个问题是解析。不同操作系统的 shell 语法差异极大：
Bash 的反引号嵌套、PowerShell 的管道语法、Cmd 的特殊字符，各不相同。
我们为每种 shell（PowerShell、Bash/Zsh、Cmd）分别构建了独立的 AST 解析器，能够穿透命令嵌套，识别所有真正会执行的子命令。
举个例子：如果一个看似无害的外层命令里嵌入了 $(rm -rf /)，我们的解析器会把 rm 抽取出来，并将其标记为高风险。
解析之后，命令还会经过三层独立风险检查：
- 硬编码黑名单：拦截已知危险命令（如
rm -rf、format、dd if=） - 规则引擎：识别那些单独看无害、组合起来却危险的“命令 + 参数”组合
- LLM 语义分析层：理解命令意图，捕捉前两者遗漏的风险
LLM 层是叠加式的：即便它失效，黑名单和规则引擎仍然会独立生效。
三者中任意一个命中，执行都会被阻断。
即便某条命令通过了三层检查，它也仍然只会在操作系统级沙箱中执行。
我们的原则是：先隔离，再在边界内授予完整权限。
Agent 可以在沙箱内自由操作，但其爆炸半径被严格限制。
Stripe 也有类似做法，他们使用自己的 devbox（“cattle, not pets”），但那要求依赖云基础设施。
而我们把它做成了本地产品能力，能够直接在开发者自己的机器上运行。
Harness 的复杂性不应该转嫁给用户
软件工程中的严谨性并没有消失。它只是迁移了。
从函数实现，迁移到了系统约束。
从人工审查，迁移到了自动化治理。
你不应该为了用一个系统，还得自己去：
- fork 一个开源 Agent
- 搭建沙箱
- 设计 Blueprint
- 写 500 条规则文件
- 实现跨平台安全机制
这些复杂性，不应该落到用户头上。
试试 Qoder 的 Experts Mode（Beta） 。
多个专门化专家，一个任务，零手把手照看。
参考资料
- Harness engineering: leveraging Codex in an agent-first world, OpenAI
- Minions: Stripe's one-shot, end-to-end coding agents, Stripe
- Minions Part 2, Stripe
- Introducing Roast: Structured AI workflows made easy, Shopify
- Why We Built Our Own Background Agent, Ramp
- How Coinbase scaled AI to 1,000+ engineers | Chintan Turakhia, Coinbase
