通俗讲解：Agent Skill和智能体的技术概念

简单场景介绍：

医保基金管理，简单说就是 “医保钱袋子的全流程管家”—— 负责医保基金的筹集、支付、监管等全环节工作，核心目标是让有限的医保基金 “花在刀刃上”，既保障参保人能合规报销医疗费用，又防止基金浪费，确保基金长期可持续运转。​

类比理解：就像一个大家庭的 “医疗开支管家”，要先收齐全家人的 “医保费”（筹集），安全存好（存储），家人看病时按规矩给钱（支付），还要盯着没人乱花钱、骗钱（监管），确保钱够全家长期用。

一、基础概念篇：从 “智障” 到 “能思考” 的进化

Q1：大模型（LLM）到底是啥？一开始就这么聪明吗？

A：一开始就是个 “文字接龙机器”！参数小的时候跟 “智障” 似的，只会顺着上一个字往下编 —— 比如你输入 “医保基金审核”，它可能瞎编 “医保基金审核要吃好喝好”，逻辑完全不通。

后来，参数越做越大（比如从几亿涨到上千亿），突然 “开窍” 涌现出智能：你再输入 “医保基金审核中，门诊报销需要哪些材料”，它能接 “门诊报销需提供医保电子凭证、门诊病历、费用清单、发票原件，注意发票需加盖医疗机构收费章，报销时限一般为出院后 3 个月内”，不仅通顺还精准贴合医保规则。

为了跟之前的 “智障版” 区分，就加了个 “大” 字 —— 恭喜，你 get 了第一个新词 “大模型”！

Q2：对话功能是咋来的？大模型天生就会聊天？

A：哪有天生！原本它只会 “一锤子买卖”，输出完就结束 —— 比如你问 “医保基金审核时，住院费报销比例是多少”，它丢给你 “在职职工 85%，退休人员 90%”，你再追问 “异地住院报销比例会降吗”，它就接不上了，因为没有连续对话的逻辑。

后来，有人想了个招：把角色分成 “提问的” 和 “回答的”，人为搞成一问一答模式 —— 比如在 Prompt 里写 “你是医保审核顾问，我问问题你解答，要跟着我的追问继续回应，结合医保政策”，这才实现了连续聊天：

你：“医保基金审核时，住院费报销比例是多少？”

大模型：“在职职工在定点三级医院住院，医保报销比例为 85%；二级医院 88%，一级医院 92%；退休人员报销比例比在职职工高 5 个百分点。”

你：“异地住院报销比例会降吗？”

大模型：“会的！异地就医未办理备案的，报销比例一般降低 10%-20%；已提前办理异地就医备案的，按参保地同级别医院比例报销。比如在职职工异地三级医院住院，未备案报销比例可能降至 65%-75%，已备案仍按 85% 报销。”

简单说，就是给 “文字接龙机器” 加了个 “医保顾问剧本”，让它知道要跟着政策节奏聊天。

Q3：Prompt、Context、Memory 这仨 “洋词” 到底啥意思？

A：说白了就是医保审核员 “指挥” 大模型的小技巧：

Prompt：有工作要求吗？你跟大模型（就叫它小 L）说话的内容，起了个洋气名，其实就是 “审核相关指令”。比如你说 “模拟医保基金审核，判断这笔门诊费用是否符合报销条件：患者感冒就诊，开具感冒药（医保目录内）和保健品（医保目录外），总费用 300 元”，这句话完整的指令就是 Prompt；

Context：有背景信息吗？指令里的背景信息，比如 “参保地为北京，患者是在职职工，医保缴费满 5 年”，这些就是 Context—— 相当于给小 L 的 “审核背景”，让它判断时贴合北京医保政策和患者身份，不会按其他地区政策判断；

Memory：如何追问？小 L 本来不会追问，你就把之前的审核记录塞进 Context 里，假装它有 “记忆”。比如：

你第一次问：“北京在职职工门诊报销起付线是多少？”（Prompt）；

小 L 回复：“北京在职职工门诊报销起付线为 1800 元，累计超过起付线的部分按比例报销”；

你追问：“那刚才说的 300 元门诊费能报销吗？”—— 这时候系统会把 “参保地北京、在职职工、起付线 1800 元、门诊费 300 元” 这些历史记录塞进 Context，小 L 就知道要结合起付线判断，回复 “不能报销。该患者门诊费用 300 元未达到 1800 元的起付线，且其中保健品属于医保目录外费用，即便超过起付线也不予报销”。

