graphify 并行语义抽取解析Task 工具单消息多子代理分发的磁盘协议Step B2【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify在 graphify 的三步语义抽取管线Step 3 Part B中文档、论文与图片的抽取不是由主对话逐个阅读文件完成的而是把每个文件分块chunk交给并行运行的子代理再统一回收 JSON 结果。本指南聚焦这套并行协议的核心环节——Step B2 用Task工具在“同一条消息”里分发全部子代理并约定每个子代理把结果写到独立磁盘文件涵盖调用模板、CHUNK_PATH绝对路径规则、抽取提示词的装载时机以及它与上游缓存检查B0/B1和下游合并B3的衔接。读完你将掌握 graphify 为支持Task工具的宿主Agent 平台设计的整套并行分发与磁盘落盘约定能够照着模板正确驱动一次大规模语义抽取。这份协议的来源与适用位置本协议对应仓库中 task-tool-disk.md 这一片段。它不是一份独立运行的文档而是 graphify 技能生成系统skillgen中按平台注入的“分发片段”skillgen 把 core.md 作为各平台共享的精简核心模板模板里在 Step B2 处留有DISPATCH占位槽见 core.md 中 “Step B1 - Split into chunks” 与 “Step B3 - Collect, cache, and merge” 之间gen.py 的_render_core()会用dispatch/平台.dispatch.md的内容替换该占位槽平台清单 platforms.toml 通过dispatch字段把每个宿主映射到具体片段。其中声明dispatch task-tool-disk的是droid、amp、agents三个平台Trae 使用加了平台注记的变体task-tool-disk-trae。渲染产物的落盘快照可以在 expected/graphify__skill-droid.md 等文件里直接看到这份片段被拼入完整技能正文后的形态。同类分发片段横向一览片段宿主/平台依据 platforms.toml分发机制agent-tool-disk.mdclaude、kilo、copilot、claw、kiro、piAgent 工具 磁盘写文件强制subagent_typegeneral-purposecodex-agenttask.mdcodexspawn_agent/wait_agent/close_agent内存汇总无逐块磁盘文件opencode-mention.mdopencodemention分发若无法写文件则回退串行磁盘路径manual-paste.mdvscode无并行子代理 API手动回贴 JSONtask-tool-disk.mddroid、amp、agentsTask工具 磁盘写文件task-tool-disk-trae.mdtrae同上并附“Trae 不支持 PreToolUse hooksAGENTS.md 是常驻机制”的注记核心协议一条消息里并发调用所有TaskStep B2 的第一条铁律是并行必须以“同一条消息内多次工具调用”来实现。片段原文的写法是Uses theTasktool for parallel subagent dispatch. CallTaskonce per chunk — ALL in the same response so they run in parallel.这与另一个常见误区直接对立如果先发起一个Task、等它结束再发起下一个就是串行执行等于放弃并行。因此主代理必须一次性把当前批次全部 chunk 的Task调用放进同一条回复中发出由宿主平台并行调度。随后把抽取提示词作为任务的description传入片段给出的可复制模板如下Task(descriptionYour task is to perform the following. Follow the instructions below exactly.\n\nagent-instructions\n[extraction prompt, with FILE_LIST, CHUNK_NUM, TOTAL_CHUNKS, DEEP_MODE substituted]\n/agent-instructions\n\nExecute this now. Output ONLY the structured JSON response.)模板里有几个值得注意的结构性约定agent-instructions标签包裹抽取提示词含已替换好的FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE被放进显式的指令标签内与结尾的命令性收束句分离结尾收束句Output ONLY the structured JSON response.要求子代理只返回结构化 JSON不带任何解释、markdown 围栏或前言——这与 extraction-spec 里“no explanation, no markdown fences, no preamble”的约束一致占位符逐字替换FILE_LIST是这一块要读的文件清单CHUNK_NUM/TOTAL_CHUNKS标识第几块/共几块DEEP_MODE则把是否传了--mode deep从主调用一路透传到每个子代理。需要说明的是Task是宿主平台提供的工具接口各宿主的参数形态可能不同这里展示的是片段在 task-tool-disk.md 中约定的、面向Task工具的调用骨架实际平台以该工具的可用能力为准。每个子代理写自己的磁盘文件与 Codex 的内存汇总方案不同这套协议采用磁盘文件作为子代理输出与主流程之间的唯一契约Each subagent writes its result to its owngraphify-out/.graphify_chunk_NN.json. Collect results as eachTaskcompletes and parse each as JSON.文件命名是定长两位数字序号NN例如第 3 块写graphify-out/.graphify_chunk_03.json。这样做的价值在下游 Step B3 充分体现见 core.md 的 “Step B3 - Collect, cache, and merge”主代理逐个检查graphify-out/.graphify_chunk_NN.json是否在磁盘上存在“文件存在且可解析”就是该块成功的判定信号若某块文件缺失说明子代理可能是只读类型导致无法写盘B3 会打印警告提示改用 general-purpose 类代理而不是静默跳过超过半数块失败/缺失时停止并提示用户重新运行。也就是说这份片段与 B3 形成“写入方—校验方”的配合B2 定义怎么写、写到哪B3 定义怎么核对、怎么容错。CHUNK_PATH必须使用绝对路径片段对子代理写盘路径的强制要求是绝对路径并在分发前就推导好。原文给出的 shell 片段为PROJECT_ROOT$(pwd) # cwd — where Part C globs graphify-out/ (NOT .graphify_root/scan dir, #1392) # Then for chunk N: CHUNK_PATH${PROJECT_ROOT}/graphify-out/.graphify_chunk_0N.json背后是两点工程考量为何必须绝对路径extraction-spec见 extraction-spec.md对子代理写盘的指示是 “no relative paths — Write resolves relative paths against an undefined cwd and the file will be silently lost”。子代理的当前工作目录不可靠相对路径可能把 JSON 写丢。CHUNK_PATH由主代理在分发前用$(pwd)推导确保graphify-out一定位于真实项目根下为何根必须是当前工作目录注释#1392提醒PROJECT_ROOT$(pwd)指的是后续 Part C 用 glob 收集graphify-out/的目录而不是.graphify_root/scan这类检测阶段用到的扫描目录避免把文件写进错误的根。抽取提示词只在需要时才装载片段的最后一段是关于依赖装载的“时机纪律”Seereferences/extraction-spec.mdfor the exact subagent prompt (JSON schema, node-ID rules, confidence rubric, hyperedge, and vision rules). Load it only here, only when at least one chunk holds a doc, paper, or image; a pure-code corpus has skipped Part B and never reads it.它指向的 extraction-spec.md渲染到各平台技能目录后的形态见 graphify/skills/amp/references/extraction-spec.md 一类产物是完整的子代理提示词内容包括JSON schemanodes/edges/hyperedges三段式及各自的字段形态Node-ID 规则小写、仅[a-z0-9_]格式为{stem}_{entity}stem 用完整仓库相对路径去掉扩展名、逐段拼接禁止追加任何 chunk 序号后缀置信度评分条confidence rubricEXTRACTED1.0、INFERRED从0.95/0.85/0.75/0.65/0.55中取一、AMBIGUOUS0.1–0.3明确禁止用 0.5 作默认值Hyperedge 规则3 个及以上节点共同参与同一概念/流程时使用每块最多 3 条Vision 规则对图片按 UI 截图/图表/推文/示意图/研究图/手写白板分类理解而非只做 OCR。关键约束是仅在“至少有一个 chunk 含 doc/paper/image”时才装载并逐字下发给每个子代理——纯代码语料库已在 B2 之前的 Fast path 跳过整个 Part B根本不会读到这份文件。而一旦需要下发给多个子代理则必须把同一份提示词逐字传递只替换五个占位符FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE、CHUNK_PATH保证每个子代理收到的是同一个“抽取契约”产出才有可比性。协议上下游从 B0 缓存到 B3 合并的完整链路把 Step B2 放回 core.md 定义的 Part B 全流程中其上下游是Fast path纯代码语料若检测结果为 0 个 doc/paper/image直接写空语义文件、跳过 Part B 进入 Part CStep B0 缓存检查用graphify.cache.check_semantic_cache()见 cache.py对照references/extraction-spec.md的绝对路径做提示词指纹缓存只对未缓存文件继续Step B1 分块从graphify-out/.graphify_uncached.txt读取未缓存文件每块 20–25 个文件同目录文件尽量聚到一块以利于抽取跨文件关系每个图片独占一块vision 需要独立上下文Step B2本文主题同一消息内并发调用所有Task子代理各自写graphify-out/.graphify_chunk_NN.jsonStep B3 收集/缓存/合并磁盘文件存在即成功信号逐块读取、按节点 id 去重合并成graphify-out/.graphify_semantic_new.json再写回缓存并并入.graphify_semantic.json最后清理临时文件其中就包括find graphify-out -maxdepth 1 -name .graphify_chunk_*.json -delete。由此可见task-tool-disk片段只是“并行引擎”它的价值要靠在 B3 的磁盘校验与find ... -delete清理配合下才闭环。gen.py 中还专门记录过.graphify_chunk_*.json清理的历史修正fish/zsh 下裸 glob 无匹配会中断rm因此改为find ... -delete这些工程细节共同解释了为何文件名模式.graphify_chunk_*.json在整个协议中被如此严格地统一。与 trae 变体的差异Trae 使用的 task-tool-disk-trae.md 与本文主题片段几乎逐字相同唯一的增量是一行平台注记Trae does NOT support PreToolUse hooks — AGENTS.md rules are the always-on mechanism instead.即 Trae 没有 PreToolUse 钩子代码变更后不会自动重建图谱需手动运行/graphify --update。这印证了 skillgen 的“一份共享核心 少量按平台插槽”设计分发逻辑本身跨宿主复用平台差异被收敛到注释与 hooks 变体中平台渲染差异的元数据见 platforms.toml。实战核查清单综合片段正文与源码实现一次规范的 Task 工具并行分发应满足同消息并发每个 chunk 一次Task调用全部放进同一条回复绝不“调用—等待—再调用”统一模板抽取提示词放进agent-instructions以Output ONLY the structured JSON response.收束占位符透传FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE、CHUNK_PATH五个变量全部替换CHUNK_PATH必须是基于$(pwd)的绝对路径且指向graphify-out/.graphify_chunk_NN.json提示词唯一来源仅当语料含 doc/paper/image 时才装载 extraction-spec且对每个子代理逐字下发同一份磁盘契约子代理用 Write 工具把 JSON 写到各自的 chunk 文件绝不使用相对路径供 Step B3 用“文件是否存在 JSON 是否可解析”来判定成败。这套协议的价值在于把“并行”与“可校验”统一起来宿主平台负责并发调度磁盘文件负责结果契约extraction-spec 负责抽取口径一致最终让成千上万个文档块的语义抽取在可控的失败语义下可靠落地为可查询的知识图谱。【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/8 22:48:32 · 阅读 1.2k graphify 并行语义抽取解析：Task 工具单消息多子代理分发的磁盘协议（Step B2）
graphify 并行语义抽取解析Task 工具单消息多子代理分发的磁盘协议Step B2【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify在 graphify 的三步语义抽取管线Step 3 Part B中文档、论文与图片的抽取不是由主对话逐个阅读文件完成的而是把每个文件分块chunk交给并行运行的子代理再统一回收 JSON 结果。本指南聚焦这套并行协议的核心环节——Step B2 用Task工具在“同一条消息”里分发全部子代理并约定每个子代理把结果写到独立磁盘文件涵盖调用模板、CHUNK_PATH绝对路径规则、抽取提示词的装载时机以及它与上游缓存检查B0/B1和下游合并B3的衔接。读完你将掌握 graphify 为支持Task工具的宿主Agent 平台设计的整套并行分发与磁盘落盘约定能够照着模板正确驱动一次大规模语义抽取。这份协议的来源与适用位置本协议对应仓库中 task-tool-disk.md 这一片段。它不是一份独立运行的文档而是 graphify 技能生成系统skillgen中按平台注入的“分发片段”skillgen 把 core.md 作为各平台共享的精简核心模板模板里在 Step B2 处留有DISPATCH占位槽见 core.md 中 “Step B1 - Split into chunks” 与 “Step B3 - Collect, cache, and merge” 之间gen.py 的_render_core()会用dispatch/平台.dispatch.md的内容替换该占位槽平台清单 platforms.toml 通过dispatch字段把每个宿主映射到具体片段。其中声明dispatch task-tool-disk的是droid、amp、agents三个平台Trae 使用加了平台注记的变体task-tool-disk-trae。渲染产物的落盘快照可以在 expected/graphify__skill-droid.md 等文件里直接看到这份片段被拼入完整技能正文后的形态。同类分发片段横向一览片段宿主/平台依据 platforms.toml分发机制agent-tool-disk.mdclaude、kilo、copilot、claw、kiro、piAgent 工具 磁盘写文件强制subagent_typegeneral-purposecodex-agenttask.mdcodexspawn_agent/wait_agent/close_agent内存汇总无逐块磁盘文件opencode-mention.mdopencodemention分发若无法写文件则回退串行磁盘路径manual-paste.mdvscode无并行子代理 API手动回贴 JSONtask-tool-disk.mddroid、amp、agentsTask工具 磁盘写文件task-tool-disk-trae.mdtrae同上并附“Trae 不支持 PreToolUse hooksAGENTS.md 是常驻机制”的注记核心协议一条消息里并发调用所有TaskStep B2 的第一条铁律是并行必须以“同一条消息内多次工具调用”来实现。片段原文的写法是Uses theTasktool for parallel subagent dispatch. CallTaskonce per chunk — ALL in the same response so they run in parallel.这与另一个常见误区直接对立如果先发起一个Task、等它结束再发起下一个就是串行执行等于放弃并行。因此主代理必须一次性把当前批次全部 chunk 的Task调用放进同一条回复中发出由宿主平台并行调度。随后把抽取提示词作为任务的description传入片段给出的可复制模板如下Task(descriptionYour task is to perform the following. Follow the instructions below exactly.\n\nagent-instructions\n[extraction prompt, with FILE_LIST, CHUNK_NUM, TOTAL_CHUNKS, DEEP_MODE substituted]\n/agent-instructions\n\nExecute this now. Output ONLY the structured JSON response.)模板里有几个值得注意的结构性约定agent-instructions标签包裹抽取提示词含已替换好的FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE被放进显式的指令标签内与结尾的命令性收束句分离结尾收束句Output ONLY the structured JSON response.要求子代理只返回结构化 JSON不带任何解释、markdown 围栏或前言——这与 extraction-spec 里“no explanation, no markdown fences, no preamble”的约束一致占位符逐字替换FILE_LIST是这一块要读的文件清单CHUNK_NUM/TOTAL_CHUNKS标识第几块/共几块DEEP_MODE则把是否传了--mode deep从主调用一路透传到每个子代理。需要说明的是Task是宿主平台提供的工具接口各宿主的参数形态可能不同这里展示的是片段在 task-tool-disk.md 中约定的、面向Task工具的调用骨架实际平台以该工具的可用能力为准。每个子代理写自己的磁盘文件与 Codex 的内存汇总方案不同这套协议采用磁盘文件作为子代理输出与主流程之间的唯一契约Each subagent writes its result to its owngraphify-out/.graphify_chunk_NN.json. Collect results as eachTaskcompletes and parse each as JSON.文件命名是定长两位数字序号NN例如第 3 块写graphify-out/.graphify_chunk_03.json。这样做的价值在下游 Step B3 充分体现见 core.md 的 “Step B3 - Collect, cache, and merge”主代理逐个检查graphify-out/.graphify_chunk_NN.json是否在磁盘上存在“文件存在且可解析”就是该块成功的判定信号若某块文件缺失说明子代理可能是只读类型导致无法写盘B3 会打印警告提示改用 general-purpose 类代理而不是静默跳过超过半数块失败/缺失时停止并提示用户重新运行。也就是说这份片段与 B3 形成“写入方—校验方”的配合B2 定义怎么写、写到哪B3 定义怎么核对、怎么容错。CHUNK_PATH必须使用绝对路径片段对子代理写盘路径的强制要求是绝对路径并在分发前就推导好。原文给出的 shell 片段为PROJECT_ROOT$(pwd) # cwd — where Part C globs graphify-out/ (NOT .graphify_root/scan dir, #1392) # Then for chunk N: CHUNK_PATH${PROJECT_ROOT}/graphify-out/.graphify_chunk_0N.json背后是两点工程考量为何必须绝对路径extraction-spec见 extraction-spec.md对子代理写盘的指示是 “no relative paths — Write resolves relative paths against an undefined cwd and the file will be silently lost”。子代理的当前工作目录不可靠相对路径可能把 JSON 写丢。CHUNK_PATH由主代理在分发前用$(pwd)推导确保graphify-out一定位于真实项目根下为何根必须是当前工作目录注释#1392提醒PROJECT_ROOT$(pwd)指的是后续 Part C 用 glob 收集graphify-out/的目录而不是.graphify_root/scan这类检测阶段用到的扫描目录避免把文件写进错误的根。抽取提示词只在需要时才装载片段的最后一段是关于依赖装载的“时机纪律”Seereferences/extraction-spec.mdfor the exact subagent prompt (JSON schema, node-ID rules, confidence rubric, hyperedge, and vision rules). Load it only here, only when at least one chunk holds a doc, paper, or image; a pure-code corpus has skipped Part B and never reads it.它指向的 extraction-spec.md渲染到各平台技能目录后的形态见 graphify/skills/amp/references/extraction-spec.md 一类产物是完整的子代理提示词内容包括JSON schemanodes/edges/hyperedges三段式及各自的字段形态Node-ID 规则小写、仅[a-z0-9_]格式为{stem}_{entity}stem 用完整仓库相对路径去掉扩展名、逐段拼接禁止追加任何 chunk 序号后缀置信度评分条confidence rubricEXTRACTED1.0、INFERRED从0.95/0.85/0.75/0.65/0.55中取一、AMBIGUOUS0.1–0.3明确禁止用 0.5 作默认值Hyperedge 规则3 个及以上节点共同参与同一概念/流程时使用每块最多 3 条Vision 规则对图片按 UI 截图/图表/推文/示意图/研究图/手写白板分类理解而非只做 OCR。关键约束是仅在“至少有一个 chunk 含 doc/paper/image”时才装载并逐字下发给每个子代理——纯代码语料库已在 B2 之前的 Fast path 跳过整个 Part B根本不会读到这份文件。而一旦需要下发给多个子代理则必须把同一份提示词逐字传递只替换五个占位符FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE、CHUNK_PATH保证每个子代理收到的是同一个“抽取契约”产出才有可比性。协议上下游从 B0 缓存到 B3 合并的完整链路把 Step B2 放回 core.md 定义的 Part B 全流程中其上下游是Fast path纯代码语料若检测结果为 0 个 doc/paper/image直接写空语义文件、跳过 Part B 进入 Part CStep B0 缓存检查用graphify.cache.check_semantic_cache()见 cache.py对照references/extraction-spec.md的绝对路径做提示词指纹缓存只对未缓存文件继续Step B1 分块从graphify-out/.graphify_uncached.txt读取未缓存文件每块 20–25 个文件同目录文件尽量聚到一块以利于抽取跨文件关系每个图片独占一块vision 需要独立上下文Step B2本文主题同一消息内并发调用所有Task子代理各自写graphify-out/.graphify_chunk_NN.jsonStep B3 收集/缓存/合并磁盘文件存在即成功信号逐块读取、按节点 id 去重合并成graphify-out/.graphify_semantic_new.json再写回缓存并并入.graphify_semantic.json最后清理临时文件其中就包括find graphify-out -maxdepth 1 -name .graphify_chunk_*.json -delete。由此可见task-tool-disk片段只是“并行引擎”它的价值要靠在 B3 的磁盘校验与find ... -delete清理配合下才闭环。gen.py 中还专门记录过.graphify_chunk_*.json清理的历史修正fish/zsh 下裸 glob 无匹配会中断rm因此改为find ... -delete这些工程细节共同解释了为何文件名模式.graphify_chunk_*.json在整个协议中被如此严格地统一。与 trae 变体的差异Trae 使用的 task-tool-disk-trae.md 与本文主题片段几乎逐字相同唯一的增量是一行平台注记Trae does NOT support PreToolUse hooks — AGENTS.md rules are the always-on mechanism instead.即 Trae 没有 PreToolUse 钩子代码变更后不会自动重建图谱需手动运行/graphify --update。这印证了 skillgen 的“一份共享核心 少量按平台插槽”设计分发逻辑本身跨宿主复用平台差异被收敛到注释与 hooks 变体中平台渲染差异的元数据见 platforms.toml。实战核查清单综合片段正文与源码实现一次规范的 Task 工具并行分发应满足同消息并发每个 chunk 一次Task调用全部放进同一条回复绝不“调用—等待—再调用”统一模板抽取提示词放进agent-instructions以Output ONLY the structured JSON response.收束占位符透传FILE_LIST、CHUNK_NUM、TOTAL_CHUNKS、DEEP_MODE、CHUNK_PATH五个变量全部替换CHUNK_PATH必须是基于$(pwd)的绝对路径且指向graphify-out/.graphify_chunk_NN.json提示词唯一来源仅当语料含 doc/paper/image 时才装载 extraction-spec且对每个子代理逐字下发同一份磁盘契约子代理用 Write 工具把 JSON 写到各自的 chunk 文件绝不使用相对路径供 Step B3 用“文件是否存在 JSON 是否可解析”来判定成败。这套协议的价值在于把“并行”与“可校验”统一起来宿主平台负责并发调度磁盘文件负责结果契约extraction-spec 负责抽取口径一致最终让成千上万个文档块的语义抽取在可控的失败语义下可靠落地为可查询的知识图谱。【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考