Weavatrix

Weavatrix — 原生 MCP 仓库智能

属于 Weavatrix 生态系统：为 AI 软件 Agent 提供证据基础设施。

在编码 Agent 开始猜测之前，为它提供仓库证据。

Weavatrix 是原生 MCP 产品，能回答 Agent 往往会自行编造答案的问题：修改此文件会造成什么影响、哪些组件使用这个 n8n 字段、MCP 架构是否仍接受昨天的请求、哪些 viem 调用点遵循 ABI 布局变更，以及 .weavatrix/architecture.json 是否仍然有效。它提供 67 项只读操作，使用一个绑定到特定修订版的图谱，不需要 LSP 或提示词包。

Codex、Claude Code、Cursor 和 Grok 可使用影响分析、架构、API、Git 历史、重复项、死代码、搜索、语义链接、时间记忆、导出的 n8n 工作流（n8n_*）、Dify YAML 应用（dify_*）、Agent 插件／技能／MCP 目录（agent_*）、Mermaid 流程图（diagram_*），以及 Web3 ABI／使用者影响分析（web3_*）。这些解析器属于 Weavatrix Core 的领域，并非新的 MCP 产品。专属页面： n8n · Dify · 解析器。

它不会靠扩大 grep 范围或编造置信度评分来回答问题。每个有界结果都可以附带生成结果所依据的仓库修订版、文件、行号、提取器、证据类型和置信度。

相邻的 MCP 工具（不属于此主机）

此仓库是 stdio MCP 主机和插件包。它固定使用 weavatrix-rust。它不会另建索引器，也不会与引擎 crate 争夺 README 的定位。

你可能已经在用	适用场景	在以下情况下改用此主机
Serena	在 Agent 内进行 LSP 精确的重命名、引用查找和编辑	你需要只读的影响分析、架构和来源信息，而且不希望 Agent 启动语言服务器
Repomix MCP	将压缩后的仓库塞进下一个提示词	你需要有界答案（change_impact、verify_architecture），又不想每轮都付出打包 token 的成本
Aider RepoMap	为单次聊天筛选符号	你需要完整的修订版绑定图谱，包括 n8n／Dify／Agent／Web3／Mermaid 领域
Claude Context / vector MCP	语义检索“类似这样的代码”	你需要由提取器支持的边，而不是最近邻代码块
GitNexus / CodeGraph 守护进程	在 IDE 旁运行长期驻留的图服务	你想要已发布的原生二进制文件，而不需要额外的数据库进程

主机的独特职责是传输：配置方案、监视、npm／crate 分发，以及通过一个引擎会话提供 67 项工具目录。实测引擎运行时间见 weavatrix-rust 基准测试， 不在此处列出。

生态定位（UNDERSTAND）

Weavatrix (this) — code facts
        │
        ▼
Weavatrix Loom — semantic composition (capabilities, registry, compile → Rust)
        │
        ▼
Realforge — artifact construction (scaffold / package / deploy)

产品	负责	不负责
Weavatrix（本项目）	代码仓库 / 代码图谱、符号、依赖、搜索、影响分析	能力互通 Registry、WVX 项目图谱
Weavatrix Loom	能力 · 实现 · 证据 · GraphPatch · 语义编译器	深度代码仓库索引（由本项目负责）
FerroSift	确定性转换配方 / 操作	能力 Registry；代码智能
Cortex Loom	Agent 工作流 / 上下文预算	代码索引；Loom 准入策略

Loom 使用 Weavatrix 的事实来进行语义分类（例如，“这个 fn 是 data.json.parse@1 的候选项”）。Loom 不得再开发第二个产品代码索引器。 Loom 侧的规范：ADR-0012。

相同的源代码以两种形式分发：

分发方式	安装	适用场景
crates.io 上的 weavatrix	cargo install weavatrix	以 Rust 为主的环境和从源码构建
npm 上的 weavatrix	npx -y [email protected] mcp <repo>	无需 Rust 工具链即可使用现成的跨平台二进制文件

npm 包是为了方便；它不包含不同的 JavaScript 引擎。两种分发方式都运行相同的原生适配器和相同的 weavatrix-rust 分析引擎。单独发布、版本号独立的 weavatrix-js 包是旧版 JavaScript 实现，用于兼容性和历史基线；它不会打包进 weavatrix。

