Reporecall：给 coding agent 的本地上下文和记忆层

在一个小项目里，coding agent 看几份文件就能开始工作。但仓库一大、改动一多，问题就会变得很现实：它到底读到的是不是最新代码？它有没有看到跨目录调用关系？上一次会话留下的规则和事实还在不在？如果每次都靠手动贴文件、手动提醒、手动让 agent 搜索，流程很快会变成上下文体力活。

今天想记下的 proofofwork-agency/reporecall，就是围绕这个痛点做的本地工具。它把代码索引、混合搜索、调用图、自动 wiki、本地记忆、MCP 工具和 Claude Code hooks 放在一起，目标不是替代 agent，而是在 agent 开始回答之前，把更可靠、更可追溯的上下文推给它。

按 GitHub repository API、README、release API、tags API、commits API 和 package.json 在 2026-07-13 能核验的公开信息，proofofwork-agency/reporecall 当前有 36 stars、6 forks。仓库主语言是 TypeScript，许可证是 MIT。仓库创建于 2026-03-16 22:39:45 UTC，最近 push 是 2026-07-09 17:01:30 UTC。默认分支 main 当前最新提交是 f6cbaf20，提交时间 2026-07-09 17:01:27 UTC。GitHub Releases 页的 latest release 是 v0.8.0，发布时间为 2026-07-09 12:59:54 UTC；Tags 页当前最新 tag 是 v0.8.1，package.json 里的版本也是 0.8.1。

项目概览

属性	详情
仓库	proofofwork-agency/reporecall
定位	面向 coding agent 的本地上下文、记忆和代码拓扑层
Stars	36
Forks	6
主语言	TypeScript
许可证	MIT
仓库创建时间	2026-03-16 22:39:45 UTC
最近 push	2026-07-09 17:01:30 UTC
最新 main 提交	f6cbaf20，2026-07-09 17:01:27 UTC
Latest GitHub release	v0.8.0
最新 tag / package 版本	v0.8.1 / 0.8.1
核心入口	npm install -g @proofofwork-agency/reporecall、reporecall init、reporecall serve
关键词	local-first、MCP、hooks、hybrid search、call graph、memory、freshness

问题不是搜索，而是上下文是否可信

Reporecall 的 quick start 很直接：

npm install -g @proofofwork-agency/reporecall
reporecall init && reporecall serve

README 里反复强调的不是“让模型更聪明”，而是给 agent 一个可检查的上下文层。它会索引本地代码，生成 wiki 和业务上下文，维护本地 memory，并通过 MCP 或 CLI 暴露搜索、解释和统计能力。对 Claude Code，它还把 hooks 当成核心体验：在 UserPromptSubmit 这类时机，把路由后的压缩上下文自动注入给 agent。

这个点很实用。很多 agent 工具都有搜索能力，但真正难的是 agent 不一定知道什么时候该搜、搜什么、搜到的索引是不是过期。Reporecall 把 freshness 放在显眼位置：README 说每次结果会包含 indexedCommit、dirty file count，并在索引为空或过期时给出明确 banner 和 refresh_context 提示。

这类“诚实的上下文状态”比单纯多塞几段代码更重要。大仓库里，错误上下文往往比没有上下文更危险。一个 stale index 可能让 agent 给出看似有根据、实际已经落后的修改建议。

它把工具面收窄到六个 MCP 工具

Reporecall 另一个值得注意的选择，是在 v0.8 之后把 MCP surface 收到 6 个工具：search_context、search_code、explain_flow、memory、refresh_context、get_stats。

这比“给 agent 一大堆工具”更克制。coding agent 的工具列表越长，选择成本越高，误用概率也越高。Reporecall 的取向是把复杂度放在本地索引、意图路由、混合检索、图扩展和压缩里，对外只给 agent 几个稳定入口。

日常使用里，search_context 适合问“这个能力在哪里实现”，explain_flow 适合追跨文件调用路径，memory 适合记录项目规则和事实，get_stats 则告诉你当前索引是否可信。它不是一个聊天 UI，而是给已有 agent 补一个本地代码理解层。

Lens 是给人看的代码地图

除了 MCP 和 CLI，Reporecall 还有一个很适合人工检查的入口：

reporecall lens --serve --open

README 把 Lens 描述为一个单文件 HTML 架构 dashboard，可以查看代码库 topology、communities、hubs、wiki pages、product areas 和 business context，也可以导出 JSON。这个方向值得注意，因为很多 agent memory 工具只服务模型，不服务人。Reporecall 至少给了一个人类能打开的观察面。

这对团队有用。你可以让 agent 借助索引回答问题，也可以自己看 Lens 输出，判断工具对项目结构的理解是否合理。如果 wiki、product areas 或 graph 明显跑偏，至少能在把它接进更自动化流程之前发现。

本地优先，但不是零成本

Reporecall 的 local-first 取向很清楚：README 写了 zero cloud by default，不需要外部 vector DB，默认离线可用。对公司代码库来说，这比把仓库上传到某个托管服务更容易接受。它还提供 reporecall explain --json、reporecall search、reporecall mcp --project .、reporecall lens --json 这类可脚本化出口，适合接进自己的流程。

但本地优先不代表没有成本。你需要在项目里运行 daemon 或索引命令，需要理解 hooks 和 MCP 配置，需要在大仓库上观察索引速度和内存占用。README 也坦率地说，小型 greenfield 项目或 grep 加 agent 内置能力已经够用的场景，不一定需要它。

我会把 Reporecall 看成一种“上下文基础设施”。如果你只是偶尔让 agent 改一个小文件，它显得重；如果你经常让 agent 在陌生仓库里做跨模块判断，或者团队希望把本地规则、记忆、代码拓扑和 freshness 统一起来，它的价值就开始明显。

适合什么场景

第一类场景，是大仓库或高 churn 仓库。代码关系经常变化，手动贴上下文很容易漏掉关键路径。

第二类场景，是你希望 coding agent 每次回答前都先看到一段经过路由和压缩的本地证据，而不是完全靠它主动调用搜索工具。

第三类场景，是团队需要本地 memory，但又不想把它变成一堆没有 freshness 信号的会话摘要。Reporecall 至少把 memory、索引提交和 dirty 状态放进同一个 trust contract 里。

第四类场景，是你想给 Codex、Claude Code、Cline、Aider 等不同 agent 一个共同的代码检索和解释后端，而不是在每个工具里各自维护一套项目知识。

需要注意的地方

第一，项目还很早期。36 stars、6 forks，创建时间是 2026-03-16，虽然最近 release 和 tag 活跃，但外部使用案例还不多。先在非关键仓库试更稳。

第二，README 很完整，也很有主张，但实际效果仍要看自己的代码库。混合检索、调用图、wiki 和 product areas 这类能力，对不同技术栈的准确度会有差异。

第三，Claude Code hooks 是它最强调的体验之一；如果你主要用 Codex 或其他工具，就更依赖 MCP 和 CLI surface。可用，但体验重点会不一样。

第四，Releases 页 latest 目前停在 v0.8.0，而 tag 和 package version 已到 v0.8.1。采用时最好明确 pin 版本，并核对 npm 包、tag、release note 三者是否对齐。

小结

Reporecall 抓到的是 coding agent 工作流里一个很基础的问题：上下文不只是“更多文本”，还需要来源、 freshness、拓扑和可复用记忆。

如果你已经习惯在大仓库里反复提醒 agent “先看这些文件”“别忘了这个规则”“这个索引可能旧了”，proofofwork-agency/reporecall 值得放进试验清单。它还小，但方向清楚：把 agent 的代码理解层放回本地，并让它对自己知道什么、不知道什么说清楚。