大语言模型应用落地：构建30个垂直领域自主决策智能体

1. 为什么不是"30个Demo"，而是"30个能自己干活的业务体"

这两年我做LLM应用落地，被问得最多的一个问题是：大语言模型到底能干什么？问这句话的人，手里往往已经有一个ChatGPT账号，也试过让它写周报、润色邮件，但真到业务系统里，总觉得它像个"什么都懂一点的实习生"——懂得多，但不敢让它拍板。

这个感觉是对的。大语言模型本身只是"大脑皮层"，它擅长的是语言理解和生成，不擅长的是"在特定规则下做决定、调用外部系统、对结果负责"。而智能体（Agent）要解决的，恰恰是"把模型从聊天窗口里拉出来，放到业务流程里去干活"这件事。

我今年给自己定了一个有点"笨"的目标：手写30个能落地到垂直领域的自主决策智能体，覆盖医疗、金融、法律、教育、供应链这些行业，而不是继续做第31个"ChatGPT套壳问答机器人"。标题里写"必须构建"，不是贩卖焦虑，是因为我确实发现：只有亲手把一个智能体从选模型、写工具、定决策边界到压测上线完整走一遍，你才会真正理解大语言模型应用的门槛不在提示词，而在工程化。

这篇文章是系列的第一篇，先把框架讲清楚，再把医疗和金融两个方向的第一批智能体拆开揉碎。之所以先从医疗和金融讲起，是因为这两个行业对"自主决策"的态度最矛盾——既最需要AI分担大量判断工作，又最怕AI出错。能在这种环境里跑通的方案，放到其他行业基本是降维打击。

在动手之前，我先把30个智能体的整体思路交代一下，这样后面每一篇拆解都有坐标系。

1.1 通用助手为什么一上业务就露怯

先看一个反直觉的现象：同样一个模型，你让它在对话框里"帮我看看这份合同有什么风险"，它答得头头是道；但你要它每天自动扫描100份新合同、按风险等级分拣、把高危合同推到法务待办列表，它就露怯了。

问题出在哪？不是模型变笨了，而是任务的形态变了。对话场景是"人给出问题，模型给出答案"，业务场景是"系统给出一堆数据，模型自己发现问题、自己决定怎么办、自己调用工具执行"。后者多出来的三个环节——感知、决策、行动——恰恰是裸模型不具备的。

我见过很多团队花三个月做一个"智能客服"，上线后发现用户问"我的订单为什么还没发货"，模型答得再漂亮也没用，因为没人教它调用订单系统、没人给它查物流的API密钥、没人告诉它什么情况下可以直接补偿优惠券。这个智能体本质上只是一个"话术生成器"，不是"业务执行者"。

所以30个智能体这个系列，我只关注一件事：让大语言模型对结果负责。每个智能体必须有明确的输入、明确的输出、明确的工具调用清单，以及明确的"什么该自己做、什么该交给人"的边界。

1.2 30个智能体的排布逻辑：从"能答"到"能办"

我把30个智能体分成五条线，每条线6个，互相之间不重复、不堆叠：

• 医疗线：患者服务、临床辅助、药事管理、病案质控、随访管理、科研数据治理。
• 金融线：反欺诈、信贷审批辅助、投研信息处理、客户KYC、合规审查、舆情风险。
• 法律线：合同审查、法规检索、证据链整理、诉讼策略辅助、合规制度生成、知识产权预警。
• 教育线：个性化习题生成、学情分析、教案辅助、口语陪练、论文审阅辅助、招生咨询。
• 运营线：经营报表解读、供应链备货决策、客服工单分类、内容审核、竞品监测、会议纪要与任务拆解。

每条线里不光有"问答类"智能体，更关键的是每条线都至少有一个"手和脚"完整的闭环智能体——能读数据库、能调API、能写回结果、能触发人工审批。只有这种智能体，才算真正把大语言模型转化成了自主决策的垂直领域生产力。

2. 垂直智能体的四层骨架：模型、记忆、工具、执行闭环

