智能出题Agent

step 0 基本数据结构、业务框架

• 基类题型，在数据结构传递的时候以隐蔽具体的题型
  • 数据结构：
    • description: 题干
    • analysis：题目解析
    • correctAnswer：答案
    • relatedKnowledgePoints [] 相关知识点，用于统计知识点分布情况
    • totalScore：题目总分
    • difficulty: 难度
• 衍生题型
  • static 变量携带该题型的结构描述prompt
  • 单选题、判断题、填空题
    • 无需scoreDivision
  • 多选题、简答题
  • 计算型简答题（不容易保证正确率），可能需要根据参考例题来辅助推理（二创）

应用搭建框架：

• 文档解析
  • doc2x
    • 成熟，效果好
    • 仅pdf，太贵，初始经费1500不够用
  • markitdown
    • 速度快、类型支持丰富、配置要求低，免费
    • 无法提取图片，解析效果一般，结构可能混乱
  • MinerU
    • 仅pdf,api需要公司申请，每天限额+排队
    • 自部署免费，可docker,配置要求中等（消费级GPU，cpu推理太慢），将图片转化为base64返回
  • 目前计划：
    • 采用Docker部署markitdown api服务，用于频繁的测试环境，兼具速度和配置成本
    • 采用Docker部署MinerU api服务，对内存有一定要求，如果有一般的消费级显卡也可以很快推理。解析质量更好，可用于E2E测试，应用质量展示时临时部署
• 主应用搭建：
  • NextJS，省去前后端联调的问题，然后可以一键部署到Vercel上面，省去服务器运维的问题。
  • AI应用框架打算用Vercel的AI-SDK,方便统一集成多种模型服务商API格式，以及MCP，会话历史、workflow等
  • 数据库方面，目前只是要整个流程跑起来，感觉可以先不管存储，先InMemory做出来，后期需要完善的时候再用添加Supbase的pgsql即可
• 其它暂时还没想到，如果有Javascript做不了的，Python也可以直接部署到vercel。再者换成Dify/Coze搭建更高级的工作流来实现

Step 1 用户输入

教师可以上传教案文件。

• Yolo模式是否开启：用户之后的任何阶段都将自动确认，以满足陈桑的灵机一动体现完全自主的agent能力。

Step 2 Planner 阶段

构建知识点图谱（人机协作）

主LLM，以Planner Agent的角色设定和行为规范

1. 根据用户意图整理文档内容
2. 调用工具生成以下生成知识点实体

使得用户可以清晰地知道接下来将要做什么

重新生成用户可以选择重新生成计划，或者追问让LLM基于现有内容继续改动

策划考试总体任务（人机协作）

主LLM，以Planner Agent的角色设定和行为规范，根据用户意图整理文档内容，调用工具生成以下数据

• 知识点考察情况(难度、着重性)
• 各类衍生题目实体
  • 将知识点分布到各个题目上
  • 对应的难度系数和分数
  • 不包含具体的题干和答案等

重新生成用户可以选择重新生成计划，或者追问让LLM基于现有内容继续改动

手动调整用户可以对每个题目进行：

• 难度值调整
• 知识点调整
• 分数调整（需要校验总体分数是否满足）

用户确认后提交

Step 3 Build Context 构建Agent及其上下文

除了模型本身的规模和参数量，它在推理时“看见了什么”也很重要。 Agent 要高质量完成复杂任务，必须聚焦上下文（用户目的和主题，参考资料）、工具调用（分析构建知识点、构建题目）、环境感知（任务完成进度）等。 我们在这里需要动态构建Agent和管理上下文。在用户的一次会话中，我们让多次让模型模型将任务分解，以不同的角色、不同的子任务目标、不同的参考资料来完成同一个任务。

目前的想法是：

1. 通过特定的agent模板，让agent builder动态的创建新的agent system prompt

2. 动态上下文：包含构建目标的题型、目标知识信息、参考题目等， 按照知识点实体反向索引到题目以完成聚类，这样在单次交互中，抓取并充分利用一次参考资料（知识信息、参考例题）即可，并且也能保持清晰的上下文，降低知识点遗忘、重复、混乱的可能性

上下文资料来源

• AI搜索引擎抓取
  • 用于作为用户参考资料的补充知识点细节等，重复冲突情况下以用户提供的知识点为准
• 题库检索
  • 通过与具有海量题库和强性能检索服务平台的开放API，检索得到高质量的现有题目
    • “拼好题”组卷模式创新点
    • 也可以作为例题，辅助设计“好题二创”创新点
• 用户上传的参考材料RAG
  • 用户上传的材料可能很长，以及图片这种token killer（在用户上传文件的时候，可以用视觉模型将图片压缩为详尽的描述文本插入材料文本中），
  • 在分类任务时，为了合适的上下文，有可能需要需要RAG来进行召回合适的用户提供的参考资料信息

Step4 Parallel Execution 并行架构执行亮点

在前一步的构建上下文中，这样不仅能够让LLM为适量的题目生成相关性强的题目，并且提升了并行计算的可能（将groupBy后构建的上下文作为子任务，分派给多个大模型进行（并发和QPM不超限制的情况下））

补充：其它非主要功能、可选的扩展方向

其实在并行计算后，直接通过程序的方式排序汇总就应该算完成主要任务了

如果之后还有余力，可以：

1. 前端在渲染的时候按照题目顺序渲染，点击题目区域可以反向跳转到生成这个题目的agent那里，进行重新生成或者追问。

2. 还不太确定是否还需要其它的校验方案。例如，添加一个可选的Test Agent进行题目推理，为每个题目评估生成质量等、置信程度...

3. 根据任务场景，动态赋予agent以不同的长处高级模型/turbo模型等，

• 按照思考分类
  • 推理模型
  • 非推理模型
  • 自主思考模型
• 按照能力分类
  • 语言能力
  • 逻辑推理能力

项目开发说明