生成式到代理式跃迁：构建保险后援数字分身｜QCon上海

在水一缸

51人浏览 · 2026-10-01 12:01:37

在水一缸 · 2026-10-01 12:01:37 发布

🌊 专注 AI 大模型与前沿科技深度解析，习惯从工程师视角拆解技术热点，让我们一起在技术浪潮中保持清醒与好奇 🚀

生成式到代理式跃迁：构建保险后援数字分身｜QCon上海

上周帮一位转行的朋友看简历，他写了一个"保险条款问答机器人"的项目：用大模型读 PDF，用户提问，模型回答。功能跑通了，但面试官只问了一句就把他问住了——“如果用户问的是’我这份保单到底能不能赔’，你的机器人怎么知道该查哪份文件、该比对哪条免责条款、该不该转人工？”

他答不上来。因为这个项目停留在生成式阶段：给输入，产出一段文本，仅此而已。而真实业务要的是代理式：它能自己拆解任务、调用工具、核对规则、在不确定时主动求助。

这篇文章就借"保险后援数字分身"这个场景，把从生成式到代理式的跃迁讲清楚。它不依赖任何公司内部系统，你在自己电脑上就能复现一个小而完整的例子，并且这段能力可以直接写进作品集。

An abstract conceptual image depicting a constella

30 秒结论

本文判断：生成式应用的天花板是"内容生成"，代理式应用的天花板是"任务闭环"。保险后援这类场景的价值不在写得多漂亮，而在能不能把一件工单从头跟到尾。
适用对象：学过 Python 基础语法、想做出第一个"能演示、能讲清楚"的 AI 应用的学生或转行者。
不适合谁：已经在大厂做 Agent 平台、关心多租户隔离和分布式调度的工程师——这篇对你们太浅。
核心门槛：不是模型多强，而是你会不会把业务规则拆成模型能调用的工具。

关键证据

证据一：生成式与代理式的分界线是"控制流归谁"。
生成式应用里，控制流在你写的代码里：读文件 → 拼 prompt → 调模型 → 输出。代理式应用里，控制流部分交给模型：它决定先查条款还是先查理赔记录，决定要不要再调一次工具。这个区别决定了你的代码从"流程脚本"变成"工具集 + 循环"。

证据二：真实后援场景的失败，多数不是模型答错，而是没查对资料。
保险后援的典型任务是：客户说"我住院了想理赔"，后援人员要确认保单有效性、险种覆盖范围、免赔额、既往症条款、所需材料清单。这里面每一步都是结构化查询 + 规则比对，不是自由文本生成。把这类任务交给纯生成模型，它会一本正经地编出一条不存在的免责条款。

证据三：工具调用（Function Calling / Tool Use）已经是当前主流大模型的标准能力。
GPT-5.5、Qwen3.6 Max、GLM 5.1、DeepSeek 4.0 Pro 等当前主流模型都原生支持结构化工具调用。这意味着你不需要自己解析模型输出的 JSON，模型会按你给的 schema 返回"我要调用哪个工具、参数是什么"。这把代理式应用的门槛从"研究课题"降到了"工程练习"。

展开说明

从"问答"到"办事"：一个最小代理循环

先看生成式的写法，你大概率写过：

def answer(question, docs):
    context = "\n".join(docs)
    prompt = f"根据以下资料回答问题：\n{context}\n\n问题：{question}"
    return llm.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"]
        }
    }
]

def run_agent(user_input, max_steps=6):
    messages = [{"role": "user", "content": user_input}]
    for _ in range(max_steps):
        resp = llm.chat(messages, tools=tools)
        if resp.tool_calls:
            for call in resp.tool_calls:
                result = dispatch(call.name, call.arguments)
                messages.append({"role": "tool", "content": result})
        else:
            return resp.content
    return "任务步骤超限，转人工"

注意三个设计点，它们才是面试里会被追问的：

第一，escalate_to_human 是一个工具，不是兜底逻辑。 把"承认自己搞不定"做成模型可主动选择的动作，比你在外面写 if confidence < 0.7 更符合代理式的思路。模型知道什么时候该求助，这本身就是能力。

第二，max_steps 必须有。 代理循环最大的工程风险是模型反复调同一个工具、陷入死循环。给一个步数上限，超了就转人工，这是生产环境的基本纪律。

第三，工具描述就是 prompt。 模型选不选对工具，八成取决于 description 写得好不好。“查询保单信息"和"根据保单号查询保单生效状态、险种、保额”——后者让模型选对的概率高得多。这是最容易被忽视、也最值得练的手艺。

为什么保险后援特别适合练手

因为它有清晰的规则边界和明确的求助出口。医疗诊断这类场景，模型错了代价太大；而保险后援里，"转人工"是一个完全可接受的正常结果。这让初学者可以在不承担高风险的前提下，练习完整的代理式设计。

面试/作业里常被追问的点：

你的工具粒度怎么定的？为什么不是一个大工具包办所有查询？
模型调错工具时你怎么发现、怎么纠正？
多轮对话里，历史工具调用结果怎么管理？会不会越堆越长？

这三个问题没有标准答案，但能答出你的取舍，就说明你真的动手做过。

落地建议

今天就能做的三件事：

把一个小问答项目改造成代理式。 找一份公开的保险条款 PDF，写两个工具：search_clause(keyword) 和 escalate(reason)。让模型自己决定先搜什么、搜不到时是否转人工。跑通这个循环，你就跨过了生成式到代理式的分界线。
给你的工具写三版 description，对比模型选择准确率。 用 10 个测试问题，记录模型选对工具的比例。这个对比实验本身就是作品集里很漂亮的一页。
加一个"轨迹日志"。 每次代理循环，把模型调了哪个工具、参数是什么、返回什么，按顺序打印出来。这既是调试手段，也是你面试时讲清楚"我怎么定位问题"的素材。