剥开所有花哨的框架名词，一个能落地的垂直智能体，骨子里就是四层东西：模型层、记忆层、工具层、执行层。这四层缺一层，这个智能体就是个半成品。我一个个讲清楚，顺便把选型的坑也说了。

2.1 模型层：不是越强越好，是够用且可控

垂直智能体选模型，很多人第一反应是"上最强最大的那个开源模型"，或者"反正预算够，直接调最强的商用API"。我的经验是，这个思路在推理类任务上没问题，但在垂直场景里会翻车，原因有三个：

第一，延迟。业务系统里的智能体往往是串在流程里的，一个预问诊智能体如果每次响应要8秒，患者早就流失了。第二，成本。全用顶级模型跑高频任务，月底账单会让人肉疼。第三，可控性。很多垂直场景需要模型严格输出结构化Json，小模型的指令遵循能力反而更容易调教，大模型"想法太多"，偶尔会给你自由发挥。

我的选型建议是这样：

需要注意，我这里的"模型层级"是针对成本与效果平衡，具体型号迭代太快，不绑死在某个名字上。判断标准很简单：先拿20条真实业务数据跑一遍，看输出可用率。如果小模型能达到90%可用，就别上大模型。

2.2 记忆层：决定智能体有没有"上下文"

没有记忆的智能体，每来一个请求都是一次"失忆重启"。这在纯问答场景还能忍，在医疗、金融这种需要连续跟踪的场景里完全不行。

记忆层我习惯分两种实现：

• 短期记忆：会话里的上下文，直接用模型上下文窗口存，关键是做好窗口管理——比如预问诊智能体，患者前面回答过的内容，后面不应重复询问。
• 长期记忆：跨会话的持久化数据，落到向量数据库或结构化表。比如患者既往病史、用药史，金融机构客户的KYC画像。每次新会话启动时，先把相关记忆检索出来注入提示词。

很多人忽视记忆层，结果智能体做着做着就成了"金鱼"——七秒记忆，每轮对话都从零开始。我的经验是：长期记忆不是简单的"把所有历史都塞进上下文"，而是按任务需要做结构化压缩。比如把一个患者五次就诊的零散描述，整合成"高血压3年、二甲双胍过敏、近期血糖控制不佳"这样的结构化摘要，检索效率和准确率都会好很多。

2.3 工具层：把领域知识变成可调用的能力

工具层是垂直智能体区分于通用聊天机器人的核心。模型再聪明，不接业务系统的数据，它就只能"空对空"地回答问题。

一个医疗智能体需要的工具可能是：挂号系统查询、病历库检索、药品信息库、检验指标解读库、 ICD编码映射服务。一个金融智能体需要的工具可能是：交易流水查询、黑名单库比对、征信数据接口、舆情新闻检索、监管规则库。

工具层有三个实践要点：

• 工具接口要窄：每个工具只做一件事，参数尽量少。比如"查询患者用药记录"这个工具，入参就是患者ID，出参是结构化用药列表，不要在工具里塞一堆业务逻辑。
• 工具返回要结构化：LLM最擅长处理结构化文本，运行时先把数据格式化为JSON或Markdown表格，模型处理起来又快又准。
• 要有工具调用失败处理：在实际场景里，查库超时、接口报错、数据为空是常态。智能体不能因为工具失败就整个崩掉，而是要有重试、降级、或者如实告知用户"暂时查不到"的分支处理。

2.4 执行闭环：计划、行动、反思、再行动

纯靠一次"模型调用工具、工具返回结果、模型生成回答"的流程，做不出真正的自主决策智能体。尤其是金融反欺诈这种复杂场景，往往需要多步验证：先查交易特征，再查历史行为，再查黑名单，最后综合判断。

我用的执行闭环很简单，就是Agent圈里常说的ReAct模式的工程化变种：计划（Plan）→ 行动（Act）→ 观察（Observe）→ 再计划（Re-plan）。

