patent-workflow

name patent-workflow description 三阶段专利撰写workflow（Research → Plan → Implement），借鉴AutoPatent架构，通过 Codex CLI 原生 spawn_agent 派发 explorer/reviewer child agent 协作，确保专利质量和授权率；也用于整理或优化已有 DOCX 专利交底书、保留图片和版式资源并生成新版 Word 文档 auto_invoke true tags ["patent","workflow","multi-agent","quality-gate","omc-agents"] version 0.2.0 source fork updated_at 2026-05-29T03:50:00.000Z layer domain checksum 917cd56131d6d9db6b2431ba2b2612053881fe48be843576d7199c4a99a80f1e Patent Workflow Skill - 专利三阶段撰写工作流 核心架构 灵感来源 : AutoPatent多Agent框架 + InstructPatentGPT权利要求优化 三阶段workflow : Research阶段 (Planner) → Plan阶段 (Planner) → Implement阶段 (Writer + Examiner) ↓ ↓ ↓ 专利检索 专利大纲生成 分段撰写 + 质量审查 术语收集 PGTree结构 IRR检查 + 术语一致性 发明分析(explorer) 权利要求审查(reviewer) explorer+reviewer 并行复审 质量门禁 : Gate 1: Research → Plan (检索完整性 ≥80%) Gate 2: Plan → Implement (大纲完整性 ≥85%) Gate 3: Implement → Delivery (质量综合评分 ≥90%) 交付约束 : 最终交付物必须是 Word .docx 文件；聊天回复只给文件路径、简短摘要、质量评估和风险说明。 如果用户提供已有 .docx 交底书并要求优化，默认进入 DOCX 保真优化模式，先保留原文档容器资源，再修改正文。 不把完整专利正文作为最终交付直接贴在聊天里；如果当前环境无法生成 .docx ，先说明阻塞并要求启用 Documents/Word 处理能力或提供可用 DOCX 生成工具。 Native Subagent Protocol (Codex) Codex CLI 支持原生 child agent。本 skill 在三个阶段都通过 spawn_agent 派发只读 subagent，主线 Codex 负责撰写与综合。最小编排： spawn_agent -> (send_input 可选) -> wait_agent -> close_agent 派发到哪个 agent_type （对应 .codex/agents/*.toml 已有定义）： 角色 agent_type TOML 默认 用于 发明架构分析 explorer medium effort, read-only Phase 1.3 拆解发明结构、对比 prior-art 权利要求对抗审查 reviewer high effort, read-only Phase 2.3 / 3.3 多视角 claims 复审 文献核验（可选） docs-researcher medium effort, read-only Phase 1.2 校验 prior-art 引用真实性 Message framing （Codex 把 message 视作 user-level 输入，按官方建议加 XML 标签）： Your task is to perform the following. Follow the instructions below exactly. <agent-instructions> [本 SKILL 中各 Step 给出的 prompt 内容] </agent-instructions> Execute this now. Output ONLY the structured response specified above. 当 child agent 不可用时的 fallback （参考 ultrapilot 约定）：在单条响应里用 [EXPLORER] / [REVIEWER] / [SYNTHESIS] 块顺序自演三个角色，仍按 prompt 模板输出。 可选强化 ：如需更强专利领域偏置，可在 .codex/agents/ 新增 patent-analyst.toml （基于 explorer）和 patent-claims-reviewer.toml （基于 reviewer），把 developer_instructions 换成专利特定指令；本 skill 不要求，但能进一步降低发散。 适用场景 自动触发条件 : 用户说："写专利"、"申请专利"、"专利workflow" 用户说："三阶段专利撰写"、"专利质量优化" 用户提到："专利检索"、"权利要求优化"、"专利授权率" 用户上传 .docx 专利交底书并要求："优化交底书"、"生成新版 Word"、"保留图片/附图/题注/格式" 与现有cn-patent-application的区别 : cn-patent-application : 单阶段文档模板填充，适合快速生成交底书 patent-workflow : 三阶段系统化workflow，适合高质量专利申请（目标：提高授权率） Word / DOCX 处理协议 本 skill 生成或优化专利材料时，默认以 .docx 作为最终交付格式。优先使用可用的 Documents skill、结构化 DOCX API、 python-docx 、OpenXML 解包编辑或等价工具；选择工具时以“保真”和“可校验”为第一目标。 A. 新建专利申请 DOCX 适用于用户没有提供原始 Word 交底书，或明确要求生成全新专利申请文本。 先完成 ResearchPack、ImplementationPlan 和 Gate 3 审查，再生成 .docx 。 文档至少包含：技术领域、背景技术、发明内容、附图说明、具体实施方式、权利要求书、摘要、质量评估报告。 如有附图，先确认图片来源和图号，再插入 Word；不要只在正文写“见图1”却没有实际图片或附件路径。 文件名建议使用 [发明名称]-专利申请交付包.docx ，并在最终回复中提供绝对路径。 B. 已上传 DOCX 保真优化模式 适用于用户提供 .docx 专利交底书并要求优化、改写、完善、补强权利要求或生成新版 Word。默认启用本模式，除非用户明确要求重新排版。 核心原则： 保留原 DOCX 容器资源，而不是从抽取出的纯文本重新生成空白文档。 纯文本抽取只能用于理解内容，不能作为最终生成 Word 的唯一来源。 优先修改原文档解包后的 word/document.xml 及确需修改的页眉、页脚、脚注、尾注或批注 XML。 不删除或重命名 word/media/* ；不移除仍被正文引用的 word/_rels/document.xml.rels 图片关系；不破坏 [Content_Types].xml 中的图片类型声明。 尽量保留图片、附图题注、图号、编号、表格、样式、页眉页脚、脚注、批注和修订痕迹。 执行步骤： 识别输入文档：记录原始 .docx 路径、输出路径、用户指定的优化目标和必须保留的资源。 建立资源清单：统计 word/media/* 图片数量、文件名和可行时的哈希；统计图片 relationship 数量和 target；记录题注、图号和图片附近段落。 执行保真编辑：只改需要优化的正文、权利要求、摘要、质量报告等文字；如需新增章节，把新内容插入原文档结构，不覆盖整份文档。 重打包输出：基于修改后的原 DOCX 目录生成新版 .docx 。 交付前校验：比对优化前后图片数量、文件名、哈希和 relationship；发现图片丢失、关系断裂或题注错位时先修复，不交付缺图文档。 C. 允许重排版的例外 只有满足以下任一条件，才允许创建全新 .docx 替代保真编辑： 用户明确要求“重新排版”“不要保留原版式”。 原 DOCX 损坏、无法解包、无法编辑或不是真正的 Word 文档。 原文档只是参考资料，用户明确要求生成全新的专利申请文本。 即便重排版，也要优先提取原图片并重新插入新版 Word；如果无法保留图片，必须在质量评估报告和最终回复中标注图片/版式风险。 Phase 1: Research阶段 - 专利检索与技术分析 角色 : Planner Agent 目标 : 检索相关专利、收集术语、分析技术布局 时间 : 15-20分钟 Step 1.1: 技术信息收集（5分钟） 向用户提问收集（Codex CLI 直接以问答方式获取）: 发明概述: Q: "请简要描述你的发明（1-2句话）" 示例: "一种基于联邦学习的用户建模方法，保护数据隐私" 技术领域: Q: "涉及哪些技术领域？（用于检索相关专利）" 示例: "联邦学习、隐私计算、机器学习、用户画像" 核心创新点: Q: "与现有技术相比，你的核心创新是什么？" 示例: "使用第三方鉴权节点进行ID对齐，避免数据外泄" Word文档输入: Q: "是否已有 DOCX 交底书需要优化？如果有，是否必须保留图片、题注、表格、页眉页脚、批注或修订痕迹？" 默认: "已有 DOCX 时启用保真优化模式；无 DOCX 时生成全新专利申请 Word" Step 1.2: 专利检索（10分钟） 检索策略 : 工具链: 1 . exa-code检索 (优先): query: "[技术领域] patent prior art analysis" tokensNum: 5000 目的: 获取高质量专利文献和技术术语 2 . WebSearch / WebFetch (备选): query: "[发明关键词] 专利 现有技术" 目的: 补充中文专利信息（CNIPA、知网等） 3 . Context7检索 (可选): libraryID: 专利领域相关库 topic: "patent drafting best practices" 目的: 获取撰写标准和术语规范 检索内容: 现有专利布局: - 相关专利数量和趋势 - 主要专利权人 - 技术演进路径 技术术语库: - 标准技术术语 - 权利要求常用表述 - 避免的模糊词汇 现有技术方案: - 主流解决方案（2-3个） - 技术缺陷和局限性 - 技术发展方向 Step 1.3: 派发 explorer subagent 做发明架构分析（5分钟） spawn_agent(agent_type="explorer", message=<下方框架>) ，主线 wait_agent 取回结果后 close_agent 。 Message 框架 （已套上 Codex 推荐的 XML 包装）： Your task is to perform the following. Follow the instructions below exactly. <agent-instructions> You are doing pre-drafting analysis for a patent application. Read-only. Do not propose claim text. Cite sources by URL or by patent number. Inputs: - Invention summary: [发明概述] - Technical domain: [技术领域] - Core innovation claim: [核心创新点] - Prior art shortlist (from Step 1.2): [代表性专利号 + URL 列表] - Terminology pool (from Step 1.2): [术语列表] Deliver a markdown report with these sections: 1. 架构层次拆解（模块 / 数据流 / 控制流） 2. 核心创新点 vs 次要创新点（每条附 prior-art 对比证据） 3. 与现有专利技术路线的差异面（表格：本发明 / 代表性 prior art / 差异） 4. 专利保护策略建议: - 推荐独立权利要求宽度: 宽 / 中 / 窄（附理由） - 建议保留的可选技术特征（供从属权利要求使用） 5. 不确定性 / 信息缺口（供 Quality Gate 1 判断是否需要补检） </agent-instructions> Execute this now. Output ONLY the structured markdown report. 为什么选 explorer 而不是 reviewer ： explorer.toml 的 developer_instructions 是 "Stay in exploration mode. Trace the real execution path, cite, avoid proposing fixes" —— 恰好匹配 Research 阶段"只分析、不出权利要求"。 reviewer 留给 Plan / Implement 阶段做对抗式 claims 评审，避免角色重叠。 若发明本质是某个仓库的代码改造，可追加一个 spawn_agent(agent_type="explorer", ...) 单独跑代码路径调研，不替换本次。 Fallback（child agent 不可用时） ：主线 Codex 在单条响应中以 [EXPLORER] 块自演同样的 prompt，紧跟主线综合。 Step 1.4: Research阶段输出 ResearchPack格式 : # 📋 Patent ResearchPack: [发明名称] ## 技术概述 - 发明名称: [标准格式名称] - 技术领域: [主领域、次领域] - 核心创新: [1-2句话] - 技术成熟度: [概念/原型/产品] ## 现有专利布局 ### 相关专利统计 - 检索到相关专利: [数量] - 主要专利权人: [公司/机构列表] - 技术演进趋势: [分析] ### 代表性专利 1. [专利号] - [专利名称] - 技术方案: [简述] - 技术缺陷: [分析] - 与本发明的区别: [对比] 来源: [URL] 2. [专利号] - [专利名称] ... ## 技术术语库 ### 标准术语（从专利文献提取） - [术语1]: [定义] (来源: [专利号]) - [术语2]: [定义] ... ### 权利要求常用表述 - [表述1]: [示例] - [表述2]: [示例] ... ### 避免使用的模糊词汇 - ❌ "等"、"或类似"、"大约" - ❌ "优化"、"改进"（需具体说明如何优化） - ❌ 主观判断词汇（"优秀"、"高效"） ## Explorer Subagent 技术分析结果 [explorer subagent 输出的架构分析、prior-art 差异、保护策略建议] ## 保护策略建议 ### 独立权利要求策略 - 建议范围: [宽/中/窄] - 核心技术特征: [列表] - 可选技术特征: [列表] ### 从属权利要求策略 - 优选实施例: [列表] - 可替代方案: [列表] ## Quality Gate 1检查 - ✅ 检索到≥3个相关专利 - ✅ 技术术语库≥10个术语 - ✅ 现有技术方案分析完整 - ✅ Explorer subagent 分析完成（含保护策略与不确定性清单） - 综合评分: [X/100] (≥80通过) ## Sources 1. [来源1 URL] 2. [来源2 URL] ... Quality Gate 1判断 : 检索完整性 ≥80分 → 进入Plan阶段 <80分 → 补充检索或询问用户提供更多信息 Phase 2: Plan阶段 - 专利大纲生成（PGTree模式） 角色 : Planner Agent 目标 : 生成结构化专利大纲，设计权利要求层次 时间 : 15-20分钟 Step 2.1: PGTree大纲规划（10分钟） PGTree (Planning Graph Tree) 结构 : 专利文档树形结构: 根节点: 发明名称 第一层: 主要章节 - 技术领域 - 背景技术 - 发明内容 - 附图说明 - 具体实施方式 第二层: 章节细分 发明内容: - 发明目的 - 技术方案 - 有益效果 具体实施方式: - 实施例1（主要实施例） - 实施例2（变形方案） - 实施例3（其他应用场景） 第三层: 段落规划 技术方案: - 总体技术方案（3-5段） - 关键技术特征（2-3段） - 可选技术特征（1-2段） 大纲生成策略: 1 . 从ResearchPack提取核心创新点 2 . 参考相关专利的章节结构 3 . 使用标准专利术语 4 . 设计3个层次的权利要求 Step 2.2: 权利要求层次设计（5分钟） 借鉴InstructPatentGPT的策略 : 独立权利要求: 范围设计: - 宽权利要求: 保护核心思路（易被规避，但覆盖广） - 中权利要求: 保护关键技术特征（平衡） - 窄权利要求: 保护具体实施方式（授权率高） 策略选择: 高创新度 → 宽权利要求 + 多个从属权利要求 中创新度 → 中权利要求 + 梯度保护 低创新度 → 窄权利要求 + 详细实施例 从属权利要求: 层次1: 进一步限定核心特征 层次2: 具体实施参数和配置 层次3: 优选方案和最佳模式 权利要求数量建议: 独立权利要求: 1 -3 个（方法、系统、装置） 从属权利要求: 8 -15 个（覆盖主要变形） Step 2.3: 派发 reviewer subagent 做权利要求对抗审查（5分钟） spawn_agent(agent_type="reviewer", message=<下方框架>) ， wait_agent 取回 → close_agent 。 为什么选 reviewer ： .codex/agents/reviewer.toml 默认 model_reasoning_effort = "high" + sandbox_mode = "read-only" + "Review like an owner, lead with concrete findings" —— 与权利要求需要承受审查员/规避者/诉讼三方压力测试的特性高度匹配。 Message 框架 ： Your task is to perform the following. Follow the instructions below exactly. <agent-instructions> You are reviewing a *draft* patent claims structure (claims not yet finalized). Read-only. Do not rewrite claims wholesale. Produce concrete findings only. Inputs: - ResearchPack (Phase 1 输出, 含 prior art + 术语库) - 草拟权利要求层次: 独立权利要求: [列表] 从属权利要求: [列表] - 选定的保护范围档位: 宽 / 中 / 窄 请用四视角对抗方式输出 findings (每条标注视角): [审查员视角] 哪些特征会被判"非显而易见性不足"或"权利要求过宽" [规避者视角] 哪些措辞最容易被竞争对手设计绕过（给反例） [诉讼律师视角] 哪些表述在维权时举证困难 [代理人视角] 是否符合《专利审查指南》标准范式 / 术语规范 最终结构化输出: 1. 高风险条款清单（按风险等级排序，每条附"哪个视角发现 / 为什么 / 建议改法"） 2. 建议补充的限制性术语 / 功能性表述（给出具体替换文本） 3. 推荐的层级再编排（如有） 4. 术语一致性问题列表（对照 ResearchPack 术语库） 5. 总判: 建议返工 Plan / 直接进入 Implement </agent-instructions> Execute this now. Output ONLY the five structured sections above. Fallback ：主线 Codex 在单条响应中用 [REVIEWER] 块自演四视角，输出同样 5 个 section。 Step 2.4: Plan阶段输出 ImplementationPlan格式 : # 📝 Patent ImplementationPlan: [发明名称] ## 专利大纲（PGTree结构） ### 1. 技术领域 段落1: 本发明涉及[一级领域]，特别涉及[二级领域] 关键术语: [术语列表] ### 2. 背景技术 段落1: 行业现状和技术发展 段落2: 现有技术方案1描述 段落3: 现有技术方案2描述 段落4: 现有技术缺陷总结 关键术语: [术语列表] ### 3. 发明内容 #### 3.1 发明目的 段落1: 本发明要解决的技术问题 关键术语: [术语列表] #### 3.2 技术方案 段落1: 总体技术方案概述 段落2: 核心技术特征1 段落3: 核心技术特征2 段落4: 可选技术特征 段落5: 技术方案工作流程 关键术语: [术语列表] #### 3.3 有益效果 段落1: 技术效果1（量化数据） 段落2: 技术效果2（对比优势） 段落3: 技术效果3（附加价值） 关键术语: [术语列表] ### 4. 附图说明 图1: [总体架构图] 图2: [流程图] 图3: [数据流图] ### 5. 具体实施方式 #### 实施例1（主要实施例） 段落1-3: 详细技术方案描述 段落4-5: 关键参数和配置 段落6: 技术效果验证 关键术语: [术语列表] #### 实施例2（变形方案1） 段落1-2: 变形方案描述 段落3: 与实施例1的区别 关键术语: [术语列表] #### 实施例3（变形方案2） 段落1-2: 变形方案描述 段落3: 应用场景扩展 关键术语: [术语列表] --- ## 权利要求书结构 ### 独立权利要求1（方法） 一种[发明名称]，其特征在于，包括以下步骤： S1: [步骤1描述，使用标准术语] S2: [步骤2描述] S3: [步骤3描述] ... ### 从属权利要求2-5（进一步限定） 2. 根据权利要求1所述的方法，其特征在于，所述[技术特征]包括... 3. 根据权利要求1所述的方法，其特征在于，所述[技术特征]进一步包括... ... ### 独立权利要求6（系统） 一种[发明名称]系统，其特征在于，包括： 模块1: 用于[功能描述] 模块2: 用于[功能描述] ... ### 从属权利要求7-10（系统细化） ... --- ## Reviewer Subagent 审查建议 [reviewer subagent 的四视角对抗审查结果与可执行修改建议] --- ## 实施清单 ### 文件准备 - [ ] 创建专利申请书文档 - [ ] 准备附图（流程图、架构图） - [ ] 准备实验数据（技术效果证明） ### 撰写顺序 1. 先写具体实施方式（最详细） 2. 再写发明内容（提炼核心） 3. 最后写背景技术（对比铺垫） 4. 权利要求书（基于说明书提炼） ### 术语一致性检查 - [ ] 全文使用统一术语（从术语库选择） - [ ] 避免模糊词汇 - [ ] 技术特征描述完整 --- ## Quality Gate 2检查 - ✅ 大纲完整（5个主要章节） - ✅ 权利要求层次清晰（独立+从属） - ✅ 段落规划详细（每段有关键术语） - ✅ Reviewer subagent 审查建议已整合（高风险条款已处理） - 综合评分: [X/100] (≥85通过) --- ## 回滚策略 如果Plan阶段发现问题： - 技术方案不够详细 → 回到Research阶段补充检索 - 权利要求范围不合理 → 重新设计权利要求策略 - 术语不规范 → 补充术语库 Quality Gate 2判断 : 大纲完整性 ≥85分 → 进入Implement阶段 <85分 → 补充大纲或重新规划 Phase 3: Implement阶段 - 分段撰写与质量审查 角色 : Writer Agent + Examiner Agent 目标 : 按大纲撰写专利文档，多层次质量审查 时间 : 40-60分钟 Step 3.1: Writer Agent分段撰写（30分钟） 撰写策略 : 顺序执行: 1 . 具体实施方式 (20分钟):