AI Agent架构收敛：OpenClaw、Codex与Hermes的三大共性层

1. 三个名字背后的真实主角：模型、运行时和工具链先分清

最近一周我先后把 OpenClaw、Codex CLI 和一整套基于 Hermes 模型的 Agent 环境都部署了一遍，本意是想做工具对比，结果越装越觉得有意思：这三样东西，一个来自开源社区的多面手自动化框架，一个来自大厂的编程智能体，一个是开源模型加社区工具拼起来的组合，出身完全不同，可把它们拆开看骨架，居然长得几乎一样。这个观察让我把之前零散的认知串起来了——AI Agent 架构正在收敛，而且收敛速度比大多数人想象的要快。

这篇文章会围绕这个主题展开：OpenClaw、Codex、Hermes 分别是什么，它们的架构共性在哪里，为什么收敛会发生在这些层，以及我从真实部署和排错中总结出来的判断。适合三类人看：正在选型 Agent 工具的开发者、想理解 Agent 底层架构的产品和技术负责人，以及打算自己动手搭一套 Agent 但不知道从哪下手的新手。

首先要做的事，是把这三个名字对应的“东西”搞清楚。“从 OpenClaw、Codex 到 Hermes”这句话很容易让人误以为它们是同一类事物，其实不是。它们分别代表了 Agent 生态里的不同层次，而架构收敛恰恰是在这几个层次上同时发生的。

1.1 OpenClaw：定位是“什么都能干的个人自动化 Agent”

OpenClaw 是一个开源的 AI Agent 运行时，社区里也有些人按项目习惯把它和另一个同名项目混着提，反正你搜的时候都能找到。它的定位非常直白：给你一个可以常驻运行的 Agent 进程，通过自然语言下达指令，它去调用文件系统、命令行、各种 API 扩展，完成自动化任务。和很多同类项目相比，OpenClaw 的最大特点是“通用”——它不像某些 Agent 只盯编程任务，它能接智能家居、接日历、接各类自建服务，更像一个“个人数字管家”。

架构上，OpenClaw 的核心模块是这几块：模型接入层、技能系统、扩展系统和执行审批机制。模型接入层负责对接各种模型后端，默认支持 OpenAI 系、Anthropic 系、Google 系，还可以配置 NVIDIA NIM 这类私有化推理服务。技能系统是给 Agent 预置的“能力清单”，每个技能描述清楚自己什么时候该被调用、需要什么参数；扩展系统则是连接外部世界的大门，接 GitHub、接 Slack、接你自己的 REST API。执行审批机制解决的是安全问题，后面我会专门展开。

安装方面，OpenClaw 支持 Windows 原生环境、Linux、macOS，也可以 Docker 部署。社区里现在问得最多的是两个问题：Windows 上怎么装，以及怎么配置 NVIDIA NIM 当后端。前者主要是环境变量和路径的坑，后者主要是 NIM 端点地址和模型名称的匹配。具体配置我放到后面的部署章节讲。

1.2 Codex：一个“编程智能体”从模型到 CLI 的完整演变

Codex 这个名字在圈子里有歧义，必须掰开讲。最早 OpenAI 发布过一代代码模型，代号就叫 Codex，当时主打“用自然语言生成代码”，内部跑在 GPT 架构上。后来这个品牌基本不单独提了。但从近两年开始，OpenAI 又把 Codex 这个名字捡起来，用在一款“编程智能体”产品上——它不再是一个单纯的补全模型，而是一个能在终端里跑命令、读文件、写代码、跑测试、甚至提 Pull Request 的 Agent。我们现在聊的架构收敛，主要指的是后者，也就是 Codex CLI 或者说 Codex Agent。

Codex 的架构可以拆成三层：前端 CLI、Agent Harness、模型 API。CLI 负责接收自然语言指令，把进度渲染在终端里；Harness 是整个 Agent 的“套具”，这一层包含系统提示词、工具定义、任务拆解循环、上下文窗口管理、权限提示等；模型 API 是大脑，默认走 OpenAI 的 /responses 端点——这个端点是后来 OpenAI 主推的 Agent 交互端点，和早期的 completion、chat completion 接口都不一样，它直接把工具调用、上下文、状态管理设计成了协议的一部分。

