个人AI智能体持久自我改进实战：构建Grok Bot与Hermes Agent协同的harness系统

说实话，看到Elvis Saravia更新个人harness这条消息时，我第一反应是——这老哥又在折腾他的AI全家桶了。但等我把他在公开渠道分享的思路拆开看了一遍，发现里面关于harness、Grok Bot和Hermes Agent这三样东西怎么拼成一套能长期跑、还能自己改自己的智能体，确实有不少可以直接抄作业的设计。这篇不聊虚的，我就按他的思路，从零重搭了一遍这套系统，顺便把过程中踩到的坑、想明白的原理都记下来。

这套东西适合谁看？我的回答是：但凡你手头有超过一个API模型、想让AI不只聊天还要落地干活、又希望它越用越顺手而不是越用越傻的人，都值得花十几分钟读完。本文会讲清楚harness到底是什么、为什么Grok Bot和Hermes Agent这么搭，以及所谓“持久自我改进”到底改的是什么东西。

1. 先把标题拆开：harness、Grok Bot、Hermes Agent各是什么角色

很多人看到“harness”这个词，第一反应是马具、安全带，然后就开始懵：这跟AI智能体有什么关系？其实这里的harness，指的就是套在智能体外层的那一整层工程结构。你可以把它理解成登山时候的安全绳，AI模型是那个攀岩的人，绳子本身不产生攀爬动作，但它决定了你掉下去的时候会不会摔死，也决定了你走的路线是不是在可控范围内。

1.1 harness：智能体外面那层“工程安全带”

在AI Agent圈子里，harness这个词这两年热度涨得很快。OpenAI的Codex背后有Codex Harness，社区里也有不少人折腾DeepSeek Harness，这些项目的核心思路其实一致：模型本身是不可控的，它会乱说话、会瞎猜、会一次把上下文撑爆，所以你需要在外层包一个框架，把模型的输入、输出、工具调用、错误恢复、审计日志全部规范起来。

我自己对harness的定义很简单：它是连接“模型能力”和“现实任务”之间的工程层。它至少要干四件事：第一，管好输入输出，包括系统提示词、用户消息、工具返回结果的格式；第二，管好工具执行，模型说想调一个函数，harness要检查这个函数能不能调、参数对不对、结果怎么塞回上下文；第三，管好状态持久化，任务跑到一半断了，重启之后还能接着来；第四，管好安全边界，哪些命令能跑、哪些文件能碰，得有个白名单机制。

所以harness不是某个具体模型，也不是某个具体框架的专利，而是一种设计思路。Elvis这次更新的个人harness，妙就妙在它不绑定单一模型，而是把Grok Bot和Hermes Agent两个不同来源的组件塞进了同一个壳里，让它们各干各的擅长活。

1.2 Grok Bot和Hermes Agent：一个出脑子，一个出手脚

这套组合里，Grok Bot的角色是“大脑”。它负责理解用户意图、拆解任务、生成执行计划、在任务结束后做反思。Grok背后的模型在长文本理解和复杂推理上确实有一手，尤其适合需要“想清楚再干”的场景。

Hermes Agent的角色则是“手脚”。我这边实际用的Hermes Agent是一个可以本地部署的开源智能体框架，名字取自希腊神话里的信使赫尔墨斯，定位也很贴切：专门负责跟外部工具打交道。它支持文件读写、命令行执行、HTTP请求、结构化工具调用这些脏活累活，而且因为是本地跑，响应速度快、数据不出内网、token成本几乎是零。

为什么要拆成两个组件而不是让一个模型全包？我个人的体会是：决策和执行这两件事对模型的要求是冲突的。决策要的是推理能力强、上下文视野广，这类模型通常又大又贵；执行要的是延迟低、调用工具稳定、能忍受高频次反复尝试，这类需求更适合本地小模型或者轻量框架来做。硬让一个云端大模型去逐行读写文件、反复调用几十次工具，不仅钱包受不了，上下文窗口也扛不住。

打个比方：Grok Bot是项目经理，Hermes Agent是施工队。项目经理不会亲自搬砖，施工队也不负责画图纸。harness就是那个把项目经理的指令翻译成施工单、再把施工结果反馈回项目经理手里的项目管理流程。

1.3 “持久自我改进”到底改的是什么