作为插件安装

此代码仓库为 Cursor、Codex、Claude Code 和 Grok Build 提供一个插件包。每个客户端都会启动已发布的原生 npm 分发包，并加载相同的只读 MCP 工具。可选的 Weavatrix 技能仅在适合使用索引后的跨文件证据的任务中启用；需要时会单独加载详细的工具路由信息。

Cursor 插件

市场审核完成后，可在 Cursor 的 Plugins 视图中搜索 Weavatrix。正式上架前，可将 plugins/weavatrix 复制或链接到 ~/.cursor/plugins/local/weavatrix 并重新加载 Cursor 窗口，以测试此插件包。

Codex 插件

codex plugin marketplace add Weavatrix/weavatrix --sparse .agents/plugins plugins/weavatrix
codex plugin add weavatrix@weavatrix

Claude Code 插件

claude plugin marketplace add Weavatrix/weavatrix --sparse .claude-plugin plugins
claude plugin install weavatrix@weavatrix

Grok Build 插件

grok plugin marketplace add Weavatrix/weavatrix

打开 /marketplace 并安装 Weavatrix。Grok 也支持直接通过 grok plugin install Weavatrix/weavatrix#plugins/weavatrix 安装插件。

30 秒内安装

运行便捷的预构建 npm 分发包：

npx -y weavatrix mcp .

或者通过 Cargo 安装相同的 MCP 产品：

cargo install weavatrix
weavatrix mcp .

Codex

# ~/.codex/config.toml
[mcp_servers.weavatrix]
command = "npx"
args = ["-y", "weavatrix", "mcp", "."]

Claude Code

claude mcp add weavatrix -- npx -y weavatrix mcp .

Grok

grok mcp add weavatrix -- npx -y weavatrix mcp .

-- 后面的所有内容都是服务命令，因此 -y 会传给 npx，而不是 Grok。手动编写的等效配置：

# ~/.grok/config.toml
[mcp_servers.weavatrix]
command = "npx"
args = ["-y", "weavatrix", "mcp", "."]
startup_timeout_sec = 120

该包解压后约为 40 MB，因此首次通过 npx 启动时，下载所需时间可能超过 Grok 默认的 30 秒启动超时。startup_timeout_sec 可在首次启动时解决此问题；使用 npm i -g weavatrix 或 cargo install weavatrix 安装后，之后的每个会话都无需冷启动。

使用 --scope project 将配置写入代码仓库内的 .grok/config.toml，这样克隆代码仓库时也会包含该服务配置。

Cursor

建议使用 Cursor 插件（它已传入 ${workspaceFolder}）。如果要手动编写用户级配置，请将服务绑定到当前打开的工作区，而不是宿主进程的 cwd，并避免同时运行用户级 MCP 和插件：

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "weavatrix": {
      "command": "npx",
      "args": ["-y", "[email protected]", "mcp", "${workspaceFolder}"]
    }
  }
}

不同配置文件提供同一引擎的受限视图：

npx -y [email protected] mcp . --profile=all
npx -y [email protected] mcp . --profile=code
npx -y [email protected] mcp . --profile=seo
npx -y [email protected] mcp . --profile=n8n
npx -y [email protected] mcp . --profile=dify
npx -y [email protected] mcp . --profile=agent
npx -y [email protected] mcp . --profile=diagram
npx -y [email protected] mcp . --profile=web3

npm 包包含适用于 Windows x64/arm64、macOS x64/arm64 和 glibc Linux x64/arm64 的原生二进制文件。它没有安装脚本，也不会在运行时下载内容。

在读取结构化输出的客户端上，将每个回答的大小减半

MCP 结果会携带两份有效载荷：一份位于 structuredContent 中，另一份 镜像到文本块中，供只读取 content 的客户端使用。镜像是经过美化格式化的副本，因此两者中它更大。

npx -y weavatrix mcp . --output-format=structured

在真实代码仓库上对 run_audit 进行测量后，响应大小从 8931 字节降至 3589 字节，缩小了 59.8%。客户端是否读取结构化输出不会因调用而变，因此只会在启动时选择一次，而不是在每次调用时都作为参数重复指定；在不便使用标志的情况下，WEAVATRIX_OUTPUT_FORMAT=structured 也能达到相同效果，而调用中指定自己的 output_format 时仍以调用参数为准。

