1. 专利代理人的日常痛点与AI工具的切入点

干了六年专利代理，我最怕的不是技术方案看不懂，而是那些重复到让人麻木的机械劳动。一份权利要求书改八遍，说明书里的技术术语前后不统一，审查意见通知书的答复模板翻来覆去就那么几套逻辑，检索对比文件时要在几十个专利数据库里来回切换。这些活儿不难，但极其消耗时间和注意力，一天下来真正用来思考技术方案创造性高度的精力可能不到三成。

这两年AI工具爆发式增长，尤其是智能体、MCP协议和Skills技能包这三个概念火起来之后，我一直在琢磨能不能把它们用到专利实务里。先说清楚这三个东西是什么关系，不然后面没法聊。智能体是能自主感知环境、做出决策并执行动作的AI程序，你可以把它理解成一个有手有脚的AI助手，不只是聊天，还能调用工具干活。MCP全称Model Context Protocol，是一个让AI模型和外部工具、数据源之间标准化通信的协议，相当于给AI装了一个通用插座，什么工具都能插上去用。Skills则是预封装好的能力模块，比如一个“专利检索”Skill、一个“权利要求格式化”Skill，智能体通过MCP调用这些Skill来完成具体任务。

这三者组合起来，理论上可以搭建一个从技术交底书理解、检索对比文件、撰写权利要求、到答复审查意见的辅助工作流。但理论归理论，国内专利领域的AI工具到底发展到什么程度了，哪些环节真的能用，哪些环节还差得远，这是我花了将近三个月时间实际测试和调研要回答的问题。这篇文章面向的是专利代理人、企业IPR、专利工程师，以及对AI工具落地实务感兴趣的技术人员。我会把调研过程中看到的、试过的、踩过的坑都摊开来讲，不吹不黑，只讲实际能跑通的东西。

2. 国内专利AI工具的三条技术路线与代表产品

2.1 通用大模型直接调用：门槛最低但专业度最弱

最直接的做法就是拿DeepSeek、通义千问、Kimi这些通用大模型来干专利的活。我试过把技术交底书丢给DeepSeek让它写权利要求，出来的东西乍一看像模像样，但仔细一读全是问题。最典型的是功能性限定滥用，它会把“一种基于深度学习的图像识别方法”写成“一种能够识别图像的智能装置”，这种写法在审查阶段几乎必然被以“得不到说明书支持”驳回。通用模型没有经过专利语料的专项训练，对权利要求书的撰写规范、说明书公开充分性的要求、审查指南的具体条款理解非常表面。

但通用模型也不是完全没用。在技术方案理解和背景技术梳理这两个环节，DeepSeek的表现出乎意料地好。你把一段晦涩的技术描述丢给它，让它用通俗语言解释这个方案解决了什么问题、怎么解决的，它提炼得相当准确。我现在的习惯是先用DeepSeek把交底书读一遍，让它输出一个技术问题-技术方案-技术效果的三段式总结，我再基于这个总结去写权利要求。这个环节能省掉大概40%的阅读理解时间。

注意：通用模型输出的任何内容都不能直接复制到专利申请文件中。它给出的权利要求草案只能作为思路参考，具体措辞、技术特征的上位概括和下位限定必须由代理人自己把控。

2.2 专利垂类智能体平台：专业度提升但灵活性受限

国内已经出现了一批专门做专利AI的智能体平台，比如智慧芽的AI助手、佰腾的专利智能体、以及一些创业公司做的专利撰写Agent。这些平台的特点是内置了专利领域的知识库和规则引擎，在权利要求撰写、审查意见答复这些环节比通用模型靠谱得多。

我重点测试了某平台的审查意见答复功能。它的工作流程是这样的：你上传审查意见通知书和原始申请文件，智能体自动识别审查员指出的缺陷类型（新颖性、创造性、不清楚、得不到支持等），然后从内置的答复模板库中匹配对应的答复策略，生成答复意见书草稿。实测下来，对于创造性答复这种最常见也最模板化的场景，它生成的草稿大概有60%的内容可以直接用，剩下的40%需要代理人根据具体对比文件和本申请的技术特征进行针对性修改。

