Hermes vs Harness：从“会思考”到“可控制”：AI Agent 的系统工程本质
许多团队开发的智能体（Agent）在演示场景中表现抢眼，然而一旦部署到真实生产环境，输出波动、上下文失控、执行风险难以约束等瓶颈便迅速暴露。这些困境经常被归因于模型能力不足或提示词设计欠佳，实则是对问题根源的误判——真正的瓶颈在于系统工程层面缺少一个闭环运行框架。
一、为什么你的 Agent 总停在 Demo：一个被误判的瓶颈
在过去一年里，从自动编程到故障排查再到发布方案生成，各类团队几乎都尝试过构建Agent系统。大多数项目在演示阶段效果出众，但进入真实环境后立刻暴露出诸多问题：输出一致性差、上下文难以掌控、执行风险无法有效约束、操作结果缺乏审计能力。许多人把原因归结为“模型不够强”或“提示词不够好”，这实际上偏离了问题的核心。
真正的瓶颈并不在于模型本身，而在于系统工程层面缺少一个能够承载“思考—执行—反馈—记忆”完整闭环的运行框架。在最新的工程语境中，这个框架被称为Harness。如果把Agent看作一个系统，模型仅仅是计算单元，而Harness才是将这些能力有机组织起来并与真实世界对接的操作系统与控制平面。
二、两个词的分工：Hermes（思考）与 Harness（控制）
将问题抽象到最底层，可以提炼出一个清晰的分工模型：
- Hermes：负责推理与决策。它以长期运行的Agent形态存在，具备记忆能力、技能沉淀能力和自我改进能力。
- Harness：负责约束与执行。它将不确定的“方案”转化为可验证、可回滚、可审计的“动作”。
这并非单纯的语义差异，而是两类系统之间的明确边界：Hermes解决“该做什么”的问题，Harness解决“如何安全地做并对结果负责”的问题。
从工程角度看，Hermes属于概率系统（基于统计学习进行推理），而Harness属于确定性系统（以规则、状态机和策略为核心）。任何试图单凭其中一侧完成闭环的方案，都会在生产环境中失败——前者缺乏可控性，后者缺乏足够的智能。
三、Agent 的真正公式：Model + Harness
将系统进一步形式化，可以得到一个更具实用价值的表达：
Agent = Model（LLM）+ Harness（系统能力）此处的Harness并非单一组件，而是一个由多种能力构成的系统集合：
- 状态与记忆（State & Memory）：文件系统、结构化存储、向量索引
- 执行环境（Execution）：Shell、容器、远程节点
- 工具与接口（Tools / APIs）：数据库、云服务、内部平台
- 上下文管理（Context）：裁剪、压缩、检索与装配
- 调度与编排（Orchestration）：计划、分解、重试、并行
- 策略与治理（Policy & Governance）：权限、审计、回滚
模型并不直接接触真实世界，它只能输出“意图”。Harness的作用，正是将这些“意图”映射为受约束的行动。
四、Hermes 的工程本质：一个长期运行的 Agent Runtime
许多早期的Agent框架停留在“单次调用”层面：输入问题，输出答案。Hermes的关键突破在于将Agent明确定义为一个长期运行的进程，并围绕“循环（loop）”来构建：
- 构建上下文（从记忆与状态中检索必要信息）
- 调用模型生成计划或下一步动作
- 执行工具或代码
- 评估结果并更新状态
- 决定继续、重试或终止
这个循环在概念上并不复杂，但其工程难点在于：如何确保每一轮迭代都可控、可恢复、可优化。这一问题引出了Hermes的两个核心子系统：Memory与Skills。
五、Memory 不是“向量库”：状态系统的三层设计
很多团队将“记忆”简化为向量检索，这种做法远远不够。Hermes采用的方式更接近一个多层状态系统：
- 持久状态（Persistent Memory）：相当于配置与知识基线（包括环境信息、账号约束、常用路径等），通常以文件或结构化存储形式存在。它并非被检索出来“参考”，而是每次都参与上下文构建的“前提条件”。
- 经验沉淀（Skills）：将成功路径或修复策略抽象为可复用单元（详见下一节）。这是连接“记忆”与“能力”的关键桥梁。
- 会话与历史（Session / History）：用于短期推理与回溯，通过全文索引或时间窗口进行选择性加载。
一个重要结论是：状态系统的设计直接决定Agent的稳定性——没有稳定的状态，就没有稳定的行为。
六、Skills：把经验变成“可执行能力单元”
Hermes的第二个关键机制是Skills。它并非简单的Prompt模板，而是包含目标、约束、工具链与步骤的能力单元。从工程角度看，一个Skill至少包含以下要素：
- 触发条件（何时适用）
- 输入输出约定
- 调用的工具与执行顺序
- 关键约束（例如只读、幂等、回滚策略）
- 失败处理路径
Skill的核心价值在于缩短推理路径并提升确定性。当一个问题命中已有Skill时，Agent无需从零开始规划，而是直接复用“经过验证的执行模式”。
更重要的是，Skill可以自动生成与迭代：当Agent多次在某类问题上形成稳定路径时，便可将其沉淀为Skill；当路径被证明不稳定时，可以进行替换或版本化管理。这使系统具备了“工程经验的累积能力”。
七、Execution Runtime：从“会想”到“会做”的跃迁
Agent一旦具备执行能力，就进入了真实世界：文件系统、网络、服务接口、集群资源。Execution Runtime的设计必须解决三个核心问题：
- 能力边界：允许做什么（读写、部署、重启）？禁止做什么？
- 环境隔离：在哪里执行（本地、容器、远程节点）？如何保证不污染宿主环境？
- 失败恢复：执行失败时如何回滚或补偿？
常见的实现方式包括：
- 以容器为最小执行单元（短生命周期、可重建）
- 通过受控的Shell/SDK调用（而非任意命令拼接）
- 对外部系统使用带限权的凭据（短期token、细粒度RBAC）
一个容易被忽视的事实是：执行能力越强，系统对安全和可控性的要求就越高。
八、Harness：把不确定的“方案”变成可控的“动作”
当Hermes生成了“该怎么做”的方案之后，系统还缺少关键的一步：将方案转化为受控执行。这正是Harness的职责所在。
在现代DevOps体系中，Harness体现在以下几个方面：
- Pipeline引擎：将步骤编排为可执行流程（包含依赖、并行、重试）
- 部署抽象：屏蔽基础设施差异（Kubernetes、VM、Serverless）
- 验证机制：基于指标与日志判断发布是否健康
- 回滚策略：在异常时自动或半自动恢复
- 治理与审计：权限控制、审批流、操作记录
关键在于：Harness不关心“为什么这么做”，它只关心“如何确保这件事被正确、可控地完成”。
九、Verification：发布的本质是“验证”，不是“完成”
传统流水线把“部署成功”当作结束条件，这种做法并不充分。Harness的一个重要进化在于引入了自动验证（Verification）机制：
- 采集关键指标（错误率、延迟、资源占用）
- 与基线或对照组进行比较（如金丝雀发布）
- 通过统计方法判断是否出现异常
- 在异常时触发回滚或暂停
这一步的意义在于将“结果判断”从人转移到系统，并形成完整的闭环：
执行 → 观测 → 判断 → 决策（继续/回滚）当与Agent结合时，这个闭环可以进一步增强：Agent负责解释异常并提出修复策略，Harness负责安全地执行与验证。
十、把两者合并：AI 控制系统的三层架构
将Hermes与Harness统一起来，可以构建一个清晰的三层模型：
- 决策层（Decision）：Hermes负责理解问题、生成方案、选择策略与技能。
- 控制层（Control）：Harness（广义）负责策略约束、权限管理、审计跟踪，将方案转化为可执行流程。
- 执行层（Execution）：基础设施与部署系统负责实际的变更操作（发布、扩缩容、配置更新）。
这三层之间的接口设计至关重要：
- 决策层输出的必须是结构化计划（而非自由文本）
- 控制层需要将计划编译为可执行的流水线
- 执行层需要提供可观测信号回馈到上层
十一、从 DevOps 到 AI Native DevOps：控制权的迁移
传统模式是“人直接驱动流水线”。在AI介入之后，控制权发生了转移：
Human → Agent（Hermes）→ Harness → System这种变化带来了两点重要影响：
- 人不再直接操作系统，而是转向审阅与干预决策
- 系统需要对AI的行为负责（审计、回滚、解释）
因此，企业落地的关键不在于“让AI更聪明”，而在于“让AI的行为可控且可追责”。
十二、实现细节：如何把“方案”编译为 Pipeline
一个可落地的路径是将Agent输出限定为中间表示（IR），再由控制层编译为具体的流水线。例如：
Agent输出：
- 目标：修复服务A的错误率上升
- 步骤：1. 回滚到版本v1.2.3 2. 启用金丝雀发布新补丁 3. 观察10分钟指标
- 约束：仅影响10%流量，失败自动回滚
控制层处理：
- 校验权限与风险等级
- 生成对应的Pipeline（包含部署、分流、验证、回滚节点）
- 注入审计与日志
这种“IR → Pipeline”的编译过程，是连接Hermes与Harness的关键技术点。
十三、策略与治理：为什么必须有 Policy Engine
当AI具备执行能力后，治理就不再是可选项。Policy Engine的职责包括：
- 权限控制：定义不同环境、资源、操作的访问边界
- 风险分级：高风险操作必须经过人工审批或双重验证
- 合规约束：如变更窗口、冻结期、审计要求
- 行为限制：禁止某些命令或跨越特定边界
策略不应写死在代码中，而应以可配置规则的形式存在，并在执行前与执行过程中生效。这也是将系统从“工具”提升为“平台”的关键所在。
十四、上下文管理：为什么 Agent 会“越跑越差”
长周期任务中常见的问题是上下文膨胀与“语义漂移”。有效的应对措施包括：
- 分层上下文：区分长期状态、技能、当前任务
- 摘要与压缩：定期对历史进行结构化总结
- 按需加载：仅加载与当前步骤相关的信息
- 技能替代：用Skill代替重复的长Prompt
本质上，这是在构建一个“运行时内存管理系统”，避免无序增长导致推理质量下降。
十五、安全边界：从 Prompt 安全转向 Runtime 安全
一旦Agent能够执行命令，安全问题的重心就从“防注入”转向“防越权执行”。可行的工程手段包括：
- 最小权限原则：为不同任务颁发最小化的短期凭据
- 沙箱执行：所有操作在隔离环境中进行
- 命令白名单/黑名单：限制可执行的范围
- 网络隔离：控制外部访问能力
- 操作审计：每一步操作都有可追溯的记录
安全不是通过更复杂的Prompt来解决，而是通过系统边界与策略来实现。
十六、失败与回滚：把“错误”纳入设计
在AI参与决策的系统中，错误是常态。关键在于如何设计应对机制：
- 设计幂等操作：多次执行不会产生副作用
- 提供回滚路径：每个关键步骤都可恢复
- 分阶段执行：小步快跑，降低单次风险
- 自动与人工结合：低风险自动处理，高风险需要审批
Harness的价值，在于将这些机制标准化，使错误不会演化为事故。
十七、一个可落地的整体方案（面向 ITSM / DevOps）
结合以上所有要素，可以构建一个实际的系统架构：
- 输入层：告警、工单、监控事件
- 决策层（Hermes）：分析根因，生成结构化修复计划
- 控制层（Policy + Compiler）：校验风险，编译为Pipeline
- 执行层（CD / Infra）：执行部署、配置、扩缩容
- 验证层（Observability）：判断效果，触发回滚或继续
- 沉淀层（Memory / Skills）：记录经验，优化后续行为
关键不在于某一个组件，而在于整个闭环是否完整且可控。
十八、一个重要判断：竞争焦点正在从模型转向系统
过去的竞争集中在模型规模与效果上；现在的竞争正在发生转移，新的焦点包括：
- 谁能构建更稳定的Harness
- 谁能把经验沉淀为Skills
- 谁能在安全与效率之间取得最佳平衡
换句话说：系统工程的深度正在成为核心竞争力。
十九、回到标题：Hermes 与 Harness 的真正关系
现在可以给出一个更精确的结论：
- Hermes让系统具备“思考与学习”的能力
- Harness让系统具备“控制与执行”的能力
两者并非替代关系，而是相互依赖的两极。缺少任何一方，都无法形成可落地的生产系统。
二十、结语：从“聪明”到“可靠”的跃迁
当讨论Agent时，人们容易被“智能”所吸引，但真正决定系统成败的是“可靠性”。Hermes解决的是“会不会想”的问题，Harness解决的是“能不能安全地做并对结果负责”的问题。
从Demo迈向生产环境时，最值得投入的方向并非更换模型，而是精心设计Harness体系——定义状态、约束执行、构建验证与回滚机制、持续沉淀经验。唯有如此，Agent才能从惊艳的演示转化为长期稳定的生产力。