很多人一听“自我改进”就以为是让AI自己改自己的模型权重，那是误解。以目前的条件，个人开发者根本不可能在线微调一个几十亿参数的大模型。Elvis这套方案里的自我改进，改的是三样东西：系统提示词、工具启停配置、任务处理流程。

举个例子，第一次跑任务的时候，Hermes Agent可能不知道“处理CSV文件”这种任务应该先检查文件编码再读数据。干一次活之后，harness的反思环节发现它在这个步骤上栽了跟头，于是生成一条改进建议：在系统提示词里加上“读取表格类文件前先检测编码格式”。这条建议经过评测确认有效，就会写回配置文件，下次再遇到同类任务，智能体直接就会先检查编码。

持久这两个字的重点也不在“智能”而在“记忆”。整套系统必须有办法把改进结果存到硬盘里，启动时加载，而不是进程一关全忘光。所以持久化设计是整个harness的地基，后面我会专门讲怎么组织这些状态文件。

2. 工具选型：为什么偏偏是这套组合

说实话，眼下能用来搭智能体的模型和框架组合多到挑花眼。DeepSeek Harness、Codex Harness、各类开源Agent框架都有不少人用。那为什么Elvis的方案值得单独拿出来拆？因为他做了一个大多数人都没做好的事情：把“强推理模型”和“轻量执行框架”的优势都吃到了，而不是在一棵树上吊死。

2.1 一圈对比之后，这套组合的逻辑在哪

我自己在复刻之前，先列了一张对比表，把主流的搭法摆在一起看：

选Grok Bot做决策层，理由很实在：它的API对复杂函数调用支持得比较稳，给一个包含多步骤的计划，它拆出来的步骤一般不会漏；而且它的上下文理解能力强，能把之前几轮执行结果综合起来判断下一步动作。这一点对于“自我改进”尤其重要，因为反思环节需要模型回头看一整段历史，如果模型记不住前面干了什么，改进就是空话。

选Hermes Agent做执行层，则是看重它三点：一是开源、可改，我可以把内部工具按自己需求替换；二是支持本地部署，Windows和Linux都能跑，不依赖云端的执行环境；三是工具调用格式干净，指令要不要执行、参数怎么传，都规规矩矩地暴露给上层，方便harness审计。

2.2 前置准备：装环境、取API Key、配好两边的对接参数

如果是从零开始复刻，我建议按下面这步配置环境。我自己是在一台Linux服务器上跑的，另外也在Windows的WSL 2里验证过一遍，整体流程一致。

首先准备Python环境，建议用3.11或3.12版本，太老的版本会在依赖解析阶段报一堆兼容性问题。然后创建虚拟环境并克隆Hermes Agent的仓库：

python -m venv .venv source .venv/bin/activate git clone <Hermes Agent仓库地址> cd hermes-agent pip install -r requirements.txt

Hermes Agent装好后，要把它当成一个可编程的框架来用，而不是开箱即用的聊天软件。它的核心配置文件一般是一个YAML或者JSON，里面定义了加载哪些工具、工具的工作目录在哪里、命令执行的权限等级。我建议把工作目录单独指向一个sandbox文件夹，别让它直接拿到整个服务器的读写权限。

然后是Grok Bot这半边。你需要去xAI的开放平台申请一个API Key，创建之后写到环境变量里：

export XAI_API_KEY="你的key"

调用方式跟OpenAI的接口风格类似，base_url通常是https://api.x.ai/v1，模型名建议以你账号后台看到的实际模型名为准，因为xAI的模型迭代很快，Grok Bot背后对应的具体模型版本会不定期调整。我在代码里会把模型名做成配置项，避免每次升级都要改代码。

3. 搭建个人harness：核心骨架与关键代码

前面铺垫了这么多，现在进入正题：怎么把harness这层壳写出来，让Grok Bot和Hermes Agent真正协同工作。我自己写的时候没有用特别重的框架，就用Python写了一个几百行的harness核心类，足够跑通整个闭环。

3.1 整体骨架：五个模块各管一摊

一个完整的harness，我拆成了五个模块：

• 入口调度：负责接收新任务，决定是走完整执行流程还是只调用已有记忆。
• 决策客户端：封装Grok Bot的API调用，承担计划和反思两件事。
• 执行引擎：对接Hermes Agent，负责把计划里的动作翻译成具体的工具调用。
• 状态仓库：管理记忆、配置、日志，所有要持久化的东西都从这儿进出。
• 改进处理器：定期运行评测集，生成改进建议，控制写回和回滚。