社区里大量讨论集中在两件事上：一是怎么把 Codex CLI 接进其他模型服务，比如“Codex 接入 DeepSeek”；二是 Harness 层面的行为约束。你会发现，官方模型当然用起来最顺，但社区通过改配置、改网关，也能让 Codex 的 Harness 去驱动第三方模型。这就触及了架构收敛的一个核心：Agent 的骨架和大脑是分离的，而且骨架已经开始标准化了。

1.3 Hermes：更多时候代表“Agent 化的开源模型底座”

Hermes 是这三个名字里最容易让人懵的。它不像 OpenClaw 和 Codex 那样指一个明确的框架产品，在社区里至少有三层含义混着用。

第一层，也是源头，是 NousResearch 的开源模型系列。Hermes 系列模型通常是基于 Llama 或其他开源基座做指令微调，特别擅长 function calling 和对话式任务执行。因为 Agent 需要模型稳定输出工具调用格式，所以这类“为 Agent 优化过”的开源模型在自建 Agent 的圈子里很受欢迎。第二层含义是各种挂了 Hermes 名字的 Agent 工具或项目，有的和模型本身没什么关系，纯粹是借这个名字。第三层是某些工作流里把 Hermes 当成“智能体运行时”来部署，配合 Docker 使用。

在“deepseek hermes”这个搜索组合里，我看到社区多是在讨论“用 Hermes 工具链部署 DeepSeek 模型做 Agent”。这恰好印证了我的判断：Hermes 在当前 Agent 架构讨论里，更多是作为“开源模型底座 + 配套 Agent 工具”的整体生态出现。它代表的是 Agent 收敛的另一个侧面——模型层也在收敛，越来越多的开源模型主动适配工具调用标准，让上层 Agent 框架可以无缝切换大脑。

把这三个角色分清后，你会发现一个事先没想到的事：OpenClaw、Codex 和 Hermes 并不在同一个赛道竞争，它们原本是三个层次——运行时工具链、编程智能体应用、开源模型底座——却在互相靠拢。靠拢的结果，就是我下面要讲的几个“收敛层”。

2. 收敛层一：模型后端可插拔，Agent 不再是单一模型的附属品

如果只看一两年前的早期 Agent 项目，你会觉得“Agent 就等于一个大模型加几个 Prompt”。但现在无论是 OpenClaw、Codex 还是围绕 Hermes 的 Agent 工具，架构图上第一个标准模块都是“模型接入/路由层”。这个层的作用是：让你可以把任何兼容模型接到同一个 Agent 骨架上，想换就换。

2.1 三个项目各自怎么处理模型切换

OpenClaw 的做法是配置文件里声明 provider。我在本机试过，最省事的路径是把 API Key 写在环境变量里，然后在配置里指定默认模型。比如你想让 OpenClaw 走 NVIDIA NIM 上的自建模型，核心就是三件事：NIM 服务地址、模型名称要和 NIM 暴露的一致、鉴权信息。它不关心你后端到底是 OpenAI 还是 NIM，只要走 OpenAI 兼容协议就行。

Codex CLI 的情况稍微特殊，因为它是 OpenAI 的产品，默认绑定自家的 /responses 端点。但它的配置里留有 provider 相关的设置项。社区“接入 DeepSeek”的方案，本质就是改掉默认的 endpoint 和 token，让 Codex 的 Harness 去调用兼容的接口。我自己在这条路上踩过不少坑，后面排错章节会详细讲。

Hermes 系工具链本来就是开源模型生态，模型切换更是家常便饭。你甚至可以在同一套工具里，对话任务用一个模型、工具调用任务用另一个模型。这种“任务级路由”已经在很多 Agent 框架里成了标配，这是前几年完全没预料到的变化。

2.2 为什么可插拔成了架构底线

这里要理解一个关键逻辑：Agent 的真正资产是编排逻辑、工具链和上下文管理，而不是模型本身。模型只是“大脑”这个零件，而且这个零件更新快、供应商多、价格浮动大。如果你把 Agent 架构焊死在某个模型上，那模型一改版、一涨价、一限流，你的整个自动化体系就瘫痪了。

用现实一点的话说：过去我们做传统系统，数据库选型是核心，轻易不换；但 Agent 时代的模型比数据库更“善变”，所以架构上必须有一个中间层来隔离这种变化。这个中间层就是模型网关/路由层。它像一个转接头：一边是 Agent 框架发出的统一工具调用协议，另一边是各家模型的差异接口，由它负责翻译和转发。

