用了一个月 Hermes Agent，从”听说过 MCP”到天天用，有些理解在实践中反复验证。不是什么新发现，就是三个层面的整理——模型怎么想、你怎么跟它说、它怎么干活。搞清楚这三层，市面上大部分 Agent 框架的设计思路就都能看懂了。
本文位置：这是 Agent 工程路线的总入口。读完这里，再看 Hermes 记忆 vs 技能：可视化全解指南 和 如何将Agent自动化任务的API成本降低60%，会更容易理解为什么“能干活”和“能低成本长期干活”是两回事。
一、模型层：自回归生成
1.1 本质还是和 LLM 一样的自回归
Agent 的”思考”过程和普通 LLM 没有区别——每次只看已经写出的内容，决定下一个字写什么。没有整体规划，是一步接一步地生成。
Hermes 做多步分析时表现得很直观：它先抛结论，再展开，再深入。这不是提前规划好的，是写到哪看到哪的结果。
1.2 上下文窗口
整个对话就是一个 messages 数组——用户消息、助手回复、系统设定、工具返回结果，全拼在一起。模型每次回复就是在数组末尾追加一段。
这个结构解释了三个约束：
| 约束 | 原因 | Hermes 的解法 |
|---|---|---|
| 系统提示至关重要 | 放在数组最前面，每条回复前都会被读到 | SOUL.md 把规则写进系统提示 |
| 上下文窗口是天花板 | 数组太长，前面的内容被截断 | session_search 按需查历史，不把全部塞进窗口 |
| 工具结果占用窗口 | 每次工具调用结果都追加到数组 | 控制工具链长度，避免膨胀 |
二、提示层：让模型输出更好的三种手段
纯指令”帮我修好这个 bug”效果一般。加了结构之后差异明显。
2.1 思维链（CoT）
强制模型把推理过程外化，而不是在黑箱里直接跳到结论。DeepSeek 的推理模型就是把这一步做成了内置功能。
实践：先分析可能原因，再定位，再给方案——比直接要答案靠谱得多。
2.2 少样本（Few-Shot）
给例子比给规则有用。Hermes 的每个 skill 前面放一两个执行示例，新任务按示例的风格来，比写十行说明准确得多。
2.3 预填充（Prefill）
模型开始回复前，帮它写好开头。要 JSON 输出时，预填一个 {"result":，它就会乖乖沿着 JSON 结构走，不会跑格式。
| 手段 | 原理 | 什么时候用 |
|---|---|---|
| CoT | 外化推理链 | 需要深度分析或排错 |
| Few-Shot | 示例比规则好记 | 有明确输出格式要求 |
| Prefill | 引导输出起点 | 需要结构化输出（JSON 等） |
三、工具层：Agent 操作外部世界的三种能力
纯聊天没什么了不起，Agent 的价值在于能操作外部世界。
3.1 Tool Use 协议
Agent 跟外界打交道的统一接口——定义工具（schema）、调用工具、把结果塞回 messages 数组。Hermes 的 MCP 工具调用就是这么工作的。
复杂的地方不在于怎么调工具，而在于什么时候该调什么工具。
3.2 ReAct 模式
Think → Act → Observe → Think 的循环。Hermes 每条调试指令都走这个回路：
分析现象 → 查文件 → 看到结果 → 再分析 → 再查
人在解决复杂问题时本质上也是这个流程。
3.3 RAG 检索增强
给 Agent 配了一个外部知识库。Hermes 的 session_search 就是轻量版 RAG：聊到之前做过什么，就去查历史会话，带回相关信息再回答。
核心工程问题就三个：
- 切块——怎么把知识切成合适的片段
- 检索——怎么把相关片段排到前面
- 注入——怎么把结果合理地塞进提示里
四、编排层：多 Agent 协作
4.1 拆任务
Multi-Agent 编排是把一个复杂任务拆成几个人协作。Hermes 的 delegate_task 就是：
- 规划者拆任务
- 执行者并行干活
- 汇总者整合
4.2 实践案例
最近试的 Kanban 自动化管线就是这样：规划者拆出看板创建、数据提取、文章生成的步骤，各由独立 Agent 并行执行，最后汇总发布——像开了一个微型咨询公司。
回头看，Agent 的”智能”没那么多玄学。三层拆清楚——模型怎么输出、提示怎么组织、工具怎么衔接——大部分 Agent 框架的设计逻辑就都能看懂了。
继续阅读
- Hermes 记忆 vs 技能：可视化全解指南：进入长期使用 Agent 时最重要的能力沉淀问题。
- 如何将Agent自动化任务的API成本降低60%：看多轮工具调用如何把上下文成本滚大，以及如何压下来。
- 把 X Premium 接入 Hermes 的真实过程：看一次模型接入和 OAuth 排障的真实记录。