json 是默认值，并保留镜像，因为否则忽略 structuredContent 的客户端会看到空结果。text 仅返回文本块，但该文本块仍包含序列化后的 JSON；它不是摘要模式。对于架构问题，请在不带参数的情况下调用 architecture_inventory，并用文字概述其有界的风格假设。

新领域究竟能回答什么

问题	工具	明确的限制
这个 MCP schema 还能接受昨天的请求吗？	agent_change_impact	string → integer 不兼容。部分目录中缺失的工具状态是 unconfirmed，而非已移除。
事件布局变更后，谁会调用这个 ABI？	web3_impact	注释或字符串中的“调用”不代表消费者。ABI 相同不代表部署仍在运行。
导出的 n8n 工作流中，谁会读取这个字段？	n8n_trace	密钥不会出现在图中。
哪些 Dify 节点会使用 start_node.query？	dify_trace	对话变量是有向边，而不是字符串是否存在。
这条 Mermaid 箭头能证明代码调用吗？	diagram_*	箭头表示的是 declared_architecture，而非 Calls。
.weavatrix/architecture.json 仍然有效吗？	verify_architecture	未知规则会按失败处理。

Agent 可以询问什么

What breaks if I change src/auth/middleware.ts?
Trace POST /api/orders through this backend and its clients.
Which production symbols are dead, and what evidence proves it?
Show duplicate implementations but suppress router boilerplate.
Which dependency violates .weavatrix/architecture.json?
Find every GraphQL, gRPC, Kafka, RabbitMQ, NATS, JMS, SQS, or SNS
contract affected by this branch.
Build the smallest source bundle needed to edit this symbol safely.
Show me this file as it was two commits ago, without a checkout.
Suggest internal links without mixing inferred SEO relationships into
the deterministic code graph.
If I change the email recipient in this exported n8n workflow, who reads it?
If I change start_node.query in this Dify YAML, which nodes consume it?
Did this MCP catalog make `id` an integer so old string requests fail?
Which viem `decodeEventLog` sites still assume the old Deposit layout?
Is this Mermaid arrow a real call, or only declared architecture?

每个修订版本只构建一次图。因此，影响分析、API 跟踪、健康检查发现、架构检查、克隆族和上下文包都会基于相同的代码仓库身份，而不是重新计算彼此不兼容的局部视图。

看看它如何作答

以下是 Weavatrix 在提交 ec8bf30 上分析自身代码仓库时给出的真实回答，经过删节（…），并缩短了本地根路径。可通过 weavatrix tool <name> . '<arguments>' 重现其中任意回答。

一次调用即可了解概况，并准确获知回答所依据的代码仓库和修订版本：

{"name": "graph_stats", "arguments": {}}

{
  "nodes": 1294,
  "edges": 2771,
  "freshness": {"state": "CURRENT", "source_revision": "sha256:dd3d96d3…"},
  "relations": {"calls": 651, "contains": 1271, "imports": 419, "references": 314, "…": "…"},
  "repository_context": {
    "root": "…/weavatrix",
    "git_head": "ec8bf3041588623f23ec5e7ebbaff3a333da9ca7",
    "scan_revision": "sha256:dd3d96d3…",
    "graph_age_seconds": 0
  }
}

每个回答都包含该 repository_context 块。从 1.11.1 开始，每个 MCP 进程都会在整个会话期间固定其启动根路径：除非启动时使用了 --allow-retarget，否则会拒绝将 open_repo 指向其他路径；如果省略了 expected_repository，则会使用该固定值填充。即使你已经知道文件夹名称，也请传入 "expected_repository": "weavatrix"——不匹配的服务会明确报错，而不是针对错误的代码仓库作答。

编辑前先了解影响范围：

{"name": "get_dependents", "arguments": {"label": "file:src/mcp/server/mod.rs", "max_nodes": 6}}

