我用Hermes Agent、Ollama与本地模型做了什么
内容提要
文章介绍如何用Hermes Agent与Ollama在本地搭建多智能体旅行研究团队“Wanderlist”：协调者将目的地调研、住宿建议和航班查询分派给三个子代理，借助本地模型和MCP联网搜索，并用自定义Python工具生成真实可用的Google Flights搜索链接。全程无需订阅或API密钥，仅消耗本机算力，并支持跨会话记忆用户偏好。
延伸解读
本地多智能体的分工与安全设计
文章中的旅行团队由协调者与三个子代理组成，每个子代理职责明确：目的地调研、住宿建议和航班查询。值得注意的是，目的地调研被明确要求每次联网搜索签证与入境要求，而非依赖模型记忆；住宿建议则禁止编造具体价格。这种设计将模型可能产生幻觉的风险点（易变信息、具体数字）用工具调用和指令约束来规避，是本地智能体落地时值得借鉴的安全思路。
航班查询的务实妥协
由于没有免费实时航班价格API，项目选择用自定义Python工具生成Google Flights搜索链接，而非伪造价格数据。工具对日期格式和空输入做了校验，确保链接真实可用。这揭示了一个现实：本地智能体在缺乏商业数据接口时，应优先提供可操作的跳转入口，而非假装拥有实时数据。读者需注意，该方案只生成搜索链接，不返回具体票价，价格上下文仍依赖联网搜索的近似范围。
本地模型的取舍与硬件门槛
文章坦承本地模型在消费级硬件上能力不及前沿云模型，且运行更慢，尤其无GPU时。项目推荐31B级模型以可靠支持工具调用，对应24GB以上内存和8GB以上显存。这意味着多智能体协作对模型工具调用能力有硬性要求，小模型可能无法稳定委派任务。读者在复现前应评估硬件是否达标，否则协调者与子代理的协作可能失效。
跨会话记忆的实际价值
协调者配置了记忆工具，将用户预算、住宿偏好等存入本地数据库，使团队在后续会话中无需重复询问。这使项目从一次性脚本变为可积累偏好的助手。但文章未说明记忆的检索与更新机制，读者需注意记忆内容可能随使用增长而影响响应相关性，实际效果取决于Hermes的记忆管理策略。
Q&A
Hermes Agent 和 Ollama 分别是什么？它们在这个旅行规划项目中各自扮演什么角色？
Hermes Agent 是 Nous Research 开发的开源 AI 代理（MIT 许可证），具备多代理编排、持久记忆、MCP 工具支持和自定义工具能力，负责协调整个旅行团队。Ollama 是本地运行大语言模型的开源工具，提供 OpenAI 兼容的本地 API，让 Hermes 能调用本地模型进行推理，无需云端 API 密钥。
搭建这个本地多智能体旅行团队需要什么样的硬件配置？
最低配置：8GB 内存、5GB 存储、4 核 CPU，无需 GPU。推荐配置：24GB 以上内存（用于 31B 级模型）、25GB 以上存储、8 核以上 CPU，以及 8GB 以上显存的 NVIDIA GPU。
Wanderlist 旅行团队是如何分工协作的？
由一个根协调者（root coordinator）接收旅行请求，将任务分派给三个专家子代理：destination-scout 负责调研目的地、景点和入境要求；stay-finder 负责寻找口碑好的住宿区域和类型；flight-finder 负责生成真实的航班搜索链接和当前票价参考。协调者最后汇总三者的结果，形成一份完整的旅行简报。
为什么 flight-finder 要使用自定义 Python 工具来生成航班搜索链接？
因为目前没有免费实时的航班价格 API，所以通过自定义 Python 工具 build_flight_search_url 生成真实的 Google Flights 搜索 URL。该工具使用 urllib.parse.quote 对查询参数进行百分号编码，确保多词城市名（如“Ho Chi Minh City”）也能生成正确链接，并对日期格式进行校验，避免产生无效链接。
这个本地旅行团队如何记住用户的偏好？
协调者配置了 memory 工具集，并指定路径 ./trip_preferences.db，因此团队可以跨会话记住用户信息，例如预算范围、住宿偏好（如精品酒店而非连锁酒店）、过去的旅行经历等。这样每次对话无需从头开始，使用越多越贴合用户需求。
使用本地模型和 Hermes 搭建旅行助手有哪些优缺点？
优点：无需订阅或 API 密钥，除网络搜索外数据不离开本机，无使用费用（仅耗电），且支持跨会话记忆。缺点：本地模型在消费级硬件上的能力通常不及前沿云端模型，运行速度较慢（尤其无 GPU 时）。但对于研究、规划和工具调用类任务，这一权衡是值得的。