这就是 Memory 的本质：“把历史审核对话当背景”，骗小 L 能连续追问处理审核相关问题。

二、高级功能篇：给大模型（小名：小 L） 配 “工具” 和 “助手”

Q4：智能体（Agent）听着老科幻了，到底是啥高科技？

A：纯纯 “新瓶装旧酒”！小 L 不会查实时医保政策、不会核对患者参保信息，你就写了个小程序，帮它干这些 “体力活”—— 比如你让小 L“审核患者张三的异地住院报销申请：张三是上海退休职工，在广州三级医院住院，费用 5 万元，已办理异地备案”，小 L 自己不知道上海退休职工异地报销比例和起付线，就会触发那个小程序（Agent）：

Agent 收到小 L 的 “求助”：“需要查询上海退休职工异地住院报销比例、广州三级医院异地就医起付线”；

Agent 自动调用医保政策数据库 / 官方接口，查到 “上海退休职工异地备案后三级医院报销比例 90%，广州异地就医起付线 1500 元”；

Agent 把查到的结果反馈给小 L；

小 L 把结果整理成审核结论，回复你：“经审核，患者张三符合异地住院报销条件：起付线 1500 元，可报销金额 =（50000-1500）×90%=43650 元；需补充材料：异地就医备案表、住院费用明细单、出院小结。”

这个小程序就叫 Agent，看着像有智能，其实就是个 “医保政策查询传话筒 + 材料核对工具人”，核心还是多加了一段 Prompt（告诉小 L “不知道医保政策就找 Agent 帮忙”），说难听点就是 “概念编造”。

Q5：RAG、Function Calling、MCP 这些缩写能说人话吗？

A：都是医保审核员、小 L、工具之间的 “约定”：

RAG（检索增强生成）：小 L 不懂的地方医保政策、医院收费标准，从本地医保文档、政策数据库里搜相关片段，塞进 Context 里帮它 “涨见识”，相当于给小 L 配了 “医保政策参考书”。比如你让小 L“根据 2024 年北京医保新政，判断肿瘤靶向药报销需满足哪些条件”，但小 L 没学过 2024 年新政，RAG 就会从你上传的《2024 北京医保新政文件》里搜 “肿瘤靶向药报销” 相关内容：“需提供基因检测报告、医生开具的靶向治疗适应症证明、药品属于医保目录内靶向药清单”，再把这段内容传给小 L，小 L 就能准确回复审核条件；

Function Calling：Agent 和小 L 沟通的格式约定，比如提前说好 “小 L 需要查医保政策，就必须用‘{"工具":"医保政策查询","参保地":"XX","查询内容":"XX","人员类型":"XX"}’这种 JSON 格式说”，方便 Agent 解析。比如小 L 不能随口说 “查上海退休职工异地报销比例”，得按约定格式输出，Agent 一看就知道要调用医保政策工具、查上海的、内容是异地报销比例、人员类型是退休职工 —— 就像医保系统和医院系统约定接口格式，没啥神秘的；

MCP（模型上下文协议）：Agent 和医保工具之间的约定，比如 “调用医保政策查询工具要用 Tools call 方法，传参是参保地、查询内容、人员类型，返回结果是 JSON 格式”，相当于工具的 “使用说明书”。比如 Agent 要查上海退休职工异地报销比例，就按 MCP 约定的方法调用医保政策工具，工具收到参数后，按约定格式返回 “比例 90%、起付线 1500 元”，Agent 才能看懂并传给小 L。

Q6：Skill、Workflow、Sub Agent 又是啥？折腾这些干啥？

A：为了让小 L 能办 “复杂医保审核任务”：

Workflow：固定审核流程的 “傻瓜版编程”，比如你要做 “接收患者报销申请→核对参保信息→检索医保政策→判断报销比例→生成审核结论→通知患者补充材料”，不用写代码，在 Workflow 工具里拖拽组件：“申请接收”→“参保核对”→“政策检索”→“比例计算”→“结论生成”→“通知发送”，再设置好每个步骤的参数（比如参保核对要对接医保系统、政策检索要调用 2024 新政文档），点击运行，系统就会自动按流程完成审核 —— 适合非技术岗的医保审核员，不用懂代码也能处理批量报销申请；

