上周基本把 大模型通义千问-Plus 的功能都试用的差不多了，接下来打算编写 通义千问3-VL-Plus 也就是 Qwen3系列 视觉理解模型的相关文章，大家可以关注我一波，接下来先对之前的文本模型做一个总结。

一、Vue3+Springboot3 + 千问 plus 流式前后端分离方案

文章链接：千问通义plus - 智能体应用基础使用-CSDN博客

1.1 总结

        操作流程为：在阿里云百炼平台创建千问通义 plus 单智能体，目标是专门问答特定寺庙（如南华古寺）的历史、地理、近年活动等信息；核心流程包括选择知识问答模板创建智能体，按 “仅指导行为、精准角色、限定任务、明确约束、关联知识库”5 点优化提示词（降低 token 消耗，原 5000token / 问题优化后大幅减少），创建文档搜索型知识库（推荐 Markdown 格式，单文档最大 100MB 或 1000 页、单图片 20MB）并配置索引（官方向量 v4、相似度阈值 0.2），测试（如拒答特斯拉相关问题）后发布；

1.2 思维导图

1.3 难点详解

1.3.1 智能体基础设置（核心：提示词优化）

提示词是控制智能体行为的核心，优化目标为 “提升精准性 + 降低 token 消耗”，具体优化维度及示例如下表：

优化维度	核心要求	优化前（反面示例）	优化后（南华古寺示例）	核心作用
职责定位	仅承担 “指导智能体行为”，具体信息转移至知识库	提示词包含寺庙历史、线路等内容	提示词仅定义规则，寺庙信息存入 “南华古寺知识库”	减少 token 消耗（避免重复传冗余内容）
角色定义	精准定位身份与语气，明确 “我是谁”	“你是助手，负责回答问题”（模糊）	“你的角色是「南华古寺专属讲解助手」，以专业、亲切的景区讲解员语气交流”	统一回答风格，提升用户体验
核心任务	限定任务范围，绑定场景，明确 “要做什么”	“回答用户各种问题”（宽泛）	“基于「南华古寺知识库」，回答历史沿革、修缮事件、建筑遗存、游览线路相关问题”	避免智能体处理无关任务
约束规则	分点约束 “输入（知识来源）” 和 “输出（回答风格）”	无明确规则	1. 仅用知识库内容，禁编造；2. 回答≤300 字，逻辑清晰；3. 无关问题拒答；4. 未知信息固定回复	保证回答准确性，减少无效 token
知识来源声明	明确关联知识库名称，强制调用知识库	未声明，依赖模型自身记忆	“所有回答均来源于「南华古寺知识库」，无需依赖自身记忆”	避免信息幻觉，确保来源可控

完整提示词示例：

你的角色是「南华古寺专属讲解助手」，以专业、亲切的景区讲解员语气与用户交流。

        核心任务是：基于已关联的「南华古寺知识库」，回答用户关于南华古寺的历史沿革、修缮事件、建筑遗存、游览线路等相关问题。
        回答需遵守以下规则：
        1. 知识来源约束：仅使用已关联的「南华古寺知识库」中的内容回答，禁止编造未包含的信息；
        2. 回答风格约束：语言简洁、逻辑清晰，避免冗长描述（单条回答不超过300字）；
        3. 边界约束：若用户问题与南华古寺无关，直接回复“抱歉，我仅能为你提供南华古寺相关的信息哦~”；
        4. 未知内容处理：若知识库中无对应问题的信息，回复“抱歉，暂未查询到南华古寺该方面的信息~”。
        所有回答内容均需来源于已关联的「南华古寺知识库」，无需依赖自身记忆回答。

1.4 关键注意事项

1. token 消耗控制：初始将具体信息写入提示词时，单个简单问题消耗约5000token；优化后将信息移至知识库，token 消耗大幅降低（如测试案例仅 292 输入 token）。
2. 自动同步：若选择 “从数据中心类目导入文件”，支持自动同步类目下新增文件，无需手动重新上传构建索引。
3. 文件处理功能：智能体可开启 “文件处理”，允许用户上传文档 / 图片 / 视频 / 音频，系统通过解析器提取内容用于回答，超长内容自动截断。

1.5 问题

