
pstack 的「绝不阻塞人类」原则面向异步监督的 Agent 自主执行与可逆性边界设计【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本篇指南解读 pstack 插件中principle-never-block-on-the-human绝不阻塞人类这条工程原则在人类异步监督的工作流里Agent 面对可逆工作时应当直接执行、展示结果、事后修正仅在不可逆动作上请求确认。读完你可以掌握该原则的触发条件、四步执行模式、可逆/不可逆边界划分以及它在 pstack 的 poteto-mode、autonomous-run、multi-phase-plan 等 playbook 中的实际落地方式。原则速览一句话定义pstack 将这条原则以独立技能文件形式封装在 pstack/skills/principle-never-block-on-the-human/SKILL.md其description字段精确划定了触发条件Apply when tempted to ask should I do X? on reversible work. Proceed, present the result, let the human course-correct after the fact; reserve confirmation for irreversible actions.即当你在可逆工作上忍不住想问「我该不该做 X」时不要问——直接做展示结果让人事后纠偏只有不可逆动作才保留确认环节。该文件头部还设置了disable-model-invocation: true说明它不是由模型自主触发的通用技能而是被poteto-mode等路由技能按需引用、按名称驱动的原则文件。为什么必须不阻塞人不是流水线的瓶颈原文档给出了核心论证Why:Every permission pause stalls the pipeline and makes the human the bottleneck. Since code changes are reversible and reviewable, a wrong decision usually costs less than blocking.逐句拆解这个论点每一次许可暂停都会卡住流水线。在一个被/poteto-mode编排的多步骤、多 PR、多子代理任务里任何一步停下来等人点头都会让后续所有步骤排队人类从监督者退化为串行队列里的单点。代码变更可逆、可审阅。写代码、改笔记、拆分任务这类操作事后都能通过 diff、git 历史复查和回滚错误决策的代价通常远小于阻塞等待的代价。pstack 的定位决定了这条原则的必要性。项目 README 明确 pstack 的目标是「fearless parallelism」无畏的并行只有当你信任单个 Agent 能深入并写出良好、可验证的代码时才能真正放心地并行启动多个 Agent。如果每个 Agent 都频繁停下来问人并行就退化为串行吞吐与质量的双重目标都无法成立见 pstack/README.md。执行模式Proceed, then present原文档定义了四条可操作的模式这是原则的实践骨架先执行后展示Proceed, then present。把工作做完把结果摆出来。不要问「我该不该做 X」直接做 X并解释为什么这么做。判断标准是结果质量与理由充分性而不是事先征求许可。只为真正的歧义保留提问Reserve questions for genuine ambiguity。只有当无法从上下文推断意图时才提问。凡是能通过运行、观察、测量得出的答案都不属于人的职责范围后文会结合prototypeplaybook 详述。让系统自愈Make the system self-healing。发现问题时记录下来并在下一轮修复它。不把问题丢回给人也不在发现问题的当下停下整个流程。监督是异步的Supervision is async。把工作流设计成「事后审阅」形态而不是「事前批准」形态。人随时回来看结果、给反馈而不是时刻在线等待提问。在 autonomous-run playbook 中的落地pstack/skills/poteto-mode/playbooks/autonomous-run.md 将上述模式固化为长时任务的硬性规则Do not park reversible work for the human or useAskQuestion. Surface only irreversible actions, genuine product or preference calls no experiment can settle, or a real dead end.这条规则与原则的 Pattern 一一对应可逆工作绝不「停放」等人处理、绝不使用AskQuestion工具只有三类情况才允许上抛——不可逆动作、实验无法裁决的产品/偏好决策、真正的死胡同。注意「genuine product or preference calls no experiment can settle」正是「Reserve questions for genuine ambiguity」的操作化定义。边界可逆与不可逆的分界原文档的 Boundaries 部分是原则的护栏防止「不阻塞」退化为「鲁莽」不可逆动作Irreversible actions仍需确认force-push、删除生产数据、发送外部消息。这类操作一旦执行无法轻易撤销代价不可估量必须保留人的确认环节。可逆动作Reversible actions直接推进写代码、编辑笔记、拆分任务。这些操作可审阅、可回滚阻塞它们得不偿失。产品方向Product direction由人决定执行Execution不应阻塞。这是一个重要的职责划分Agent 不替人做产品决策但也不因产品方向未定时就在执行层空转。在 poteto-mode Autonomy 章节中的对应pstack/skills/poteto-mode/SKILL.md 的Autonomy章节给出了同一边界的运行时版本Just do it.可使用任何 MCP 工具。可逆工作与外部动作团队聊天、工单更新、启动 eval无需询问直接推进。Always pausefor irreversible writes: force-push to shared branches, deploys, data deletion, customer messages. 即共享分支的 force-push、部署、数据删除、客户消息必须暂停等待确认。Session overrides:「Dont stop」「going to bed」「run until done」「be fully autonomous」→ 继续执行。人明确授权长时自主后连确认节奏都可以放宽但不可逆边界仍然保留。No is an acceptable answer.被问是否要做某事、被邀请扩大范围时给出真实判断敢于拒绝或反驳。这说明「不阻塞」不等于「有求必应」Agent 的推荐是判断而非讨好。哪些问题不该问人用实验替代提问原则要求「只为无法从上下文推断的歧义提问」那么如何区分「该问」与「不该问」poteto-mode 给出了一条可操作的标准即将对「选哪种方案」「我该怎么做」「这个该做什么」的分叉点调用AskQuestion时先分类再问。如果答案是可以通过运行某物观察得到的事实行为、时序、布局、输出、性能甚至一个 eval 是否区分方案那它就不是该由人来回答的问题。用 Prototype playbook 草拟方案让结果来做决定。对应地pstack/skills/poteto-mode/playbooks/prototype.md 正是为此设计的它是一个「可抛弃的实验仪器」用来低成本裁决设计或行为分歧——哪种布局、哪种交互、哪种时序行为。原则的「不阻塞」在这里体现为让实验代替提问让观察代替许可。原型 playbook 的严格度反转快速、粗糙、无测试恰恰是为了快速产出证据、尽快结束「该选哪个」的悬而未决状态。反过来pstack/skills/poteto-mode/playbooks/multi-phase-plan.md 明确保留了一个合法的提问窗口原型无法裁决的产品或偏好问题才问操作者且要以给出选项的方式问Ask the operator only about a product or preference call that no run can settle. Give options (thenever-block-on-the-humanprinciple skill)。这与原则的 Boundaries 完全对齐产品方向归人执行不阻塞。长时任务中的节制检查点 vs 每步询问「不阻塞」并不意味着长时任务连一个进度检查点都不给。这条原则与figure-it-out技能配合时有一个关键补充——pstack/skills/figure-it-out/SKILL.md 的 Phase A 写道Reversible work proceeds (thenever-block-on-the-humanprinciple skill), but a multi-hour run earns one checkpoint.即可逆工作照常推进但一个长达数小时的运行值得设置一个检查点在承诺投入长期执行前向人呈现框架与权衡Present the framing and tradeoffs before committing to a long run。这让原则从「绝不阻塞」细化为「按风险分级阻塞」单步可逆操作零确认跨小时的高成本运行一次确认。这与figure-it-out的「Rigor is gates and artifacts, not try harder」精神一致——严谨度由关卡和产物体现而非无谓的反复询问。与姊妹原则的协作关系never-block-on-the-human属于 pstack 二十三原则中的Delegation委派分组与其相邻的是 pstack/skills/principle-guard-the-context-window/SKILL.md守护上下文窗口将批量读取路由给子代理、主线程只留摘要。两者配合支撑 pstack 的核心目标——放心并行guard-the-context-window解决「并行时上下文怎么装得下」never-block-on-the-human解决「并行时怎么不等人」。在 pstack/docs/guide/08-principles.md 中这两条被并列为委派分组的原则原话是「The delegation principles keep parallel work sane」——让并行工作保持理智。同时原则的「Proceed, then present」还要求执行本身可靠pstack 的 Verification 分组原则prove-it-works、sequence-verifiable-units保证了「直接做」出来的东西是可验证、可审阅的——否则「事后纠偏」就没有可靠的纠偏依据。不阻塞的前提是每步都留下可核验的产物。实战用法如何用原则名驱动 Agentpstack 的原则不是让你逐条背诵的而是「用名字来指挥」——这正是 pstack/docs/guide/08-principles.md 的主题Steer with principle names。poteto-mode在每次多步任务开始时读取原则索引根据任务触发相应原则并在回复中说明每条原则改变了哪个具体决策。如果 Agent 的回复只引用了原则名却没有对应的决策变更那说明它在「贴标签」而非真正应用。实际操作示例不要在可逆工作上等我。直接做做完展示结果和理由我来事后纠偏。或更精确地引用原则名apply never block on the human. 写代码这类可逆工作直接推进只有 force-push、删数据、发外部消息这类不可逆操作才来问我。边界案例清单何时该停何时该走综合原文档 Boundaries、poteto-mode Autonomy 与各 playbook得到一张可直接对照的决策清单场景是否阻塞依据写代码、改笔记、拆分任务不阻塞直接执行原文档 Reversible actions发现运行中的问题broken skill、相关 bug、flaky verifier不阻塞记录并在下一轮修复单独 PR 处理autonomous-run 第 4 步共享分支 force-push阻塞请求确认原文档 Irreversible actions删除生产数据阻塞请求确认原文档 Irreversible actions发送外部/客户消息阻塞请求确认poteto-mode Autonomy部署上线阻塞请求确认poteto-mode Autonomy行为、时序、性能等可观察事实的歧义不阻塞用 prototype 实验裁决poteto-mode 触发规则、prototype playbook实验无法裁决的产品/偏好决策阻塞以给出选项的方式提问multi-phase-plan 第 2 步多小时的长期运行执行前给一次检查点figure-it-out Phase A人明确授权「going to bed」「run until done」全程自主不可逆边界除外poteto-mode Session overrides小结principle-never-block-on-the-human是 pstack 委派原则组的基石它以「可逆/不可逆」为分界把 Agent 从「事事请示的串行组件」改造成「异步监督下的自主执行者」。通过先执行后展示、为歧义保留提问、系统自愈、异步监督四个模式配合 prototype 实验替代提问、检查点分级、与其他原则的协作pstack 将这条原则从一句口号落成了 poteto-mode、autonomous-run、multi-phase-plan、figure-it-out 等可运行的工程机制——这正是它能够支撑「无畏并行」的根本原因。需要深入了解时可从 pstack/skills/poteto-mode/SKILL.md 的原则索引和 pstack/docs/guide/08-principles.md 的完整原则表继续阅读。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考