Chapter 00 · Harness Engineering

包裹模型的 操作系统

模型本身只是 CPU。让"无状态" LLM 变成会用工具、有记忆、能自我纠错的 Agent, 靠的不是模型升级,而是它外围那一整套被称为 Harness 的基础设施。

"如果你不是模型本身,那你就是 Harness。" —— Vivek Trivedy, LangChain

来源 · 原文综述 时长 · 20–30 分钟精读 对接 · Brain OS 编排层 关键概念 · 12 组件 / 7 步循环 / 7 决策
Chapter 01 · 心智模型

原生 LLM 是 没有外设的 CPU

Beren Millidge 给过一个精准的类比:原生大语言模型像一颗没有内存、没有硬盘、也没有 IO 设备的 CPU。 上下文窗口是它的内存(快但小),外部数据库是硬盘(大但慢),工具集成是设备驱动。 而 Harness,就是把这些零件粘起来的操作系统。

冯·诺依曼架构的重新发明

LLM
CPU
Context Window
RAM 内存
External DB
硬盘
Tools
设备驱动

围绕模型的 三个同心圆

从内到外,工程化的范围在不断扩大。Harness 工程包住了前两者。

  • 01
    Prompt Engineering
    精心设计模型每次接收到的指令。最内圈,最早被工程化。
  • 02
    Context Engineering
    管理模型在什么时间点能看到什么内容。压缩、检索、掩码、子智能体浓缩,都是这一层的工作。
  • 03
    Harness Engineering
    前两者 + 工具编排 + 状态持久化 + 错误恢复 + 验证循环 + 安全执行 + 生命周期管理。完整的应用架构。
Core Distinction
"AI 智能体" 是 用户感知到的行为;Harness 是 产生这种行为的机器。 当有人说"我开发了一个智能体",他真正的意思是"我开发了一套 Harness,并把它接入了模型"。
Evidence
LangChain 仅仅通过 改变包裹模型的架构——模型没变,参数没变—— 就让系统在 TerminalBench 2.0 上的排名从 30 名开外飙升到了第 5 名。
Chapter 02 · 解剖结构

生产级 Harness 的 12 个组件

点击卡片查看细节。BRAIN OS 标记的组件,是你已经在 Brain OS 编排层里做出对应实现的。先看它们,再看缺口。

Chapter 03 · 心跳

一次循环里的 7 个动作

Anthropic 把他们的运行时描述为一个"笨循环"——所有智慧都存在模型里,Harness 只负责管理回合切换。 但每一步要做的事并不简单。下面这张图是你 Brain OS 里 claude_step 真正应该长成的样子。

01
提示词组装
Harness 把系统提示、工具定义、记忆文件、对话历史和当前用户消息按优先级栈拼成完整输入。OpenAI Codex 用的是严格的优先级:服务器系统消息 → 工具定义 → 开发者指令 → 用户指令 → 对话历史。
点击节点切换,或用下方按钮播放
01 / 07
Chapter 04 · 主流玩家

同样的概念,五种姿态

所有这些框架都在解决同一个问题,但在"哪部分留给模型、哪部分写死在代码里"上做出了截然不同的选择。理解差异,你就知道自己 Brain OS 的编排层在哪个流派。

Claude Agent SDK

Anthropic
通过一个简单的 query() 函数暴露 Harness。运行时被称为"笨循环"——所有智慧都在模型里,Harness 只负责传话和执行。明确把"权限"和"推理"在架构层分离。
立场 · 模型最大化,Harness 最小化

Agents SDK

OpenAI
代码优先策略。工作流逻辑直接用 Python 表达,不引入复杂的图形语言。三层护栏(输入/输出/工具)+ 四种会话状态方案,绊网机制立即停止智能体。
立场 · 代码即架构,类型即合约

LangGraph

LangChain
把 Harness 建模为显式的状态图。类型化字典在节点间流动,关键步骤"存档"(Checkpointing),可恢复,甚至支持"时间旅行"调试。错误分四类、各有恢复策略。
立场 · 状态显式化,流程精细控

CrewAI

独立框架
基于角色的多智能体协作。一个"流程层"管理确定性的骨干逻辑,角色化的智能体填充具体任务。适合可以分解为分工的工作流。
立场 · 组织模拟,角色即模块

AutoGen

Microsoft
支持多种编排模式:顺序执行、群聊、移交(handoff)、动态任务管理。最灵活但也最容易过度工程化——一切皆可,但你需要自己决定什么时候用什么。
立场 · 编排模式工具箱
Chapter 05 · 架构师的选择题

每个 Harness 都要回答的 7 个问题

两个用相同模型的智能体,性能可能天差地别。差距来自下面这 7 个决策。每一个都附了一条 Brain OS 视角的反思——不是答案,是问题。

Chapter 06 · 接回 Brain OS

已经做了什么,还 缺什么

把这篇文章的 12 个组件投影到你的 Brain OS 上。左边是你的编排层已经覆盖的部分,右边是按文章标准看还薄弱、值得优先补的位置。

已经覆盖

  • 编排循环 YAML pipeline 串起 claude_steplocal_step,本质就是文章描述的"笨循环"。
  • 工具层 local_step 是 Python 工具,claude_step 通过 SKILL.md 注入能力。工具协议清晰。
  • 状态管理 JSONL state store 做 run 持久化,可 resume——和 LangGraph 的 checkpointing 思想一致。
  • 护栏(人在回路) pause_for_review gate 在标题选择、合规风险、最终发布——真实的决策点。这是设计良好的人类介入。
  • 验证循环(部分) DingTalk 项目里的 verify.sh + CLAUDE.md + Playwright E2E + AI screenshot review,恰好覆盖了文章推荐的三种方法。

值得补的缺口

  • 上下文管理 目前 SKILL.md 全量加载。当 pipeline 跑长链条(拆解 → 改写 → 题图 → 合规 → 发布),还没有 compaction、observation masking 或 just-in-time retrieval。是 Brain OS 长跑后失忆的高风险点。
  • 记忆系统的三层结构 ingest / archaeologist / memory-archiver 还是分散的。Claude Code 的"轻索引 + 主题文件 + 原始记录"三层架构,是个值得复刻的标杆。
  • 错误处理分级 目前的错误处理偏粗。LangGraph 的四分类(临时/模型可恢复/用户可修复/上报)可以直接迁移成 pipeline 的错误恢复策略表。
  • 子智能体编排 content-pipeline 链是顺序的,没有 fork / teammate / worktree 模式。当你需要"同时跑 3 个题图候选 + 选最优"这种分支任务时,会成为瓶颈。
  • 跨环境桥 Claude.ai 的 custom skills 和本地 Python CLI 之间还没有桥。这一条不是文章的标准组件,但是你 Brain OS 进入下一阶段的卡点。
随着模型越来越强,Harness 会变薄,
但它永远不会消失
— 协同进化原则
Table of Contents
  1. 01心智模型
  2. 0212 个组件
  3. 037 步循环
  4. 04主流框架
  5. 057 个决策
  6. 06接回 Brain OS