REA Agent 逆向时如何压住 token 成本4 个实操控制点【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea用 REAReverse Engineer Anything让 Agent 做逆向时token 成本很容易失控这个项目用 Agent 逆向任意目标从应用行为到原生二进制而它每次工具调用返回的都是符号表、反汇编、伪代码这类高密度事实。一次不加边界的资源解码就可能让上下文从几千 token 涨到上百万。压住成本的关键不是少用功能而是让 REA 内置的边界机制替你工作能复用的不重算要拉的先限定范围。开新目标前先确认会话是否已就绪最常见的浪费是重复开会话Agent 每换一个新问题就open_binary重新导入、重新索引一遍。朴素做法是一题一会话优化做法是先把当前状态问清楚。正确的第一步是调用binary_session传{}它报告当前绑定的目标、provider、tool_availability和已保留的证据。状态匹配就复用生命周期确实变了才重新打开。官方技能文件明确要求不要重复完全相同的分析或已被拒绝的调用见 SKILL.md 的 Work summary-first。调查结束时调用close_binary它会排空自有工作并释放 provider 资源别让空闲会话占着引擎。重复分析前把快照交给命令行对同一目标反复提问时朴素做法是每次都全量重跑优化做法是让快照命中缓存。CLI 侧给analyze加--snapshot指定缓存文件rea analyze /absolute/path/to/program --provider ghidra --snapshot /absolute/path/to/analysis/program.json当目标字节、操作、参数、provider 和配置全部匹配时REA 直接返回精确结果CLI 的精确命中通常在启动 provider 进程之前就读取完毕第二个问题接近零引擎成本。MCP 侧等价open_binary传snapshot_path原子导入close_binary传snapshot_path加overwrite: true在释放资源前保存。细节见 docs/cli.md 的 Save and reuse analysis snapshots 一节。⚠️ 注意缓存边界变更类操作和游标依赖的调用不参与缓存一次元数据写入会直接使当前会话的快照缓存失效新查询或实时查询仍可能启动 provider。拉数据前先限定再调用全量拉取是上下文膨胀的另一个主源。以inspect_keyed_archive为例不显式给root、offset、limit你面对的就是整个$objects列表显式给范围后返回的只是要的那一段硬上限为 64 MiB 输入、20 万对象。量级上更有说服力的例子是 Interface Builder 解码文档中实测一个完整应用图约 6.7 MB、折合 200 万 token超出默认 MCP 响应预算所以 MCP 调用方应传detail: summary再用inspect_analysis_view按offset: 0, limit: 64这类参数分页取行docs/native-investigation.md。两个补充动作结果超传输预算时resource_constraint且details.resource为transport不要重跑同一次调用改用inspect_analysis_view对同一会话的证据按段、按页读取。需要标识符时走 MCP 的completion/complete取前缀建议而不是先列全量清单再人工挑docs/mcp-prompts.md。追踪数值时预算从小起步跨函数追踪是 token 最容易爆炸的操作。trace_native_values用 budget 控制深度、反编译次数、调用点解析数、节点与边数节点负载上限 8 MiB、序列化结果上限 32 MiB——即使目标再复杂输出也有硬边界且省略的部分会被显式计数而不是静默截断。它的分页只返回源节点在当前页上的边端点使用稳定 ID翻页不会丢上下文。 遇到N 项已省略时朴素做法是直接调大预算优化做法是先判断省略项是否与当前问题相关只有返回证据留下具体缺口时才扩大预算。收尾核对结论进台账否定搜索收边界调查收尾前过一遍 SKILL.md 的 Plan broader investigations给每个结论建 finding ledger结论台账关联 Evidence ID、置信度、搜索边界与未解疑问后续步骤引用台账而不是重新翻聊天记录。确认某功能不存在的否定搜索边界一到就停。对照检查这几点开新目标前是否先问过binary_session可复用的查询是否指向了同一个--snapshot文件每次拉数据是否给了offset/limit或detail: summary追踪类操作是否从保守预算起步。先做哪一步先把binary_session当第一调用再给每个数据请求补上范围参数预算扩大永远由具体缺口驱动而不是由怕漏驱动。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考