问题
律师的一天，多数时候是在与文档打交道。哪条规定管这件事，它现在还有没有效，所里上次碰到同类的事是怎么处理的， 然后要写一份每句话都有出处的意见。
通用的聊天模型回答这些问题其实很流畅，而且经常是对的。但是问题正出在这里：答案来了，没有一个能点开核对的引注； 它引的那条规定还在不在生效，它自己也不知道。一个说得越像的工具，越难看出它什么时候错了。
我建了什么
给一位执业律师做的助手，2026 年 6 月起在真实的案子上每天用。它不是一个聊天窗口，而是一条邮件管线， 中间站着一个智能体。
- 来信进，回信出。 律师把问题发到一个监听邮箱；智能体被这封信唤醒，先把这个案子的历史拼起来
（以往的意见、律师给的材料、附件），再检索，再用中文写出完整的回信，发回去，需要的时候附一份
.docx。 一封来信只回一次；收件人和免责声明在服务端写死，来信正文改不了它。 - 两个语料库，中间是一条保密边界。 公开法源库（差不多 3,300 部法规，加一个律协的资料集，这是 2026 年 6 月的数） 和所里自己的案卷库，作为两个独立的向量库放在 Meinrag 里，端口都不一样。 前者查到的按公开法源引用，后者查到的不出这次会话。我把这条边界做成了架构，而不是一个过滤条件， 因为过滤条件是会被绕过去的。
- 检索给的是原文，不是答案。 排好序的原文段落、引注元数据、一个置信档。这一点是我定的，不是省事： 在律师和法条之间垫一层摘要，核实就从「读原文」变成了「读摘要」，而这个变化没有人会察觉，包括律师自己。
- 六个 MCP 工具服务。 案卷导航、收发信、故障上报、判例检索，加上面那两个库。智能体像任何程序一样去调它们： Bearer 令牌、SSH 密钥，来自外部邮件的检索式先过一遍注入过滤。
- 每件事留一条记录。 每个案子一条结构化、可检索的锚点；另外一份手写的判断记录（依据档位、风险自评、复核回看） 单独放，不和机器生成的东西混在一起。
律师本人审阅每一封。系统给出的是给专业人士的草稿材料，不是法律意见，每一封信上都写着这句。
它证明了什么
有意思的地方其实不在起草。是「法律」这种语料，会把 RAG 的那些默认假设一条条推翻， 而下面每一条都是在生产里撞上的，不是设计评审时想出来的。
- 语料库没有「现在」这个概念。 最近邻检索从来不说「我没有」，它只给最接近的那条，于是一条已经废止的法条 可以是一个完美匹配。置信度回答的是像不像，从来不是还算不算数。一部 2025 年 9 月 1 日生效的核心规则， 在库里缺了整整一年，还是我为别的事去查时才撞见的。回头想，一个不会报告自己缺什么的系统，维护流程就得自带清单， 不然「定期更新」靠的是运气。
- 废止比一条法条更细。 新规废止的是旧规某一条的第一款，第二款还活着。条这一级的「有效 / 失效」标志 两个方向都错，所以粒度得在分块的时候、灌库之前定下来，事后补一个元数据字段是补不回来的。
- 故障有两个方向，但只有一个方向会有人来报修。 判例检索坏掉那天，一天八次超时，烧掉几个小时， 可是没有一个错答案进过任何文件。语料库坏掉是另一个方向：它照样回答。一个浪费你一天但不撒谎的工具， 比一个秒回但会撒谎的安全，而人的本能排序是反过来的。
- 多接一个数据源，可能花掉一条你不知道自己在用的安全保证。 只有公开法源的时候，「检索到的都是公开的」 这句话就是真的。案卷库建起来之后它不再为真了，一条结构上的保证，只能靠纪律去替。
所以这套系统比一个普通聊天窗口强在哪，答案挺窄，也挺老实：引注能点开，引的东西查过时效， 检索不到的时候说「未能检索」，不说「不存在」。
现状
2026 年 6 月 9 日起给律师上线。记录期内从来信到发出是 7 到 46 分钟，一次成功。6 月到 8 月初归档了 23 件事项， 这是下界：8 月下旬主机故障之后索引冻住了，积压的还在重建。
没量过的我就不说：检索的准确率和召回率、和律师独立作业的对比、省下的时间。这些实验都设计得出来，但是没有做过。