说实话，站在2025年春天的节点上往回kan，AI圈子里发生了一件挺耐人寻味的事儿。各家大厂你追我赶，GPT-4来了Claude Opus也上了Gemini Progeng是不甘示弱。但hen多真正在一线“搬砖”的工程师发现了一个扎心的事实：单纯换个geng强的模型，对实际产出的提升，远不如把模型外面那一圈“配套设施”搞好来得猛。

这并不是什么空穴来风的判断，而是有一组相当有说服力的实验数据在背后撑腰。这其实揭示了一个即将在2026年成为主流的趋势：我们不再仅仅关注模型本身，而是开始关注如何“驾驭”它。这“外面那一圈东西”，现在有了一个正式且响亮的名字——Harness Engineering。

从“模型崇拜”到“驾驭工程”的范式转移

咱们得先搞清楚一个概念。2025年1月3日HashiCorp 的联合创始人 Mitchell Hashimoto 在一篇博客里首次明确提出了这个术语。仅仅六天后OpenAI 在他们那篇备受瞩目的“百万行代码实验报告”里正式采用了这个词。紧接着，连大名鼎鼎的 Martin Fowler也跟进撰文。这阵仗，基本上等于给行业定调了。

hen多人会问：这玩意儿和 LangChain、AutoGen、CrewAI 这些 Agent 框架是什么关系？是替代还是升级？

答案hen明确：Harness 不是 Framework 的替代品，而是位于它们之上的一层。

打个比方，模型是一匹日行千里的良驹，而 Harness 就是缰绳、马鞍和马蹄铁。缰绳的存在不是为了把马勒住不让它跑，而是为了确保它在正确的赛道上全力冲刺，别跑偏到沟里去。这三者不是替代关系，而是嵌套包含关系：Prompt ⊂ Context ⊂ Harness。

核心公式其实就一行字：Agent = Model + Harness。

模型决定了系统的上限，而 Harness 决定了系统的底线。在未来的竞争格局中，两者缺一不可。但Ru果从投入产出比的角度来kan，目前 Harness 的杠杆率远高于单纯的模型升级。与其苦等下一个geng强的模型发布，不如现在就把项目的 AGENTS.md 写好、把 Linter 规则配上、把验证闭环搭起来。这事儿一点dou不遥远，它Yi经在发生了。

六层架构：重新审视技术栈

业内目前比较被认可的是一套六层体系框架，层层递进，形成了一个完整的闭环。咱们Ke以把它想象成一个金字塔：

┌─────────────────────────────────────────────────┐
│  Harness Layer                          │
│  约束 · 反馈循环 · 上下文工程 · 熵管理 · 生命周期  │
├─────────────────────────────────────────────────┤
│  Agent Frameworks │
│  智Neng体定义 · 消息路由 · 任务生命周期               │
├─────────────────────────────────────────────────┤
│  SDK / API         │
│  模型调用 · 工具注册 · 流式输出                     │
├─────────────────────────────────────────────────┤
│  Foundation Model        │
└─────────────────────────────────────────────────┘

有一个非常敏锐的观察：模型正在逐渐吸收框架大约 20% 的功Neng。但剩下那 80%——比如持久化、确定性重放、成本控制、可观测性、错误恢复——恰好是驾驭层的价值所在。这“六层的核心价值”就在于从 L1到 L6形成完整闭环。建议从 L1 和 L6 入手，L1 决定了 Agent 知道该干什么L6 决定了它搞砸了Neng不Neng拉回来这两层的投入产出比是Zui高的。

CodeBuddy IDE：天然的 Harness 载体

Harness Engineering 的核心洞察其实就一句话：工程化。落实到具体工具上，CodeBuddy IDE 本身就是一个比较完整的 Harness 载体。它的 Craft Agent 模式、MCP 协议支持、Skills 系统、Working Memory 机制，天然适合落地 Harness Engineering。

具体该怎么Zuo？咱们拆开来kan。

1. 创建项目级 AGENTS.md：给 AI 的岗位说明书

这就相当于给新入职的员工发一份岗位说明书。不是把公司所有的文档一股脑dou塞给它，而是明确告诉它：“你负责什么、相关资料在哪里、不用管的别kan”。

你Ke以在项目根目录或者 .codebuddy/ 目录下创建这个文件，内容Zui好控制在一定行数以内，保持精炼。CodeBuddy 的 Plan 模式天然实现了“规划与执行分离”。对于复杂功Neng，先用 Plan 模式审批方案，确认无误后再切换到 Craft 模式执行。这就像让 Agent 像人一样走完“理解目标 → 判断信息 → 分析 → 生成 → 检查”的完整轨道，而不是一股脑全干完。

2. Skills 按需加载：拒绝上下文臃肿

CodeBuddy 的 Skills 系统本质上就是 Anthropic 所说的“延迟加载层”。会话开始的时候，它不占用上下文，只有在被触发时才注入。合理组织项目 Skills，Ke以有效控制上下文利用率，避开那个危险的“Dumb Zone”。

这里有个格外危险的特性：Agent 非常擅长模式复制——包括坏模式。Ru果不加约束，Agent 会以惊人的速度积累技术债务。所以按需加载技Neng，只给它当下需要的，是防止它“学坏”的关键。

3. 配置 CodeBuddy 的 Working Memory：解决状态管理

解决什么问题长任务中间结果怎么管？Agent 怎么知道自己Zuo对了没有？

CodeBuddy 的 .codebuddy/memory/ 目录就是 L4的天然实现。在日常开发中，把关键决策、踩坑记录写进去，Agent 下次启动时会自动读取，不用每次dou重新交代上下文。这就像是独立管理当前任务状态、中间产物和长期记忆，防止上下文腐化。

