法律AI智能体架构设计：体验与效率的平衡之道

最近帮一个法律科技团队做智能体架构评审，遇到了一个挺典型的情况：产品经理提了一堆交互诉求——多轮对话要连贯、回答必须有法条出处、关键结论要能一键导出文书；后端同事一看推理链路，光是跑完一次完整咨询就要触发 6 次模型调用，单轮延迟接近 9 秒，成本也不让人省心。这不是个别项目的痛点，而是法律AI智能体架构设计里最核心的博弈：用户体验要“懂我”，效率要“快且省”，架构师夹在中间，既不能像搜索引擎那样只给结果不负责任，也不能为了炫技堆出过度复杂的链路。作为长期做 AI 应用架构的人，我想把最近踩过的坑、验证过的方案，以及这套体验与效率平衡的逻辑完整拆出来，给同样在搞智能体落地的同学一个参考。

1. 先分清两类用户：法律AI的体验与效率不是一回事

1.1 专业律师和普通咨询者，对“好体验”的定义完全不同

很多法律AI项目一上来就对着大模型封装提示词，觉得能回答法律问题就行。但真正落到架构层面，第一个要回答的问题是：你在为谁设计？

第一类用户是专业律师。他们要的是速度和准确率：输入一段合同条款，最好几秒钟内定位风险点，引用具体判例，还能输出可编辑的审核意见。对他们来说，“体验好”等于“不打断工作流”，冗长的解释反而是干扰。这类用户允许界面简陋，但绝对不能容忍检索跑偏。

第二类用户是普通市民。他们可能连“诉讼时效”和“起诉期限”都分不清，需要在多轮对话里被引导，希望系统把“押金不退”拆解成“先看合同约定、再看法定事由、最后给行动建议”。对他们来说，“体验好”等于“有耐心、能听懂、给安全感”，哪怕回答慢一点也能接受——但绝不能答非所问。

如果一个法律AI系统不做用户分流，统一走同一条处理链路，两个群体的体验必然同时崩塌。所以我设计架构时，第一层就要加一个路由分类模块，用轻量级的意图识别模型判断当前用户身份和问题类型，把请求分流到不同处理策略上。这不是为了炫技，而是给后续所有效率优化留出空间：专业律师走快速通道，普通用户走解释通道，系统资源花在刀刃上。

1.2 场景拆解：不同法律任务对体验与效率的权重差异很大

法律AI不是一个“万能问答”，落到实际产品里通常是几个相对独立的任务场景：

• 法律咨询问答：需要多轮澄清、口语理解、通俗解释，体验权重高。
• 合同审查/风险标注：需要精准定位条款、分析风险等级，效率和准确率并重。
• 法规与判例检索：需要快速返回可验证的原文条目，效率权重极高。
• 文书起草：需要结构化输出、格式正确，用户会对结果反复修改，完整性和体验权重更高。

每个场景的架构策略应该不一样。比如法规检索，我倾向于用“关键词+向量”混合检索，快速召回，再让大模型对结果做重排；而合同审查，就不能只靠检索，必须引进分步骤的规则引擎和条款抽取器，分段落异步处理。很多团队用一个全功能的“超级智能体”打天下，结果每个场景都不好用。

架构师的核心工作，就是先把场景边界画清楚，再决定哪些环节用模型、哪些环节用规则。 有些模块根本不需要大模型参与，比如日期提取、金额计算、条款编号解析，用正则表达式和结构化解析器更快更便宜，还能让大模型专注在最需要语义理解的部分。

2. 从一句法律咨询看完整链路：80%的延迟根本不在大模型

2.1 一条请求在系统里的完整旅程

我用一个真实场景来拆解链路：用户输入“我签了房屋租赁合同，房东不退押金，怎么办？”从点击发送到看到回答，系统内部大概会经历这些阶段：

1. 输入预处理与安全过滤：脱敏，去除无关信息。
2. 会话记忆加载：从短期记忆或长期记忆里恢复上下文。
3. 意图识别与实体抽取：识别出“房屋租赁合同”“押金不退”“怎么办”。
4. 检索阶段：从法规库、判例库、合同模板库检索相关内容。
5. 推理与规划：决定回答结构，是给建议框架，还是需要计算违约金。
6. 生成阶段：大模型生成最终回复。
7. 答案验证与引用标注：检查引用是否真实存在，给出来源。

