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

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

Package Catalog · Pi

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

扩展介绍

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

• @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"
}
}
}
```- @ff-labs/pi-fff · Packages · Pi 也就是前文说的ffgrep和fffind，相比原来的grep和find速度提升了许多，非常推荐。

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

- 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都欢迎来讨论，也欢迎提出自己的看法与见解！