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小模型的指令遵循能力反而更容易调教大模型想法太多偶尔会给你自由发挥。我的选型建议是这样任务类型建议模型层级原因高频结构化抽取病历、订单、工单中端开源模型如Qwen系列中等尺寸快、便宜、输出格式稳定低频复杂推理欺诈争议判断、合同风险识别高端商用模型或大尺寸开源模型需要跨多文档综合推理实时对话预问诊、客服中端商用模型流式输出延迟体验优先代码生成/工具编排代码能力强的模型函数调用成功率差异明显需要注意我这里的模型层级是针对成本与效果平衡具体型号迭代太快不绑死在某个名字上。判断标准很简单先拿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_promptFRAUD_SYSTEM_PROMPT, toolstools, initial_inputtransaction_data, max_steps5, memoryagent_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而是把怎么让一个模型在真实业务里安全地做决定这件事想透了。模型更新换代很快但这套边界设计工具编排审计追踪的方法论是通用的。你哪怕只打算做一个智能体这篇文章里的四层骨架和三级权限设计应该也够你少走不少弯路。