1. 项目概述当法律文书生成遇上智能体与评分表最近在琢磨一个挺有意思的课题就是怎么让大语言模型LLM生成的法律裁判文书质量再上一个台阶。这事儿听起来有点“高大上”但说白了核心就两个痛点第一模型生成的内容法律依据和事实细节够不够准、够不够全第二生成出来的文书结构、逻辑、法言法语能不能真正达到专业法官的水平单纯靠给模型“喂”海量文书数据然后让它“自由发挥”效果总是不尽如人意要么是法条引用似是而非要么是论证逻辑跳跃格式也不规范。所以我们团队尝试了一个新思路把整个生成过程拆解成两个核心模块智能体驱动的法律信息收集和基于评分表的引导优化。这就像是在模拟一个资深法官助理的工作流程助理智能体会主动、有策略地去检索、核实、整理案件相关的所有法律条文、司法解释、类似判例信息收集然后法官优化模块手里有一份详细的评分标准评分表他会对照这份标准对助理草拟的文书初稿进行逐项审查和修改确保最终文书在事实认定、法律适用、说理逻辑、文书格式等方方面面都无可挑剔。这个项目我们内部称之为“增强型裁判文书生成系统”。它不是一个简单的文本续写工具而是一个融合了任务分解、主动检索、多轮交互和强化学习反馈的复合型智能系统。对于法律科技从业者、对AI辅助法律文书生成感兴趣的研究者或者任何希望提升LLM在专业领域输出可控性和质量的开发者来说这个框架都提供了一个可借鉴的实践路径。接下来我就把这个项目的设计思路、核心实现细节以及我们踩过的坑毫无保留地分享出来。2. 核心架构与设计哲学2.1 为什么是“智能体”“评分表”传统的法律文书生成模型无论是基于模板填充还是端到端的序列生成其信息源主要依赖于训练数据中的统计规律。模型“知道”在某种案情描述后经常出现某条法条但它并不“理解”这条法条为什么适用也无法主动去验证这条法条是否是最新版本、是否有相关司法解释。这导致了生成内容的“静态性”和“被动性”无法应对法律数据库的动态更新也难以保证在复杂案件中论证的深度和准确性。智能体Agent的引入就是为了赋予系统“主动性”和“探索性”。我们将文书生成任务分解为一系列子任务例如“检索与本案争议焦点最相关的民法条文”、“查找近三年内类似案由的上级法院判例”、“核实原告主张的损害赔偿计算标准是否有司法解释支持”。每个子任务由一个专门的智能体来执行。这个智能体具备规划、工具调用如法律数据库API、搜索引擎、记忆和反思的能力。它不再是被动地等待输入而是像一个真正的法律研究者带着问题去主动寻找、筛选、整合信息。评分表Rubric的引入则是为了解决生成质量的“可控性”和“可评估性”问题。法律文书有极其严格的格式规范和内容要求。一份判决书在事实查明部分、本院认为部分、判决主文部分各有其写作范式。单纯依靠模型的“原始创造力”或对训练数据的模糊模仿很难稳定输出符合所有规范的高质量文本。评分表就是将这种复杂的、多维度的质量要求拆解成一系列具体、可量化、可操作的评分项。例如法律适用准确性权重30%引用的法律条文编号是否正确、是否现行有效、是否与案件性质匹配。事实与证据对应性权重25%文书中的事实陈述是否都能在证据清单中找到对应有无主观臆断。说理逻辑严密性权重20%争议焦点归纳是否准确论证过程是否环环相扣是否回应了各方诉辩意见。文书格式规范性权重15%文书结构首部、事实、理由、主文、尾部是否完整标题、编号、字体等是否符合法院文书格式标准。语言表达专业性权重10%是否使用规范的法言法语有无口语化、情绪化表达。这个评分表不仅用于最终评估更关键的是用于引导生成过程的优化。系统会尝试生成多个版本的文书段落然后用评分表去评估每个版本选择得分高的或者基于得分反馈去指导下一轮的生成或修改。这就把模糊的“写得好”变成了可以迭代优化的具体目标。2.2 系统整体工作流程整个系统的工作流程是一个多阶段的、循环迭代的过程大致可以分为四个核心阶段任务解析与智能体规划系统接收一个案件的基本描述如起诉状、答辩状摘要、证据列表。首先一个“总控智能体”会分析案情拆解出需要收集信息的子任务列表。例如对于一起劳动合同纠纷它可能规划出“检索《劳动合同法》相关条款”、“检索关于经济补偿金计算的司法解释”、“检索本地区类似案件的判决倾向”等任务。多智能体并行信息收集各个子任务被分配给不同的“信息收集智能体”。每个智能体配备不同的工具法条检索智能体连接国家法律法规数据库API确保获取最新、最权威的法条全文。案例检索智能体接入裁判文书网或商业法律数据库检索类似案例并提取其裁判要旨。计算标准智能体针对涉及金额计算的部分如利息、违约金检索相关的计算方法和标准。 这些智能体并行工作将收集到的信息法条原文、案例摘要、计算规则进行初步清洗和格式化存入一个“案件知识库”中。基于知识库的文书草稿生成一个“文书生成智能体”登场。它拥有案件描述和刚刚构建的“案件知识库”。它的任务不是凭空创造而是基于知识库中的结构化信息生成一份初步的裁判文书草稿。这个过程可以提示模型“请根据以下案件描述和提供的法律依据、参考案例撰写一份民事判决书的事实查明和本院认为部分。”评分表引导的迭代优化这是最核心的优化环节。生成的草稿会被送入“优化模块”。该模块使用我们预先定义好的评分表对草稿进行多维度评分。如果总分或某个关键维度如法律适用准确性得分低于阈值系统不会直接输出。反馈生成根据评分低的项生成具体的修改建议。例如“法律适用准确性得分低。请检查引用的《合同法》第XX条是否适用于本案的‘预约合同’性质建议参考知识库中的《民法典》第YYY条。”迭代重写将草稿和具体的修改建议反馈给“文书生成智能体”让它进行局部或整体的重写。多候选评分与选择系统也可能同时生成几个不同侧重点的版本如一个版本侧重说理一个版本侧重格式然后通过评分表选择综合得分最高的版本。 这个过程可以迭代多次直到文书评分达到满意标准或达到预设的迭代次数上限。这个流程的关键在于信息收集和文书优化不再是割裂的。评分表反馈可能揭示信息不足如“说理逻辑严密性”得分低是因为缺少支持某一论点的关键案例从而触发新一轮的智能体信息收集。系统形成了一个“收集-生成-评估-再收集/再生成”的动态闭环。3. 关键技术模块深度解析3.1 智能体Agentic法律信息收集的实现细节“智能体”在这里不是噱头它需要一套具体的架构来实现。我们参考了ReActReasoning Acting等框架的思路为每个信息收集智能体设计了标准的工作循环。智能体的核心结构规划器根据总控智能体分配的子任务思考需要分几步完成。例如任务“查找近三年商品房买卖合同纠纷中关于逾期办证违约金的判例”规划器可能分解为a) 确定案由关键词b) 确定检索的时间范围和法院层级c) 在数据库中执行检索d) 过滤与“逾期办证”直接相关的判例e) 提取违约金计算比例或判决思路。工具集这是智能体的“手”和“脚”。我们为智能体集成了多种工具search_law_database(query): 向法律法规数据库发送查询。search_case_by_keywords(keywords, year_range, court_level): 根据关键词、年份、法院层级检索案例。extract_judgment_gist(case_text): 从冗长的判决书全文中提取裁判要旨。calculate_legal_interest(principal, start_date, end_date): 计算法定利息。web_search(query): 对于某些前沿或非成文的法律实践观点谨慎使用通用搜索引擎需严格过滤结果。执行器调用工具执行动作并获取结果观察。反思器对工具返回的结果进行评估。例如检索到的法条是否已经废止检索到的案例数量是0个、1个还是100个如果是0个可能需要调整关键词如果是100个则需要进一步筛选。反思器会根据评估结果决定是继续下一步还是重新规划。记忆体记录智能体在本轮任务中的所有思考步骤、工具调用和结果。这不仅用于最终输出也用于在任务链中传递上下文。一个实操示例假设智能体任务是“检索支持精神损害赔偿的法律依据”。规划“我需要先找到关于侵权责任的一般规定然后专门查找关于人身权益侵害和精神损害赔偿的条款。”行动-观察1调用search_law_database(“侵权责任 精神损害赔偿”)返回《民法典》第一千一百八十三条第一款。反思“找到了核心条款。但可能需要更具体的司法解释来明确适用情形和计算标准。”行动-观察2调用search_law_database(“精神损害赔偿 司法解释”)返回《最高人民法院关于确定民事侵权精神损害赔偿责任若干问题的解释》。反思“主要依据已找到。任务完成。”输出将《民法典》第1183条和该司法解释的相关条文摘要结构化地存入案件知识库。注意法律信息的准确性至关重要。必须为智能体设定严格的规则优先使用权威数据库的官方API对网络检索内容必须进行可信度交叉验证任何引用的法条都必须附带生效状态和来源标识。我们曾因早期版本智能体过于“自信”地引用了一个过时的部门规章导致生成文书存在硬伤这是一个深刻的教训。3.2 评分表Rubric的设计与量化设计一份好的评分表是引导优化的“指挥棒”。它必须兼具专业性、可操作性和可计算性。评分表的设计原则维度独立各个评分项如格式、法条、逻辑应尽可能相互独立避免交叉影响便于定位问题。权重合理根据法律文书的核心要求分配权重。“法律适用准确性”和“说理逻辑”通常权重最高“格式规范性”次之“语言表达”再次之。权重可以在系统配置中调整以适应不同法院或法官的偏好。描述具体每个评分项的描述必须非常具体避免“说理充分”这样的模糊表述。应改为“说理部分是否逐项回应了原告和被告的全部上诉/答辩理由”。可评估性每一项都必须能通过规则、模型或人工辅助的方式进行评估。有些可以自动化如格式检查、法条编号正则匹配有些则需要更复杂的模型如逻辑连贯性评估。我们的一份简化版评分表示例维度子项描述评分方法权重法律适用法条引用准确性引用的法律、法规、司法解释名称、条款编号完全正确且现行有效。规则校验与法律数据库核对。模型判断引用是否与上下文匹配。15%法条适用恰当性引用的法条与案件争议焦点、法律性质高度相关无牵强附会。微调后的LLM进行相关性判断。15%事实与论证事实陈述完整性文书认定的事实能覆盖起诉状、答辩状及证据中的核心要素无重大遗漏。对比文书事实部分与输入案情摘要的实体重合度NER提取对比。10%说理逻辑连贯性从“本院认为”到“判决如下”论证过程环环相扣推理清晰无逻辑跳跃。使用逻辑关系抽取模型或通过提示词让LLM自评逻辑链完整性。20%争议焦点回应文书说理部分明确回应了各方当事人的主要诉辩意见。提取各方意见关键点检查是否在文书说理部分被提及并反驳/支持。10%文书规范结构完整性具备判决书完整的首部、事实、理由、主文、尾部等部分。规则检查通过章节标题关键词匹配。10%格式规范性法院名称、案号、当事人称谓、字体、标点等符合《法院文书格式标准》。基于模板的规则校验。10%语言表达法言法语使用规范、庄重、中立的司法文书语言避免口语、俚语、情绪化词汇。训练一个文本分类器判断语言风格或使用特定风格评估提示词。5%无语法错误语句通顺无病句、错别字。通用语法检查工具。5%总分计算总分 Σ(子项得分 * 子项权重)。每个子项得分可以是0/1是否通过也可以是0-5分的区间评分。3.3 优化引擎从评分到改进有了评分如何驱动优化这里我们探索了两种主要路径并最终倾向于两者的结合。路径一提示工程迭代优化这是最直接、成本较低的方法。将评分结果转化为给LLM的修改指令。操作将低分项和具体反馈如“法律适用准确性得分低疑似引用的《物权法》已废止请使用《民法典》相应条款”作为系统提示的一部分连同原文书草稿再次发送给生成模型要求其根据反馈进行修改。优点实现简单无需额外训练。缺点改进方向依赖提示词的质量模型可能“知其然不知其所以然”修改可能不彻底或引入新错误。迭代次数多后内容可能变得冗长或偏离初衷。路径二强化学习微调RL Fine-tuning这是更根本、但更复杂的方法。我们的项目重点尝试了GRPOGroup Relative Policy Optimization这类近端策略优化算法的变体。核心思想将文书生成模型视为一个“策略”Policy。我们不再通过提示词告诉它“怎么改”而是通过奖励Reward来训练它“怎样写更好”。评分表的总分或加权总分就是我们的奖励信号。GRPO流程简述采样对于同一个输入案件知识库让当前的策略模型生成一小批例如4个不同版本的文书。评分用我们的评分表对这批文书进行评分得到每个版本的奖励值R1, R2, R3, R4。优势计算GRPO的核心在于“组内相对优势”。它不直接使用绝对奖励值而是计算每个版本奖励相对于本组平均奖励的优势Advantage。这减少了奖励函数本身偏差带来的影响让训练更稳定。优势A_i R_i - (本组平均奖励)。策略更新根据每个版本的优势值更新模型参数使得生成高奖励高质量文书的概率增大生成低奖励文书的概率减小。同时GRPO会通过约束如KL散度确保每次更新幅度不会太大避免策略“跑偏”。优点经过训练后模型内化了高质量文书的标准能直接生成更符合要求的文本减少后期迭代次数生成质量更稳定。缺点需要构建奖励模型即我们的评分表自动化训练计算成本高且需要精心设计奖励函数以避免模型钻空子例如为了格式分高而生成无实质内容的空洞文书。我们的混合策略在系统冷启动阶段主要使用提示工程迭代优化快速验证流程并积累高质量的数据对输入-优化后输出。当积累到一定数据量后利用这些数据对预训练模型进行监督微调SFT得到一个基础更好的生成模型。最后在这个SFT模型的基础上使用GRPO进行强化学习微调让模型进一步对齐我们评分表定义的复杂、多维度的质量要求。实测表明这种分阶段的方式比直接进行RL训练更稳定效果提升也更明显。4. 系统搭建与核心环节实现4.1 技术栈选型与工具链一个可用的原型系统离不开合适的技术选型。以下是我们经过多次试错后确定的工具链核心LLM生成与推理主力GPT-4/GPT-4 Turbo或Claude 3 Opus。它们的强大推理和长上下文能力对于理解复杂案情、规划智能体任务、生成连贯文书至关重要。尽管API调用有成本但在关键环节值得投入。辅助与微调Llama 3 70B或Qwen 2.5 72B等开源模型。用于对生成内容进行初筛、评分如语言风格检查以及作为后续SFT和GRPO微调的基础模型以控制长期成本。智能体框架LangChain或LlamaIndex。它们提供了构建智能体所需的链条Chain、工具Tool、记忆Memory等高级抽象能极大简化开发流程。我们主要用LangChain来编排整个智能体的工作流。法律信息源权威数据库API采购或申请如“北大法宝”、“威科先行”等商业法律数据库的API服务这是准确性的生命线。裁判文书网通过其公开接口如有或合规的爬虫方案注意频率限制和合规性获取案例数据。自建向量知识库将常用的法律法规、司法解释文本切片后用Sentence Transformers生成向量存入ChromaDB或Pinecone。智能体需要查询时先进行向量相似度检索快速定位相关法条再通过API核实细节。强化学习框架TRLTransformer Reinforcement Learning库。它提供了与Hugging Face transformers库无缝集成的RL工具支持PPO、DPO等算法。我们需要在其基础上实现或适配GRPO的逻辑。评估与评分规则引擎自己编写Python函数用于格式、法条编号等硬性规则的检查。评估LLM使用一个专门的、经过少量指令微调的LLM如DeepSeek-R1作为“裁判员”根据我们设计的评分提示词对文书草稿进行各维度的软性评分如逻辑性、恰当性。后端与部署FastAPI构建后端服务Docker容器化部署在云服务器上。前端可以是一个简单的Web界面用于输入案情和查看生成的文书。4.2 核心代码流程示意以下是一个高度简化的、展示智能体任务规划和评分优化主循环的伪代码逻辑import langchain from scoring_rubric import LegalDocScorer class JudgmentDocGenerator: def __init__(self, llm, law_db_tool, case_db_tool, scorer): self.llm llm self.law_tool law_db_tool self.case_tool case_db_tool self.scorer scorer # 评分表实例 self.knowledge_base {} def agentic_info_collection(self, case_description): 智能体信息收集 # 1. 任务规划 planner_prompt f基于以下案件描述列出需要检索的法律信息点 描述{case_description} 请以列表形式输出。 tasks self.llm.invoke(planner_prompt) # 输出如[“劳动合同解除条件” “经济补偿金计算标准” “类似案例”] # 2. 多智能体执行 for task in tasks: if “法条” in task: agent LawRetrievalAgent(self.llm, self.law_tool) info agent.run(task) self.knowledge_base[laws].append(info) elif “案例” in task: agent CaseRetrievalAgent(self.llm, self.case_tool) info agent.run(task) self.knowledge_base[cases].append(info) # ... 其他类型智能体 return self.knowledge_base def rubric_guided_optimization(self, draft_doc, max_iterations3): 评分表引导的迭代优化 best_doc draft_doc best_score 0 for i in range(max_iterations): # 1. 评分 score_details, total_score self.scorer.evaluate(best_doc) print(f迭代 {i1}, 当前得分: {total_score}) if total_score 90: # 达到阈值停止优化 break # 2. 生成反馈 feedback self.scorer.generate_feedback(score_details) # 例如“法律适用项得分低请检查XX法条引用。” # 3. 基于反馈重写 (提示工程方式) rewrite_prompt f你是一名法官助理请根据以下反馈意见修改这份法律文书草稿 原文书 {best_doc} 反馈意见 {feedback} 请输出修改后的完整文书。 new_doc self.llm.invoke(rewrite_prompt) # 4. 评估新版本选择更好的 new_score self.scorer.evaluate(new_doc)[1] if new_score best_score: best_doc new_doc best_score new_score else: # 如果分数没提高可以尝试其他策略如细化反馈 pass return best_doc, best_score def generate(self, case_input): 主生成流程 print(阶段1: 智能体信息收集中...) kb self.agentic_info_collection(case_input) print(阶段2: 基于知识库生成初稿...) draft_prompt f请根据以下案件描述和相关法律知识撰写一份判决书草稿 案件描述{case_input} 相关法律依据{kb[laws]} 参考案例{kb[cases]} initial_draft self.llm.invoke(draft_prompt) print(阶段3: 评分表引导优化中...) final_doc, final_score self.rubric_guided_optimization(initial_draft) return final_doc, final_score, kb4.3 GRPO微调的具体实现步骤如果你决定采用强化学习来进一步提升模型以下是基于TRL库和LoRA进行GRPO微调的关键步骤数据准备你需要一个数据集其中每个样本包含案情描述 法律知识库 - 生成的文书。更重要的是你需要为每个“生成的文书”打上奖励分数。这个分数来自你自动化评分表的输出。数据集规模至少需要几千条高质量样本。奖励函数建模将你的评分表封装成一个Python函数reward_fn(text) - float。这个函数输入生成的文书文本输出一个综合奖励分数如百分制。这是GRPO训练的驱动信号。训练脚本配置关键参数示意from trl import GRPOConfig, GRPOTrainer from transformers import AutoModelForCausalLM, AutoTokenizer model_name 你的SFT后模型路径 model AutoModelForCausalLM.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) # GRPO配置 training_args GRPOConfig( output_dir./grpo-judgment-model, learning_rate1.0e-6, # RL学习率通常很小 batch_size4, # 每组样本数即“Group”的大小 mini_batch_size1, gradient_accumulation_steps4, num_train_epochs3, max_length2048, # 适应文书长度 # 关键优势计算和策略约束参数 gamma0.99, # 折扣因子在GRPO中可能作用不同但通常保留 lam0.95, # GAE参数 cliprange0.2, # 策略梯度裁剪范围 cliprange_value0.2, # 值函数裁剪范围 vf_coef0.1, # 值函数损失系数 # 使用LoRA等高效微调方法 use_peftTrue, peft_configlora_config, ) # 初始化Trainer trainer GRPOTrainer( modelmodel, argstraining_args, train_datasetyour_dataset, # 需要格式化为(instruction, reward)的形式 reward_funcs[reward_fn], # 传入你的奖励函数 tokenizertokenizer, ) # 开始训练 trainer.train()注意标准的TRL库可能尚未直接提供GRPO实现上述代码是概念示意。你可能需要基于PPOTrainer自行实现GRPO的逻辑即在一个Batch内计算每个样本奖励相对于本Batch平均奖励的优势然后用这个优势值替代传统的优势估计。这涉及到修改训练循环内部的优势计算部分。训练监控密切关注训练过程中的奖励曲线和生成样本的质量。奖励分数应该总体呈上升趋势。如果奖励分数震荡或下降可能是奖励函数设计有问题、学习率过大或Batch内样本差异过大。5. 实战挑战与避坑指南在实际开发和测试中我们遇到了无数坑。这里分享几个最典型的希望能帮你节省时间。5.1 智能体“幻觉”与信息可靠性问题智能体在规划或执行任务时可能会“捏造”一个不存在的法律依据或案例或者对检索结果进行过度解读。案例在一次测试中智能体为了完成“查找支持惩罚性赔偿的依据”任务在未找到明确法条的情况下生成了一个看似合理但完全虚构的“《消费者权益保护法实施条例》第XX条”。解决方案严格工具约束为智能体设定铁律任何法律条文、案例的引用必须来自工具调用的原始文本且必须注明具体出处如“《民法典》第XXX条来源于北大法宝API”。禁止智能体对法律内容进行概括性转述只能直接引用或严格摘录。设置反思检查点在智能体输出最终结果前增加一个“事实核查”步骤。例如让另一个LLM专门检查输出中的每一个法律引用是否都能在提供的工具调用记录中找到原始支持。如果找不到则触发重新检索或标记为“信息缺失”。人工审核回路在关键环节如最终文书生成前设置人工审核点。系统可以高亮显示所有引用的来源方便人工快速核对。5.2 评分表设计的“漏洞”与博弈问题模型可能会学会“刷分”即生成一些在评分表上得分很高但实际质量堪忧的文书。案例早期我们的“格式规范性”权重较高且主要通过检查标题是否存在来评分。结果模型生成的文书充满了“一、”、“二、”这样的标题但标题下的内容空洞重复。又或者为了提升“法条引用准确性”分数模型堆砌大量无关但正确的法条编号。解决方案引入负向惩罚项在评分表中增加对“内容空洞”、“文不对题”、“重复啰嗦”等情况的扣分项。这需要训练一个分类器或设计更精巧的提示词来检测。使用集成评估不要完全依赖一个评分模型或一套规则。结合规则校验、多个LLM评估如同时让GPT-4和Claude评分取平均或最低分、以及关键指标的人工抽查。动态调整权重设计一个动态权重机制。例如如果系统检测到模型在大量堆砌法条可以临时调高“法条适用恰当性”子项的权重降低“法条引用准确性”的权重引导模型关注质量而非数量。在RL训练中设置复杂度惩罚在奖励函数中加入对文本长度或信息熵的轻微惩罚避免模型生成无意义的冗长文本。5.3 GRPO训练的不稳定性问题GRPO/PPO等在线RL算法训练不稳定容易发散奖励分数可能剧烈波动最终模型性能反而下降。案例在训练初期奖励分数快速上升但几个epoch后生成的文书开始出现乱码或重复固定短语奖励分数崩溃。解决方案坚实的SFT基础千万不要用原始预训练模型直接做RL必须先用高质量的数据进行监督微调SFT得到一个已经初步会写法律文书的模型。RL只是在这个“好学生”的基础上进行“精雕细琢”。较小的学习率RL训练的学习率通常要比SFT小一个数量级例如1e-6 vs 1e-5。过大的学习率会导致策略更新过快立即破坏SFT学到的知识。严格的KL散度惩罚在损失函数中增加KL散度项的系数强制新策略与旧策略或SFT模型的输出分布不要偏离太远。这是防止模型“学坏”的关键。小批量与多轮检查使用较小的batch size并频繁地在验证集上评估生成效果不仅仅是看奖励分数更要人工阅读一些样本确保内容没有变质。准备好随时回滚到之前的检查点。奖励函数的平滑与裁剪对奖励函数进行标准化处理如减去均值除以标准差使其分布更稳定。也可以对极端奖励值进行裁剪防止单个样本对梯度产生过大影响。5.4 系统延迟与成本控制问题多轮智能体调用、多次LLM生成、迭代优化导致单次文书生成耗时可能长达数分钟API调用成本也急剧上升。解决方案缓存与索引对常见的法律条文、司法解释建立本地向量索引。智能体优先查询本地缓存未命中再调用外部API。对相似的案情可以缓存最终的知识库和文书实现近似匹配的快速返回。模型层级化并非所有步骤都需要最强大的模型。任务规划、最终优化可以用GPT-4但信息提取、格式初检、简单评分可以使用小得多的开源模型如7B-13B参数级别通过量化技术部署在本地。优化迭代策略不是每次都需要迭代到满分。可以设置一个合理的分数阈值如85分和最大迭代次数如3次。达到任一条件即停止。对于分数接近阈值的可以只针对最低分的1-2个维度进行优化而不是全文重写。异步与队列将生成任务放入队列允许用户提交后异步处理通过通知告知完成。这样用户体验不会因等待而变差。这个项目让我们深刻体会到将前沿的AI技术Agent LLM RL应用到像法律这样严谨、专业的垂直领域最大的挑战不在于技术本身而在于如何将领域知识深度融入系统设计的每一个环节。智能体不是万能的它需要被严谨的规则和可靠的数据源所约束评分表不是一劳永逸的它需要与模型在博弈中共同进化。最终一个可靠的系统必然是技术逻辑与领域逻辑紧密结合的产物。这条路还很长但每一步都充满了挑战和乐趣。