pstack-claude：把 Cursor 技能棧移植到多個編碼代理的工作流

技术背景与问题定义

编码代理的能力在过去一年里提升很快，但同一个模型在不同任务上的表现差异依然很大。多数时候，问题不出在模型本身，而出在流程：代理没有先复现故障就开始改代码，没有核对证据就宣布修复，或者把一个小改动扩散成一次大范围重构。pstack 要解决的正是这类「流程缺失」。

据 README 介绍，Lauren Tan 的 pstack 是一套带有明确立场的 Cursor 技能栈，目标是改善代理的产出。pstack-claude 则是它的移植版，面向 Claude Code、Codex、Pi 以及其他代理运行环境。项目描述里还列出了 OpenCode、Gemini 与 Prime Agent。这个移植工作的难点不在于复制文字，而在于把 Cursor 提供的原语（子代理、提问、唤醒等能力）翻译成其他环境里的对应物。仓库简介用的说法是「Cursor primitives translated for other harnesses」。

这个问题有现实意义。团队往往同时使用多个代理工具，每个工具各有一套技能格式和调用方式。如果好的工作流只能绑定在一个编辑器上，经验就无法复用。移植版的价值在于，同一套方法可以在不同环境里保持一致的行为。需要说明的是，本文基于对仓库 README 的阅读，没有在本地安装运行，下面关于效果的判断都属于对设计的分析，而不是实测结论。

核心架构与原理解析

从 README 可以拼出这个项目的结构，它大致分成四层。 第一层是入口技能 poteto-mode。用户只需要说出目标，例如「修复换页时搜索过滤器被重置的问题」，它就会选择合适的工作流。README 说它让代码保持简洁、简单，并且经过验证。仓库中的 SKILL.md 还列出了多种剧本（playbooks），覆盖规划、功能开发、重构、性能问题、调查、原型、PR 维护、发布和较长的项目。 第二层是一组可组合的专项技能。README 的示例里出现了 `how`、`why` 和 `architect`。以修复缺陷为例，流程是：先复现故障，再用 `how` 与 `why` 做调查，然后把修复委派出去，最后重新运行原来失败的用例。如果修复跨越了函数边界，poteto-mode 会在实现之前引入 `architect`。用户拿到的是修复本身，加上失败和通过两份证据。这种「证据先行」的交付方式，是整个设计里最有价值的部分。

第三层是各运行环境的适配。在 Claude Code 上，安装通过插件市场完成，使用 `/plugin marketplace add michael-denyer/pstack-claude` 和 `/plugin install pstack@pstack-claude`。Codex 使用 `codex plugin marketplace add` 与 `codex plugin add`。Pi 使用 `pi install git:github.com/michael-denyer/pstack-claude`。Pi 上还会加载一个 pstack 扩展，补上子代理、提问和唤醒三类工具，以及 `/loop` 命令和路由指令。这说明移植并非只搬运技能文本，而是为缺少某些原语的环境补出了实现。 第四层是策略与配置。项目跟踪上游，同时携带若干具名的策略分支，每个分支都在 `tools/forks.json` 中声明。`setup-pstack` 技能可以修改模型默认值，也可以为每个角色设置推理强度。README 给出的例子是 `arena runners: opus @xhigh, fable @max`。在 Claude Code 上，这类设置通过插件的 `pstack:effort-` 或 `pstack:poteto-agent-` 代理分发。没有指定强度的角色沿用会话本身的强度，除非配置表中的 `default effort` 一行另有指定。自动路由可以关闭。

关键功能与实战评估

最值得关注的功能有三项。 其一是自动路由。插件在 Claude Code 和 Codex 上安装路由钩子，让代理在收到任务时先走 poteto-mode。Codex 要求用户通过 `/hooks` 明确信任这个钩子之后才会运行。这是一个合理的安全设计，因为钩子会改变代理的行为，不应该被静默启用。在 Pi 上，由扩展注入同样的路由指令。 其二是按角色配置模型与推理强度。把昂贵的高强度推理只分配给需要它的角色，其余角色使用较低强度，可以在质量与成本之间做细粒度的取舍。 其三是数据处理边界。README 明确写道，pstack 没有服务器，也没有遥测。技能要求代理读取的任何内容，包括会话记录，都会发送给用户所选的模型提供方。脚本在本地运行，PR 相关工具使用用户的 GitHub CLI 登录状态。这条说明很坦率：它没有承诺「数据不出本机」，而是讲清楚了数据会去哪里。

在使用建议上，它最适合有明确验收标准的任务，例如能写成失败用例的缺陷。对于需求模糊的探索性工作，剧本里的规划和调查类流程更合适。局限也要说清楚：流程越严格，单次任务消耗的调用和时间越多；技能的效果依赖底层模型遵循指令的能力；各环境的原语翻译是否完全等价，需要用户自己在目标环境里验证。截至本文撰写时，仓库约有 1194 个星标。我们没有找到可复现的对比评测，所以不对「结果改善了多少」下结论。

行业影响与未来演进

pstack-claude 反映出一个正在成形的趋势：技能与工作流正在成为独立于具体代理产品的可移植资产。过去，提示词和流程多半锁在某个编辑器的配置里。现在，插件市场、技能目录和钩子机制在多个代理工具里都有了相近的形态，这让「一次编写，多处安装」变得可行。 其次，它展示了上游与下游分叉并存的维护方式。移植版跟踪上游，又用 `tools/forks.json` 把自己的策略差异写成明确的清单。这比悄悄修改要透明，也让用户知道自己安装的到底是哪一套规则。 再次，作者另有一个独立插件 agent-formal-verify，用 TLA+ 模型检查和 Lean 证明处理测试无法触及的并发缺陷与不变量。两个项目的分工很清晰：pstack 管日常工作流的严谨，形式化验证管测试覆盖不到的角落。

未来的关键问题有两个。一是不同环境的原语差异会不会随各工具版本演进而扩大，使移植成本持续上升。二是工作流的质量能否被客观度量。只有出现公开的、可复现的评测，这类技能栈才能从「看起来合理」走向「证明有效」。对于想尝试的团队，建议先在一个低风险的仓库里，用一个已有的失败用例做试点，观察交付的证据是否真的减少了返工。