06｜查订单：让回答来自接口

如果想获取全套课程资料，请关注微信公众号 「AI面包君」，回复 「课程资料」 即可领取。

知识库可以解释 shipped 是“已发货”，却不能知道某个订单现在是否发货。这一节调用课程提供的虚构订单接口，把状态转换成中文回复，并检查订单号与客户是否对应。

我们分两段做：先在本机确认接口有正确数据，再让 Dify 发同样的请求。这样能分清接口问题、网络问题和节点配置问题。

1. 启动课程的模拟接口

在 bread-dify 文件夹打开 PowerShell，逐行运行：

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
.\.venv\Scripts\python.exe -m uvicorn mock_api.app:app --host 127.0.0.1 --port 8770

保持服务终端打开。浏览器访问 http://127.0.0.1:8770/docs，找到 GET /orders/{order_id}。点击页面的 Authorize，填写公开教学 token bread-demo-token；在接口的 Try it out 中填写 order_id=B1001、customer_id=C001，执行请求。

应返回 200，状态为 shipped，物流号为 DEMO-001。这些是虚构数据，不要拿物流号去真实承运商查询。

实际接口调试界面：先在这里核对参数与响应。它证明模拟接口可用，还没有证明 Dify Cloud 能连接你的电脑。

把查订单看成一次带编号的查询

知识库说明“shipped 表示已发货”，相当于词典告诉你一个词的含义；订单接口返回“B1001 当前是 shipped”，才提供了具体记录的状态。两者合起来，才能回答“你的这笔订单已发货”。

如果只查知识库，模型最多能解释状态词，不能知道 B1001 今天处于哪个状态。让模型根据“一般两天发货”推算某笔订单已经发货，会把规则与记录混在一起。

用终端再查一次，排除浏览器表单因素

另开 PowerShell，确认本机模拟服务还在运行，然后执行：

$headers = @{ Authorization = 'Bearer bread-demo-token' }
Invoke-RestMethod -Uri 'http://127.0.0.1:8770/orders/B1001?customer_id=C001' -Headers $headers

你应能找到 order_id、customer_id、status、tracking 等字段，分别对应订单号、归属客户、状态和物流号。终端查到与接口文档页面相同的记录，就说明两种入口都在访问同一个模拟服务。

这里把教学 token 写出来是因为它本来就是公开练习值。换成真实服务时，不要把私人凭证贴进教程或截图；参数结构可以照学，凭证管理要按实际系统处理。

2. 先解决“请求从哪里发出”

在 Dify 里使用的接口根地址，我们记作 api_base。如果 Dify 运行在云端，127.0.0.1 指向云端执行环境，不是你的电脑。Cloud 学员需要一个自己管理、Cloud 可访问的 HTTPS 测试服务；本课不会通过填写本机地址自动建立公网连接。

如果已经在本地 Docker 部署 Dify，可以让课程模拟服务加入 Dify 请求链路可达的教学网络。在 Dify 的 docker 目录先用 docker compose ps 找到实际 worker/出口代理容器，再用 docker inspect 容器名 查看网络；docker network ls 可列出网络名称。确认目标网络后，回到 bread-dify 执行：

$env:DIFY_NETWORK = '你已确认的教学网络名'
docker compose -f compose.mock.yml up -d --build

容器间根地址通常设为 http://mock-api:8770。如果第一步的本机 Python 服务仍占用 8770，先在那个终端按 Ctrl+C，再启动容器版。课程提供了这份配置，但本机制作环境没有执行 Docker 部署验收。