夜雨聆风
AI Agent架构新范式——从对话助手到自治智能体
AI Agent架构新范式——从对话助手到自治智能体
小李的周一早晨
周一早上8点47分，小李的Slack、Telegram和终端窗口同时亮起。作为一名全栈开发者，他正同时推进三个项目：为客户搭建的加密货币交易助手、内部数据分析pipeline、还有一个跨平台客服机器人。三个月前，他像大多数人一样把ChatGPT当成”超级搜索引擎”——每次提问都精雕细琢prompt，每次对话结束，上下文就归零。上周部署的Hermes Agent和这周试用的IronClaw，正在改变这种工作方式。
Hermes在凌晨3点自动归档了交易助手的异常日志，并在MEMORY.md里记下了新的排错模式。IronClaw则把客服机器人的工具调用锁在了WASM沙箱里，即使prompt注入攻击成功，攻击者也摸不到数据库连接串。小李发现这两个Agent不只是回答问题——它们在持续改变工作方式本身。这背后是AI Agent领域一场静悄悄的范式转移：从”对话式助手”到”自治智能体”。
为什么现有的AI助手不够用
传统大语言模型（Large Language Model, LLM）有三道难以逾越的结构性壁垒。
第一道是无状态（Stateless）。每次API调用都是独立的 HTTP 请求，服务端不保留任何对话上下文。ChatGPT的”记忆”不过是客户端把历史消息拼接进请求体里伪造出来的幻觉。一旦开启新会话，所有累积的上下文灰飞烟灭。小李上周让ChatGPT分析了交易助手的日志格式，这周换个窗口再问，模型一脸茫然。
第二道是无持久记忆（No Persistent Memory）。LLM没有文件系统，没有数据库，不能写入只能读取（而且读的还是开发者在prompt里塞进去的文本）。这意味着Agent无法跨会话学习，无法积累经验，更无法形成对特定用户或项目的深度理解。每次对话从零开始，就像一位记忆力为零的医生，每次见到同一个病人都要重新询问过敏史。
第三道是无进化能力（No Evolution）。模型的知识在训练结束时就被冻结，后续的fine-tuning成本高昂且操作复杂。普通开发者几乎不可能让模型”越用越聪明”。prompt engineering的优化成果无法沉淀，下一次升级模型版本，所有精心调教的技巧可能一夜归零。
这三道壁垒催生了一个尴尬的现实：LLM是出色的通用推理引擎，却是糟糕的长期合作伙伴。你需要它记住项目规范？塞到prompt里。需要它理解代码库的特定风格？每次都要重新解释。这种”一次性交互”的模式，在企业级应用场景中很快触碰到天花板。
Agent框架（Agent Framework）应运而生。它不是取代LLM，而是在LLM之上构建一层运行时基础设施——持久记忆、工具调用、任务调度、安全防护——让LLM从”聪明的对话者”进化为”可靠的执行者”。
Agent框架的演进光谱
理解Agent框架的演进，需要回望这条并不漫长但密度极高的发展轨迹。
第一代：对话式LLM（2022-2023）。ChatGPT、Claude、Gemini。核心能力是文本生成，交互模式是问答。用户负责提供完整的上下文，模型负责给出尽可能好的回答。没有工具调用，没有记忆持久化，没有任务执行。
第二代：增强型对话（2024）。Claude Code、ChatGPT with Plugins。模型获得了调用外部工具的能力——搜索网页、执行代码、读取文件。但记忆仍然停留在会话级别，工具调用是手动配置而非自动发现，Agent没有”自主性”。
第三代：自治Agent框架（2025-2026）。这是当前的主战场。OpenClaw率先定义了”Agent运行时”的概念：持久记忆、多平台网关、工具注册表、技能系统。随后分化出两个方向——广度与深度。
Hermes Agent选择了广度。它的定位标语直击痛点：”The agent that grows with you”。这不是修辞，而是工程承诺。通过自我进化循环（GEPA, Generative Prompt Auto-tuning），Hermes能在完成任务后自动生成技能文档，这些技能会被索引并在后续会话中被自动调用。它在GitHub上收获了108K星标，30位核心贡献者维护着18个平台适配器和40余种内置工具。
IronClaw选择了深度。NEAR AI团队用Rust从零重写了OpenClaw，核心假设极为激进：”LLM必然会被攻破，架构必须在被攻破时限制爆炸半径”。WASM沙箱隔离、凭据边界注入、prompt注入检测——每一层都是硬边界。11.9K星标、127位贡献者、432+测试用例、~25,000行Rust代码。
两张画像，两种哲学。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tools/registry.py
|
src/tools/registry.rs
|
|
|
|
|
|
|
|
|
|
|
|
|
零CVE记录在Agent框架界堪称稀有动物。两个项目都做到了，但路径迥异：Hermes依赖Python生态的成熟安全实践和快速迭代修复；IronClaw则依靠Rust的编译期内存安全保证，从语言层面消除整类漏洞。
Hermes Agent：以记忆为核心的单体架构
打开Hermes的代码仓库，最醒目的文件是 run_agent.py——约12,155行，608KB。在Python项目中，单个文件承担如此体量并不常见。这不是技术债务的堆积，而是刻意的设计选择：一个 AIAgent 核心类统摄全局，所有子系统围绕它运转。
核心循环在 run_agent.py 中定义。它接收消息，构建系统提示（system prompt），调用LLM，解析工具调用，执行工具，将结果回注上下文，循环往复。所有平台——CLI、Telegram、Discord、Slack、WhatsApp——都复用同一个 AIAgent 实例。平台差异被隔离在各自的入口文件中，而不是渗透到核心逻辑里。
记忆系统采用三层架构。最底层是SQLite + FTS5（Full-Text Search version 5），负责会话存储和全文检索。中间层是 MEMORY.md 和 USER.md——两个Markdown文件，分别存储Agent的环境知识和用户画像。最上层是可选的外部记忆提供者（Honcho、Mem0等），通过 MemoryProvider 抽象基类接入。这种分层让记忆既能在本地高效运作，也能对接企业级记忆后端。
技能系统是Hermes最具辨识度的设计。完成复杂任务后，Agent会自动生成技能文档（skill document），保存到 ~/.hermes/skills/。下次遇到类似任务，工具发现阶段会索引这些文档并注入系统提示。技能采用开放的 agentskills.io 格式，可在不同Agent实例间迁移。这不是prompt缓存——是结构化的、可演进的知识沉淀。
提示构建器agent/prompt_builder.py（959行）按照严格的层次组装系统提示：SOUL.md人格定义 → 工具使用规则 → 记忆快照 → 技能索引 → 项目上下文文件 → 平台特定提示。每层可独立替换和测试，检测到prompt注入攻击时自动替换为 BLOCKED 标记而非静默丢弃。
这种架构的优势在于内聚性。所有核心逻辑在一个文件里，开发者能快速理解全貌。代价是 run_agent.py 成为了一个”上帝文件”，理解任何子系统都需要先理解核心循环。
IronClaw：以安全为信仰的分层架构
IronClaw走了另一条路。它的代码分布在 src/ 下的30多个模块中，6个独立crate构成工作空间（workspace）。这不是过度工程化，而是安全架构的必然要求：每个模块拥有最小权限，层与层之间通过显式接口通信。
Agent Loop 是IronClaw的心脏，位于 src/agent/ 目录下。它不直接执行工具调用，而是将任务路由给调度器（Scheduler），调度器再分配给工作线程（Worker）。这种间接层使得并行执行、任务取消和资源配额成为可能。
Router 负责意图分类（intent classification），将用户输入判别为命令、查询或任务。分类结果决定了后续处理路径——简单查询可能直接由缓存响应，复杂任务则进入完整的推理-执行循环。
工具注册表src/tools/registry.rs（1,756行，62.9KB）管理三种工具类型：内置工具（built-in）、MCP（Model Context Protocol）外部工具、WASM沙箱工具。注册表维护 PROTECTED_TOOL_NAMES 常量列表，防止动态注册的工具覆盖核心功能。这种三级分类比Hermes的二分（内置 + MCP）多了一层安全边界。
WASM沙箱是IronClaw安全架构的王牌。每个不可信工具运行在独立的WebAssembly容器中，拥有能力型权限（capability-based permissions）、端点白名单和严格资源限制。外部工具无法接触宿主机资源——除非被显式授权。沙箱运行时基于wasmtime，支持燃料计量（fuel metering）防止无限循环，每次执行使用全新实例消除状态复用攻击。
安全层贯穿整个架构，不是可选项而是默认行为。五层纵深防御：TLS 1.3加密通信 → 端点白名单与prompt注入检测 → AES-256-GCM加密凭据管理 → WASM沙箱隔离 → Docker容器隔离。LLM本身被视为不可信组件，安全不依赖模型的行为正确性。
IronClaw的架构选择反映了Rust社区的设计哲学：编译期保证优于运行时检查，显式依赖优于隐式全局状态，纵深防御优于单点信任。代价是更高的认知门槛——理解IronClaw需要同时掌握Rust的所有权模型、WASM运行时和Docker容器化。
关键差异：一体 versus 分层
两个项目的架构差异可以从三个维度审视。
代码组织。Hermes的核心是一个Python文件（run_agent.py12K行），IronClaw的核心是一个Rust目录（`src/agent/` 20+文件）。前者强调内聚性——打开一个文件就能读懂循环；后者强调隔离性——修改安全层不会波及Agent循环。两种选择都有代价：Hermes的”上帝文件”对新人不够友好，IronClaw的模块间跳转需要更多上下文切换。
工具执行模型。Hermes的工具在Python进程中直接运行，依赖OS级别的权限控制。IronClaw的工具默认在WASM沙箱中执行，不可信代码被隔离在能力型权限边界内。Hermes的路径更轻量，工具调用延迟低；IronClaw的路径更安全，即使工具被恶意控制，爆炸半径也被严格限制。
记忆哲学。Hermes使用SQLite + 文件系统（MEMORY.md / USER.md），强调简单性和可移植性——一个 ~/.hermes 目录就是全部状态。IronClaw使用PostgreSQL + pgvector，强调生产级持久化和向量检索能力——需要单独部署数据库服务，但支持混合全文+语义搜索（RRF算法）。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Agent架构的三条演进主线
Hermes和IronClaw代表了Agent架构演进的三条主线中的两条关键方向。
主线一：从状态less到状态ful——记忆持久化。LLM本质上是无状态的，但真正的智能需要记忆。不是把聊天记录拼接进prompt的那种假记忆，而是结构化的、可检索的、跨会话 persisted 的知识。Hermes的 MEMORY.md + SQLite方案和IronClaw的PostgreSQL + pgvector方案，是同一问题的两种工程实现：Agent必须记住你是谁、你在做什么、之前犯过什么错。这是从”工具”到”伙伴”的分水岭。
主线二：从静态到动态——自我进化。传统软件的能力在发布时就被固定，Agent框架打破了这一范式。Hermes的GEPA系统让Agent从任务经验中提炼技能，技能又反过来提升后续任务的执行质量。这是一个闭环：执行 → 反思 → 沉淀 → 复用。Agent不再是静态程序的容器，而是持续演化的认知系统。
主线三：从信任到验证——安全纵深防御。IronClaw将这一主线推到了极致。它的核心假设是：LLM会被攻破，工具会被滥用，prompt会被注入。安全不能依赖任何单一组件的正确性，必须在每一层设置硬边界。WASM沙箱、凭据边界注入、prompt注入检测——这些不是锦上添花，是Agent从”开发玩具”走向”生产工具”的必要条件。
三条主线交汇之处，是下一代Agent框架的形态：有记忆、能进化、默认安全。Hermes和IronClaw各自在不同方向上探索边界，它们的竞争与互补将定义2026年Agent基础设施的基准线。
这个系列的后续文章将深入每一个子系统——记忆架构的读写路径、技能系统的进化机制、WASM沙箱的实现细节、以及两个框架在生产环境中的真实表现。小李的旅程也还在继续：他的交易助手正在Hermes的技能系统里积累新的排错模式，而客服机器人的安全审计报告刚从IronClaw的TEE环境中生成。从对话助手到自治智能体，这场范式转移刚刚进入深水区。