Skill 模式不够用之后：一个 JRXML 自动生成 Agent 的 RAG 前置设计

现在待的公司一直用 Jaspersoft 出打印单。版本很老中文教程几乎没有。年初 OpenClaw 火了之后公司开始推 WorkBuddy。当时 Skill 这个概念正热——本质上就是一个 Markdown 文档包配上几个工具调用声明。逻辑很简单把接口文档和公司现有的几类报表模板喂给 AI构建一个知识库再配合一堆校验工具让 AI 按需生成 JRXML 模板。实际效果是WorkBuddy 确实能产出半成品。字段定义了band 结构也有了。但问题出在后面——随着需求的增加每次生成的 JRXML 结构都不同模型经常“忘记”调用校验工具复杂嵌套 band 直接超出模型能力。半成品缩短了一部分工作量但后续修改和校验的投入超过了人工从头写的成本。项目卡在了一个尴尬的位置用也不是不用也不是。问题不在 Skill在控制力复盘下来Skill 这个模式本身有天花板随机输出同一模板的多次修改每次生成的 JRXML 结构可能完全不同工具调用不稳定模型不是每次都记得调用校验工具也不一定按正确顺序调智商上限真实存在复杂报表中的字段计算及自定义字段通用模型理解不到位Skill 本质是 prompt 工具列表它不能强制工作流、验证输出、自我纠错。所以决定做一个自定义 Agent有结构化的生成流程、强制工具调用链、校验-修正循环。而 Agent 能做出靠谱的 JRXML前提是它手里有靠谱的参考资料——这就是 RAG 要解决的问题。RAG 解决什么两个核心问题大模型知识盲区Jaspersoft 企业内部数据大模型拿不到小众的领域大模型知识有限幻觉降低让模型基于检索到的真实模板片段生成而不是凭空编造标签和属性在我们的场景里RAG 的职责很明确当 Agent 要生成一个带日期参数的 textField 时先从知识库里检索出最相关的 JRXML 片段——参数定义怎么写、textFieldExpression 怎么嵌、band 里怎么布局——然后把原始需求 检索到的参考一起喂给模型。模型基于证据输出而不是基于记忆瞎猜。RAG 的三段式流水线RAG 流水线准备数据 → 检索相关内容 → 喂给模型生成答案。对应到 JRXML 场景数据准备解析 JRXML → 按语义分块 → 文本嵌入模型转向量 → 存入向量数据库检索用户需求转向量 → 向量库相似度搜索 → 取 Top-N 结果生成需求 检索到的参考模板 → LLM → JRXML每一步都涉及大量选择——分块策略用哪种、嵌入模型选哪个、向量数据库用什么——这些选择直接决定检索质量检索质量直接决定 Agent 生成质量。后续内容后续内容分块策略从固定大小分块到语义分块为什么 JRXML 需要领域感知的拆分方式以及JRXMLSemanticChunker的实现文本嵌入模型稀疏向量 vs 稠密向量MTEB 排行榜解读本项目的模型选择向量数据库HNSW / IVF-PQ / Annoy 三种索引算法对比Milvus / Qdrant / Chroma 的选型逻辑混合搜索的实践jaspersoft下载jaspersoft社区版