{
  "dependents": [
    {"distance": 1, "node": {"id": "file:src/main.rs", "language": "rust"}},
    {"distance": 1, "node": {"id": "file:src/mcp/mod.rs"}},
    {"distance": 1, "node": {"id": "file:src/mcp/server/tests/catalog.rs"}},
    {"…": "…"}
  ]
}

文件原样内容——无需检出（git_read_blob）：

{"name": "git_read_blob", "arguments": {"path": "Cargo.toml", "revision": "HEAD~3", "max_bytes": 400}}

{
  "path": "Cargo.toml",
  "revision": "70b5bc788a10ec89ab28b9ecbc005e3b9c7f9829",
  "oid": "f5f54bac00a4feb6e965c0d87c5c6d4d25782e91",
  "kind": "utf8-text",
  "lines": ["[package]", "name = \"weavatrix\"", "version = \"1.9.2\"", "…"],
  "size_bytes": 1224,
  "returned_bytes": 400,
  "truncated": true
}

在 ec8bf30 之前的三个提交中，这个软件包的版本是 1.9.2；Agent 无需触碰工作树，就能读取 diff 中的后续版本。二进制 blob 会按失败处理，不会被解码成乱码。

67 项只读操作

工作流	操作
图谱概览	graph_stats、get_node、get_neighbors、query_graph、god_nodes、shortest_path、get_community、list_communities、module_map、build_graph
变更影响	get_dependents、change_impact、select_tests、verified_change、prepare_change、graph_diff
精确源码上下文	search_code、read_source、inspect_symbol、go_to_definition、find_references、context_bundle、map_stacktrace
健康度与质量	find_duplicates、find_dead_code、run_audit、coverage_map、hot_path_review、perf_attribution

| API 与传输方式 | list_endpoints、trace_endpoint、trace_api_contract | | 架构 | architecture_inventory、get_architecture_contract、verify_architecture、verify_capabilities、explain_architecture_violation、propose_architecture_exception | | 本地 CI | ci_restrictions、explain_restriction | | Git 与仓库 | git_history、git_read_blob、cross_repo_git、open_repo、list_known_repos、rebuild_graph | | 原生扩展 | vector_search、semantic_link、seo_link_suggestions、memory_context | | n8n 工作流 | n8n_inventory、n8n_trace、n8n_context | | Dify 应用 | dify_inventory、dify_trace、dify_context | | Agent 包 | agent_inventory、agent_trace、agent_context、agent_change_impact | | Mermaid 图表 | diagram_inventory、diagram_trace、diagram_context | | Web3 集成 | web3_inventory、web3_trace、web3_impact、web3_context |

coverage_map 是数据导入工具，而非测试运行器。请将其与 Weavatrix Quality 的 quality_run 配合使用；后者会将 .weavatrix/coverage/lcov.info 写入 引擎搜索路径。缺少报告表示未测量，而非 0%。

就被分析的仓库而言，每项操作都是只读的。 分页和显式限制可控制大型邻域、历史记录、搜索结果 和契约清单的规模。

build_graph 和 architecture_inventory 现共用一个类型化构建模型。 architecture_inventory 默认使用 detail:"summary"：在有界响应中提供完整图谱 总量、代表性组件路径、主要耦合关系，以及明确标注的候选环。它还会分别报告 模块化源码组织、洋葱式依赖、端口与适配器、分层依赖和部署拓扑的风格假设。每个 假设都会说明其证据、矛盾、未知项和状态；声明的契约风格绝不会被视为证明。请求 detail:"full" 可获取分页边和源码证据；output_format:"text" 不会减少详细程度。 在 Rust 中，显式的 impl Trait for Type 可支持洋葱式或 端口与适配器架构的判断；固有的 impl Type 则不能。 这些操作会保留嵌套的 Cargo、npm/TypeScript、Go 和 Python 组件、 多对多的声明成员关系、无冲突的标识、配置谓词和不可变的源码证据。组件总量及 SCC/环路见证会在分页前基于完整投影计算，因此响应上限不会改变图谱判定。商图中的组件环 会作为架构环报告，而不会被错误标记为符号递归。

ci_restrictions 在读取本地 GitHub Actions 工作流和字面检查项时，会复用该面向目标的拓扑。根目录文件、重复命令、UTF-8 BOM 偏移、可选事件、基础分支和变更路径场景都会保留其精确证据。动态条件、互斥的配置并集、 实际运行情况和远程必需检查仍会明确标记为未知；单凭工作流文件绝不能证明某个门禁已通过。

