不再列禁止词，而是为每种提供严格的输出结构模板，LLM 只需要填空。

核心思路是：用 LLM 做"理解+推理"，用知识图谱做"事实裁决"，两者通过 Tool Calling 连接。

本文探讨了在医疗Agent系统中确保工具调用稳定性的关键问题。作者通过测试案例发现，LLM在工具调用参数传递上存在不确定性，如在药物冲突检测中未能正确归一化药名（如"芬必得"未转为"布洛芬"）。文章提出三层解决方案：1）完善工具描述，明确要求传入药物通用名、患者状态和食物信息；2）在SystemPrompt中严格约束调用规则，禁止跳过工具直接回答；3）设置循

这大概就是"联调"这件事的真实面目：不是任何单个问题很难，而是需要前后端两个人持续对齐，每修一个问题就可能引出下一个问题，而且很多 bug 只在两边真正连起来的时候才会出现。进入联调阶段之前，我以为 AI 模块和前端的对接应该很顺——接口契约定好了，JSON Schema 定好了，状态机设计好了，两边按照契约开发，联调应该是"插上就能跑"的事。选项二比一好，但 LLM 生成中间步骤的时间占了总耗时

用户输入"消炎药"，Agent 提取出来的就是"消炎药"这个词，字典里没有，检索返回空。用 LoRA 对 Qwen2.5-3B 做轻量微调（显存成本低，适合 4090 单机快速实验），当前阶段不追求最终性能，只验证四件事：模型能否稳定输出合法 JSON、能否覆盖关键字段（年龄/性别/诊断/用药）、缺失字段能否被正确识别、训练后模型能否被后端直接调用。解决方案是在 FastAPI 里加完整的。字段是

Constraints 是绝对红线——其中最核心的两条是"禁绝幻觉（必须 100% 依赖工具返回的 Observation，绝不依赖训练数据进行药理判断）"和"强制 JSON 输出（不含 Markdown 标记、无前置后置问候语）"。35 岁女性，高血压+偏头痛，青霉素过敏史，妊娠状态未知，候选赖诺普利+布洛芬。效果提升明显，但暴露了更隐蔽的问题——LLM 在整合时开始"发挥"，自发引入图谱之外的

Agent 最终的输出格式不稳定。林煒这周制定的接口契约要求后端返回严格的 JSON，必须是 PASS / BLOCK / CLARIFY / FALLBACK 四个枚举值之一。但 LLM 在自然状态下不会输出这个格式——它会输出一段自然语言，有时候夹杂着这样的片段，有时候完全不包含。解决方案是用 LangChain 的 Output Parser 强制约束输出结构。extracted_drugs

实际测试时我就遇到了：用户输入"吲哚美辛"（消炎痛），这是另一个 NSAIDs 类药物，图谱里收录了，但 Agent 从用户的"消炎药"这个描述里提取出来的实体是"消炎药"这个词，字典里没有这个词，检索返回空。"胃溃疡史"、"有胃病"、"胃不好"、"之前做过胃镜有溃疡"——这些表达在语义上等价，但字符串差异很大，别名字典覆盖不了这种程度的语义变体。字段是关键——用户不会说"ibuprofen"，他

用户输入"消炎药"，Agent 提取出来的就是"消炎药"这个词，字典里没有，检索返回空。用 LoRA 对 Qwen2.5-3B 做轻量微调（显存成本低，适合 4090 单机快速实验），当前阶段不追求最终性能，只验证四件事：模型能否稳定输出合法 JSON、能否覆盖关键字段（年龄/性别/诊断/用药）、缺失字段能否被正确识别、训练后模型能否被后端直接调用。解决方案是在 FastAPI 里加完整的。字段是

实际测试时我就遇到了：用户输入"吲哚美辛"（消炎痛），这是另一个 NSAIDs 类药物，图谱里收录了，但 Agent 从用户的"消炎药"这个描述里提取出来的实体是"消炎药"这个词，字典里没有这个词，检索返回空。"胃溃疡史"、"有胃病"、"胃不好"、"之前做过胃镜有溃疡"——这些表达在语义上等价，但字符串差异很大，别名字典覆盖不了这种程度的语义变体。字段是关键——用户不会说"ibuprofen"，他