ZiChuanLan/agent-purge

如果你同时用多个 coding agent，并且反复把同一段工作说明贴进不同工具，agent-purge 值得花十分钟试一下；但它更像面向本机已安装工具的提示词路由工具，不保证每个 agent 之后行为一致。

解决什么问题

各家 coding agent 读取系统提示词的位置不一样：有的认启动参数，有的认配置文件，有的靠插件改运行时对象。想让 Codex、Claude Code、opencode 等工具采用同一套工作风格，要么把同一段文字抄进多个配置文件，要么每次会话开头重新粘贴上下文。agent-purge 把 persona 收敛到一个 Markdown 文件，再分发给本机已安装的 harness；切换模式后，下一次启动就按新内容运行，不必逐个手改。实际得到的是“一处维护文本、一个总开关”的工作流。

有什么不同

它不只包装命令，而是把三条通道都指向同一份 persona 正文：install 把托管块写进 harness 配置（常驻，别人启动也生效），shim 在 PATH 前面放同名小壳，裸敲命令也会被转发，slash 则在会话内切换模式、不动磁盘。这个分层是主要机制：你可以先用 slash 试效果，再通过 install 持久化；README 说明 --mode off 或 Web 总开关会撤回到原样。

控制台和 ls 展示的是运行期信息——harness 是否安装、版本、哪些通道可用——静态的 matrix.json 只是能力表，冲突时以运行期为准。边界同样明确：提示词放在服务端或二进制里的闭源桌面端只做原样启动，会打印原因，不做注入（支持说明）。因此覆盖范围取决于具体 harness，而不是项目的总体承诺。

谁值得试

适合已经安装两个以上受支持的本地 coding agent、希望统一语气、安全条款或工作备注，并且想保留回到原始提示词路径的开发者。作者也把它定位成在本机做提示词工程与鲁棒性评测的辅助工具，这个场景同样合理。

如果你主要使用厂商的桌面客户端、提示词在远端，或者你希望工具能对所有 agent 强制统一行为，那么它并不合适。决定因素就是各 harness 的通道可用性，所以在围绕它搭建流程前，先查你要用的那个 harness 的运行期通道报告。

使用条件与边界

需要 Node 20 或更高版本，包本身宣称零依赖（安装说明）。数据默认放在包外的 ~/.agent-purge/，里面有 state.json 和 personas/；可以用 AGENT_PURGE_HOME 环境变量改位置，这对想把 persona 纳入自己的备份或 dotfile 管理的人有实际意义。README 还提到旧版 0.1.x 的数据会在首次运行时迁移，原文件保留，所以升级后如果没清理，会暂时存在两份。

更长期的约束是维护对齐：install 和 shim 各自挂在 harness 的配置或 PATH 上，harness 更新换了配置位置时，需要重新核对通道状态。README 把 uninstall、disarm 和 off 模式列为撤回路径，但这只说明项目自己的清理方式，不等于第三方工具一定会以相同方式读取恢复后的状态。很长的一段法律合规声明主要用来限制滥用，增加的是阅读负担，不是技术能力。另外，README 没有细讲追加模式下各 harness 的系统提示词如何合并，采用前最好在自己的环境里确认拼接后的结果。

HotRepo 点评

目前唯一带日期的信号是 2026-10-26 的 JavaScript 新项目榜快照（不是总榜或每日 Trending 榜），显示 163 总星、第 6 名——这只是单次观察，不是日增。由于只有一天记录、没有可比的每日榜单历史，HotRepo 无法判断热度能否持续；该项目在那次快照时只创建了一天。思路直白，可逆模式也容易理解，但跨 harness 的覆盖面才是风险所在。采用前先看运行期支持报告里你实际使用的 agent 和版本，并确认它可用的通道与你启动该工具的方式匹配。