Pi个人扩展设置与讨论

对pi使用过程中的一些个人经验和理解，欢迎各位佬友前来讨论！

如果有佬友不熟悉pi的话可以直接在站内或者网上搜，有非常详细的文字，这里就不再做赘述。简单来说，pi就是一个harness的最小实现，具有read, write, edit, bash四个默认启用的功能，没有subagent，没有mcp，这些都可以通过社区或者自己直接向模型提需求拓展出来。以下是pi package的官网：

Package Catalog · Pi

那么接下来就先介绍一下我个人的一些extensions

扩展介绍

1. 
   

   @narumitw/pi-btw · Packages · Pi 首先是类似Claude Code的一个对话底部栏，使用/btw启动，可以在主对话运行过程中创建一个side thread，启动时读默认截取最多40,000字符作为背景，可以单独设置回答模型和思考强度，是独立的并发请求，回答不会污染原本上下文。适合在执行任务期间问一些问题，但又不希望这些内容进入主对话，比如：xxx函数的作用是什么？

   
   


2. 
   

   @gotgenes/pi-permission-system · Packages · Pi Pi和其他不coding agent不一样，没有权限管理，默认是yolo模式，这个扩展可以给pi加上权限管理，并且可以自定义权限，以下是我的配置（这里我使用ffgrep和fffind替代了原来的grep和find，所以把这两个命令也禁用掉了），使用下来不会像Claude Code一样一直点yes，但也没有codex那种自动审核功能，部分命令还是需要需要自己点确认，这个可以按自己的喜好更改配置。

   
   

{

  "$schema": "https://raw.githubusercontent.com/gotgenes/pi-packages/refs/heads/main/packages/pi-permission-system/schemas/permissions.schema.json",

  "debugLog": false,

  "permissionReviewLog": false,

  "yoloMode": false,



  "permission": {

    "*": "allow",



    "grep": "deny",

    "find": "deny",



    "external_directory": {

      "*": "ask"

    },



    "path": {

      "*": "allow",



      "*.env": "deny",

      "*.env.*": "deny",

      "*.env.example": "allow",



      "~/.ssh/*": "deny",



      "~/.pi/agent/auth.json": "deny",

      "~/.pi/agent/models.json": "deny",

      "~/.pi/agent/models-store.json": "deny",



      "~/.pi/agent/settings.json": "ask",

      "~/.pi/agent/trust.json": "ask",

      "~/.pi/agent/SYSTEM.md": "ask",

      "~/.pi/agent/APPEND_SYSTEM.md": "ask",

      "~/.pi/agent/npm/package.json": "ask",

      "~/.pi/agent/npm/package-lock.json": "ask",

      "~/.pi/agent/extensions/pi-permission-system/config.json": "ask"

    },



    "bash": {

      "*": "allow",



      "cmd *": "ask",

      "cmd.exe *": "ask",

      "CMD *": "ask",

      "CMD.exe *": "ask",

      "powershell *": "ask",

      "powershell.exe *": "ask",

      "PowerShell *": "ask",

      "PowerShell.exe *": "ask",

      "pwsh *": "ask",

      "pwsh.exe *": "ask",

      "Pwsh *": "ask",

      "Pwsh.exe *": "ask",

      "bash *": "ask",

      "sh *": "ask",

      "dash *": "ask",

      "zsh *": "ask",

      "fish *": "ask",



      "rm *": "ask",

      "del *": "ask",

      "erase *": "ask",

      "rd *": "ask",

      "rmdir *": "ask",

      "mv *": "ask",



      "git clean *": "ask",

      "git reset --hard *": "ask",

      "git checkout -- *": "ask",

      "git restore *": "ask",

      "git branch -D *": "ask",

      "git stash drop *": "ask",

      "git stash clear *": "ask",



      "git push *": "ask",

      "gh pr create *": "ask",

      "gh pr merge *": "ask",

      "gh pr close *": "ask",

      "gh release create *": "ask",

      "gh release delete *": "ask",

      "npm publish *": "ask",

      "pnpm publish *": "ask",

      "yarn npm publish *": "ask",

      "cargo publish *": "ask",

      "twine upload *": "ask",



      "ssh *": "ask",

      "scp *": "ask",

      "sftp *": "ask",

      "curl *": "ask",

      "wget *": "ask",



      "npx *": "ask",

      "pnpm dlx *": "ask",

      "yarn dlx *": "ask",

      "bunx *": "ask",

      "uvx *": "ask",

      "npm install *": "ask",

      "npm i *": "ask",

      "npm ci *": "ask",

      "npm update *": "ask",

      "pnpm install *": "ask",

      "pnpm i *": "ask",

      "pnpm add *": "ask",

      "pnpm update *": "ask",

      "yarn install *": "ask",

      "yarn add *": "ask",

      "yarn up *": "ask",

      "bun install *": "ask",

      "bun i *": "ask",

      "bun add *": "ask",

      "pip install *": "ask",

      "pip3 install *": "ask",

      "python -m pip install *": "ask",

      "python3 -m pip install *": "ask",

      "py -m pip install *": "ask",

      "uv add *": "ask",

      "uv sync *": "ask",

      "uv pip install *": "ask",

      "pipx install *": "ask",

      "pipx run *": "ask",

      "cargo install *": "ask",

      "go install *": "ask",

      "gem install *": "ask",



      "grep *": "deny",

      "find *": "deny"

    }

  }

}