具体到代码层面，就是给模型一个循环：每一步，模型先基于当前信息决定下一步调用哪个工具、传什么参数，执行工具后把结果喂回去，再判断是继续调用工具还是输出最终结论。为了防止模型在闭环里"转圈圈"，必须设置最大步数（我一般设5步），超过就强制收敛并转人工。

这个闭环是整个系列所有智能体的通用底座。后面每一篇拆解，我都会先画出这个智能体的工具调用图和决策分支，再讲具体的提示词设计和代码实现。有了这个底，你就能理解为什么我说"构建30个智能体"不是重复劳动——底座复用，但每个智能体的业务决策逻辑完全不同。

3. 第一批医疗智能体拆解：预问诊、用药核对、入组筛选

医疗方向我做了三个智能体，分别覆盖患者入口、药事安全、临床研究三个场景。选这三个，是因为它们分别代表了三类典型的智能体工作模式：采集结构化信息、交叉比对多源数据、基于规则+推理的合规筛选。搞懂这三类，医疗线剩下的就好做了。

3.1 预问诊智能体：把患者主诉整理成结构化病历

很多医院在患者就诊前都有一道"填问卷"的环节，让患者描述症状、既往病史、过敏史。但传统问卷是死板的勾选项，患者经常填得词不达意，医生重新问一遍，时间全浪费了。

我做的预问诊智能体，核心思路是让患者"像聊天一样描述症状"，后台用大语言模型把口语化的描述实时整理成结构化病历草稿。

实现上有三个关键细节：

第一，分诊分级而非直接诊断。智能体绝不能下"你这是感冒"这种诊断结论，它的职责是采集信息并做初步分诊建议——比如根据"胸痛伴随大汗"，提示"建议优先排队心内科，存在高危胸痛可能，需尽快评估"。这个边界必须写死在系统提示词和输出约束里。

第二，追问逻辑要像医生，而不是像搜索引擎。患者说"肚子疼"，直接记下来就完了？不够。好的预问诊要追问疼痛部位、性质（绞痛/胀痛/隐痛）、持续时间、诱因、伴随症状。我用的是基于NLU槽位填充的思路，给模型一个追问清单模板，按优先级逐项补齐。

第三，输出必须是医生可用的结构化数据。对话结束后，智能体生成这样一份结构化记录：

{ "主诉": "上腹部隐痛3天，饭后加重", "现病史": { "onset_time": "3天前", "character": "隐痛", "location": "上腹部", "aggravating_factor": "饭后", "accompanying_symptoms": ["反酸", "腹胀"] }, "既往史": { "chronic_disease": ["胃溃疡"], "allergy": ["青霉素过敏"], "medication": ["奥美拉唑，按需服用"] }, "生命体征": null, "triage_level": "普通门诊" }

这个JSON直接写入HIS系统（医院信息系统）的预问诊表，医生打开患者档案就能看到。我实测下来，一份完整的预问诊对话大约3-5分钟，比传统的纸版问卷信息量高出不少，关键是患者的配合度更高——聊天总比填表舒服。

3.2 用药安全核对智能体：清单比对与相互作用预警

第二个医疗智能体解决的是"用药核对"问题。它的价值非常直接：在开药环节，系统要能第一时间发现药物配伍禁忌、重复用药、剂量异常。

这个智能体的核心不是让模型"懂药理学"，而是让它准确调用药物数据库并解释规则，在需要模糊推理的地方（比如患者自述的"最近有点头晕乏力"能不能对应到某药物的不良反应）再发挥模型能力。

整体是一个规则引擎+LLM混合架构：

• 规则引擎层：用药清单里的药名、剂量、频次、相互作用，先跑一遍结构化规则库。这一层快、准、可解释，所有确定的禁忌和冲突都能抓出来。
• LLM层：处理规则引擎覆盖不了的"模糊问题"。比如患者的肾功能指标轻度异常，某种药物需要调整剂量，但数据库里没有明确的规则映射，此时让LLM基于药品说明书和临床指南给出提示，并且必须附带依据来源。
• 输出层：生成给药师和医生看的用药风险报告，按严重程度分级：红色禁忌、橙色慎用、黄色提示。

