作者：武卓

旅行规划听起来很简单——直到你真的开始做。

你从“北京三日游”起步，下一秒就要同时处理最新的网页信息（开闭馆时间、购票规则、天气导致的行程变更）、个人偏好（口味、预算、行动便利性约束），有时还要处理图片（“我照片里的这个地方是哪？”）。单纯的 LLM 对话看起来可能很自信，但旅行规划恰恰属于那种：没有事实依据的自信，很容易生成一份“看着合理、实则坑很大”的行程。

在这篇博客里，我们将带你走一遍一个完整可运行的参考套件：Agentic Multimodal Travel Planner（智能体多模态旅行规划师），它来自OpenVINO™ AI Reference Kits。这个套件展示了一种实用的旅行助手架构：通过MCP（Model Context Protocol） 和A2A（Agent-to-Agent） 协议协作多个专用智能体（酒店搜索、机票搜索、图片描述），并且用OpenVINO™ 模型服务器（OVMS） 在本地高效运行优化后的推理。

我们搭建了什么：一个路由智能体+ 三个专家智能体 + 底层工具服务

理解这个系统最好的方式，是把它看成两层：

Layer 1：智能体层（A2A + BeeAI）

这是“决策层”。Travel Router Agent（旅行路由智能体） 负责统筹对话、拆解任务，并把子任务分发给各个工作智能体（worker agents）。

为了让这种任务分发在工程上真正可用，这个示例使用A2A 作为智能体之间的通信层。A2A（https://a2a-protocol.org/latest/ ） 是一个开放标准，并且已经进入 Linux Foundation 体系。它定义了智能体如何互相发送任务、如何传递上下文、如何返回结果。需要特别强调：A2A 不是编排（orchestration），也不是框架（framework），它是协议（protocol）。当路由智能体把任务交给某个专家智能体时，它并不是“调用一个函数”，而是发出一个 A2A 请求。专家智能体收到结构化输入后进行推理，并返回结构化输出。这样做的好处是：智能体彼此解耦，避免把控制流写死在代码里。

但仅有协议还不够，系统还需要一个“执行与协调”的编排层（也就是框架）来真正跑起来。虽然你也可以用 LangChain（https://www.langchain.com/ ）、LangGraph （https://github.com/langchain-ai/langgraph ）或 LlamaIndex （https://www.llamaindex.ai/ ）来做编排，但这个示例使用的是BeeAI framework（https://framework.beeai.dev/introduction/welcome ）——一个开源的 Agentic 框架，用来把从 LLM 推理到 A2A 通信的整个流程串起来。BeeAI 负责实例化智能体、路由 A2A 消息、管理状态与记忆、协调执行。当任何智能体发起 A2A 请求时，BeeAI 会解析目标智能体、注入上下文、运行它，并返回结果。从智能体视角，BeeAI 是执行环境；从系统视角，BeeAI 是调度器与编排器。

Layer 2：工具层（MCP servers）
 

这是“能力层”。它把一些能力以 MCP 的形式暴露出来：酒店搜索、机票搜索、图片描述（image captioning）。当智能体需要真实数据时，就会调用这些工具。

具体来说，这个 demo 使用了若干服务与端口：底层智能体会与 MCP 工具服务器通信；而模型则通过 OVMS 在本地提供服务，如下图所示。

A2A 与 MCP 的区别一定要分清

A2A 用于智能体之间的通信；MCP 用于智能体调用工具。

• 当一个智能体需要把推理任务“交给另一个智能体”时，用 A2A

• 当一个智能体需要调用外部能力（搜索、数据库、API 等）时，用 MCP

可以这样理解：
A2A 在智能体之间移动“意图与责任”；
MCP 把“执行”交给工具服务去完成。

模型层：通过OVMS 本地部署 OpenVINO™ 优化的LLM + VLM

这个套件使用了两个 OpenVINO™ 优化后的模型：

• OpenVINO/Qwen3-8B-int4-ov：用于文本生成（LLM）

• OpenVINO/Phi-3.5-vision-instruct-int4-ov：用于图片描述 / 多模态推理（VLM）

与其把模型加载逻辑塞进每个智能体进程里，我们选择用OVMS 来统一服务这两个模型。这样智能体代码会更干净：智能体只需要“访问一个 endpoint”，推理与性能优化由 OVMS 负责。

运行demo: OVMS → MCP servers → agents → UI

这个仓库设计成分步启动。我会保留叙述逻辑，同时给出可直接复现的命令。

1) 环境准备

先clone 仓库并创建虚拟环境 (Python 3.8+):

git clone https://github.com/openvinotoolkit/openvino_build_deploy.gitcd openvino_build_deploy/ai_ref_kits/agentic_multimodal_travel_planer
python3 -m venv agentic_venvsource agentic_venv/bin/activate   # Linux/macOS# agentic_venv\Scripts\activate    # Windows
python -m pip install --upgrade pippip install -r requirements.txt

到这里为止，你已经安装好了智能体运行环境与 UI 相关依赖。

2) 用OpenVINO™ Model Server（OVMS）准备 LLM/VLM

本套件把 LLM 和 VLM 运行在 OVMS 后面，这样每个智能体都可以调用本地 endpoint，而不用在自身进程里加载模型。