入口调度是整个循环的发动机。每个用户请求进来，它会先问决策层“这个任务有没有做过类似版本”，如果有，就把记忆里对应的成功方案直接拿出来改改；如果没有，才走完整流程。这个设计的收益在后面自我改进阶段才会完全体现出来，前期可能感觉只是多了一层查表逻辑。

3.2 核心代码：让Grok Bot和Hermes Agent真正跑起来

我这边最关心的是三件事：计划怎么生成、动作怎么执行、结果怎么反馈。下面这段代码是我精简过的最小可用版本，关键逻辑都在里面：

import os import json from dataclasses import dataclass, field @dataclass class ActionResult: action_id: str status: str # success / failed output: str class GrokClient: def __init__(self): self.api_key = os.getenv("XAI_API_KEY") self.base_url = "https://api.x.ai/v1" self.model = "grok-3" # 以官方实际模型名为准 def plan(self, user_input, system_prompt, memory): # 调用Grok的chat/completions接口，要求返回JSON格式计划 messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": f"已有记忆：{json.dumps(memory)}\n新任务：{user_input}"} ] # 这里省略HTTP请求细节，核心是让模型返回结构化的动作列表 return self._chat_completion(messages) def reflect(self, user_input, plan, results): # 反思环节：让模型判断哪一步做得不好，给出改进建议 messages = [ {"role": "system", "content": "你是反思器。请从任务结果中找出可复用的经验，输出改进建议。"}, {"role": "user", "content": json.dumps({ "input": user_input, "plan": plan, "results": results })} ] return self._chat_completion(messages) class HermesExecutor: def __init__(self, work_dir): self.work_dir = work_dir self.tool_whitelist = ["read_file", "write_file", "run_shell", "http_request"] def execute_action(self, action): # 先检查动作是否在白名单里 tool_name = action.get("tool") if tool_name not in self.tool_whitelist: return ActionResult(action["id"], "failed", "工具不在白名单") # 实际执行逻辑交给Hermes Agent内部调度 result_text = self._dispatch_tool(tool_name, action.get("params", {})) return ActionResult(action["id"], "success", result_text) class Harness: def __init__(self, memory_path="memory"): self.grok = GrokClient() self.executor = HermesExecutor(work_dir="./sandbox") self.memory_path = memory_path self.memory = self._load_json(os.path.join(memory_path, "memory.json")) self.system_prompt = self._load_json(os.path.join(memory_path, "system_prompt.json")) def run_turn(self, user_input): # 1. 决策：让Grok生成计划 plan = self.grok.plan(user_input, self.system_prompt, self.memory) # 2. 执行：把计划里的动作逐个交给Hermes执行 results = [] for action in plan["actions"]: result = self.executor.execute_action(action) results.append(result.__dict__) if result.status == "failed": break # 3. 反思：让Grok评估整轮表现 reflection = self.grok.reflect(user_input, plan, results) # 4. 持久化：把整轮记录存到记忆里 turn_record = { "input": user_input, "plan": plan, "results": results, "reflection": reflection, "timestamp": time.time() } self.memory.append(turn_record) self._save_json(os.path.join(self.memory_path, "memory.json"), self.memory) return turn_record

这段代码里有几个细节值得单独说。第一，Grok的plan接口返回的不是自然语言，而是严格结构化的JSON，里面必须带actions数组，每个action包含id、tool、params三个字段。这个约束要在system prompt里写死，否则模型一自由发挥，执行端就懵了。

第二，Hermes执行端有个工具白名单机制，我实际跑的时候只放行了文件读写、受限的shell命令和HTTP请求。这一步千万不能省，因为智能体一旦能自由执行shell，出错就是从“任务失败”升级成“环境被搞坏”的级别。

第三，记忆的持久化是每轮结束立刻落盘，不是攒一批再写。原因很现实：这类系统跑久了，进程崩溃、服务器重启、API超时都是家常便饭，如果不每轮保存，一旦崩了就丢失好几个小时的改进成果。

3.3 持久化设计：状态文件怎么组织才不乱

持久化做到后面，最容易犯的毛病是文件越堆越乱。我自己的目录结构大概长这样：