这样设计的原因很实际：纯规则引擎漏掉"模糊风险"，纯LLM会在明确禁忌上偶尔犯低级错误。双层架构把可靠性和灵活性都兼顾了。我测试过一组100条用药方案的样本，双层架构的准确率明显高于单用任一方案，最关键的是，规则引擎兜底让模型在"确定性问题"上几乎没有出错空间。

3.3 临床试验入组筛选智能体：把I/E标准变成决策流

第三个医疗智能体是给临床研究部门用的。临床试验招募患者，最大的成本在于"筛选"——把几百上千名候选患者的病历，逐条对照入排标准（Inclusion/Exclusion Criteria）。

传统做法是CRC（临床协调员）人工初筛，一份病历看十几分钟，看得头晕眼花，还容易漏项。我用智能体做初筛，思路是：先结构化抽取，再规则匹配，最后LLM补判断。

流程分三步：

• 结构化抽取：从患者病历文本中，用LLM抽取试验方案关心的关键字段，包括诊断、分期、既往治疗史、关键检验指标、合并用药、年龄性别等。
• 规则匹配：把入排标准转成可执行的条件表达式。比如"HbA1c ≤ 9%"、"既往无免疫治疗史"，这些直接代码比对。
• LLM补判断：有些标准是语义性的，比如"依从性良好者""无明显器官功能障碍"。这类没法写成严格公式，就让LLM根据病历中的描述给出"建议/存疑/不建议"三档判断，并把判断依据原文引用出来，方便人复核。

整个筛选从"人看10分钟"压缩到"机器30秒出结果"。但我要强调：这个智能体的定位是"初筛辅助"，最终入组决定必须由研究者确认。我甚至会在界面上刻意把"存疑"的患者标成醒目的黄色，而不是直接排除——宁可让人多看一眼，也不能让机器误杀一个本可入组的患者。

4. 金融线第一个"发钱"智能体：反欺诈初筛仲裁的实现笔记

金融方向我做了不少，但第一个拿出来写的是反欺诈初筛仲裁智能体。原因很简单，这个智能体是目前所有30个里唯一一个有资金处置权限的——它能直接冻结异常交易，是真"发钱相关"的决策体，对自主决策的边界问题最有代表性。

4.1 场景与输入输出定义

场景是这样的：支付平台每天有海量交易，规则引擎会先跑一遍，自动拦截明显欺诈的交易（比如命中黑名单卡号、超高频小额试探）。但总有一批"灰色交易"——初筛命中了一些风险特征，但又不满足自动拦截的硬规则。这批交易积压下来，靠人工风控专员逐笔审核，效率极低，而且审核标准容易受个人疲劳影响。

我的智能体就干这个活：对规则引擎标记为"存疑"的交易逐笔做深度评估，输出三级结论——放行、冻结、转人工，并附带决策依据。

输入是一笔交易的结构化数据加上相关上下文，包括：交易金额、时间、设备指纹、IP归属地、收款方历史、付款方近期行为序列、是否命中任何灰名单标签。输出是JSON格式的决策结果。

4.2 核心代码：决策链、工具调用与置信度

构建的时候，我的核心不是写花哨的提示词，而是把决策链拆成模型可以一步一步走的工具序列。下面是我的参考实现：

def fraud_review_toolchain(transaction_data: dict, agent_memory: dict) -> dict: """ 反欺诈初筛仲裁智能体的主流程。 transaction_data: 交易原始数据 agent_memory: 会话期记忆，包含历史评估记录 """ # 工具层：可供LLM调用的函数清单 tools = [ { "name": "query_payer_history", "description": "查询付款方近30天交易历史，返回时间序列摘要", "args": {"payer_id": transaction_data["payer_id"]} }, { "name": "query_payee_risk_score", "description": "查询收款方风险分值与历史投诉记录", "args": {"payee_id": transaction_data["payee_id"]} }, { "name": "query_device_risk", "description": "查询设备指纹在风控黑名单/白名单的命中情况", "args": {"device_id": transaction_data["device_id"]} }, { "name": "check_watchlist", "description": "检查交易双方是否命中监管关注名单", "args": {"payer_id": transaction_data["payer_id"], "payee_id": transaction_data["payee_id"]} } ] # 执行闭环：模型逐步决定调用哪些工具，观察结果后再给出结论 decision_result = run_agent_loop( system_prompt=FRAUD_SYSTEM_PROMPT, tools=tools, initial_input=transaction_data, max_steps=5, memory=agent_memory ) return decision_result

