1. 为什么“30 个智能体”不是噱头而是 AI 工程师的能力分水岭过去一年我面试过不少挂着“AI 工程师”头衔的候选人简历上写着熟悉 LLM、做过 RAG、调过 Agent但真让他设计一个能在医疗场景里自主完成“分诊—追问—建议—转诊”闭环的智能体多数人卡在第二步他不知道该让模型在什么条件下停下来问人什么条件下自己决策。这就是“会调 API”和“能构建自主决策智能体”之间的鸿沟。大语言模型本身只是一个概率生成器它没有记忆、没有工具、没有边界感更不会为决策负责。所谓“智能体”本质上是给 LLM 套上一套感知—规划—行动—反思的循环结构再把它放进一个垂直领域的约束框架里。医疗、金融这类领域对错误零容忍所以智能体的设计重点不是“让它更聪明”而是“让它知道什么时候不该自作主张”。我打算用几篇的篇幅把 30 个必须构建的智能体逐个拆开讲。这一篇先解决三个问题智能体的通用架构到底由哪些模块组成、医疗和金融两个领域的智能体在设计逻辑上有什么本质差异、以及构建第一个可用的垂直领域智能体时最容易踩的坑在哪里。如果你正在做智能体开发或者准备面试智能体相关岗位这篇内容可以直接当作设计参考。提示本文讨论的“自主决策”指的是在预设规则和置信度阈值内的有限自主不是让模型脱离约束自由行动。垂直领域智能体的第一原则永远是可控性优先于能力上限。2. 拆开一个智能体LLM 之外还缺哪四块拼图2.1 感知层把非结构化输入变成模型能吃的“信号”很多人以为智能体的起点是 prompt其实起点是输入规范化。医疗场景里用户可能发来一段语音转文字的病诉、一张化验单照片、或者一句“我胸口疼了三天”。这些输入格式完全不同如果直接丢给 LLM模型会浪费大量 token 在理解格式上而不是做决策。感知层的核心任务是把多模态输入统一成结构化字段。以医疗分诊智能体为例我会设计一个前置解析模块把输入映射成如下结构{ chief_complaint: 胸痛, duration: 3天, severity: 未明确, accompanying_symptoms: [], vital_signs: null, source_type: text }这个结构不是随便定的它对应的是后续决策所需的最小信息集。缺了severity和accompanying_symptoms智能体就无法判断是否需要紧急转诊。感知层的价值在于它决定了智能体“看到”的世界是什么样子。如果感知层丢掉了关键字段后面的规划再精妙也是空中楼阁。实操中我习惯用规则引擎加小模型做第一层解析再用 LLM 做兜底补全。纯靠 LLM 抽取字段在长文本和口语化表达下召回率会明显下降而规则引擎对“胸痛”“呼吸困难”这类关键词的命中率反而更稳。2.2 规划层让模型学会“先问什么、后做什么”规划层是智能体最像“智能”的部分也是最容易做砸的部分。常见错误是让 LLM 一次性输出完整行动计划结果模型在第一步就编造了不存在的检查项。我的做法是把规划拆成意图识别—槽位填充—路径选择三步。意图识别判断用户想干什么咨询、分诊、挂号、复诊槽位填充检查当前信息是否足够做决策路径选择根据前两步结果决定下一步动作。这三步可以用一个状态机来管理LLM 只负责在状态转移时做判断而不是从头生成整个流程。以金融领域的信贷咨询智能体为例状态机大致长这样当前状态触发条件下一状态动作初始用户提问意图识别调用分类模型意图识别意图贷款咨询信息收集追问收入、用途信息收集槽位完整资质预判调用规则引擎资质预判命中高风险人工转接生成转接摘要资质预判低风险方案推荐调用产品库这张表看起来简单但它解决了一个关键问题LLM 不需要记住整个流程只需要在每一步做局部判断。这大幅降低了模型幻觉对整体流程的影响。我试过让 GPT-4 直接输出完整信贷审批流程十次里有三次会漏掉“收入验证”环节而状态机方案下这个环节是强制经过的。2.3 行动层工具调用的边界比工具数量更重要行动层负责把规划结果变成实际动作查数据库、调 API、发消息、生成文档。这里最大的误区是追求工具数量觉得接的工具越多智能体越强。实际上工具越多模型选错工具的概率越高。我在医疗智能体里只保留四类工具知识库检索、预约系统接口、紧急转诊接口、人工客服转接。每类工具都有明确的调用条件比如紧急转诊接口只有在severity高且accompanying_symptoms包含危险信号时才允许调用。这个限制不是写在 prompt 里让模型自觉遵守而是在代码层做硬校验。def call_emergency_referral(patient_state): if patient_state.severity ! high: raise PermissionError(非紧急状态禁止调用转诊接口) if not has_danger_signal(patient_state.accompanying_symptoms): raise PermissionError(缺少危险信号需人工复核) return referral_api.submit(patient_state)这种硬校验看起来笨但它把“模型判断”和“系统约束”分开了。模型可以建议转诊但最终是否执行由代码决定。金融场景同理转账、授信这类动作必须有独立的权限校验层不能依赖 LLM 的自我约束。2.4 反思层智能体自己发现“我刚才是不是答错了”反思层是区分“玩具智能体”和“生产级智能体”的关键。没有反思层的智能体错了就一路错到底有反思层的智能体能在生成回答后做一次自检发现置信度低或信息冲突时主动降级处理。我的做法是在输出前加一个轻量校验步骤用另一个 prompt 让模型回答三个问题——当前回答是否引用了未经验证的信息、是否遗漏了用户明确提到的关键症状、是否给出了超出智能体权限的建议。任何一个问题答案为“是”就把回答降级为“建议咨询专业医生/顾问”并触发人工转接。这个反思步骤会增加约 15% 的 token 消耗和 200-400ms 延迟但在医疗和金融场景里这个代价完全值得。我实测过一个没有反思层的分诊智能体它在用户明确说“对青霉素过敏”的情况下仍然推荐了阿莫西林原因就是规划层没有把这个槽位传给行动层。反思层能拦住这类跨层信息丢失问题。3. 医疗智能体在“不能出错”和“必须有用”之间找平衡3.1 分诊智能体的核心不是诊断而是风险分层很多人做医疗智能体第一反应是让它做诊断。这是方向性错误。诊断需要资质智能体不能碰。真正有价值的是风险分层把用户按紧急程度分成“立即就医”“24小时内就医”“可观察”“可自我护理”四档然后给出对应的行动建议。风险分层的逻辑可以用规则加模型混合实现。规则部分处理明确危险信号比如胸痛伴呼吸困难、意识模糊、持续高热模型部分处理模糊描述比如“不太舒服”“有点晕”。规则优先于模型因为规则的可解释性和稳定性远高于模型。我设计的分诊智能体在输出时会附带一个置信度标签置信度含义输出策略高规则命中或模型高置信直接给出分层建议中模型中等置信给出建议并提示“建议结合线下检查”低信息不足或模型低置信追问关键信息不给出分层这个设计的好处是用户能感知到智能体的“不确定”而不是被一个看似确定的错误建议误导。实测中低置信度场景占比约 20%其中大部分通过一轮追问就能提升到中或高置信度。3.2 追问策略问对问题比问多问题更重要医疗智能体的追问不能像问卷调查一样一条条列那样用户会失去耐心。我的策略是按信息增益排序每次只问当前最能改变分层结果的那个问题。比如用户说“肚子疼”信息增益最高的问题不是“疼了多久”而是“疼痛位置在哪里”。因为位置直接决定风险分层右下腹疼痛需要警惕阑尾炎上腹疼痛可能关联胃部问题全腹疼痛则可能涉及更紧急的情况。位置信息拿到后再问持续时间和伴随症状。这个排序逻辑可以用决策树来实现每个节点选择信息增益最大的特征。LLM 在这里的作用是把决策树的输出转化成自然的追问话术而不是让 LLM 自己决定问什么。我试过让 LLM 自由追问结果它经常在用户已经说了“疼了三天”之后还问“疼了多久”这种低级重复会严重损害用户体验。3.3 医疗智能体的合规红线在哪里医疗智能体有三条红线不能碰不做诊断、不开处方、不替代医生做治疗决策。这三条必须写进系统 prompt同时在代码层做输出过滤。比如智能体输出中出现“你患有”“建议服用”“确诊为”这类表述时自动拦截并替换为“根据你描述的情况建议尽快就医由医生做进一步判断”。输出过滤不能只靠关键词匹配因为模型会换说法。我的做法是训练一个小型分类器判断输出是否包含诊断性表述分类器阈值设得比较低宁可误拦不可漏放。误拦的代价是用户多看到一句“建议就医”漏放的代价可能是法律风险两者不对等。另外医疗智能体的知识库必须标注来源和更新时间。我见过一个智能体引用五年前的指南给出建议而该指南已经更新。知识库检索时应该带上时间过滤优先返回近三年的内容超过五年的内容需要显式标注“该信息可能已过时”。4. 金融智能体在“效率”和“风控”之间走钢丝4.1 信贷预审智能体的决策链路设计金融智能体和医疗智能体的最大区别是医疗智能体的错误可能导致健康风险金融智能体的错误直接导致资金损失。所以金融智能体的决策链路必须每一步都可追溯、可回滚。信贷预审智能体的典型链路是身份核验—收入评估—负债计算—风险评分—额度建议。每一步的输出都写入审计日志包含输入数据、模型版本、决策依据、置信度。如果最终用户对结果有异议可以逐层回溯是哪一步出了问题。风险评分环节我倾向于用规则引擎而非 LLM。LLM 适合做信息抽取和话术生成但不适合做数值计算和阈值判断。让 LLM 算负债收入比它可能在长对话中算错小数点规则引擎不会。LLM 在金融智能体里的正确定位是“翻译官”把用户口语化的需求翻译成结构化参数把规则引擎的输出翻译成用户能理解的话术。4.2 反欺诈智能体的实时性要求与架构取舍反欺诈场景对延迟极其敏感用户提交申请后超过 2 秒没响应转化率就会明显下降。这意味着反欺诈智能体不能走“LLM 深度思考”路线必须把大部分判断放在轻量模型和规则上LLM 只处理边缘案例。我的架构是三层过滤第一层规则引擎处理黑名单、频繁申请、设备异常等明确信号响应时间控制在 50ms 内第二层轻量模型处理行为序列异常响应时间 200ms 内第三层 LLM 只处理前两层无法判断的模糊案例响应时间放宽到 1-2 秒。实测下来90% 的申请在前两层就能完成判断只有 10% 进入 LLM 层。这个架构的关键是层间路由逻辑。什么情况下把案例升级到下一层需要有明确的置信度阈值。阈值设得太松LLM 层压力大、延迟高设得太紧漏掉欺诈案例。我通常用历史数据做回溯测试找到使漏报率和误报率之和最小的阈值点。4.3 金融智能体的可解释性为什么比准确率更重要在金融场景里一个准确率 95% 但无法解释的模型往往不如一个准确率 90% 但每步决策都能说清楚原因的模型。因为金融决策涉及用户权益用户有权知道“为什么我被拒了”。如果智能体只能说“模型判断你有风险”这在合规上是过不了的。我的做法是让每个决策节点都输出自然语言解释。规则引擎输出“近三个月申请次数超过 6 次触发频繁申请规则”模型输出“收入稳定性评分低于阈值主要影响因素是近六个月收入波动较大”。这些解释会汇总成一段用户可读的说明同时写入审计日志。LLM 在这里的作用是把技术性解释转化成用户友好话术但不能改变解释的实质内容。我会在 prompt 里明确要求“不得添加原始解释中没有的原因”并在输出后做一致性校验确保转化后的话术没有引入新信息。5. 从零构建第一个垂直领域智能体的实操路径5.1 先定边界再写代码智能体设计文档该包含什么我见过太多人一上来就写 prompt、调 API结果做到一半发现流程走不通回头改架构成本极高。正确的顺序是先写设计文档文档至少包含五部分领域边界智能体能做什么、不能做什么、状态机图所有状态和转移条件、工具清单每个工具的调用条件和权限、失败降级策略每类失败如何兜底、评估指标怎么判断智能体是否合格。以医疗分诊智能体为例领域边界写清楚“不提供诊断、不开具处方、不替代医生”状态机图列出初始、追问、分层、转接、结束五个状态工具清单只有知识库检索和转接接口两个失败降级策略规定模型超时或置信度过低时统一转人工评估指标包括分层准确率、追问轮次、用户满意度。这份文档不需要很长但必须写。我自己的经验是写文档花两小时能省掉后面至少两天的返工。5.2 用状态机管流程用 LLM 管语言这是我在多个智能体项目里验证过的最稳架构。状态机负责流程控制LLM 负责语言理解和生成。两者通过结构化数据交互LLM 不直接控制流程跳转。具体实现上我用 Python 的transitions库管理状态机每个状态对应一个处理函数。处理函数里调用 LLM 做意图识别或话术生成但状态转移条件由代码判断。比如from transitions import Machine class TriageAgent: states [initial, collecting, stratifying, referring, done] def __init__(self): self.machine Machine(modelself, statesTriageAgent.states, initialinitial) self.machine.add_transition(start, initial, collecting) self.machine.add_transition(enough_info, collecting, stratifying, conditionhas_minimum_info) self.machine.add_transition(need_more, collecting, collecting) self.machine.add_transition(high_risk, stratifying, referring) self.machine.add_transition(low_risk, stratifying, done)has_minimum_info是一个纯代码函数检查槽位是否填满。LLM 只负责从用户输入里抽取槽位不参与“是否继续追问”的判断。这个分工让流程极其稳定我压测过 500 轮对话没有出现流程卡死或跳错状态的情况。5.3 评估智能体不能只看准确率我常用的四个指标准确率在垂直领域智能体里是个有欺骗性的指标。一个把所有案例都判为“低风险”的分诊智能体准确率可能有 80%但它漏掉了所有高风险案例。我用的评估指标是四个高风险召回率高风险案例中被正确识别的比例这个指标优先级最高目标 100%。追问效率平均追问轮次目标控制在 3 轮以内。降级率需要转人工的比例目标控制在 15% 以内。用户修正率用户主动纠正智能体理解的比例目标低于 5%。这四个指标需要一起看。高风险召回率 100% 但追问效率 10 轮用户体验太差追问效率 2 轮但降级率 40%智能体价值太低。我通常先保高风险召回率再优化其他三个。5.4 上线前必须做的对抗测试我踩过的三个坑第一个坑是同义表述覆盖不足。测试时用“胸痛”能正确触发高风险但用户说“胸口发闷”“心口疼”就漏了。解决办法是建同义词库在感知层做归一化同时用 LLM 做同义扩展生成测试用例。第二个坑是多轮对话中的信息覆盖。用户第一轮说“疼了三天”第三轮说“其实断断续续疼了一周”智能体如果只记住第一次的信息就会判断错误。解决办法是在状态机里维护一个槽位版本号新信息覆盖旧信息时记录变更日志。第三个坑是工具调用超时处理。知识库检索接口偶尔会超时如果没有超时降级策略智能体会卡在“正在查询”状态。我的做法是给每个工具调用设 3 秒超时超时后返回“暂时无法查询建议直接就医/咨询人工”并记录超时事件用于后续优化。6. 智能体面试里真正会被问到的三个问题如果你在准备智能体相关岗位的面试面试官大概率不会问你“什么是 Agent”而是会问场景题。我整理了自己被问过和问过别人的三个高频问题。第一个问题是“你的智能体怎么处理用户前后矛盾的信息”。这个问题考的是状态管理和冲突解决。好的回答应该提到槽位版本管理、冲突检测规则、以及必要时向用户确认的策略。差的回答是“让 LLM 自己判断”因为 LLM 在多轮对话里对矛盾的敏感度并不稳定。第二个问题是“智能体调用外部工具失败时怎么办”。这个问题考的是降级设计。我期望听到的是分层降级重试一次、切换备用工具、返回兜底话术、转人工。只回答“捕获异常”是不够的因为没有说明降级后的用户体验如何保障。第三个问题是“你怎么评估一个智能体是否可上线”。这个问题考的是评估体系。只回答准确率会被追问“高风险场景准确率够吗”好的回答会区分不同风险等级的指标要求并提到对抗测试和线上灰度。这三个问题的共同点是它们都不考 LLM 本身而是考智能体作为系统的工程设计能力。这也印证了我一直说的观点——构建智能体的核心难点不在模型而在模型之外的流程、边界和降级设计。7. 我在实际项目里总结的几条硬经验第一条经验是不要追求智能体的“全能”。我做过一个试图覆盖分诊、咨询、预约、随访四个功能的医疗智能体结果每个功能都做得不深用户满意度反而低于只做分诊的单一功能智能体。后来拆成四个独立智能体各自优化整体效果明显提升。垂直领域智能体的价值在于深度不在于广度。第二条经验是把 LLM 当组件而不是当大脑。LLM 擅长语言理解和生成不擅长流程控制、数值计算、状态管理。把这些任务交给代码LLM 只做它擅长的事系统稳定性和可维护性都会好很多。我现在的项目里LLM 调用点通常不超过五个每个都有明确的输入输出格式和失败处理。第三条经验是日志比 prompt 重要。智能体出问题时第一反应不应该是改 prompt而是看日志。日志里记录了每步的输入、输出、状态转移、工具调用结果。我遇到过用户投诉智能体“答非所问”查日志发现是感知层把“头晕”错误解析成了“头痛”改解析规则后问题解决prompt 一个字没动。第四条经验是上线只是开始。智能体上线后需要持续收集失败案例每周做一次失败复盘把新发现的边界情况补充到测试集和规则里。我维护的一个医疗智能体上线三个月后高风险召回率从 92% 提升到 98%靠的就是持续迭代而不是一次性调优。这 30 个智能体的构建思路本质上是一套方法论先定边界再拆流程LLM 做组件代码做控制日志做反馈。掌握这套方法具体做哪个领域的智能体只是换领域知识和工具接口的事。下一篇我会拆解金融领域里更具体的几个智能体包括反欺诈、投顾、合规审查每个都会给出状态机设计和关键代码片段。
从零构建垂直领域智能体：医疗与金融场景下的架构设计与工程实践
1. 为什么“30 个智能体”不是噱头而是 AI 工程师的能力分水岭过去一年我面试过不少挂着“AI 工程师”头衔的候选人简历上写着熟悉 LLM、做过 RAG、调过 Agent但真让他设计一个能在医疗场景里自主完成“分诊—追问—建议—转诊”闭环的智能体多数人卡在第二步他不知道该让模型在什么条件下停下来问人什么条件下自己决策。这就是“会调 API”和“能构建自主决策智能体”之间的鸿沟。大语言模型本身只是一个概率生成器它没有记忆、没有工具、没有边界感更不会为决策负责。所谓“智能体”本质上是给 LLM 套上一套感知—规划—行动—反思的循环结构再把它放进一个垂直领域的约束框架里。医疗、金融这类领域对错误零容忍所以智能体的设计重点不是“让它更聪明”而是“让它知道什么时候不该自作主张”。我打算用几篇的篇幅把 30 个必须构建的智能体逐个拆开讲。这一篇先解决三个问题智能体的通用架构到底由哪些模块组成、医疗和金融两个领域的智能体在设计逻辑上有什么本质差异、以及构建第一个可用的垂直领域智能体时最容易踩的坑在哪里。如果你正在做智能体开发或者准备面试智能体相关岗位这篇内容可以直接当作设计参考。提示本文讨论的“自主决策”指的是在预设规则和置信度阈值内的有限自主不是让模型脱离约束自由行动。垂直领域智能体的第一原则永远是可控性优先于能力上限。2. 拆开一个智能体LLM 之外还缺哪四块拼图2.1 感知层把非结构化输入变成模型能吃的“信号”很多人以为智能体的起点是 prompt其实起点是输入规范化。医疗场景里用户可能发来一段语音转文字的病诉、一张化验单照片、或者一句“我胸口疼了三天”。这些输入格式完全不同如果直接丢给 LLM模型会浪费大量 token 在理解格式上而不是做决策。感知层的核心任务是把多模态输入统一成结构化字段。以医疗分诊智能体为例我会设计一个前置解析模块把输入映射成如下结构{ chief_complaint: 胸痛, duration: 3天, severity: 未明确, accompanying_symptoms: [], vital_signs: null, source_type: text }这个结构不是随便定的它对应的是后续决策所需的最小信息集。缺了severity和accompanying_symptoms智能体就无法判断是否需要紧急转诊。感知层的价值在于它决定了智能体“看到”的世界是什么样子。如果感知层丢掉了关键字段后面的规划再精妙也是空中楼阁。实操中我习惯用规则引擎加小模型做第一层解析再用 LLM 做兜底补全。纯靠 LLM 抽取字段在长文本和口语化表达下召回率会明显下降而规则引擎对“胸痛”“呼吸困难”这类关键词的命中率反而更稳。2.2 规划层让模型学会“先问什么、后做什么”规划层是智能体最像“智能”的部分也是最容易做砸的部分。常见错误是让 LLM 一次性输出完整行动计划结果模型在第一步就编造了不存在的检查项。我的做法是把规划拆成意图识别—槽位填充—路径选择三步。意图识别判断用户想干什么咨询、分诊、挂号、复诊槽位填充检查当前信息是否足够做决策路径选择根据前两步结果决定下一步动作。这三步可以用一个状态机来管理LLM 只负责在状态转移时做判断而不是从头生成整个流程。以金融领域的信贷咨询智能体为例状态机大致长这样当前状态触发条件下一状态动作初始用户提问意图识别调用分类模型意图识别意图贷款咨询信息收集追问收入、用途信息收集槽位完整资质预判调用规则引擎资质预判命中高风险人工转接生成转接摘要资质预判低风险方案推荐调用产品库这张表看起来简单但它解决了一个关键问题LLM 不需要记住整个流程只需要在每一步做局部判断。这大幅降低了模型幻觉对整体流程的影响。我试过让 GPT-4 直接输出完整信贷审批流程十次里有三次会漏掉“收入验证”环节而状态机方案下这个环节是强制经过的。2.3 行动层工具调用的边界比工具数量更重要行动层负责把规划结果变成实际动作查数据库、调 API、发消息、生成文档。这里最大的误区是追求工具数量觉得接的工具越多智能体越强。实际上工具越多模型选错工具的概率越高。我在医疗智能体里只保留四类工具知识库检索、预约系统接口、紧急转诊接口、人工客服转接。每类工具都有明确的调用条件比如紧急转诊接口只有在severity高且accompanying_symptoms包含危险信号时才允许调用。这个限制不是写在 prompt 里让模型自觉遵守而是在代码层做硬校验。def call_emergency_referral(patient_state): if patient_state.severity ! high: raise PermissionError(非紧急状态禁止调用转诊接口) if not has_danger_signal(patient_state.accompanying_symptoms): raise PermissionError(缺少危险信号需人工复核) return referral_api.submit(patient_state)这种硬校验看起来笨但它把“模型判断”和“系统约束”分开了。模型可以建议转诊但最终是否执行由代码决定。金融场景同理转账、授信这类动作必须有独立的权限校验层不能依赖 LLM 的自我约束。2.4 反思层智能体自己发现“我刚才是不是答错了”反思层是区分“玩具智能体”和“生产级智能体”的关键。没有反思层的智能体错了就一路错到底有反思层的智能体能在生成回答后做一次自检发现置信度低或信息冲突时主动降级处理。我的做法是在输出前加一个轻量校验步骤用另一个 prompt 让模型回答三个问题——当前回答是否引用了未经验证的信息、是否遗漏了用户明确提到的关键症状、是否给出了超出智能体权限的建议。任何一个问题答案为“是”就把回答降级为“建议咨询专业医生/顾问”并触发人工转接。这个反思步骤会增加约 15% 的 token 消耗和 200-400ms 延迟但在医疗和金融场景里这个代价完全值得。我实测过一个没有反思层的分诊智能体它在用户明确说“对青霉素过敏”的情况下仍然推荐了阿莫西林原因就是规划层没有把这个槽位传给行动层。反思层能拦住这类跨层信息丢失问题。3. 医疗智能体在“不能出错”和“必须有用”之间找平衡3.1 分诊智能体的核心不是诊断而是风险分层很多人做医疗智能体第一反应是让它做诊断。这是方向性错误。诊断需要资质智能体不能碰。真正有价值的是风险分层把用户按紧急程度分成“立即就医”“24小时内就医”“可观察”“可自我护理”四档然后给出对应的行动建议。风险分层的逻辑可以用规则加模型混合实现。规则部分处理明确危险信号比如胸痛伴呼吸困难、意识模糊、持续高热模型部分处理模糊描述比如“不太舒服”“有点晕”。规则优先于模型因为规则的可解释性和稳定性远高于模型。我设计的分诊智能体在输出时会附带一个置信度标签置信度含义输出策略高规则命中或模型高置信直接给出分层建议中模型中等置信给出建议并提示“建议结合线下检查”低信息不足或模型低置信追问关键信息不给出分层这个设计的好处是用户能感知到智能体的“不确定”而不是被一个看似确定的错误建议误导。实测中低置信度场景占比约 20%其中大部分通过一轮追问就能提升到中或高置信度。3.2 追问策略问对问题比问多问题更重要医疗智能体的追问不能像问卷调查一样一条条列那样用户会失去耐心。我的策略是按信息增益排序每次只问当前最能改变分层结果的那个问题。比如用户说“肚子疼”信息增益最高的问题不是“疼了多久”而是“疼痛位置在哪里”。因为位置直接决定风险分层右下腹疼痛需要警惕阑尾炎上腹疼痛可能关联胃部问题全腹疼痛则可能涉及更紧急的情况。位置信息拿到后再问持续时间和伴随症状。这个排序逻辑可以用决策树来实现每个节点选择信息增益最大的特征。LLM 在这里的作用是把决策树的输出转化成自然的追问话术而不是让 LLM 自己决定问什么。我试过让 LLM 自由追问结果它经常在用户已经说了“疼了三天”之后还问“疼了多久”这种低级重复会严重损害用户体验。3.3 医疗智能体的合规红线在哪里医疗智能体有三条红线不能碰不做诊断、不开处方、不替代医生做治疗决策。这三条必须写进系统 prompt同时在代码层做输出过滤。比如智能体输出中出现“你患有”“建议服用”“确诊为”这类表述时自动拦截并替换为“根据你描述的情况建议尽快就医由医生做进一步判断”。输出过滤不能只靠关键词匹配因为模型会换说法。我的做法是训练一个小型分类器判断输出是否包含诊断性表述分类器阈值设得比较低宁可误拦不可漏放。误拦的代价是用户多看到一句“建议就医”漏放的代价可能是法律风险两者不对等。另外医疗智能体的知识库必须标注来源和更新时间。我见过一个智能体引用五年前的指南给出建议而该指南已经更新。知识库检索时应该带上时间过滤优先返回近三年的内容超过五年的内容需要显式标注“该信息可能已过时”。4. 金融智能体在“效率”和“风控”之间走钢丝4.1 信贷预审智能体的决策链路设计金融智能体和医疗智能体的最大区别是医疗智能体的错误可能导致健康风险金融智能体的错误直接导致资金损失。所以金融智能体的决策链路必须每一步都可追溯、可回滚。信贷预审智能体的典型链路是身份核验—收入评估—负债计算—风险评分—额度建议。每一步的输出都写入审计日志包含输入数据、模型版本、决策依据、置信度。如果最终用户对结果有异议可以逐层回溯是哪一步出了问题。风险评分环节我倾向于用规则引擎而非 LLM。LLM 适合做信息抽取和话术生成但不适合做数值计算和阈值判断。让 LLM 算负债收入比它可能在长对话中算错小数点规则引擎不会。LLM 在金融智能体里的正确定位是“翻译官”把用户口语化的需求翻译成结构化参数把规则引擎的输出翻译成用户能理解的话术。4.2 反欺诈智能体的实时性要求与架构取舍反欺诈场景对延迟极其敏感用户提交申请后超过 2 秒没响应转化率就会明显下降。这意味着反欺诈智能体不能走“LLM 深度思考”路线必须把大部分判断放在轻量模型和规则上LLM 只处理边缘案例。我的架构是三层过滤第一层规则引擎处理黑名单、频繁申请、设备异常等明确信号响应时间控制在 50ms 内第二层轻量模型处理行为序列异常响应时间 200ms 内第三层 LLM 只处理前两层无法判断的模糊案例响应时间放宽到 1-2 秒。实测下来90% 的申请在前两层就能完成判断只有 10% 进入 LLM 层。这个架构的关键是层间路由逻辑。什么情况下把案例升级到下一层需要有明确的置信度阈值。阈值设得太松LLM 层压力大、延迟高设得太紧漏掉欺诈案例。我通常用历史数据做回溯测试找到使漏报率和误报率之和最小的阈值点。4.3 金融智能体的可解释性为什么比准确率更重要在金融场景里一个准确率 95% 但无法解释的模型往往不如一个准确率 90% 但每步决策都能说清楚原因的模型。因为金融决策涉及用户权益用户有权知道“为什么我被拒了”。如果智能体只能说“模型判断你有风险”这在合规上是过不了的。我的做法是让每个决策节点都输出自然语言解释。规则引擎输出“近三个月申请次数超过 6 次触发频繁申请规则”模型输出“收入稳定性评分低于阈值主要影响因素是近六个月收入波动较大”。这些解释会汇总成一段用户可读的说明同时写入审计日志。LLM 在这里的作用是把技术性解释转化成用户友好话术但不能改变解释的实质内容。我会在 prompt 里明确要求“不得添加原始解释中没有的原因”并在输出后做一致性校验确保转化后的话术没有引入新信息。5. 从零构建第一个垂直领域智能体的实操路径5.1 先定边界再写代码智能体设计文档该包含什么我见过太多人一上来就写 prompt、调 API结果做到一半发现流程走不通回头改架构成本极高。正确的顺序是先写设计文档文档至少包含五部分领域边界智能体能做什么、不能做什么、状态机图所有状态和转移条件、工具清单每个工具的调用条件和权限、失败降级策略每类失败如何兜底、评估指标怎么判断智能体是否合格。以医疗分诊智能体为例领域边界写清楚“不提供诊断、不开具处方、不替代医生”状态机图列出初始、追问、分层、转接、结束五个状态工具清单只有知识库检索和转接接口两个失败降级策略规定模型超时或置信度过低时统一转人工评估指标包括分层准确率、追问轮次、用户满意度。这份文档不需要很长但必须写。我自己的经验是写文档花两小时能省掉后面至少两天的返工。5.2 用状态机管流程用 LLM 管语言这是我在多个智能体项目里验证过的最稳架构。状态机负责流程控制LLM 负责语言理解和生成。两者通过结构化数据交互LLM 不直接控制流程跳转。具体实现上我用 Python 的transitions库管理状态机每个状态对应一个处理函数。处理函数里调用 LLM 做意图识别或话术生成但状态转移条件由代码判断。比如from transitions import Machine class TriageAgent: states [initial, collecting, stratifying, referring, done] def __init__(self): self.machine Machine(modelself, statesTriageAgent.states, initialinitial) self.machine.add_transition(start, initial, collecting) self.machine.add_transition(enough_info, collecting, stratifying, conditionhas_minimum_info) self.machine.add_transition(need_more, collecting, collecting) self.machine.add_transition(high_risk, stratifying, referring) self.machine.add_transition(low_risk, stratifying, done)has_minimum_info是一个纯代码函数检查槽位是否填满。LLM 只负责从用户输入里抽取槽位不参与“是否继续追问”的判断。这个分工让流程极其稳定我压测过 500 轮对话没有出现流程卡死或跳错状态的情况。5.3 评估智能体不能只看准确率我常用的四个指标准确率在垂直领域智能体里是个有欺骗性的指标。一个把所有案例都判为“低风险”的分诊智能体准确率可能有 80%但它漏掉了所有高风险案例。我用的评估指标是四个高风险召回率高风险案例中被正确识别的比例这个指标优先级最高目标 100%。追问效率平均追问轮次目标控制在 3 轮以内。降级率需要转人工的比例目标控制在 15% 以内。用户修正率用户主动纠正智能体理解的比例目标低于 5%。这四个指标需要一起看。高风险召回率 100% 但追问效率 10 轮用户体验太差追问效率 2 轮但降级率 40%智能体价值太低。我通常先保高风险召回率再优化其他三个。5.4 上线前必须做的对抗测试我踩过的三个坑第一个坑是同义表述覆盖不足。测试时用“胸痛”能正确触发高风险但用户说“胸口发闷”“心口疼”就漏了。解决办法是建同义词库在感知层做归一化同时用 LLM 做同义扩展生成测试用例。第二个坑是多轮对话中的信息覆盖。用户第一轮说“疼了三天”第三轮说“其实断断续续疼了一周”智能体如果只记住第一次的信息就会判断错误。解决办法是在状态机里维护一个槽位版本号新信息覆盖旧信息时记录变更日志。第三个坑是工具调用超时处理。知识库检索接口偶尔会超时如果没有超时降级策略智能体会卡在“正在查询”状态。我的做法是给每个工具调用设 3 秒超时超时后返回“暂时无法查询建议直接就医/咨询人工”并记录超时事件用于后续优化。6. 智能体面试里真正会被问到的三个问题如果你在准备智能体相关岗位的面试面试官大概率不会问你“什么是 Agent”而是会问场景题。我整理了自己被问过和问过别人的三个高频问题。第一个问题是“你的智能体怎么处理用户前后矛盾的信息”。这个问题考的是状态管理和冲突解决。好的回答应该提到槽位版本管理、冲突检测规则、以及必要时向用户确认的策略。差的回答是“让 LLM 自己判断”因为 LLM 在多轮对话里对矛盾的敏感度并不稳定。第二个问题是“智能体调用外部工具失败时怎么办”。这个问题考的是降级设计。我期望听到的是分层降级重试一次、切换备用工具、返回兜底话术、转人工。只回答“捕获异常”是不够的因为没有说明降级后的用户体验如何保障。第三个问题是“你怎么评估一个智能体是否可上线”。这个问题考的是评估体系。只回答准确率会被追问“高风险场景准确率够吗”好的回答会区分不同风险等级的指标要求并提到对抗测试和线上灰度。这三个问题的共同点是它们都不考 LLM 本身而是考智能体作为系统的工程设计能力。这也印证了我一直说的观点——构建智能体的核心难点不在模型而在模型之外的流程、边界和降级设计。7. 我在实际项目里总结的几条硬经验第一条经验是不要追求智能体的“全能”。我做过一个试图覆盖分诊、咨询、预约、随访四个功能的医疗智能体结果每个功能都做得不深用户满意度反而低于只做分诊的单一功能智能体。后来拆成四个独立智能体各自优化整体效果明显提升。垂直领域智能体的价值在于深度不在于广度。第二条经验是把 LLM 当组件而不是当大脑。LLM 擅长语言理解和生成不擅长流程控制、数值计算、状态管理。把这些任务交给代码LLM 只做它擅长的事系统稳定性和可维护性都会好很多。我现在的项目里LLM 调用点通常不超过五个每个都有明确的输入输出格式和失败处理。第三条经验是日志比 prompt 重要。智能体出问题时第一反应不应该是改 prompt而是看日志。日志里记录了每步的输入、输出、状态转移、工具调用结果。我遇到过用户投诉智能体“答非所问”查日志发现是感知层把“头晕”错误解析成了“头痛”改解析规则后问题解决prompt 一个字没动。第四条经验是上线只是开始。智能体上线后需要持续收集失败案例每周做一次失败复盘把新发现的边界情况补充到测试集和规则里。我维护的一个医疗智能体上线三个月后高风险召回率从 92% 提升到 98%靠的就是持续迭代而不是一次性调优。这 30 个智能体的构建思路本质上是一套方法论先定边界再拆流程LLM 做组件代码做控制日志做反馈。掌握这套方法具体做哪个领域的智能体只是换领域知识和工具接口的事。下一篇我会拆解金融领域里更具体的几个智能体包括反欺诈、投顾、合规审查每个都会给出状态机设计和关键代码片段。
