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 三种主流推理模式的选择逻辑

我的实际选择经验是这样的：医疗诊断辅助类智能体优先用Reflexion，因为漏诊的代价远大于多花几毛钱Token；金融报表生成类用Plan-and-Execute，因为流程是固定的，先规划能避免模型"自由发挥"；客服类智能体用ReAct，因为用户的问题千变万化，需要灵活应对。

这里有个细节值得展开说。ReAct模式在实现时，很多人会忽略"最大循环次数"这个参数。我一般会把它设在5到8之间，超过就强制中断并返回"需要人工介入"。不设这个上限的智能体，在生产环境里迟早会给你烧出一张惊人的账单。

3. 医疗领域智能体：准确性是唯一的KPI

3.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当成一个需要精心设计接口的推理组件，而不是一个万能的黑盒。