技术实践

技术实践：怎么让 AI 助手真能办事？两步调用的意图识别与业务桥接

发布日期：2026-11-11·北京云帆互联·栏目：技术实践

让大模型陪聊容易，让它把事办成难。云帆轻工具的 AI 助手能建签到、出考试、建题库、做分班——用的不是模型厂商的 function calling，而是自己搭的两步调用。这篇讲这套架构怎么搭、坑在哪里。

为什么不直接用 function calling

接的模型服务没开放原生 function calling，于是用提示词约束模拟：让模型输出一份 JSON 声明「我要做什么、参数是什么」，后端解析后调用真实业务方法。效果等价，代价是要自己兜住「模型不按格式来」的各种情况——这个兜底逻辑占了实现的一小半。

第一步：意图识别 + 参数提取

第一条提示词只干一件事：读用户消息，判断属于哪个操作、把参数抽出来，输出 {"intent":"create_exam","params":{"title":"期中数学","qualifyScore":70}} 这样的 JSON。意图枚举里写死每个操作需要哪些参数、哪些必填，还带一组推断规则——「爬山」「团建」这类词指向活动报名，「下周三」这种相对时间换算成具体日期。

第二步：桥接层执行，结果回填

解析出的意图进入一个分发分支：每个意图对应一个业务桥接方法。桥接方法把参数塞进业务 DTO 调用真实服务，智能默认值在这里补全——考试没说要多久就 60 分钟、没说及格线就 60 分。执行结果（成功与否、分享链接、二维码、管理页地址）回传给第二次 AI 调用，让模型基于真实结果生成回复，而不是凭空编。

结果怎么变成界面上的卡片

回复末尾追加一段 HTML 注释形态的元数据块，里面装结构化字段：分享链接、管理地址、二维码、标题、类型。前端渲染时剥掉注释、按类型渲染成富卡片——「复制链接 / 下载二维码 / 前往管理」按钮就这么来的。HTML 注释在纯文本流里对用户不可见，又天然能随 SSE 分片传输。

两个兜底，保住体验下限

• JSON 解析失败（模型输出带了代码块围栏、前后缀废话），先做格式清洗再解析，还失败就降级成普通对话，不让用户看到报错。
• 业务执行抛异常，不吞掉：把失败结果回填给第二次调用，让回复如实说明原因，用户知道卡在哪一步。