Euthynos

智能体在读取文件时，可以看到该文件依赖什么。但它看不到什么依赖这个文件。入边从内部是不可见的，因此智能体通过读取更多文件来弥补，这会消耗上下文，却仍然可能遗漏调用方。Euthynos 转而从 AST、导入图和 git 历史中回答这些问题——零 LLM 调用，查询路径中无网络请求。

它提供证据。它不保证某个变更是安全的。

安装

全局安装。 -g 参数很重要：它负责将 euthynos 命令添加到你的 PATH 环境变量中，这是你的 MCP 客户端启动服务器的方式。

npm install -g euthynos

在连接任何东西之前，确认它已安装成功：

euthynos --help

然后将其注册到你的智能体中：

claude mcp add euthynos -- euthynos mcp

或者在任何 MCP 客户端配置中：

{ "mcpServers": { "euthynos": { "command": "euthynos", "args": ["mcp"] } } }

需要 Node.js 18+。适用于 Windows、macOS 和 Linux。

几乎总是因为本地安装而非全局安装。不带 -g 的 npm install euthynos 会将二进制文件放入 ./node_modules/.bin/，该目录不在你的 PATH 中，因此你的 MCP 客户端无法运行。请通过以下命令确认：

npm ls -g euthynos --depth=0

如果输出 (empty)，请使用 -g 重新安装。要清理意外创建的本地副本，请删除运行命令所在目录中生成的 node_modules 文件夹和 package.json。

如果它确实是全局安装但仍然找不到，说明你的 npm 全局 bin 目录不在 PATH 中——npm config get prefix 会显示其位置。或者直接将客户端指向二进制文件：

{ "mcpServers": { "euthynos": { "command": "C:\\full\\path\\to\\euthynos.cmd", "args": ["mcp"] } } }

Related MCP server: codemap

23 个工具，按它们回答的问题分组

每个答案都声明其自身的范围。否定答案会说明未检查的内容，而不是暗示不存在任何内容。

可测量，而非断言

M2 是一个预注册的基准测试：任务、有效性规则和答案键在任何会话运行之前就已通过提交冻结，召回率仅根据最终答案进行盲审评分，无效会话与有效会话一同发布。相同的模型、相同的仓库、相同的提示——一组挂载了 Euthynos，一组没有。

在达到完整测量的三个任务上：

两组召回率完全相同且完美——每组 42 个必需项全部命中——而 Euthynos 组使用的 token 数减少了 13–31%。 智能体在读取更少内容的情况下得出了相同的答案。一个旨在诱导出看似合理但错误的调用方的预注册陷阱，在两组中均未触发。

这并不说明什么。 46 个尝试的会话中有 21 个有效；外部速率限制墙导致了其中 14 个无效。引导编辑和定位任务从未被测量，也不暗示任何相关数字。一个测试工具，一个仓库。这是节省的工作量，而非答案质量的提升——我们宁愿发布这句话，也不愿发布一个更大的数字。

未发布任何延迟数据。 两个内部有效的测量结果不一致，而本可以解决此问题的受控实验未能完成，因此我们两者都不发布，而是提供测试工具——docs/PROVENANCE.md 中有相关推理。

本地优先

• 查询路径中不上传任何内容。 MCP 服务器不进行任何网络调用和 LLM 调用。它读取你的工作树，包括未提交的编辑。

• 只读。 它从不修改你的源代码。

• 路径沙盒化。 服务器在启动时固定其可服务的根路径；超出这些路径的路径将被拒绝。不跟随符号链接。

• 磁盘上一个目录： 仓库根目录下的 .euthynos/，包含内容寻址索引和本地仅元数据的遥测日志。它创建时带有自己的 .gitignore，删除它只会导致重新扫描。 使用 EUTHYNOS_NO_INDEX=1 和 EUTHYNOS_NO_TELEMETRY=1 可选择退出。