我在调 OpenClaw 切换后端时切身感受过这个转接头的重要性。切到另一家模型后，Agent 的思维链、系统提示词、工具调用全都不用动，只需要改路由配置。没有这层抽象，每次模型升级都等于把 Agent 重写一遍，谁也受不了。所以你现在去看任何一个认真的 Agent 项目，模型路由层都是第一优先级设计的模块。

2.3 可插拔不等于无缝替换

不过这里必须泼一盆冷水：模型路由层解决的是“能不能接”的问题，解决不了“接得好不好”的问题。不同模型对工具调用格式的遵循能力差异非常大。有些开源模型看起来支持 function calling，实际一压测，参数名拼错、该转 JSON 的字段给你返回字符串、多轮工具调用后格式直接崩。这都正常。

所以收敛的架构只是降低了“切换成本”，没有消除“适配成本”。踩过这个坑之后我才明白，选 Agent 框架时真正要看的不是它支持多少模型，而是它对“模型差异”有多大的容错和补偿能力。比如有些框架会在路由层做工具调用结果修复，失败后自动重试、格式化纠正；有些框架完全不管，把烂结果直接交给上层，最后表现就是 Agent 行为混乱。建议你在选型时把这一层的能力也算进去。

3. 收敛层二：执行审批与技能目录，成了 Agent 的“标准配件”

第二个所有 Agent 都在往一个方向走的层，是执行安全层。过去聊大模型，没人关心权限；但 Agent 一旦真的去执行命令、写文件、调接口，权限问题就从“运维话题”变成了“架构核心话题”。有意思的是，OpenClaw、Codex、Hermes 系工具，不约而同地给出了几乎相同的答案：动作级审批加技能目录。

3.1 OpenClaw 的 exec-approvals：把“让不让执行”做成持久化配置

OpenClaw 里有一个很重要的概念叫 exec-approvals，也就是执行审批。具体表现是，Agent 第一次准备执行某个敏感操作，比如运行一段 shell 命令、写入某个文件、调用某个扩展时，不会直接动手，而是先停下来向你确认。你同意之后，这条规则会被记录到审批配置里，下次同样是这个操作，就不再反复问你了。

社区里有很多关于这个机制的提问，最有代表性的一个报错大意是：提示在 /root/.openclaw/ 路径下存在旧的 exec-approvals.json 文件，工具启动时检测到了历史遗留数据，需要手动处理。我当时看到这条信息的第一反应是版本升级后，旧版审批文件格式和新版不兼容。解决办法通常是备份旧文件、让它生成新的审批配置，或者手动做字段迁移。这类报错看起来吓人，其实机制设计上是好事——它说明工具在一丝不苟地维护“执行权限边界”，而不是默认放行一切。

我在实际使用中最深的体会是：审批机制不是摆设。没有它，即使模型再强，你也不敢把 Agent 放到有真实数据的环境里跑。它本质上是给大模型这个“不可控的执行者”加的一层保险丝。

3.2 Codex 的权限提示与 Harness 约束

Codex 的权限模型没有独立的审批文件，但它把“权限确认”做进了 Harness。每一次文件写入、命令执行、网络请求，都可以配置成“自动放行”“询问我”或“直接拒绝”。这样做有两个好处：一是保证了安全边界，二是保证了可审计性——干了什么都有痕迹，随时可以回看。

这里我想多说一句 Harness 的概念。英文里 harness 原意是马具、套具，用在 Agent 架构里，指的是“套在模型外面、约束它行为的那层工具”。系统提示词、工具定义、任务循环、权限策略、上下文管理，全都在 Harness 里。Codex 和其他同类编程 Agent 的差距，很多时候不在模型，而在 Harness 的精细度。Harness 写得好，小模型也能稳定完成多步任务；Harness 写得糙，再强的模型也会在复杂任务里跑偏。

3.3 技能系统：为模型预置“能力目录”

第三个所有 Agent 都长出来的模块是技能系统。OpenClaw 有 Skills，Codex 有类似插件和 Harness 扩展的机制，Hermes 系 Agent 普遍支持工具调用定义。它们的共同逻辑是：把 Agent 可能用到的能力——发邮件、查天气、操作数据库、调某个 API——提前写好描述，放进一个目录里，模型在执行任务时先审视这个目录，再决定调用哪个技能。

其底层原理是：大模型的上下文窗口是有限的，不可能把所有工具的完整代码都塞进去；而技能目录相当于“压缩后的工具说明手册”，让模型知道“有这个工具，它能干什么，参数是什么”。等到真正调用时，再加载对应的执行代码。这种“按需加载”的设计，和传统软件里的插件机制很像，但有一个显著区别：技能描述是给 LLM 看的，不是给人看的。