整套系统里最关键的不是这段编排代码，而是系统提示词里写的"决策原则"。我贴几段核心内容（消除敏感细节）：

你是一名反欺诈审核助手。你的任务是审核被规则引擎标记为"存疑"的交易。 处理原则： 1. 先调用工具收集信息，禁止仅凭单条数据下结论。 2. 判断优先级：监管名单命中 > 设备风险黑名单 > 历史欺诈关联 > 行为异常。 3. 只有满足所有条件时才输出"放行"：无监管名单命中、设备无已知欺诈关联、 收款方风险分低于阈值、付款方行为序列无明显异常。 4. 任何涉及大额、首次交易、异常时段、境外IP的组合，默认输出"转人工"。 5. 输出必须使用JSON格式，包含：conclusion, confidence, critical_facts, suggested_actions, audit_trace。

这段提示词的精髓是预设了决策边界：智能体可以在一定程度上自主判断（放行/冻结），但高风险组合必须"转人工"输出。这就是垂直领域智能体和大模型裸用的最大区别——模型的能力不变，但业务规则给它的决策空间画好了红线和安全通道。

4.3 上线前必须压测的边界案例

这类智能体上线前，我做了大量边界案例测试。有些测试结果让我后背发凉，这里列出来给你参考：

• 短时间内高频小额试探后的一个大额交易：模型容易只盯着大额交易本身判断，忽略前序试探行为。解决办法是把"付款方近30天交易行为序列摘要"变成必选工具，每次判断前必须先拉取该数据。
• 信息不足时不自觉脑补：当工具查询超时或数据缺失时，模型总倾向于"根据经验判断"。我的处理是：任一关键工具调用失败，强制走转人工，禁止脑补。
• 收款方是新注册但多笔小额交易：模型容易直接判为"洗钱特征"，但实际可能是正常收款码。处理方法是增加"商户历史稳定交易占比"这个维度，降低误杀率。

压测完这些案例，我得出一个结论：智能体的风控能力，一半在模型推理，一半在工具设计。工具给不到的数据，模型再聪明也只能猜。所以与其反复调提示词，不如把工具层的数据覆盖率做扎实，然后把"数据缺失就走转人工"写死成规则。

5. 自主决策的权限边界：三级授权、审计追踪、人工回退

写到这里，肯定有人会问：又是医疗又是金融，智能体到底有没有"自己做主"的权限？我的回答是：有，但必须分级。这是整个系列里我认为最值得单独拿出来讲清楚的部分，因为它决定了智能体是"生产力"还是"事故源"。

5.1 三级决策权限：建议级、执行级、监督级

我给智能体的决策权限设计了三个级别，每个智能体在初始化时就必须明确自己属于哪一级：

• 建议级（Level 1）：只输出建议和分析，由人来拍板。"诊断辅助""合同风险提示"都属于这一级。这类智能体错了，最坏的结果是人看了个错误建议，还有防线。
• 执行级（Level 2）：可以在明确边界内自动执行，比如反欺诈智能体冻结命中强规则的高危交易、预问诊智能体自动写入结构化病历草稿。这类智能体错了，会直接产生业务影响，所以必须配审计。
• 监督级（Level 3）：可以跨系统自动执行并自动触发下游流程，比如自动调整库存备货、自动驳回恶意退款。这类智能体我目前只会在运营场景小范围试点。