很多人以为最耗时的一定是大模型推理，但实际压测数据往往会打脸。我曾经在一个项目里用分布式追踪日志统计过一个典型法律问答请求的耗时分布，结果如下：

也就是说，真正拖慢体验的，通常是检索环节和大模型的输入构造环节，而不是模型生成本身。 这和我早期“只要换一个更快的模型就能解决延迟”的直觉完全不同。

2.2 法律文本的检索为什么不能用纯向量方案

通用场景做RAG（检索增强生成），把文档切块丢进向量库，然后按余弦相似度召回，基本够用。但法律文本有个特殊性：条款和判例对精确性极其敏感。 “押金不退”和“租金不退”在法律逻辑上是两码事；一个法条如果被截断成碎片，语义就变了。

所以我在法律AI的检索层，通常做混合检索策略：

• 对用户输入先做实体抽取，提取“合同类型”“争议焦点”等关键词。
• 用这些关键词走结构化检索，优先命中法条编号和条款库。
• 同时把语义向量也跑一遍，作为召回补充。
• 最后用一个重排序模型，把结构化结果和向量结果合并排序。

这套组合比单一向量检索要多花 100-200 毫秒的耗时，但准确率能提升一大截。对于律师用户来说，这个延迟完全可以接受；对于普通用户，虽然多等了零点几秒，但看到回答里带着具体的法条名称，信任感立刻上来，体验反而更好。

效率优化不是为了把每个环节都压到极限，而是在该快的地方快，该稳的地方稳。 把检索质量做好，减少模型因为信息不足而“编造法条”的概率，这比单纯降低延迟更影响用户的真实体感。

3. 智能体架构分层实录：把法律场景拆成可编排的动作

3.1 从“大模型+提示词”到“智能体”的转变

很多团队做法律AI的第一版，就是一个大模型加上一段冗长的系统提示词。这种方案在 demo 阶段没问题，一旦进入生产环境，各种问题就冒出来：用户多问两句话，上下文就乱了；问一个超出提示词范围的问题，模型开始胡编；想加入实时法规数据，提示词里根本塞不下。

智能体架构的核心，是把“什么都让模型想”变成“让模型调用工具、控制流程”。法律场景特别适合这套思路，因为法律业务本质上就是一系列动作：检索、计算、起草、校验。我通常把系统拆成四个层次：

编排层：负责接收用户请求，维护对话状态，决定下一步调用哪个工具或模型。这一层可以直接写代码实现状态机，也可以用现成的编排工具，比如 Dify 这类可视化智能体平台，能快速搭出多步骤工作流，对早期验证很友好。

工具层：把法律领域动作封装成一个个可复用的工具。比如“法规检索工具”“合同条款解析工具”“违约金计算器”“文书模板填充器”。每个工具都有清晰的输入输出 schema，模型只需要理解“这个工具能做什么”，不必关心内部实现。

记忆层：短期记忆保存当前会话上下文，长期记忆保存用户偏好和历史案例。法律咨询对上下文连贯性要求高，用户可能在第五轮突然问“那我刚才说的那个合同还有效吗”，系统必须能正确指代。

模型层：不同任务用不同模型，大小模型混用。简单分类用小模型，复杂生成用大模型。

3.2 工具调用的关键设计：控制循环，别让模型死循环

智能体听起来很聪明，但实际操作里最常见的翻车现场是循环失控。模型发现自己缺少信息，反复调用检索工具，来回折腾六七次，用户等到花都谢了，token成本也爆表。

我对工具调用的约束很简单：每次智能体循环都设定最大迭代次数，默认 3 次，超过就强制收敛到当前已有信息。 如果信息确实不足，宁可让模型明确说“目前信息不足以判断”，也不要让它在死循环里打转。这个约束看似简单，却直接决定了系统的可用性。