我在这上面栽过跟头。刚开始给 Agent 写技能描述时，我按写 API 文档的习惯写得特别简洁，结果模型经常在明明该调用技能的场景下不调用，或者调用了但参数传得乱七八糟。后来我把技能描述拆成三部分——场景触发条件、参数说明（含默认值和示例）、返回结果格式——调用成功率立刻上去了。如果你也在自己写技能目录，这个经验可以直接抄：技能描述的核心不是“代码怎么写”，而是“模型什么时候该用它”。

3.4 为什么这套设计会收敛到这同一个形态

深想一层，执行审批和技能目录几乎是 Agent 架构的“必然收敛解”。原因很简单：Agent 的不可控性来自大模型的概率生成，而概率生成恰恰不能在敏感动作上“自由发挥”。所以架构上必须引入确定性机制——权限审批是确定性规则，技能目录是确定性接口——用确定性去约束概率性。凡是做不到这两点的 Agent 项目，要么只能停在 Demo 状态，要么早晚出事。因此成熟的 Agent 框架在迭代中必然会收敛到同一个答案，这不是谁抄谁，而是需求推出的最优解。

4. 收敛层三：部署形态趋同——本地 CLI、Docker 容器和远端服务各司其职

第三个收敛发生在部署层面。如果你早几年搜“Agent 部署”，看到的可能是一堆云平台、托管服务的宣传；但现在的社区风向非常明确：本地优先、容器可选、远程接入。OpenClaw、Codex CLI 和 Hermes 系 Agent，全都默认给你一套本地可跑的工具链，而 Docker 容器化则成为隔离环境的标准姿势。

4.1 Windows 上部署 Hermes 系 Agent 的最稳路径

“Windows 系统如何部署 Hermes 智能体比较合适”是近期的高频问题。我的答案很直接：别在裸的 Windows 环境里硬装一堆依赖。Hermes 系 Agent 往往要跑 Python 或 Node 环境、要下载模型、要装各种工具库，直接在宿主环境里塞，大概率过几个月系统就乱了。

推荐的做法是 Docker Desktop 加 WSL2。具体路径：

1. 先启用 WSL2，并在 PowerShell 里设置 WSL2 为默认版本。
2. 安装 Docker Desktop，设置里确认 Use WSL 2 based engine 是打开状态。
3. 为 Agent 单独建一个工作目录，写好 docker-compose.yml，把模型目录、技能目录、配置目录用 volume 挂载出来。
4. 在容器里运行 Agent 主进程，日常通过端口或本地命令交互。

这样做的理由是：Agent 在运行过程中会频繁安装依赖、写缓存、调本地工具，容器隔离能把这些“脏活”锁在一个可随时重建的环境里。而 WSL2 解决了 Windows 本地文件访问和 Docker 运行时的兼容问题。我自己的经验是，这套方案比直接跑 Python 虚拟环境要省心得多。唯一要注意的是文件挂载的路径建议放在用户目录下的独立文件夹，避免权限问题。

4.2 OpenClaw 的部署形态：从桌面进程到边缘设备

OpenClaw 的部署形态更“野”一点。它本身可以作为一个常驻进程跑在桌面电脑上，也支持 Docker，社区里甚至有人在树莓派上跑它来充当家庭自动化中心。这个跨度说明的其实是同一个趋势：Agent 正在从“云端的对话服务”变成“贴近你设备的常驻服务”。

贴近设备的好处是能操控真实世界——读本地文件、控制智能家居、跑本地脚本。这与传统 SaaS 完全不同：SaaS 时代的自动化发生在云端，Agent 时代的自动化发生在你的设备上。所以在架构收敛的现象背后，其实是使用场景发生了根本变化。任何不允许“本地部署”的 Agent 产品，都会天然丧失一批需要掌控数据、掌控执行环境的用户。

4.3 docker hermes 这类组合，本质上是在给 Agent“打包环境”

社区里的另一个高频词是 “docker hermes”。把 Hermes 和 Docker 放在一起搜的人，通常是想快速把 Agent 环境跑起来，不想被依赖地狱折磨。用 Docker 部署 Hermes 系 Agent，最大的收益是环境一致性——你同事那份配置、生产环境那份配置、你本机这份配置，可以完全是同一份镜像。

