← 返回文章一览
技术笔记

AI Agent 工作原理深度解析 — 以 Hermes Agent 为例

AIAgentHermes架构源码分析对比

AI Agent 工作原理深度解析 — 以 Hermes Agent 为例

从 ReAct 循环到工具系统，从记忆到多 Agent 协作，用一款真实开源框架讲清楚 AI Agent 到底怎么工作的。

🎬 一、开篇：当 Chatbot 变成 Agent

假设你跟你的 AI 助手说：

“帮我查一下东京下周的天气预报，把结果存到 Obsidian 笔记里，然后发封邮件告诉我同事。”

如果这是一个传统 Chatbot，它会回答你：“好的，我建议你查一下天气网站，然后用 Obsidian 的手动功能记下来，再到邮箱里发邮件。“——它只能说，不能做。

但如果这是一个 AI Agent，它会：

  1. 用浏览器打开天气网站 → 查到东京下周的天气
  2. 用文件工具在 Obsidian vault 创建一篇 Markdown 笔记
  3. 调用邮件客户端发送总结邮件

整个过程不需要你碰一下键盘。

这就是 AI Agent 和 Chatbot 的根本区别：Chatbot 回答问题，Agent 执行任务。它不再只是语言模型——它是一个能调用工具、操作环境、自主决策的数字员工。

那么，一个 AI Agent 内部到底是怎么工作的？是什么机制让语言模型从”会说话”变成了”会干事”？

这篇文章用 Hermes Agent（一个完全开源的生产级 AI Agent 框架）作为解剖样本，一步步拆解 Agent 的核心原理。Hermes 由 Nous Research 开发，它支持 20+ 模型提供商、运行在 CLI / Telegram / Discord / Feishu 等 20+ 平台上、有持久化记忆和自进化技能系统——用来理解 AI Agent 的架构再合适不过。

Hermes Agent 系统架构总览 ▲ Hermes Agent 完整系统架构：接入层 → 核心层 → 能力层 → 模型层，四层分离设计

🧠 二、Agent 核心循环：Think → Act → Observe

2.1 ReAct 范式

所有现代 AI Agent 都建立在一个底层范式上：ReAct（Reasoning + Acting）。

2023 年，Shinn 和 Yao 等人发表了开创性的论文 ReAct: Synergizing Reasoning and Acting in Language Models，提出了一种思路：为什么不把 LLM 的推理（Reasoning）和行动（Acting）结合起来，而不是分开？

ReAct 的核心循环极其简洁：

Observe（观察环境/用户输入）
  → Think（推理，决定下一步做什么）
  → Act（调用工具采取行动）
  → Observe（观察工具返回的结果）
  → Think（根据新信息推理）
  → Act（继续行动或给出最终答案）
  → ...

这个循环持续进行，直到 Agent 判断任务完成（即不再需要调用工具，直接输出文本回复）。

2.2 Hermes 的主循环：run_conversation()

在 Hermes Agent 中，这个循环的实现位于 agent/conversation_loop.py，核心函数 run_conversation() 约 3900 行，是 Agent 的心脏。

简化后的伪代码：

def run_conversation(agent, user_message, conversation_history):
    # 1. 构建/恢复系统提示词（缓存的，会话内只构建一次）
    active_system_prompt = restore_or_build_system_prompt(agent)
    
    # 2. 准备消息列表（system + history + 当前用户消息）
    messages = build_messages(active_system_prompt, conversation_history, user_message)
    
    # 3. 主循环
    while api_call_count < max_iterations and iteration_budget.remaining > 0:
        
        # 3a. 调用 LLM
        response = call_llm(messages, tools=agent.tool_definitions)
        
        # 3b. 检查是否有工具调用
        if response.has_tool_calls():
            for tool_call in response.tool_calls:
                # 分配工具调用
                result = handle_function_call(
                    name=tool_call.function.name,
                    args=tool_call.function.arguments
                )
                # 把结果追加到消息列表
                messages.append({"role": "tool", 
                                  "content": result, 
                                  "tool_call_id": tool_call.id})
            # 继续循环，让 LLM 看到工具结果后决定下一步
            continue
        
        # 3c. 没有工具调用 → 输出最终回复，循环结束
        if response.has_text():
            final_response = response.text
            break
    
    return {"final_response": final_response, "messages": messages}

2.3 一次 Turn 的完整生命周期

当用户发送一条消息时，Agent 内部经历以下阶段：

