AI 编程 Agent 最耗 token 的地方，是每接一个新任务都要重新认识一遍代码库：grep、开文件、再开三个、再 grep。repowise 的思路是把这些提前算好——在本地给代码、git 历史、测试和架构决策建一次索引，Agent 问索引而不是自己去翻。官方实测一次任务只开 3 个文件而不是 7.2 个，输出少 31.6%。这个「上下文层」的设计值得拆。
一个索引的三种用途
它的定位是「给你和你的 Agent 的代码库智能」。一个索引，三种用途：看懂代码（调用图、架构图、自动生成的 wiki）、安全地改（改动风险、测试影响）、持续改进（健康评分、死代码、重构计划）。关键点是图、健康评分、死代码这些计算零 LLM 调用、不需要 API key 就能索引，只有「生成文档/回答」这一步才可选地调模型。
上手就是几行命令：
uv tool install repowise # 或 pipx / pip install repowise
cd /path/to/your/repo
repowise init --yes --no-prose # 建图、git、健康、死代码、文档，无需 key
repowise serve # 本地 dashboard + MCP server
健康评分的来源
每个文件一个 1–10 的健康分，来自 53 个确定性的检测器，分成缺陷风险、可维护性、性能三档来看。性能类能跨文件追 N+1 查询、循环里的 I/O、异步里的阻塞调用。这个分数不是拍脑袋——官方用真实 bug 历史验证过：在 21 个开源项目上，按健康分排的修复优先级，找到的「后来出 bug 的文件」是 CodeScene 的 2.3 倍。而且每次索引完它会在你自己的仓库上自检：「20 个最低分文件里有 16 个过去半年修过 bug，是 24% 基线的 3.3 倍」，让分不准这件事对你可见。
十件 MCP 工具
repowise 给 Agent 暴露十个 MCP 工具，刻意压在这个量级——工具面小了，Agent 才选得准。核心几件：
| 工具 | 只回答什么 |
|---|---|
| get_overview | 架构摘要、模块图、入口点，接手陌生仓库的第一调 |
| get_answer | 混合检索加图扩展，一次往返带引用答案 |
| get_context | 文件/模块的分诊卡：摘要、签名、热点标记 |
| get_risk | 热点、依赖方、共变伙伴、测试缺口 |
| get_change_risk | 一个 commit 在三个维度上改糟了什么 |
每次响应都带一个 _meta 信封：索引的 commit、索引年龄、落后于当前 checkout 时的过期警告，Agent 永远知道自己读到的东西有多可信。修什么、跑哪些测试，也都有对应的命令入口：
repowise next # 按影响和成本排序，先修哪个
repowise health --refactoring-targets # 具体的重构计划
repowise dead-code # 按置信度分层的死代码
repowise impacted-tests main..HEAD # 只跑这个 diff 涉及的测试
可复用的点
最值得抄的，是「把代码理解做成一层可复用的索引，而不是让 Agent 每次现场重新发现」。这个抽象换到任何 Agent 系统都成立：昂贵又重复的「理解」提前算一次，Agent 只做「问」。第二点是「回答带置信度」——调用图的每条边都标了怎么解析、可信度多少（从 same_file 的 0.95 到仓库级名字匹配的 0.50），把猜测标成猜测，而不是给一个看似确定的答案。这一层「知道自己不知道」的能力，恰恰是大多数检索增强方案缺的。
命令输出的蒸馏也值得一提：repowise distill pytest 只留失败行、去掉噪音，还能 expand 还原，一条都不丢。实测 npm ci 的输出能缩 99.5%。对「Agent 要先读一段命令输出再决定下一步」的流程，这一层省下的上下文是实打实的。
局限
要留意的几点：一是建全索引不便宜——官方数据里，构建 django 的完整索引要 366.8 秒，是同类里最慢的，因为它连 git 历史层、wiki、决策、健康都建了；如果你只要调用图，CodeGraph 那种只建图的 22 倍更快，是更对的选择。二是协议是 AGPL-3.0，公司内部用没问题，但想嵌进自己产品、规避 AGPL 义务，得买商业授权。三是可选的语言生成能力（写文档、抽决策）会把你代码派生的提示词发到你自己的模型 provider，介意的话用 --no-prose 的确定性模式，代码派生内容就不出本机。