但问题也很明显。这些平台通常是封闭生态，你没法自己接入外部工具，也没法调整智能体的决策逻辑。比如我想让智能体在答复创造性问题时优先引用本申请中与对比文件技术领域不同的特征来论证非显而易见性，但平台的规则引擎不支持这种自定义策略。另外，这些平台的数据安全政策参差不齐，有的明确承诺不保留用户上传的专利文件，有的则含糊其辞，对于处理未公开的专利申请来说这是个必须考虑的风险点。

2.3 基于MCP协议的自建工作流：灵活度最高但技术门槛也最高

这条路线是我个人最看好的方向。核心思路是用MCP协议把各种工具串联起来，让智能体能够自主调用专利检索API、文档处理工具、格式检查脚本等，形成一个可定制的工作流。举个例子，你可以搭建这样一个流程：智能体先通过MCP调用专利检索工具，输入技术关键词获取对比文件列表；然后调用PDF解析工具提取对比文件的技术特征；接着调用一个自定义的创造性分析Skill，将本申请与对比文件的技术特征进行逐项比对；最后调用权利要求撰写Skill生成草案。

我实际搭建过一个简化版的工作流，用Claude Desktop作为智能体前端，通过MCP接入了Google Patents的检索接口和一个自己写的Python脚本（用于检查权利要求中是否出现“所述”指代不明的情况）。整个搭建过程花了大概两天，主要时间花在调试MCP Server的接口和写那个检查脚本上。跑通之后的体验确实好，智能体可以自主完成“检索-分析-检查”的闭环，我只需要在关键节点做审核和调整。

但这条路线对使用者的技术要求不低。你需要懂基本的Python编程，理解MCP的Server-Client架构，知道怎么配置JSON格式的工具描述文件。对于大多数专利代理人来说，这个门槛偏高。不过好消息是，已经有一些开源项目在降低这个门槛，比如有人做了封装好的专利检索MCP Server，你只需要填API Key就能用。

3. 专利检索环节：MCP协议真正能打的地方

3.1 传统检索方式的效率瓶颈在哪里

专利检索是专利工作中最耗时的环节之一。传统的检索流程是：确定关键词和分类号，在多个数据库（CNIPA、Espacenet、Google Patents、Incopat等）中分别检索，下载对比文件，逐篇阅读筛选。一个中等复杂度的检索任务，从确定检索式到筛选出10篇左右的对比文件，熟练的检索员也需要3-5个小时。瓶颈主要在两个方面：一是跨库检索的重复劳动，同一个检索式要在不同数据库里分别输入和调整；二是对比文件筛选的阅读量，检索结果动辄几百篇，真正相关的可能只有几篇，但你必须把这几百篇的摘要都过一遍。

AI工具在这个环节的切入点很明确：用智能体自动执行跨库检索，用自然语言处理技术对检索结果进行相关性排序和摘要提取。我测试过用MCP协议接入Google Patents的检索接口，让智能体根据我提供的技术方案描述自动生成检索式并执行检索，然后对返回的结果按相关度打分排序。实测下来，检索式的生成质量取决于你给智能体的技术描述是否清晰，如果描述中包含明确的技术特征和技术效果，它生成的检索式质量相当不错，能覆盖到我手动构造的检索式80%以上的关键要素。

3.2 用MCP串联检索工具的实际操作步骤

我把自己搭建的检索工作流拆解一下，方便你复现。整个流程分为四个步骤：

第一步：准备MCP Server。我用的是Python写的自定义MCP Server，核心功能是封装Google Patents的检索API。代码结构很简单，定义一个search_patents工具，接收关键词、分类号、日期范围等参数，返回检索结果的JSON列表。MCP Server的配置文件中需要声明这个工具的名称、描述和参数schema，这样智能体才知道什么时候该调用它。