阶段做了什么对应代码
Prologue消毒用户输入、恢复/构建系统提示词、加载记忆、预压缩检查build_turn_context()
LLM Call将 messages + tool definitions 发给 LLM APIcall_llm()
Parse解析 LLM 返回，区分是文本还是 tool_calls响应解析器
Dispatch如果是 tool_calls，逐个调用 handle_function_call()model_tools.py
Append将工具执行结果以 tool role 追加回消息列表循环体内
Repeat带着新消息继续调 LLM回到步骤 2
Return当 LLM 返回纯文本时，作为最终回复输出循环结束

2.4 迭代预算控制

Agent 不能在工具调用循环里无限跑下去。Hermes 有两层保护：

当循环耗尽时，Agent 会输出一个提示告知用户。

Agent ReAct 核心循环 ▲ 一次 Turn 的完整生命周期：Prologue → LLM 调用 → 决策循环 → 输出结果。橙色虚线框内是核心的 ReAct 循环。

🔧 三、工具系统：Agent 的双手

没有工具的 LLM 只能写作文。有了工具，它才能操作世界。工具系统是 Agent 架构中最关键的工程组件之一。

3.1 工具声明与注册

在 Hermes 中，每个工具都是一个独立的 Python 文件，通过 registry.register() 在模块级别自注册。

# tools/example_tool.py
from tools.registry import registry

def my_tool(param: str) -> str:
    return json.dumps({"result": f"处理了: {param}"})

registry.register(
    name="my_tool",
    toolset="example",
    schema={
        "name": "my_tool",
        "description": "这是一个示例工具",
        "parameters": {
            "type": "object",
            "properties": {
                "param": {"type": "string", "description": "输入参数"}
            },
            "required": ["param"]
        }
    },
    handler=lambda args, **kw: my_tool(param=args.get("param", "")),
    check_fn=lambda: True,  # 环境检查，不满足则不显示
    requires_env=["EXAMPLE_API_KEY"],  # 需要的环境变量
)

关键设计亮点：注册是声明式的，不需要在中央列表里手动添加工具。

tools/registry.py 中的 discover_builtin_tools() 函数会扫描 tools/ 目录下的所有 .py 文件，通过 AST 静态分析（不是 import 执行！）判断文件是否包含顶层的 registry.register() 调用，然后才真正 import。

def discover_builtin_tools(tools_dir=None):
    for path in sorted(tools_path.glob("*.py")):
        source = path.read_text()
        tree = ast.parse(source)
        if any(is_registry_register_call(stmt) for stmt in tree.body):
            importlib.import_module(f"tools.{path.stem}")

💡 这意味着新增一个工具只需要写一个文件 + 一行 registry.register()，框架自动发现和加载。

3.2 ToolEntry 数据结构

注册后的工具被包装为 ToolEntry 对象：

class ToolEntry:
    __slots__ = (
        "name",          # 工具名，LLM 通过这个名字调用
        "toolset",       # 所属工具集（如 web, terminal, file）
        "schema",        # OpenAI Function Calling 格式的 JSON Schema
        "handler",       # 实际执行的函数
        "check_fn",      # 可用性检查函数
        "requires_env",  # 需要的环境变量列表
        "is_async",      # 是否异步
        "description",   # 人类可读描述
        "emoji",         # 显示用 emoji
    )

这个结构体在三个地方被使用：

  1. 生成 tool_definitions → 传给 LLM API 作为 tool schema
  2. 调度执行 → handle_function_call() 查找并调用 handler
  3. UI 展示 → hermes tools list 显示可用工具

3.3 工具调度流程

当 LLM 返回 tool_calls 时，model_tools.py 中的 handle_function_call() 负责调度：

LLM 返回: {function: "web_search", arguments: {query: "东京天气"}}
     │
     ▼
1. 参数类型强制转换 (coerce_tool_args)
   └─ 字符串 "42" → 整数 42（schema 一致性）
     │
     ▼
2. Tool Search Bridge 检查
   └─ 如果是 tool_search/tool_describe → 走目录查询路径
     │
     ▼
3. 安全中间件检查
   └─ pre_tool_call hook → 权限验证 → 命令审批
     │
     ▼
4. 调用 handler
   └─ 执行实际函数 → 返回 JSON 字符串
     │
     ▼
5. 结果限幅 (max_result_size_chars)
   └─ 防止超长结果撑爆上下文
     │
     ▼
6. post_tool_call hook
   └─ 审计日志、性能追踪

3.4 Toolset 分组管理