Skill：把审核 Workflow 的说明写成文档，让 Agent 自己选流程，比如你写个 Skill 文档：“如果用户需要处理医保报销审核，先判断报销类型（门诊 / 住院 / 异地），再核对参保状态，检索对应类型的医保政策，计算报销金额，最后判断是否需要补充材料”，再把各种报销类型的核对脚本、政策检索脚本放在一起。当你说 “审核李四的门诊特殊病报销申请”，Agent 就会看 Skill 文档，自动选 “门诊特殊病审核流程”：“核对参保状态→检索门诊特殊病政策→计算报销比例→判断材料完整性”，不用你手动拖拽 —— 本质是把 Prompt 换个地方存，往游戏英雄技能方向凑热度；

Sub Agent：处理复杂审核任务时，分个 “子审核员”，比如你让 Agent“批量审核 100 份异地住院报销申请，筛选不符合条件的申请并标注原因，生成审核汇总表”。主 Agent 会把 “逐份核对参保信息” 分给 Sub Agent 1，“检索每份申请对应的异地政策并计算金额” 分给 Sub Agent 2，“筛选不符合条件的申请” 分给 Sub Agent 3，自己只负责统筹：让 Sub Agent 1 把参保异常的申请标记出来，Sub Agent 2 把政策适用错误的申请标注原因，最后汇总成表格。Sub Agent 1 的审核记录（比如哪些患者参保断缴）不会存到主 Agent 里，避免主 Agent 的上下文太臃肿 —— 其实就是 “审核上下文隔离”，不让子任务的垃圾信息占内存。

三、灵魂拷问篇：这些概念到底有用没用？

Q7：Function Calling 和 MCP、Skill 和 MCP 有啥区别？谁能取代谁？

A：完全不是一回事，别瞎比：

Function Calling 是 Agent 和小 L 的约定（让小 L 说话守规矩）：比如小 L 要查医保政策，必须按 Function Calling 约定的格式说，不然 Agent 看不懂；MCP 是 Agent 和医保工具的约定（让 Agent 会用工具）：比如 Agent 要调用参保信息核对工具，必须按 MCP 约定的方法传参（患者身份证号、参保地），不然工具不干活。举个例子：小 L 说 “{"工具":"参保信息核对","身份证号":"110XXXXXXX","参保地":"北京"}”（这是 Function Calling），Agent 按 MCP 约定的 “Tools call（工具名 = 参保信息核对，参数 = 身份证号 + 参保地）” 调用工具，工具返回 “参保状态正常，缴费满 6 年”—— 俩八竿子打不着；

Skill 是 “医保审核技能手册”，MCP 是 “医保工具使用说明书”，Skill 能包含 MCP 的功能：比如你在 Skill 文档里写 “调用参保信息核对工具时，用 Tools call 方法，传参是身份证号和参保地，返回后判断参保状态是否正常”，相当于把 MCP 的约定写进了 Skill 里。未来常用医保工具（比如参保核对、政策检索）会直接内置进 Agent，不用再单独约定 MCP，MCP 大概率要被淘汰。

Q8：LangChain、Workflow、Skill、纯 Agent 哪个好用？

A：从 “死板” 到 “灵活” 排个队：

LangChain：纯编程，死板但稳定，程序员专用。比如程序员用 LangChain 写代码：“第一步读取门诊报销申请→第二步调用参保核对工具→第三步检索门诊政策→第四步计算报销金额→第五步生成结论”，代码写死了，每次只能处理门诊报销，要处理住院报销就得改代码；

Workflow：拖拽式低代码，比编程灵活点，但不如 Skill 方便。比如你拖拽 “住院报销申请→异地备案核对→住院政策检索→金额计算→结论生成”，下次要处理门诊特殊病就重新拖拽组件，不用改代码，但还是得手动选流程；

Skill：让 Agent 自己看 “医保审核技能手册” 干活，兼顾灵活和稳定，医保审核员也能用。比如你说 “审核王五的门诊特殊病报销申请”，Agent 看 Skill 文档，自动选 “门诊特殊病审核流程”，不用你手动操作；

纯 Agent：全靠它自己判断，最灵活但容易瞎折腾。比如你说 “审核一批医保报销申请”，它可能自己判断 “先分类（门诊 / 住院）→再核对参保→再检索政策→再计算金额”，但也可能画蛇添足，比如给符合条件的申请也标注 “需补充无关材料”，把简单审核搞复杂。

