现在待的公司一直用 Jaspersoft 出打印单。版本很老，中文教程几乎没有。

年初 OpenClaw 火了之后，公司开始推 WorkBuddy。当时 Skill 这个概念正热——本质上就是一个 Markdown 文档包，配上几个工具调用声明。逻辑很简单：把接口文档和公司现有的几类报表模板喂给 AI，构建一个知识库，再配合一堆校验工具，让 AI 按需生成 JRXML 模板。

实际效果是：WorkBuddy 确实能产出半成品。字段定义了，band 结构也有了。但问题出在后面——随着需求的增加，每次生成的 JRXML 结构都不同，模型经常“忘记”调用校验工具，复杂嵌套 band 直接超出模型能力。半成品缩短了一部分工作量，但后续修改和校验的投入超过了人工从头写的成本。

项目卡在了一个尴尬的位置：用也不是，不用也不是。

问题不在 Skill，在控制力

复盘下来，Skill 这个模式本身有天花板：

• 随机输出：同一模板的多次修改，每次生成的 JRXML 结构可能完全不同
• 工具调用不稳定：模型不是每次都记得调用校验工具，也不一定按正确顺序调
• 智商上限真实存在：复杂报表中的字段计算及自定义字段，通用模型理解不到位

Skill 本质是 prompt + 工具列表，它不能强制工作流、验证输出、自我纠错。

所以决定做一个自定义 Agent：有结构化的生成流程、强制工具调用链、校验-修正循环。而 Agent 能做出靠谱的 JRXML，前提是它手里有靠谱的参考资料——这就是 RAG 要解决的问题。

RAG 解决什么

两个核心问题：

1. 大模型知识盲区：Jaspersoft 企业内部数据大模型拿不到，小众的领域大模型知识有限
2. 幻觉降低：让模型基于检索到的真实模板片段生成，而不是凭空编造标签和属性

在我们的场景里，RAG 的职责很明确：当 Agent 要生成一个带日期参数的 textField 时，先从知识库里检索出最相关的 JRXML 片段——参数定义怎么写、textFieldExpression 怎么嵌、band 里怎么布局——然后把原始需求 + 检索到的参考一起喂给模型。

模型基于证据输出，而不是基于记忆瞎猜。

RAG 的三段式流水线

RAG 流水线：准备数据 → 检索相关内容 → 喂给模型生成答案。

对应到 JRXML 场景：

1. 数据准备：解析 JRXML → 按语义分块 → 文本嵌入模型转向量 → 存入向量数据库
2. 检索：用户需求转向量 → 向量库相似度搜索 → 取 Top-N 结果
3. 生成：需求 + 检索到的参考模板 → LLM → JRXML

每一步都涉及大量选择——分块策略用哪种、嵌入模型选哪个、向量数据库用什么——这些选择直接决定检索质量，检索质量直接决定 Agent 生成质量。

后续内容

后续内容：

• 分块策略：从固定大小分块到语义分块，为什么 JRXML 需要领域感知的拆分方式，以及 JRXMLSemanticChunker 的实现
• 文本嵌入模型：稀疏向量 vs 稠密向量，MTEB 排行榜解读，本项目的模型选择
• 向量数据库：HNSW / IVF-PQ / Annoy 三种索引算法对比，Milvus / Qdrant / Chroma 的选型逻辑，混合搜索的实践

jaspersoft下载

jaspersoft社区版

仓库地址

rag_jrxml