Hermes 的工具按功能分组为 toolsets，可以在配置中按需启用/禁用：

Toolset工具举例场景
webweb_search, web_extract信息检索
browserbrowser_navigate, browser_click网页交互
terminalterminal()执行 Shell 命令
fileread_file, write_file, patch文件操作
code_executionexecute_code沙箱 Python 执行
memorymemory()读写持久化记忆
delegationdelegate_task子代理分发
cronjobcronjob()定时任务管理

每个工具集中包含的工具只有在满足条件时才会暴露给 LLM，通过 check_fn 实现：

# 只有设置了 OPENROUTER_API_KEY，web_search 工具才可见
def check_requirements() -> bool:
    return bool(os.getenv("OPENROUTER_API_KEY"))

3.5 与其他框架的对比

大多数 Agent 框架的工具系统都遵循 OpenAI Function Calling 格式的 schema，差别在于：

📝 四、系统提示词工程：Agent 的灵魂

系统提示词（System Prompt）是 Agent 大脑的操作系统。它告诉 LLM：你是谁、你能用什么工具、你的可用资源是什么、你要遵守什么规则。

4.1 三层架构

Hermes 的 build_system_prompt_parts() 函数（位于 agent/system_prompt.py）将系统提示词拆为三层：

┌─────────────────────────────────────────────┐
│              Volatile（易变层）                │
│  - 记忆快照（当前会话的最新记忆）               │
│  - 用户画像信息                               │
│  - 时间戳（当前日期时间）                      │
├─────────────────────────────────────────────┤
│              Context（上下文层）               │
│  - AGENTS.md / .cursorrules 项目上下文文件     │
│  - 调用者附加的系统消息                        │
├─────────────────────────────────────────────┤
│              Stable（稳定层）                  │
│  - Agent 身份标识（SOUL.md 或默认身份）        │
│  - 工具使用指引                               │
│  - Skills 索引（当前加载的技能）               │
│  - 环境提示（OS、终端类型、平台）               │
│  - 模型族操作指导                             │
│  - 任务完成指引                               │
│  - 并行工具调用指引                           │
└─────────────────────────────────────────────┘

4.2 提示词缓存优化

这个三层结构的设计有一个核心目标——最大化前缀缓存命中率。

现代 LLM API（Anthropic、OpenAI 等）支持 Prompt Caching：如果上下文的开头部分与上一次请求相同，缓存命中可以节省 50-90% 的延迟和成本。

Hermes 的策略是：

def build_system_prompt(agent):
    """只在会话开始时或压缩后调用"""
    parts = build_system_prompt_parts(agent)
    return "\n\n".join([parts["stable"], parts["context"], parts["volatile"]])

def invalidate_system_prompt(agent):
    """压缩后调用，强制下次重建"""
    agent._cached_system_prompt = None
    agent._memory_store.load_from_disk()

4.3 分段注入的条件逻辑

不同工具的存在与否会影响系统提示词的内容：

if "memory" in agent.valid_tool_names:
    tool_guidance.append(MEMORY_GUIDANCE)    # 如何正确使用记忆工具
if "session_search" in agent.valid_tool_names:
    tool_guidance.append(SESSION_SEARCH_GUIDANCE)  # 如何搜索历史会话
if "skill_manage" in agent.valid_tool_names:
    tool_guidance.append(SKILLS_GUIDANCE)    # 如何管理技能

这样只会加载与当前可用工具相关的指引，避免冗余文本占用上下文窗口。

💾 五、记忆系统：跨会话的持续性

普通 Chatbot 每次对话都是”失忆”的——关了窗口，一切归零。Agent 需要记住你的偏好、你的项目结构、之前犯过的错误和积累的经验。

5.1 记忆架构

Hermes 的记忆系统是双轨制：

记忆存储 (SQLite / Honcho / Mem0 / ...)
├── memory（工具笔记）
│   └── 环境细节、工具使用技巧、项目约定
│   └── 示例："用户使用 pytest 测试，习惯用 -n 4 并行"
│
└── user（用户画像）
    └── 姓名、角色、偏好、风格
    └── 示例："用户是开发者，偏好 SwiftUI，中文沟通"

5.2 记忆的读写时机

记忆不是每次都重写的，而是有策略地管理：

5.3 后端可插拔

Hermes 支持多种记忆后端：

后端特点配置
内建 SQLite无需额外服务，零配置默认
Honcho多用户、知识图谱关联需 Honcho 插件
Mem0语义搜索、自动关联需 API key
Hindsight知识图谱 + 时间线需额外配置