# 简化的MCP Server工具定义示例 @mcp.tool() def search_patents(keywords: str, cpc_class: str = "", date_range: str = "") -> list: """根据关键词和分类号检索专利""" # 调用Google Patents API results = google_patents_search(keywords, cpc_class, date_range) return [{"title": r.title, "abstract": r.abstract, "patent_id": r.id} for r in results]

第二步：配置智能体的系统提示词。系统提示词决定了智能体的行为模式。我写的提示词大意是：“你是一个专利检索助手。当用户提供技术方案描述时，你需要：1）提取核心技术特征；2）生成2-3组检索式，每组包含关键词和IPC/CPC分类号；3）调用search_patents工具执行检索；4）对返回结果按技术特征覆盖度进行相关性排序；5）输出排序后的结果列表，并标注每篇对比文件与目标方案的相关性理由。”

第三步：执行检索并人工复核。智能体执行完检索后，我会人工检查它生成的检索式是否合理，排序结果是否符合我的预期。这一步不能省，因为智能体对技术方案的理解可能出现偏差，尤其是当技术方案涉及多个技术领域的交叉时。

第四步：迭代优化。根据人工复核的结果，调整系统提示词或检索策略。比如我发现智能体倾向于过度使用上位概念关键词，导致检索结果过于宽泛，就在提示词中加入了“优先使用说明书中出现过的具体技术术语作为关键词”的约束。

提示：MCP协议目前还在快速演进中，不同智能体平台对MCP的支持程度不一样。Claude Desktop的支持最完善，国内的一些智能体平台也在陆续跟进。如果你用的是国产智能体平台，建议先确认它是否支持自定义MCP Server的接入。

3.3 检索结果相关性排序的实测效果

我拿一个真实的案例做了对比测试。技术方案是一种“基于注意力机制的医学图像分割方法”，我分别用传统关键词检索和MCP智能体检索各跑了一遍。传统检索我用了“注意力机制 AND 医学图像 AND 分割”这组关键词，在Google Patents上返回了约1200条结果，我手动筛选出15篇相关度较高的对比文件，耗时约2.5小时。MCP智能体检索生成了三组检索式，返回了约800条结果，智能体自动排序后我检查了前30篇，其中12篇与手动筛选的结果重合，另外还发现了3篇我手动检索时漏掉的相关专利。整个流程耗时约40分钟，其中智能体执行检索和排序用了约15分钟，我人工复核用了25分钟。

这个结果说明智能体在召回率上已经接近人工水平，在效率上有明显优势。但它的精确率还有提升空间，前30篇中有约6篇是明显不相关的，智能体对技术方案的理解在某些边界情况下会出现偏差。我的经验是，把智能体当作第一轮粗筛工具，用它把候选集从几百篇缩小到几十篇，然后人工做精细筛选，这个组合的效率最高。

4. 权利要求撰写与审查意见答复：智能体能力的真实边界

4.1 智能体写权利要求的三个典型失败模式

我让多个智能体平台尝试撰写同一份技术交底书的权利要求书，总结出三个高频失败模式。

失败模式一：独立权利要求缺少必要技术特征。智能体倾向于把说明书中提到的所有技术特征都往独立权利要求里塞，导致独立权利要求的保护范围过窄。比如一个方案包含“数据采集模块、预处理模块、特征提取模块、分类模块”四个组成部分，智能体写的独立权利要求会把四个模块全部写进去，但实际上“预处理模块”可能不是解决核心技术问题的必要技术特征，不应该出现在独立权利要求中。这个问题的根源在于智能体缺乏对“必要技术特征”的判断能力，它不知道哪个特征对解决技术问题是必不可少的。

失败模式二：从属权利要求的引用关系混乱。智能体生成的从属权利要求经常出现引用关系错误，比如权利要求3引用权利要求1，权利要求4又引用权利要求3，但权利要求4的技术特征实际上与权利要求3的方案没有逻辑上的进一步限定关系。这种错误在形式上可能不会导致驳回，但会影响专利的层次结构和后续的无效程序中的修改灵活性。