结论：Skill 最实用，Workflow 和 MCP 迟早变 “鸡肋”。

Q9：所有新概念的核心逻辑是啥？有没有通杀的理解方法？

A：就俩字：“凑上下文”！不管是 Search、RAG 还是 Skill，本质都是把更多医保相关信息塞进 Context 里，让小 L 显得更懂审核：比如你让小 L “审核一笔罕见病药品报销申请”，Search 会搜最新罕见病医保目录塞进 Context，RAG 会搜参保地罕见病报销政策塞进 Context，Skill 会把 “罕见病报销需提供诊断证明、药品处方、基因检测报告” 的要求塞进 Context；Agent 就是个 “医保审核甩手掌柜”，把能固定的流程（比如参保信息核对）用程序搞定，模糊的判断（比如药品是否属于罕见病目录）交给小 L。最终都是为了省审核时间、降低审核门槛 —— 比如审核员不用自己翻几百页医保政策，Agent 和小 L 配合就全搞定了。

Q10：未来这些概念会咋样？医保从业者该咋应对？

A：别被花里胡哨的名词忽悠！未来一定会有 “超级医保审核 Agent”，把所有 Skill、MCP 都打包好 —— 比如医保局用的 “智能医保审核系统”，审核员直接上传报销申请，系统自动调用参保核对工具、政策检索工具，生成审核结论和补充材料清单，不用你配置任何参数。就像现在的医保结算系统，没人会关心它背后用了啥协议、啥框架，知道能快速审核就行。记住：所有大模型概念，最终都是为了 “让医保审核更高效、更准确”，搞复杂了的都是过渡产物！比如现在你不用懂 “MCP 协议”，也能用上智能审核工具，未来更是如此 —— 管它叫啥，能帮你少翻政策、少出错就行！

初级核心概念（大模型运作的底层基础）

大模型（LLM）：参数规模足够大后 “涌现智能” 的语言模型，从 “文字接龙机器” 进化为能精准贴合医保政策、解答审核问题的智能体，是所有功能的核心载体。

Prompt（指令）：医保审核员向大模型下达的具体任务指令，比如 “判断某门诊费用是否符合报销条件”，是触发大模型工作的 “开关”。

Context（上下文）：指令中的背景信息（如参保地、患者类型、医保缴费年限），为大模型提供审核依据，确保判断贴合具体场景。

Memory（记忆）：将历史审核对话、前期查询结果纳入 Context，让大模型能连续处理追问（如先问起付线、再问具体费用能否报销），模拟 “连续审核” 能力。

中级扩展概念（为大模型赋能的工具 / 协议）

智能体（Agent）：辅助大模型完成 “体力活” 的小程序，可调用医保政策数据库、参保信息系统等工具，帮大模型查询实时政策、核对参保状态，本质是 “传话筒 + 工具人”。

RAG（检索增强生成）：为大模型配备 “医保政策参考书”，可从本地新政文档、收费标准库中检索相关片段（如肿瘤靶向药报销条件），补充进 Context 提升审核准确性。

Function Calling（函数调用）：Agent 与大模型的沟通格式约定（如 JSON 格式），确保大模型提出的工具使用需求（如查异地报销比例）能被 Agent 准确解析。

MCP（模型上下文协议）：Agent 与医保工具（如参保核对工具、政策查询工具）的调用约定，明确传参方式、返回格式，相当于工具的 “使用说明书”。

高级协作概念（处理复杂审核任务的模式）

Workflow（工作流）：固定审核流程的低代码工具，通过拖拽组件（如 “申请接收→参保核对→政策检索→结论生成”）实现批量报销申请的自动化处理，适合非技术岗审核员。

Skill（技能）：整合审核流程说明与工具脚本的 “技能手册”，让 Agent 能自动匹配审核场景（如门诊特殊病、异地住院），无需手动设置流程，本质是 Prompt 的固化存储。

Sub Agent（子智能体）：处理复杂任务时的 “子审核员”，负责单一子任务（如逐份核对参保信息、计算报销金额），实现上下文隔离，避免主 Agent 信息臃肿。

LangChain：纯编程式流程实现工具，程序员通过代码固定审核步骤，死板但稳定，仅适用于技术人员。