这种可插拔设计使得记忆系统从”简单的键值存储”扩展到”关系图谱 + 语义搜索”。

📚 六、技能系统：Agent 的自我进化

如果说记忆是 Agent 的”短期 RAM”，技能就是它的”长期程序库”。这是 Hermes 与其他 Agent 框架最核心的区别之一。

6.1 什么是 Skill

Skill 是一个 SKILL.md 文件，结构为 YAML 前端元数据 + Markdown 正文：

---
name: systematic-debugging
description: 4 阶段根因调试方法
tags: [debugging, python, workflow]
version: 1.2.0
---

# 系统性调试

## 触发条件
当遇到 Bug 需要根因分析时：

## 步骤
1. **复现** — …
2. **隔离** — …
3. **根因** — …
4. **修复** — …

每个 Skill 包含：

6.2 Skills 的加载机制

加载流程：

  1. Hermes 在工具列表中发现 skill_manage 工具 → 在系统提示词中添加 Skills 使用指引
  2. 初始扫描：skills_list 检查所有可用 Skill → 构建为 <available_skills> 区块注入系统提示词
  3. 基于任务匹配：Agent 根据用户问题判断是否需要加载某个 Skill
  4. 主动加载：用户也可以 /skill <name> 手动加载

6.3 Skills 与记忆的区别

维度记忆 (Memory)技能 (Skill)
内容事实、偏好、配置流程、方法、最佳实践
结构短文本片段结构化 Markdown
生命周期Agent 自动管理用户/Agent 手动创建
作用域个人化信息通用化工作流
示例”用户用 pytest""如何调试 Python 内存泄漏”

6.4 自我改进循环

这是 Hermes 最有意思的特性——Agent 可以在工作中自我改进：

完成任务
  → 意识到这个流程有复用价值
  → 调用 skill_manage(action='create') 保存为 Skill
  → 下次遇到类似任务时自动加载
  → 发现问题/流程更新 → skill_manage(action='patch') 更新

🔀 七、任务委派与多 Agent 协作

不是所有任务都需要由主 Agent 亲自完成。有些任务适合并行处理，有些任务需要独立的环境。

7.1 delegate_task() 原理

Hermes 的 delegate_task 工具可以创建一个完全隔离的子 Agent：

主 Agent（当前会话）
  │
  ├── 任务 A → delegate_task()
  │   └── 子 Agent（独立会话 + 独立的 terminal + 独立的上下文）
  │       ├── Research 子任务
  │       └── 返回摘要报告
  │
  ├── 任务 B → delegate_task()
  │   └── 另一个子 Agent
  │       ├── 代码审查子任务
  │       └── 返回审查结果
  │
  └── 汇总两个子 Agent 的结果，输出给用户

子 Agent 的特点是：

7.2 使用场景

场景为什么用委派代码
并行调研同时搜索多个来源，不阻塞主流程delegate_task(goal="查论文A", ...)
独立代码审查审查期间不干扰主 Agent 的工作目录delegate_task(goal="审查PR diff")
耗时子任务子任务慢但可以不等待delegate_task(goal="跑完整测试套件")

7.3 多 Agent 模式的对比

⚡ 八、上下文管理

LLM 有上下文窗口限制——即使最新的 GPT-5.5 有 1M token 窗口，一个长时间运行的 Agent 也会触及天花板。上下文管理是 Agent 工程中必须解决的问题。

8.1 主动压缩

Hermes 的压缩策略是主动的——不是在溢出时才动作，而是提前检测：

每次 LLM 调用后：
  检查 token 使用量 → 估算剩余窗口
  ├─ 如果 < 阈值 → 不操作
  └─ 如果 > 阈值 → 触发压缩
       ├─ 保存当前对话历史
       ├─ 执行 compress_conversation()
       │  ├─ 精简工具调用结果（保留关键信息，去掉完整输出）
       │  ├─ 合并连续的 non-tool 轮次
       │  └─ 保留对话骨架
       ├─ 重建系统提示词（触发 _invalidate_system_prompt）
       └─ 输出 "[Context compressed]" 通知用户

8.2 被动恢复

当 API 返回 413 Payload Too Large 或上下文溢出错误时：

  1. Hermes 先检查是否开启了压缩（compression.enabled）
  2. 如果启用了 → 自动压缩历史后重试
  3. 如果禁用了 → 输出错误提示，让用户手动 /compress 或 /new

