1. 项目缘起当劳动法咨询遇上大语言模型最近在做一个挺有意思的尝试想看看能不能用现在火热的LLM大语言模型和智能体Agents技术来解决一个非常具体且棘手的实际问题巴西劳动法的自动问答。你可能觉得这听起来有点跨界一个是前沿的AI技术一个是严谨的法律条文但恰恰是这种结合让我看到了技术落地的巨大潜力。巴西的劳动法体系以其复杂性和频繁的修订而闻名。对于在巴西运营的企业HR、法务甚至是普通员工来说快速、准确地获取一个法律问题的答案往往意味着需要翻阅厚重的法典、追踪最新的判例或者支付高昂的律师咨询费。传统的基于关键词匹配的FAQ系统或者简单的单轮问答机器人在面对“我这种情况算不算加班”、“公司单方面调整我的工作地点是否合法”这类需要结合具体情境、进行多步推理的问题时就显得力不从心了。它们要么给出一个过于宽泛、可能不准确的答案要么直接回复“无法理解您的问题”。这正是LLM和智能体技术可以大显身手的地方。LLM比如大家熟知的GPT系列、Claude等拥有强大的自然语言理解和生成能力能够理解用户用日常语言描述的复杂情境。而“智能体”这个概念则可以理解为赋予了LLM“行动能力”和“协作能力”。一个智能体可以调用工具比如搜索数据库、计算器可以规划步骤甚至多个智能体可以分工合作共同完成一个复杂任务。这就像组建了一个虚拟的专家团队一个负责理解用户意图一个负责检索相关法条一个负责分析案例相似性最后一个负责整合信息用通俗易懂的语言给出最终建议。我这次实验的核心就是基于CrewAI这个多智能体编排框架构建一个名为“HR-Agents”的系统。它不是让一个“全能”的LLM去硬啃所有问题而是设计多个各司其职的智能体通过协作来提升问答的准确性、可靠性和可解释性。简单说我想看看让多个“AI专家”一起开会讨论是不是比问一个“AI通才”更靠谱。这个想法听起来很酷但实际搭建过程中遇到的坑、获得的启发远比预想的要多。接下来我就把这套系统的设计思路、实现细节以及踩过的那些“坑”毫无保留地分享出来。2. 系统架构设计为什么是“多智能体”而非“单模型”在决定用多智能体架构之前我首先评估了“单一大模型”方案的局限性。直接向一个强大的LLM例如GPT-4提问“根据巴西《统一劳动法》CLT员工在什么情况下有权获得危险津贴”模型很可能基于其训练数据给出一个看起来非常专业的答案甚至能引用法条编号。但问题在于时效性无法保证LLM的训练数据有截止日期无法获取最新的法律修订或判例。幻觉风险模型可能会“自信地”编造一个不存在的法条或解释这在法律领域是致命的。缺乏可追溯性答案是如何得出的依据了哪些法条用户无法验证系统也无法审计。复杂问题处理能力弱对于需要多步推理的问题例如计算一个涉及多次加班、假期和奖金的最终赔偿金额单次问答难以完成。因此我决定采用“分工协作”的多智能体架构。这套架构的核心思想是解耦与流水线。将复杂的法律问答任务拆解成多个子任务每个子任务由一个专门的智能体负责智能体之间通过清晰的信息传递进行协作。这样做的优势非常明显专业化每个智能体可以针对特定任务进行优化例如检索智能体专注于精准匹配分析智能体专注于逻辑推理。可维护性可以独立更新某个智能体的知识库或提示词Prompt而不影响整个系统。可解释性整个推理过程被记录了下来我们可以查看每个智能体提供了什么信息最终答案是如何综合得出的。灵活性可以很容易地加入新的智能体来处理新的任务类型例如加入一个“判例检索智能体”。我选择了CrewAI作为智能体编排框架。相比自己从零开始用LangChain或AutoGen来管理智能体间的状态和通信CrewAI提供了一套更高级、更直观的抽象。它用“角色Role”、“任务Task”和“流程Process”来定义多智能体协作非常贴合我们的场景。你可以把CrewAI想象成一个项目的“项目经理”它负责给每个“专家”智能体分配工作并确保他们之间的沟通顺畅。基于CrewAI我设计了HR-Agents系统的核心工作流如下图所示概念图用户提问 | v [问题理解与分类智能体] | (解析出问题类型、关键实体、时间范围等) v [法律条文检索智能体] ---(可选)--- [外部数据库/知识库] | (提供相关的法条原文、编号、生效日期) v [情境分析与推理智能体] | (结合用户情境和法条进行逻辑推理、计算) v [答案生成与格式化智能体] | (生成结构清晰、引用明确、语言友好的最终答案) v 最终答案返回给用户这个流水线确保了从原始问题到可信答案的每一步都是可控、可审计的。接下来我们深入每个智能体的具体实现。3. 智能体分工与核心实现细节3.1 智能体一问题解析与分类器这是流水线的第一环也是最关键的一环。它的任务不是直接回答问题而是像一位经验丰富的律师助理先听懂客户在问什么并把问题“翻译”成后续流程能处理的结构化指令。它的核心工作包括意图识别判断用户问题是关于“加班费”、“解雇赔偿”、“假期权利”还是“工作安全条件”等。实体抽取提取问题中的关键实体如“员工类型”正式工、实习生、“时间点”入职日期、事件发生日期、“金额”或“百分比”。情境参数化将模糊的描述转化为可查询的参数。例如用户说“我晚上经常加班”解析器需要尝试提取“加班频率”经常、“时间段”晚上等并标注这些信息可能存在不确定性需要后续确认。我是如何实现的我并没有为这个智能体连接一个庞大的法律数据库而是赋予它强大的**指令解析和少量示例学习Few-Shot Learning**能力。它的核心是一个精心设计的提示词Prompt和一套输出规范。# 提示词核心部分示例概念代码 problem_parser_agent_prompt 你是一个专业的巴西劳动法问题分析专家。你的任务不是直接回答法律问题而是深入分析用户的问题并将其分解为结构化、可操作的查询要素。 请严格按照以下JSON格式输出你的分析结果 { core_question_type: 加班补偿 | 解雇程序 | 假期权利 | 工资福利 | 健康安全 | 其他, extracted_entities: { employee_type: [CLT, PJ, Estagiário, 不确定], time_references: [具体日期或时间段如2023-01-01], monetary_mentions: [提及的金额或百分比], key_actions: [被解雇, 要求加班, 发生事故] }, ambiguities: [列出问题中所有模糊、需要澄清的点例如经常加班的频率定义], suggested_search_queries: [根据分析生成2-3条用于检索法律条文的关键词或短语使用葡萄牙语] } 用户问题{user_input} 实操心得与避坑点注意LLM的JSON输出并不总是稳定的。最初我直接让智能体输出JSON偶尔会遇到格式错误导致后续流程解析失败。解决方案是使用CrewAI或LangChain的OutputParser如StructuredOutputParser强制将输出约束到预定义的Pydantic模型中这大大提升了系统的鲁棒性。另外对于“其他”类问题我会让解析器额外输出一个置信度分数如果分数过低系统会直接提示用户重新表述问题而不是进入不可靠的检索流程。3.2 智能体二法律知识检索专家这个智能体是系统的“记忆库”。它的唯一职责是根据第一个智能体提供的search_queries从我们构建的巴西劳动法知识库中精准、快速地找到最相关的法律条文。知识库的构建是关键我并没有使用通用的网络爬虫因为法律文本需要绝对的准确性和权威性。我的数据源来自巴西政府官方网站发布的《统一劳动法》CLT电子版、主要补充法规以及劳工部的重要解释性条文。这些文本经过以下处理清洗与分段将法律条文按“条Artigo”进行分割每条作为一个独立的文档块Chunk。同时保留条号、标题和上下文信息。向量化使用文本嵌入模型我选择了text-embedding-3-small它在多语言法律文本上表现不错且性价比高将每个条文块转换为高维向量。存储将这些向量存入向量数据库我选用的是Pinecone因其简单易用但Chroma或Weaviate也是很好的开源选择。检索智能体的工作流程接收解析后的查询词葡萄牙语。将查询词同样转换为向量。在向量数据库中进行相似度搜索通常使用余弦相似度召回Top-K例如K5个最相关的法律条文块。不仅返回条文内容还返回条文的元数据法律名称、条号、修订版本、生效日期。这对于后续的可解释性至关重要。为什么不用传统关键词搜索因为法律语言中存在大量的同义表述和复杂逻辑。例如用户问“试用期被解雇有赔偿吗”法律条文可能写的是“在稳定性条款estabilidade未生效前雇主可无需理由解除合同……”。向量检索能够更好地捕捉这种语义关联。然而纯向量检索也有坑它可能召回语义相关但条款编号完全不对的条文。因此我在后期加入了混合检索策略结合向量相似度语义和BM25算法关键词匹配的分数进行加权排序显著提高了召回准确率。3.3 智能体三情境推理与计算引擎这是系统的“大脑”。前两个智能体提供了“用户情境”和“法律依据”现在需要将它们结合起来进行逻辑推理、判断甚至数值计算。这个智能体需要最强的逻辑推理能力因此我为其分配了能力最强的LLM如GPT-4。它的提示词也最为复杂reasoning_agent_prompt 你是一名资深的巴西劳动法律师。现在你需要基于以下信息为用户的具体情况提供法律分析。 **用户情境分析摘要** {context_from_parser} **相关法律条文** {retrieved_laws} **你的任务** 1. **适用性判断**逐条分析上述法律条文是否完全或部分适用于用户描述的情境说明理由。 2. **推理过程**如果适用请一步步推导出法律后果。例如如果涉及计算请清晰列出计算步骤和依据的条款。 3. **不确定性说明**明确指出分析中基于的假设以及因信息缺失如“经常加班”的具体时长而无法确定的部分。 4. **生成中间结论**输出一个结构化的推理摘要包括适用的法条、推导出的权利或义务、以及任何待澄清项。 请以严谨、逻辑清晰的方式进行。 典型工作示例问题“我是一名CLT正式员工月薪5000雷亚尔公司在未提前30天通知的情况下将我解雇我有哪些权利”输入解析器会识别出“CLT正式员工”、“解雇”、“未提前通知”等实体。检索器会找到关于解雇通知期aviso prévio、解雇基金FGTS罚金、未休假期补偿等相关法条。推理过程推理智能体会执行如下计算确认适用《统一劳动法》第7条及相关条款。计算通知期补偿因未提前通知公司需支付相当于30天工资的补偿金。5000雷亚尔 / 30天 * 30天 5000雷亚尔。计算FGTS罚金公司需支付账户余额的40%作为罚金假设账户余额需从FGTS系统获取此处提示用户自查。计算未休假期补偿按比例计算当年已工作月份对应的假期工资并加上1/3的额外补贴。汇总并说明以上各项需叠加并指出最终金额取决于FGTS具体余额和精确的工作时长。这个环节最大的挑战是让LLM进行“可靠的计算”。LLM在数学计算上并不总是可靠。我的解决方案是让智能体“调用工具”。我为其集成了一个简单的Python计算工具。当提示词中检测到“计算”、“乘以”、“百分比”等关键词时智能体会生成一个计算表达式如calculate(5000 / 30 * 30)并由后端工具执行再将结果返回给智能体用于组织语言。这确保了数字结果的绝对准确。3.4 智能体四答案合成与沟通专家这是面向用户的最后一环负责将专业的法律推理转化为清晰、友好、无歧义的最终答案。它需要具备良好的“情商”和沟通技巧。它的核心职责结构化呈现将答案组织成“结论摘要”、“权利清单”、“计算明细”、“法律依据”、“您的下一步行动建议”等模块。风险提示明确声明“本分析基于AI模型和提供的信息不构成正式法律意见对于重大决策请咨询持证律师”。引用溯源在答案中明确标注所引用的法律名称和条号例如“根据《统一劳动法》第7条第XX款…”并支持点击回溯查看原文在实现UI的情况下。引导澄清如果推理智能体指出了信息模糊点答案生成智能体会以提问的方式引导用户提供更多信息例如“您所说的‘经常加班’具体是指每周超过多少小时呢”。这个智能体的提示词侧重于风格和格式指令确保输出的一致性和专业性。4. CrewAI下的多智能体协作与流程编排设计好单个智能体只是第一步如何让它们高效、有序地协作才是CrewAI框架发挥价值的地方。在CrewAI中你需要定义三个核心概念Agent智能体、Task任务和Crew团队。1. 定义智能体Agents每个智能体除了有对应的LLM和提示词外还需要定义其role角色和goal目标。这听起来像写岗位说明书但非常有用。from crewai import Agent # 问题解析智能体 problem_parser Agent( role巴西劳动法问题分析师, goal准确解析用户问题提取关键实体、意图和模糊点并生成高质量的检索查询词。, backstory你是一名在劳动法领域有十年经验的律师助理擅长快速理解客户的核心诉求并将其转化为专业的法律查询语言。, llmllm_model, # 可以指定一个轻量级的、快速的LLM verboseTrue # 调试时打开可以看到它的思考过程 ) # 法律检索智能体 legal_retriever Agent( role法律知识库检索专家, goal根据提供的查询词从权威巴西劳动法知识库中精准召回最相关的法律条文原文及元数据。, backstory你是一个拥有海量法律条文记忆且一丝不苟的图书管理员你的工作就是找到最准确的那一本法典和那一个条款。, llmllm_model, # 这个智能体甚至可以不需要很强的LLM重点在工具调用 tools[retrieval_tool], # 为其装备检索工具 verboseTrue ) # 同理定义推理智能体和答案生成智能体2. 定义任务Tasks任务是智能体需要执行的具体工作。每个任务需要指定agent由谁执行、description任务描述和expected_output期望的输出格式。最关键的是你可以定义任务之间的依赖关系。from crewai import Task # 任务1解析问题 task_parse Task( description分析用户输入的问题{user_input}。提取问题类型、关键实体、模糊点并生成用于检索的查询词。, agentproblem_parser, expected_output一个结构化的JSON对象包含core_question_type, extracted_entities, ambiguities, suggested_search_queries。 ) # 任务2检索法律条文 task_retrieve Task( description根据任务“task_parse”生成的suggested_search_queries从巴西劳动法知识库中检索最相关的法律条文。, agentlegal_retriever, context[task_parse], # 关键指定依赖关系此任务需要task_parse的输出作为上下文 expected_output一个列表包含检索到的Top-K条法律条文每条需包含原文、法律来源、条号、生效日期。 ) # 任务3进行法律推理 task_reason Task( description基于任务“task_parse”提供的用户情境和任务“task_retrieve”提供的法律条文进行逐步法律推理和计算。, agentreasoning_agent, context[task_parse, task_retrieve], # 依赖前两个任务 expected_output一份详细的推理报告包括适用性分析、逐步计算过程如有、中间结论和剩余不确定性。 ) # 任务4生成最终答案 task_answer Task( description将任务“task_reason”生成的推理报告转化为面向用户的、清晰友好、结构完整且带有风险提示的最终答案。, agentanswer_generator, context[task_reason], # 依赖推理任务 expected_output一份结构化的最终答案包含结论摘要、权利清单、计算明细、法律依据引用和行动建议。 )3. 组建团队并执行Crew最后将智能体和任务组装成一个团队Crew并指定执行流程。CrewAI支持顺序流程、分层流程等。这里我们使用简单的顺序流程。from crewai import Crew, Process # 组建项目团队 project_crew Crew( agents[problem_parser, legal_retriever, reasoning_agent, answer_generator], tasks[task_parse, task_retrieve, task_reason, task_answer], processProcess.sequential, # 顺序执行parse - retrieve - reason - answer verbose2 # 输出详细的执行日志 ) # 执行任务 result project_crew.kickoff(inputs{user_input: 公司因业绩不佳要裁员我应该获得多少赔偿}) print(result)通过这样的编排一个复杂的法律问答就被分解成一条清晰的生产线。CrewAI会自动管理任务之间的输入输出传递你只需要关注每个“工位”智能体的质量和它们之间的协作逻辑。5. 实测挑战、优化策略与效果评估搭建完原型系统后我用了上百个真实的、从简单到复杂的巴西劳动法问题对其进行测试。这个过程暴露了许多问题也催生了一系列优化策略。挑战一检索精度与召回率的平衡最初只使用向量检索发现对于一些非常具体的法条编号查询如“CLT Art. 477”效果反而不如关键词检索。优化策略采用混合检索Hybrid Search。结合向量检索的语义优势和关键词检索如BM25的精确匹配优势对两者的得分进行加权融合例如0.7 * 向量相似度分 0.3 * BM25分。同时为知识库的文档块添加丰富的元数据法律名称、章节、条号、关键词标签检索时可以先通过元数据过滤再进行语义搜索大幅提升效率。挑战二LLM的“幻觉”与推理偏差即使在提供了准确法条后推理智能体有时还是会“过度发挥”添加一些不存在的规定或做出过于绝对的判断。优化策略提示词约束在推理智能体的提示词中反复强调“严格基于提供的法律条文进行推理如果条文未提及则回答‘根据所提供信息无法确定’”。分步验证Step-by-Step Verification要求智能体在输出中必须将其推理链条中的每一步与提供的具体法条原文对应起来。例如“得出‘有权获得通知期补偿’的结论是基于《统一劳动法》第7条第XX款中关于解除合同通知期的规定”。后处理校验在答案生成阶段加入一个简单的校验步骤检查最终答案中提到的每个法律概念是否都能在检索到的条文列表中找到对应或合理推论否则进行标记或要求重新推理。挑战三处理模糊与信息不全的用户输入用户的问题常常是模糊的如“我加班很多”。系统最初要么直接拒绝回答要么给出一个基于假设的、可能误导的答案。优化策略将“模糊点”作为系统的一等公民。问题解析智能体必须列出所有歧义。答案生成智能体在最终输出时必须包含一个“重要假设与待澄清项”部分明确告诉用户“我们的分析基于以下假设[列出假设]。如果您能提供[具体信息]答案将更加精确。”这既体现了专业性也引导了对话。挑战四性能与成本使用GPT-4这样的强大模型运行四个智能体每个问题消耗的Token和成本是可观的响应速度也较慢。优化策略智能体分级。不是所有智能体都需要最强的模型。问题解析和答案生成智能体可以使用更轻量、更便宜的模型如GPT-3.5-Turbo它们对逻辑推理要求相对较低。而核心的法律推理智能体则保留使用GPT-4。此外对检索结果和解析结果进行缓存对于相同或相似的问题可以直接复用中间结果显著降低成本和延迟。效果评估经过多轮优化系统在测试集上表现出了显著优于单模型问答的能力准确性在事实性问题上如法条内容、计算公式由于有检索到的条文作为依据幻觉率大大降低。可解释性每个答案都附带清晰的引用和推理步骤用户和开发者都能追溯答案来源。复杂问题处理能够处理多步骤计算和条件判断问题例如综合计算涉及加班费、假期和奖金的最终薪酬。用户体验结构化答案和风险提示让用户感觉更可靠、更专业。当然它仍然不是一个完美的“AI律师”。其上限受限于知识库的完备性、检索的准确性以及LLM本身的理解和推理能力。但对于企业HR快速查询常见问题、员工自助了解基本权益、甚至法律学习者作为辅助工具其价值已经非常明显。6. 扩展思考从巴西劳动法到更广阔的场景完成这个项目后我深刻体会到HR-Agents这套多智能体协作框架其核心范式具有很高的通用性。它本质上是一个基于LLM的、模块化的、可审计的复杂信息处理流水线。巴西劳动法问答只是一个具体的应用实例。我们可以很容易地将这个框架迁移到其他领域企业内部IT支持智能体1解析用户报障描述智能体2检索知识库/历史工单智能体3推理故障原因和解决方案智能体4生成回复并附带操作步骤。金融产品咨询智能体1分析客户风险偏好和需求智能体2检索产品数据库和合规条款智能体3进行收益风险测算智能体4生成个性化投资建议报告。医疗健康问答需严格监管智能体1解析症状描述智能体2检索医学文献和指南智能体3进行初步的、非诊断性的可能性分析智能体4生成健康建议并强烈提示就医。未来的优化方向动态智能体路由根据问题解析的结果动态决定启用哪些智能体、以什么顺序执行而不是固定的流水线。人类在环Human-in-the-loop对于高置信度低或涉及重大利益的问题系统可以自动暂停将问题转交人工审核并将审核结果反馈学习。持续学习将用户对答案的反馈如“有帮助/无帮助”、修正信息用于优化检索排序和智能体的提示词。这个项目让我看到将大语言模型视为一个“全能大脑”去解决所有问题可能并非最佳路径。相反将其视为拥有不同专业技能的“专家组成员”通过精心设计的流程让它们各司其职、协同工作往往能构建出更可靠、更透明、也更强大的应用系统。从单智能体到多智能体的思维转变或许是下一代AI应用开发的关键。