# JourneyAgent：基于本地大模型与MCP协议的智能出行规划系统 > JourneyAgent展示了一种基于本地大语言模型和Model Context Protocol（MCP）的智能体架构，通过标准化工具协议实现AI与外部API的解耦，为构建隐私优先、低延迟的智能应用提供了可行方案。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-12T23:06:27.000Z - 最近活动: 2026-05-12T23:19:30.337Z - 热度: 159.8 - 关键词: 大语言模型, 智能体, MCP协议, 本地AI, 工具调用, 开源模型, 隐私保护, TypeScript - 页面链接: https://www.zingnex.cn/forum/thread/journeyagent-mcp - Canonical: https://www.zingnex.cn/forum/thread/journeyagent-mcp - Markdown 来源: ingested_event --- ## 项目背景与架构理念\n\n当前大多数AI应用依赖专有大语言模型的云端API，这种模式虽然降低了开发门槛，但也带来了数据隐私、网络延迟和供应商锁定等问题。JourneyAgent项目试图探索一条不同的路径：完全基于本地部署的开源模型，同时保持与云端方案相当的功能完整性。\n\n该项目的核心架构理念可以概括为"关注点分离"（Separation of Concerns）。系统将AI推理能力与工具执行能力明确分离：AI负责理解用户意图、规划执行步骤、整合结果生成回复；而工具层则专注于与外部API的交互，提供标准化的数据访问接口。这种分离使得系统各部分可以独立演进，也便于替换或扩展特定组件。\n\n## Model Context Protocol（MCP）的价值\n\nJourneyAgent采用Anthropic提出的Model Context Protocol作为AI与工具之间的通信标准。MCP定义了一套统一的接口规范，使得AI模型能够以一致的方式发现和调用各种外部能力。\n\n在传统架构中，AI系统通常需要为每个外部API编写特定的适配代码，将API调用硬编码到推理流程中。这种方式的弊端在于灵活性差——新增或修改工具都需要改动核心代码。MCP通过引入标准化的工具描述格式（基于JSON Schema）和统一的调用协议，解决了这一问题。\n\n在JourneyAgent中，MCP服务器独立运行，对外暴露一组标准化的工具接口，如查询列车时刻表、查找车站信息、获取线路延误状态等。AI编排器（Orchestrator）无需了解这些工具的具体实现细节，只需要根据MCP协议描述动态发现可用工具，并在需要时发起调用请求。\n\n## 系统架构详解\n\nJourneyAgent的系统架构由四个主要层次构成，形成了一个清晰的职责划分：\n\n### 用户界面层（UI）\n\n基于Next.js构建的前端应用，负责呈现用户界面和处理用户交互。该层保持轻量，主要承担输入收集和结果展示的职责，将复杂的业务逻辑下沉到下层处理。\n\n### 编排器层（Orchestrator）\n\n这是系统的"大脑"，负责整个智能体工作流的协调。编排器接收用户的自然语言查询，初始化推理循环，分析查询意图，确定需要补充的信息，规划工具调用序列，并最终整合所有信息生成回复。\n\n编排器与本地运行的Ollama服务通信，使用Qwen 2.5模型进行推理。通过精心设计的系统提示词和工具描述，编排器能够从开源模型中诱导出结构化的函数调用行为，媲美专有API提供的工具调用能力。\n\n### MCP工具层\n\n这一层实现了Model Context Protocol服务器，负责将外部API的能力封装成标准化的工具接口。工具定义使用Zod进行严格的输入输出校验，确保数据在系统边界处的类型安全。\n\n当前实现主要集成了铁路相关的API，提供列车时刻查询、车站搜索、线路状态检查等功能。由于采用了MCP协议，这些工具可以被任何兼容MCP的客户端使用，不仅限于JourneyAgent本身。\n\n### 数据源层\n\n最底层是与真实世界数据源的连接，包括各类铁路运营商和交通信息提供商的API。这一层处理身份认证、请求格式化、错误处理等底层细节，向上层提供干净的数据接口。\n\n## 本地AI运行时的技术实现\n\nJourneyAgent最引人注目的特点之一是完全基于本地AI基础设施。项目使用Ollama作为本地大语言模型服务，搭配阿里巴巴开源的Qwen 2.5模型。\n\n### 为什么选择本地模型\n\n本地部署带来了几个显著优势：首先是隐私保护，用户的查询数据不会离开本地机器，适合处理敏感信息；其次是低延迟，避免了网络传输带来的延迟；最后是成本可控，没有按token计费的API调用成本。\n\n当然，本地方案也面临挑战。开源模型在指令遵循和工具调用能力上通常不如最先进的专有模型。JourneyAgent通过以下策略弥补这一差距：\n\n### 提示工程优化\n\n项目投入了大量精力优化系统提示词，明确指导模型如何分析用户意图、何时需要调用工具、如何解析工具返回结果。提示词中包含了详细的工具描述和示例对话，帮助模型理解MCP协议的交互模式。\n\n### 结构化输出引导\n\n通过要求模型以特定的JSON格式输出工具调用请求，系统能够可靠地解析模型的意图。即使模型偶尔产生不符合预期的输出，系统也设计了优雅的错误处理机制，向用户解释遇到的问题而非直接崩溃。\n\n## 实际应用示例\n\n让我们通过一个具体场景来理解JourneyAgent的工作流程。当用户询问"明天上午10点前到达曼彻斯特皮卡迪利站的列车有哪些"时：\n\n首先，编排器接收到查询，识别出关键信息：目标车站（Manchester Piccadilly）、到达时间约束（明天上午10点前）。由于这些信息不足以直接查询，编排器决定调用工具获取更多信息。\n\n编排器向MCP服务器查询可用工具，发现`getTrainSchedule`和`findStation`等候选工具。根据查询意图，它选择调用`getTrainSchedule`，并构造包含出发地、目的地、时间等参数的调用请求。\n\nMCP服务器接收到请求后，使用Zod验证参数格式，然后向底层铁路API发起实际请求。API返回的原始JSON数据经过处理后返回给编排器。\n\n编排器将API返回的列车数据注入到对话上下文中，再次请求模型生成最终回复。模型基于这些结构化数据，生成一段自然语言描述，列出符合条件的列车选项及其关键信息。\n\n## 技术选型与工程实践\n\nJourneyAgent在技术栈选择上体现了现代TypeScript全栈开发的最佳实践：\n\n- **运行时**：Node.js 18+，利用现代JavaScript特性\n- **类型系统**：端到端TypeScript，配合Zod进行运行时类型校验\n- **前端框架**：Next.js，提供React服务端组件和API路由能力\n- **后端路由**：Hono，轻量高效的Web框架\n- **AI基础设施**：Ollama，本地大语言模型服务\n- **协议标准**：Model Context Protocol，工具定义与调用标准化\n\n项目采用monorepo结构管理多个子包，包括UI、编排器、MCP工具和API代理等模块。这种组织方式便于代码共享和版本协调，也为未来的功能扩展预留了空间。\n\n## 局限性与改进方向\n\n作为一个演示项目，JourneyAgent还存在一些待完善之处。当前的铁路API集成相对简单，仅支持基础的查询功能，尚未覆盖票价比较、座位预订等高级场景。\n\n在AI能力方面，虽然Qwen 2.5在工具调用上表现不错，但在处理复杂多轮对话和模糊查询时仍有提升空间。未来可以考虑支持模型热切换，允许用户根据需求选择不同能力的模型。\n\n此外，当前系统主要面向单机运行，缺乏多用户支持和持久化存储。如果要转化为生产级应用，还需要补充用户认证、对话历史管理、配置持久化等功能。\n\n## 对AI应用开发的启示\n\nJourneyAgent项目为AI应用开发者提供了几个有价值的参考：\n\n首先，本地开源模型已经具备构建实用AI应用的能力，不必盲目依赖专有API。通过合理的架构设计和提示工程，开源模型同样可以提供良好的用户体验。\n\n其次，标准化协议（如MCP）在AI工具生态中的价值不容忽视。采用标准协议可以显著降低工具集成成本，也便于利用社区生态中的现有工具。\n\n最后，关注点分离的架构原则在AI应用中同样适用。将推理逻辑与工具实现解耦，不仅提高了代码的可维护性，也为系统的持续演进创造了条件。\n\n## 结语\n\nJourneyAgent作为一个技术演示项目，成功展示了基于本地大语言模型和标准化工具协议构建智能应用的可行性。虽然在功能完整度和鲁棒性上还有提升空间，但其架构设计和技术选型为同类项目提供了有价值的参考。随着开源模型能力的持续提升和工具生态的日益完善，类似的本地优先AI架构有望在实际生产环境中获得更广泛的应用。