100天前，我对智能体（Agent）的概念还停留在"调API的工具"。100天后，我亲手搭建了一套运行在Ubuntu上的双智能体协同系统——OpenClaw与Hermes Agent通过编排器高效协作，具备状态管理、记忆持久化、降级路由和自愈机制。这不是一篇教程，而是一段真实的认知跃迁记录：从黑箱使用者到系统设计师，我走过的每一步弯路和顿悟。

100天，从AI小白到双智能体架构师

企业级的应用系统 | 创作创造创新的工业级底座 | 人类与智能体协同工作的典范

architecture diagram:

Ubuntu 
├─ Docker容器：
│  ├─ Gateway 
│  ├─ Openclaw
│  └─ hermes agent
├─ 挂载目录
│  ├─ /home/ubuntu/.openclaw
│  │  ├─ workspace/
│  │  ├─ agents/hermes/agent/
│  │  ├─ delegation-mechanism/（任务监控系统脚本）
│  │  └─ runs.json
│  ├─ /var/www/hugo.princewill.cn
│  └─ /home/ubuntu/openclaw_backups（核心脚本、日志、报告）
│      ├─ model_guard.py / model_guard_fast.py（模型守护，自治）
│      ├─ umami_stats.py（统计同步）
│      ├─ check_search_index_py.sh（搜索索引自愈）
│      ├─ backup_agent.sh / backup_website.sh（备份）
│      ├─ safe_feishu.py
│      ├─ daily_report.py（只读巡检）
│      ├─ self_heal.sh（自愈机制）
│      └─ 各种日志文件
├─ 独立服务（systemd）
│  └─ comment.service（留言系统）
├─ 独立数据目录
│  └─ /opt/ssq_system（福彩应用系统）
└─ 核心特性
   ├─ BOT消息安全发送
   ├─ 福彩分时保存+次日推送（彩票兑奖和信息推送）
   ├─ 委派监控（动态）
   ├─ Nginx HTTP/HTTPS 直服
   ├─ 模型守护（独立长/短周期-大模型能力调用）
   ├─ 系统云备份
   ├─ 全链路日志与只读巡检 + 每日三次健康巡检
   ├─ 基础环境自愈
   └─ 专项自治（搜索/统计/留言/模型各自恢复）

这就是我100天后亲手搭建的系统。它不是论文里的理想拓扑，而是一个运行在Ubuntu上、每天处理真实任务、能够自我诊断和部分自愈的工业级双智能体底座。而100天前，我甚至连OPENCLAW是什么都不知道。

起点：纯粹的好奇（3月 – 4月上旬）

那时的我：一个"用户/操作者"

一切始于好奇。OPENCLAW这个名字在技术社区里反复出现，有人说它是"下一代智能体框架"，有人说是"带爪子的AI工具"。我没有任何具体任务要解决，只是想亲眼看看：它到底是什么？

最初的体验是"低摩擦"的——服务器上已经配置好了OPENCLAW环境。我像一个游客，在别人铺好的路上散步。输入指令，看着Agent拆分任务、调用工具、返回结果。神奇吗？有一点。但更像是在操作一个黑箱：我按按钮，它发光。

局限很快显现：

• 我无法修改它默认的行为模式
• 它总是忘记之前的对话状态（记忆浅）
• 一旦任务稍微复杂（比如"先查A，再根据A的结果决定是否调用B"），它就混乱

当时我不确定这是OPENCLAW本身的问题，还是配置环境的问题。但我意识到一件事：如果我只能"用"它，我永远无法真正理解它。这个念头，把我推向了第二阶段。

转折：容器化安装，为了控制与理解（4月中旬 – 5月下旬）

角色进化：“部署者/集成者”

我决定自己动手——从零开始，在一个干净的容器里安装OPENCLAW。为什么选择容器？因为我想隔离、想复现、想拆解。Docker对我来说原本只是一个"跑起来就行"的工具，这次我逼自己去读Dockerfile，去理解每个ENV的作用，去调试网络和卷挂载。

几个让我"开窍"的时刻：

1. 环境隔离如何影响行为确定性 第一次容器化部署后，OPENCLAW在容器内总是报"权限不足"，而宿主机上同样的二进制文件却能运行。查了很久才发现是容器内的用户UID映射问题。这让我意识到：Agent的"确定性"不只取决于代码，还取决于它所在的环境——网络策略、文件系统权限、时间同步、甚至locale设置。一个不确定的环境，会让同一个Agent表现出截然不同的行为。

2. 阅读源码，不再恐惧 为了调试一个记忆丢失的bug，我第一次打开OPENCLAW的核心状态管理模块。原来它用了一个简单的字典+时间戳来维护短期记忆，而长期记忆需要外挂向量数据库。那一刻我忽然理解：Agent不是魔法，是精心设计的状态机 + 检索系统 + 调用回路。我以前以为它只是"聪明地调API"，现在看到了它内部的规划器（planner）和执行器（executor）如何协同。

3. 从"填参数"到"写规范" 我开始写脚本——不是简单的docker run，而是用docker-compose定义服务，用Makefile封装常用命令，甚至写了一个小的entrypoint脚本来预置OPENCLAW的初始配置。这不再是"使用"，而是"封装与交付"。我甚至开始给团队内部的同事写一份《OPENCLAW容器化部署最佳实践》。