3. 
   

   @ff-labs/pi-fff · Packages · Pi 也就是前文说的ffgrep和fffind，相比原来的grep和find速度提升了许多，非常推荐。

   
   


4. 
   

   pi-context-view · Packages · Pi 一个查看上下文占用的小工具，/context injection可以看到完整的system prompt, tool definitions等，界面做的也挺不错
   
   

   
   


5. 
   

   pi-workspace-history · Packages · Pi 可以实现Claude Code上/rewind的效果，回溯对话状态和文件修改。他使用的是shadow git，不需要项目本身有git即可运行。但他原本是基于pi的tree功能（这是pi非常好用的一个功能，下面会详细讲到）实现的，我不希望在使用/tree的同时回溯文件的修改（原因下文会讲到），所以我稍微做了一下修改，用/rewind代替了原来的/tree功能，/tree保持原有功能。使用过程中应避免在用户根目录这类目录下启动pi（默认排除根目录），或者当文件夹内有多个.git目录时也不会启用。

   
   

tree功能

Pi的tree功能很多人都说好用，但我很少看到有人说为什么好用，我来谈谈我的看法。首先，使用pi内置的/tree命令可以选择一个节点（可以是user message，assistant message或者tool result，可以多次重复选择一个节点），生成一个branch，该branch会携带到该节点之前的上下文内容（可以选择summary或no summary, 这里summary可以选择custom prompt，我一般选择no summary），这样就在一个session内完成多项任务，避免重开一个session浪费无谓的token重新了解文件结构或其他。适合的场景有：开发项目时，在模型了解项目结构和代码的节点，获取干净的上下文进行各自独立的功能开发；或者了解一份项目、一篇文章，进行独立的提问（相比btw，这些问题、过程和结果都会完整写入transcript）。

关于subagent

相信有佬注意到了我的扩展里并没有装任何关于subagent的扩展。对于这一点，我的看法是，首先，subagent会引入大量的依赖，这与pi的极简理念相违背，并且pi的作者也认为subagent是"a black box within a black box"；pi本身就是完全透明的，并且在一些文献，比如 Towards a Science of Scaling Agent Systems也指出，对于一些工具密集型，推理链长的任务单agent表现已经足够好，某些任务引入多agent效果可能更差。

我认为Subagent有两个明显的优点，第一：执行任务时有干净的上下文；第二：对于一些可以并行实现的重复任务，subagent可以节省大量时间。对于第一点，我推荐一个项目，是站里看到的，skhoroshavin/pi-supergsd，这个项目就是基于pi的tree功能实现了一个伪subagent的效果，思想很不错。项目是几个月前写的，内置了定制的superpowers skills，如果佬们觉得对于现在的模型superpowers太重了，可以酌情删除，或把思想借鉴过来融入自己的skill（我就借鉴他的思想修改了一下matt的code-reviewer）。对于第二点，我需求不是很大，目前还没想到特别好的方法，也许可以使用herdr或是其他？所以当前我就是用supergsd来替代subagent，轻量且透明。

上下文管理

上下文管理我觉得是使用agent过程中的一个很重要的部分，会直接影响到模型表现。不知道什么原因，我总觉得pi的上下文涨的特别快，这一块我还没具体去深入，不知道有没有佬友知道原因，还者是我的幻觉？

system prompt

