医疗相关 Agent 工具会先卷工程能力，不会先卷模型参数

医疗 Agent 工具的竞争，不会一开始就落在“谁的模型参数更大”上，而会先落在工程能力上：能不能稳定接入工具、能不能记录过程、能不能追溯输出、能不能被机构规则约束。本文从医疗健康技术开发者视角，拆解一个面向医学文献处理、科研辅助和内部知识问答的 Agent 工具链应该如何设计。本文只讨论技术架构和工程流程示例，不提供诊断、治疗、分诊或用药建议。

为什么医疗 Agent 先卷工程能力

医疗健康场景里的 Agent 通常不是一个简单聊天框，而是一个带约束的任务执行系统。它可能需要检索医学文献、读取机构知识库、调用翻译服务、生成摘要、标注引用来源，并把每一步记录下来。

模型能力当然重要，但在真实系统里，模型只负责一部分推理和生成。开发者更早遇到的问题通常是：

• 工具调用是否稳定，失败后如何重试
• 文献检索、摘要生成、引用追踪如何串成工作流
• 每次输出使用了哪些输入材料，能否审计
• 用户权限、数据范围、日志留存如何治理
• 生成结果是否能被规则拦截和人工复核

如果这些工程能力没有建立起来，换更大的模型也只能放大不确定性。医疗相关工具链更需要“可控执行”，而不是单纯追求“更会说”。

一个医疗 Agent 工具链应拆成哪些层

下面是一个常见的工程拆分。这里以“医学文献辅助阅读 Agent”为例，任务范围限定在文献检索、摘要、术语解释和引用整理，不涉及临床决策。

这个架构里，Agent 不应该直接“想做什么就调用什么”。更稳妥的做法是把任务拆给 workflow engine，由它控制状态、超时、重试和人工确认节点。

几个关键模块的职责如下：

• Policy Guard：检查请求范围，过滤不允许的任务类型
• Workflow Engine：管理任务状态、步骤依赖和失败恢复
• Tool Calling Layer：统一封装外部工具，避免模型直接拼接请求
• Result Validator：检查引用、格式、敏感表达和示例规则
• Audit Log：记录输入、工具调用、模型版本、输出和人工修改

这类拆分会增加一些开发成本，但能换来可维护性。尤其在医疗健康场景，后续排查问题时，只有最终回答是不够的，必须知道它是如何产生的。

工作流比提示词更值得优先设计

在 Demo 阶段，开发者可能会把所有要求写进一个长 Prompt：请检索、请总结、请给引用、请注意风险。这个方式很快，但上线后会出现三个问题。

第一，步骤不可观测。你很难知道 Agent 是检索失败了，还是摘要阶段丢了引用。

第二，错误不可恢复。某个 API 超时后，如果整个 Prompt 重新跑，成本和延迟都会上升。

第三，规则不可治理。机构内部的示例规则、禁用表达、人工复核条件，很难只靠 Prompt 稳定执行。

更合理的方式是把 Agent 任务写成显式 workflow。下面是一个简化版 Python 示例，用来表达“文献检索 Agent”的任务状态、工具调用和审计日志。规则均为工程示例，真实项目应由医疗专业人员和机构规范确认。

