本文包含

  • 从网页问答到 CLI Agents 的使用历程
  • 我目前使用的 Agents、模型、AI 网关和上下文工具
  • OMP、Codegraph、RTK 和 REA 的安装记录

本文是个人使用记录，不是模型或产品评测。工具排名、费用和可用性都会随时间变化。

先看结论：我现在的工作流

我目前以 Arch Linux 和 CLI 为主，核心工具是 OMP（oh-my-pi）。模型来源通过 AI 网关切换，任务规则使用 Skills 管理，复杂任务交给子代理，代码库查询和终端输出则分别使用 Codegraph 和 RTK。

层次 当前工具或方案 主要作用
Agent OMP 读取项目、调用工具、修改代码、执行命令
模型 免费中转服务和开源模型为主 提供代码分析和生成能力
AI 网关 AxonHub；之前使用过 Bifrost 统一管理供应商和 API 请求
Skills 自己维护的 Skills 固定任务规则、工作流程和约束
子代理 OMP 内置子代理 并行处理相互独立的调查或实现任务
上下文工具 Codegraph、RTK 减少无关代码和终端输出进入上下文
逆向工具 REA 将逆向分析能力接入 Agent

这里需要区分四个容易混淆的概念：Agent 不是模型，AI 网关也不是模型。Agent 负责执行任务，网关负责转发请求，LLM 负责生成结果；Skills 和子代理则分别约束任务方式、拆分任务执行。

一、从网页问答到 CLI Agents

我的使用方式大致经历了以下几个阶段：

阶段 使用工具 当时的工作方式 变化原因
网页问答 Gemini、Google AI Studio、ChatGPT 主要提问和查资料，代码由自己编写 还没有使用 Agent 工作流
第一次接触 Agents Cline 在车载开发中尝试 Agent，但实际使用的多是基础模型 模型能力和完成质量有限，仍以手动实现为主
Copilot Pro GitHub Copilot、GPT-5.4 体验按对话次数计费的 Copilot，并开始让 AI 完成部分代码 价格和当时的使用方式比较合适
KMP / WebAssembly Copilot 等工具 自己设计项目架构，后续部分代码开始使用 Vibe Coding AI 适合处理重复实现，但架构仍由自己控制
Qoder Qoder、Qwen 3.7 Max 在订阅制度变化后切换工具 对国产模型从谨慎转为实际尝试
Codex 和 Claude Codex、Claude、CCSwitch 使用 CLI、API 中转和配置切换工具 Codex 体验不错，但子代理不符合我的工作习惯；Claude 早期也不适合我的使用方式
Copilot CLI Copilot CLI 尝试解决免费模型在 Codex 上的兼容性问题 自定义模型和子代理支持有限，但内置 Agents 体验较好
OMP OMP、AxonHub、omp-ctl 使用 CLI、Skills、子代理和 AI 网关组合工作流 子代理和整体操作方式更符合我的习惯

最开始做 AttrTextView 时，我几乎完全手写实现，并且前后做过多个版本。后来开始使用 Agents，变化并不是“完全不写代码”，而是把一部分重复实现、资料查询和代码检查交给工具。

在 WebAssembly 相关的 Kotlin Multiplatform 开源项目中，我仍然自己设计框架结构；AI 主要参与后续代码实现。这个边界对我比较重要：架构、模块职责和关键技术选择由自己负责，重复性代码可以交给模型处理。

费用变化对工具选择的影响

我曾经使用 API 中转服务，累计花费达到三位数。后来逐渐转向免费的中转服务和开源模型，目前月度 AI 支出约为 0 元。这个结果依赖当前可用的服务，不能理解为所有人的固定成本方案；免费服务的稳定性、速度和模型质量都可能变化。

二、我现在如何选择工具

CLI 优先

我主要使用 CLI，原因很直接：Arch Linux 的工作环境以终端为中心，CLI 工具更容易组合 Shell、Git、MCP、Skills 和脚本。

桌面端工具也使用过，包括 Qoder Desktop、Codex Desktop、Claude Desktop、Zed、Kiro、Cursor 和 Google AI Studio。它们适合快速体验或需要图形界面的场景，但目前不是我的主要工作入口。

个人排序

按照目前的使用体验，我的排序是：

OMP > Copilot > Codex > Claude > Qoder

这个排序只代表个人偏好，主要受以下因素影响：

  • CLI 操作是否顺手
  • 子代理是否容易使用
  • 自定义模型和 API 是否兼容
  • 上下文管理是否可控
  • 价格和服务稳定性