Pi的system是可以完全自己定制的。相比其他厂商，pi默认的提示词少的不只是一点，对比了一圈下来，grok build的提示词是相对较少的，但也比pi多了不少。感兴趣的佬友可以看 https://phistory.cc/ （这也是普适性和个性化的区别，比如Claude Code就强调了很多安全性的东西，包括一些政治正确的东西，比如代词的使用；codex就对形象，以及回复的语气进行了大篇幅的描写）。我直接用SYSTEM.md替换了原本的提示词，加入了个人的一些习惯：

# System Prompt



You are a coding agent Pi that helps users complete their tasks using available tools.



## Working Rules



- Do not assume file contents, code behavior, or task scope. Verify with tools first.

- If something is genuinely ambiguous and affects the result, ask the user rather than guessing.

- Stay strictly within the requested scope. Do not modify unrelated files or make unrelated refactors, cleanups, formatting changes, or fixes.

- Do not silently remove explicit requirements. If a simpler solution cannot fully satisfy them, ask.

- Lead responses with the result. Be concise and avoid unrequested design essays or feature tours.



## Tool Use



- Keep tool-call narration brief.

- Prefer specialized tools over shell equivalents:

  - Use `read` to inspect file contents instead of `cat` or `sed -n`.

  - Use `ffgrep` to search file contents instead of `grep`.

  - Use `fffind` to locate relevant files by name or concept instead of `find`.



## Engineering Baseline



- Prefer deletion over addition.

- For coding tasks, understand the affected flow before editing.

- Fix root causes, not symptoms. Before changing shared behavior, inspect its callers and fix the common path when possible.

我还写了APPEND_SYSTEM.md对提示词做了补充，主要是参考了ponytail，他本质上也是通过提示词对模型进行软约束，我就直接迁移了一下，也修改了一些skill，比如code-reviewer，省的再多装一个插件了（使用APPEND_SYSTEM.md的原因是可以达到on/off的效果，和ponytail的区别就是无法选择强度了，一直都是full）

## Decision Ladder



For coding tasks, stop at the first option that fully solves the task:



1. Does this need to exist?

2. Reuse an existing implementation from the codebase.

3. Use the standard library.

4. Use a native platform feature.

5. Use an already-installed dependency.

6. Use one clear line when it remains readable and correct.

7. Otherwise, write the minimum code that works.



## Complexity Constraints



- Prefer boring code over clever code.

- Avoid unrequested abstractions, single-use factories, single-implementation interfaces, speculative configuration, unnecessary dependencies, and scaffolding for future needs.

- Use the fewest files and smallest correct diff.



## Non-Negotiable Boundaries



Never simplify away:



- trust-boundary input validation

- error handling that prevents data loss

- security controls

- accessibility basics

- correctness on relevant edge cases



Non-trivial new logic should leave one minimal runnable check. Trivial changes need no extra test.

magic context

链接是 GitHub - cortexkit/magic-context: Unbounded context. Memory that manages itself. One session, for life. The hippocampus for coding agents, part of CortexKit. · GitHub 这个也是之前站里的佬友推荐的，一般原生的压缩都是给一段提示词让模型自己总结，我觉得这种压缩效果很难评，会丢失太多东西，而且很模型能力也有很大关系。

这个项目总体使用下来压缩挺无感的，不会特地打断你进行压缩，并且考虑到了缓存命中的问题，一般都是在cache bust的节点进行压缩，细节我认为保留的不错，本来想在这里讲具体实现的，但感觉太长了，有感兴趣的佬友我可以单独再开一个话题谈一谈压缩。

一些讨论

当前我的扩展装的不多，一些常见的扩展比如mcp-adapter、todo类的我都没装，一方面是我当前没有遇到什么必须使用的mcp，还有一个就是佬友们认为todo对模型有实际的提升吗（magic context自带todo，但我觉得那个不太好，后面打算自己修改一下把todo、ctx_note、ctx_aug这些功能都去掉，明确一下边界，具体原因在这里就先不展开了）；还有一些，比如web-acccess我是想装还没装，佬友们使用下来感觉怎么样？还有一些修改tui的我也没看到满意的，以及整理tool output类的；还有关于trellis，我本来装了的，但感觉对于个人使用有点重了，佬们怎么看，有没有一些实践说明…

结尾

佬们如果有什么其他推荐的扩展或者skill都欢迎来讨论，也欢迎提出自己的看法与见解！