工程观察
这些观察不是官方定义，而是从 关键文章 与 社区讨论 中反复浮现的稳定工程信号。它们更接近研究解释，而不是可以直接当作事实陈述的结论。
这里主要关注的是 Harness Engineering 这条实践线：人如何组织长期开发、交接、控制与评审。它们当然会反过来影响 Agent Harnesses 的设计，但不承担对象层分类的工作。
先用什么角度读这些观察
Section titled “先用什么角度读这些观察”- 这些观察来自多份材料里反复出现的相似问题，而不是单一厂商或单一帖子。
- 它们不是为了证明某个做法唯一正确，而是帮助读者辨认哪些问题一旦进入长时代理工作流，就几乎一定会冒出来。
- 与 概念入口 对照着看，更容易看清哪些层在真实实践里最先变重。
控制面往往比代码面更重
Section titled “控制面往往比代码面更重”一个反复出现的信号是：在长任务里，真正占据系统复杂度的往往不是代码改了多少，而是如何规划、交接、记录、审查和恢复。很多时间花在让代理持续处于“知道自己在干什么、下一步该干什么”的状态上。
为什么这是稳定信号
Section titled “为什么这是稳定信号”Anthropic 的长任务文章把进度工件、干净交接和上下文重置提到核心位置；OpenAI 的 harness 文章则把可读性、防护栏和合并纪律视为工程对象。这些都说明：一旦任务跨过单轮会话，控制面就不再是附属品。
这会改变什么
Section titled “这会改变什么”- 比较
Agent Harnesses时，不能只比较“会不会改代码”，还要比较谁在控制下一步 - 评估一条
Harness Engineering路线时，应该重点看记录、审批、恢复和可读性，而不是只看模型能力 - 因而，宿主、记忆、审批和交接不应被看成产品外围细节
短任务、一次性脚本或高约束自动化流里，控制面未必会显著重于代码面。这个观察最适用于持续多轮推进、需要验证和交接的工程任务。
长任务的关键是干净交接
Section titled “长任务的关键是干净交接”多份材料都在强调：如果任务要跨会话、跨上下文窗口甚至跨代理继续，干净交接就会从“好习惯”变成基础设施要求。没有交接结构，系统很快会退化回普通问答。
为什么这是稳定信号
Section titled “为什么这是稳定信号”Anthropic 把干净交接说成长期代理成败关键；社区实践里则不断回到“计划文件”“进度摘要”“续跑文档”这些具体工件。这两边实际上在说同一件事：恢复能力不是回放历史，而是压缩出可继续工作的状态。
这会改变什么
Section titled “这会改变什么”- 好的
Harness Engineering实践，不只是任务能暂停和继续，而是要求Agent Harnesses在继续时减少重新理解成本 - 记忆的价值不在存更多，而在把下轮真正需要的控制信息留下来
- 像 宿主与 Harness 结构图 这样的专题，能帮助读者看到恢复路径是回到哪里，而不只是回到“再试一次”
并不是所有系统都需要重交接设计。高度同步、短链路、单控制器任务里，简单回溯历史也可能够用。问题一旦变成长任务或多人协同，交接的权重就会迅速上升。
单一控制层 + 文档接口
Section titled “单一控制层 + 文档接口”社区实践里反复出现一个工程直觉：高阶决策层不应该直接淹没在原始代码噪声里，更有效的做法是保留一个干净的控制层，再通过文档、摘要、计划、图表和报告去压缩信息。
为什么这是稳定信号
Section titled “为什么这是稳定信号”OpenAI 的 harness 表达里一直强调“人类掌舵，代理执行”；很多社区工作流也把文档当作不同代理或不同层级模型之间的接口。文档不只是给人看的，它还是控制层之间交换状态的接口。
这会改变什么
Section titled “这会改变什么”- 研究
Harness Engineering时，文档系统应该被看成运行机制的一部分，而不是附属产物 - 这也解释了为什么技能系统、规格驱动系统、评审纪律常常会与 harness 套件黏在一起出现
- 这也说明相关材料不该只展示结果，也应该展示“中间工件如何承担控制作用”
这不是在说“所有任务都应该文档化到极致”。问题的关键不是文档数量，而是有没有一种可复用、可压缩、可交接的信息表面。
用户参与契约本身就是承重层
Section titled “用户参与契约本身就是承重层”最近两条宿主链路研究还给出了一个很稳的信号：比较 Agent Harnesses 时，不能只问“它有哪些能力”，还要问“用户在什么时候被拉进来”。很多系统表面上都同时拥有工具、技能、子代理、记忆和状态，但真正决定使用体验与长任务成本的，往往是 用户参与契约。
这里说的 用户参与契约，不是菜单或 UI 设计，而是：
- 用户通常通过什么接口触发工作协议
- 一开始必须提供什么信息
- 哪些时机会进入批准、回问、续跑或停止节点
- 任务恢复时，用户要回到 thread、plan、state shell，还是 team runtime
为什么这是稳定信号
Section titled “为什么这是稳定信号”OpenCode -> oh-my-openagent 和 Codex -> oh-my-codex 这两条链都说明：宿主原生能力已经很厚，但外层系统真正拉开差距的地方，常常不是“多几个功能”，而是怎样重排用户的进入时机、决策节点和恢复接口。
这会改变什么
Section titled “这会改变什么”- 比较宿主与 harness 时，应该把
触发接口 / 输入接口 / 授权接口 / 续跑接口当成单独的判断轴 - 设计
Harness Engineering方法时，最好把“用户何时介入”当成一等工程对象，而不是默认让用户自己一路猜 - 这也解释了为什么很多看起来只是 prompt、skills、hooks 的差异，最终会变成完全不同的工作流体验
不是所有系统都需要把参与契约做得很厚。短任务、强约束自动化流和单控制器工作里，这层差异可能不明显。问题一旦进入长任务、交接或多角色协作，这一层通常就会迅速变重。
模型供应现实会同时塑造 Agent Harnesses 与 Harness Engineering
Section titled “模型供应现实会同时塑造 Agent Harnesses 与 Harness Engineering”很多 Agent Harnesses 设计与 Harness Engineering 实践并不是固定教条，而是在模型能力、供应稳定性、成本、上下文窗口和工具可用性变化下不断漂移。模型升级会让一部分脚手架失去必要性，也会暴露新的瓶颈。
为什么这是稳定信号
Section titled “为什么这是稳定信号”官方文章和社区经验都在不断调整关注点：一段时间大家强调提示纪律，之后重心移到工具，再后来变成记忆、交接、审批和协议。问题不是“以前谁错了”，而是瓶颈位置真的在移动。
这会改变什么
Section titled “这会改变什么”- 相关页面里的分类和图谱必须允许漂移，不能把今天的实现形态写成永久定论
- 页面里需要明确标注哪些是
事实陈述，哪些是当前阶段的研究解释 - 这也说明比起纯列表，更需要能把“为什么现在这样分”解释清楚的专题材料
供应现实会影响 harness，但不会自动决定一切。好的设计仍然要能区分：什么是临时适配，什么是长期有效的工程对象。