pstack-claude：当AI Agent工作流变成可移植产物
你在 Cursor 里用了一套叫 pstack 的工作流——它定义了怎么修 bug、怎么做 code review、怎么规划功能。你换到 Claude Code，工作流没了。你换到 Codex，又得从头配。每个 AI 编程助手都有自己的"技能"格式，互不相通。
目录
场景开篇：同一个工作流，六个 AI 助手
你在 Cursor 里用了一套叫 pstack 的工作流——它定义了怎么修 bug、怎么做 code review、怎么规划功能。你换到 Claude Code，工作流没了。你换到 Codex，又得从头配。每个 AI 编程助手都有自己的"技能"格式，互不相通。
pstack-claude 做的事情很简单：把 Cursor 的工作流原语翻译成 Claude Code、Codex、Pi、OpenCode、Gemini、Prime Agent 都能理解的格式。同一套工作流定义，六个 AI 助手都能跑。
这听起来像是一个简单的"翻译器"项目，但它指向一个更深的趋势：AI Agent 的工作流定义正在变成可移植产物——和代码、配置文件一样，是一种可以跨平台移动的资产。
什么是 pstack？
pstack 最初是 Lauren Tan（poteto）为 Cursor 创建的技能栈。它定义了一套严谨的 agent 工作流——不是简单的 prompt 模板，而是包含角色、流程、验证步骤的完整方法论。
比如修一个 bug，pstack 的工作流是：
1. 复现失败：先确认 bug 能稳定复现 2. 用 how 和 why 调查：理解 bug 的根因，不只是症状 3. 委托修复：让 agent 实施修复 4. 重跑失败用例：验证修复有效 5. 跨函数边界时引入 architect：如果修复涉及多个函数，先做架构评审
这不是一个 prompt——这是一个流程定义。它有状态（当前在哪一步）、有条件分支（跨函数边界？）、有角色切换（implementer → architect）。
翻译的核心挑战
把 pstack 从 Cursor 翻译到其他 harness，不是简单的文本替换。每个 harness 有不同的：
- 技能格式：Cursor 用
.mdc文件，Claude Code 用SKILL.md，Codex 有自己的格式 - 调用方式：Cursor 的 slash commands、Claude Code 的
/command、Codex 的@skill - 上下文管理：每个 harness 管理会话上下文的方式不同
- 工具接口：每个 harness 暴露的工具 API 不同
/pstack:fix，在 Codex 里用 @pstack fix。这和 POSIX 标准的思路类似：POSIX 定义了 open()、read()、write() 的语义，不同操作系统（Linux、macOS、FreeBSD）各自实现，但程序只需要针对 POSIX 接口编程。pstack 定义了 agent 工作流的"接口"，不同 harness 各自实现"绑定"。
Poteto Mode：工作流的自动路由
pstack-claude 引入了一个有趣的概念叫 poteto-mode。你不需要记住"修 bug 用 /pstack:fix、做 code review 用 /pstack:review"。你只需要告诉 agent 你的目标：
"修复搜索筛选器在我切换页面时重置的问题"
poteto-mode 会自动判断这是一个 bug 修复任务，调用 pstack 的 fix 工作流。如果它判断这是一个功能开发任务，调用 feature 工作流。如果是一个性能问题，调用 performance 工作流。
这是一个路由层——在用户意图和工作流定义之间加了一层抽象。用户不需要知道有哪些工作流可用，只需要描述目标。agent 自己路由到正确的工作流。
这和 LLM router 的思路异曲同工：LLM router 根据 prompt 路由到最合适的模型，poteto-mode 根据目标路由到最合适的工作流。两者都是在调用者和被调用者之间加一个智能中间层。
策略分叉：同一工作流的不同变体
pstack-claude 有一个叫 policy forks 的机制。不同的团队可能对同一个工作流有不同的策略偏好：
- 团队 A 的 code review 工作流要求两个人工审核
- 团队 B 的 code review 工作流允许一个人工审核 + 一个 AI 审核
- 团队 C 的 code review 工作流完全自动化
这是一个很聪明的设计。它承认了没有唯一正确的工作流——不同团队有不同的约束（人员、风险偏好、自动化程度），同一个工作流定义需要支持变体。策略分叉让变体管理变得可控，而不是每个团队从头定义自己的工作流。
形式化验证：不只是 prompt
pstack-claude 最不寻常的地方是它包含了形式化验证的组件：
- TLA+ 模型检查：用 TLA+ 定义工作流的状态机，验证是否存在死锁、是否所有路径都能到达终态
- Lean 证明：用 Lean 证明某些关键工作流属性（如"修复后必须验证"不会被跳过）
这反映了一个信念：当 AI agent 越来越多地做关键决策时，工作流的正确性不能靠"试一试看看"。你需要证明：在所有可能的情况下，工作流都会做正确的事。TLA+ 和 Lean 是这个证明的工具。
无服务器、无遥测
pstack-claude 的数据策略很干净：
"pstack has no server or telemetry. Anything its skills ask your agent to read, including session transcripts, goes to your model provider. Scripts run locally, and PR tools use your GitHub CLI login."
没有服务器，没有遥测。技能读取的所有数据（包括会话记录）都直接发到你的模型供应商（Anthropic、OpenAI 等）。脚本本地运行，PR 工具用你自己的 GitHub CLI 登录。
这意味着 pstack-claude 本身不收集任何数据。你的工作流定义、你的代码、你的会话记录——都在你自己的机器上和你的模型供应商那里。pstack-claude 只是一个翻译层和路由层。
更大的趋势：工作流定义成为一等公民
pstack-claude 指向的趋势比项目本身更重要：AI agent 的工作流定义正在从"附属于特定工具的配置"变成"可移植的一等公民"。
这和编程语言生态的历史类似：
1. 早期：每个编辑器有自己的宏语言（Emacs Lisp、Vim script），互不相通 2. 中期：出现 LSP（Language Server Protocol），语言分析能力变成可移植的——一个 language server 可以被任何编辑器使用 3. 现在：每个 AI agent 有自己的技能格式，互不相通 4. 未来：出现"工作流定义协议"，工作流定义变成可移植的——一个工作流可以在任何 agent harness 里运行
pstack-claude 是这个趋势的早期实例。它不是一个协议——它是一个特定工作流（pstack）的特定翻译。但它证明了翻译是可行的，工作流定义确实可以跨 harness 移动。
如果这个趋势继续，我们可能会看到一个"Agent Workflow Protocol"——类似 LSP 之于编辑器，定义 agent 工作流的标准接口。任何 agent harness 实现这个协议，就能运行任何符合标准的工作流定义。pstack-claude 这样的翻译项目就不需要了——因为接口已经统一。
但在那一天到来之前，pstack-claude 是一个实用的过渡方案：让你在 Cursor 里积累的工作流经验，不被锁定在 Cursor 里。
结语
pstack-claude 做的事情看起来简单——翻译工作流定义。但它指向的问题很深：当 AI agent 的工作流定义变成可移植的，agent 的选择就变成了一个实现细节而不是架构决策。你可以今天用 Claude Code，明天换到 Codex，后天试 Gemini——你的工作流跟着你走。
这和"代码可移植"的价值一样：不是为了让换工具更容易，而是为了让工具为你服务，而不是你为工具服务。当工作流定义可移植时，工具的竞争回到了"谁实现工作流更好"，而不是"谁锁定了更多用户"。
项目地址：https://github.com/michael-denyer/pstack-claude