但这里有个容易踩的坑：容器环境里跑 Agent，它的“本地文件访问”往往会被限制在容器内部。如果你打算让 Hermes 类 Agent 去操作宿主机上的文件，一定要把对应目录以 volume 方式挂进去，并且设置好用户权限。否则模型可能明明觉得自己已经把文件写好了，实际上写进了容器里一个不存在的持久化层，容器一删全没了。我见过太多次这种“容器里一切正常，宿主机上啥都没有”的尴尬。

4.4 部署形态收敛的底层原因

为什么部署形态会收敛到“本地 CLI + Docker + 远程接入”三件套？我想了很久，最后得出一个比较简单的解释：这是“可控性”和“便利性”博弈的平衡点。纯云端方案便利但数据不受控、延迟高；纯本地裸装方案可控但环境极易污染。Docker 容器正好站在中间：环境可控、依赖隔离、可复制、可销毁重来。本地 CLI 则保证 Agent 能访问真实的工作目录和工具链；远程接入解决的是“人不在设备旁”的场景。三个形态各有各的存在理由，所以最后的收敛结果必然是三者并存，而不是某一种吃掉另外两种。

5. 一个真实报错还原：/responses endpoint 请求失败的完整排查

前面几章都在讲架构层面的收敛，但架构落到地，就是一个个具体的报错。这几天社区里有一条非常典型的报错，几乎可以当成 Agent 架构收敛的一个活教材，大意是：cc switch 的本地转发组件在处理 Codex 的 /responses 端点请求时失败，后面通常还跟着 provider 相关的提示。

这条报错的信息量很大，拆开看场景是这样的：你让 Codex 客户端把请求发到一个本地转发组件，再从这个组件转发到真正的模型服务，结果转发这一步挂了。整个链路是：Codex 客户端构造了一个访问 /responses 端点的请求，交给本地转发层，本地转发层再转发给目标模型服务。

5.1 先从架构图上判断故障点

这种报错千万别急着改配置，先画一遍请求路径（脑子里画就行）：

客户端 → 本地转发层 → 目标模型服务

/responses 请求失败，可能的原因有五种：

1. 客户端里配置的 endpoint 地址写错了，指向了一个不存在的本地端口。
2. 本地转发服务没有启动，或者启动后监听的不是配置里写的端口。
3. 路由映射规则没配对——客户端请求 /responses，但转发层只定义了旧的聊天补全端点。
4. 转发层起来了，但目标模型服务地址配错或当前不可达。
5. 鉴权信息没带对，目标服务直接拒绝。

5.2 逐步排查的实操过程

我最常用的排查方式，是不依赖任何调试工具，从外层往内层一层层剥。

第一步，先验证“目标模型服务”本身是否正常。如果目标是 DeepSeek 这类 API 服务，直接用 curl 测一下：

curl https://api.deepseek.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $API_KEY" \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"hi"}]}'

如果这一步通了，说明目标服务没问题，问题在本地转发层或客户端配置；如果这一步都不通，先看网络连通性和密钥，别往下查。

第二步，确认本地转发层是否真的在监听。不同工具检查方式不同，但通用的命令是看端口监听状态，Linux 和 macOS 用 lsof，Windows 用 netstat。比如你配置文件里写的转发端口是 8080，先确认这个端口有人监听。没监听就去查转发服务的启动日志——十有八九是服务根本没拉起来，或者启动时配置路径读错了。

第三步，验证客户端到转发层的请求。Codex CLI 这类工具通常支持 verbose 或 debug 日志，打开之后能看到完整请求头和目标 URL。重点检查两件事：请求 URL 的端口、路径和转发层配置是否一致；Authorization 头是否还在。很多转发层为了让请求能转出去，会重写请求头，结果重写后鉴权丢了，目标服务直接返回 401。

第四步，检查路由映射。我发现最容易出问题的是“端点版本不匹配”。Codex Agent 默认走 /responses 端点，而市面上很多兼容服务只实现了老式的 /v1/chat/completions。中间转发层如果没做端点映射，请求就会撞上一堵墙。解决思路有两个：要么给你的转发层配一条“把 /responses 映射成目标服务兼容端点”的规则；要么在客户端配置里切换成目标服务支持的端点格式。

5.3 这类报错为什么是“收敛”的缩影

仔细想想，这个报错本身就是架构收敛带来的新问题。以前模型厂商自己出 CLI、自己出后端，不存在“本地转发层”这种东西，也就不存在转发失败。但现在大家都把模型后端做成可插拔了，中间自然多出一层基础设施——转发层。转发层的出现让“用 A 框架驱动 B 模型”成为可能，但也引入了新的故障点。