在这里，我给大家留下三道题目，大家可以试着问问自己是否能够得出答案。

        问题 1：创建针对特定寺庙的智能体时，提示词优化的核心逻辑是什么？如何通过优化降低 token 消耗？

        问题 2：文档搜索型知识库的文件上传有哪些关键限制？为何优先推荐 Markdown 格式而非其他格式（如 Word）？

        问题 3：智能体如何精准区分 “用户问题与寺庙无关” 和 “问题相关但知识库无信息” 两种场景？处理机制是如何实现的？

二、千问通义plus - 智能体应用基础使用

文章链接：千问通义plus - 智能体应用基础使用-CSDN博客

2.1 总结

        基于前期实现的Vue3+Springboot3 + 千问 plus 流式前后端分离方案，详细阐述了在阿里云百炼平台搭建千问通义 plus 南华古寺专属单智能体的完整流程。核心目标是打造可精准解答南华古寺历史沿革、建筑遗存、修缮事件、游览线路等专属信息的问答智能体，具体涵盖智能体创建、提示词优化（核心为 “行为指导与知识分离” 以降低 token 消耗）、文档搜索型知识库搭建（含文件上传、索引配置）、功能测试及应用发布，同时明确了平台免费额度用尽转按量付费的计费规则，以及 token 管控、文件同步等关键注意事项。

2.2 思维导图

2.3 难点详解

        没有难点

三、Springboot调用单智能体

文章链接：Springboot调用单智能体-CSDN博客

3.1 总结

        在Springboot 项目中调用阿里云百炼平台单智能体（此前搭建的南华古寺专属智能体）的完整流程，核心步骤包括从阿里云百炼获取智能体应用 ID（APP_ID） 、修改代码（将原调用基础模型的GenerationParam参数类替换为智能体专属的ApplicationParam，新增智能体参数构建、流式调用与结果解析方法）、修复SseEmitter.send 参数错误（因传入 SseEventBuilder+MediaType 触发转换器异常，改为直接发送 UTF-8 字节流），最终通过测试验证（提问 “1+1 等于多少” 触发智能体边界约束，返回专属拒答话术），实现了智能体与 Springboot 项目的流式集成。

2.2 思维导图

3.3 难点详解

难点 1：调用智能体为何不能继续使用原有的 GenerationParam 参数类？两者的核心区别是什么？

答案：不能使用 GenerationParam 的原因是其设计初衷为 “调用阿里云 DashScope 基础模型（如 qwen-plus、qwen-turbo）”，参数中仅包含model（指定基础模型），无appId（智能体唯一标识），无法关联阿里云百炼平台的 “智能体 / 应用” 配置；两者核心区别如下表：

参数类	适用场景	核心参数	依赖平台配置
GenerationParam	调用基础大模型	apiKey、model、messages	不依赖百炼 “应用 / 智能体”
ApplicationParam	调用百炼平台单智能体	apiKey、appId、prompt	依赖百炼 “应用 / 智能体” 配置

难点 2：在流式调用中，为何要先通过 “发送空数据” 检查 SseEmitter 状态？若不检查会导致什么问题？

答案：先检查 SseEmitter 状态的核心目的是 “避免无效推送与资源浪费”：SseEmitter 可能因前端断开连接、超时（本文设置 60 秒）等原因提前关闭，此时调用emitter.send会触发IllegalStateException（Emitter 已完成 / 超时）；若不检查，会导致大量无效异常日志，且可能因重复尝试发送占用线程资源，影响项目性能。

难点 3：解析智能体返回结果时，为何要设计 “直接 getText + 兜底 JSON 解析” 的双重逻辑？两种解析方式分别适配什么场景？

答案：设计双重逻辑是为了 “确保结果解析的稳定性”，避免因智能体返回结构差异导致解析失败；两种方式的适配场景如下：

1. 直接result.getOutput().getText()：适配智能体正常返回场景，此时output.text字段直接存储核心应答文本，解析效率最高；
2. 兜底 JSON 解析：适配特殊场景（如智能体返回结果中output.text字段为空，但 JSON 结构中存在该字段值），通过将ApplicationResult转为 JSON 字符串，用 JSONObject 提取output.text，确保不丢失应答内容。