有一阵我以为自己已经懂了 harness，也大概知道 Hermes。两个词分开看，都像能说上几句。后来它们经常被放进同一句话里，我反而说不清彼此是什么关系。那种感觉很具体：不是完全陌生，是半懂半不懂，最容易把自己绕进去。

后来我才把问题说清楚。我当时把它们当成同一层级的两个名词，好像在比较两个相近概念，或者两个竞品。真正卡住的地方在于，它们根本不是一类东西。

一个是做法，一个是产品

Harness 说的是模型外面那一层运行环境。工具能调什么，上下文怎么拼，权限卡在哪里，怎样算做完，失败了怎么恢复，跨步骤要不要留状态。把这些合在一起，模型才从“会回答”变成“能办事”。围绕这层环境去设计和改造，就是常说的 harness engineering。

Hermes 则是一个具体产品。Nous Research 做的开源智能体，强调可自托管、跨会话记忆、把成功做法沉淀成可复用 skill，也能挂到消息应用里长期跑。它内部当然有一套 harness，但它本身不是 harness 这个词的意思。

一个方便的对照是：harness 像“操作系统该负责什么”这种角色描述；Hermes 像某一款已经装好的发行版。你可以说 Hermes 的环境层做得全，也可以讨论要不要给它再套企业治理。你不该把“要不要做 harness”和“要不要上 Hermes”问成同一个选择题。

Cursor 这类编程助手也是一种 harness 实现。它提供工具、拼上下文、执行命令、把结果喂回模型。会话里老犯同一类错时，更有效的改法常常是加规则、补文档、收紧权限、加验收，而不是只在聊天里纠正一次。错一次，就把环境改到更难再犯，这才是 harness 思维落到手上的样子。

记忆偏好不等于 harness

做智能体应用时，我很快碰到另一层疑惑。市场上很多产品都要求有记忆、能保存用户偏好、结果能迭代，最好越用越好用。这些诉求听起来和 harness 很近，我一度怀疑它们是不是一回事。

它们高度相关，却不是同义词。

记忆、偏好、持续变好，是产品能力诉求。Harness 是承载这些诉求的系统设计层，同时还要管工具、编排、校验、权限、审计。可以说，没有像样的 harness，这些能力很难做得稳；但不能说有了记忆表，就等于做完了 harness。

记忆最好再拆开看。会话状态管这一轮做到哪；用户偏好管语气、格式、默认选项和忌讳；长期知识或技能管项目事实和可复用流程。混成一个“memory 字段每次全塞进 prompt”，通常只是雏形。真正难的是谁写、谁读、何时召回、错记怎么废掉、敏感信息怎么隔离。这些才是 harness 问题。

“越用越好用”更容易说糊。至少有几档：

同一次任务里根据反馈改到满意，这是会话内迭代。

跨会话记住偏好和成功样本，下次起点更高，这是个性化。

把成功流程沉淀成 skill 或策略，系统越用越会办事，这是学习环。

再用数据去改模型权重，这是训练，通常已经离开 harness 主线。

很多人嘴里说越用越好，心里要的是中间两档。Harness 主要负责把中间两档做成可治理的机制。Hermes 一类产品会把学习环做得更显眼，所以讨论时更容易和 harness 黏在一起。黏得紧，不代表两个词可以互换。

只接大模型 API 为什么不够

如果产品只做“请求进去、文本出来”，用户要的却常常是理解我是谁、调用工具办事、对照结果自检、记住这次教训。中间缺的不是更长的提示词，而是运行时。

一个比较稳妥的分层是：

产品层定义任务、交互和价值主张。

编排层负责多步推进、重试和人机协作点。

能力层接工具、内部 API、检索或其他执行面。

认知状态层管会话状态、偏好、长期记忆和模板技能。

模型层保持可替换，最好不要把业务逻辑焊死在某一家 API 上。

再加两条横切能力：治理和评测。没有权限、审计和成本控制，很多能力不敢放开；没有评测，你分不清变差是因为模型，还是因为环境设计。

按这个看法，规范一点的智能体应用接近“业务产品加 harness”，而不是“业务页面加大模型接口”。

什么样的产品形态更合理

市场空间大，不等于一上来就该做全能常驻助手。更稳的切入往往是窄而深的任务闭环：高频、有明确对错、能接入真实系统。用户买的是少动手、少返工、可信任的结果。

常见且相对合理的形态大概有三类。

一类是任务型 Copilot，嵌在已有工作流里，有完成定义，关键步骤可确认，能记住项目规范和个人偏好。

一类是受控工作流 Agent，由事件或日程触发，多步调用加校验门，失败可重试或告警，全过程可审计。这类最能体现 harness。

一类是常驻助手，跨会话记忆、多入口、技能沉淀，越用越好还有可解释路径。差异化强，也更难做、更难控。多数团队更适合先把前两类做透，给第三类留接口，而不是第一天就对标完整学习环。

我自己后来用来打分的标准也很具体。有没有主任务闭环；成功标准能不能检验；有没有工具面和失败恢复；编排是不是带状态的循环；记忆是否分层且可编辑可遗忘；用户纠正会不会改变下次行为；权限和成本能不能看见；改环境和换模型之后有没有办法对比。满足大半条，才像按现代 harness 理念设计过的产品。只有聊天框和 API，仍然偏演示封装。

有几条原则我现在会优先坚持。先定结果契约，再让模型在框内发挥。上下文靠装配和检索，不靠无限倾倒历史。高风险动作默认人机协同。把“变好”做成用户能看见、能关闭、能修改的机制，而不是黑盒自称在学习。垂直数据和工作流的深集成，通常比单纯追更聪明的模型更难抄。

收束成一句口径

脑是模型，身与缰是 harness，节奏是 loop，Hermes 或 Cursor 是市场上的整机实现。记忆和偏好是 harness 里的关键模块，越用越好是产品目标，常常靠 harness 落地，却不等于 harness 这个词本身。

我现在不太会再问“harness 和 Hermes 到底谁更重要”。更有用的问法是：这句话在谈抽象层，还是在谈具体产品？我们缺的是环境设计，还是缺一个现成的常驻助手？用户要的“变好”，究竟是偏好记住了，还是流程沉淀了，还是模型权重更新了？

问法一变，设计就不会那么容易糊成一团。