原生函数摘要验证 — 2026-10-23¶

行为与来源¶

MCP analyze_function 默认使用紧凑的派生摘要。完整的 函数 Evidence 会保留在会话中，并可通过返回的 parent_evidence_id 在 inspect_analysis_view 中选取。detail: "complete" 保留历史完整回复。交付细节保持在提供方输入和父 Evidence 标识之外。 此 MCP 默认行为属于破坏性变更。

CLI rea function 仍默认输出完整结果。选择摘要 需要独占的 --evidence_output 捆绑目标。认证后的 捆绑可通过绝对 evidence-file 来源和显式记录 ID 在提供方关闭后分页查阅。普通记录也遵循显式 ID。

该实现复用了现有的 JSON 认证/余量所有者，以及 一个捆绑认证函数，用于导入和文件视图。每个请求仅读取 一个文件一次。模糊捆绑引导保留完整 ID，并将 JSON 编码的引用预览限制为 2 KiB，省略超大的操作标签。 原生摘要继承函数位置和关系覆盖范围；省略 或不可用的事实保持未知状态，而不会变为零。

已测来源：

• 之前：fb6c88d518ab9b84ed396cf82dcb1c28a608c501。
• 之后：4e3d930ada93014efa43610265b58307de49a687。
• 测试框架 SHA-256：d67b23db21024361b34f796add1ff91bf3fbcda1991ea9e369ef8bcf64c71ec4。
• Linux x86-64；固定 Node 24.22.1 / npm 11.16.0；自带 Ghidra 12.1.4 和 JDK 21.0.12.1+1。无目标执行。
• 目标 SHA-256： 9c49d2eef9c2083f6f66f38de4ed0ee1bac17ca5b73dc8f3a90d9ba62a8d1d5d。 其 3,000 分支 C 源码是超时验证器测试夹具，SHA-256 f99074876faae8e18e45265dab007b6fcc396fe909d57efab72adc8925a960c7。 已知条目 0x1010f9 和 0x128ed6 仅适用于此确切工件。

已完成的公共 MCP 对比¶

一个全新的生产环境 stdio MCP 客户端发现全部 221 个工具，打开目标， 然后获取两个答案：小函数的标识、可用性/计数和 完整伪代码；以及大函数的标识、可用性、汇编/ 块计数和前 20 行汇编。它在同一会话中 重复两次读取，执行一次匹配的完整小函数兼容性读取后关闭。

之前，每个默认函数回复都携带完整档案。之后，每个 答案使用默认摘要和一页保留的 Evidence。两条通道均使用 一秒原生反编译限制、明确的 600 秒 SDK 工具截止时间 和匹配的 128 MiB 服务器/客户端接收预算。所选事实在 不同实现和轮次之间一致。大函数有 45,007 行汇编 和 9,001 个块，伪代码不可用；小函数伪代码为 64 字节，SHA-256 c947ff22cab1ffef9b962b12d82e12d0e5f5e2a6c5634a2ed5ea3c353e1d5807。 每次运行在其任务期间保持了相同的已观测 JVM 启动标识，并 在目标摘要不变的情况下完成清理。

此已完成任务的估算上下文下降 97.66%，包括更大的目录和 四次额外分页调用。仅目录本身就从 982,457 增长到 985,662 个估算 Token。完整小函数兼容性读取仍包含在两个总计中。

重复小函数任务增加了一次分页调用，在此 配对中耗时约多 6.7 毫秒。大型部分档案保持活跃并重试原生分析；健康的 小函数快照复用仍然可用。此变更减少了代理 输出及其序列化/传输工作，同时仍生成并保留 完整的父档案。

Token 是 tokenx 1.3.0 对实际目录、参数和完整 SDK 结果的估算，包括文本和结构化投影。协议帧、 握手、提示、客户端渲染/重放和实际模型使用 均未计量。整体基准包括 Token 估算、哈希、资源 采样和交换文件写入。汇总的已计量 MCP 阶段排除 后续计数/写入开销：217.327 → 127.538 秒。 整体基准时间不得作为纯提供方分析时间来呈现。

