夜雨聆风2025年，所有人都在讨论AI Agent能做什么。2026年，真正有趣的问题变成了：Agent能不能自己构建自己的工具链？
这不是一个思想实验。在过去三周里，我用自己的Agent框架Hermes做了一件事：让Agent自己设计、开发、迭代它的桌面客户端——HermesBuddy。从v1.0到v1.2.2，每一个版本的功能需求、代码实现、bug修复、版本规划，全部由Agent自己完成。我只负责提需求和验收。
这篇文章记录的不是Demo，是真实的生产工具链。我会完整拆解HermesBuddy的架构设计思路，包括模型路由层、桌面客户端、工作空间管理、Session Log等核心模块，以及在这个过程中Agent如何"自己写自己"的工程实践。
一、问题：Agent工具链的三个断层
在构建AI Agent的过程中，我发现现有工具链存在三个致命断层：
第一，模型层断层。市面上的Agent框架几乎都绑定单一模型供应商。OpenAI的Agents SDK绑定GPT，LangChain默认走OpenAI API。但现实中，火山引擎有coding plan套餐，阿里云有token plan套餐，本地还有LM Studio跑的开源模型。每个套餐都有配额限制，今天用完了明天才恢复。Agent框架没有能力在多个供应商之间自动切换——它们只会报错然后停下来。
第二，执行层断层。Agent的"大脑"跑在云服务器上，但用户真正需要操作的是本地文件系统——Windows上的项目代码、文档、配置文件。大多数Agent框架要么只能操作服务器文件系统（对用户不可见），要么通过复杂的远程桌面方案（延迟高、不稳定）。Agent需要一个可靠的方式从云端控制本地机器。
第三，演进层断层。这是最深层的问题。Agent框架本身是静态的——开发者写好代码、发布版本、用户升级。但Agent的使用场景是动态的：今天需要代码模式，明天需要设计模式，后天需要新的工具集成。框架本身没有能力感知这些需求变化并自我演进。
HermesBuddy的设计就是为了填平这三个断层。
二、架构总览：三层分离设计
HermesBuddy的架构可以概括为三层分离：Model Router（模型路由层）→ Hermes Agent（智能核心）→ HermesBuddy Desktop（桌面执行层）。
这三层各自独立运行，通过标准HTTP API连接。任何一层都可以独立替换、升级，不影响其他层。这是整个设计思路的核心——解耦。
先看整体数据流：
用户输入 → HermesBuddy(EXE/Windows)
→ server.js(代理层+Session Log)
→ Hermes Gateway(api_server:22122)
→ Model Router(localhost:8800)
→ 火山/阿里/本地LMS 自动选择
← Agent推理+工具调用
← SSE流式返回
← 渲染到聊天界面
Agent工具调用 → SSH到Windows → 本地文件操作
用户在Windows上打开HermesBuddy，输入任务。请求通过server.js代理层传到Hermes Gateway（运行在246服务器上），Gateway调用Model Router选择最佳模型，Agent推理后通过SSH回连Windows执行文件操作。整个过程对用户透明——他只看到一个聊天界面。
三、Model Router：模型供应商的自动调度器
Model Router是整个架构的第一个关键设计。它是一个运行在Hermes服务器上的FastAPI服务，监听8800端口，对外暴露OpenAI兼容的API接口。所有LLM调用都走这一个入口，Router内部管理多个供应商，自动处理配额耗尽、错误重试、模型切换。
核心设计思路是抽象模型名。Hermes配置中不写具体模型名，而是写一个抽象别名hermes-agent。Router收到请求后，内部按fallback链依次尝试：
hermes-agent → [
火山 ark-code-latest (priority=1)
阿里 qwen3.8-max (priority=2)
阿里 qwen3.8-max-preview (priority=2)
本地 LMS qwen3.6-35b-a3b (priority=99)
]
当火山返回429（配额耗尽），Router自动冷却火山5小时，立即切换到阿里。阿里也耗尽了？切到本地LM Studio。本地LM Studio没启动？Router通过SSH远程到Windows机器自动拉起LM Studio服务，然后重试请求。
这里有三个关键的工程设计：
第一，model级冷却而非provider级。一个provider下可能有多个模型，某个模型429了不应该连累同provider的其他模型。State使用provider/model复合键，精确到模型粒度。比如qwenplan/qwen3.8-max冷却了，qwenplan/qwen3.8-max-preview仍然可用。
第二，探测恢复机制。配额冷却不是死等。后台线程每5分钟对冷却中的provider发一个轻量探测请求（max_tokens=8的"hi"），如果成功就立即清除冷却。这解决了用户升级套餐后额度提前恢复但Router还在傻等的经典问题——从24小时死等缩短到5分钟内自动恢复。
第三，全链路冷却时的强制探测。当整条fallback链都在冷却时，Router不会直接返回失败，而是按冷却剩余时间排序，强制尝试最快恢复的那个provider。这应对的是"升级套餐后所有provider同时恢复"的场景——不用等冷却到期，立即试一次。
Router的响应中统一返回hermes-agent作为model字段，不管实际调用的是火山还是阿里还是本地模型。Hermes Agent完全无感知——它不知道也不需要知道请求被路由到了哪个供应商。这就是抽象层的价值：切换供应商时，Agent零修改。
四、HermesBuddy Desktop：从云端到桌面的执行桥梁
HermesBuddy Desktop是一个Electron应用，运行在用户的Windows机器上。它的核心职责不是"另一个聊天界面"，而是打通云端Agent和本地文件系统的执行链路。
架构上，EXE内嵌一个本地HTTP服务（127.0.0.1:18700），有两个路由前缀：
/hb-api/* → 246:22122 (win profile gateway)
/api/* → 246:8700 (workbuddy server)
/hb-api/*走的是win profile的Hermes Gateway——一个独立配置了SSH terminal backend的Gateway实例。这个Gateway的terminal工具不是在服务器上执行命令，而是通过SSH回连到用户的Windows机器（192.168.0.138）执行。Agent调用terminal("dir C:\\Users\\hermes\\projects")，实际在用户的Windows上运行。
/api/*走的是workbuddy server——一个Node.js服务层，负责静态文件托管、API代理、密钥注入、Session Log记录。浏览器永远不接触API密钥，所有认证在服务端完成。
这个设计解决了一个关键问题：Hermes的服务器端工具不能直接操作Windows文件系统。通过SSH terminal backend，Agent的每一次文件读写、命令执行都落在用户的真实工作环境中。用户选择一个工作空间文件夹，Agent就在那个目录里工作——创建文件、修改代码、运行脚本，全部是真实的本地操作。
五、工作空间：权限与模式的上下文注入
工作空间管理是HermesBuddy v1.2.2的核心新功能。每个工作空间是一个Windows本地目录，用户可以配置权限级别和工作模式。
权限分三级：只读（read）、读写（read-write）、完全访问（full）。只读模式下，system_message明确告知Agent"禁止修改、创建或删除任何文件"。完全访问模式下，Agent可以执行包括删除在内的所有操作。
模式分三种：日常办公（office）、代码开发（dev）、设计创意（design）。每种模式对应不同的system prompt注入，引导Agent采用不同的工作方式。dev模式强调"最佳编程实践"，design模式侧重"创意发想和UI/UX设计"。
这些配置不只是一个UI选择——它们被注入到每次请求的system_message字段中，Agent在每次对话时都能感知当前的工作上下文：
用户当前的工作空间是: C:\Projects\myapp
权限级别: read-write - 可读取和修改文件
工作模式: dev - 代码编写、调试、测试
所有操作通过 terminal 在此目录执行
这个设计的核心理念是：Agent的上下文应该由用户的真实工作环境决定，而不是由一个静态的system prompt决定。用户切换工作空间，Agent的工作方式就跟着变——从只读到可写，从办公到开发，全部动态。
六、Session Log：事件溯源的执行轨迹
v1.2.2引入了Session Log——每次对话的完整事件流以JSONL格式持久化到~/.hermes/sessions/{session_id}.jsonl。这不是简单的聊天记录，而是事件溯源（Event Sourcing）模式。
每个事件包含时间戳、事件类型、请求内容、响应状态、模型选择、工作空间路径等元数据。通过这些事件，可以完整重建任意一次对话的执行过程：用户说了什么、Agent用了哪个模型、调用了哪些工具、花了多长时间。
{"ts":1786804629,"type":"chat_request",
"user_message":"修复login bug",
"model":"hermes-agent",
"workdir":"C:\\Projects\\myapp"}
{"ts":1786804635,"type":"chat_response",
"status":200,
"preview":"已修复..."}
Session Log的价值在于可追溯性。当Agent做了一件出乎意料的事，你不需要猜——翻Session Log就能看到完整决策链。这也为未来的"结晶"系统（从历史对话中提取可复用的操作规则）提供了原始数据。
七、日志系统：分级与轮转
v1.2.2同时引入了结构化日志系统。所有操作按四个级别记录：debug、info、warn、error。日志写入~/.hermes/logs/workbuddy.log，超过2MB自动轮转为.old文件。
日志和Session Log的区别是：Session Log记录用户对话事件，日志记录系统运行状态。Session Log回答"发生了什么"，日志回答"为什么发生"。当Agent返回了空回复，Session Log看到的是"chat_response status=200 preview=''"，日志看到的是"volcengine-coding 5h quota exhausted, cooling 5h, fallback to qwenplan"。
两个数据源配合，任何异常都能快速定位根因。前端还提供了日志查看器，用户可以直接在HermesBuddy界面里查看系统日志和Session Log，不需要SSH到服务器翻文件。
八、Agent自己写Agent：自演进的工程实践
现在回到最初的问题：Agent能不能自己构建自己的工具链？
在HermesBuddy的开发过程中，我的角色是产品经理+验收者，Agent的角色是全栈工程师。整个开发流程是这样的：
我提出需求，比如"工作空间需要支持权限设置"或者"Model Router火山额度到了没有自动切换，修一下"。Agent收到需求后，自己分析代码、定位问题、编写修复代码、运行测试、提交commit。我验收后提下一个需求。
从v1.0到v1.2.2的12次commit，全部由Agent完成。包括：
工作空间文件夹选择对话框（3f9a740）——Agent自己发现了文本输入框不如系统文件夹选择器好用，主动建议改。工作空间管理页面（bfef528）——Agent参考了WorkBuddy的UI设计，自己实现了完整的工作空间列表、搜索、权限标签。三个关键bug修复（710fd0a）——dialog未解构、app.js语法错误、模态框按钮缺失，Agent自己诊断、自己修。workdir注入system_message（07ad6bb）——Agent发现api_server不处理workdir字段，自己想出了通过system_message注入的方案。
Model Router的迭代更典型。最初版本只有简单的429检测。我反馈"火山额度到了没自动切换"，Agent分析日志发现AccountOverdueError没被识别为配额错误，修复了is_quota_error函数。我反馈"qwen升级套餐后还在冷却"，Agent加了探测恢复机制。我要求"全冷却时切本地LMS"，Agent加了fallback链和远程唤醒脚本。
每一次迭代都是：人类反馈→Agent分析→Agent修复→人类验收→下一个反馈。这个过程本身就是一种Agent自演进——不是Agent自己改自己的代码（那需要更高的自主性），而是Agent作为开发工具，被人类用自然语言驱动着迭代自己的工具链。
九、设计哲学：抽象、解耦、可观测
回顾HermesBuddy的整体设计，有三条贯穿始终的哲学：
第一，用抽象层解决多后端路由。Model Router暴露hermes-agent抽象模型名，内部自动映射实际供应商。切换供应商时Hermes零修改。这是工程模式的胜利——不hack改字段，而是抽象一个新模型名，让切换对调用方透明。
第二，三层分离，各自独立。Model Router、Hermes Agent、HermesBuddy Desktop各自独立运行，通过HTTP API连接。Model Router重启不影响Gateway，Gateway重启不影响Desktop。每一层都可以独立迭代、独立部署。
第三，一切可观测。Session Log记录用户对话事件，日志系统记录系统运行状态，Model Router的/health和/stats端点实时展示供应商健康度和请求统计。当系统出问题时，不需要猜——每一个决策、每一次切换、每一个错误都有据可查。
十、总结与展望
HermesBuddy不是一个Demo，是一个每天在用的生产工具。它的每一次迭代都来自真实使用中遇到的问题——Model Router的自动切换是因为火山额度真的会用完，工作空间权限是因为Agent真的会误删文件，Session Log是因为Agent真的会做出出乎意料的事需要追溯。
"Agent自己写自己的工具链"不是一个未来愿景，它已经发生了。只是当前的形式是人类用自然语言驱动Agent迭代，而不是Agent完全自主地决定"我要加一个新功能"。但这个距离正在快速缩小。
下一步的方向是明确的：更深度的自演进——Agent从Session Log中学习常见的用户操作模式，自动生成新的工作流；更强的本地执行——不只是文件操作，还包括本地应用的自动化控制；更智能的模型路由——不只是配额切换，还包括根据任务类型自动选择最合适的模型（代码任务走coding模型，创意任务走更大参数的模型）。
Agent的下一个版本，真的是它自己写的。
关注AI Agent架构、记忆系统设计、LLM推理工程