语言和仓库表面

引擎可识别 65 种已注册扩展名中的 24 种命名表面。 支持情况取决于证据：无损词法分析不代表能够进行类型化语义解析。

分组	表面
代码	Rust；JavaScript/JSX；TypeScript/TSX；Python；Go；Java；C#；C；C++；SQL；Bash/Zsh；Swift；Solidity
合约和配置	GraphQL；Protobuf/gRPC；JSON/JSONC（n8n 在解析后）；YAML/Kubernetes（Dify 在解析后）；Terraform/HCL；XML
文档和 UI	HTML/Vue/Svelte；CSS/SCSS/Sass/Less；Markdown/MDX；reStructuredText；AsciiDoc

跨表面处理流程会关联 HTTP 路由和调用、GraphQL 操作和架构类型、gRPC 服务和流模式，以及 Kafka、RabbitMQ/AMQP、JMS、NATS、SQS 和 SNS 的生产者与消费者。包清单、锁文件、覆盖率文件和架构契约也会成为证据。

无法证明的动态分派会保持未解析状态。静态可达性不会被称为实测覆盖率，缺失的可选证据会明确标记为缺失。

工作流导出领域

n8n 和 Dify 不是新的 MCP 服务、编辑器或运行时。它们是同一证据图上的领域。JSON 仍由 JSON 适配器处理；YAML 仍由 Kubernetes 适配器处理。解析后，可识别的导出会转换为类型化节点、端口和关系。package.json 不会变成 n8n 工作流。Kubernetes ConfigMap 不会变成 Dify 应用。

flowchart LR
  export["n8n JSON / Dify YAML in git"] --> parse["Existing JSON / YAML parse"]
  parse --> domain["After-parse domain"]
  domain --> graph["Revision-bound evidence graph"]
  graph --> inventory["inventory"]
  graph --> trace["trace"]
  graph --> context["context"]

产品页面：n8n · Dify · 解析器。

n8n（随 1.12.0 发布）

已导出的工作流 JSON → n8n_inventory、n8n_trace、n8n_context。

当问题涉及已纳入 git 的导出文件时，请使用此功能：谁读取了这个字段，哪个节点为该输出提供输入，这个文件实际包含什么。Agent 会停留在仓库版本中，不会登录 n8n。

• 身份范围限定在单个文件内。两个工作流中相同的显示名称仍对应两个节点；同时匹配两个节点的简短标签会标记为 ambiguous。
• flows_to 表示控制流。depends_on_output 表示数据。两者不会作为同一种关系遍历。
• 每个 $('Name') / $node / $items 都会绑定，而不只是第一个匹配项。.item 和 .first() 会保持区分。动态表达式 $('' + prefix) 会标记为 unresolved:dynamic_node。
• typeVersion 1.7 不会被强制转换为整数。
• 缺失的子工作流会标记为“未提供”，而不是“已删除”。
• 密钥、Cookie、身份验证标头、URL 凭据、pinData、staticData 和 $env 值不会出现在默认图和上下文中。

npx -y [email protected] mcp . --profile=n8n

Dify（随 1.13.0 发布）

已导出的 DSL YAML → dify_inventory、dify_trace、dify_context。

当问题涉及本地 YAML 导出时，请使用此功能：哪些节点使用了 start_node.query，哪些 Code 或 Template 区域提到了某个选择器，以及导出文件省略了什么。Agent 会停留在仓库版本中，不会调用 Dify 控制台。