在架构实现上，我倾向于做一个统一的 Agent 执行器，而不是让每个场景都写一套独立的循环逻辑。执行器负责以下事情：

• 解析模型返回的 tool_call 请求；
• 调用对应的工具函数；
• 把工具结果拼回上下文；
• 再次交给模型；
• 判断是否要终止循环。

这样的好处是，循环控制、错误重试、超时管理都在同一个地方处理。我见过一些团队用 LangChain 或类似的框架把 Agent 嵌在业务代码里，结果每个场景的循环行为都不一样，出了问题很难排查。通用执行器 + 场景化配置，是我比较推荐的形态。

3.3 多智能体还是单智能体加工具？

法律AI经常被问到需不需要引入多智能体架构，比如“咨询师Agent”“审查Agent”“检索Agent”各司其职。我的观点是：先用单智能体加工具，除非有明确的功能隔离需求，否则不要上多智能体。

多智能体的最大问题是通信开销和一致性成本。两个 Agent 之间传递信息，要么走模型生成，要么走结构化数据，无论哪种，都会增加延迟，而且容易出现信息失真。法律场景对信息准确性要求极高，一条判例编号传错，整个回答就废了。

我目前的实践是：核心对话由一个主 Agent 控制，但内部可以按规则切换到不同的“专家工具”。比如检测到用户上传了合同文件，主 Agent 就调用文档解析工具，把合同结构化之后，再决定是否进入条款审查子流程。这不是多智能体，而是工作流+工具调用的组合，既保留了灵活性，又不会牺牲效率。

如果未来业务规模上去了，可以按团队边界拆成独立服务，但对外仍然是单一接口。我也看到 Coze 这类平台提供了不错的智能体搭建体验，适合快速原型验证；但生产级法律AI要处理私有化部署、数据隔离、细粒度审计，最终还是得自己掌控编排层。

4. 平衡过程中的真实冲突：长上下文、流式响应与成本账

4.1 长上下文与成本的直接矛盾

法律咨询是多轮对话的重度场景。用户从“押金不退”开始，可能会追问“合同没到期我也能退吗？”“押金抵扣维修费合理吗？”“我要不要起诉”……如果每一轮都把全部历史消息塞给大模型，token 数量会迅速膨胀。

以一篇 2000 字的合同审查对话为例，假设每轮平均产生 1200 个 token，跑到第 8 轮时，单次请求的输入 token 就可能超过 10000。如果用高端的闭源模型按 token 计费，成本会随着对话轮数非线性上涨。

我的处理方式分三层：

• 滚动窗口：只保留最近 4-6 轮的原始消息，更早的内容压缩成摘要。摘要由一个小模型生成，保留核心事实，比如“用户在讨论2024年签订的商铺租赁合同，押金3万元，房东以墙面损坏为由不退押金”。
• 关键信息保护：法律场景里有一些信息宁可多花钱也不能丢，比如合同编号、金额、日期、当事人名称。这些实体在摘要生成时单独抽出来放进结构化字段，不依赖模型摘要。
• 缓存：对常见问题的回答做语义缓存。用户问“诉讼时效是几年”这类高频问题，命中缓存后直接返回，完全不需要走模型链路。实际测试里，法律咨询的缓存命中率通常能做到 10%-15%，对成本控制有明显帮助。

4.2 流式输出：让体验“显得快”

一个不可避免的事实是：法律AI的复杂回答往往要生成几百字，如果等模型全部生成完再一次性返回，感知延迟至少 5 秒以上。这种体验在移动端基本是灾难。

流式输出是最直接的解法。让模型一段一段吐文字，用户看到画面在动，感知等待时间会大幅下降。即使是 6 秒才能生成完的回答，流式输出会让用户感觉 2 秒后就“有东西了”。

但流式输出也带来了新的架构问题：法律回答需要引用法条和判例，这些引用如果在流式输出过程中没法校验，用户可能先看到一条错误引用，然后再被修正，这对信任感是致命打击。

我的折衷方案是结构化流式：

• 预先让模型生成一个回答骨架，包含主要结论点。
• 按小节流式输出正文，但引用部分用特殊标记，等校验完成后才展示成超链接或脚注。
• 如果校验不通过，宁可隐藏引用，也不能展示错误来源。