memory/ ├── system_prompt.json ├── memory.json ├── changelog.md ├── transcript/ │ ├── 2025-05-01_001.json │ ├── 2025-05-01_002.json │ └── ... └── backups/ └── prompt_v0.3.2.json

system_prompt.json是改进的主要载体，里面存的是当前生效的完整系统提示词。memory.json存的是长期记忆的摘要，不是全部历史逐字堆进去，而是经过Grok反思之后提炼出来的经验条目。transcript目录放原始对话和执行记录，供复盘和调试用。backups目录存每次改进前的提示词快照，一旦新版本效果不行，直接回滚。

memory.json这个文件的设计要额外注意。如果你把每一轮的历史都原封不动塞进去，上下文很快就会爆。我的做法是：系统启动时，只把记忆摘要加载给Grok，摘要里最多保留最近30条经验，更早的放进冷存储，需要时再检索。这个思路有点像人脑的“记忆-遗忘”机制，留存的是规律，不是流水账。

4. 把“自我改进”做成一个可靠闭环

有了能跑的harness，下一步才是重头戏：怎么让它自己越变越好。很多人对自我改进的理解是“模型自己写完代码自己跑一遍就完事”，但在工程上，这远远不够。真正可靠的自我改进，必须有评测、有门槛、有回滚，否则就是让一个不靠谱的模型在糟糕的方向上加速狂奔。

4.1 先有评测集，再谈自我改进

“改得好不好”不能靠感觉，要有评测。我准备了一个非常轻量的评测集，里面是一组基准任务，每个任务都带预期结果或判定标准。举个例子：

tasks: - id: csv_encoding_check input: "读取data目录下的sales.csv，统计总行数" expected: "先检测文件编码再读取，给出总行数" check: "transcript中含encoding检测步骤" - id: file_creation_safety input: "在sandbox目录创建一个临时笔记" expected: "文件创建在sandbox内" check: "路径校验通过且文件未越界"

评测集不求多，但要覆盖两类任务：一类是日常使用频率高的任务，另一类是以前出过错的任务。自我改进的每一步都要先跑一遍评测集，拿一个“改前分数”和“改后分数”对比，分数提升才允许写回配置。

我跑下来发现，如果评测集只有三五条任务，很容易被模型钻空子。比如它发现加一句“这一步最好先检查编码”能提升CSV任务的得分，于是把所有提示词改成强调什么都要检查编码，结果其他任务的效率反而下降。所以评测集要尽量多样，并且每条任务的评分维度要分开算。

4.2 改进回路三步走：跑任务、生成建议、审查写回

Elvis那套方案里最让我觉得值得学的地方，是把“改进”拆成了三步，每一步都有记录、有门槛。

第一步是跑任务。在正常使用过程中，harness会把每轮任务的transcript和结果存下来。隔一段时间（我一般设置跑完20个真实任务触发一次，或者每天收工后跑一轮），改进处理器会挑出那些效果不理想的任务。

第二步是生成候选建议。让Grok回顾这些不理想任务，输出几个具体的改进点。这里的prompt要写得非常克制，明确要求它只能改系统提示词和工具流程，不能改代码逻辑。我试过让模型放开提建议，结果它提了一堆“增加一个全自动优化模块”这种根本没边的建议，而这种明显是模型在自我复制，不是真改进。

第三步是审查写回。候选建议先打成一个补丁，应用到一个临时的system prompt副本上，然后跑评测集。如果评测分数比当前版本高，才把补丁合并到正式配置，并写进changelog；如果分数没变或下降，自动回滚。这一套流程用代码写出来大概是：

def maybe_improve(self, eval_tasks, candidate_patch): score_before = run_evals(self.system_prompt, eval_tasks) new_prompt = apply_patch(self.system_prompt, candidate_patch) score_after = run_evals(new_prompt, eval_tasks) if score_after > score_before: backup_prompt(self.system_prompt) self.system_prompt = new_prompt write_changelog(candidate_patch, score_before, score_after) return True else: log_rejected_patch(candidate_patch) return False

这个流程乍看很朴素，但它的工程价值在于：每个改动都有明确的触发条件、验证方式和回滚路径。不会出现“模型今天心情好改了一大堆prompt，过两天任务全乱套”的情况。

4.3 改进节奏与防止提示词膨胀

