简介这份PDF资料面向具备一定编程基础、对AI与对话型智能体开发感兴趣的研发人员聚焦第十六届蓝桥杯项目实战赛智能体开发省赛围绕「智能阅读助手」赛题给出比赛规则与技术实现要点。内容涵盖HiAgent平台登录与答题流程、知识库与数据库物料说明以及回答准确率、响应速度、多轮上下文连贯、杜绝胡乱作答等核心目标并展开信息审查七类问题、固定格式输出、复杂内容处理与统一拒答等实现策略。资源包共1个PDF文件约553KB便于赛前快速通读与要点查阅。已有445人学习下载。读者可据此理解赛题评分导向掌握字段级索引、Session记忆、意图槽位填充、低置信度拒答与Prompt示例驱动等落地思路为智能体开发与发布提供清晰参考。1. 对话型智能体做阅读助手蓝桥杯这条赛题到底在考什么蓝桥杯智能体开发赛道上「基于对话型智能体的智能阅读助手设计」这个题目看起来像是个套壳聊天机器人实际动手做过一轮就会发现它考的不是你会不会调 API而是你能不能把「读—理解—追问—沉淀」这条链路用对话型智能体的方式串起来。我去年带学生备赛时第一版方案就是把一篇长文丢给大模型做摘要结果评委一句「用户读完还是不知道第三章在讲什么」就把我们问住了。这个赛题真正解决的是让智能体在用户阅读长文档、论文、报告时能主动拆结构、答追问、给延伸而不是被动等提问。它适合有 Python 基础、想入门智能体开发的学生也适合想用 HiAgent、Coze 这类平台快速搭原型的从业者。核心词「智能阅读助手」和「对话型智能体」会贯穿后面所有章节因为选型、记忆设计、评测口径全都围绕这两个词展开。2. 赛题规则拆解与对话型智能体的能力边界2.1 蓝桥杯智能体赛题的评分维度到底看什么蓝桥杯智能体开发类赛题通常不会只跑一个「能不能回答」的测试从历年真题和公开的评分口径看评委关注的是任务完成度、交互合理性、技术实现完整度和创新性四块。任务完成度看的是智能体能不能在给定阅读材料上完成摘要、问答、定位原文、生成笔记这些动作交互合理性看多轮对话里有没有上下文丢失、答非所问技术实现完整度看你是不是真的用了检索、记忆、工具调用而不是纯 prompt 硬扛创新性则看你有没有针对阅读场景做别人没做的设计比如章节级索引、阅读进度感知。这里有个反直觉的点很多队伍把精力全砸在模型选型上觉得换个更强的模型分数就上去了。实际评分里模型只是底座真正拉开差距的是「智能体有没有阅读状态」。一个没有阅读状态的对话型智能体用户问「刚才那段什么意思」它只能重新检索有阅读状态的智能体知道用户当前停在第几节、上一轮问了什么、哪些段落已经解释过。这个差别在交互合理性维度上直接体现为分数差。所以备赛第一步不是写代码是把评分维度翻译成技术需求任务完成度对应文档解析和检索交互合理性对应会话记忆和状态管理技术实现完整度对应工具调用和 RAG 链路创新性对应阅读场景的专属设计。这四块后面每一章都会落到具体实现。2.2 对话型智能体和普通问答机器人的分界线普通问答机器人是「一问一答」对话型智能体是「带着状态和工具去完成一个任务」。放到阅读助手场景分界线体现在三个地方。第一是记忆普通机器人每轮独立对话型智能体要维护短期会话记忆和长期阅读记忆短期记的是这轮对话聊了什么长期记的是这篇文档的结构、用户标记的重点、已经生成的笔记。第二是工具普通机器人只会生成文本对话型智能体要能调用文档解析、向量检索、章节定位、笔记写入这些工具。第三是主动性普通机器人等提问对话型智能体在用户读完一节后可以主动问「要不要我把这节的方法论整理成三步」。我一般会把这三条当成自检清单如果你的方案里没有独立的记忆模块、没有工具调用层、没有主动追问逻辑那它本质上还是个问答机器人放在蓝桥杯赛题里技术实现完整度这一项就拿不到高分。HiAgent、Coze 这类平台之所以被频繁提到是因为它们把记忆和工具调用做成了可视化配置能让你把精力放在阅读场景的逻辑设计上而不是从零搭一套 agent 框架。但平台不是必须的用 Python 加 LangChain 或直接调模型 API 也能做区别在于平台省了工程脚手架Python 方案省了平台学习成本备赛时间紧就选平台想展示底层能力就选 Python。2.3 阅读助手的能力边界哪些能做哪些别硬做备赛时最容易翻车的地方是贪多。阅读助手不是万能助手它的能力边界要提前划清楚。能做的长文档结构化解析、章节级摘要、基于原文的问答、关键概念解释、阅读笔记生成、跨章节关联。别硬做的实时联网查资料赛题环境通常不保证网络、多文档跨库检索除非赛题明确要求、图像和公式的深度理解解析成本高且容易出错、超长文档一次性塞进上下文token 限制摆在那。划边界的好处是你能把有限时间投到确定拿分的地方。比如文档解析PDF 和 Markdown 的处理难度差很多如果赛题材料是 Markdown就别花时间写 PDF 解析如果材料是 PDF那表格和公式的提取就要提前测别等到评测当天发现解析出来全是乱码。这个判断在备赛初期就要做后面第 4 章的避坑部分会展开讲解析环节的具体坑。3. 用 HiAgent 或 Python 搭出最小可跑的阅读助手3.1 文档解析与章节切分阅读助手的地基阅读助手的第一层是文档解析。不管后面用多强的模型解析出来的文本质量决定了上限。常见做法是先把文档转成纯文本再按标题层级切分成章节块。Markdown 直接按#层级切PDF 用解析库提取后按字号和空行推断标题。切分粒度我一般控制在 300 到 500 字一块太短检索时上下文不够太长塞进模型浪费 token。import re def split_by_heading(text): # 按 Markdown 标题切分保留标题作为块元数据 pattern re.compile(r^(#{1,3})\s(.)$, re.MULTILINE) matches list(pattern.finditer(text)) blocks [] for i, m in enumerate(matches): start m.end() end matches[i 1].start() if i 1 len(matches) else len(text) content text[start:end].strip() if content: blocks.append({ level: len(m.group(1)), # 标题层级1 是章2 是节 title: m.group(2).strip(), content: content }) return blocks这段代码的逻辑是先找到所有标题位置再用相邻标题的位置差切出每块内容。level字段保留下来是为了后面做章节定位用户问「第二章讲了什么」时能直接按层级过滤。参数上#{1,3}只匹配一到三级标题如果你的文档有四级标题要么加进去要么在预处理时合并别让四级标题被当成正文。切完后建议打印每块的标题和字数字数超过 800 的块要再按段落切一次否则检索时召回的内容会太杂。3.2 会话记忆与阅读状态让智能体记住「读到哪了」记忆模块是对话型阅读助手和普通问答机器人的分水岭。最小实现需要两个存储会话记忆存最近几轮对话阅读状态存用户当前章节、已解释概念、已生成笔记。会话记忆可以直接用列表维护超过一定轮数就截断或摘要阅读状态用一个字典每次用户提问或智能体回答后更新。class ReadingState: def __init__(self): self.current_section None # 当前所在章节标题 self.explained set() # 已解释过的概念 self.notes [] # 生成的笔记 self.history [] # 最近对话元素为 (role, content) def update_section(self, title): self.current_section title def add_exchange(self, role, content, max_turns6): self.history.append((role, content)) # 只保留最近 max_turns 轮防止上下文无限增长 if len(self.history) max_turns * 2: self.history self.history[-max_turns * 2:] def mark_explained(self, concept): self.explained.add(concept)current_section让智能体知道用户读到哪回答时能优先检索当前章节explained集合避免同一个概念反复解释用户问第二次时可以直接说「这个概念刚才解释过需要我换个角度吗」max_turns控制历史长度设 6 是因为再长模型也容易忽略早期内容不如截断后靠摘要补。这个类不复杂但有没有它交互合理性评分能差一档。3.3 检索增强问答把答案锚定在原文上阅读助手的问答必须锚定原文不能让模型自由发挥。做法是把切好的章节块做向量化用户提问时先检索最相关的几块再把检索结果和问题一起给模型。向量化可以用平台自带的知识库功能也可以用 sentence-transformers 本地跑。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) def build_index(blocks): texts [b[title] \n b[content] for b in blocks] embeddings model.encode(texts, normalize_embeddingsTrue) return texts, embeddings def retrieve(query, texts, embeddings, top_k3): q_emb model.encode([query], normalize_embeddingsTrue)[0] scores embeddings q_emb # 归一化后点积等于余弦相似度 idx np.argsort(scores)[::-1][:top_k] return [(texts[i], float(scores[i])) for i in idx]normalize_embeddingsTrue是关键参数归一化后点积直接等于余弦相似度省去除法。top_k3是经验值检索太多会稀释重点太少可能漏掉答案。检索回来的块要连同标题一起给模型并在 prompt 里明确「只根据以下内容回答找不到就说找不到」。这一步是防幻觉的核心没有它模型会拿自己的知识补答案评测时一问原文细节就露馅。3.4 把链路串起来一个最小可跑的对话循环前面三块拼起来就是一个最小可跑的阅读助手。流程是加载文档切块建索引进入对话循环每轮先更新阅读状态再检索再生成回答最后更新记忆。def chat_loop(blocks, state): texts, embeddings build_index(blocks) while True: query input(你) if query.strip() in (退出, exit): break # 1. 检索相关章节 hits retrieve(query, texts, embeddings) context \n\n.join([h[0] for h in hits]) # 2. 拼 prompt带上当前章节和检索内容 prompt f当前章节{state.current_section}\n参考资料\n{context}\n\n用户问题{query}\n请只根据参考资料回答。 # 3. 调用模型生成回答此处用伪函数表示 answer call_llm(prompt) # 4. 更新状态 state.add_exchange(user, query) state.add_exchange(assistant, answer) print(助手, answer)这个循环里call_llm换成平台 API 或本地模型都行。重点是第 2 步的 prompt 结构当前章节给模型定位感参考资料给事实依据最后一句约束防幻觉。跑通这个循环大概半天时间但它已经覆盖了任务完成度和技术实现完整度的基础分。后面要提分就是在每一块上加细节比如章节定位更准、记忆更聪明、主动追问更自然。4. 备赛避坑阅读助手开发中最容易翻车的五件事4.1 现象检索明明命中模型却说「资料中没有」原因通常有两个。一是检索回来的块和问题语义匹配但字面不匹配模型没认出这是答案二是 prompt 里参考资料和问题的位置太远模型注意力没覆盖到。解决方法是把检索结果放在问题前面并在每块前加「【资料1】」这样的标记让模型明确知道哪段是依据。如果还不行把 top_k 从 3 提到 5或者换一个对中文更友好的 embedding 模型。4.2 现象多轮对话后智能体忘了前面聊过什么原因是会话记忆被截断得太狠或者根本没把历史拼进 prompt。解决方法是保留最近 6 轮原文更早的对话做一次摘要存起来每轮把摘要加最近几轮一起给模型。另外阅读状态里的explained集合要真的用起来用户重复问同一个概念时智能体应该能识别并换角度解释而不是当新问题处理。4.3 现象PDF 解析出来全是乱码或段落粘连原因是 PDF 里的文字是分栏或图片形式直接提取会打乱顺序。解决方法是先用 pdfplumber 按页提取检测到分栏时按 x 坐标切列如果是扫描件要么上 OCR 要么在赛题允许范围内换材料。段落粘连可以在提取后按句号加换行做二次切分但别切太碎否则检索时上下文不够。4.4 现象评测时响应超时原因是每轮都重新建索引或者检索时遍历了全部块。解决方法是在对话开始前建一次索引并缓存检索时用矩阵运算而不是循环。如果用的是平台检查知识库是不是每次对话都重新加载是的话改成会话级缓存。另外 top_k 别设太大检索本身很快慢通常慢在模型生成控制 prompt 长度比优化检索更有效。4.5 现象智能体答得太泛没有原文细节原因是 prompt 里没有强制引用原文模型习惯性用自己的话概括。解决方法是在 prompt 里加「回答中至少引用一处原文并标明来自哪一节」生成后再做一次检查如果回答里没有原文片段就重新生成。这个约束在评测的「任务完成度」维度上很吃分因为评委能直接看到答案有没有锚定材料。5. 从能跑到能拿分阅读助手的进阶技巧与自测方法把最小链路跑通只是及格线想拿高分要在「阅读场景专属设计」上做文章。我一般会加三个东西。第一是章节级导航用户问「这篇文档结构是什么」时智能体直接输出带层级的目录并标注每节字数让用户知道哪里是重点。第二是阅读进度感知结合current_section和用户提问频率判断用户是不是卡在某一节主动问「这节需要我拆开讲吗」。第三是笔记沉淀用户说「记一下」时智能体把当前解释整理成条目存进notes最后能一次性导出。自测方法上别只测「能不能回答」要按评分维度设计测试用例。任务完成度测 10 个问题覆盖摘要、定位、解释、笔记四类交互合理性测连续 5 轮追问看有没有上下文丢失技术实现完整度检查记忆和检索是不是真的在跑可以打印中间结果验证创新性就看你有没有别人没做的设计。我习惯在备赛最后一周每天跑一遍这四类测试把失败案例记下来逐个修比盲目加功能有效得多。还有一个容易被忽略的点是 prompt 的版本管理。阅读助手的 prompt 会随着测试不断调整今天加一句约束明天改一个措辞如果没有版本记录改崩了都回不去。我的习惯是每次改 prompt 前存一份标注改了什么、为什么改、测试结果如何。这个习惯在最后冲刺阶段能省下大量「后悔药」时间因为你能清楚看到哪次改动带来了提升哪次是负优化。最后说个血泪经验备赛时别追求功能大而全把「解析准、检索稳、记忆不丢、回答有据」这四件事做到扎实比堆十个花哨功能更能拿分。评委看的是链路完整和场景贴合不是功能数量。希望帮到你。本文还有配套的精品资源点击获取
