从使用模式上来说，很多人接触人工智能，是从直接使用AI产品开始的。产品是一个经过封装的概念，就像买了一瓶冰红茶，能想起来看一眼配料表的人都是少数，更不会有人去研究制作工艺。封装后的AI产品，从用户端能够感知到的是产品所实现的功能，早期主要表现为基础问答、信息检索。现在，在ChatGPT、豆包、DeepSeek中输入一个需求，还可以进一步让它生成图片、制作PPT，或者完成其他更加花里胡哨的操作。
从心态上来说，基本上大家也形成了一个认识：AI回答还是不太靠谱，容易输出看似正确的错误答案。较有代表性的例子，是2026年初在网络上走红的“洗车问题”。问题大致是：“我想洗车，洗车店距离我家只有50米，我应该走路去还是开车去？”对人类而言，答案几乎不需要推理：既然要洗的是车，就必须把车开到洗车店。但不少大模型却把它机械地理解成一个短距离出行方式选择题，围绕步行更快、更环保、更省油等因素进行分析，最后一本正经地建议用户走过去。
如果把AI定位为玩具，或者只是图一乐、看表演，其实按照如上所述的心态与使用方式就足够了。但是，本文讨论法律人使用AI，更多的还是想把AI作为生产力工具来使用。如果定位为生产力工具，我认为工具能力反而是第二位，第一位是建立信任。
我对AI的认识也经历了否定、肯定、再否定、再肯定的过程。2023年，我发过一篇文章《实测：律师各类工作场景，ChatGPT与NewBing真的能胜任吗？》。我当时的结论是：“现阶段两款AI的法律实用价值有限，基础法律工作无法完全放手交给AI，律师在相当长的未来仍将作为法律综合解决方案提供者，法律科技产品与AI相结合成为发展趋势。”说实话，这段话真正想表达的还是：AI不行，法律人行！
截至2026年7月，AI的发展速度远超大部分人的预期。对于ChatGPT，以及国内的WorkBuddy、QoderWork和我们团队研发的LawBuddy等一系列AI产品，我现在的结论是：“拥抱AI就完事儿了。”
但是，拥抱归拥抱。至少弄清基本机制，才会更有信心把它用到具体业务中。弄清机制以后，也才能在后续使用中不断迭代自己的工具。
因此，终于引入本文需要讨论的概念：LLM、RAG和Agent。例如在合同审查场景中，分清这三个概念以后，AI给出一份让我感觉哪里不太对的审查意见时，我才能知道应该先检查合同上下文和提问方式、知识文件，还是它调用的工具与权限。
一、从合同审查GPT说起
很多通用AI的法律功能以及法律垂直AI，都将合同审查作为重要落地场景。合同审查也确实是法务日常工作以及律师常年法律顾问业务中工作量最大且最枯燥的部分之一（不包括少部分交易结构复杂、各种埋雷挖坑、勾心斗角的合同）。
我一直在使用一个自己创建的合同审查GPT（通过ChatGPT创建的自定义GPT）。我在创建时设置了审查立场、风险等级和输出格式，并放入经过整理、适合上传的审查规则。每次使用前，我会对材料进行必要的脱敏，补充项目背景，再要求GPT进行审查。GPT据此识别风险、匹配等级，并按固定模板生成一版审查意见。当然，这里说得简单，创建GPT过程中指令怎么设置、知识来源怎么规划，如果GPT输出了让我不满意的答案又该怎么复盘和优化，这些都需要长期调整。
目前，这套工具已经能处理一部分实际工作。由这套工具还可以进一步拆分出三个运作层面：审查意见由什么生成，知识文件怎样被调用，系统能否继续修改合同、更新台账并归档。这三个层面分别对应LLM、RAG和Agent。
二、LLM、知识库和RAG分别做了什么
LLM是Large Language Model的缩写，中文通常译作“大语言模型”。它是一类处理和生成语言内容的模型。放到合同审查中，它负责理解条款、联系上下文、概括风险，再把分析组织成审查意见。
这种工作方式与传统数据库查询并不相同。数据库主要返回已经存储的记录，大语言模型会根据输入和上下文组织新的文字。它能把交付、验收、付款和违约责任等几处条款放在一起分析；材料不完整时，也可能补出合同里根本没有的前提（当然，这是使用者不希望看到的）。
例如，合同约定买方可以根据项目需要随时调整交货时间，卖方不得因此调价或者主张额外费用。即使我没有上传企业内部的风险等级指引，模型通常也能从文字中识别交期不确定、履约成本增加和库存积压等一般商业风险。
模型的判断主要来自训练中形成的一般语言和商业知识，再结合这次提交的合同。它通常能看出一般商业风险，却不知道我所在企业怎样划分风险等级，也不知道具体交易中有哪些特殊底线。
这种生成方式也会带来问题。材料不足时，模型仍可能顺着已有信息继续补全一个看似合理的答案。模型错误不只表现为虚构法条、案例或者材料中不存在的事实，也可能表现为忽略例外条件、错误联系多个条款，以及把一种可能的解释写成确定结论。其中，虚构事实和依据通常属于较典型的“幻觉”，其他情况也可能属于遗漏、误读或者推理错误。
为了让模型使用企业自己的审查规则，可以把相关文件整理为知识文件。在我的使用场景里，所谓知识库，就是提前整理并允许系统参考的一组知识文件。
知识文件准备好以后，还要解决面对一份具体合同时，怎样找到相关内容的问题。RAG是Retrieval-Augmented Generation的缩写，通常译作“检索增强生成”。系统先针对当前问题查找相关资料，再把检索结果提供给大语言模型，由模型结合问题和资料生成回答。
上传的知识文件、企业文档库、法规库和联网取得的网页内容，都可能成为检索来源。知识库解决有哪些资料可以使用的问题；RAG则解决怎样从中检索相关内容，并将其提供给模型生成本次回答的问题。
可能这么说以后，RAG的概念还是有点模糊，也容易让人把RAG直接理解为检索功能。我认为，可以把RAG理解为“带着检索功能的生成机制”，但不能直接把RAG等同于检索功能。
更准确的关系是：
RAG＝检索＋把检索结果交给LLM＋LLM依据这些资料生成回答。
法律人最喜欢问：“你这个观点有什么依据？有什么证据证明你的观点？依据的是哪一条合同条款、哪一条法条？”因此，RAG不单纯扮演一个“搜索框”的作用，而是把查找依据和生成分析连接起来，有点类似于法律人主动去找法条、找合同条款，再结合当前合同和问题形成分析的整体过程。
三、知识文件接入以后，还需要不断校准
知识文件让合同审查GPT能够参考相对固定的审查标准，也减少了我每次重新说明要求的工作。不过，检索和生成仍可能出现偏差。
这个地方多说一句。前文说到了，把AI当作生产力工具的第一步是建立信任。很多人可能花了很大功夫，付费安排上了OpenAI当前的旗舰模型GPT-5.6 Sol，也用心整理了知识库，了解了操作过程，但是最终AI的输出结果还是不尽如人意，于是心灰意冷，放弃了。要我说，这确实没有必要。从好的方面想，能够判断AI错了，并且相信自己是对的，这种判断力本身就是人的优势所在，也是在AI时代人的重要价值。最近，我还看到OpenAI在招募投资银行领域专家，其中一项重要工作，就是判断AI输出是否正确、是否真正有价值和实际用途，而不是只输出正确的废话。
我个人在实际使用中，也会发现结果与预期不符。有时审查意见没有按照预设格式输出。同一条款触发多种合同风险时，系统也可能把风险名称、风险等级和分析内容杂糅在一起。有些风险判断基本正确，但提出的修改建议不能满足我的要求，甚至在我已经预设了风险项和修改意见的明确对应关系的情况下，还是能看到AI的“创意部分”。
遇到这些问题，我不会只让GPT重写当前答案。我会先指出偏差，通过多轮讨论确定正确的格式、判断口径或者修改内容，再让它结合本轮讨论提出指令或知识文件的调整方案。随后，我会重新编辑这个自定义GPT的指令、知识文件或其他配置，再用新的合同审查任务验证效果。总之就是迭代，再迭代。其实，迭代也是一种让人享受的过程。迭代让工具更完善，也更契合我的工作方式和习惯。
目前，这套合同审查GPT主要还是生成审查意见。如果要让系统继续进入项目目录、读取全部附件、修改原文件、更新台账并保存版本，讨论的重点就从如何提高回答质量，转向怎样完成后续所有任务。这时，才需要进一步理解Agent。
四、Agent增加了哪些任务执行能力
现在越来越理解，“懒”是科技进步的第一动力。为什么会出现Agent？因为只是在传统AI网页端的对话框中，让AI一条一条地列出建议，再由人类手动操作执行，已经让我们觉得还不够。AI还应该做得更多一点，人类应该做得更少一点。于是，Agent出现了。
先来看概念。Agent并不是另一种与LLM并列的模型。不同厂商对Agent的定义并不完全一致，但通常都会涉及几个共同特征。它能围绕目标拆分步骤，根据进展选择工具，保留任务状态，并根据中间结果继续执行。
能回答问题，不等于能把整项工作做完。判断一个产品是否具备Agent式能力，关键要看它能否围绕目标调用工具、处理文件，并根据前一步的结果调整后续行动，形成“行动—观察—调整—继续行动”的任务循环。
Codex就是一个典型例子。它的官方定位仍然是面向软件开发和技术工作的编程Agent，可以在授权范围内处理本地文件夹、代码仓库、终端和开发工具。2026年7月，OpenAI将原来的Codex应用整合进新版ChatGPT桌面端，Chat、Work和Codex由此被整合到同一个桌面应用中。
虽然Codex主要是为写代码设计的，但实际使用范围并不限于编程。只要一项工作能够被拆解为读取文件、分析内容、执行命令、修改文件和检查结果，它就可能参与其中。例如整理资料、转换文件格式、批量处理文本、生成结构化报告，甚至协助完成合同审查工作流。不过，这不等于所有工作都适合交给Codex。它仍然更擅长规则相对明确、可以在文件和工具中执行，并且能够验证结果的任务。
QoderWork则更直接地把目标放在日常办公场景。其官方定位是桌面Agent式助手，可以读取和整理本地文件，处理数据，生成Word、Excel、PowerPoint和PDF，使用浏览器查询和填写网页，并根据目标逐步完成任务。用户不再只是向它提出一个问题，而是提供目标和工作目录，由它规划、执行并交付结果。
一个相对完整的流程可以是：Agent读取合同正文和附件，调用企业内部审查规则进行初审，检查正文与附件之间是否存在冲突，识别缺失条款和风险条款，生成风险清单和审查意见。经过人工确认后，再由它修改合同文本、添加批注、保留修订痕迹、另存审查版本，并更新合同台账或者归档目录。
现在，部分具备本地文件操作能力的通用Agent，以及越来越多的法律垂直类AI，已经可以直接在本地电脑的Word文档中，以修订模式和批注形式反馈建议。它们主打的就是让经AI审查和修改后的合同看起来像“手工作品”，经过专业人员确认后，可以直接发给业务侧或者客户。这倒不是什么稀有功能。
从我个人的使用体验来说，AI作为生产力工具的价值，在Agent层面会体现得更加充分。对于生产力工具，还是得考虑性价比。如果ChatGPT Plus订阅提供的Agent额度足够多，我甚至愿意尝试把所有适合拆解、执行和验证的任务都先交给Agent处理。我负责提出目标、确定标准和审核结果，Agent负责完成其中大量重复、机械但耗时的步骤。而我现在也确实以此为目标，让AI参与处理、梳理和管理我的所有事项。实话说，法律事务只是其中一个很小的板块。
至于有人问，使用Agent会不会导致文件被误修改或者删除，权限应该怎么设置？我只想说，都说了拥抱AI了——“完全访问权限”，启动！
五、法律人应当怎样理解三者关系
把三者放回合同审查流程，位置大致如下。
| 概念 | 它是什么 | 在合同审查中的作用 |
|---|---|---|
| LLM | 处理和生成语言内容的模型 | 理解合同、分析条款并生成审查意见 |
| RAG | 将外部资料检索与模型生成结合的技术方法 | 从企业审查规则等资料中找出相关内容，供模型分析时使用 |
| Agent | 围绕目标调用模型和工具、连续推进任务的系统 | 读取材料、调用检索、修改文件并推进后续流程 |
对我来说，理解这些概念的直接作用，是知道AI输出不理想时应当从哪个环节排查和调整。一般风险识别不理想，可能需要检查合同上下文、提问方式或者所用模型。内部审查口径没有正确使用，我会回头检查知识文件、指令，以及本次输出是否真正用到了相关规则。如果希望系统继续修改文件、更新台账，就要考虑Agent、工具权限和人工确认。
LLM、RAG和Agent讲清以后，还有一个问题需要继续往下推进。AI有时知道我的背景和偏好，有时又需要重新提供材料；同样是长期使用的信息，有的来自当前对话，有的来自记忆，还有的放在项目和知识文件中。下一篇继续谈上下文、记忆和知识库分别在保存什么。