Anthropic 的Zuo法hen有启发性——他们不压缩上下文，而是启动一个全新的 Agent + 结构化交接文档来恢复状态，这有点像重启进程来解决内存泄漏的问题。

4. MCP 集成：打通外部世界

解决什么问题Agent 怎么跟外部世界交互。

CodeBuddy 原生支持 MCP。你Ke以根据项目需要配置 MCP Server。比如在配置文件里写入 Playwright 和 GitHub 的服务配置：

// ~/.codebuddy/mcp.json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": 
    },
    "github": {
      "command": "npx",
      "args": ,
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

这样，Craft Agent 在执行任务时就Ke以直接调用 Playwright Zuo端到端验证，或者通过 GitHub MCP 创建 Issue 和 PR。工具的选拔、调用时机、结果的提炼与反馈，这一套流程的数据hen有参考价值：通过“Tool Search Tool”按需发现工具，仅加载当前任务实际需要的工具，Neng节省大量的上下文 Token，同时显著提升准确率。

避开“Dumb Zone”：上下文管理的艺术

Dex Horthy 发现了一个非常实际的问题：即便你有 168K token 的上下文窗口，用到大约 30% 到 40% 的时候，Agent 的输出质量就开始明显下降。他管这叫“Dumb Zone”——0% 到 30% 是 Smart Zone，推理清晰、工具调用准确；一旦超过 40%，它就开始出幻觉、兜圈子、格式混乱。

这说明什么？上下文不是越多越好，管理上下文的手段才是关键。

一个叫 Can Bölük 的开发者Zuo了个大规模测试，涉及 7 个模型、3 种编辑格式、每种 50 个任务。他把编辑工具格式从 str_replace 换成自创的 hashline，模型完全没动——结果呢？效果提升显著。这 印证了 Harness 的重要性。

这里有一份实用的维护清单，建议收藏：

□ codebuddy.md 保持精简，每次 Agent 犯新错就geng新
□ Working Memory 记录关键架构决策和踩坑点
□ MCP Server 按需配置，不贪多
□ Linter 规则的错误信息带修复建议
□ 复杂功Neng先 Plan 再 Craft
□ 定期清理 .codebuddy/memory/ 中过期的日志
□ 每两周回顾一次 codebuddy.md，删掉不再需要的规则

Linter 规则即 Prompt：自动验证的魔力

这是 Harness Engineering 投入产出比Zui高的实践之一。核心思路hen简单：每条 Linter 错误信息本身，就是一个自动触发的 Prompt。

利用 CodeBuddy 的 Hook 机制，要求 Agent 每次编辑代码后自动运行测试。Ru果失败，Agent 会拿着错误信息自动修复，根本不需要人介入。

OpenAI 的经验是“自定义 Linter + 结构测试强制执行”。他们内部有句话说得特别狠：“If it cannot be enforced mechanically, agents will deviate.”。

咱们来kan个具体的例子。比如写一个禁止直接使用 fetch 的规则：

// eslint-rules/no-raw-fetch.js
module.exports = {
  meta: {
    messages: {
      noRawFetch: .join
    }
  }
};

Agent kan到这种报错，不需要任何额外提示就Neng自己改对。这就把被动的“报错”变成了主动的“教学”。Anthropic 工程师了三种典型失败模式，Zuo过 AI 编程的大概dou中过招，而这种机制正好Neng对症下药。

数据不会说谎：Harness 的实战威力

咱们来kankan几个震撼的案例，你就知道这事儿有多值了。

这是 2025 年初Zui震撼的案例之一。LangChain 团队底层模型一个参数dou没改，纯靠优化外部驾驭环境，在 Terminal Bench 上的分数从 个位数飙升到两位数，全球排名从第 18 名直接跳到了第 3 名。这简直是“换壳如换机”。

还有 Grok Code Fast，其成功率从 个位数飙到了 60% 以上，翻了整整十倍。这靠的dou不是模型参数的微调，而是工程化手段的介入。

Anthropic 的 Planner → Generator → Evaluator 三 Agent 编排，Stripe 的混合状态机，dou是这一层的典型实现。预设规则拦截错误，失败时提供重试或回滚，这些机制共同构成了一个健壮的系统。

工程师角色的蜕变：从码农到建筑师

随着 Harness Engineering 的普及，工程师的角色正在发生深刻的转变。我们正在从“代码编写者”转变为“环境建筑师”——从直接构建产品，转向构建Neng够构建产品的工厂。

有人得hen精辟：“你在怪飞行员技术差，其实是起落架坏了。” 当我们抱怨 AI 写不出好代码时也许应该检查一下我们为它准备的 Harness 是否足够坚固。

成熟度自评：你在哪一层？

Zui后给一个成熟度参考，方便大家对号入座：

大多数团队目前在 Level 2 到 Level 3 之间。不用着急上 Level 6——从一份好的 AGENTS.md 和一条带修复建议的 Linter 规则开始，比什么dou不Zuo强一百倍。

回顾一下这几年 AI 工程方法论的演变脉络，会发现有一条清晰的递进关系。人工智Neng和自动化长期以来一直在工作场所引起焦虑，企业高管也没有Zuo太多事情来平息这些担忧。相反，该领域的进步Yi经导致越来越多的……嗯，变革。但与其焦虑，不如行动。

2026年的核心战场，不在模型参数的比拼，而在驾驭工程的较量。谁Neng把缰绳勒得geng紧，谁Neng把马鞍配得geng稳，谁就Neng让这匹千里马跑得geng远。这就是未来的答案。

---