这个阶段的收获：我获得了控制权，也承受了复杂性。但最大的领悟是：单一Agent再强大，也有边界。它的记忆受限于上下文窗口，它的规划受限于预设的工具集，它的行动受限于单一的执行线程。我开始想：如果让两个Agent一起工作呢？

蜕变：OPENCLAW + Hermes Agent 协同（6月至今）

角色最终形态：“架构师/AI系统设计师”

Hermes Agent是另一个当时很火的智能体框架，以轻量、可嵌入、消息驱动著称。我不满足于二选一，我要让两个最火的智能体都为我所用，并且让它们协同工作。你看到的架构图，正是这一阶段的完整产物——Gateway统一入口，Openclaw与Hermes各司其职，通过挂载的脚本体系（委派监控、模型守护、自愈机制等）实现闭环。

协同设计的核心挑战：

• 通信协议：两个Agent没有原生接口。我设计了一个基于Redis Pub/Sub的中间层，OPENCLAW发布任务，Hermes订阅并执行，结果再原路返回。
• 分工原则：OPENCLAW擅长复杂规划和多步推理（像"大脑"），Hermes擅长快速响应和原子操作（像"手"）。我给OPENCLAW分配了"任务拆解与异常处理"，给Hermes分配了"工具调用与结果格式化"。
• 状态同步：如何让两个Agent共享同一份任务上下文？我设计了一个轻量级的共享状态表（用Redis Hash存储task_id对应的全局状态），并引入了版本号避免写冲突。

几个让我真正成为"专家"的设计决策：

1. 不是硬连接，而是编排 最初我试图让两个Agent直接互相调用，很快发现会死锁。后来改成"编排器模式"：一个轻量级的协调者（我自己写的一个几十行的Python脚本）负责任务的分发与结果的路由。Agent之间不直接对话，而是通过编排器交换消息。这让我悟出了那条核心原则：多Agent系统不是连接多个强大的单体，而是设计一个允许它们松散耦合的生态系统。

2. 失败回退与动态切换 在一次演示中，OPENCLAW的规划模块超时了。我的系统自动将当前任务切换到Hermes的"快速模式"，虽然结果粗糙但保住了完成率。这个机制后来演变成了"降级路由表"——每个任务都有主Agent和备选Agent，备选甚至可以是一个更小的专用模型。这是我从"让它们能通信"到"让它们有韧性"的跨越。

3. 理解深入：从工具到队友 过去我把Agent看作"可编程的工具"。协同架构让我必须把它们看作"有局限的队友"——有的擅长记忆，有的擅长速度，有的擅长谨慎。设计通信协议本质上是在设计团队规范。我甚至开始记录两个Agent的"性格日志"：OPENCLAW容易过度思考，Hermes容易忽略依赖顺序。这些观察反过来指导我调整超时参数和重试策略。

100天的认知跃迁：三点最深的领悟

1. 从"API调用"到"状态与记忆" 最初：Agent = 根据输入调API。现在：Agent = 状态机 + 记忆系统 + 规划器 + 执行器。没有记忆的Agent只是被动的函数，没有规划的Agent只是随机漫步。

2. 从"黑箱操作"到"环境确定性" 容器化让我明白：Agent的行为边界不只有代码，还有它所在的运行环境（网络、存储、权限）。一个在宿主机上表现完美的Agent，到了容器里可能因为/tmp目录不可写而崩溃。确定性不是写出来的，是锁出来的。

3. 从"单体崇拜"到"编排信仰" 最强的单个Agent也比不过两个设计良好、松散耦合的Agent。OpenAI、Anthropic等厂商在拼命做大模型，而我在做相反的事：把大Agent拆成小Agent，再让它们通过简单协议协同。这条路线让我看到了超越单一模型局限的可能性。

角色演进表（3月→6月）

尾声：下一个100天

回看这100天，最神奇的并不是我从"不会用"到"会设计"，而是每一次"为什么"都没有被放过：

• 为什么它记不住？→ 去读状态管理
• 为什么容器里跑不通？→ 去学UID映射和网络模式
• 为什么单个Agent总是卡住？→ 去设计双Agent降级路由

今天，我可以用一句话总结我的角色变化：从OPENCLAW的乘客，变成了以它为组件之一的智能体交通系统的设计师。

如果你也在类似的旅程中，我想分享一个体会：不要害怕"手脏"。去读源码，去写Dockerfile，去让两个Agent吵架然后你来调停。100天足够你完成从好奇到专家的跃迁——前提是你愿意从"按按钮"走向"造按钮"。

我的下一个目标是：让OPENCLAW与Hermes的协同系统能够动态发现新的Agent（服务发现），并允许Agent之间协商任务（契约式协作）。这又将是一个全新的层次。

感谢这段旅程中的每一次报错、每一个凌晨的调试、每一个"原来如此"的顿悟。它们共同构成了我从3月到6月的技术成长——不是陡峭的曲线，而是一级级亲手砌上去的台阶。