这也解释了为什么现在社区问答里，大量 Agent 技术问题都集中在“接口适配”而非“算法原理”。你不需要理解 Transformer 的注意力机制才能用 Agent，但你必须理解 endpoint 背后的一整套协议，否则连第一个 Hello World 都跑不通。所以我的建议是：学习 Agent 开发，与其死磕某个框架的 API 文档，不如先把 OpenAI 兼容协议、/responses 端点、工具调用格式这些跨框架的公共知识吃透。它们才是 Agent 架构收敛之后，所有系统共用的语言。

6. 架构都收敛了，选型反而要回到“边界条件”

最后聊聊选型。很多读者看完前面的分析，可能会产生一个问题：既然架构在收敛，那 OpenClaw、Codex、Hermes 这些是不是随便选一个就行？我的回答是：架构收敛降低的是“切换成本”，降低不了“任务适配差异”。选型还是要回到你自己的边界条件。

6.1 三套体系的核心适用场景对照

我根据实际部署和一段时间的使用体验，做了这么一张对照表：

需要注意的是，表格里只是“天然更合适”的场景，不是“只能干这个”的场景。OpenClaw 也能写代码，Codex 也能做点自动化，Hermes 配上合适的工具也能办公。但术业有专攻，用“通用 Agent 跑编程任务”和“编程 Agent 干编程任务”，体验差距会很明显，尤其任务一复杂，差距立刻显现。

6.2 我的个人选型建议

如果你问我自己怎么选，我的判断标准是三条。

第一，看任务类型。你的核心需求是“帮我干杂活、整合各种服务”，首选 OpenClaw 这类通用运行时；核心需求是“帮我把代码写对、把工程跑通”，Codex CLI 这类编程智能体更顺手。

第二，看运行环境。你的 Agent 要长期跑在一台 Windows 电脑上，并且需要和本地文件、本地服务频繁交互，那 Docker 加 WSL2 的隔离方案几乎是最优解。如果你想要极致简单，先跑通再说，那直接本地裸装也未尝不可，反正环境乱了可以推倒重来。

第三，看你对模型底座的掌控力需求。如果你在意数据隐私、想部署私有模型，Hermes 系和开源模型生态绕不开。如果你更在意效果、愿意把模型交给更强大的商用模型来驱动，那 OpenClaw 和 Codex 支持的商用模型后端会更省心。

6.3 别被“大一统”叙事迷惑

最后想提醒一句：架构收敛不等于模型能力收敛。OpenClaw、Codex、Hermes 可以长成相似的骨架，但骨架上的“大脑”差距依然悬殊。架构收敛带给我们的真正红利是低成本实验——你可以今天用这个模型、明天换那个模型，用同一套 Agent 工具快速跑对比，找到最适合任务的那一个，而不是被某个生态绑死，再也没有选择权。

所以在实际操作中，我的态度是：框架不追新，协议要跟紧。凡是把模型网关、执行审批、技能系统这三层做扎实的项目，都值得认真学；凡是只靠一个模型 API 拼出来的“套壳 Agent”，不管包装多华丽，都建议直接跳过。

我自己把这套思路在真实项目里验证了一轮之后，最大的体会是：AI Agent 架构的收敛，不是某个团队灵光一闪想出来的标准，而是被同样的问题逼出来的统一解。大模型不可控，所以需要确定性的执行审批；工具越来越多样，所以需要标准化的技能目录；模型更新太快，所以需要可插拔的模型路由。谁都得过这几关，架构自然就长得越来越像。

分享一个我实际用下来最顺手的小技巧：不要在 Agent 项目里堆功能，先把“模型网关 + 权限审批 + 技能目录”这三个模块当成地基来搭。想清楚这三层，任何新框架出来，你都能在半天内上手——因为它们的骨架你已经提前理解了。

最后再补一个更落地的提醒：部署任何 Agent 之前，先花十分钟把官方文档里关于配置文件的默认路径找出来。OpenClaw 的配置集中在用户目录下的 .openclaw 文件夹里，Codex CLI 的配置也在它自己的配置目录里，容器部署的 Hermes 系工具则要留意 volume 挂载路径。你后面八成以上的排错工作，几乎都会围绕这几个文件展开。先把地图拿到手，再开始探索，就没什么好慌的了。