失败模式三：功能性限定使用不当。这是最普遍的问题。智能体喜欢用“用于...的装置”“被配置为...”这种功能性语言来撰写装置权利要求，但审查指南对功能性限定的使用有严格限制。如果说明书中没有给出足够的具体实施方式，这种功能性限定会被认定为“得不到说明书支持”。我测试的几个平台中，只有智慧芽的AI助手在提示词中内置了功能性限定的警告机制，其他平台都需要人工逐条检查。

4.2 审查意见答复场景下智能体的可用性评估

审查意见答复是专利代理工作中最标准化的环节，也是智能体最容易发挥价值的场景。我拿一份真实的第一次审查意见通知书做了测试，审查员指出的缺陷是“权利要求1相对于对比文件1和对比文件2的结合不具备创造性”。我让智能体生成答复草稿，然后对比我自己写的答复。

智能体生成的答复草稿结构完整，包含了“修改权利要求”“争辩创造性”“陈述技术效果”三个部分。在争辩创造性部分，它正确地识别出了本申请与对比文件1的区别技术特征，并尝试论证该区别技术特征带来了预料不到的技术效果。但问题在于，它引用的“预料不到的技术效果”是从说明书中直接摘录的，没有结合对比文件2的技术启示进行针对性反驳。审查员的逻辑是“对比文件2给出了将区别特征应用到对比文件1的启示”，要有效反驳这个逻辑，你需要论证对比文件2中的相应技术手段与本申请中的区别特征在技术领域、所解决的技术问题、技术效果上存在差异，使得本领域技术人员没有动机将二者结合。智能体目前还做不到这种深度的法律论证。

我的判断是，智能体在审查意见答复场景下的定位应该是草稿生成器，它能帮你快速搭建答复的框架、提取关键的技术特征对比、生成形式合规的修改文本，但核心的争辩逻辑和法律论证必须由代理人自己完成。用得好能省掉50%左右的机械劳动时间，但省不掉最核心的思考环节。

4.3 一个可落地的半自动答复工作流

基于上面的测试结果，我整理了一个目前实际在用的半自动答复工作流，分四步走。

第一步：智能体预处理。把审查意见通知书和申请文件一起丢给智能体，让它输出：审查员指出的缺陷清单、每条缺陷对应的法条、审查员引用的对比文件及其关键段落、建议的修改方向。这一步用通用大模型就能做，DeepSeek的表现足够好。

第二步：人工确定答复策略。基于智能体的预处理结果，代理人确定每条缺陷的答复策略：是修改权利要求还是纯争辩，修改的话怎么改，争辩的话核心论点是什么。这一步是纯人工的，不能交给AI。

第三步：智能体生成答复草稿。把答复策略输入智能体，让它生成答复意见书的草稿。这一步用专利垂类平台的效果比通用模型好，因为垂类平台内置了答复格式模板和法条引用规范。

第四步：人工精修和法律论证。在智能体草稿的基础上，代理人进行针对性的修改和补充，重点是创造性争辩中的技术启示分析和预料不到的技术效果论证。

这个工作流实测下来，一份中等复杂度的审查意见答复，从收到通知书到完成答复初稿，传统方式需要4-6小时，用这个半自动流程可以压缩到2-3小时。省下来的时间主要是在格式调整、法条查找、技术特征对比表的制作上。

5. Skills技能包在专利实务中的定制化开发思路

5.1 为什么通用Skills不够用

目前市面上的Skills技能包大多是面向通用办公场景的，比如“文档摘要”“邮件撰写”“数据整理”这类。专利实务需要的Skills非常垂直，比如“权利要求引用关系检查”“说明书技术术语一致性校验”“审查意见缺陷类型自动分类”“对比文件技术特征提取与比对”。这些Skills在公开市场上基本找不到现成的，必须自己开发或者定制。