把绝大多数智能体定在"建议级+执行级混合"是最稳妥的起步姿势。我在第2节说的"放行/冻结/转人工"三级结论，本质上就是把决策权限动态拆开：低风险场景执行级，高风险场景回退到人工。这个设计不需要预判所有情况，核心是让智能体"自己知道自己能决定什么、不能决定什么"。

5.2 审计日志：让每一次自主决策可复盘

只要给了智能体执行权限，审计就必须跟上。我做的审计追踪包含两个维度：

• 决策痕迹：记录了模型每次调用的工具、观察到的结果、中间推理、最终结论。这一步的意义在于，任何一个决策出问题，审计人员能在五分钟后搞清楚"它为什么这么决定"。
• 人工确认痕迹：所有转人工的记录，必须保留人工review后的结论——是同意冻结还是驳回冻结。这些人工反馈会作为反馈样本沉淀下来，用于后续调优。

实际操作中，我会把审计日志设计成追加式、不可篡改的结构，审计员只能读不能改。这样加上完整审计链路，业务方和监管方才有安全感。

5.3 医疗与金融的"红线"指令

不同行业，智能体的红线不同。我总结了一套自己的红线清单，作为每个智能体初始化时的强制内容：

• 医疗方向：不做出诊断结论、不开具处方、不自行调整用药方案。智能体的输出永远是"辅助提示"，最终处方权和诊断权归医生。任何"建议急诊"级别的指令输出，必须在界面上强提醒，并附上判读依据。
• 金融方向：大额、跨境、名单内交易的最终冻结权必须由授权人员确认。智能体可以"建议冻结"，但"执行冻结"必须满足预设的强条件。智能体不能因为自动决策导致客户资金长时间不可用。

说到底，自主决策智能体的本质不是"替代人"，而是"替代重复劳动，把人的注意力集中在异常和复杂案件上"。医疗和金融这两个行业尤其如此，实践时红线宁可多画几条，也不要让一个聪明的模型在真实业务里放飞自我。

6. 30个的排布逻辑：先解决"脏活累活"，再谈战略智能

最后把整个30个智能体的布局思路交代一下。有人可能觉得30个太多了，其实一旦你搭好了底座，每个智能体真正的工作量主要在"业务规则梳理"和"工具对接"上，这两个恰恰是工程活，不是研究活。

我自己的排布逻辑是三个原则：先高频后低频、先执行后战略、先局部后全局。

• 先高频后低频：优先做每天都会被调用的智能体，比如客服工单分类、预问诊、合同初筛。这种智能体使用频率高，验证快，反馈闭环也快。不要一上来就做"战略决策辅助"这种一年用不了几次的智能体。
• 先执行后战略：先做能替代重复劳动的，比如报表解读、数据录入；再做辅助决策的，比如合同条款风险判断、投资信息聚合；最后才考虑需要多智能体协作的复杂场景，比如"从舆情预警到预案生成"的完整链路。
• 先局部后全局：每个智能体先在一个业务单元跑通，跑满三个月以上再说横向复制。比如预问诊先在体检中心跑通，再逐步扩展到门诊。吉姆·柯林斯有句话：先发射子弹，命中后再发炮弹，智能体落地也是这个道理。

按这个逻辑，我目前第一批落地的是医疗线三个（预问诊、用药核对、入组筛选）和金融线三个（反欺诈初筛仲裁、信贷审批辅助初版、KYC信息结构化），每一篇单独写出来都能当独立教程用。

这个系列我打算至少拆成四篇来讲，第一篇是总纲和医疗+金融的开场；后面会深入讲法律方向的合同审查智能体、运营方向的多智能体协作、以及教育和供应链场景的落地案例。每一篇都会保持同样的实在风格——不给PPT式的架构图，给能跑的代码和踩坑记录。

最后再说一个我自己的心得：构建这30个智能体，最大的收获不是"我做了多少Agent"，而是把"怎么让一个模型在真实业务里安全地做决定"这件事想透了。模型更新换代很快，但这套"边界设计+工具编排+审计追踪"的方法论是通用的。你哪怕只打算做一个智能体，这篇文章里的四层骨架和三级权限设计，应该也够你少走不少弯路。