三、四个需要先理解的概念

1. Agents

Agent 是能够读取项目上下文、调用工具并执行任务的 AI 工具。它和普通聊天的区别在于：Agent 不只返回一段文字，还可以在授权范围内读取文件、修改代码、运行命令，再根据命令结果继续处理。

Agent 生成的改动仍需要人工检查。尤其是跨文件修改、依赖升级、构建配置和删除操作，不能只看模型的文字说明。

2. Skills

Skills 是提供给 Agent 的可复用任务说明，通常包含：

  • 什么时候使用这项 Skill
  • 任务应该按什么步骤执行
  • 哪些文件或 API 可以修改
  • 哪些行为必须避免
  • 最后如何验证结果

我一开始并不熟悉 Skills，后来发现它本质上是一份结构化的工作规则。我通常让模型协助生成初稿，再按照 Agent Skills 规范调整。

Skills 解决的是“怎么做”的问题，不负责提供模型能力。模型能力不足时，写得更长的 Skill 也不能替代更合适的模型。

3. AI 网关

AI 网关位于 Agent 和 API 供应商之间：

Agent → AI 网关 → API 供应商 → LLM

它通常负责：

  • 管理多个 API 供应商
  • 使用统一入口转发请求
  • 隔离 Agent 与具体 API Key
  • 在不同模型来源之间切换
  • 处理部分协议和请求格式差异

我先后使用过 Bifrost 和 AxonHub，目前更喜欢 AxonHub。

CCSwitch 和 AI 网关容易被混为一谈，但用途不完全相同：CCSwitch 主要帮助切换客户端配置和 API 来源；AI 网关则真正接收并转发 Agent 发出的请求。两者也可以配合使用。

4. 子代理

子代理是由主 Agent 分配任务的独立 Agent。适合拆分以下类型的工作：

  • 一个代理调查现有实现，另一个代理检查测试
  • 分别分析多个互不依赖的模块
  • 将资料检索、代码审查和实现任务分开

子代理不是越多越好。任务存在依赖时，必须明确先后顺序；并行任务结束后，也需要由主 Agent 检查和整合结果。

四、上下文和 Token 开销

Agent 的输入不只有用户问题，还包括文件内容、命令输出、工具 Schema 和历史对话。无关内容越多，Token 消耗越高，模型越容易遗漏真正重要的信息。

Codegraph：减少无效代码读取

Codegraph 可以为代码库建立符号和调用关系索引。查询代码时，Agent 更容易直接定位相关文件、符号和调用路径，而不是把大量无关文件全部读入上下文。

它适合解决“代码在哪里”“谁调用了这个方法”“修改一个接口会影响哪些文件”等问题。索引不能代替源码核对，最终仍需要确认实际文件内容。

RTK：减少终端输出

RTK 用于减少部分终端命令产生的无关输出。命令输出越短，Agent 处理结果时需要传输和阅读的上下文越少。

它适合优化频繁执行的查询、构建和检查命令，但不能隐藏错误。需要完整日志时，仍应使用原始命令或保留完整输出。

上下文优化的边界

Codegraph 和 RTK 只能减少无关信息，不能替代源码审查、测试、构建和运行结果。压缩输出时尤其要确认错误码、警告和关键日志没有被过滤掉。

五、基础工具安装

下面先安装与日常 Agents 工作流直接相关的工具。REA 的逆向分析依赖放在下一节，避免把普通 Agents 环境和完整逆向环境混在一起。

OMP

macOS 和 Linux：

curl -fsSL https://omp.sh/install | sh

Nix 可以直接运行而不安装：

nix run github:can1357/oh-my-pi

安装到当前用户的 Nix profile：

nix profile add github:can1357/oh-my-pi

Nix 低于 2.30 时，使用旧命令：

nix profile install github:can1357/oh-my-pi

需要自定义 API 供应商时，安装自定义端点插件：

omp install pi-custom-endpoint

Codegraph

macOS 和 Linux：

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh

Windows PowerShell：

irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 | iex

RTK

Homebrew：

brew install rtk

Windows：

winget install rtk-ai.rtk

Linux 和 macOS：

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

安装脚本默认把程序放在 ~/.local/bin。如果该目录不在 PATH 中，可添加：

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
# 使用 Zsh 时改为 ~/.zshrc

也可以通过 Cargo 安装：

cargo install --git https://github.com/rtk-ai/rtk

安装提示