• AppKey 由语料库和制品来源确定。data.title 仅用于显示。
• 节点主题类型取自 node.data.type，而不是画布的 custom UI 类型。
• 迭代/循环子节点会保留 parentId 作用域，不会被扁平化。
• {{#start_node.query#}} 标记和结构化选择器会转换为带有源代码范围的 reads_variable / depends_on_output。
• 对话分配器的读写会保留类型化表示。Code 和 Template 区域会被纳入清单，但不会执行。
• 可识别 Chat 和其他模式。不支持的模式会标记为 structure_only，而不是成功生成空图。
• 环境值和类似凭据的标签会从默认清单和上下文中省略。

npx -y [email protected] mcp . --profile=dify

Agent packages（随 1.14.0 发布）

本地插件、技能、目录和观测文件 → agent_inventory、 agent_trace、agent_context、agent_change_impact。

如果问题涉及 Git 中已有的软件包，请使用此功能：插件公开了哪些目录工具，哪个 MCP 配置绑定了某个服务，以及两个目录快照在受支持的架构子集内是否保持兼容。不支持的关键词仍标记为 undetermined。重复的工具标签标记为 ambiguous-identity。Agent 不会启动命令，allowed-tools 只是声明，并非已证实的调用。

npx -y [email protected] mcp . --profile=agent

Mermaid 图表（随 1.14.0 发布）

.mmd、.mermaid 和 Markdown/MDX 围栏代码块 → diagram_inventory、 diagram_trace、diagram_context。

绘制的箭头属于 declared_architecture，绝不是 Calls。它们不会消除死代码发现。绑定仅来自 .weavatrix/diagram-links.json。名称匹配不代表精确匹配。change_impact.documentation 与生产影响相互独立。

npx -y [email protected] mcp . --profile=diagram

Web3 集成（随 1.15.0 发布）

ABI JSON、提供的 solc/Foundry 构建产物，以及静态 viem/wagmi 使用方 → web3_inventory、web3_trace、web3_impact、web3_context。

当合约接口发生变化，且你需要已证实的客户端调用或解码位置时，请使用此功能。使用方仅关联到配对的构建产物文件。缺失候选项标记为 missing_input，而不是已移除成员。调用对象内部的注释属性并非被调用方。索引掩码事件的变更可能导致静默误解码。ABI 相同并不能证明部署仍在线。引擎不会编译合约、调用 RPC 或打开钱包。

npx -y [email protected] mcp . --profile=web3

与相邻工具的比较

这些工具解决的是不同问题。Weavatrix 不能替代实时控制台或 CI 检查工具。

需求	使用
分析 Git 中已有的 n8n 或 Dify 导出文件的变更影响	在同一绑定到特定修订版本的图上使用 Weavatrix n8n_* / dify_*
操作实时 n8n 实例（运行、凭据、编辑器 API）	n8n-mcp
操作实时 Dify 控制台（运行、发布、150+ 个 API 工具）	dify-mcp
在 CI 中检查或比较 Dify YAML	difyctl

Weavatrix 回答的是“在这个仓库的此修订版本中，哪些代码会使用这个变量？” 它不会执行表达式、Jinja 或 Code 节点，也不会部署或发布应用。

共享引擎基准测试

n8n 和 Dify 的证据会在解析后于进程内生成。这些工具不会通过 HTTP 访问 n8n 或 Dify 主机。我们不会杜撰各解析器的毫秒级数据。

在安装后的 MCP 边界测得的数据（2026-08-03，打包版本 1.2.0 / weavatrix-rust 2.1.1 对比 weavatrix-js 0.3.15，使用相同的 JavaScript 服务仓库）是这两个领域共享的真实引擎数据：

安装后的边界	Rust 1.2.0	JavaScript 0.3.15	比率
冷启动边界中位数（从启动到首个工具结果）	157.34 ms	5,068.22 ms	32.21x
热启动 tools/call 中位数	7.94 ms	292.55 ms	36.85x

方法说明：发布证据 和 docs/benchmarks.md。

这不是什么

不执行表达式或 Jinja。不部署 n8n 或 Dify。不自动编辑。不引入新的图引擎。我们不会假称完全支持未知 DSL 版本和隐藏的导出字段。

产品边界

Weavatrix 特意拆分为与协议无关的引擎和精简的产品适配器：

coding agent
    |
    | MCP over stdio
    v
weavatrix 1.17.5
    profile catalog · session refresh · filesystem watcher · MCP framing
    |
    v
weavatrix-rust 2.17.4
    typed graph · analysis pipeline · 67 product operations including local CI, n8n, Dify, agent packages, Mermaid, and Web3
    |
    +-- weavatrix-scan      repository discovery and selection
    +-- weavatrix-parse     lossless tokenization and structural facts
    +-- weavatrix-graph     graph model and algorithms
    +-- weavatrix-git       direct Git-object evidence
    +-- weavatrix-search    bounded content and index search
    +-- vector / clone / semantic / memory components

本仓库负责 MCP 传输、监视器、原生 npm 打包，以及面向客户端的标识 weavatrix。weavatrix-rust crate 负责可复用引擎和独立诊断 CLI；它不是 MCP 服务。weavatrix-stream 是一个独立的 crate，为 Weavatrix 观测结果提供适配器；此宿主不会在运行时依赖它。 因此，它的独立二进制文件通过 --version 报告 weavatrix-rust <engine-version>；而本产品会同时报告 weavatrix 产品版本及其嵌入的引擎版本。

希望嵌入引擎的 Rust 应用应依赖此 crate：

[dependencies]
weavatrix-rust = "2"

use weavatrix_rust::{Weavatrix, operations};

let mut engine = Weavatrix::open(".")?;
let result = operations::call(
    &mut engine,
    "change_impact",
    blazingly_json::json!({"files": ["src/auth.rs"]}),
)?;
# Ok::<(), weavatrix_rust::Error>(())

发布证据

发布门槛衡量的是已安装的 npm 边界，而非进程内微基准测试。双方都会打包、安装到隔离的 npm 根目录，并在 HOME、XDG、AppData 和图缓存均为空的环境中启动。测试框架会验证包／原生组件／初始化标识、公布的操作、成功的 MCP 结果以及进程清理。

由 weavatrix-rust 2.1.1 提供支持的 1.2.0 打包产品，于 2026-08-03 在同一个真实 JavaScript 服务仓库（2,165 个节点／5,712 条边）上，与已安装的 weavatrix-js 0.3.15 进行了测量；每种工具运行 3 次成对的全新进程，启动顺序交替：

已安装边界	Rust 1.2.0	JavaScript 0.3.15	比率
冷启动边界中位数（从启动到首次工具结果）	157.34 ms	5,068.22 ms	32.21x
成对冷启动加速比，6 组配对的中位数	-	-	32.06x
热启动工具调用中位数	7.94 ms	292.55 ms	36.85x

两项发布阈值（冷启动 24x、热启动 30x）均已通过；成对冷启动中位数略高于 1.0.0 基线记录的 30.34x，因此新增的三个工具、令牌预算和依赖注入证据并未导致已安装边界性能退化。原始证据和方法见 benchmark-results 和 docs/benchmarks.md。

安全性与确定性

• 只读 MCP 接口；
• 不执行任何写入源代码的操作；
• 不执行仓库代码；
• 原生引擎不会启动 git、rg、语言服务器、Node 或 Python；
• 仓库分析不涉及网络；
• 没有 npm 安装脚本或安装后下载二进制文件的操作；
• 对文件、字节数、结果、历史记录和分页均设有上限；
• 排序稳定，且保留修订来源信息；
• 第一方引擎 crate 禁止使用 Rust unsafe；
• 产品、引擎和受维护的第一方组件均采用 MIT 许可证。

文件系统监视仅会使派生状态失效。下一次操作会执行有界刷新；它绝不会修改仓库。监视所需内存为常量：每个事件到达时都会进行分类，并合并为一个待处理的变更标记，因此，即使 target/ 或 node_modules/ 下的构建输出不断变化，服务器在工具调用间空闲时也不会累积事件。

架构与开发

产品适配器采用端口与适配器模式：

inbound MCP server
        |
application session
        |
repository + change-monitor ports
        |
weavatrix-rust adapter · notify adapter

mcport 仅用于入站服务器。应用层既看不到 MCP 帧，也看不到 notify 事件；引擎也不依赖这两者。

本地门槛：

cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test --all-targets

原生 npm 构件由 scripts/build-npm-packages.mjs 构建；所有平台二进制文件、标识检查、包检查和已安装边界门槛全部通过后，才会由受保护的 GitHub Actions 工作流执行发布。

文档

• 快速入门
• 工具参考
• 证据模型
• 语言支持
• MCP 产品架构
• npm 分发
• 依赖项
• 基准测试
• n8n 导出证据
• Dify 导出证据
• 工作流解析器
• 引擎 API 和架构

许可证

MIT。请参阅 LICENSE。