专注AI 大模型与前沿科技深度解析习惯从工程师视角拆解技术热点让我们一起在技术浪潮中保持清醒与好奇 生成式到代理式跃迁构建保险后援数字分身QCon上海上周帮一位转行的朋友看简历他写了一个保险条款问答机器人的项目用大模型读 PDF用户提问模型回答。功能跑通了但面试官只问了一句就把他问住了——“如果用户问的是’我这份保单到底能不能赔’你的机器人怎么知道该查哪份文件、该比对哪条免责条款、该不该转人工”他答不上来。因为这个项目停留在生成式阶段给输入产出一段文本仅此而已。而真实业务要的是代理式它能自己拆解任务、调用工具、核对规则、在不确定时主动求助。这篇文章就借保险后援数字分身这个场景把从生成式到代理式的跃迁讲清楚。它不依赖任何公司内部系统你在自己电脑上就能复现一个小而完整的例子并且这段能力可以直接写进作品集。30 秒结论本文判断生成式应用的天花板是内容生成代理式应用的天花板是任务闭环。保险后援这类场景的价值不在写得多漂亮而在能不能把一件工单从头跟到尾。适用对象学过 Python 基础语法、想做出第一个能演示、能讲清楚的 AI 应用的学生或转行者。不适合谁已经在大厂做 Agent 平台、关心多租户隔离和分布式调度的工程师——这篇对你们太浅。核心门槛不是模型多强而是你会不会把业务规则拆成模型能调用的工具。关键证据证据一生成式与代理式的分界线是控制流归谁。生成式应用里控制流在你写的代码里读文件 → 拼 prompt → 调模型 → 输出。代理式应用里控制流部分交给模型它决定先查条款还是先查理赔记录决定要不要再调一次工具。这个区别决定了你的代码从流程脚本变成工具集 循环。证据二真实后援场景的失败多数不是模型答错而是没查对资料。保险后援的典型任务是客户说我住院了想理赔后援人员要确认保单有效性、险种覆盖范围、免赔额、既往症条款、所需材料清单。这里面每一步都是结构化查询 规则比对不是自由文本生成。把这类任务交给纯生成模型它会一本正经地编出一条不存在的免责条款。证据三工具调用Function Calling / Tool Use已经是当前主流大模型的标准能力。GPT-5.5、Qwen3.6 Max、GLM 5.1、DeepSeek 4.0 Pro 等当前主流模型都原生支持结构化工具调用。这意味着你不需要自己解析模型输出的 JSON模型会按你给的 schema 返回我要调用哪个工具、参数是什么。这把代理式应用的门槛从研究课题降到了工程练习。展开说明从问答到办事一个最小代理循环先看生成式的写法你大概率写过defanswer(question,docs):context\n.join(docs)promptf根据以下资料回答问题\n{context}\n\n问题{question}returnllm.generate(prompt)代理式的写法核心是一个循环tools[{name:query_policy,description:根据保单号查询保单基本信息包括生效状态、险种、保额,parameters:{type:object,properties:{policy_id:{type:string}},required:[policy_id]}},{name:check_coverage,description:检查某险种是否覆盖某类医疗行为,parameters:{type:object,properties:{policy_id:{type:string},treatment_type:{type:string}},required:[policy_id,treatment_type]}},{name:escalate_to_human,description:当信息不足或涉及纠纷时转人工后援,parameters:{type:object,properties:{reason:{type:string}},required:[reason]}}]defrun_agent(user_input,max_steps6):messages[{role:user,content:user_input}]for_inrange(max_steps):respllm.chat(messages,toolstools)ifresp.tool_calls:forcallinresp.tool_calls:resultdispatch(call.name,call.arguments)messages.append({role:tool,content:result})else:returnresp.contentreturn任务步骤超限转人工注意三个设计点它们才是面试里会被追问的第一escalate_to_human是一个工具不是兜底逻辑。把承认自己搞不定做成模型可主动选择的动作比你在外面写if confidence 0.7更符合代理式的思路。模型知道什么时候该求助这本身就是能力。第二max_steps必须有。代理循环最大的工程风险是模型反复调同一个工具、陷入死循环。给一个步数上限超了就转人工这是生产环境的基本纪律。第三工具描述就是 prompt。模型选不选对工具八成取决于description写得好不好。“查询保单信息和根据保单号查询保单生效状态、险种、保额”——后者让模型选对的概率高得多。这是最容易被忽视、也最值得练的手艺。为什么保险后援特别适合练手因为它有清晰的规则边界和明确的求助出口。医疗诊断这类场景模型错了代价太大而保险后援里转人工是一个完全可接受的正常结果。这让初学者可以在不承担高风险的前提下练习完整的代理式设计。面试/作业里常被追问的点你的工具粒度怎么定的为什么不是一个大工具包办所有查询模型调错工具时你怎么发现、怎么纠正多轮对话里历史工具调用结果怎么管理会不会越堆越长这三个问题没有标准答案但能答出你的取舍就说明你真的动手做过。落地建议今天就能做的三件事把一个小问答项目改造成代理式。找一份公开的保险条款 PDF写两个工具search_clause(keyword)和escalate(reason)。让模型自己决定先搜什么、搜不到时是否转人工。跑通这个循环你就跨过了生成式到代理式的分界线。给你的工具写三版 description对比模型选择准确率。用 10 个测试问题记录模型选对工具的比例。这个对比实验本身就是作品集里很漂亮的一页。加一个轨迹日志。每次代理循环把模型调了哪个工具、参数是什么、返回什么按顺序打印出来。这既是调试手段也是你面试时讲清楚我怎么定位问题的素材。风险与反例反例一任务本身没有工具可用。如果业务就是把这段文字润色一下那它本质上还是生成任务硬套代理式只会增加复杂度。判断标准很简单这件事需不需要查外部数据、需不需要多步决策不需要就别上代理。反例二规则极其稳定、步骤完全固定。如果理赔流程永远是查保单 → 查险种 → 查免赔额 → 出结论这四步那写死流程比让模型决策更可靠、更便宜。代理式的价值在于步骤不确定、需要根据中间结果调整的场景。反例三模型能力不足时的代理循环会放大错误。模型第一步查错了保单后面每一步都建立在错误前提上最后给你一个逻辑自洽但完全错误的结论。所以工具返回值里要带足够的原始信息让你能在日志里回溯是哪一步偏的。代理式不是生成式的升级版而是另一类问题的解法。想清楚你的问题属于哪一类比追新概念重要得多。