我尝试过用低代码平台搭建几个简单的专利Skills。第一个是“权利要求编号与引用检查”Skill，逻辑很简单：解析权利要求文本，提取每条权利要求的编号和引用关系，检查是否存在引用错误（如引用不存在的权利要求编号、从属权利要求引用了同样从属的权利要求等）。这个Skill用Python写核心逻辑，封装成MCP工具，大概花了半天时间。

第二个是“技术术语一致性检查”Skill，逻辑稍微复杂一些：提取说明书中出现的所有技术术语，检查同一概念是否在不同位置使用了不同的表述（比如“图像采集单元”和“图像获取模块”混用）。这个Skill需要维护一个术语同义词表，我目前是用一个简单的JSON文件来管理，后续可以考虑用向量数据库来做语义级别的术语匹配。

5.2 开发一个专利Skills的完整流程

以“审查意见缺陷类型自动分类”Skill为例，我详细说一下开发流程。

第一步：定义输入输出。输入是审查意见通知书的文本内容，输出是一个结构化的缺陷列表，每条缺陷包含：缺陷类型（新颖性/创造性/不清楚/得不到支持/其他）、涉及的权利要求编号、审查员引用的法条、缺陷描述摘要。

第二步：准备训练/提示数据。我收集了50份真实的审查意见通知书，人工标注了每份通知书中的缺陷类型和对应法条。这些数据用来构造Few-shot提示，让大模型在分类时参考示例。

第三步：编写Skill逻辑。核心是一个提示词模板，将审查意见文本和Few-shot示例一起输入大模型，要求它输出JSON格式的分类结果。然后用Python做后处理，校验JSON格式的合法性，提取关键字段。

第四步：封装为MCP工具。将上述逻辑封装成一个MCP Server，定义工具名称为classify_oa_defects，参数为审查意见文本，返回值为结构化的缺陷列表。

第五步：测试与迭代。用预留的20份审查意见做测试，计算分类准确率。我第一版的准确率大概是75%，主要错误集中在“创造性”和“得不到支持”的混淆上。通过增加Few-shot示例中这两种缺陷的区分性描述，第二版准确率提升到了88%。

注意：Skills的开发不是一劳永逸的。审查指南的修订、审查实践的变化都会影响Skills的效果。建议每季度用新的审查意见数据做一次回归测试，必要时更新提示词和示例。

5.3 Skills组合使用的协同效应

单个Skills的价值有限，但多个Skills组合起来就能形成完整的工作流。我目前搭建的Skills组合包括：classify_oa_defects（缺陷分类）、extract_comparison_features（对比文件特征提取）、check_claim_references（权利要求引用检查）、generate_response_draft（答复草稿生成）。这四个Skills通过MCP协议串联，智能体可以按照“分类缺陷→提取对比文件特征→检查权利要求修改后的引用关系→生成答复草稿”的顺序自动执行。

实测下来，这个组合工作流处理一份审查意见答复的时间大约是25分钟（不含人工精修），而传统方式下光是制作技术特征对比表就需要1小时以上。当然，智能体生成的草稿仍然需要人工精修，但精修的工作量比从零开始写要小得多。

6. 数据安全与合规：专利AI工具不可回避的红线

6.1 未公开专利申请的保密要求

专利代理行业有一条铁律：未公开的专利申请文件属于客户的商业秘密，任何未经授权的披露都可能导致严重的法律后果。在使用AI工具处理专利申请文件时，这个问题尤其敏感。你把一份未公开的专利申请文件上传到某个AI平台，这份文件就离开了你的本地环境，进入了平台的服务器。平台是否会保留这些数据、是否会用于模型训练、数据存储在哪里、传输过程是否加密，这些都是必须搞清楚的问题。