这个方案牺牲了一点流畅度，但保住了法律AI最值钱的东西：可信度。

4.3 模型选型：大模型不是万能的

做法律AI时，很多人对模型的期待是“越强越好”。但架构师的职责是把合适的任务分配给合适的模型。

我目前的常用分流策略是这样的：

这个表不是死的。实际选型时还要考虑团队的技术栈、部署环境、预算上限。但核心思路是：把最重的推理留给最复杂的问题，把最简单的判断留给最便宜的方式。 这样整体资源利用率最高，用户体验也稳定。

4.4 同步还是异步，取决于任务复杂度

当用户问“租房押金不退”时，我们希望同步快速回应；但当用户上传一份 50 页的合同要求全面审查时，如果也同步等待，用户可能要盯着加载圆圈转半分钟。

我的经验是设置一条复杂度阈值线：

• 简单任务：走同步链路，2-3 秒内返回。
• 中等任务：走同步链路，但用流式输出或骨架先行，让用户看到实时进展。
• 复杂任务：走异步链路，先返回“任务已提交”，审查完成后通过消息推送或页面轮询通知用户。

法律场景里有一个特殊的地方：用户对“结果确定性”的期待远高于“速度”。 一个异步任务如果能明确告诉用户“预计 1 分钟后完成，当前正在检索相关判例”，体验往往比一个等 10 秒还不确定结果的同步请求更好。这里面的关键是给出明确的进度反馈，而不是让用户无脑等待。

5. 度量天平：我用来同时管好体验和效率的四类指标

5.1 没有数据支撑的架构迭代就是在赌运气

很多智能体项目上线后，团队对效果的评价停留在“感觉还行”或“某个用户反馈不太好”。这种模糊反馈没法指导架构优化。我建议从一开始就建立指标监控体系，分四类：

体验类指标：

• 平均首字时间：从用户发出请求到界面出现第一个字的时间，目标小于 1.5 秒。
• 用户留存/回访率：用户愿不愿意再次使用。
• 回答采纳率：用户是否参考了回答并继续追问，或点击了“有用”按钮。
• 多轮对话深度：平均会话轮数，太低说明回答没能引导用户继续。

效率类指标：

• 单次请求平均耗时。
• 单次请求平均 token 消耗。
• 缓存命中率。
• 检索响应时间。

质量类指标：

• 引用准确率。
• 幻觉率：模型生成的内容里，无法被任何检索证据支持的比例。
• 任务完成率：比如合同审查任务中，成功输出完整报告的比例。

成本类指标：

• 单会话成本。
• 不同模型承担的 token 占比。

这些指标不是孤立的。我在复盘时喜欢算一个“综合体验效率分”：(体验得分 + 质量得分) / 单位成本。这个分数不完美，但能帮我在不同方案之间做横向对比，比拍脑袋靠谱得多。

5.2 搭建评测集：用回归测试守住底线

法律AI最怕版本升级后，某个旧问题突然回答错了。每次替换模型、调整 prompt、修改检索策略，都应该跑一遍回归测试。

我建议准备一个不对外公开的评测集，覆盖典型法律咨询场景，包含标准答案和必要的引用检查规则。比如：

问题：“试用期被辞退有补偿吗？”
标准答案应包含：试用期内被证明不符合录用条件可解除；若无法证明，则可能构成违法解除，需支付赔偿金。
校验规则：必须出现“不符合录用条件”或“违法解除”关键词；若引用法律条文，需要匹配真实存在的法条编号。

评测集里除了答案匹配，还要专门检查幻觉问题：引用是否真实存在、数字是否被篡改、地名/法条名称是否准确。这套评测集独立于开发团队，由法务或专业顾问维护，防止开发人员“自己考自己”。

5.3 线上追踪：不只看日志，要看完整Trace

传统日志只能告诉你“哪一步报错了”，但智能体架构的问题往往是“哪一步的决策让最终结果跑偏了”。我强烈建议给智能体执行链加上全链路追踪，记录每一步的输入输出、工具调用结果、模型选择、耗时和 token 数。

