1. 为什么“30个智能体”是一个值得认真对待的工程命题
1.1 从“会聊天”到“能干活”的分水岭
大语言模型刚火起来那阵子，大家最直观的体验就是“能聊天”。你问它答，写文案、改代码、翻译文档，确实好用。但真把它丢进业务场景里，问题马上就来了：它只会说，不会做。你让它查一下今天的库存，它给你编一个数字；你让它根据客户邮件自动生成工单，它写完就停在那儿，没人去创建工单。
这就是“聊天机器人”和“智能体”之间最本质的差别。智能体的核心不是“说”，而是“决策加执行”。它要能感知环境、拆解目标、调用工具、拿到结果、根据结果调整下一步，最后把事办成。大语言模型在这里扮演的是“大脑”的角色，负责推理和规划，但光有大脑不够，还得有手脚——也就是工具调用、记忆管理、状态跟踪这些工程组件。
我见过太多团队，拿着一个效果不错的模型，兴冲冲地想做业务自动化，结果卡在“怎么让模型稳定地输出结构化指令”这一步。这不是模型不行，是架构没设计对。一个能落地的智能体，模型能力可能只占三成，剩下七成全是工程活儿：提示词编排、工具接口设计、错误重试、上下文压缩、权限控制、审计日志。这些东西听起来不性感，但缺一个，智能体就只能在演示环境里跑跑，上不了生产。
1.2 医疗、金融为什么是智能体的“试金石”
在所有行业里，医疗和金融对智能体的要求是最苛刻的。这两个领域的共同特点是：数据敏感、流程严谨、错误代价极高。你让一个智能体帮用户查天气，查错了顶多被骂两句；你让它帮医生整理病历摘要，漏掉一个过敏史，那就是医疗事故；你让它帮分析师生成交易信号，逻辑有偏差，可能就是真金白银的损失。
所以，拿这两个领域来检验智能体的成熟度，是最有说服力的。医疗智能体要解决的核心问题是“信息过载下的精准提取与合规流转”。一个医生一天要看几十个病人，每个病人的病历、检查报告、用药记录散落在不同系统里，智能体要做的不是“替医生做诊断”，而是“把医生需要的信息在正确的时间以正确的格式送到面前”。金融智能体则更偏向“规则约束下的实时决策辅助”，比如反欺诈场景，它要在毫秒级判断一笔交易是否可疑，同时给出可解释的理由，因为监管要求你必须能说清楚为什么拦截。
这两个领域还有一个共同点：它们都有大量的“长尾场景”。通用模型在常见问题上表现不错，但遇到罕见病、特殊交易结构，就容易胡编。智能体的价值就在于，它可以通过工具调用去查权威数据库、去检索内部知识库、去请求人工确认，而不是硬编一个答案。这种“知道自己不知道，并且知道去哪里找答案”的能力，才是智能体真正区别于普通模型的地方。
1.3 这30个智能体到底覆盖了什么
标题里说的“30个智能体”，不是随便凑数的。如果按功能维度拆，大致可以分成几类：第一类是信息提取与结构化类，比如从非结构化病历中抽取诊断编码、从财报PDF里提取关键财务指标；第二类是流程自动化类，比如自动生成理赔初审意见、自动完成KYC材料核验；第三类是决策辅助类，比如临床路径推荐、投资组合风险预警；第四类是交互服务类，比如智能导诊、智能投顾问答；第五类是监控与合规类，比如交易行为异常检测、病历质控。
每一类智能体的技术栈和设计重点都不一样。信息提取类重在对模型输出格式的强约束和校验规则；流程自动化类重在状态机和异常处理；决策辅助类重在可解释性和置信度阈值；交互服务类重在多轮对话管理和意图识别；监控类重在实时性和低误报率。后面我会挑几个典型的智能体，把它们的架构、关键参数、踩坑点一个个拆开讲。
2. 构建垂直领域智能体的核心架构拆解
2.1 智能体的四层结构：感知、规划、执行、记忆
不管你是用现成的智能体框架，还是自己从零搭，一个能跑通的垂直领域智能体，基本都逃不开这四层。
感知层负责把外部输入转成模型能理解的形式。在医疗场景里，输入可能是一段医生口述的语音、一张化验单图片、一份HL7消息；在金融场景里，可能是FIX协议报文、一封客户邮件、一个API回调。感知层的核心任务不是“理解”，而是“标准化”。你要把各种乱七八糟的输入，统一成结构化的文本或向量，再喂给规划层。这里最容易犯的错是直接把原始数据丢给模型，比如把整个PDF转成文本塞进提示词，结果token爆了，关键信息还被淹没了。
规划层就是大语言模型的主场。它要根据当前状态和目标，决定下一步做什么。是直接回答，还是调用工具？调用哪个工具？传什么参数？如果工具返回失败，是重试还是换路径？这些决策的质量，直接决定智能体的上限。规划层的提示词设计有个诀窍：不要试图让模型“一次性想清楚所有步骤”，而是让它“走一步看一步”。ReAct模式之所以流行，就是因为它把推理和行动交替进行，模型每做一步都能看到环境反馈，再决定下一步。
执行层是真正干活的。它负责调用外部API、查询数据库、发送消息、写入文件。执行层的关键是“幂等”和“超时控制”。我见过一个理赔智能体，因为调用核保接口超时后自动重试了三次，结果同一笔理赔被重复提交了三遍。后来我们在执行层加了请求ID去重和最大重试次数限制，才解决这个问题。
记忆层分短期和长期。短期记忆就是当前对话的上下文，通常用滑动窗口或摘要压缩来管理。长期记忆则是向量数据库或知识图谱，存的是领域知识、历史案例、用户偏好。医疗智能体的长期记忆里，往往还要存诊疗指南和药品说明书；金融智能体的长期记忆里，存的是监管规则和历史交易模式。记忆层的设计难点在于“什么时候写入”和“什么时候读取”。写得太频繁，噪声太大；读得太宽泛，检索出来的东西不相关，反而干扰模型判断。
2.2 工具调用的设计原则：别让模型猜你的接口
工具调用是智能体从“说”到“做”的关键一跃。但很多团队在这一步翻车，原因出奇地一致：工具描述写得太烂。
大语言模型调用工具，靠的是你给的函数签名和描述。如果你写的是get_data(id)，模型根本不知道这个id是什么格式、返回什么、什么时候该用。正确的做法是，把工具描述当成给一个新员工的交接文档来写。比如：
def query_patient_lab_results( patient_id: str, # 患者唯一标识，格式为"P"开头加8位数字，如"P00012345" test_codes: list[str], # 检验项目编码列表，如["GLU", "HBA1C"]，空列表表示查全部 date_range: str = "last_30d" # 时间范围，支持"last_7d"、"last_30d"、"last_90d"或"YYYY-MM-DD:YYYY-MM-DD" ) -> dict: """ 查询指定患者在指定时间范围内的检验结果。 返回包含检验项目名称、结果值、单位、参考范围、异常标志的列表。 如果患者不存在或无权访问，返回空列表并在error字段说明原因。 """你看，这样写，模型就知道什么时候该用、参数怎么填、返回什么。还有一个容易被忽略的点：工具的数量不要太多。我建议单个智能体的工具数量控制在10到15个以内。超过这个数，模型的选择准确率会明显下降。如果业务确实需要很多工具，那就做分层：先让模型选“工具类别”，再在类别内选具体工具。
2.3 状态管理与错误恢复：智能体不是一次性的
智能体跟普通API调用最大的区别在于，它是有状态的。一个理赔智能体可能要经过“接收申请→核验身份→检查保单→计算赔付→生成意见→人工复核”六个步骤，中间任何一步失败，都不能从头再来。这就要求你把状态管理做好。
我的做法是，用一个轻量级的状态机来管理智能体的执行流程。每个状态节点定义清楚：进入条件、执行动作、成功后的下一个状态、失败后的处理策略。状态数据存在Redis或数据库里，带上过期时间。这样即使服务重启，智能体也能从上次中断的地方继续。
错误恢复策略要分类型。网络超时这种临时错误，可以重试；参数校验失败这种逻辑错误，重试没用，得让模型重新生成参数；权限不足这种业务错误，得转人工。我一般会在执行层加一个错误分类器，根据错误码和错误信息自动判断该走哪条恢复路径。这个分类器不用很复杂，一个规则表就够了，但能省掉大量人工干预。
3. 医疗领域智能体的实操拆解
3.1 病历结构化智能体：从自由文本到标准编码
病历结构化是医疗智能体里最基础也最刚需的一个。医生写的病历往往是自由文本，里面夹杂着专业术语、缩写、甚至笔误。智能体要做的，是把这些文本转成ICD-10诊断编码、LOINC检验编码、RxNorm药品编码这样的标准格式，方便后续分析和质控。
这个智能体的核心难点在于“术语归一化”。比如“心梗”和“心肌梗死”是同一个东西，“阿司匹林”和“乙酰水杨酸”也是同一个东西。模型直接做映射，准确率大概在70%到80%，剩下的长尾案例很容易出错。我的做法是“模型初筛加规则兜底”：先用模型把文本里的实体抽出来，然后拿实体去查本地维护的同义词表，同义词表覆盖不到的，再用向量检索去匹配标准术语库。这样能把准确率拉到95%以上。
提示词设计上，我强烈建议用“少样本加结构化输出”的方式。给模型三到五个标注好的例子，然后要求它输出JSON格式，每个字段都规定好类型和取值范围。比如：
{ "diagnoses": [ { "text": "2型糖尿病", "icd10_code": "E11.9", "confidence": 0.95 } ], "medications": [ { "text": "二甲双胍", "rxnorm_code": "6809", "dosage": "500mg", "frequency": "bid" } ] }输出之后，一定要加校验层。ICD-10编码必须是合法的，药品剂量必须在合理范围内，置信度低于阈值的要标记出来让人工复核。我踩过的一个坑是，模型有时候会把“否认糖尿病史”里的“糖尿病”抽出来当成诊断，后来在提示词里明确加了“否定语境下的实体不抽取”的规则，才解决这个问题。
3.2 临床路径推荐智能体：辅助而不是替代
临床路径推荐智能体的定位一定要清晰：它是给医生做参考的，不是替医生做决定的。这个定位决定了它的设计原则——高召回、可解释、易否决。
高召回的意思是，它宁可多推荐几条可能的路径，也不要漏掉关键选项。医生看到五条建议，扫一眼就能排除三条不相关的，但如果只给一条，万一不对，医生就得从头自己想。可解释的意思是，每条推荐都要附上理由，比如“根据患者年龄、并发症和最新指南，建议优先考虑XX方案”。易否决的意思是，医生要能一键标记“不适用”，这个反馈要能回流到系统里，用于后续优化。
技术实现上，这个智能体通常是“检索加推理”的混合架构。先从临床指南库和歷史病例库里检索相关片段，然后把患者信息和检索结果一起喂给模型，让模型生成推荐意见。检索环节的质量直接决定推荐质量，所以指南库的更新维护是个长期活儿。我建议至少每季度更新一次指南库，每次更新后跑一遍回归测试，看看推荐结果有没有异常变化。
3.3 智能导诊智能体：多轮对话的意图收敛
智能导诊看起来简单，不就是问用户哪里不舒服，然后推荐科室吗？但实际做起来，多轮对话的意图收敛非常考验设计功力。用户说“我肚子疼”，可能是消化内科、普外科、妇科、泌尿外科，甚至心内科（下壁心梗也会表现为上腹痛）。智能体要通过追问，一步步缩小范围。
我的经验是，导诊智能体的对话策略要用“决策树加模型”的混合模式。决策树负责主干流程，比如先问部位、再问性质、再问伴随症状；模型负责理解用户的自由表述，把“肚子疼”映射到“腹痛”，把“拉肚子”映射到“腹泻”。这样既有结构化的引导，又能处理口语化的输入。
还有一个细节：导诊智能体一定要有“兜底策略”。当用户描述模糊、追问三轮还无法收敛时，不要硬猜，直接推荐“全科医学科”或“急诊科”，并提示“如果症状加重请立即就医”。这个兜底策略看起来简单，但能避免很多风险。
4. 金融领域智能体的实操拆解
4.1 反欺诈交易监控智能体：毫秒级决策的工程挑战
反欺诈智能体跟医疗智能体最大的不同是时间约束。医疗场景里，医生等个几秒钟看推荐结果没问题；但交易反欺诈，你必须在毫秒级给出判断，否则交易早就完成了。
这就决定了反欺诈智能体的架构不能是“大模型直接推理”。大模型的推理延迟通常在几百毫秒到几秒，扛不住高并发。我的做法是“小模型加规则引擎做实时拦截，大模型做异步分析和策略优化”。实时链路用轻量级模型或规则引擎，在50毫秒内给出“放行、拦截、人工审核”三选一的决策；异步链路用大模型分析被拦截的交易，生成详细的欺诈特征报告，供风控团队调整策略。
实时链路的特征工程是关键。我一般会构造三类特征：交易特征（金额、时间、商户类别）、用户特征（历史交易频率、平均金额、常用设备）、行为特征（本次交易与历史模式的偏离度）。这些特征喂给一个梯度提升树模型，效果通常比直接上大模型好，而且延迟可控。
大模型在异步链路里的价值在于“解释性”。监管要求金融机构必须能解释为什么拦截一笔交易。大模型可以根据交易特征和模型打分，生成一段人类可读的解释，比如“该交易金额是用户历史平均金额的15倍，且发生在用户从未使用过的设备上，与用户惯常消费时段不符”。这种解释对客服和合规团队非常有用。
4.2 智能投研助手：信息聚合与观点生成
投研助手是金融领域里大模型应用最成熟的场景之一。它的核心功能是：把散落在研报、新闻、财报、公告里的信息聚合起来，生成结构化的投资要点。
这个智能体的技术难点不在模型，在数据管道。你要对接多少个数据源？每个数据源的更新频率是多少？格式怎么统一？我做过一个投研助手，对接了二十多个数据源，光是数据清洗和去重就花了整个项目一半的时间。我的建议是，先把数据源分成“核心源”和“补充源”。核心源是必须实时对接的，比如交易所公告；补充源可以每天批量拉取，比如行业新闻。这样能大幅降低工程复杂度。
观点生成环节，一定要加“引用溯源”。模型生成的每一条结论，都要能追溯到原始数据。比如“该公司营收同比增长20%”后面要附上财报的页码或链接。这不仅是合规要求，也是建立用户信任的关键。我见过一些投研助手，观点写得头头是道，但用户一问“数据哪来的”，就露馅了。
4.3 KYC材料核验智能体：多模态与规则引擎的结合
KYC（了解你的客户）材料核验是个典型的“多模态加规则”场景。用户上传的可能是身份证照片、营业执照扫描件、银行流水PDF，智能体要从中提取关键字段，跟用户填写的信息做比对，判断是否一致。
这个智能体的架构通常是：OCR负责把图片转成文本，模型负责从文本里抽取字段，规则引擎负责比对和判断。OCR的准确率是基础，如果身份证号都识别错了，后面全白搭。我建议在OCR之后加一个“格式校验层”，比如身份证号必须是18位、最后一位校验码要算对，格式不对的直接打回重传，不要浪费模型算力。
字段抽取环节，模型要处理各种版式差异。同样是营业执照，不同地区的版式可能不一样。我的做法是，先用目标检测把关键区域框出来，再对每个区域单独做OCR和抽取。这样比整图识别准确率高很多。比对环节的规则要写清楚：哪些字段必须完全一致，哪些字段允许模糊匹配（比如地址），哪些字段不一致时触发人工审核。这些规则最好让业务方参与制定，因为不同金融机构的风险偏好不一样。
5. 智能体开发中的常见坑与排查技巧
5.1 模型输出不稳定：结构化输出的强制约束
智能体开发里最让人头疼的问题，就是模型输出格式不稳定。你要求它输出JSON，它有时候给你加个“好的，以下是JSON：”，有时候字段名大小写不一致，有时候干脆少一个字段。这在演示环境里可能只是小瑕疵，在生产环境里就是致命错误。
我的解决方案是“三层约束”。第一层是提示词约束，在系统提示里明确写“只输出JSON，不要任何额外文字”，并给出严格的schema。第二层是输出解析器的容错处理，比如自动去掉markdown代码块标记、自动补全缺失字段的默认值。第三层是校验失败后的重试机制，如果解析失败，把错误信息附在提示词里让模型重新生成，最多重试两次。
如果模型还是不稳定，那就考虑用“函数调用”或“结构化输出”的原生支持。现在主流的大模型API都支持强制JSON输出，开启这个选项后，模型输出的格式合规率能到99%以上。代价是稍微牺牲一点灵活性，但在生产环境里，稳定性比灵活性重要得多。
5.2 工具调用死循环：超时与最大步数控制
智能体调用工具时陷入死循环，是另一个高频问题。比如模型调用了一个查询接口，返回空结果，模型不理解，又调了一次同样的接口，还是空，再调一次……直到token耗尽或者超时。
预防死循环，要在三个地方设限。第一是最大步数限制，单个任务最多执行N步（我一般设10到15步），超过就强制终止并返回当前结果。第二是重复调用检测，如果连续两次调用的工具名和参数完全相同，直接跳过第二次，把第一次的结果再喂给模型，并在提示里加一句“该工具已调用过，返回结果同上，请尝试其他方法”。第三是超时控制，每个工具调用设一个超时时间（比如5秒），超时后返回错误信息，让模型决定下一步。
还有一个隐蔽的死循环场景：模型在两个工具之间来回切换，A调完调B，B调完调A。这种情况用最大步数限制也能兜住，但更好的做法是在提示词里加一句“如果你已经尝试了两种方法都没有进展，请直接说明当前无法完成，并给出建议”。让模型学会“认输”，比让它硬撑更安全。
5.3 上下文窗口溢出：摘要压缩与关键信息保留
长对话场景下，上下文窗口溢出是迟早的事。你不可能把几十轮对话全塞进提示词里，token费用扛不住，模型注意力也会被稀释。
我的做法是“滑动窗口加摘要”。保留最近N轮对话的完整内容（N一般取5到8），更早的对话压缩成一段摘要。摘要的生成也有讲究：不要简单地说“用户问了X，助手答了Y”，而要提取关键信息，比如“用户已提供患者ID为P00012345，已确认查询范围为最近30天，已排除药物过敏史”。这样即使原始对话被压缩了，关键状态信息还在。
对于医疗和金融场景，还有一些信息是绝对不能压缩的：患者ID、交易金额、诊断编码、合规标记。这些信息我会单独存到一个“关键状态”字段里，每次调用模型都带上，不参与摘要压缩。这样既控制了token量，又保证了关键信息不丢失。
5.4 权限与审计：智能体不能是“黑盒”
在医疗和金融领域，智能体的每一步操作都必须可追溯。谁在什么时候让智能体做了什么，智能体调用了哪些工具，返回了什么结果，最终输出了什么，这些都要记日志。
日志的设计有个原则：结构化、不可篡改、可检索。我一般用JSON格式记录每条日志，包含时间戳、用户ID、会话ID、步骤序号、动作类型、输入摘要、输出摘要、耗时、错误信息。日志存到独立的审计库里，只允许追加，不允许修改。这样万一出了纠纷，可以完整回放整个执行过程。
权限控制要细到工具级别。不是所有用户都能让智能体调用所有工具。比如查询患者检验结果的工具，只有医生角色才能调用；生成交易拦截建议的工具，只有风控角色才能调用。这个权限校验要在执行层做，不能只靠提示词约束，因为提示词是可以被绕过的。
6. 从单智能体到多智能体协作的演进思路
6.1 什么时候需要多智能体
单智能体搞不定的场景，通常有这几个特征：任务步骤太多，一个提示词装不下；需要不同领域的专业知识，一个模型提示词覆盖不了；需要并行处理多个子任务，串行太慢。
比如一个完整的理赔流程，涉及身份核验、保单查询、医疗审核、金额计算、反欺诈检查五个环节，每个环节都需要不同的工具和知识。用一个智能体从头做到尾，提示词会变得极其臃肿，而且任何一个环节出错都会影响全局。这时候拆成多个智能体，每个负责一个环节，通过消息队列或共享状态来协作，反而更稳定。
但多智能体不是没有代价的。智能体之间的通信开销、状态同步、错误传播，都是新的复杂度。我的建议是：能用单智能体加工具解决的，就不要上多智能体。只有当单智能体的提示词超过2000字、工具超过15个、或者需要不同模型处理不同环节时，才考虑拆分。
6.2 协作模式：流水线、辩论、层级
多智能体协作主要有三种模式。流水线模式是最常见的，智能体A的输出是智能体B的输入，像工厂流水线一样。这种模式适合步骤明确的流程，比如理赔。辩论模式是多个智能体对同一个问题给出不同意见，然后由一个仲裁智能体综合判断。这种模式适合需要多角度分析的场景，比如投研。层级模式是一个主管智能体负责任务拆解和分配，多个执行智能体负责具体干活。这种模式适合复杂但可分解的任务，比如大型项目的风险评估。
我实际用得最多的是流水线模式，因为它最容易调试和监控。每个智能体的输入输出都明确，出了问题容易定位。辩论模式效果有时候很好，但成本高，而且仲裁逻辑不好设计。层级模式对主管智能体的要求很高，主管一旦判断失误，整个任务就偏了。
6.3 通信协议与状态共享
多智能体之间的通信，我建议用“消息加共享状态”的方式。消息用于传递任务和结果，共享状态用于维护全局上下文。消息格式要统一，我一般用JSON，包含发送方、接收方、消息类型、负载、时间戳。共享状态存在Redis里，每个智能体都可以读写，但要有版本号控制，避免并发写冲突。
状态共享的一个坑是“状态膨胀”。所有智能体都往共享状态里写东西，很快状态就变得巨大无比，每次读取都要序列化反序列化，性能急剧下降。我的做法是，共享状态只存关键字段，比如任务ID、当前阶段、关键实体ID，其他细节存在各智能体自己的本地存储里，需要时通过消息传递。
7. 智能体上生产前的检查清单
7.1 功能验收：不是“能跑”就行
智能体在开发环境能跑通，不代表能上生产。功能验收要覆盖正常路径、边界情况、异常路径三类用例。正常路径就是最常见的输入，比如标准的病历文本、正常的交易请求。边界情况包括空输入、超长输入、特殊字符、多语言混合。异常路径包括工具超时、工具返回错误、模型输出格式错误、权限不足。
我一般会准备一个包含200到300条用例的测试集，覆盖这三类情况。每条用例都有预期的输出或预期的行为（比如“应该转人工”）。跑完测试集，统计通过率。通过率低于95%的，不上生产。这个标准听起来严，但医疗和金融场景容错率本来就低，宁可多测几轮。
7.2 性能压测：并发下的稳定性
智能体的性能瓶颈通常在两个地方：模型推理和工具调用。模型推理的延迟取决于模型大小和部署方式，工具调用的延迟取决于外部系统的响应速度。压测的时候，要分别测这两个环节的P50、P95、P99延迟。
我做过一个测试，单智能体在10并发下响应时间还是200毫秒，到50并发就飙到2秒，到100并发直接超时。后来发现是工具调用的连接池太小，改成连接池加异步调用后，100并发下P95延迟控制在500毫秒以内。所以压测不是走形式，是真能发现问题的。
还有一个容易被忽略的点：模型API的限流。很多团队用第三方模型API，没注意QPS限制，一上量就被限流，智能体直接不可用。上生产前一定要确认API的配额，并做好降级方案，比如限流时切换到备用模型或返回缓存结果。
7.3 监控告警：上线只是开始
智能体上线后，监控要盯住几个核心指标：调用量、成功率、平均延迟、工具调用失败率、人工转接率。这些指标要设阈值告警，比如成功率低于90%告警、平均延迟超过1秒告警、人工转接率突然升高告警。
除了技术指标，还要监控“业务指标”。比如导诊智能体的科室推荐准确率、理赔智能体的初审通过率、反欺诈智能体的拦截准确率。这些指标需要业务方配合定义和跟踪。技术指标正常但业务指标恶化，说明智能体的决策逻辑出了问题，可能是数据漂移或者模型退化。
日志要保留足够长的时间，医疗和金融场景建议至少保留一年。日志不仅要记技术信息，还要记业务上下文，比如用户输入、智能体输出、人工干预记录。这些日志是后续优化和合规审计的基础。
8. 一些实操中的个人体会
做智能体这段时间，最大的感受是：模型能力在快速进步，但工程能力才是决定成败的关键。我见过太多团队把精力全花在调提示词上，结果工具接口设计得一塌糊涂，状态管理乱七八糟，最后智能体只能在演示环境里跑跑。提示词当然重要，但它只是智能体的一小部分。真正让智能体从“玩具”变成“工具”的，是那些不起眼的工程细节：错误重试、超时控制、日志审计、权限校验。
另一个体会是，垂直领域的智能体，领域知识的质量比模型大小更重要。你用一个中等规模的模型，配上高质量的领域知识库和精心设计的工具，效果往往比用最大的模型但知识库乱七八糟要好。医疗和金融领域尤其如此，因为这些领域的知识更新快、专业性强，通用模型的知识往往滞后或者不准确。把领域知识维护好，是长期投入，但回报也最稳定。
最后说一个具体的技巧：智能体的提示词里，一定要加一句“如果你不确定，请明确说明不确定，并建议用户咨询专业人士”。这句话在医疗和金融场景里能避免很多风险。模型有时候会“自信地胡说”，加了这个约束后，它会更多地选择“我不知道”而不是硬编一个答案。对于垂直领域智能体来说，“知道自己不知道”比“什么都敢答”重要得多。