我调研了国内主要的专利AI平台，发现数据安全政策差异很大。有的平台明确承诺“用户上传的文件仅用于本次服务，服务完成后立即删除，不用于任何模型训练”，并且提供了本地化部署方案。有的平台则在用户协议中含糊地写着“可能将用户数据用于服务优化”，这种就需要格外警惕。我的建议是，对于核心客户的未公开申请，优先使用支持本地化部署的方案，或者至少确认平台有明确的数据不保留承诺。

6.2 本地化部署的可行性与成本

本地化部署是解决数据安全问题的最彻底方案。目前可行的方法是在本地服务器上部署开源大模型（如DeepSeek的开源版本、Qwen的开源版本），然后通过MCP协议接入本地的专利工具链。这样所有数据都在你自己的服务器上流转，不经过任何第三方平台。

我实际测试过在本地部署DeepSeek的7B版本，用一张消费级显卡（RTX 4090）就能跑起来。推理速度对于专利撰写这种不需要实时响应的场景来说完全够用，生成一份权利要求草稿大约需要30-60秒。但7B版本的能力相比云端的大参数模型有明显差距，尤其是在技术方案理解和法律论证方面。如果预算允许，建议至少部署32B以上的版本，但那就需要专业级的GPU了，成本会高不少。

一个折中方案是混合部署：对数据安全要求最高的环节（如未公开申请的权利要求撰写）使用本地模型，对数据安全要求相对较低的环节（如公开专利的检索和分析）使用云端模型。这样既能保证核心数据不出本地，又能利用云端模型的更强能力。

6.3 使用AI工具时的合规检查清单

根据我的实际经验，使用AI工具处理专利业务时，建议逐项确认以下事项：

• 平台的数据保留政策是否明确承诺不保留用户上传的文件
• 平台是否提供本地化部署或私有化部署选项
• 数据传输过程是否使用加密协议
• 平台是否通过了相关的信息安全认证
• 用户协议中是否有关于数据用于模型训练的条款
• 对于涉外业务，平台的数据存储位置是否符合相关要求

这份清单看起来繁琐，但专利文件涉及客户的核心技术秘密，一旦泄露后果不堪设想。我个人的原则是：未公开的申请文件，要么用本地部署的模型处理，要么在脱敏后使用云端模型。脱敏的意思是删除申请文件中的申请人信息、发明人信息、具体的参数数值等敏感内容，只保留技术方案的框架性描述。这样即使数据泄露，也不会直接暴露客户的核心技术细节。

7. 现阶段专利AI工具选型的个人建议

如果你是一个专利代理人，想开始尝试AI工具，我的建议是从通用大模型+人工复核的模式起步。先用DeepSeek或Kimi做技术方案理解和背景技术梳理，这个环节风险最低、收益最直接。等你对AI工具的能力边界有了直观感受之后，再考虑引入专利垂类平台或搭建MCP工作流。

如果你是一个企业IPR，管理大量的专利申请和审查意见答复，建议优先评估专利垂类平台的批量处理能力和数据安全政策。批量处理能力决定了工具能否真正提升团队效率，数据安全政策决定了工具能否合规使用。两者缺一不可。

如果你是一个技术能力较强的专利工程师，想深度定制AI工作流，MCP协议是目前最值得投入时间研究的方向。它的生态还在快速成长中，现在掌握的MCP Server开发能力，未来两三年内都会是稀缺技能。我自己的体会是，花两天时间搭一个能跑通的MCP工作流，比花两周时间研究各种平台的UI功能要有价值得多。

最后说一个我踩过的坑。刚开始用AI工具的时候，我总想着让它一步到位生成完整的专利申请文件。试了多次之后发现，AI在专利领域的定位应该是副驾驶，不是自动驾驶。它最擅长的是信息提取、格式检查、草稿生成这些辅助性工作，而技术方案的理解、权利要求的布局、创造性高度的判断这些核心决策，仍然需要代理人的专业判断。把AI用在它擅长的环节，把人的精力集中在真正需要专业判断的地方，这才是现阶段专利AI工具的正确打开方式。