实际排查问题的场景经常会是这样：

• 用户问了合同违约金问题，最终回答却答非所问。打开 trace 一看，检索阶段没有召回任何内容，而模型在无证据情况下强行编了一个回答。
• 一个简单问题耗时 8 秒。打开 trace 发现，意图识别模块把问题错误分类到“合同审查”，触发了完整的长链路。

这些案例如果只看最终日志是发现不了的。我现在做架构评审时，第一件事就是问对方：“你线上有没有存完整的 trace？”没有 trace 的智能体项目，优化基本靠猜。

6. 架构师视角的避坑心得：先骨架后智能，所有流程都要可回退

6.1 不要被“智能”冲昏头脑，先固化工作流

我见过不少团队一上来就追求“让智能体自由规划”，结果是模型情绪稳定时很好用，稍微碰到底层问题就崩。因为大模型的规划能力再强，它也不了解你的业务约束：哪些数据能用，哪些工具调用有权限，哪些动作需要人工审批。

我的建议是先画业务状态机，再让模型在状态机里选择路径。比如法律咨询的固定流程是：收集信息 -> 法律定位 -> 给出建议 -> 推荐行动。模型可以自由决定每个环节的具体内容，但不能跳过某个节点。这套方式牺牲了一点“自由度”，换来了稳定性和可解释性。

6.2 给足“不回答”和“转人工”的余地

法律AI和普通客服机器人有一个本质区别：它不能犯错。 普通客服说错一句话，用户最多抱怨两句；法律AI说错一个法条引用，可能导致用户做出错误决策，这个责任谁也担不起。

所以我在智能体的系统提示词里会明确写入：当模型判断自己无法确定答案、检索结果不足、或者问题涉及新型复杂争议时，必须明确告诉用户“该问题需要专业法律咨询”，并给出人工咨询入口。这不是逃避，而是对用户负责。

在工程实现上，我还会加一个置信度过滤层：如果检索到的证据与模型生成内容的关联度不够高，宁可降低回答的详细程度，也要避免“一本正经地胡说八道”。

6.3 数据隐私与合规隔离是法律AI的底线

法律业务涉及的数据敏感度极高，合同文本、当事人信息、案件细节都不是可以随便丢给第三方 API 的。如果你的客户是律所或企业法务部，私有化部署或至少数据隔离几乎是硬性要求。

架构设计时，我会把数据流权限控制放在非常靠前的位置：

• 用户上传的文档只进入隔离的存储空间，用完即删或加密保存。
• 外部模型 API 调用时，对文档内容做脱敏处理，替换姓名、身份证号、地址等敏感信息。
• 审计日志记录每一次数据读取和模型调用，确保后续可追溯。

这些措施虽然不直接影响“体验”和“效率”，但它们决定了系统能不能真正上线。一个体检不过关的法律AI，体验再顺滑也没意义。

6.4 上线之后，永远准备一张回退牌

最后说一个我在生产环境里反复踩过的坑：智能体系统上线后，某个环节升级了模型或者改了检索策略，整体效果却下降了，想回滚却发现之前的版本配置已经被覆盖掉了。

现在我要求所有配置都以代码形式管理，例如 prompt 版本、模型版本、工具列表全部纳入版本控制，并且保留每一个发布版本的完整快照。每次变更都遵循“小步试错”原则：先让 10% 流量走新配置，对比指标没问题再逐步放量；一旦指标异常，立刻切回旧版本。这套机制不复杂，但很多团队因为怕麻烦而省略，最后付出了更大的代价。

回到开头的那个法律科技团队。我们最终把单轮平均延迟从 9 秒压到了 4 秒以内，成本也控制了近一半，核心不是换了一个更快的大模型，而是重新设计了链路：把简单咨询分流到轻量模型、把检索层从纯向量改成混合检索、给复杂任务换上了异步流程。用户体验的提升反而来自那些“看不见”的架构决策——用户不知道系统内部做了分流，只感觉到回答更稳了，引用更准了，等待变短了。这就是我理解的体验与效率平衡：不是互相妥协，而是通过架构设计让两者互相成就。