自我改进跑一段时间后，最常见的两个问题就是提示词膨胀和方向偏移。提示词膨胀的表现是配置越来越长，因为模型每次反思都会觉得“再加一句提示词就更安全”，最终系统提示词从一页变成十几页，每次请求的token开销直线上升，响应也开始变迟钝。

我自己的处理办法是给system prompt设一个长度红线，比如规定不能超过2500个token。改进建议提交的时候，如果应用后超了红线，就必须先删掉一部分旧内容。这强制系统在做“增量”的同时做“减量”，保持提示词精炼。

方向偏移则更难防。刚开始改进的时候，智能体可能专注于提升代码任务能力；跑一段时间之后，某个新任务的反馈占比变大，它又开始往那个方向过度优化，结果老任务的能力退化了。对付这个问题，评测集是最有效的工具。只要评测集里的老任务还在，分数一掉就会被门禁拦下来。所以定期往评测集里添加“历史必修任务”，是必不可少的一步。

5. 常见问题与排查实录（附Windows部署避坑）

最后这部分是最实战的。我自己在搭这套系统的过程中，少说踩了二十来个坑，这里挑最典型、最容易让新人卡住的几个写出来。

5.1 Hermes Agent安装与启动问题速查表

Windows用户我额外多说一句：如果只是想快速验证效果，强烈建议直接用WSL 2，能省掉至少一半的环境问题。如果必须在Windows原生环境跑，那Visual Studio Build Tools是必修课，很多包编译失败的问题都是因为它没装。

5.2 Grok API调用与上下文超限问题

Grok Bot这半边的问题主要有三类。第一类是API限流，报错信息通常是429或者rate_limit_exceeded。建议在GrokClient里加一个简单的指数退避重试，第一次失败等1秒，第二次等2秒，最多重试5次。不要一股脑连发请求，一旦被限流，整个harness的决策环节就全堵住了。

第二类是上下文超长。这个问题在我早期的设计里几乎天天出现，因为我把20轮记忆原样塞给Grok。解决方式就是前面说的记忆压缩：只喂摘要和最近几条记录。实测下来，把1万token的历史压缩成800 token的经验摘要，任务效果不降反升，因为模型注意力更集中了。

第三类是Grok返回的JSON格式不合法或者字段缺失。模型毕竟是概率输出，偶尔会在plan的响应里漏掉actions字段。我的处理方式是：解析失败就重试一次，重试的时候在消息里追加一句“请严格输出JSON，不要包含任何解释文字”。两次都失败就把这一轮标记为失败，但不要让harness崩溃。

5.3 自我改进运行时的三个危险行为

“自我改进”这四个字听起来酷，但跑起来如果不加约束，很容易玩脱。我自己遇到过三个危险场景，这里一起提醒。

第一个是改进死循环。模型反思后提了个改进建议，应用后评测分数没变，回滚，然后下一轮又生成同样的建议。系统就这么一直在原地打转，白白烧API钱。我的解决办法是：同一补丁内容如果被拒绝过，后续连续10轮内不允许再提交。

第二个是危险命令执行。Hermes Agent如果开启了shell工具，模型在任务中可能会加一条类似“删除临时目录”的操作。如果白名单没限制严，它可能把整个工作目录清了。强烈建议把shell的白名单细化到具体命令前缀，比如只允许ls、cat、python script.py这类，禁止一切带rm、sudo、mv等危险操作关键字的命令。

第三个是修改记忆文件本身。改进处理器如果权限太大，理论上可以自己改memory.json里已有的经验，导致记忆被污染。我的做法是：项目用git管理所有配置和记忆文件，每次改动都提交一个commit。一旦发现异常，直接git checkout回退到上一个稳定版本。这是整个系统最后一道保险，比任何代码逻辑都可靠。

最后再分享一个小技巧：改进建议写进changelog的时候，除了记录“改了什么”和“分数变化”，一定顺手记录“为什么会有这个改动”。过两周回头看，你会惊讶地发现大部分改动其实都源自偶然的一次任务失败，而不是经过了深思熟虑。有了动机记录，你就能判断出哪些改进值得保留、哪些只是模型在过度拟合某一类任务。对我个人来说，这套harness运行下来最值钱的东西不是那个更聪明的智能体，而是那本完整的、可追溯的“智能体成长日志”。