• 一个例外，可选且仅限 CLI： euthynos scan --ai 会将候选的重复代码片段发送到 Anthropic API 以确认发现。它需要 ANTHROPIC_API_KEY，默认关闭，并且不是 MCP 服务器的一部分。

规模——我们将和不会声称的内容

Euthynos 已验证至大约 10,000 个文件。低于约 1,500 个文件时，它运行舒适。超过 10,000 个文件时，它未经验证，不应假定其能正常工作。

~10,000 个文件是已验证范围的上限，而非保证。

内存是上限端的约束因素，而非延迟。 解析后的语料库保存在内存中：一个 10,000 个文件的仓库在编辑循环期间，进程 RSS 大约从 0.6 GB 增长到 ~1.1 GB。线性外推——一个估计值，而非测量值——默认的 Node 堆可能在 25,000–35,000 个文件左右耗尽。因此，代码中 60,000 个文件的发现上限并非一个可达的限制。

V1 版本未发布精确的延迟数据。 我们持有两个内部一致的测量结果，它们在较大规模上存在分歧，而本可以解决该信任问题的受控实验未能完成。与其发布一个我们无法支持的数字，我们选择不发布任何数字，并提供测试工具，以便你测量自己的机器：

node scripts/measurement/gen-scale-repos.mjs
node --expose-gc scripts/measurement/measure-latency.mjs --reps=20

推理过程在 docs/PROVENANCE.md 中；范围及影响性能的因素在 docs/SUPPORTED-SCALE.md 中。

在安装之前，其他值得了解的局限性：

• 调度是同步的。 一次一个工具调用，冷启动的首次扫描会在其整个持续时间内阻塞队列——持续数秒，并随仓库大小增长。没有每次调用的超时；你的 MCP 客户端必须提供一个能够容忍首次调用的超时。

• 索引读取并非免费，也非规模不变。 find_symbol、read_function 和 find_references 需要实际时间，并随仓库大小增长。此文件的早期版本声称它们在所有规模下都保持在 1 毫秒以下；该数字是一个参数拒绝错误路径，而非一次读取。请参阅 docs/BENCHMARK-INTEGRITY-AUDIT.md。

• 编辑循环的成本是热调用的数倍，因为必须重新解析已更改的文件。任何未说明测量的是两者中哪一个的数字，其信息量都很有限。

• 冷构建时间取决于机器和存储环境。 构建索引是 I/O 密集型的。

• 迄今为止的所有测量都是在 TypeScript 上进行的。其他语言会有所不同。

语言

通过三种策略解析 16 种语言。 TypeScript、JavaScript 和 Vue SFC 通过 TypeScript 编译器 API；Python、Go、Java、Ruby、Rust、PHP、C、C++、C#、Dart、Kotlin 和 Swift 通过 tree-sitter WASM；COBOL 通过确定性行解析器。

每个语法规则都作为纯 WASM 运行——无原生绑定、无平台匹配的预构建、无编译器工具链。调用图解析质量在 TypeScript 上最强。

Euthynos 不会声称什么

它是一个静态分析器。它能看到导入、声明和调用边。它看不到反射、动态分发、运行时代码生成、字符串构建的符号名、动态导入或框架连接——并且它从不假装能看到。

以下短语在其输出中被禁止，并且该禁令由测试强制执行：

是安全的 · 安全地…… · 没有其他消费者 · 所有引用 · 未使用 · 已完全测试 · 无影响 · 任何关于数学证明安全性的声明

callers_of 返回空值意味着静态图没有找到调用者，而绝不意味着没有任何东西调用它。存在歧义的跨模块名称会产生零边，而不是给出猜测结果，因此答案是一个下界，未解析调用的数量会一并打印出来。

自行验证这些说法

这里没有任何内容需要你盲目相信一个数字：

这最后一项并非披露过程中的偶然。我们的两个基准测试框架曾把参数校验错误当作测量结果来计时，其中一个已发布的声明错了三个数量级。审计文档记录了哪些环节出了问题、哪些结果已失效、哪些被重新测量，以及哪些仍然缺乏依据。

