阶段 1
代码补全
目标是把局部生成质量做得更高。
瓶颈：模型能不能写对这一段代码？
Everything Harness Engineering
仓库当前聚焦三件事：`AI Agents` 如何提供真实执行宿主，`Agent Harnesses` 如何补控制与恢复，以及 `Harness Engineering` 如何把命令、MCP、工具、钩子、技能、子代理等机制组织成可运行的开发方法。
概念入口
先把 AI Agents、Agent Harnesses 和 Harness Engineering 的边界说清楚。
Harness Engineering 讨论的是人如何站在 AI Agents 与 Agent Harnesses 提供的工作面之上，把命令、MCP、钩子、技能、子代理、记忆和审批机制组织成可持续、可控、可验证的开发系统。
更稳的理解方式是先分开三件事：AI Agents 提供主执行宿主，
Agent Harnesses 在其上补控制面、恢复面与用户参与契约，
命令 / MCP / 钩子 / 技能 / 子代理 / 记忆 / 审批 是这些系统调用和编排的机制层，
Harness Engineering 则是人如何把这些能力编成长期开发方法。
演进与瓶颈
AI 编程范式在演进，瓶颈也在迁移。
讨论之所以会从补全、对话式编程一路转向 AI Agents、Agent Harnesses 和
Harness Engineering，本质上是因为瓶颈已经从生成质量迁移到了底层能力、恢复能力和控制结构。
真正变重的是模型之外的执行宿主、外层 harness 和人类围绕它们组织出的长期方法。
阶段 2
对话式编程
开始跨文件理解需求、解释代码、提出修改。
瓶颈：上下文理解够不够完整？
阶段 3
AI Agents
代理直接读仓库、改文件、跑命令、做验证。
瓶颈：能不能把单次任务真正执行完？
阶段 4
Agent Harnesses
控制、恢复、记忆、规则与交接开始变成核心。
瓶颈：长任务能否持续、可控、可恢复地跑？
阶段 5
Harness Engineering
控制、交接、评审、规则和长期方法进入主舞台。
瓶颈：怎样把这些能力组织成长期、稳定、可治理的开发方法？
真正重要的不是某一层替代了前一层，而是瓶颈在持续外移，系统必须回答的问题也随之改变。
关键文章
想把这条领域线看清，最好回到把宿主、harness 和实践问题逐步说清楚的那些文章。
这不是资料堆砌，而是两条逐渐分开的线：一条解释 AI Agents 和
Agent Harnesses 的对象边界怎样变清晰，另一条解释 Harness Engineering
为什么会变成独立的工程实践语言。
2024-12
2025-09
2025-11
Effective Harnesses for Long-Running Agents
Anthropic
通过交接、进度跟踪与任务续跑，把 agent harness 的长任务设计具体落到编程代理场景里。
2026-02
2026-03
基本构成
要理解 Harness Engineering，先要看清宿主和 Agent Harnesses 暴露了哪些底层能力。
这些能力不都来自同一层。AI Agents 先提供主执行面， Agent Harnesses 再把状态、控制、恢复和流程编成外层系统。下面这些项更适合先看成 harness 机制：它们是被系统调用和组合的能力，不等于对象层分类本身。
状态与持久化
让代理不只活在单个上下文窗口里，而能跨会话保存和恢复工作状态。
工具与接口表面
为代理提供可用、可理解、边界清晰的工具表面，而不是只给人类友好的接口。
执行环境
给代理一个真正能读写文件、执行命令、安装依赖并与外部系统交互的工作面。
反馈与验证回路
通过测试、浏览器、日志、指标、评审等信号，让代理能观察结果并继续修正。
上下文管理与知识注入
决定代理在每次运行时看到什么知识、看到多少，以及如何避免上下文腐坏。
约束、规则与边界
用防护栏、架构规则、工具边界和停止条件保证行为可控。
续跑、交接与恢复
让长任务在多轮会话之间仍能持续推进，而不是每次都从猜测当前状态开始。
人类控制面
保留意图、优先级、审批、检查点和停止条件，使“人类掌舵，代理执行”真正成立。
生态与比较
现在有哪些代表性选择，以及这些项目应该怎么放在一起比较？
最大的误区不是漏看项目，而是把不在同一层的问题拿来做同一种比较。
更稳的读法是先把 `AI Agents` 和 `Agent Harnesses` 这两层对象对齐，再把 `Harness Engineering` 当作横切实践线，比较它们各自的控制面、状态面和用户参与契约。
比较时先把两层对象和一条实践线分开，再看项目到底落在哪一层：
- AI Agents 如何让代理真正进入仓库、执行命令、修改文件并完成单次工程任务？
- Agent Harnesses 如何把编程代理提升成更可恢复、更可协作、更可治理的工程环境？
- Harness Engineering 如何把这些机制组织成稳定、长期、可治理的开发方法？
下面这张表先把主要项目放到同一张比较坐标里；首页只给一张总览表，具体子形态和证据边界在生态页继续展开。
| 套件 | 简介 | 定位 | 运行形态 |
|---|---|---|---|
| Anthropic 官方把它描述成面向编程的代理工具；更适合把它看成编程代理的宿主。 | AI Agents | 独立代理宿主 | |
| OpenAI 官方将 Codex CLI 描述为运行在本地机器上的编程代理；它的 CLI 形态是这一层的典型代表。 | AI Agents | 独立代理宿主 | |
| 官方自称开源 AI 编程代理，可作为终端、IDE 和桌面中的开放宿主。 | AI Agents | 独立代理宿主 | |
| 更广义的本地 AI 代理，重点在工程自动化；虽然不只做编程，但和这一层共享相同宿主工作面。 | AI Agents | 独立代理宿主 | |
| 构建在 OpenCode 之上的 harness 增强层，重点把 ulw、规划到执行接力、后台任务和持久状态组织成宿主内工作流协议。 | Agent Harnesses | 宿主内扩展 | |
| 构建在 Codex 之上的 workflow layer：Codex 保留原生 substrate，OMX 再叠加 prompts、workflow skills、`.omx/` state 与可选 team runtime。 | Agent Harnesses | 宿主内扩展 | |
| 构建在 Claude Code 之上的以团队为先的编排层，强调多代理协作与调度。 | Agent Harnesses | 宿主内扩展，可拉起外部工作进程 | |
| 跨宿主的 harness 框架，试图把多平台编程环境统一到同一层控制面。 | Agent Harnesses | 宿主内扩展（跨宿主） | |
| 面向 agent harness 的增强系统，重点在性能优化与工作流加强。 | Agent Harnesses | 宿主内扩展（跨宿主） | |
| 以技能、检查清单和执行纪律定义工作方法，属于方法系统型 harness，而不是新的代理宿主。 | Agent Harnesses | 宿主内方法系统 | |
| 用元提示、上下文工程与规格驱动开发组织工作方法，属于方法系统型 harness。 | Agent Harnesses | 宿主内方法系统 | |
| 把 agile 开发过程、专门代理、workflow、技能和模块生态打包成可安装的方法系统，运行在 Claude Code、Cursor 等宿主里。 | Agent Harnesses | 宿主内方法系统（模块化） | |
| workspace-first 多代理协调平台，用看板、Specs、Review Guard、ACP agent lifecycle 和 traces 把 Codex、OpenCode、Claude Code 等外部 agents 组织进跨宿主交付闭环。 | Agent Harnesses | 独立协调平台（跨宿主） | |
| 面向交付的角色化工作流，用多角色分工来组织产品与工程推进。 | Agent Harnesses | 宿主内交付套件 | |
| 以 Claude、Codex、Gemini 为核心的多模型协作工作流。 | Agent Harnesses | 宿主内编排 | |
| 一个会反复运行直到 PRD 条目完成的自主代理回路，强调持续推进与任务闭环。 | Agent Harnesses | 独立调度外壳 |
研究专题
如果你想拆开 agent harness，最好进入可运行专题。
只有进入可运行专题，很多判断才会从抽象说法变成可检查的结构差异。当前专题主要聚焦 `AI Agents` 与 `Agent Harnesses` 之间的边界：宿主在哪里，外层 harness 接手了哪些控制面，用户又是通过什么接口参与流程。
宿主与 Harness 结构图 一个可运行的研究应用，重点比较 `AI Agents` 与 `Agent Harnesses` 之间的宿主工作面、控制中心、用户参与契约与恢复路径。
深入剖析 OMO 与 OMX 拆开 OpenCode 与 Codex 各自提供了哪些 harness 机制层能力，OMO（oh-my-openagent）与 OMX（oh-my-codex）如何利用并扩展这些能力，以及它们最终分别给用户定义了什么交互面。
社区讨论
如果想看这个概念在真实使用中怎么被消化，社区材料很重要。
围绕 Agent Harnesses 与 Harness Engineering 的社区讨论不是官方定义，却最能补足真实实践里的成本、失败模式、工具取舍与使用路径。
把这些材料和官方文章交叉着读，更容易看清哪些问题已经反复出现，哪些说法还停留在经验层。
想开一个 harness engineering 实践的长期帖子，大家一起分享实践经验
这是一条持续更新的实践帖，适合先看一遍社区怎样理解 Harness Engineering，再顺着里面提到的工具和经验继续深入。
最近 harness，自主进化很火，大家有什么经验和用法吗？
这是一组更偏经验交换的讨论，能帮助读者快速看到社区用户在实际使用里最关心的能力、成本和做法。
都在聊 AI-Native Engineering，分享几个 AI coding workflow
如果想把单个 harness 套件放回更大的 AI 编程流程背景里看，这帖能提供一张更宽的参照面。
Vibecoding 进阶教程总集篇——从能用到可控
即使不直接使用 harness 这个词，这帖讨论的“从能用到可控”也和 Harness Engineering 关心的问题高度重合。
OpenAI 提出 “Harness Engineering”：完全使用 Agent 进行编程的实践
这帖适合配合 OpenAI 原文一起看，重点不在转述本身，而在看社区最先抓住了这个概念的哪些部分。
Codex 增强版：对标 Claude Code 新增 Agent Teams、Hooks、anthropic api Agent 、WebUI
这帖能帮助读者理解：社区很早就在把代理宿主往钩子、团队协作和控制层方向扩展，这正是今天很多 harness 套件的演化路径。
新年来分享我的 oh-my-opencode 配置和学习心得
如果你想看 OpenCode 生态里的真实配置、使用路径和踩坑经验，这帖提供了很具体的第一手材料。
经过 8 个月 Claude Code 高强度实战，我们决定开源内部的最佳实践
这帖的价值在于把长期实践沉淀成更系统的做法，适合拿来辨认哪些已经从提示技巧演化成更稳定的开发方法和外层控制结构。
工程观察
把这些材料放在一起看，会慢慢浮现出一些更偏 Harness Engineering 的实践判断。
这些判断不负责给 `Agent Harnesses` 下定义，它们描述的是长期开发里反复出现的工程负载：控制、交接、恢复、审批和用户参与契约。
控制面往往比代码面更重
24 小时运行里，实际代码改动往往远小于设计、协调、进度记录和交接等控制面产出。这说明瓶颈常常不在补几行代码，而在如何组织长期执行。
长任务的关键是干净交接
上下文清洁、交接文档、计划文件与新会话续跑反复被强调。会话一旦退化成普通问答，整体效率会迅速下降。
单一控制层 + 文档接口
讨论中反复出现一个共识：决策层不应淹没在代码细节里，更有效的做法是用文档、摘要、报告和图表压缩信息后再交给高阶决策模型。
用户参与契约本身就是承重层
最近两条宿主链路研究都在提醒同一件事：差异不只在工具多少，更在用户通过什么接口触发流程、何时批准、何时续跑，以及恢复时要回到哪一层状态面。
模型供应现实会同时塑造 Agent Harnesses 与 Harness Engineering
很多 Agent Harnesses 设计和 Harness Engineering 做法都不是静态教条，而是在供应稳定性、可用性和成本约束下不断漂移。
下一步
如果首页已经让你对整体图景有了感觉，下一步就按问题深入。
这几条入口对应的是不同的问题：你是在问 `AI Agents` 和 `Agent Harnesses` 怎么分，在问命令、MCP、 钩子、技能、子代理这些机制怎样联动，还是在问这些能力怎样被组织成长期开发方法。 先把问题对准，再进入对应页面，阅读成本会低很多。
我想先看精确定义 先分清 `AI Agents`、`Agent Harnesses` 与 `Harness Engineering` 的边界。
我想先理解怎么选路线 如果你在比较宿主、Agent Harnesses 与方法系统，先看生态与比较。
我想看这个领域是怎么形成的 看对象层和实践线是怎样逐步分化、又彼此牵连的。
我想直接看可运行材料 如果你想拆开宿主和 `Agent Harnesses` 之间到底怎样分工，先看专题。