摘要
当前AI Agent框架百花齐放，但多数争论都集中在模型本身。本文作者通过深度源码分析，揭示了真正的分水岭在于 "Harness"------连接模型与世界的"骨架" 。本文对比了openclaw、deer-flow、hermes-agent和OpenHarness四种截然不同的设计哲学，从核心引擎、工具系统到安全管理六大模块，全面解构了它们在灵活性、严谨性和扩展性上的根本取舍。文章最终指出，所有项目的共性瓶颈指向同一结论：Agent框架的下一个突破点不在于更强的模型，而在于更结构化的Workflow与Workbench层。
核心速览：四种"骨架"的画像
在深入代码之前，我们先为这四个项目分别"画一张像"，建立一个直观的第一印象：
openclaw：一个"万能路由器"
一句话：它的使命是连接一切。无论你从微信、Slack还是API来，无论你要调搜索引擎、数据库还是发邮件，它只负责将消息和工具天衣无缝地"接通"。
- GitHub: github.com/openclaw/op...
deer-flow：一位"严谨的研究员"一句话：它不追求全能，只追求在研究流程上做到极致。每一步都可规划、可执行、可回溯，像一份严谨的实验记录。
- GitHub: github.com/geekan/Meta...（deer-flow 为 Metagpt 生态项目之一）
hermes-agent：一个"自我进化的发明家"一句话：它不仅能用工具，还能在运行中发现不足，自己创造新的工具和技能，像一块会自我迭代的乐高积木。
- GitHub: github.com/NousResearc...
OpenHarness：一套"工业级裸机骨架"一句话：它不做任何具体应用，只提供最严谨、最灵活的基础设施。你不是用它，而是基于它"组装"出一个专属Agent，就像用精密零件搭建一台机器。
- GitHub: github.com/PrefectHQ/o...
这四种哲学不是对同一问题给出的不同答案，而是对四个全然不同的问题的回答。理解了它们"为何而生"，就能理解其后所有的架构取舍。
引言：当模型不再是唯一壁垒
Agent 工程化的核心命题，正从"模型有多聪明"转向 "如何将模型武装成能干的智能体" 。而这个"武装"过程所需的全部基础设施------指令解析、工具调用、记忆存取、安全护栏------我们称之为 Harness（骨架/线束）。
Harness------包裹模型、使其成为功能性 Agent 所需的全部基础设施------是 Agent 工程化的核心命题。当前开源生态中，openclaw [1]、deer-flow [2]、hermes-agent [3]、OpenHarness [4] 四个项目各自展示了 Harness 关键设计决策的不同实现方式。本文基于源码分析，从设计哲学、通用能力模块、架构取舍三个维度展开深度对比，揭示 Harness 工程的设计空间与共性瓶颈。
一、六大模块深度对比：架构取舍的具象化
Harness 工程有六个通用能力模块：QueryEngine（核心引擎）、Tool System（工具系统）、Permission System（权限系统）、Context Management（上下文管理）、Memory（记忆系统）、Extensibility（扩展系统）。下面逐一对比四个项目在每个模块上的实现差异。
1.1 QueryEngine（核心引擎）：循环里的"控制论"
QueryEngine 是 Harness 的心脏------它决定了模型如何推理、何时调用工具、如何处理结果、何时停止。四个项目在这一模块上的差异最大。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 实现方式 | 自研 Orchestrator（进程级 Agent 管理） | LangGraph StateGraph（图驱动状态机） | 自研 while-loop（AIAgent.chat() → while tool_calls → loop） |
自研 QueryEngine（712 行 run_query()，管线治理型） |
| 核心循环 | Gateway → Agent Orchestrator → Model/Plugin → Tools | ChannelManager → LangGraph Server → StateGraph Nodes → Checkpoint | handle_function_call() → registry.dispatch() → tool.execute() → loop |
run_query() → API Client → LLM → tool_use → Permission + Hook → execute → loop |
| 分支/并行 | ACP Spawn 启动外部 Agent，支持并行子任务 | StateGraph 的条件边（add_conditional_edges）天然支持 |
无内建分支，靠 LLM 自由决定 | 无内建分支，靠 LLM 自由决定 |
| 状态持久化 | Session Store（文件系统） | LangGraph Checkpoint（SQLite/内存） | 无内建持久化 | 会话存储 + tool_metadata 字典 |
| 停止条件 | Agent 自主决定 + 外部控制 | StateGraph 终止节点 + max_turns | max_turns + stop_reason | max_turns + auto_compact 触发 |
设计取舍：
- deer-flow 的 StateGraph 优势在于结构化------研究流天然是"搜索→阅读→提取→综合"的 DAG，用 StateGraph 表达比自研 while-loop 更自然，且每一步状态可回溯。代价是强依赖 LangGraph，
deerflow-harness包无法脱离 LangGraph 运行。LangGraph 是由 LangChain 团队开发的用于构建有状态、多角色 Agent 应用的框架 [5]。 - hermes-agent 的 while-loop 优势在于极简------
while tool_calls循环不到 20 行核心逻辑，没有框架依赖。代价是无分支/并行能力，完全依赖 LLM 的推理来决定下一步。 - OpenHarness 的 QueryEngine 优势在于管线治理------每轮循环集成了压缩检查、权限检查、Hook 执行、Carry-over 记录，是四个项目中最严谨的 Agent Loop。代价是组装复杂------13 个构造器参数需要手动注入。
- openclaw 的 Orchestrator 优势在于进程级管理------Agent 生命周期、子 Agent 派生、Session 恢复都是进程级操作。代价是架构最重------Gateway + Channel + Plugin + Session 四层协同。
1.2 Tool System（工具系统）：能力边界与加载艺术
工具系统决定了 Agent 的能力边界------有哪些工具可用、如何注册发现、如何按需加载。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 工具数量 | 40+ Skills（Plugin 提供） | 4 层来源（Built-in/Configured/MCP/Community） | 50+ 自注册 | 43+ 内置 + MCP 适配 |
| 注册方式 | Plugin SDK 清单驱动：openclaw.plugin.json + compat.pluginApi 版本兼容 |
Config YAML + LangGraph Agent 配置 | registry.register() 模块级自动注册：零配置 |
BaseTool 抽象类 + ToolRegistry：Pydantic 强类型 |
| 按需加载 | Plugin 按需加载，加载后工具全量注册 | tool_search 延迟加载 |
toolsets 分组（静态） | Skills Markdown 按需加载，工具全量注册 |
| Schema 校验 | 编译期校验（Plugin SDK 边界契约） | 无 | 无编译期校验（运行时警告冲突） | Pydantic model_json_schema() 自动生成 |
| 特色能力 | 200+ subpath exports 边界契约 | Community Tools 社区贡献 | skill_manage 自进化 + RL Training |
tool_search 工具搜索 + MCP 适配 |
设计取舍：
- openclaw 最严谨但扩展成本最高------写一个新 Plugin 需要理解 SDK 的 200+ 个导出点和版本兼容规则。
- hermes-agent 最灵活但无编译期校验------写一个
.py文件加一行registry.register()就完事，但工具名冲突只在运行时警告。 - OpenHarness 中间路线------
BaseTool要求 Pydantic 类型定义，兼顾了类型安全和开发便利。Pydantic 是 Python 生态中广泛使用的数据校验库，通过类型注解提供运行时和静态类型检查 [6]。 - deer-flow 最实用------4 层来源覆盖最广，但发现逻辑复杂。
1.3 Permission System（权限系统）：安全底线的四种偏重
权限系统决定了 Agent 的安全边界------哪些操作允许、哪些需要审批、哪些被拒绝。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 权限模型 | DM Policy 三模式（Pairing/Open/Gated） | Guardrails OAP Policy + Allowlist | Security/Redact 敏感信息脱敏 | 三级模式（DEFAULT/PLAN/FULL_AUTO）+ 敏感路径硬编码 |
| 粒度 | 设备级配对 + 操作级策略 | 工具级 Allowlist | 参数级脱敏 | 工具级 + 路径级（glob 规则）+ 命令级拒绝 |
| 敏感路径 | SSRF 防护 + 速率限制 | 无硬编码 | CredPool 凭证轮换 | */.ssh/*、*/.aws/credentials 等 9 个硬编码模式 |
| 动态切换 | 配对认证流程 | Guardrails 作为 Middleware | 无 | 三级模式可运行时切换 |
| 偏重方向 | 安全导向（配对认证） | 合规导向（Guardrails） | 隐私导向（脱敏） | 灵活导向（三级可切换） |
源码细节（OpenHarness）：
```python
OpenHarness 的三种权限模式
if self._settings.mode == PermissionMode.FULL_AUTO: return PermissionDecision(allowed=True) # 全自动：允许一切 if is_read_only: return PermissionDecision(allowed=True) # 只读工具：始终允许 if self._settings.mode == PermissionMode.PLAN: return PermissionDecision(allowed=False) # Plan 模式：阻止变更 return PermissionDecision(allowed=False, requires_confirmation=True) # Default：需确认 ```
设计取舍 ：所有框架都面临"安全与便捷的冲突"，但没有一个找到完美解。openclaw 偏安全（配对认证），OpenHarness 偏灵活（三级可切换），deer-flow 偏合规（Guardrails），hermes-agent 偏隐私（脱敏）。安全治理是与业务强耦合的，不存在通用解。
1.4 Context Management（上下文管理）：抵抗遗忘的艺术
上下文管理决定了 Agent 的智能上限------如何利用有限的上下文窗口，如何在不丢失关键信息的前提下压缩。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 压缩策略 | Compact 命令（手动触发） | Summarization Middleware（可插拔） | Context Compressor（核心子模块，32KB） | Microcompact（低成本）→ LLM 摘要（高成本）→ Carry-over 保护 |
| 压缩触发 | 用户手动 | Middleware 链自动 | Agent Loop 内建自动 | 每轮开始前检查 token 阈值自动 |
| 分级策略 | 无 | 无 | 无 | 有：先 microcompact（清除旧工具结果），不够再 LLM 摘要 |
| 关键状态保护 | 无 | 无 | 无 | Carry-over 机制：_record_tool_carryover() 把关键信息写入 tool_metadata，压缩时不丢失 |
| 记忆注入 | Active Memory Plugin 自动注入 | 记忆 Middleware 注入 | Memory Manager 注入 | 无自动注入 |
源码细节（OpenHarness 的 Carry-over 机制）：
```python def _record_tool_carryover(context, *, tool_name, tool_input, tool_output, ...): if tool_name == "read_file": _remember_read_file(context.tool_metadata, path=..., output=...) elif tool_name == "skill": _remember_skill_invocation(context.tool_metadata, skill_name=...) elif tool_name in {"agent", "send_message"}: _remember_async_agent_activity(context.tool_metadata, ...) ```
每次工具调用后，关键信息被写入 tool_metadata 字典------这个字典在压缩时被保护（不随旧消息一起被清除），确保 Agent 压缩后仍然"记得"自己读过的文件、调过的 skill、派过的子 agent。
设计取舍：
- OpenHarness 的分级压缩最精细------先用低成本方式，不够再用高成本方式，且 Carry-over 保护关键状态不丢失。
- deer-flow 的 Confidence 评分门控（记忆质量 ≥0.7 才持久化）确保只有高质量记忆被存储。
- hermes-agent 的 Context Compressor 作为 Agent 核心子模块，与 Agent Loop 耦合。
- openclaw 的手动触发最简单，但依赖用户判断。
1.5 Memory（记忆系统）：经验如何积累
记忆系统决定了 Agent 能否积累经验------短期记忆保持对话连贯，长期记忆实现跨会话学习。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 架构 | 3 个 Plugin 组合：memory-core + memory-lancedb + active-memory | LLM 提取事实 → 防抖队列(30s) → Confidence 评分(≥0.7) → Prompt 注入 | 跨会话 Memory Manager + MEMORY.md 文件 | Markdown 持久 + 会话存储 |
| 记忆后端 | LanceDB（向量检索）+ QMD（本地搜索）+ Wiki（知识库） | JSON 文件 | MEMORY.md 文本文件 | 文件系统 |
| 检索方式 | memory_search（语义搜索）+ memory_recall（向量召回）+ memory_get（精确获取） |
Confidence 评分过滤 + Prompt 注入 | 文件读写 | 无专用检索 |
| 存储范围 | 用户级 + 项目级 + 本地级（MEMORY_SCOPES = ("user", "project", "local")） |
会话级 | 跨会话 | 会话级 |
| 自进化 | 无 | 无 | skill_manage：LLM 自主创建/修改/删除 Skill |
无 |
关键洞察 ：openclaw 不是"记忆薄弱"，而是记忆是 Plugin ------这是"一切皆 Plugin"哲学的延伸。active-memory 插件在每次回复前启动一个阻塞式子 Agent，检索相关记忆并注入到 Prompt 中。后端可以是 QMD（本地搜索）或 LanceDB（向量搜索），由 searchMode 配置决定。LanceDB 是一个开源的、面向 AI 应用的向量数据库，支持嵌入式运行和云原生部署 [7]。这比 hermes-agent 的 MEMORY.md 文件更灵活，但配置也更复杂。
openclaw 的记忆配置项 （active-memory Plugin）：
``` searchMode: "search" | "vsearch" | "query" # 搜索模式 promptStyle: "balanced" | "strict" | "contextual" | "recall-heavy" | "precision-heavy" | "preference-only" # 检索策略 queryMode: "message" | "recent" | "full" # 查询范围 allowedChatTypes: "direct" | "group" | "channel" | "explicit" # 生效的会话类型 circuitBreakerMaxTimeouts: 1-20 # 熔断器阈值 ```
1.6 Extensibility（扩展系统）：生命力的源泉
扩展系统决定了 Harness 的生命力------能否接入新能力、能否定制行为、能否适配新场景。
| 维度 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| 扩展单元 | Plugin（独立包，含 openclaw.plugin.json 清单） |
LangGraph Agent（YAML/代码定义） | .py 文件（模块级 registry.register()） |
BaseTool 子类 + AgentDefinition YAML/Markdown + Hook 注册 |
| 扩展契约 | Plugin SDK（200+ subpath exports + 版本兼容声明） | LangGraph 协议 | 无（零配置） | Pydantic 类型 + ABC 抽象类 |
| 生命周期钩子 | Plugin Hooks（before_prompt_build 等） |
Middleware Chain（9 层） | 无 | HookExecutor（PreToolUse/PostToolUse/PreCompact/SessionStart/SessionEnd 等） |
| 多 Agent 定义 | SubAgent（orchestrator/leaf 角色，Session 级管理） | Sub-Agent Executor（线程池） | Delegate Tool（上下文隔离，最大深度 2） | AgentDefinition（7 种内置 + 用户自定义 + 插件扩展，三层优先级） |
| 多 Agent 后端 | ACP Spawn（进程隔离） | 线程池 | 同进程 | BackendRegistry（subprocess/tmux/in_process 三后端） |
| MCP 支持 | Plugin 层 MCP 适配 | LangChain MCP Adapters | mcp_tool.py（动态发现 + 注册） |
McpClientManager + McpToolAdapter |
MCP（Model Context Protocol）是 Anthropic 于2024年发布的开源协议，旨在为 AI 模型提供与外部工具和数据源交互的标准化接口，已成为 Agent 工具集成的行业趋势 [8]。
源码细节（OpenHarness 的三层 Agent 扩展）：
```python
OpenHarness 的 Agent 定义系统：三层优先级
def get_all_agent_definitions() -> list[AgentDefinition]: agent_map: dict[str, AgentDefinition] = {} # 1. Built-ins（最低优先级） for agent in get_builtin_agent_definitions(): agent_map[agent.name] = agent # 2. User-defined agents（~/.openharness/agents/） for agent in load_agents_dir(_get_user_agents_dir()): agent_map[agent.name] = agent # 3. Plugin agents（最高优先级） for plugin in load_plugins(settings, cwd): for agent_def in getattr(plugin, "agents", []): agent_map[agent_def.name] = agent_def return list(agent_map.values()) ```
源码细节（openclaw 的子 Agent 系统）：
```typescript // openclaw 的子 Agent 角色：orchestrator（可再派生）和 leaf（叶子节点） function normalizeSubagentRole(raw: string): "orchestrator" | "leaf" | undefined { const normalized = normalizeOptionalLowercaseString(raw); if (normalized === "orchestrator" || normalized === "leaf") return normalized; return undefined; }
// 4 种任务运行时，subagent 是一等公民 type TaskRuntime = "subagent" | "acp" | "cli" | "cron"; ```
关键洞察：
- openclaw 的子 Agent 系统比 hermes-agent 更复杂 ------subagent 有 orchestrator/leaf 两种角色，4 种 TaskRuntime，Session 级生命周期管理。只是它通过 Plugin + Session 体系组织，不像 hermes-agent 通过一个
delegate_tool.py文件那样直观。 - OpenHarness 的扩展不是"薄弱"而是"结构化" ------你不能像 hermes-agent 那样写一个
.py文件就完事，你需要遵循BaseTool/AgentDefinition/HookExecutor的接口契约。这种结构化扩展在多 Agent 协作、权限治理、可审计性上更有优势。 - hermes-agent 的扩展是最灵活的------零配置注册、运行时动态组合、提示词驱动的自进化。但灵活的代价是无编译期保障。
二、六大模块综合对比矩阵
| 模块 | openclaw | deer-flow | hermes-agent | OpenHarness |
|---|---|---|---|---|
| QueryEngine | 进程级 Orchestrator，Gateway+Channel+Plugin+Session 四层协同 | LangGraph StateGraph，DAG 编排 + Checkpoint 持久化 | 极简 while-loop，无框架依赖 | 管线治理型 QueryEngine，13 依赖注入 + 分级压缩 + Carry-over |
| Tool System | Plugin SDK 清单驱动，编译期校验，扩展成本高 | 4 层来源 + tool_search 延迟加载 | 零配置自注册 + toolset 分组 + skill_manage 自进化 | BaseTool Pydantic 强类型 + ToolRegistry + MCP 适配 |
| Permission | DM Policy 三模式 + 配对认证，安全导向 | Guardrails OAP + Allowlist，合规导向 | Security/Redact 脱敏 + CredPool 轮换，隐私导向 | 三级模式 + 敏感路径硬编码 + glob 规则，灵活导向 |
| Context | Compact 命令手动触发 + Active Memory Plugin 注入 | Summarization Middleware 可插拔 + Confidence 门控 | Context Compressor 内建 + 与 Agent Loop 耦合 | 分级压缩（microcompact→LLM 摘要）+ Carry-over 保护 |
| Memory | 3 Plugin 组合（memory-core + memory-lancedb + active-memory），后端可替换 | LLM 提取 + 防抖 + 评分门控 + Prompt 注入 | 跨会话 Memory Manager + MEMORY.md + skill_manage 自进化 | Markdown 持久 + 会话存储 |
| Extensibility | Plugin 生态（200+ exports 边界契约）+ SubAgent（orchestrator/leaf） | LangGraph Agent 定义 + Middleware Chain（9 层） | 零配置注册 + toolset 递归组合 + RL Training | BaseTool + AgentDefinition 三层扩展 + HookExecutor + BackendRegistry 三后端 |
三、从模块对比看设计取舍
3.1 灵活性 vs 严谨性谱系
``` 最灵活 ←------------------------------------------------------------------------------------→ 最严谨 hermes-agent deer-flow OpenHarness openclaw 零配置注册 Config YAML Pydantic 类型 Plugin SDK 清单 运行时校验 Middleware 构造器注入 编译期校验 skill_manage StateGraph Carry-over 版本兼容声明 ```
这条谱系的两端各有代价：
- 最灵活端（hermes-agent）：工具名冲突只在运行时发现，Skill 质量无保障。
- 最严谨端（openclaw）：扩展成本高，第三方开发者门槛高。
3.2 多 Agent 协调的隔离-通信谱系
``` 强隔离 ←------------------------------------------------------------------------------------→ 弱隔离 openclaw OpenHarness hermes-agent deer-flow ACP Spawn Swarm Delegate Sub-Agent Executor 进程隔离 subprocess/tmux 上下文隔离 线程池 消息通信 Mailbox 上下文传递 SSE 状态追踪 安全性高 中等 中等 安全性低 通信开销大 中等 中等 开销小 ```
3.3 上下文管理的"不丢失"vs"只存高价值"谱系
``` 不丢失关键信息 ←------------------------------------------------------------→ 只存储高价值信息 OpenHarness deer-flow Carry-over 保护 Confidence 评分门控 分级压缩 防抖队列 "压缩后仍记得读过什么" "只持久化评分 ≥0.7 的记忆" ```
四、设计哲学溯源：为何他们如此不同？
在深入技术细节之后，我们需要回到原点，理解每个项目的设计哲学------哲学决定了取舍，取舍决定了架构。
4.1 openclaw：连接优先------"一切皆 Channel，一切皆 Plugin"
核心信念 ：Agent 的价值不在于自身有多聪明，而在于能连接多少平台、接入多少能力。openclaw 把自己定位为消息中枢，而非"最聪明的 Agent"。
源码印证 ：openclaw 的 Plugin SDK 在 package.json 中签出了 200+ 个 subpath exports------每一个都是一个接入点的类型定义。Plugin 开发者只需 import { xxx } from "@openclaw/plugin-sdk/xxx" 就能接入对应能力，覆盖认证、流式传输、工具、搜索、安全、SSRF 防护等。外部 Plugin 必须在 package.json 中声明 openclaw.compat.pluginApi 和 openclaw.build.openclawVersion，否则无法发布到 ClawHub------这是连接优先的必然选择：要做消息中枢，就必须保证所有接入的 Plugin 都是版本兼容的。
大白话理解 ：openclaw 把自己理解成一个路由器 ------不管你用的是 WiFi、有线、还是 5G，进来都是 IP 包；不管你要访问的是百度、Google 还是 YouTube，出去都是 IP 包。路由器不关心内容，只关心"连通"。当你通过微信说"帮我查天气"，微信只是一个 Channel（消息进来被统一包装成 InboundMessage），查天气用的 Web Search 只是一个 Plugin（能力可插拔），回复又是通过微信这个 Channel 发回去------全程 openclaw 只做"连接"。
取舍代价：扩展成本高------写一个新插件需要理解 SDK 的 200+ 个导出点和版本兼容规则。
4.2 deer-flow：深度优先------"以研究流为纲"
核心信念：不追求连接广度，而是追求单一领域（研究流）的极致深度。Agent Loop 用 LangGraph 的 DAG 编排来实现可复现的研究流程。
源码印证 ：deer-flow 的 ChannelManager 不直接管理 Agent Loop，消息进来后只做"路由到 LangGraph"这一件事。真正的推理-工具调用循环由 LangGraph 的 StateGraph 驱动------节点即函数，边即条件，天然支持分支与回环。研究流被定义为一个有明确步骤的 DAG：必须先制定计划 → 必须搜索 → 搜索不够必须继续读 → 读完了才能分析 → 分析完了才能写综述。每一步的状态都持久化在 LangGraph 的 Checkpoint 中，可以随时回溯、审计、恢复。
deerflow-harness Python 包硬依赖了 6 个 LangGraph/LangChain 相关包（langgraph>=1.0.6,<1.0.10、langgraph-api、langgraph-cli、langgraph-runtime-inmem、langgraph-checkpoint-sqlite、langgraph-sdk），版本窗口极窄------这是"深度优先"的代价：框架强耦合。
取舍代价：框架耦合------必须依赖 LangGraph 的 StateGraph/Checkpoint/SDK 体系，无法轻易替换底层编排引擎。
4.3 hermes-agent：进化优先------"Agent 不仅能用工具，还能创造工具、改进工具"
核心信念：工具系统不应该是静态的，Agent 应该能动态注册新工具、自我改进技能、甚至通过 RL Training 进化。
源码印证 ：任何一个新的 tools/xxx.py 文件只需 registry.register(...) 一行即可注册工具------没有 Schema 校验、没有版本兼容检查、没有 Plugin 清单。Toolset 支持组合和递归解析------debugging 包含 web + file，hermes-gateway 递归组合 15 个平台 toolset。系统提示词里的 SKILLS_GUIDANCE 告诉 LLM："完成复杂任务后保存为 Skill，发现 Skill 过时立即修改"------进化机制不是算法驱动的自动化，而是提示词驱动的自主进化。
取舍代价 ：缺乏编译期校验------registry.register() 不校验 Schema 类型正确性，工具名冲突只在运行时警告。
4.4 OpenHarness：基础设施优先------"纯 Harness，不做应用"
核心信念 ：不做任何垂直场景，只提供最严谨的 Agent 基础设施------让其他应用可以基于它构建。"The model is the agent. The code is the harness."
源码印证 ：QueryEngine 的构造器接收 13 个依赖------api_client、tool_registry、permission_checker、hook_executor、tool_metadata 等等，每个子系统都通过构造器显式声明，组装方式完全透明。run_query() 的核心循环集成了自动压缩检查、PreHook 拦截、Permission 检查、Carry-over 记录、PostHook 审计------管线治理而非简单循环。build_runtime() 函数有 10 个组装步骤，每个步骤都可以被上层应用定制替换。
取舍代价：上层应用需要自行组装------你需要理解每个零件的接口和依赖关系，组装过程比"装个 Plugin 就跑"复杂得多。
4.5 四种哲学的底层逻辑
| openclaw | deer-flow | hermes-agent | OpenHarness | |
|---|---|---|---|---|
| 解的问题 | 连接广度 | 流程深度 | 能力进化 | 基础严谨 |
| 核心抽象 | Channel + Plugin | StateGraph + Middleware | Registry + Toolset | QueryEngine + Carry-over |
| 语言选择 | TypeScript（生态优势） | Python + LangGraph | Python（灵活性） | Python + Pydantic（类型契约） |
| 一句话 | 让一切连接一切 | 让研究流可复现 | 让 Agent 自我进化 | 让基础设施最可靠 |
关键洞察 ：四种哲学不是对同一问题的四种解法，而是对不同问题的四种回答。
五、共性瓶颈与突破方向
四个项目虽然设计哲学各异，但在六个通用能力模块上不约而同地撞上了相同的天花板：
| 模块 | 共性瓶颈 | 本质原因 |
|---|---|---|
| QueryEngine | Agent Loop 内的推理路径不可预测 | LLM 输出有随机性，while-loop 无结构约束 |
| Tool System | 全量注册致 Prompt 臃肿 vs 按需加载致发现困难 | 工具发现是"元问题"------需要"知道所有工具但不在 Prompt 中显示所有工具" |
| Permission | 安全与便捷的根本冲突 | 权限治理与业务场景强耦合，静态规则无法应对动态场景 |
| Context | 压缩的信息损失无法量化评估 | "谁来判断什么状态是关键的"本身也是不确定的 |
| Memory | 记忆检索的相关性与完整性不可兼得 | 语义搜索召回率高但精确率低，精确获取覆盖面窄 |
| Extensibility | 扩展的灵活性校验强度成反比 | 零配置=零保障，强校验=高门槛 |
5.1 突破方向：Workflow/Workbench 架构是什么？
上述瓶颈的根源在于：Agent 层的 while-loop 既承担了"推理"，又承担了"流程控制"，两者耦合导致了不可预测性。而 Workflow/Workbench 架构的核心思想，是在 Agent 层之上增加一个显式的流程控制层。
Workflow 层 负责定义任务的执行骨架。它将一个复杂任务分解为预定义的步骤序列（DAG），每个步骤指定：该步骤能使用哪些工具子集、必须达成什么产出标准、满足什么条件才进入下一步。Agent 在单个步骤内仍然自由推理，但步骤间的流转由 Workflow 控制，直接解决了引擎的不可预测性和工具的全量注册问题。
Workbench 层负责全局治理。它将工具、Skill、权限规则作为可复用的资产统一管理，形成跨项目的"工具市场"和"规则库"。Agent 按需从市场中加载能力子集，解决了扩展的治理难题和权限的业务耦合问题。
架构关系示意：
``` Workbench 层（全局治理：工具市场 + 规则库 + 状态存储） ↓ 加载子集 Workflow 层（流程定义：步骤序列 + 条件分支 + 工具子集 + 权限上下文） ↓ 控制流转 Agent 层（推理执行：while-loop / StateGraph / QueryEngine） ↓ 调用 Tool/Memory/Permission（Harness 的基础能力模块） ```
这本质上是将原先由 LLM 自由决定的"下一步做什么"，在关键环节上收归为显式的流程定义------让不确定性被结构约束，让治理规则从隐式变为显式。这正是四个项目的共性瓶颈共同指向的演进方向。
这一架构思想在 LangGraph 的 StateGraph（已内置 DAG 能力）、Anthropic 的 MCP 协议（工具市场的标准化尝试）中已经有了雏形，但尚未形成完整的、被广泛采纳的 Workflow/Workbench 层抽象 [5][8]。
六、总结：选择，始于理解差异
四个项目的深度对比揭示了 Harness 工程的核心设计空间：
- QueryEngine 是分水岭------自研 while-loop（灵活但无结构）、LangGraph StateGraph（结构化但框架耦合）、管线治理型 QueryEngine（严谨但组装复杂），三种选择决定了整个 Harness 的气质。
- Tool System 是能力边界------零配置注册（hermes-agent）到 Plugin SDK 清单（openclaw），灵活性与严谨性的权衡贯穿始终。
- Permission 是安全底线------三级模式（OpenHarness）、Guardrails（deer-flow）、配对认证（openclaw）、脱敏（hermes-agent），四种偏重反映了不同场景的安全需求。
- Context Management 是智能上限------Carry-over 保护（OpenHarness）和 Confidence 门控（deer-flow）代表了两种方向：不丢失关键信息 vs 只存储高价值信息。
- Memory 是经验积累------Plugin 化记忆（openclaw）vs 文件化记忆（hermes-agent）vs 评分门控记忆（deer-flow），体现了不同的可靠性假设。
- Extensibility 是生命力------结构化扩展（OpenHarness 的 AgentDefinition + HookExecutor）vs 零配置扩展（hermes-agent 的 registry.register），决定了谁能在生产环境中走得更远。
最终洞察 ：openclaw、deer-flow、hermes-agent 和 OpenHarness 并非成熟度上的高下之分，而是设计目标上的泾渭之别。它们分别回答了 "如何连接"、"如何做深"、"如何进化"和"如何做稳" 四个根本性问题。
一位真正的架构师，不会在这四个选项中简单地"择一而终"。真正的工程智慧，在于理解它们的设计取舍，并在一个更高级的Workflow/Workbench架构中，综合运用这四种风格：让关键的流程像deer-flow一样严谨，让能力的扩展像hermes-agent一样灵活，让服务的连接像openclaw一样广阔，而这一切，都建立在像OpenHarness一样稳固的基础设施之上。
这才是Harness工程的终局想象。
参考链接
1\] openclaw 项目仓库：[github.com/openclaw/op...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fopenclaw%2Fopenclaw "https://github.com/openclaw/openclaw") \[2\] deer-flow 项目（Metagpt 生态）：[github.com/geekan/Meta...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fgeekan%2FMetaGPT "https://github.com/geekan/MetaGPT") \[3\] hermes-agent 项目仓库：[github.com/NousResearc...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2FNousResearch%2Fhermes-agent "https://github.com/NousResearch/hermes-agent") \[4\] OpenHarness 项目仓库：[github.com/PrefectHQ/o...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2FPrefectHQ%2Fopenharness "https://github.com/PrefectHQ/openharness") \[5\] LangGraph 官方文档：[https://langchain-ai](https://link.juejin.cn?target=https%3A%2F%2Flangchain-ai "https://langchain-ai")