术语与证据边界
读这些材料时，最容易混淆的是事实、官方自述和文章中的比较解释。先把三者的边界摊开，会更容易判断一条说法到底落在哪一层。
如果你想先分清 agent harness 和 harness engineering 分别在说什么，先看 概念入口；如果你更关心判断依据，以及哪些属于研究解释，再读下文。如果你还想知道“应该怎么精读一篇文章，再把它稳定带进概念和比较页面”，可以同时看 文章证据工作法。
三层证据边界
Section titled “三层证据边界”文中的判断尽量拆成三层：
| 层级 | 它是什么 | 在文中通常长什么样 |
|---|---|---|
事实陈述 | 可以直接回到一手来源核对的陈述 | “OpenAI 把 thread / turn / item 暴露成会话原语” |
官方表述 | 项目官方对自己的定位、自述和命名方式 | “X 官方称自己是 AI coding agent / agent harness / multi-agent orchestration” |
研究解释 | 为了让比较成立而做出的工程划分与解释 | “文中把它放到 AI Agents / Agent Harnesses，或写成 Harness Engineering 的实践视角” |
这三层不是互斥关系，但不能混写。
事实陈述 的标准不是“听起来合理”，而是“能回到一手材料确认”。一手材料包括：
- 官方博客 / 工程文章
- 官方文档
- 官方仓库 README
- 官方协议、接口或架构说明
例如：
- Anthropic 区分
workflows和agents - OpenAI 的 Codex App Server 公开了
thread / turn / item这组会话原语 - LangChain 在其博客里明确提出
Agent = Model + Harness
这些都可以算 事实陈述，因为原文里能直接找到。
官方表述 指项目或厂商如何描述自己。它很重要，因为它是理解一个系统“想解决什么问题”的第一入口，但它不自动等于跨项目通用定义。
例如：
- 一个项目官方自称
编程代理 - 一个项目 README 把自己叫作
agent harness - 一个项目把自己描述为
multi-agent orchestration
这些都应优先保留原表达，再决定文章如何解释它。
研究解释 的作用，是把不同来源放进同一个可比较坐标系里。它不是为了取代官方定义，而是为了让比较可以成立。
例如：
- 某个项目更适合被放在
AI Agents - 某套系统更像宿主之上的
Agent Harnesses - 某篇文章强调的是
Harness Engineering的实践问题，而不是对象层分类
这类判断可以很有价值，但必须明确标注为研究解释，而不是写成“官方就是这样定义的”。
从证据边界到阅读方法
Section titled “从证据边界到阅读方法”上面的三层边界主要解决“这句话算哪一层”。但真正读文章时，往往还需要再多问一步：这篇文章把重心压在什么地方？
在仓库里，我们通常把这个问题交给 文章证据工作法：
- 先看文章重心落在哪几个
要素 - 再判断关键句属于
可直接回原文确认、原文 framing还是本文解释
这样做的目的，不是增加复杂度，而是防止把原文内容、作者 framing 和仓库判断混成一种声音。
最容易混淆的几个词
Section titled “最容易混淆的几个词”AI Agents
Section titled “AI Agents”文中用它来指直接作为工作宿主或代理产品出现的系统。它偏对象层。
它首先回答的是：
- 代理在哪里运行
- 代理能不能进入真实工程环境
- 代理有没有完整执行面、工具面和回话面
agent harness
Section titled “agent harness”文中用它来指模型外面那层让代理能工作、能恢复、能被约束的外壳系统。它偏系统对象。
它通常包括：
- 提示词 / 上下文注入
- 工具 / 协议化能力表面 / 中间层
- 执行环境 / 沙箱 / 文件系统
- 记忆 / 进度工件 / 交接表面
- 验证 / 评审 / 审批 / 防护栏
harness engineering
Section titled “harness engineering”文中用它来指人如何设计、调试、约束、简化和演化这层外壳及相关机制的工程实践。它偏方法与实践，不是对象层里的第四类产品。
简化地说：
harness是对象harness engineering是围绕这个对象和相关机制进行的工程活动
宿主（host）
Section titled “宿主（host）”host 指代理实际工作的主工作面，例如终端、IDE、桌面应用或某个核心运行时。它首先回答“代理在哪里工作”。
在本文语境里，像 Codex、Claude Code、OpenCode 这类通常更适合先看成 host。
工作流 / 编排（workflow / orchestration）
Section titled “工作流 / 编排（workflow / orchestration）”它更偏任务组织，关注的是多代理、多模型、多审批节点如何被编进一个更大的闭环。
它可以与 harness 深度重叠，但不自动等于一个独立对象层分类。当前仓库更倾向把很多工作流套件先收进 Agent Harnesses 这一层，再在内部继续区分它究竟更像方法系统还是交付套件。
技能 / 方法系统（skills / methodology）
Section titled “技能 / 方法系统（skills / methodology）”它更偏执行纪律和方法层，例如规格驱动开发、评审纪律、上下文工程和检查清单。
它常常落在 Harness Engineering 的实践层里，也可能被某个 Agent Harness 吸纳，但不自动等于 agent harness 本身。
默认讨论范围
Section titled “默认讨论范围”如果没有额外说明，本文默认讨论的是：
- 软件工程语境中的编程代理
- 代理直接进入代码仓库、命令行、浏览器、测试或其他真实工程工作面
- 长任务、恢复、验证、人类控制面这些问题已经变得重要
这意味着：
- 默认不会把所有代理系统都自动纳入核心研究范围
- 也不会把某个厂商在自己产品里的
harness用法，自动扩张成所有场景的统一定义
什么时候需要保留模糊性
Section titled “什么时候需要保留模糊性”有些边界本来就在漂移，保留这种不稳定性，比强行裁成硬边更诚实：
AI Agents与Agent Harnesses会互相吸收Agent Harnesses与workflow经常重叠skills有时只是外挂层，有时已经成为承重部分- 模型进步会让一些 harness 组件失去必要性，也会让新的组件变得重要
因此，更应该看重“当前主要重心”而不是“永久类别”。
阅读这些材料时的顺序
Section titled “阅读这些材料时的顺序”如果看到一句判断，最稳的读取方式是：
- 先问：这是
事实陈述、官方表述，还是研究解释？ - 再问：这个判断是在什么语境下成立？
- 最后问：它是在说
AI Agents、Agent Harnesses，还是Harness Engineering这条实践视角？
按这个顺序读，更容易判断一条说法到底在说什么。