法律行业一直被认为是最难被 AI 改造的领域之一专业门槛高、容错率低、数据敏感。最近 Google 的产品动作让这条赛道重新成为焦点——面向法律专业人士推出基于 Gemini 的专用工具。本文不打算停留在新闻解读而是把“法律 AI”从产品到代码完整拆开先讲清楚它在解决什么问题再梳理 Google 这套工具的技术底座最后用 Gemini API 亲手实现一个合同审查小工具并给出可落地的工程建议。如果你正在关注 AI Agent 应用、法律科技方向或者想在具体行业落地大模型这篇文章都值得读下去。1. 背景与核心概念1.1 法律 AI 为什么现在才真正热起来在 ChatGPT 刚出现的时候法律行业尝试过很多“大模型 法律”的组合但大部分产品停留在“普法问答”或“法条速查”的层面。原因并不复杂法律工作的核心不是“知道法条”而是“处理复杂文本和流程”。一份合同可能有几十页一个并购项目涉及上百份文件一次诉讼要梳理多年的往来邮件和证据材料。传统大模型虽然能回答法律问题但无法完成“读文件、找风险、写草稿、跟踪流程”这类多步骤任务。Google 这次入场把重心放在了 Agent 能力上。所谓 Agent也就是智能体是指模型不仅能回答问题还能根据目标自主规划步骤调用检索、文档处理等工具最终产出一份可用的结果。这是法律 AI 从“玩具”走向“生产力工具”的关键转变。理解了这一点再看各家厂商的法律 AI 产品就不会被表面的“懂法条”迷惑而会更关注它到底能不能完成一整条业务闭环。1.2 法律 AI 的核心能力拆解一个完整的法律 AI 工具通常包含以下几类能力能力说明典型场景法律检索从法条、案例、行政规定中查找相关信息评估诉讼风险、准备法律意见书文档审阅快速浏览大量合同或披露文件标注异常条款合同审查、尽调文件复核内容起草根据既有模板和事实生成合同、备忘录初稿生成保密协议、律师函草稿风险识别基于规则和经验判断条款中的商业与法律风险付款周期过长、违约责任缺失合规监测跟踪法规变化并提示企业调整内部流程新规下修改用户协议流程执行像员工一样推进多步骤任务汇总各部门合同意见、跟进审批这些能力单独看都不算新但把它们组合到一个可控、可追溯的 Agent 流程里就是 Google 这次发布的核心看点。它意味着法律 AI 不再只是“给律师一个更聪明的搜索框”而是变成能承接具体任务的数字员工。1.3 先区分几组容易混淆的概念第一组是“通用大模型”与“法律专用模型”。通用模型如 Gemini 系列具备强大的语言理解能力但缺乏对法律业务的精细约束。法律专用工具通常是在通用模型之上叠加专门的法律知识库、提示词约束、业务审批流和校验逻辑所以它更像“行业解决方案”而不是一个全新的模型。第二组是“单次问答”与“RAG 检索增强生成”。单次问答直接让模型生成答案速度快但容易产生幻觉RAG 是先检索企业知识库或法条库中的相关片段再把这些片段作为上下文交给模型回答。后者更可控也更适合专业场景。第三组是“AI 辅助”和“AI 决策”这也是法律 AI 最敏感的边界。当前所有主流产品包括 Google 在内都强调“人类在环”human-in-the-loop也就是 AI 负责起草和提示最终由律师审核签字。理解这个边界是做法律 AI 应用开发的前提系统设计上一定要预留人工确认、修改和留痕的环节而不是让模型直接对外输出结论。2. Google 的 Gemini 法律专用工具做了哪些事2.1 产品定位从问答助手到法律 Agent根据 Google Cloud 的公开介绍本次面向法律行业推出的工具暂定名为 Axel是构建在 Gemini 2.5 之上的 AI 代理。它面向律师、公司法务和法务运营团队目标不是简单地回答“某法条怎么规定”而是承接一整条工作流用户给一个任务目标Axel 在授权范围内读取 Workspace 中的邮件、文档、表格检索公开的法律信息再输出一份结构化的结果比如合同风险清单、纠纷备忘录草稿或法律研究摘要。这类产品形态的变化值得关注。过去法律科技产品多数是“工具”需要人来操作按键Axel 这类 Agent 更像是“初级助理”把任务分配给它之后它会尝试拆解并执行。当然所有关键输出仍然需要用户确认这也符合法律行业对审计和责任的严格要求。对于技术团队来说这种“任务目标驱动 多工具协同 结果人工确认”的模式也代表了 AI 应用未来的主流交互方式。2.2 技术底座Gemini 2.5 的长上下文与多步骤推理从技术角度看这类 Agent 能落地主要依赖三个能力。第一个是长上下文。合同、判例、尽调材料动辄几万字甚至几十万 token早期模型根本读不完。Gemini 2.5 系列大幅提升了上下文窗口让模型可以在一次分析中覆盖更完整的文档这是法律场景的硬性需求。文档读不全条款就找不准后续所有分析都没有意义。第二个是结构化输出。工具会要求模型返回 JSON 等固定格式方便下游系统继续处理。例如合同分析结果可以直接落到数据库或者自动生成工单。第三个是工具调用Agent 需要调用法条检索接口、文档解析服务、内部审批 API 等多个外部能力这正是 Gemini 的 function calling 机制解决的。另外可以关注的是Google 强调模型输出会被记录和审计。对于法律行业这比“答得准不准”更关键因为律师需要对过程和依据负责。2.3 集成方式与行业影响Axel 的另一大卖点是原生集成。它跑在 Google Workspace 之上能够读取 Gmail、Google Docs、Google Drive 和 Google Sheets 中的内容同时通过 API 与法律行业常用的文档管理系统、案例管理系统对接多家海外法律科技平台已经出现在官方合作名单中。这种“企业数据 协作工具 大模型”的闭环是普通法律 AI 创业公司短期内难以复制的优势。对开发者而言这条新闻意味着两件事。第一大模型厂商开始卷“行业 Agent”通用 API 之外会出现越来越多开箱即用的垂直方案。第二技术同学如果只会调用 API竞争力会越来越有限理解业务流程、数据治理和 Agent 编排才是法律科技项目的真正壁垒。换句话说不要把目光只放在“模型多聪明”上而要放在“工作流能不能被数字化”上。3. 从产品到代码搭建法律 AI 应用的准备工作产品层面看清楚了下面进入实战。我们不直接使用 Google 官方的法律工具因为它目前主要面向企业内测而是利用 Gemini API 搭建一个同类能力的最小实现合同关键条款提取与风险提示。这个案例能帮助你看清法律 AI 背后的通用管线也方便你后续扩展成自己的业务工具。3.1 技术选型与运行环境本文示例以 Python 为例环境如下操作系统Windows / macOS / Linux 均可Python 版本3.10 及以上主要依赖google-generativeai、pypdf、python-dotenvIDEVS Code 或其他任意编辑器版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。当前 Gemini API 的模型列表如 gemini-2.5-flash、gemini-2.5-pro会随着官方迭代变化请以 Google AI Studio 页面显示的模型列表为准。如果遇到 API 调用报错优先检查模型名称和 SDK 版本是否匹配。3.2 获取 API Key 与基础配置使用 Gemini API 需要先在 Google AI Studio 或 Google Cloud Console 中创建一个 API Key。企业场景建议在 Google Cloud 中管理密钥并开启相应的计费项目和配额。创建完成后不要直接把密钥写死在代码里建议使用环境变量存放。export GEMINI_API_KEY你的_API_KEY在 .env 文件中管理也可以GEMINI_API_KEY你的_API_KEY GEMINI_MODELgemini-2.5-flash这里需要特别说明企业法律场景中API Key 的权限范围要尽可能小并且严格限制在服务器端。不要把 Key 放在前端代码、仓库或文档里避免被其他人获取后盗用配额。3.3 法律 AI 应用的核心管线一个生产级的法律 AI 应用通常包含以下环节输入解析读取 PDF、Word、扫描件转成模型可处理的纯文本。预处理与切片长文档按章节或固定长度切片避免超出上下文限制。模型分析使用精心设计的 法律AI开发实战：基于Gemini Agent的合同审查工具
法律行业一直被认为是最难被 AI 改造的领域之一专业门槛高、容错率低、数据敏感。最近 Google 的产品动作让这条赛道重新成为焦点——面向法律专业人士推出基于 Gemini 的专用工具。本文不打算停留在新闻解读而是把“法律 AI”从产品到代码完整拆开先讲清楚它在解决什么问题再梳理 Google 这套工具的技术底座最后用 Gemini API 亲手实现一个合同审查小工具并给出可落地的工程建议。如果你正在关注 AI Agent 应用、法律科技方向或者想在具体行业落地大模型这篇文章都值得读下去。1. 背景与核心概念1.1 法律 AI 为什么现在才真正热起来在 ChatGPT 刚出现的时候法律行业尝试过很多“大模型 法律”的组合但大部分产品停留在“普法问答”或“法条速查”的层面。原因并不复杂法律工作的核心不是“知道法条”而是“处理复杂文本和流程”。一份合同可能有几十页一个并购项目涉及上百份文件一次诉讼要梳理多年的往来邮件和证据材料。传统大模型虽然能回答法律问题但无法完成“读文件、找风险、写草稿、跟踪流程”这类多步骤任务。Google 这次入场把重心放在了 Agent 能力上。所谓 Agent也就是智能体是指模型不仅能回答问题还能根据目标自主规划步骤调用检索、文档处理等工具最终产出一份可用的结果。这是法律 AI 从“玩具”走向“生产力工具”的关键转变。理解了这一点再看各家厂商的法律 AI 产品就不会被表面的“懂法条”迷惑而会更关注它到底能不能完成一整条业务闭环。1.2 法律 AI 的核心能力拆解一个完整的法律 AI 工具通常包含以下几类能力能力说明典型场景法律检索从法条、案例、行政规定中查找相关信息评估诉讼风险、准备法律意见书文档审阅快速浏览大量合同或披露文件标注异常条款合同审查、尽调文件复核内容起草根据既有模板和事实生成合同、备忘录初稿生成保密协议、律师函草稿风险识别基于规则和经验判断条款中的商业与法律风险付款周期过长、违约责任缺失合规监测跟踪法规变化并提示企业调整内部流程新规下修改用户协议流程执行像员工一样推进多步骤任务汇总各部门合同意见、跟进审批这些能力单独看都不算新但把它们组合到一个可控、可追溯的 Agent 流程里就是 Google 这次发布的核心看点。它意味着法律 AI 不再只是“给律师一个更聪明的搜索框”而是变成能承接具体任务的数字员工。1.3 先区分几组容易混淆的概念第一组是“通用大模型”与“法律专用模型”。通用模型如 Gemini 系列具备强大的语言理解能力但缺乏对法律业务的精细约束。法律专用工具通常是在通用模型之上叠加专门的法律知识库、提示词约束、业务审批流和校验逻辑所以它更像“行业解决方案”而不是一个全新的模型。第二组是“单次问答”与“RAG 检索增强生成”。单次问答直接让模型生成答案速度快但容易产生幻觉RAG 是先检索企业知识库或法条库中的相关片段再把这些片段作为上下文交给模型回答。后者更可控也更适合专业场景。第三组是“AI 辅助”和“AI 决策”这也是法律 AI 最敏感的边界。当前所有主流产品包括 Google 在内都强调“人类在环”human-in-the-loop也就是 AI 负责起草和提示最终由律师审核签字。理解这个边界是做法律 AI 应用开发的前提系统设计上一定要预留人工确认、修改和留痕的环节而不是让模型直接对外输出结论。2. Google 的 Gemini 法律专用工具做了哪些事2.1 产品定位从问答助手到法律 Agent根据 Google Cloud 的公开介绍本次面向法律行业推出的工具暂定名为 Axel是构建在 Gemini 2.5 之上的 AI 代理。它面向律师、公司法务和法务运营团队目标不是简单地回答“某法条怎么规定”而是承接一整条工作流用户给一个任务目标Axel 在授权范围内读取 Workspace 中的邮件、文档、表格检索公开的法律信息再输出一份结构化的结果比如合同风险清单、纠纷备忘录草稿或法律研究摘要。这类产品形态的变化值得关注。过去法律科技产品多数是“工具”需要人来操作按键Axel 这类 Agent 更像是“初级助理”把任务分配给它之后它会尝试拆解并执行。当然所有关键输出仍然需要用户确认这也符合法律行业对审计和责任的严格要求。对于技术团队来说这种“任务目标驱动 多工具协同 结果人工确认”的模式也代表了 AI 应用未来的主流交互方式。2.2 技术底座Gemini 2.5 的长上下文与多步骤推理从技术角度看这类 Agent 能落地主要依赖三个能力。第一个是长上下文。合同、判例、尽调材料动辄几万字甚至几十万 token早期模型根本读不完。Gemini 2.5 系列大幅提升了上下文窗口让模型可以在一次分析中覆盖更完整的文档这是法律场景的硬性需求。文档读不全条款就找不准后续所有分析都没有意义。第二个是结构化输出。工具会要求模型返回 JSON 等固定格式方便下游系统继续处理。例如合同分析结果可以直接落到数据库或者自动生成工单。第三个是工具调用Agent 需要调用法条检索接口、文档解析服务、内部审批 API 等多个外部能力这正是 Gemini 的 function calling 机制解决的。另外可以关注的是Google 强调模型输出会被记录和审计。对于法律行业这比“答得准不准”更关键因为律师需要对过程和依据负责。2.3 集成方式与行业影响Axel 的另一大卖点是原生集成。它跑在 Google Workspace 之上能够读取 Gmail、Google Docs、Google Drive 和 Google Sheets 中的内容同时通过 API 与法律行业常用的文档管理系统、案例管理系统对接多家海外法律科技平台已经出现在官方合作名单中。这种“企业数据 协作工具 大模型”的闭环是普通法律 AI 创业公司短期内难以复制的优势。对开发者而言这条新闻意味着两件事。第一大模型厂商开始卷“行业 Agent”通用 API 之外会出现越来越多开箱即用的垂直方案。第二技术同学如果只会调用 API竞争力会越来越有限理解业务流程、数据治理和 Agent 编排才是法律科技项目的真正壁垒。换句话说不要把目光只放在“模型多聪明”上而要放在“工作流能不能被数字化”上。3. 从产品到代码搭建法律 AI 应用的准备工作产品层面看清楚了下面进入实战。我们不直接使用 Google 官方的法律工具因为它目前主要面向企业内测而是利用 Gemini API 搭建一个同类能力的最小实现合同关键条款提取与风险提示。这个案例能帮助你看清法律 AI 背后的通用管线也方便你后续扩展成自己的业务工具。3.1 技术选型与运行环境本文示例以 Python 为例环境如下操作系统Windows / macOS / Linux 均可Python 版本3.10 及以上主要依赖google-generativeai、pypdf、python-dotenvIDEVS Code 或其他任意编辑器版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。当前 Gemini API 的模型列表如 gemini-2.5-flash、gemini-2.5-pro会随着官方迭代变化请以 Google AI Studio 页面显示的模型列表为准。如果遇到 API 调用报错优先检查模型名称和 SDK 版本是否匹配。3.2 获取 API Key 与基础配置使用 Gemini API 需要先在 Google AI Studio 或 Google Cloud Console 中创建一个 API Key。企业场景建议在 Google Cloud 中管理密钥并开启相应的计费项目和配额。创建完成后不要直接把密钥写死在代码里建议使用环境变量存放。export GEMINI_API_KEY你的_API_KEY在 .env 文件中管理也可以GEMINI_API_KEY你的_API_KEY GEMINI_MODELgemini-2.5-flash这里需要特别说明企业法律场景中API Key 的权限范围要尽可能小并且严格限制在服务器端。不要把 Key 放在前端代码、仓库或文档里避免被其他人获取后盗用配额。3.3 法律 AI 应用的核心管线一个生产级的法律 AI 应用通常包含以下环节输入解析读取 PDF、Word、扫描件转成模型可处理的纯文本。预处理与切片长文档按章节或固定长度切片避免超出上下文限制。模型分析使用精心设计的