1. 中药科普助手为什么需要双引擎 Agent做中药科普助手最容易踩的坑不是模型不懂中药而是模型“太懂”了——它会一本正经地编造药材性味归经。我试过直接问某个通用模型“当归的归经是什么”它能给出三个版本每个版本都言之凿凿。这就是典型的 hallucination模型在缺乏外部数据源约束时会用语言概率补全看似合理的答案。Dify 里的 Agent 节点本质上是一个“决策器”它决定当前这轮对话要不要调工具、调哪个工具、传什么参数。而驱动这个决策器的策略主流就是 Function Calling 和 ReAct 两条路线。前者像点菜——你给菜单JSON Schema模型选菜输出函数名和参数后厨做完端上来后者像现场教学——模型一边想一边做Thought 是它的自言自语Action 是它伸手去拿工具Observation 是工具返回的结果循环到它觉得可以回答了为止。中药科普这个场景天然适合双引擎查单味药材的功效、性味、归经是典型的单步结构化查询Function Calling 一把梭最快但用户经常会问“当归和黄芪一起用有什么讲究”“这个方子里哪味药是君药”这就涉及多步推理、多源信息融合ReAct 的透明思考链路更合适。你要做的是让同一个 Agent 根据问题复杂度自动切换而不是写两套 Bot。这里的关键基础设施是模型接入通道。Dify 的 Agent 节点需要调用外部 LLM 来做意图识别和推理如果每个模型都单独配 Key、单独处理 Base URL维护成本会爆炸。TaoToken 在这里扮演的是统一网关的角色——一个 Key、一个 Base URL背后可以路由到不同的模型能力。你不需要在 Dify 里为每个模型建一个供应商配置只需要把 TaoToken 的 API 地址填进去模型 ID 按需切换。具体来说TaoToken 能做什么它提供 OpenAI 兼容的/v1/chat/completions接口Dify 的模型供应商配置里选 OpenAI 兼容模式Base URL 填https://taotoken.net/apiAPI Key 填你在控制台生成的 Key就能跑通。适合谁已经在用 Dify 搭 Agent、但被多模型 Key 管理搞烦的开发者或者想快速验证 Function Calling 和 ReAct 效果、不想在接入层耗时间的人。这一篇的目标很明确交付可复制的 Dify 工具节点配置、ReAct 提示词模板以及一次端到端验证——提问中药功效触发工具返回结构化结果。下面从 TaoToken 的前置配置开始。2. TaoToken 前置配置与 Dify 模型供应商接入在 Dify 里接 TaoToken核心是把“模型供应商”这一层配通。Dify 的模型供应商配置决定了 Agent 节点能用哪些模型来做推理和函数调用。如果你跳过这一步后面工具节点配得再漂亮Agent 也没有“大脑”去驱动。先拿 Key。访问 TaoToken 控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite在 API Keys 页面创建一个新 Key。建议按项目命名比如dify-zhongyao-agent方便后面排查是哪个应用在调用。创建后立即复制保存页面刷新后不再显示完整 Key。拿到 Key 后在 Dify 里操作进入「设置」→「模型供应商」→ 找到「OpenAI-API-compatible」或「OpenAI 兼容」这一类点击添加。关键参数如下配置项填写值说明模型类型LLMAgent 推理需要对话模型模型名称按需填写如gpt-4o-mini或claude-3-5-sonnet填 TaoToken 支持的模型 IDAPI Key你刚创建的 Key粘贴完整 KeyBase URLhttps://taotoken.net/api注意结尾不带/v1Dify 会自动补模型上下文长度128000按实际模型能力填最大 token 上限4096按需调整这里有个容易踩的坑Base URL 到底填https://taotoken.net/api还是https://taotoken.net/api/v1。Dify 的 OpenAI 兼容供应商在发起请求时会自动拼接/v1/chat/completions所以你填https://taotoken.net/api即可。如果你填了/v1最终请求会变成/v1/v1/chat/completions直接 404。配置完成后点「保存」Dify 会做一次连通性测试。如果测试通过你会在模型列表里看到刚添加的模型。如果报 401检查 Key 是否复制完整、是否有多余空格如果报连接超时检查 Base URL 是否写错。注意TaoToken 的 API 地址是https://taotoken.net/api不要加 UTM 参数到 API 请求里UTM 只用于官网跳转追踪。API 请求保持干净。模型供应商配好后回到你的中药科普助手应用在 Agent 节点里选择刚添加的模型。这一步决定了 Agent 用哪个“大脑”来做 Function Calling 的意图识别和 ReAct 的 Thought 生成。建议先用一个推理能力中等偏上的模型跑通流程再根据效果换更强的模型。如果你还没有 Dify 应用先在 Dify 里创建一个「Agent」类型的应用或者在一个「工作流」里添加 Agent 节点。中药科普助手的场景建议用 Agent 应用模式因为需要多轮对话和工具调用的动态决策。3. 可复制的 Dify 工具节点配置与 ReAct 提示词模板这一节是核心交付。我会给出两部分一是 Dify 里工具节点的配置方式包括 Function Calling 的 JSON Schema 和 MCP 工具的接入二是 ReAct 的提示词模板直接复制到 Agent 的指令区。先说 Function Calling 的工具注册。在 Dify 的 Agent 节点里你可以添加「自定义工具」本质是提供一个符合 OpenAI Function Calling 规范的 JSON Schema。中药科普助手至少需要两个工具get_yaocaiInfo和get_yaocai_image。前者查药材信息后者生成药材图片。get_yaocaiInfo的 Schema 如下直接复制到 Dify 自定义工具的「参数」区域{ name: get_yaocaiInfo, description: 根据中药名称获取药材的详细信息包括药性、药味、归经、功效主治、用法用量。适用于查询单味药材的结构化信息。, parameters: { type: object, properties: { yaocai: { type: string, description: 中药材名称例如当归、黄芪、甘草 } }, required: [yaocai] } }get_yaocai_image的 Schema 类似只是 description 改为“根据中药名称生成药材实物图片返回图片 URL”{ name: get_yaocai_image, description: 根据中药名称生成高清药材实物图片白色背景返回可访问的图片 URL。适用于需要视觉展示的场景。, parameters: { type: object, properties: { yaocai: { type: string, description: 中药材名称例如当归、黄芪、甘草 } }, required: [yaocai] } }在 Dify 里这两个工具可以指向你自己的后端 API也可以指向 MCP Server。如果你用 MCP 方式Dify 的 MCP SSE 插件配置如下在 Agent 的 MCP 配置区粘贴{ mcpServers: { zhongyao_mcp: { type: sse, url: http://你的MCP服务地址:8003/sse, timeout: 120000 } } }MCP Server 端用 FastMCP 注册工具核心代码结构如下。注意这里的关键是mcp.tool()装饰器把函数暴露为 MCP 工具Dify 通过get_tool_list自动发现通过call_tool调用from fastmcp import FastMCP import requests, json, os mcp FastMCP(ZhongyiServer, port8003) mcp.tool() async def get_yaocaiInfo(yaocai: str): 输入药材名称返回中药材结构化信息 url https://api.siliconflow.cn/v1/chat/completions headers { Authorization: fBearer {os.getenv(SILICONFLOW_API_KEY)}, Content-Type: application/json } payload { model: Qwen/Qwen2.5-VL-72B-Instruct, messages: [ {role: system, content: 你是中医药专家请提供准确信息。}, {role: user, content: f请以 JSON 格式返回关于 {yaocai} 的信息包含 name、property、taste、meridian、function、usage 字段。} ] } resp requests.post(url, headersheaders, jsonpayload, timeout60) content resp.json()[choices][0][message][content] try: return json.loads(content) except json.JSONDecodeError: return {error: 无法解析为 JSON, raw: content} if __name__ __main__: mcp.settings.host 0.0.0.0 mcp.settings.port 8003 mcp.run(transportsse)启动后MCP Server 监听 8003 端口Dify 通过 SSE 连接。这里有个细节Dify 的 MCP 插件会先调get_tool_list获取工具列表再在对话中按需调call_tool。你不需要在 Dify 里手动注册每个工具MCP 协议会自动发现。接下来是 ReAct 提示词模板。在 Dify Agent 的「指令」区域粘贴以下内容。这个模板的关键是明确 Thought/Action/Observation 的格式并给出终止条件你是一个中药科普助手使用 ReAct 模式工作。你可以调用以下工具 - get_yaocaiInfo(yaocai): 查询药材信息 - get_yaocai_image(yaocai): 生成药材图片 工作流程 1. 收到用户问题后先输出 Thought分析需要哪些信息。 2. 如果需要调用工具输出 Action格式为Action: 工具名(参数名参数值) 3. 系统会返回 Observation你读取后继续 Thought。 4. 当信息足够回答时输出 Answer给出最终回复。 规则 - 单味药材查询优先用 get_yaocaiInfo一次调用即可。 - 涉及多味药材对比或方剂分析时可以多次调用 get_yaocaiInfo。 - 需要图片时调用 get_yaocai_image。 - 不要编造工具返回之外的信息。 - 如果工具返回错误在 Answer 中说明并给出建议。这个模板配合 Dify 的 Agent 节点就能跑通 ReAct 循环。Dify 会自动解析 Action 并执行工具把 Observation 回填到上下文。4. 端到端验证提问中药功效触发工具返回结构化结果配置完成后必须做一次端到端验证。验证的目标是用户提问 → Agent 判断需要调工具 → 触发get_yaocaiInfo→ 返回结构化 JSON → Agent 基于结果生成自然语言回复。在 Dify 的调试预览里输入“当归有什么功效”观察执行链路。如果 Function Calling 模式生效你会看到 Agent 节点输出类似{ name: get_yaocaiInfo, arguments: {yaocai: 当归} }然后工具节点执行返回{ name: 当归, property: 温, taste: 甘、辛, meridian: 肝、心、脾, function: 补血活血调经止痛润肠通便, usage: 6-12g煎服 }最后 Agent 生成回复“当归性温味甘辛归肝、心、脾经主要功效是补血活血、调经止痛、润肠通便常用量 6-12g。”如果 ReAct 模式生效你会看到更详细的中间过程Thought: 用户问当归的功效我需要查询药材信息。 Action: get_yaocaiInfo(yaocai当归) Observation: {name:当归,property:温,...} Thought: 已获取信息可以回答。 Answer: 当归性温味甘辛...验证时重点看三个点一是工具是否被正确触发二是参数是否正确传递yaocai的值是不是“当归”三是返回结果是否被正确解析并用于生成回复。如果工具没触发检查 Agent 的指令里是否明确提到了工具名称和调用条件如果参数传错检查 Schema 里的description是否足够清晰。再测一个多步场景“当归和黄芪一起用有什么讲究”这个场景下ReAct 应该会先查当归再查黄芪然后综合两者信息给出回答。Function Calling 可能会分两次调用也可能一次调用两个函数取决于模型能力。观察哪种模式更符合你的预期。验证通过后你可以在 Dify 的「日志」里查看每次调用的详细记录包括 token 消耗、工具调用次数、响应时间。这些数据对后续优化很重要。5. 本篇常见错排查401、local proxy failed、reading choices接入过程中最容易遇到的几个报错我按实际踩坑顺序列出来。401 Unauthorized最常见。原因通常是 Key 复制不完整、Key 前后有空格、或者 Key 被禁用。排查步骤在 TaoToken 控制台确认 Key 状态是「启用」在 Dify 的模型供应商配置里重新粘贴 Key注意不要带换行符如果用的是环境变量确认变量名拼写正确。还有一种情况是 Base URL 写成了https://taotoken.net/api/v1导致请求路径错误虽然报错可能不是 401但也会认证失败。local proxy failed这个报错通常出现在 Dify 的模型连通性测试阶段。原因是 Dify 容器无法访问外部网络或者 DNS 解析失败。排查进入 Dify 的容器执行curl -I https://taotoken.net/api看是否能通。如果不通检查容器的网络配置和 DNS 设置。如果是 Docker 部署确认容器没有绑定到错误的网络模式。reading choices 报错完整报错通常是KeyError: choices或list index out of range。这说明 API 返回的 JSON 里没有choices字段或者choices是空数组。原因可能是模型 ID 填错了TaoToken 返回了错误信息而不是正常的 completion 响应或者请求体格式不对比如messages字段缺失。排查在 Dify 的日志里找到原始响应体看返回的error字段是什么。如果是模型不存在换一个 TaoToken 支持的模型 ID如果是参数错误检查max_tokens是否超出模型限制。OAuth 相关报错如果你在 Dify 里配置的是 OAuth 类型的供应商但 TaoToken 用的是 API Key 认证会报 OAuth 错误。解决在 Dify 的模型供应商里选择「OpenAI-API-compatible」而不是 OAuth 类型认证方式选 API Key。MCP 连接失败如果 Dify 的 MCP 插件报连接超时检查 MCP Server 是否在运行、端口是否开放、防火墙是否放行。用curl http://你的MCP地址:8003/sse测试如果返回 SSE 事件流说明服务正常。如果 Dify 和 MCP Server 不在同一台机器确认host设置为0.0.0.0而不是127.0.0.1。工具调用后 Agent 不回复有时候工具执行成功但 Agent 节点没有生成最终回复。原因可能是 ReAct 循环没有正确终止模型一直在 Thought/Action 里打转。解决在提示词里明确「当 Observation 包含所需信息时必须输出 Answer」并设置最大循环次数。6. 从单次验证到长期运行Coding Plan 与接入文档跑通单次验证只是开始。中药科普助手要长期运行你需要考虑几个工程问题模型调用的稳定性、成本控制、以及后续扩展更多工具。如果你打算把这个 Agent 做成长期在线的服务或者后续要接入更多中药数据源、扩展成多 Agent 协作建议看一下 TaoToken 的 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。它适合需要持续调用模型能力、但又不想每次手动管理 Key 和额度的场景。对于中药科普这种需要频繁调用工具、多轮推理的应用稳定的调用通道比单次低价更重要。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite里面有完整的 API 参数说明和错误码对照。遇到报错时先查文档里的错误码比盲目搜索快得多。如果你只是想快速验证模型对话效果可以直接用模型对话页面https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite测试提示词确认 ReAct 模板的输出格式符合预期再搬到 Dify 里。最后说一个实用技巧在 Dify 的 Agent 节点里把get_yaocaiInfo的返回结果做一层缓存。同一味药材在短时间内被多次查询时直接返回缓存结果减少 API 调用。这个优化在用户连续追问同一味药材时特别有效响应时间能从秒级降到毫秒级。缓存可以用 Dify 的代码节点实现也可以用外部 Redis看你的部署环境。