文章中的远程安装脚本来自对应项目的官方仓库。生产环境执行前，应先查看脚本内容，并确认下载地址、权限和安装路径符合自己的环境。

六、将 REA 接入 OMP

REA 是一组面向 Agents 的逆向分析工具。它可以调用本机已有的分析器和命令行工具，但 REA 本体不会替代 Ghidra、JADX、Wireshark 等外部依赖。

REA 的能力取决于已安装的工具：

能力 主要依赖
原生程序分析和伪代码 Ghidra、Hopper 或 IDA
APK 分析 JADX、Apktool、ADB
固件识别和提取 Binwalk、Unblob
网络抓包和解析 mitmproxy、tshark
逻辑信号解码 sigrok-cli、libsigrokdecode
ELF 布局和崩溃分析 pwntools、pyelftools、Unicorn
网页和 Electron 分析 Chromium 或已有 Chrome

1. 安装 REA 并注册到 OMP

REA 需要 Node.js。根据我的安装记录，需要 Node.js 22.19+、24.11+ 或 26+；SQLite 检查需要 Node.js 24.15+。版本要求应以 REA 当前文档为准。

Arch Linux：

sudo pacman -S nodejs npm

也可以使用 nvm 安装和管理 Node.js 版本。全局安装 REA：

npm i -g rea-agents

不想全局安装时，使用 npx：

npx -y rea-agents@latest setup --client omp --dry-run --json
npx -y rea-agents@latest setup --client omp --yes

全局安装后，先预览配置计划，再正式写入 OMP 的 MCP 注册和 Skill：

rea setup --client omp --dry-run --json
rea setup --client omp --yes

2. Arch Linux 软件包

以下版本是我核对 Arch 官方仓库、AUR 和上游发布产物时的记录。软件包版本会变化，安装前应重新检查当前版本。

软件包 当时核对的版本 用途
ghidra、jdk21-openjdk 12.1.2、21 原生程序分析和伪代码
binwalk 3.1.0 固件区域识别和提取
wireshark-cli 4.7.2 使用 tshark 解析 pcapng
sigrok-cli 0.7.2 逻辑信号解码；另需 libsigrokdecode
mitmproxy 12.2.3 网络流量捕获
android-tools、android-udev 37.0.0 ADB 设备访问
jadx 1.5.6 APK 反编译
uv — 管理 Python 工具和隔离环境
chromium — 可选，用于网页/CDP 分析；也可使用已有 Chrome

我的本机记录如下：Node.js 为 24.18.0，REA 已全局安装；adb、jadx、apktool、mitmdump、binwalk 和 unblob 已安装，tshark、sigrok-cli、WABT 和 Ghidra/Hopper 尚未安装。

一次安装官方仓库中的常用依赖：

sudo pacman -S ghidra jdk21-openjdk binwalk wireshark-cli sigrok-cli \
  libsigrokdecode mitmproxy android-tools android-udev jadx uv

浏览器按需安装：

sudo pacman -S chromium

需要抓包和访问 ADB 设备时，将当前用户加入对应用户组；重新登录后生效：

sudo usermod -aG wireshark,adbusers "$USER"

3. 安装版本固定的额外依赖

以下依赖不在官方仓库，或 REA 要求的版本高于我核对时的仓库版本：

# WABT 1.0.42；仓库版本可能较低
sudo mkdir -p /opt/wabt-1.0.42
curl -L https://github.com/WebAssembly/wabt/releases/download/1.0.42/wabt-1.0.42-linux-x64.tar.gz \
  | sudo tar -xz --strip-components=1 -C /opt/wabt-1.0.42

# REA 使用的 JADX headless MCP JAR
mkdir -p ~/.local/share/rea
curl -L -o ~/.local/share/rea/jadx-headless-mcp-0.7.1-all.jar \
  https://github.com/1013503897/jadx-headless-mcp/releases/download/v0.7.1/jadx-headless-mcp-0.7.1-all.jar

# Apktool：AUR 包
paru -S android-apktool

# Unblob
uv tool install unblob
# Unblob 还需要额外提取器依赖；按 Unblob 自带说明安装。

# 固定版本的 pwntools 隔离环境
uv venv ~/.venvs/rea-pwn
uv pip install --python ~/.venvs/rea-pwn/bin/python \
  'pwntools==4.15.0' 'pyelftools==0.33' 'unicorn==2.1.2'