8.3 压缩 vs 截断

关键区别：压缩不是简单地从消息列表头部截断。截断会丢失早期的关键决策信息。Hermes 采用摘要+骨架模式：

压缩前：
  [用户] "写一个 FastAPI 用户管理模块"
  [助手] → tool_call: terminal("fastapi new ...")
  [工具] 返回: 完整输出 2000 行...
  [助手] → tool_call: write_file(...) → 返回: 成功
  [助手] "已完成，API 端点如下..."
  [用户] "加个 rate limiting"
  ...

压缩后：
  [用户] "写一个 FastAPI 用户管理模块"
  [助手] → tool_call: terminal("fastapi new ...")
  [工具] 返回: [已压缩 — 命令成功执行，耗时 3.2s]
  [助手] → tool_call: write_file(...) → 返回: 成功
  [助手] "已完成，API 端点如下..."
  [用户] "加个 rate limiting"
  ...

工具结果中的长输出被替换为摘要标签，但对话流程和关键决策保存在保留。

🌉 九、多平台网关

Agent 不一定要生活在终端里。Hermes 的 Gateway 架构让它能同时运行在多个平台。

9.1 Core + Adapter 架构

                        ┌──────────────┐
                        │  Agent Core  │
                        │  (LLM + 工具) │
                        └──────┬───────┘
                               │
                        ┌──────┴───────┐
                        │   Gateway    │
                        │   Router     │
                        └──────┬───────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
   ┌──────┴──────┐    ┌───────┴───────┐    ┌───────┴──────┐
   │  Telegram   │    │   Discord     │    │   Feishu     │
   │  Adapter    │    │   Adapter     │    │   Adapter    │
   └─────────────┘    └───────────────┘    └──────────────┘
          │                    │                    │
   Telegram API          Discord API           Feishu API

每个平台适配器负责：

  1. 连接管理：WebSocket / Webhook 长连接
  2. 消息转换：平台特有格式 ↔ 标准消息格式
  3. 媒体处理：图片、语音、文件的转换
  4. 平台特性适配：Markdown 支持度差异、交互限制

9.2 跨平台挑战

特性TelegramDiscordFeishuCLI
Markdown 表格✅✅❌✅
内联代码✅✅✅✅
长消息截断4096 字符2000 字符无限制无限制
交互按钮✅✅✅❌
语音消息✅❌✅❌
图片✅✅✅✅

一个 Agent 核心需要在适配层处理所有这些差异，但对上层 LLM 调用而言，它看到的只是统一的消息接口。

9.3 平台支持的广度

截至 2026 年中，Hermes Gateway 支持 20+ 平台：Telegram、Discord、Slack、WhatsApp、Signal、Email、SMS、Matrix、Mattermost、Home Assistant、钉钉、飞书、企业微信、iMessage、微信、API Server、Webhooks 等。

这是 Hermes 区别于其他 Agent 框架的显著优势——大多数框架只聚焦于 CLI 或单一平台。

⚔️ 十、主流 AI Agent 横向对比

理解了 Agent 的工作原理后，我们来比较一下 2026 年主流的四款 Agent 框架：Hermes Agent、Claude Code、OpenAI Codex 和 OpenClaw。

10.1 总览对比

维度🏠 Hermes Agent🌀 Claude Code⚡ OpenAI Codex🌐 OpenClaw
开源性✅ MIT 开源❌ 闭源✅ Apache 2.0✅ 开源
核心语言PythonTypeScriptRustTypeScript
模型锁定❌ 无绑定（20+ Provider）✅ 仅 Claude 模型✅ 仅 OpenAI 模型❌ 多 Provider
模型灵活度⭐⭐⭐⭐⭐ 任意切换⭐⭐ Claude 独占⭐⭐ OpenAI 独占⭐⭐⭐⭐ 多 Provider
代码能力⭐⭐⭐ 通用 Agent⭐⭐⭐⭐⭐ 顶级编码⭐⭐⭐⭐⭐ 顶级编码⭐⭐⭐ 通用 Agent
多平台⭐⭐⭐⭐⭐ 20+ 平台⭐ 仅 CLI⭐⭐ CLI + 桌面 App⭐⭐⭐⭐⭐ 多 Channel
记忆持久化✅ 内建 SQLite + 外部❌ 无✅ 有✅ 有
技能/自进化✅ 成熟（核心特性）❌ 无✅ Skills（较新）✅ Skills
子代理✅ delegate_task✅ Sub-agents✅ Multi-agent v2✅ 多 Agent 原生
沙箱安全⚠️ 权限审查✅ 内建安全✅ OS 级 Seatbelt/Landlock⚠️ 权限策略
定时任务✅ Cron 内建❌❌❌
Webhook✅❌❌✅
多 Profile✅❌✅✅
MCP 支持✅ 原生✅✅✅
社区⭐⭐ 建设中⭐⭐⭐⭐ 大厂驱动⭐⭐⭐⭐⭐ 97K+ Stars⭐⭐⭐ 增长中
安装复杂度⭐⭐⭐⭐⭐ 极简⭐⭐⭐⭐ 简单⭐⭐⭐⭐ 简单⭐⭐⭐ 需指导

