背景 为何使用起 Pi Coding Agent： 主要原因：近几个月很多公益站的 gpt 模型没有了，想要低成本使用没有降智的 gpt 越来越难（还是想白嫖为主 ）。 与此同时，很多公益站都上了国模，主要还是以 flash 为主的模型，比如 deepseek-v4-flash、deepseek-v4.1-flash、glm-5.3-flash，当然也有 glm-5.3，kimi-k3 等大参数模型，但是限制于额度或者是稳定性，一般都不太能顺畅使用。 这些 flash 模型在 Codex 或者 Claude Code 上面表现不佳，我猜测原因还是现在这两个功能越来越庞大，并且与自家模型绑定了一些功能（比如 cache_control 和 prompt_cache_key），导致启动时上下文占用很多，并且默认注册的工具也多，一些特殊用法在自家模型上表现正常，在别的模型上则不能正常发挥作用甚至影响模型发挥。 平时水 L 站多了，自然早已耳闻 pi 的大名，以简洁著名，能个性化打造自己的 coding agent，并且有了稳定版本，而且还在积极推进，没有那么多 breaking change，所以没怎么考虑就选择了这个了。 目标：能够在一些没有那么复杂的场景下使用 Pi Coding Agent + 国模来代替 gpt，达到最低成本 vibe coding。 我写的插件 以下插件基本都是边 Pi Coding Agent+flash 国模开发，边完善的，也是体会到了奥特曼他们用 gpt 开发 codex 的过程，确实以这种方式，开发了也能用起来，用起来的时候也能发现又哪些不足，然后又继续演进，互相成就。 目前基本能用阶段，因为我开发这些插件的过程，就是在用这些插件了，但是估计还得慢慢优化。 watchdog（自动发继续） 解决明明输出还没有结束，但是 api 的流式输出就是完成了，只有发 继续 才能接着输出。会注册一个工具到主 agent。 因为我默认开启这个插件，如果没有问题，也会发一次给 llm 确认一下，没法知道任务是不是真的完成了，如果人不在屏幕面前，所以下面的截图是正常情况下的。 更多了解可以见文章：【Pi Coding Agent】watchdog自动发继续插件 | GreenHatHGのBlog subagent 其实 subagent 有时候还是有必要的，我在用 flash 模型的时候发现有些结论并不对，如果你单独拿出这条结论重新开个对话用同样的 flash 模型再确认一次，这次就对了。所以你可以手动复制粘贴一下结论给在新的对话确定一下，或者是叫主 agent 启用 subagent 再去确认一下结论（这里有个坑就是主 agent 给 subagent 的描述，会不会把 subagent 也引导歪了，这是另外一个话题了）。 基于 tmux+Pi Coding Agent 本身，等于是用 tmux 启动另外一个 Pi Coding Agent，基于文件交流。 基于 tmux 好处是可以随时使用 tmux 命令连接上去看 subagent 干了什么，也能提前结束，重新发送别的内容，其实就是跟用 Pi Coding Agent 一样，不用管什么 subagent 不 subagent 的。但是 subagent 不注册 subagent 工具，也就是不能嵌套启用 subagent。 另外 subagent 是一个 Pi Coding Agent 实例的话，也可以用到上面提到的 watchdog 插件，来帮助你自动发继续，确定 subagent 是真的完成了。大家都知道，公益站提供的 llm 很多时候都不稳定，用在 subagent 上是个很痛苦的事情，subagent 可能一直断流，需要靠主 agent 来监控和重试，可能现在很多 harness 框架处理的比较好了，在早期版本，subagent 很不完善。 总共有三种模式，所以会注册三个工具到主 agent，advisor用的最多，其次是websearch，最后是普通的： 普通 subagent 模式：system prompt，tools 和主 agent 基本一样。 websearch 专用：system prompt 改为用于专门搜索，加载 pi-web-access 插件，同时限制 tools 列表。 advisor 模式：用于 flash 模型询问高级模型，system prompt 改为 advisor 模式专用，同时限制 tools 列表。 以 advisor 模式举例，总共5个部分，如图里面的圆圈： 代表模型调用 advisor 工具，然后 subagent 插件会输出一些常用的命令，用于快速复制粘执行，比如 kill 掉这个 subagent、连接到 tmux 上面看这个 subagent 的输出等等。 主 agent 给 subagent 写的任务详细说明，点击可以展开查看。 主 agent 等待 subagent 完成，超时 1800s，如果 subagent 完成了，会通知这个命令，主 agent 就会接着执行。 subagent 任务完成后，会将结果写到文件中，点击可以展开查看。 主 agent 查看结果文件。 简单加了个 subagent 的状态，先凑合用，ui 和操作并不是很完美 默认情况下展示 agent 的状态，左边是 agent 的名字，右边则是最后一行输出： 点击可以展开，查看更多的状态行： 展开后还可以点击具体一个 subagent，这时候弹出一个悬浮窗，其实就是连接上了 tmux 的窗口，可以实时预览 subagent 的输出。 subagent 一执行结束，tmux 就不能连接上去查看，想要事后看到 subagent 做了些什么，只能是通过读 Pi Coding Agent 的 jsonl 文件，里面记录了 subagent 当时做了些什么，可以下载个专门解析 jsonl 的工具，也可以使用 pi --session 命令恢复。 bash guard（命令拦截） 我在用 flash 模型的过程中，发现 flash 用 bash 会执行一些很宽泛的命令，比如 find ~ ，或者是 grep 没加关键过滤条件或者是条件太广泛，返回 40 kb 的结果。所以我搞了个插件，专门拦截一些广泛的命令还有大搜索结果返回，主要是下面几种情况： 针对搜索的命令：find、rg、grep、find、tree、ls -R、ps 等命令： 命令返回限制在 8KB，如果超过了就将完整输出保存在磁盘，返回给 llm 超额的错误提示、修正的意见、磁盘文件路径、按 error/warning 关键字提取的关键行、头和尾的预览等等。 拦截一些搜索范围很大的命令：如果扫描的目录是 $HOME 、/ 或者系统目录（/etc、/var、/usr 这些），会拒绝运行，然后返回给 llm 建议。 搜索命令如果没设超时参数或者设得比 300 秒大，则修改参数为300，如果设置比 300 小，则不修改，避免 llm 无脑设置一个很大的超时。 针对真的需要查看很多内容的命令：比如 git diff、pnpm build、pytest、sed 等，限制在 30kb，如果超过了就将完整输出保存在磁盘，返回给 llm 磁盘文件路径以及怎么用 read/grep 工具按需读取的建议。 Pi Coding Agent 的 bash 工具默认限制 50kb 返回，这个未修改。 1 和 2 是利用静态代码去做命令识别，所以只能覆盖常见情况，并且可能有一些误杀的情况，比如确实是得输出这么多，但是被拦截了，llm 还得多次读取，反而增加了开销。还得随着使用次数增多，根据拦截的结果进一步优化静态代码。 此外还有两个额外的功能： 只读命令模式：用于 advisor subagent，避免 advisor 执行修改命令，比如写、删、装依赖、联网搜索等。毕竟设计 advisor 的目的是咨询，而不是让 advisor 重新深度调查一次。 注入 bash guard 拦截和正确使用 rg、head 等命令的说明，会自动当作用户消息发出去，只会发一次。（这个说明可能不太完善，并且后续看看添加到system prompt是不是会更好点）： [BASH OUTPUT DISCIPLINE]\nAn extension guards shell output. Search/listing/dump commands (e.g. rg, recursive grep, find, ls -R, env, ps, git log) are capped at 8.0KB; other commands are capped at 30.0KB. Above the cap, the result is replaced with a short preview, the error/warning lines, and a path to the full output. Guarded results are marked [BASH OUTPUT GUARD]. Treat it as a nudge to rewrite the command, or to read the file, not as a failure.\n\nBound output before you run:\n- Content search: use the grep tool (limit caps matches; it respects .gitignore). In bash, rg -l lists matching files only, -c counts per file, -m 5 caps matches per file. Never scan a huge tree unbounded.\n- Read files: use the read tool with offset/limit. For spot checks use sed -n '1,80p' <file> or head -n 80 <file> — not cat.\n- Logs/lists: tail -n 50, git log --oneline -n 20, git diff --stat, ls | head.\n- Aggregate first: | wc -l, | sort | uniq -c, -q/--quiet/-s. Write big output to a file, then read/grep it selectively.\n\nSearch commands (find, recursive grep, rg, du, tree) are capped at 5 minutes (300 seconds) automatically; scans rooted at $HOME, /, or a system directory like /etc are blocked before they run. Everything else runs with no timeout guard — pass an explicit timeout for anything that can hang (log follow, foreground servers). plan mode（计划模式） 这个我有两个实现，主要是用第一个实现比较多，也最简单，目前用着还行。其实就是在 ~/.pi/agent/prompts/discuss.md 写入 --- description: 先讨论方案与影响，待用户确认后再开始执行修改 argument-hint: "<task>" --- 先讨论，再执行：$@% 比如你在 tui 里面输入 /discuss 帮我看看怎么修复这个错误：xxx ，其实就等于发 先讨论，再执行：帮我看看怎么修复这个错误：xxx 。这个我在 flash 模型用着都还行，没有遇到过什么情况，也很简单。 第二种则是类似 Codex 那种，我是通过插件实现的，实现的逻辑：如果使用了 /plan ，那么就动态注册一个 submit_plan 工具，并且在 plan 阶段只给使用只读命令和只能写 .md 文件。 还会给 llm 发送一条消息说，你已经在 plan 模式，你应该怎么做，什么是不能做的： "[PLAN MODE]\nYou are in plan mode.\n\nUntil the plan is approved:\n- write/edit may only modify .md/.mdx files inside the working directory (cwd). All other writes are blocked.\n- bash is for read-only exploration. File mutations, redirects, installs, git write operations, sed -i, and tee may be blocked by a best-effort guard.\n- Explore the codebase, then write the complete plan to a markdown file and call submit_plan with its path.\n- The plan must include context, approach, files to modify, implementation steps, and verification.\n- A blocked tool call is not an error to retry: it means plan mode forbids it.\n- If non-markdown changes are needed before approval, ask the user to run /

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/15 17:03:21