技能：一份 525 行的调查协议
工具告诉模型"能调什么"，技能告诉它"什么时候调、按什么顺序、什么算完成"。REA 的 525 行 SKILL.md 不是说明书，是一份带恢复路径的调查协议。
技能：一份 525 行的调查协议
REA 安装到客户端的东西有两样：一个 MCP server，一份技能文件。
MCP server 提供能力，技能文件提供方法。前者是”你能调什么”，后者是”你什么时候该调、按什么顺序调、什么算做完、做砸了怎么办”。
很多人把 skill 当成更长的工具说明。REA 的写法不是这样：它的 SKILL.md 只有 525 行，真正的细节放在 7 份参考文档里，合计 2,480 行；主文件负责路由和纪律，参考文档负责领域细节。
第一段就在说”什么时候不要用”
技能的开头不是功能介绍，而是适用边界：
Use REA when a claim depends on a shipped binary or package, decompilation, requested runtime evidence, or comparison with behavior not established by available source. For ordinary analysis of a complete source repository, use normal repository tools and do not run REA readiness or provider commands.
这句话挡掉了一大类误用：用户只是想让 Agent 读一个开源仓库，结果 Agent 先跑一遍 doctor、再装引擎、再开二进制分析。技能明确说：有完整源码的普通架构分析，不要用 REA。
接下来还有一条更细的：
Do not run diagnostics or setup before every investigation.
工具连得上就直接干活；连不上再按恢复路径处理。把”诊断”当成每次调查的仪式，是 Agent 常见的浪费。
路由表：先认目标，再选工具
SKILL.md 的第二节叫 “Route the target first”，列了一张目标到首个工具的映射：
| 目标 | 第一个工具 |
|---|---|
| ASAR / 解包后的 JS/Electron 目录 | analyze_javascript_application |
| ZIP/APK/IPA/MSIX/AppX/DMG/PyInstaller | open_binary → inspect_artifact |
| Apple plist / IB / 资源目录 | open_bundle_resources |
| Android APK 代码 | inspect_android_package |
| .NET 程序集 | inspect_managed_artifact |
| 固件镜像 | inspect_firmware_regions / extract_firmware |
| 原生程序行为 | 运行时工作流（Frida / GDB / 进程捕获） |
| 已打开的浏览器页面 | list_browser_targets |
| HAR/SAZ 流量 | inspect_web_network_capture |
这张表解决的是”工具太多，模型从哪开始”的问题。172 个工具里，大多数只在特定目标上有意义；先认目标，就把候选缩到了一个族。
证据纪律写在主文件里
技能里最重要的一段，不是工具用法，而是这句话：
Every conclusion must distinguish observations, inferences, and unknowns. Cite Evidence IDs, preserve limitations and incomplete coverage, and never imply that static analysis observed execution.
它要求模型在回答里做三件事：
- 把”看到的”、”算出来的”、”猜的”分开。
- 引用 Evidence ID，而不是只说”源码显示”。
- 保留 limitations 和 coverage，不把静态分析说成运行时观测。
这不是文风要求，是输出契约。REA 的 Evidence 已经把这些字段准备好了；技能负责让模型真的去用它们。
调查是一个循环，不是一次调用
“Plan broader investigations” 这一节给了七步：
- 把请求拆成问题清单，写清每个答案需要什么证据。
- 检查当前会话、目标身份、已有数据库、书签和旧证据，能复用就复用。
- 从最小的概览或清单开始，沿入口追到状态变化和结果。
- 同时看打包资源和配置，不要只读代码。
- 用证据类型匹配结论：静态答不了的问题才上运行时。
- 能并行的独立问题分给 worker，要求返回来源、结论和未解缺口。
- 维护一份 finding ledger：结论、Evidence ID、置信度、搜索边界、剩余未知。
最后一条最重要：调查结束前要回到最初的问题清单，逐条标记 answered / partially answered / unresolved。不能因为”大部分都答了”就说调查完成。
恢复路径是按故障分的
技能里有一份 connection-and-recovery.md，它不把所有失败都归为”重装”：
- 工具不在目录里：检查注册和客户端。
- 调用被客户端拦：检查审批策略。
- provider 不可用：检查引擎安装和宿主。
- 启动超时：区分”还在跑”和”已经死了”。
- 连接断开：只在安全可重试时重试一次。
- 插件安装：走插件自己的恢复路径，不要跑 setup。
这种分法避免了一个常见循环：Agent 遇到任何问题都跑一遍 setup，装完还是不通，再跑一遍。
技能本身也能被检索
技能文件不是一次性塞进上下文的。REA 提供两个工具：
search_guidance：按问题在安装好的技能包里找章节。read_guidance_section：按 locator 读回完整章节。
限制是 1 MiB / 文件、4 MiB / bundle、4,096 个 section；locator 带内容哈希，技能包换了版本会报 stale，而不是返回旧内容。
这样主文件可以保持短，细节按需加载。模型不需要在开局就背下 2,480 行。
安装：版本化，可回滚
rea setup 会把技能文件复制到客户端目录（共享路径是 ~/.agents/skills），同时写 MCP 注册。它有几个约束：
- 注册里记录绝对 runtime 和入口脚本，不依赖
npx的临时缓存。 - 覆盖已有文件前先备份，备份路径写进计划。
- 只改 REA 自己的注册和技能文件，不动别的配置。
doctor只读；uninstall只删 REA 拥有的东西。
插件安装（Claude Code / Codex）是另一条路：插件把技能和 MCP 注册打包在一起，升级走插件机制，不走 setup。
技能不是强制
最后要说清楚：技能是 instructions，不是 enforcement。模型可以不读、可以读错、可以读了不照做。
REA 没有把安全性寄托在技能上。真正强制的东西在 server 里：schema 校验、路径检查、进程监管、证据哈希、响应预算。技能负责的是”在没人强制的地方，让模型有一个正确的默认动作”。
用一句话收束这个专栏：
工具让模型有力气，技能让它有纪律，证据让它可被审计。
三者缺一，逆向 Agent 都只是一个会说话的 strings。