fromdataclassesimportdataclass,asdictfromdatetimeimportdatetimefromtypingimportDict,Any,Listimportuuid@dataclassclassAuditEvent:trace_id:strstep:strstatus:strpayload:Dict[str,Any]created_at:strclassAuditLogger:def__init__(self):self.events:List[AuditEvent]=[]defwrite(self,trace_id:str,step:str,status:str,payload:Dict[str,Any]):self.events.append(AuditEvent(trace_id=trace_id,step=step,status=status,payload=payload,created_at=datetime.utcnow().isoformat()))defdump(self):return[asdict(event)foreventinself.events]classLiteratureAgentWorkflow:def__init__(self,audit_logger:AuditLogger):self.audit=audit_loggerdefpolicy_guard(self,trace_id:str,user_query:str):blocked_terms=["诊断结论","用药建议","治疗方案"]ifany(terminuser_queryforterminblocked_terms):self.audit.write(trace_id,"policy_guard","blocked",{"reason":"request_out_of_scope","query":user_query})raiseValueError("当前示例系统仅支持文献辅助处理，不提供诊断、治疗或用药建议")self.audit.write(trace_id,"policy_guard","passed",{"query":user_query})defsearch_literature(self,trace_id:str,user_query:str):result={"query":user_query,"papers":[{"id":"PMID_EXAMPLE_001","title":"Example literature record"},{"id":"PMID_EXAMPLE_002","title":"Another example record"}]}self.audit.write(trace_id,"search_literature","success",result)returnresultdefsummarize_with_llm(self,trace_id:str,search_result:Dict[str,Any]):summary={"summary":"这是基于示例文献记录生成的技术性摘要，不构成医学建议。","citations":[paper["id"]forpaperinsearch_result["papers"]]}self.audit.write(trace_id,"summarize_with_llm","success",summary)returnsummarydefvalidate_result(self,trace_id:str,summary:Dict[str,Any]):ifnotsummary.get("citations"):self.audit.write(trace_id,"validate_result","failed",{"reason":"missing_citations"})raiseValueError("摘要缺少引用来源")self.audit.write(trace_id,"validate_result","passed",{"citation_count":len(summary["citations"])})defrun(self,user_query:str):trace_id=str(uuid.uuid4())self.policy_guard(trace_id,user_query)search_result=self.search_literature(trace_id,user_query)summary=self.summarize_with_llm(trace_id,search_result)self.validate_result(trace_id,summary)return{"trace_id":trace_id,"answer":summary,"audit_log":self.audit.dump()}if__name__=="__main__":logger=AuditLogger()workflow=LiteratureAgentWorkflow(logger)output=workflow.run("请整理某主题相关医学文献的研究背景和引用来源")print(output)

这个例子没有追求复杂框架，而是展示一个核心观点：Agent 工具链要把“能跑”升级为“可追踪地跑”。后续无论换成 Temporal、Airflow、LangGraph，还是自研状态机，设计重点都是一致的。

工具调用层需要做成受控接口

医疗 Agent 不适合让模型直接决定任意 URL、任意参数、任意数据范围。工具调用层应该像后端服务一样设计接口契约。

建议至少约束四件事：

• 输入 Schema：字段类型、长度、必填项、可选项
• 权限边界：哪些用户能访问哪些文献库或内部知识库
• 超时与重试：避免单个工具拖垮整个任务
• 输出规范：返回结构化结果，而不是一段难解析的文本

例如文献检索工具可以只暴露query、limit、date_range等参数，不允许模型拼接任意复杂查询。这样会牺牲一部分灵活性，但能降低不可控调用风险。

对于工具失败，也不要简单返回“系统繁忙”。审计日志里应记录工具名、请求摘要、错误类型、耗时和重试次数，方便后续定位是外部 API 问题、网络问题，还是参数生成问题。

可观测性决定 Agent 能不能上线维护

Agent 系统上线后，最难排查的不是“报错”，而是“看起来没报错，但结果不稳定”。因此可观测性要从第一版就设计进去。

建议记录以下指标：

• workflow 总耗时和每个步骤耗时
• 工具调用成功率、超时率、重试次数
• 模型输入输出 token 数和成本
• 结果校验失败原因分布
• 人工复核触发次数和通过率

日志结构也要避免只存自然语言。推荐按trace_id串联用户请求、工具调用、模型输出和最终结果。这样一个用户反馈“这次摘要引用不完整”时，开发者能还原执行链路，而不是猜测模型当时发生了什么。

治理能力会成为产品分水岭

医疗相关 Agent 的治理能力不是额外功能，而是基础设施。越接近真实业务，越需要把规则显式化。

一些常见治理点包括：

• 任务范围声明：明确系统只做文献、知识整理或科研辅助
• 示例规则配置：哪些表达需要降级、拦截或人工复核
• 人工确认节点：高风险输出必须进入 review queue
• 版本管理：Prompt、工具、模型、规则都要能回溯
• 数据留存策略：按机构要求配置日志保存周期

这里的“高风险”不应由开发者凭感觉写死。本文所有规则都只是工程示例，真实项目应由医疗专业人员、合规团队和机构规范共同确认。

结论：先把 Agent 做成可靠系统

医疗相关 Agent 工具的早期竞争点，会更多集中在工作流、工具调用、审计日志、可观测性和治理能力。模型参数提升会改善部分理解和生成效果，但无法替代工程系统对稳定性、边界和追溯的要求。

如果你正在做医疗健康方向的 Agent 工具，建议下一步先检查三件事：任务是否被显式拆成 workflow，工具调用是否有接口契约，输出过程是否能通过 trace_id 完整追溯。把这些能力补齐后，再评估模型升级，投入产出会更清晰。

本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。