未发布的内容： M2 标准答案和完整的会话账本。任何关于这些内容的说法都无法通过本仓库得到验证，我们宁可明说这一点，也不愿暗示相反的情况。

Euthynos for Teams

◈ Euthynos for Teams

同一套引擎，横亘在拉取请求与 main 之间。

![LLM calls](https://img.shields.io/badge/LLM%20calls-zero-0BABB4?style=for-the-badge

目前尚未全面发布。 现在还没有任何可登录的公共实例。本节描述的是存在且可以运行的软件——以便你现在就能判断它是否值得关注——而不是此刻就能买到的产品。加入 euthynos.dev 的早期访问名单 →

通过 GitHub App 连接一个仓库。每次推送和每个拉取请求都会由本仓库中的引擎在服务端进行扫描，结果会出现在真正做出决策的地方。

◈ 合并策略，以规则书写

五种规则类型，每种为 warn 或 block：

边界在服务端强制执行。表单只是便利设施，并不是校验器。

◈ 每次扫描的依赖图

每次扫描都会产出一个交互式图产物——包含模块、导入边，以及无法干净切断的环。

在四个维度上评分，外加重复度：

depth · seams · locality · leverage

每项都以区间（band）形式报告——Strong、Stable、Drifting、At Risk——因为区间才是真正有意义的部分。

◈ 每个 PR 上的检查运行（check run）

判定会记录在产生它的规则名下，因此“我为什么被阻止”会得到一个不是凭空感觉的答案。

警报状态会在多次扫描之间延续：new · ongoing · resolved · archived-until-worse · regressed。

◈ 审计员可读的证据

导出一个日期范围，即可得到当时有效的规则集、该时间窗口内的每条合并判定、每条覆盖记录及其操作者和书面理由，以及每个模块的归属覆盖率。

阅读时无需任何账户。

◈ 来自 git 历史的知识风险。 每个模块的归属百分比和公交因子（bus factor）——因此*“最薄弱的模块恰好也只有一个人理解”*这件事，是由仪表盘告诉你的，而不是等那个人离开后你才发现。

这里同样是零 LLM 调用。 相同的 diff 每次都会产生相同的判定。不做任何采样，因此没有可产生幻觉的内容，也没有可被提示注入的内容。推送同一个分支两次，会得到两次相同的审查。

本仓库中的 CLI 保持免费、本地运行，并采用 Apache-2.0 许可——这是一项承诺，而非试用。它不会联系平台，平台也永远不会接触你的机器。

想等它开放时获取吗？

→ 加入 euthynos.dev 的早期访问名单

本地 CLI 永远免费 · 无需信用卡 · 使用本仓库中的任何内容都无需账户

CLI

MCP 服务器是主要的界面，但 CLI 也可以独立使用：

euthynos scan [path]        architecture scan — six metrics, module table
euthynos graph [path]       build the call graph; --impact/--callers/--path
euthynos dashboard [path]   self-contained interactive HTML, zero runtime deps
euthynos index [path]       inspect or rebuild the local index
euthynos mcp                start the MCP stdio server

euthynos --help 会打印完整的标志集和构建标记。

文档

docs/ARCHITECTURE.md · docs/SUPPORTED-SCALE.md · docs/SECURITY.md · docs/CONTRIBUTING.md · docs/TRADEMARK.md · docs/PROVENANCE.md · CHANGELOG.md

安全

请通过 GitHub Security Advisories 私下报告漏洞，而不是公开提交 issue。范围与预期：docs/SECURITY.md。

许可证

Apache License 2.0 — 参见 LICENSE 和 NOTICE。

Copyright © 2026 Tonil Kumar.

许可证覆盖代码，但不覆盖名称：“Euthynos”被声明为 Tonil Kumar 的未注册商标——没有申请过，也没有获得过任何注册。参见 docs/TRADEMARK.md。