• 选项1: Linux (Docker)

先安装 Docker（各发行版文档是最稳的参考）。然后运行脚本下载模型并启动 OVMS 容器：

chmod +x download_and_run_models_linux.sh./download_and_run_models_linux.sh

验证服务是否运行（你应该能看到两个 OVMS 容器，通常映射到 8001 和 8002 端口）：

docker psCONTAINER ID   IMAGE                          PORTS                  NAMES<...>          openvino/model_server:latest   0.0.0.0:8001->8000/tcp <...><...>          openvino/model_server:latest   0.0.0.0:8002->8000/tcp <...>

• 选项 2: Windows (本地二进制)

运行批处理脚本下载模型并启动 OVMS：

./download_and_run_models_Window***at

注意：Windows 上如果二进制启动失败，你可能需要安装 Microsoft Visual C++ Redistributable。

3) 启动MCP servers（工具层）

旅行助手依赖MCP servers 来获取“真实世界能力”。在这个 demo 中，酒店搜索与机票搜索需要用到 SerpAPI Key（可免费获取）。SerpAPI （https://serpapi.com/）提供结构化、实时的搜索结果接口，数据来源包括Google 等搜索引擎。

启动脚本 start_mcp_servers.py 会检查环境变量 SERP_API_KEY；如果没有设置，它会提示你输入，并自动写入本地 .env 文件。

• 启动 MCP servers：Start MCP servers:

python start_mcp_servers.py

你会看到 logs/ 下生成日志文件，每个 MCP server 一份（例如 log***cp_<name>.log）。如果需要停止：

python start_mcp_servers.py --stop

4) 启动智能体（先worker，后 router）

• 启动智能体层：

python start_agents.py

这个脚本会先启动各个worker 智能体，再启动 router 智能体，确保 router 一启动就能立刻分派任务。日志会写到 logs/<agent>.log。停止同样简单:

python start_agents.py --stop

5) 运行Gradio UI

• 最后，加载UI:

python start_ui.py

• 浏览器打开:

http://127.0.0.1:7860

如果你想换端口，可以在启动前设置GRADIO_SERVER_PORT。

Demo 运行起来是什么体验？

当你提交一个 query，UI 会连接到 Travel Router Agent（默认 http://127.0.0.1:${TRAVEL_ROUTER_PORT}，端口默认 9996），并把中间过程以流式方式输出到 “Agent Workflow” 面板。这让系统看起来“活”起来了，同时也极大降低了调试难度——你可以实时看到任务是如何被分派与执行的。所有智能体日志也都会被保存到 /logs 目录。

多模态路径的设计也很务实：当你上传图片时，UI 会把图片保存在本地，并在 query 中追加一个结构化的 image_path 提示。router 会决定是否调用图像处理智能体；后者再通过 MCP 工具调用本地 VLM 服务来生成图片描述。

视频

自定义扩展：从哪里开始改？

当基础版本跑通后，扩展才是最好玩的部分。仓库的设计理念是：“加能力”不需要重写系统。

最常见的扩展方式是：新增一个专家智能体（比如 “预算优化智能体”“本地交通智能体”），再通过 MCP server 暴露它需要的数据能力。通常你会改三处：

• config/agents_config.yaml ：注册新智能体（名称、端口、enabled 开关等）

• config/agents_prompts.yaml ：定义它的系统 prompt 与行为方式

• Optionally, config/mcp_config.yaml ：如果新智能体需要新的 MCP 工具服务

这种分离——“智能体负责推理”“工具负责能力”——正是让智能体系统可维护、可扩展的关键。

结语：为什么它不止适用于旅行应用？

即使你对旅行应用不感兴趣，这个套件仍然是一个很强的现代 GenAI 产品模板。它展示了：

• 如何让LLM 更“诚实”（通过工具拿真实数据）

• 如何让工作流可扩展（专用智能体分工）

• 如何让集成更清晰（MCP）

• 如何让多智能体通信更一致（A2A）

• 如何让推理部署可落地且高效（OpenVINO™ + OVMS）

如果你希望构建一种开发者能在自己机器上真实复现的智能体应用，我会推荐这个方向：

本地优化推理 + 协议化工具调用 + 可观测的多智能体编排。

如果你基于这个套件新增了智能体或MCP server，也欢迎提交上游 PR 或分享实践文章。生态之所以变强，正是因为参考实现不会永远停留在“参考”，而会逐渐成为大家共同的基础设施。Happy coding.

更多资源：

• 智能体旅游规划师GitHub 仓库: https://github.com/openvinotoolkit/openvino_build_deploy/tree/master/ai_ref_kits/agentic_multimodal_travel_planer 

• OpenVINO™ GenAI：https://github.com/openvinotoolkit/openvino.genai/tree/master

• OpenVINO™ Documentation：http://docs.openvino.ai/

• OpenVINO™ Notebooks：https://github.com/openvinotoolkit/openvino_notebooks

• Provide Feedback & Report Issues：https://github.com/openvinotoolkit/openvino/issues/new/choose

OpenVINO 小助手微信 : OpenVINO-China

如需咨询或交流相关信息，欢迎添加OpenVINO小助手微信，加入专属社群，与技术专家实时沟通互动。