Node 堆为 2 GiB，Ghidra 堆为 1 GiB，亲和 CPU 0/1，Java 活动 处理器数为二。所观测进程族的提前停止保护允许 6 GiB RSS、 600 秒 CPU 和 900 秒耗时；两次完成的运行均未触发保护。 RSS 每 50 毫秒通过递归 /proc 观测采样一次。共享 页面可能被重复计数，短暂/未被观测到的子进程转换可能被 遗漏；这不是内核 cgroup 峰值或硬性进程族内存限制。等待 CPU 包含已回收的后代进程。基线先运行，操作系统缓存未刷新， 主机与其他工作共享。这是一次配对调查， 具有上述冷/结果缓存区分，而非普遍性的速度声明。

早期基线尝试使用 240 秒 SDK 截止时间，并首先 处理大函数。它超时后成功关闭；整个尝试耗时 280.628 秒，等待 CPU 219.562 秒，未触发资源保护停止。 其失败的接收/交换保持独立。它被排除在已完成任务 比较之外。最终配对在两种实现上使用相同的更长截止时间和任务顺序。

公共 CLI 与保留文件¶

真实的默认 CLI 命令返回了一个完整的小函数档案，并带有预期的伪代码（耗时 70.627 秒，CPU 70.034 秒）。第一个验证框架假设只有裸 Evidence，未能解包成功的公共 ok/data/meta 封装。修正该框架后，其已完成的记录和输出得到了验证并被复用，而无需再次进行提供者分析。

summary CLI 命令分析了大函数，并写入了一个 29,141,012 字节的捆绑包。它在 78.163 秒内返回了一个 8,499 字节的摘要封装，CPU 时间为 94.196 秒，采样到的进程族 RSS 为 2,381.2 MiB。两个全新的 CLI 进程在 Ghidra 安装路径不可用的情况下验证了该捆绑包，并返回了其前 20 行和末尾 20 行汇编行。覆盖报告显示总计 45,007 行，延续与耗尽均正确。目标摘要保持不变。

那些独立的文件分页命令分别耗时 17.218 / 18.175 秒，CPU 时间为 15.150 / 17.015 秒，RSS 约为 666 / 669 MiB。每个全新的命令都会读取并验证完整的捆绑包；这并非亚线性磁盘访问，也不是跨进程缓存。完整证据仍保留在调用方的文件中。

验证与限制¶

• 在与 main 分支 a062529bb2aa064be37e82df39c59c4fa798fe50（源码 b7c3f0cd79c4a02b135da56fff06de08dd456ff7）集成后，完整的 npm run check 通过。docs:check 也通过。
• 最新的聚焦 contract/progress/snapshot/local-path 运行通过了 139 项测试；所测集成的选定运行通过了 136 项，更早的一次更广泛的 CLI-selector/contract 运行通过了 169 项。重叠部分不计入总和。更早的 domain/Evidence 运行有 87 次通过和一次遗留的 progress-fixture 失败。explicit-complete fixture 和新 summary 的递增通知随后在一个单独的 8 用例 MCP 运行中通过。
• 实际的 SDK/schema 检查在重新生成被忽略的测试目录元数据后，全部 15 个用例均通过。初始运行有 14 次通过和一次陈旧目录相等性失败；其记录已保留。
• 上述生产环境下的 CLI/MCP 观测使用真实的 Linux 版 Ghidra。Hopper、IDA、Kuna、macOS 和 Windows 的行为仅在选定的源码/边界测试范围内得到覆盖，并未进行新的真实提供者验证。
• 早期的源码集成修复和后来的 main 分支更改并未包含在每一个历史测试/性能基准点中。所测的那一对运行仍与上述明确的源码提交绑定。

原始交换、协议观测、控制失败、脚本和资源记录均保留在 /tmp/rea-maintenance-20261023/5660/ 之下。提供者项目、生成的二进制文件、构建输出和本地规划文件不会被提交。