我核对时 Arch 仓库提供的 WABT 是 1.0.41，而 REA 要求 1.0.42，因此单独安装 WABT。pwntools 也使用隔离环境，以固定 REA 要求的 Unicorn 版本。

4. 可选的原生分析器

REA 可以使用 Ghidra、Hopper 或 IDA 作为原生分析器。Hopper 是商业软件；IDA 需要本机已有 IDA Pro。

# 由 REA 安装 Hopper 支持
rea setup --yes --install-hopper

# 安装 IDA MCP 集成
pipx install https://github.com/mrexodia/ida-pro-mcp/archive/refs/heads/main.zip
uv run ida-pro-mcp --install

如果使用 JEB，需要先启动可访问的 JEB MCP 服务。默认地址为 http://127.0.0.1:8425/mcp，也可以通过 REA_JEB_MCP_URL 指定地址。

5. 配置环境变量

将需要的变量设置在 OMP 启动 MCP 服务时能够读取到的环境中。可以写入 Shell 配置文件；如果 OMP 通过其他方式启动，则配置在对应的 MCP Server 环境中。

# 原生分析器：ghidra | hopper | ida
export REA_ANALYSIS_PROVIDER=ghidra
export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.2_PUBLIC
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
export REA_GHIDRA_STARTUP_TIMEOUT_MS=600000

# 按使用的分析器配置；Hopper 默认启动超时为 120 秒
export HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper
export REA_HOPPER_STARTUP_TIMEOUT_MS=600000
export REA_IDA_MCP_CONFIG=/abs/ida-mcp.json

# 可选分析工具的路径
export REA_PWNTOOLS_PYTHON="$HOME/.venvs/rea-pwn/bin/python"
export REA_WABT_BIN_DIRECTORY=/opt/wabt-1.0.42/bin
export REA_BINWALK_COMMAND="$(command -v binwalk)"
export REA_UNBLOB_COMMAND="$(command -v unblob)"
export REA_TSHARK_COMMAND="$(command -v tshark)"
export REA_SIGROK_COMMAND="$(command -v sigrok-cli)"
export REA_MITMDUMP_COMMAND="$(command -v mitmdump)"
export REA_ADB_PATH="$(command -v adb)"
export REA_APKTOOL_COMMAND="$(command -v apktool)"
export REA_JADX_MCP_JAR="$HOME/.local/share/rea/jadx-headless-mcp-0.7.1-all.jar"

# 按 MCP 客户端能力调整响应大小和工具 Schema
export REA_MCP_MAX_RESPONSE_BYTES=33554432
export REA_MCP_INPUT_SCHEMA_PROFILE=compact

REA_MCP_MAX_RESPONSE_BYTES 不应低于 10485760；增大该值时，也要确认客户端的响应缓冲区足够。REA_MCP_INPUT_SCHEMA_PROFILE=compact 可用于工具 Schema 超出客户端限制的情况。

如果某项工具没有安装，不要设置一个不存在的可执行文件路径。按需安装依赖，并配置对应变量即可。

6. 自检

rea doctor --json
rea doctor --provider ghidra --json
rea capabilities --json
rea inspect-apktool-client --json
rea inspect-adb-client --json
  • doctor：检查安装和配置
  • capabilities：列出当前可用能力
  • inspect-apktool-client、inspect-adb-client：检查对应客户端

没有额外依赖时，REA 仍可提供静态 JavaScript/Electron、.NET、ZIP 和常见包清单、Go 二进制、EVM、Flutter、HarmonyOS、SQLite 分析，以及进程捕获。SQLite 检查需要 Node.js 24.15+；进程捕获需要 PTY。固件提取、Android 设备分析、原生伪代码和网页抓包，则需要安装对应工具。

七、相关项目

类型 项目
Agents oh-my-pi、omp-ctl
AI 网关 AxonHub；也使用过 Bifrost
API 配置切换 CCSwitch
代码上下文 Codegraph
终端输出优化 RTK
Skills crowforkotlin.skills
逆向分析 REA

总结

我的 AI 使用方式经历了三个明显变化：

  1. 从网页问答转向能够操作项目的 CLI Agents。
  2. 从单独选择模型转向同时管理 Agent、AI 网关、Skills 和子代理。
  3. 从让 AI 直接生成代码，转向让 AI 读取上下文、执行任务并根据结果继续处理。

目前我主要使用 OMP。对我来说，合适的工作流比单独追求某个模型的排名更重要：自己控制架构和边界，让 Agent 处理可验证的具体任务，再通过构建、测试和人工审查确认结果。