10.2 深度分析：每家之长短

🏠 Hermes Agent — 瑞士军刀

核心定位：通用 AI Agent 框架，不绑定任何模型，可部署到任何平台。

优势：

劣势：

最佳场景：个人助手、多平台自动化、研究分析、知识管理、需要长期记忆和技能积累的场景。

🌀 Claude Code — 代码专家

核心定位：终端原生编码 Agent，Anthropic 出品，Claude 模型独占。

优势：

劣势：

社区反馈：2026 年初的配额缩减（约 20 prompt 耗尽 5h 额度）引发了大量 GitHub Issue 投诉，用户反映”完成一个完整功能都困难”。Claude Code 强在质量，弱在可用量。

最佳场景：单次深度代码任务、复杂重构、代码审查。不适合持续运行、多平台或在模型间灵活切换的场景。

⚡ OpenAI Codex — 安全优先的编码平台

核心定位：OpenAI 官方的终端编码 Agent，开源 Rust 实现。

优势：

劣势：

最佳场景：软件开发的完整工作流（编码、调试、审查、PR）、需要严格安全沙箱的环境、OpenAI 生态用户。

🌐 OpenClaw — 多 Agent 平台

核心定位：个人 AI 助手平台，Gateway 原生多 Agent 架构。

优势：

劣势：

最佳场景：多 Agent 协作环境、需要多平台收发消息的个人助理、Ops 运维场景。

10.3 选型建议

你的需求推荐框架理由
写代码、重构、修 bugClaude Code 或 Codex编码能力最强，专项优化
全平台个人助理（工作+生活）Hermes Agent多平台 + 记忆 + 技能 + 定时任务
需要严格安全沙箱OpenAI Codex内核级沙箱，无可匹敌
多 Agent Ops 平台OpenClawGateway 原生多 Agent 架构
不想被一个模型绑定Hermes Agent20+ Provider，随时切换
自动化定时任务Hermes Agent唯一内建 Cron + Webhook 的框架
轻量级单次编码任务Claude Code命令行一句话，即开即用
给团队用的 AI 平台OpenClaw多 Agent + 多 Channel + 权限管理

🔮 十一、总结与展望

11.1 Agent 的核心要素

通过解剖 Hermes Agent，我们看到了一个生产级 AI Agent 需要哪些组件：

  1. ReAct 循环 — Think → Act → Observe 的持续迭代
  2. 工具系统 — 将 LLM 与真实世界连接的自注册、自发现机制
  3. 系统提示词工程 — 缓存友好的三层架构，兼顾稳定性与时效性
  4. 持久化记忆 — 跨会话的知识沉淀
  5. 技能/过程知识 — Agent 的自我进化能力
  6. 委派与合作 — 多 Agent 并行工作
  7. 上下文管理 — 在有限的窗口内高效工作
  8. 多平台适配 — 一个核心，多渠道

11.2 当前局限

Agent 在实际生产中仍然面临一些没有完美解决的问题：

11.3 趋势与方向

展望未来 1-2 年，AI Agent 的几个明确方向：

文中涉及的 Hermes Agent 源码分析基于 NousResearch/hermes-agent 项目。核心循环代码在 agent/conversation_loop.py，工具注册在 tools/registry.py，系统提示词构建在 agent/system_prompt.py。

Footnotes

  1. Claude Code 配额限制相关讨论，详见 GitHub Issue #20767。不同使用模式下的实际限制可能不同。 ↩

相关文章

AI Agent 完全入门指南：从概念到主流方案
AIAgent入门LLM教程对比
AI 基础知识入门
AI入门LLMAgent教程机器学习
AI 缓存命中：推理中最被低估的指标
AILLM缓存Cache Hit推理优化成本控制

© 2026 9x9