AI智能体构建方法论：从架构设计到医疗金融落地实践

1. 从会聊天到能干活智能体到底改变了什么大语言模型刚火起来那阵子几乎所有人都在做同一件事——把模型接进一个对话框然后问它问题。这个阶段我称之为问答模式模型本质上是个知识渊博但手脚被绑住的顾问它能告诉你该怎么做但没法替你去做。真正让行业兴奋起来的转折点是大家意识到如果把LLM当作一个推理引擎再给它配上工具调用、记忆存储、任务规划这几样东西它就能从一个顾问变成一个执行者。这个执行者就是智能体Agent。我在过去一年多的时间里陆续参与过几个垂直领域的智能体项目覆盖医疗问诊辅助、金融风控审核、法律文书初筛等场景。踩过的坑不算少从最早的给个提示词就以为能跑通到后来认真设计工具接口、状态机、异常回滚机制中间交了不少学费。这篇文章想做的事情很直接把AI工程师必须构建的30个智能体这个命题拆开先讲清楚智能体的底层逻辑和构建方法论再针对医疗、金融这两个对准确性要求极高的领域给出具体的设计思路和实操细节。这是系列的第一篇重点放在通用架构方法论和前几个核心智能体的实现上。如果你是一个刚接触Agent开发的工程师或者你已经会用Coze、Dify这类平台搭简单的对话机器人但想进一步理解为什么这么设计以及怎么让它在真实业务里稳定跑起来那这篇内容应该对你有用。我不会只给你一个流程图就完事而是会把每个设计决策背后的权衡讲清楚——为什么用ReAct而不是Plan-and-Execute为什么记忆要分三层为什么工具描述比工具本身更重要。这些细节才是决定一个智能体能不能上生产的关键。2. 智能体的核心架构别急着写代码先把这四层想明白2.1 为什么大多数智能体项目死在Demo阶段我见过太多团队花两周时间搭出一个演示效果惊艳的智能体然后花六个月都没能把它推上生产环境。问题几乎都出在同一个地方他们把智能体当成了一个更聪明的聊天机器人而不是一个需要工程化治理的软件系统。聊天机器人的容错率很高——答错了用户重新问一遍就行。但智能体是要执行动作的它可能调用一个支付接口、生成一份诊断建议、提交一条风控决策。这些动作一旦出错后果不是用户体验不好而是真金白银的损失甚至法律风险。所以智能体的架构设计第一优先级不是能力有多强而是边界有多清晰、错误有多可控。我的经验是一个能上生产的智能体必须把下面四层分清楚任何一层偷懒都会在后面加倍还回来。2.2 四层架构拆解感知、推理、行动、记忆感知层负责把外部输入转化成模型能理解的结构化信息。很多人觉得这层不重要直接把用户原话丢给LLM就完事了。但在垂直领域原始输入往往是非结构化、有噪声、甚至带有误导性的。比如医疗场景里患者说我最近胸口闷得慌喘不上气这句话里包含了症状描述、可能的情绪表达、以及需要追问的模糊点。感知层的任务就是做初步的意图识别和信息抽取把胸口闷映射到标准症状词表喘不上气识别为呼吸困难相关表述同时标记出持续时间未知诱因未知这些需要补全的槽位。推理层是LLM真正发挥作用的地方但它的职责不是一次性给出答案而是决定下一步做什么。这里就涉及到智能体最核心的设计模式选择。我后面会专门讲ReAct、Plan-and-Execute、Reflexion这几种模式的适用场景和取舍。行动层是智能体与外部世界交互的接口也就是工具调用。这一层的设计原则只有一条每个工具都应该是一个职责单一、输入输出明确、可独立测试的函数。我见过有人把查询患者完整病历并生成诊断建议做成一个工具这是灾难性的设计——它把推理和行动混在了一起导致你既没法测试也没法在出错时定位问题。记忆层是最容易被低估的一层。短期记忆当前对话上下文、长期记忆跨会话的知识积累、工作记忆当前任务的中间状态需要分开管理。把它们混在一个向量数据库里是很多项目后期变得不可维护的根源。2.3 三种主流推理模式的选择逻辑模式核心机制适用场景主要缺点ReAct推理-行动交替循环步骤数不确定、需要动态调整的任务Token消耗大可能陷入循环Plan-and-Execute先制定完整计划再逐步执行步骤明确、可预先拆解的流程化任务计划一旦有误后续全错Reflexion执行后自我反思并修正对准确性要求极高、允许重试的任务延迟高成本翻倍我的实际选择经验是这样的医疗诊断辅助类智能体优先用Reflexion因为漏诊的代价远大于多花几毛钱Token金融报表生成类用Plan-and-Execute因为流程是固定的先规划能避免模型自由发挥客服类智能体用ReAct因为用户的问题千变万化需要灵活应对。这里有个细节值得展开说。ReAct模式在实现时很多人会忽略最大循环次数这个参数。我一般会把它设在5到8之间超过就强制中断并返回需要人工介入。不设这个上限的智能体在生产环境里迟早会给你烧出一张惊人的账单。3. 医疗领域智能体准确性是唯一的KPI3.1 症状采集智能体会追问比会回答更重要医疗场景里患者的主诉往往是模糊的。一个合格的症状采集智能体核心能力不是根据症状给出诊断而是通过结构化追问把模糊主诉变成清晰的临床信息。我设计这个智能体时用的是槽位填充动态追问的思路。先定义一组必须采集的槽位主症状、持续时间、诱因、加重缓解因素、伴随症状、既往史、用药史。然后让LLM在每轮对话后判断哪些槽位还空着针对性地追问。这里的关键技巧是追问的优先级排序。不是所有空槽位都同等重要。比如一个说头痛的患者持续时间和是否伴随呕吐的优先级远高于家族史。我会在系统提示词里明确告诉模型这个优先级逻辑而不是让它随机追问。SYMPTOM_SLOTS { primary_symptom: {priority: 1, required: True}, duration: {priority: 1, required: True}, severity: {priority: 2, required: True}, triggers: {priority: 2, required: False}, associated_symptoms: {priority: 1, required: True}, medical_history: {priority: 3, required: False}, }注意症状采集智能体绝对不能给出任何形式的诊断结论。它的输出应该是一份结构化的症状报告交给下游的医生或诊断辅助系统。这个边界必须在系统提示词里反复强调并且在输出层做硬性校验。3.2 用药交互检查智能体规则引擎和LLM的配合药物相互作用检查是个典型的不能全靠LLM的场景。LLM的知识有截止日期而且它可能自信地胡说。我的做法是用权威药物数据库做规则匹配用LLM做结果解释和患者沟通。具体流程是这样的智能体先从处方中提取所有药物名称这一步用LLM做实体识别然后查询本地维护的药物相互作用数据库这一步是纯规则匹配不涉及LLM最后把匹配到的相互作用结果交给LLM让它用患者能听懂的语言解释风险等级和注意事项。这个设计的好处是核心的安全判断由确定性系统负责LLM只负责它擅长的语言组织。即使LLM在解释环节出了偏差也不会导致漏报了一个严重相互作用这种致命错误。3.3 医疗智能体的合规红线做医疗智能体有几条线是绝对不能碰的。第一不能给出明确的诊断结论第二不能推荐具体处方第三不能替代医生的知情同意过程。这些不是技术问题是合规问题必须在产品设计阶段就固化到系统架构里而不是靠提示词提醒模型。我的做法是在输出层加一个合规过滤器对所有要返回给用户的内容做关键词和语义双重检查。一旦触发红线词如你患有建议服用确诊为直接拦截并替换为标准的安全话术。这个过滤器是独立于LLM的用规则小模型分类器实现确保不会被提示词注入绕过。4. 金融领域智能体在确定性和灵活性之间找平衡4.1 财报分析智能体结构化提取是基本功金融领域的数据密度极高一份年报动辄两三百页。财报分析智能体的第一个任务是从非结构化的PDF里准确提取关键财务指标。这一步看起来简单实际上坑很多——表格跨页、单位不统一、附注里的数字和正文对不上这些都是常态。我的处理策略是分而治之先用版面分析工具把PDF切成文本块和表格块表格块单独走结构化提取流程文本块走LLM信息抽取。提取完成后再做一轮交叉校验——比如资产负债表里的资产总计应该等于负债合计所有者权益合计如果对不上就标记为待人工复核。这个交叉校验的步骤是我踩过坑之后加上的。早期版本直接信任LLM的提取结果结果在一次测试中模型把万元当成了元导致整个分析结论偏差了一万倍。从那以后我坚持在关键数字上做量纲校验和勾稽关系校验。4.2 风控审核智能体可解释性比准确率更重要风控场景有个特殊性即使模型判断对了如果给不出监管认可的解释这个判断也是无效的。所以风控审核智能体的设计重点不是追求最高的准确率而是每一个决策都能追溯到具体的规则或数据依据。我采用的架构是规则引擎为主LLM为辅。规则引擎负责执行明确的风控策略比如近三个月逾期次数超过2次则拒绝LLM负责处理规则覆盖不到的边缘案例并且必须输出结构化的决策依据。{ decision: reject, primary_reason: rule_match, rule_id: RISK_003, explanation: 申请人近三个月内逾期次数为3次超过阈值2次, llm_supplement: 结合申请人当前负债率85%的情况还款能力存在较大不确定性 }这种结构化输出既满足了可解释性要求也方便后续做审计和模型迭代。4.3 反欺诈智能体对抗性环境下的持续进化反欺诈是个对抗性极强的场景欺诈手法每天都在变。这意味着反欺诈智能体不能是一个训练完就固定的系统它必须具备持续学习的能力。我的做法是建立一个可疑模式库智能体在每次审核后把新发现的可疑模式经过人工确认的写入这个库并在后续审核中优先匹配。同时定期用新数据对LLM的few-shot示例进行更新让模型对新型欺诈手法保持敏感。提示反欺诈智能体的阈值设置需要格外谨慎。阈值太松会放过欺诈太紧会误伤正常用户。我的经验是先用历史数据做回溯测试找到误杀率和漏杀率的平衡点然后在这个基础上留10%的安全边际。5. 工具调用设计智能体的手脚灵不灵全看这一步5.1 工具描述比工具本身更重要这是我最想强调的一点。很多人花大量时间优化工具函数的实现却用一句话草草描述工具的功能。结果就是LLM根本不知道该在什么时候调用这个工具或者传错参数。一个好的工具描述应该包含四个要素功能说明、适用场景、参数含义、返回值格式。我举个例子对比一下。差的描述def check_drug_interaction(drug_list): 检查药物相互作用好的描述def check_drug_interaction(drug_list: list[str]) - dict: 检查多种药物之间是否存在已知的相互作用。 适用场景当用户提供了两种或以上药物名称需要评估联合用药安全性时调用。 不适用场景单一药物的副作用查询请使用 query_drug_side_effects。 参数 drug_list: 药物通用名列表如 [阿司匹林, 华法林]最多支持10种 返回 { interactions: [ {drug_pair: [阿司匹林, 华法林], severity: major, description: ...} ], checked_count: 2 } 后者的Token消耗确实更多但它能让工具调用的准确率提升一个数量级。这笔账怎么算都划算。5.2 工具粒度的把握太粗和太细都是坑工具设计的一个核心矛盾是粒度问题。粒度太粗一个工具干太多事LLM难以正确使用粒度太细工具数量爆炸LLM选择困难。我的经验法则是一个工具只做一件语义上完整的事。什么叫语义上完整就是这件事做完之后有一个明确的结果可以返回给推理层做下一步判断。比如查询患者信息是一个完整的工具但连接数据库执行SQL格式化结果就不应该拆成三个工具因为前两步单独拿出来对推理层没有任何意义。一般来说一个垂直领域智能体的工具数量控制在8到15个之间比较合适。少于8个可能覆盖不了业务需求多于15个则LLM的选择准确率会明显下降。5.3 工具调用的错误处理别让一个失败拖垮整个任务工具调用失败是常态——API超时、参数格式错误、权限不足什么情况都可能发生。关键是要有一套分级的错误处理机制。我的做法是把错误分成三类可重试错误如超时自动重试最多3次可降级错误如某个数据源不可用切换到备用方案并记录日志致命错误如权限被拒绝立即中断任务并返回明确的错误信息给用户。这套机制需要在智能体的主循环里实现而不是在每个工具里各写各的。我一般会用一个装饰器模式把所有工具统一包装在包装层处理重试、降级和日志。6. 记忆系统让智能体记住该记住的忘掉该忘掉的6.1 三层记忆的分工与实现短期记忆就是当前会话的对话历史直接用列表维护就行但要注意Token预算。我的做法是保留最近N轮完整对话更早的对话做摘要压缩。N的取值取决于任务复杂度一般客服场景取10轮复杂诊断场景取20轮。长期记忆是跨会话的知识积累比如患者的历史病史、用户的偏好设置。这部分我用向量数据库存储检索时结合语义相似度和时间衰减因子。时间衰减很重要——三个月前的用药记录和昨天的用药记录权重应该不一样。工作记忆是当前任务的中间状态比如已经采集了哪些槽位已经调用了哪些工具。这部分我直接用结构化对象维护不经过向量化因为它是精确的状态不需要模糊检索。6.2 记忆检索的时机和策略不是每一轮对话都需要检索长期记忆。频繁检索不仅浪费Token还可能引入不相关的信息干扰推理。我的策略是在任务开始时检索一次在用户提到新信息时按需检索。具体实现上我会在系统提示词里告诉模型如果你需要了解用户的历史信息来回答当前问题请调用retrieve_memory工具。让模型自己决定什么时候需要记忆比每轮都强制检索要高效得多。7. 评测与迭代怎么知道你的智能体到底行不行7.1 构建领域专属的评测集通用的LLM评测榜单如MMLU、GSM8K对垂直领域智能体的参考价值有限。你需要构建自己的评测集覆盖真实业务中的典型场景和边缘案例。我的做法是从历史工单或业务记录中采样每个场景标注期望的工具调用序列和期望的输出要点。评测时不仅看最终答案对不对还要看工具调用路径是否合理。一个答案正确但调用了错误工具的智能体在生产环境里迟早会出问题。7.2 在线监控与灰度发布智能体上线不是终点而是起点。必须建立在线监控体系跟踪工具调用成功率、平均响应时间、用户满意度等指标。新版本上线一律走灰度先放5%的流量观察一周确认没有异常再逐步扩大。我特别想提醒的是要监控异常中断率。就是智能体在任务执行到一半时因为各种原因循环超限、工具连续失败、输出不合规被迫中断的比例。这个指标如果超过2%说明系统还有明显的稳定性问题不应该扩大流量。8. 一些踩坑之后的真心话做智能体这一年多最大的体会是技术选型的重要性远低于工程治理的重要性。用什么框架、接哪个模型这些问题的答案会随时间变化但怎么设计工具接口、怎么管理记忆、怎么做错误处理、怎么建立评测体系这些是稳定的核心能力。另一个体会是不要试图让智能体解决所有问题。明确它的能力边界在边界之外设计好人工接管流程比硬撑着让模型再想想办法要靠谱得多。我在医疗项目里坚持所有诊断相关输出都必须经过医生确认在金融项目里坚持所有拒绝决策都必须可追溯到具体规则这些不智能的设计恰恰是系统能上生产的前提。后面几篇我会继续拆解剩下的智能体包括法律文书审查、教育辅导、代码审查等场景。每个场景的坑都不一样但底层的方法论是相通的——把LLM当成一个需要精心设计接口的推理组件而不是一个万能的黑盒。