pi 编程智能体 CLI 实战：LLM API + Agent Loop + TUI 架构解析

1. 从"pi"这个标题说起：一个极简命名背后的技术野心

第一次看到"pi"这个项目标题，很多人会愣一下——是那个圆周率？还是树莓派？其实都不是。在当下 coding agent CLI 这个赛道里，"pi"是一个把 LLM API、agent loop、TUI 三样东西揉在一起，做成命令行编程智能体的开源项目。它的命名逻辑很直白：像圆周率一样，是一个基础常数，简单、通用、无处不在，你可以在任何终端里把它拉起来，让它帮你读代码、改代码、跑命令。

我接触 pi 的契机很偶然。当时我在折腾一个老项目的重构，需要在几十个文件里批量替换一套 API 调用方式，手动改太慢，用 IDE 的全局替换又怕误伤。朋友甩给我一句"你试试 pi"，我装完跑起来，发现它就是一个跑在终端里的 agent，能理解自然语言指令，能自己决定调用哪些工具，能读文件、写文件、执行 shell 命令，整个过程在一个 TUI 界面里实时展示。那一刻我意识到，这类工具真正解决的痛点不是"AI 能不能写代码"，而是"AI 能不能在一个可控、可观测、可中断的循环里，替我把那些琐碎的、重复的、需要来回切换上下文的活儿干掉"。

pi 适合谁？三类人最该关注。第一类是每天泡在终端里的后端和运维，你们本来就不爱开 IDE，pi 的 TUI 形态天然贴合你们的工作流。第二类是需要批量处理代码库的工程师，比如做迁移、做重构、做代码审查，pi 的 agent loop 能把多步操作串起来自动跑。第三类是想自己搭 agent 的开发者，pi 的架构足够清晰，LLM API 层、loop 层、TUI 层分得干净，拿来当学习范本或者二次开发的底座都合适。这篇文章我会把 pi 的核心设计、安装配置、agent loop 的实现逻辑、TUI 的交互细节、以及我踩过的坑，全部摊开讲清楚，让你看完就能自己跑起来。

2. pi 的整体架构设计：为什么是"LLM API + Agent Loop + TUI"这三件套

2.1 三层架构的职责划分与选型逻辑

pi 的架构可以用一句话概括：TUI 负责交互，agent loop 负责决策，LLM API 负责推理。这三层各司其职，边界清晰，这是它能保持轻量的关键。

先说 TUI 层。为什么不做成 Web UI 或者 IDE 插件？因为 pi 的目标用户是终端重度使用者，TUI 的优势在于零上下文切换——你不用离开终端，不用等浏览器加载，不用在 IDE 里找插件面板。TUI 用字符绘制界面，资源占用极低，SSH 远程连上去也能用，这是 Web UI 做不到的。pi 的 TUI 通常基于 ratatui（Rust 生态）或 blessed/ink（Node 生态）这类库实现，核心是把 agent 的思考过程、工具调用、执行结果实时渲染成可滚动的面板。

再说 agent loop 层。这是 pi 的心脏。所谓 agent loop，就是一个"思考-行动-观察"的循环：LLM 根据当前上下文决定下一步做什么，agent 执行这个动作（比如读文件、跑命令），把结果喂回给 LLM，LLM 再决定下一步，直到任务完成或者达到终止条件。这个循环的设计质量直接决定了 agent 好不好用。pi 的 loop 层要处理几个关键问题：如何管理对话历史、如何解析 LLM 返回的工具调用、如何执行工具并把结果格式化、如何判断循环该不该停。

最后是 LLM API 层。pi 不绑定某一家模型，它通过统一的 API 抽象层对接不同的 LLM 服务。这一层的设计要点是：请求格式统一、流式响应处理、错误重试、token 计数。为什么要做抽象层？因为不同模型的 API 细节差异很大，有的用 function calling，有的用 JSON mode，有的只支持纯文本。抽象层把这些差异屏蔽掉，让上层的 agent loop 不用关心底层用的是哪家模型。

提示：三层架构的价值在于可替换性。你想换模型，只动 API 层；你想换界面，只动 TUI 层；你想改决策逻辑，只动 loop 层。这种解耦是 pi 能快速迭代的基础。

2.2 为什么 agent loop 是这类工具的真正门槛

很多人以为做个 coding agent 就是"调个 LLM API 然后执行返回的命令"，真做起来才发现坑全在 loop 里。我举个实际例子：你让 pi "把这个项目里所有 console.log 删掉"。一个幼稚的实现会直接把这句话发给 LLM，LLM 返回一段 sed 命令，agent 执行，完事。但现实是：项目里可能有几百个文件，sed 命令可能误伤注释里的 console.log，可能有文件编码问题，可能执行到一半报错。一个成熟的 agent loop 必须能处理这些情况——它得先搜索定位、再逐个确认、再执行、再验证结果、遇到错误要能回退或重试。

pi 的 loop 设计里，我观察到几个关键决策。第一，工具调用是结构化的，不是让 LLM 自由输出文本再解析，而是用 function calling 或严格的 JSON schema 约束 LLM 的输出，这样解析可靠得多。第二，每一步都有观察反馈，工具执行的结果（包括 stdout、stderr、退出码）都会回灌给 LLM，让它知道上一步到底成没成。第三，有最大迭代次数限制，防止 agent 陷入死循环烧 token。第四，支持中断，用户在 TUI 里随时可以按快捷键打断当前循环。

这些设计听起来简单，但每一个都是踩坑踩出来的。比如最大迭代次数，设太小任务做不完，设太大又可能失控，pi 一般默认在 20 到 50 之间，具体看任务复杂度。再比如中断，如果没有优雅的中断机制，agent 正在执行一个长命令时你按 Ctrl+C，可能留下半截状态，下次跑就乱了。

2.3 与同类工具的差异化定位

市面上 coding agent 工具不少，pi 的差异化在哪？我总结三点。

第一是终端原生。很多同类工具要么是 IDE 插件，要么是 Web 应用，pi 坚持做 CLI + TUI，服务的是那群"终端就是家"的人。这个定位看似小众，但用户粘性极高。

第二是可组合性。pi 的工具集是开放的，你可以给它加自定义工具，比如对接你们内部的部署脚本、查询内部文档的接口。这让 pi 不只是一个通用助手，而是能深度嵌入你团队工作流的智能体。

第三是透明可控。pi 的 TUI 会把 agent 的每一步都展示出来——它在想什么、要调什么工具、参数是什么、结果是什么。这种透明度在调试和信任建立上非常重要。你永远知道它在干什么，而不是面对一个黑盒等结果。

3. 安装与配置实操：从零把 pi 跑起来

3.1 环境准备与依赖检查

pi 的安装方式取决于它的实现语言。目前这类工具主流是 Node.js 或 Rust 实现。假设 pi 是 Node 生态的（这是最常见的情况），你需要先确认环境。

打开终端，先检查 Node 版本：

node --version npm --version

pi 一般要求 Node 18 以上，因为要用到原生的 fetch API 和较新的 ES 特性。如果版本太低，用 nvm 升级：

nvm install 20 nvm use 20

然后是 API key 的准备。pi 需要至少一个 LLM 服务的凭证。这一步是新手最容易卡住的地方——不是技术难，是概念绕。你需要理解：pi 本身不含模型，它只是个客户端，你得给它一个能调用的模型服务。这个服务可以是官方的 API，也可以是你自己部署的兼容接口。

配置 API key 通常有两种方式。一种是环境变量：

export PI_API_KEY="your-key-here" export PI_API_BASE="https://your-api-endpoint"

另一种是写配置文件，一般在~/.config/pi/config.json或项目根目录的.pi/config.json。我推荐用配置文件，因为环境变量在多个终端会话间容易丢，而且不方便管理多套配置。

注意：API key 千万不要硬编码进代码提交到仓库。用.gitignore把配置文件排除掉，或者用专门的密钥管理工具。

3.2 安装 pi 的几种方式与选择建议

安装方式一般有三种，我按推荐度排序。

方式一：包管理器全局安装。如果是 npm 生态：

npm install -g pi-agent

装完直接pi命令就能用。优点是简单，缺点是全局包升级要手动，而且可能和系统里其他 Node 工具的依赖打架。

方式二：项目本地安装。在具体项目里：

npm install --save-dev pi-agent npx pi

这种方式适合你想把 pi 的版本和项目绑定，团队协作时大家用同一个版本。缺点是每个项目都要装一遍。

方式三：从源码构建。如果你想改 pi 的代码或者用最新特性：

git clone https://github.com/xxx/pi.git cd pi npm install npm run build npm link

npm link会把本地的构建产物链接到全局，这样你改完代码重新 build 就能生效。这种方式适合开发者和深度定制用户。

我个人的选择是：日常用方式一，做定制开发时用方式三。方式二我很少用，因为 pi 本身是通用工具，没必要和单个项目绑定。

3.3 首次运行与基础配置验证

装完之后，第一次运行建议先做个连通性测试：

pi --version pi config check

config check这类命令会验证你的 API key 是否有效、endpoint 是否可达、模型是否可用。如果这一步报错，八成是三个原因：key 错了、endpoint 写错了、网络不通。逐个排查。

然后跑一个最简单的任务试试水：

pi "列出当前目录下所有的 .js 文件"

如果 pi 正常启动 TUI，你能看到它在思考、调用列目录的工具、返回结果，说明基础链路通了。这一步很关键，很多人跳过直接上复杂任务，结果出问题时分不清是配置问题还是任务问题。

配置项里我建议重点调这几个：

auto_approve这个配置我要特别说一句。设成 true 时，agent 调用任何工具都不问你，直接执行。爽是爽，但风险大——万一它要删文件、要跑危险命令，你连拦的机会都没有。我建议新手一律 false，等熟悉了 pi 的行为模式，再对特定安全工具开自动批准。

4. Agent Loop 深度拆解：pi 的决策循环是怎么跑起来的

4.1 一次完整循环的生命周期

要理解 pi，必须理解它的 agent loop。我用一个具体任务来串：你输入"帮我把 utils.js 里的 formatDate 函数改成支持时区参数"。

第一步，上下文组装。pi 把你的指令、系统提示词、历史对话、可用工具列表打包成一个请求。系统提示词很关键，它定义了 agent 的角色、行为规范、工具使用约定。pi 的系统提示词一般会强调"你是编程助手，优先读文件再改文件，改动前先确认"这类规则。

第二步，LLM 推理。请求发给 LLM，LLM 返回一个响应。这个响应可能是纯文本（比如它想先问你一个问题），也可能是一个工具调用（比如它决定先读 utils.js）。

第三步，工具调用解析。如果 LLM 返回工具调用，pi 解析出工具名和参数。比如read_file工具，参数是{"path": "utils.js"}。

第四步，工具执行。pi 执行这个工具，拿到结果。读文件就返回文件内容。

第五步，结果回灌。把工具执行结果作为一条新消息追加到对话历史，再次发给 LLM。

第六步，循环判断。LLM 拿到文件内容后，可能决定继续调用edit_file工具来改代码，也可能觉得信息不够要再读别的文件，也可能直接返回最终答案。pi 检查是否满足终止条件——LLM 返回了最终答案、达到最大轮数、用户中断、或者出错。

这个循环看起来简单，但每一步都有讲究。我重点讲两个最容易出问题的地方。

4.2 工具调用的结构化约束与解析

让 LLM 可靠地输出工具调用，是 agent 能不能用的分水岭。早期很多实现是让 LLM 输出一段特定格式的文本，比如：

ACTION: read_file ARGS: {"path": "utils.js"}

然后正则解析。这种做法极其脆弱——LLM 可能多输出一个空格、可能把 JSON 写错、可能在 ARGS 后面加解释文字，解析就崩了。

pi 用的是更可靠的方式：function calling或JSON schema 约束。function calling 是主流 LLM 服务都支持的能力，你在请求里声明有哪些工具、每个工具的参数 schema，LLM 就会按 schema 返回结构化的调用请求。这样解析几乎不会出错。

如果用的模型不支持 function calling，退而求其次用 JSON mode，强制 LLM 只输出 JSON。再不行，才用文本解析加容错。

我实测下来，function calling 的可靠性比文本解析高一个数量级。如果你在选模型，优先选支持 function calling 的，这能省掉大量调试时间。

工具的定义也有讲究。一个好的工具定义包含：名字（清晰无歧义）、描述（告诉 LLM 什么时候用）、参数 schema（类型、是否必填、描述）。描述写得好不好，直接影响 LLM 会不会在正确的时机调用正确的工具。比如read_file的描述如果只写"读文件"，LLM 可能在该用search的时候也去读文件；如果写"读取指定路径的完整文件内容，适用于已知确切路径的场景，如果不知道路径请先用 search 工具"，LLM 的选择就准确多了。

4.3 循环终止条件与失控防护

agent loop 最怕的就是失控——LLM 陷入某种循环，反复调用同一个工具，或者在一个错误上反复重试，token 哗哗烧，任务就是做不完。pi 的防护机制有几层。

第一层，最大迭代次数。硬性上限，到了就停。这个值要平衡：太小编程任务做不完，太大失控成本高。我的经验是简单任务 10 到 15，中等任务 20 到 30，复杂重构 40 到 50。

第二层，重复检测。如果 agent 连续多次调用相同的工具、相同的参数，pi 会警告或直接终止。这能抓住"LLM 卡在某个错误上反复重试"的情况。

第三层，用户中断。TUI 里随时可以打断。这是最后一道防线，也是最有效的——你看着不对劲，直接按停。

第四层，工具级超时。单个工具执行超过设定时间就杀掉。防止某个命令卡死拖垮整个循环。

提示：如果你发现 agent 经常撞到最大迭代次数，先别急着调大这个值。多半是任务描述太模糊，或者工具集不够用。把任务拆细、把工具补全，比单纯调大上限有效得多。

4.4 上下文管理与 token 优化

agent loop 跑起来，对话历史会越来越长。每一轮都要把完整历史发给 LLM，token 消耗是累积的。跑个几十轮，token 成本可能很吓人，而且可能超出模型的上下文窗口。

pi 的上下文管理策略一般有几种。滑动窗口：只保留最近 N 轮对话，老的丢掉。简单但可能丢关键信息。摘要压缩：把老对话用 LLM 总结成一段摘要，保留要点。成本低但会损失细节。关键信息提取：把工具执行结果里的关键部分（比如文件路径、错误信息）单独存起来，原始大段输出丢弃。

我观察到 pi 通常组合使用这些策略。比如读了一个大文件，文件内容在回灌给 LLM 后，下一轮可能就被压缩成"已读取 utils.js，包含 formatDate 函数"这样的摘要，而不是保留整个文件内容。这样既让 LLM 知道读过什么，又不占 token。

这个机制对使用者也有启示：给 agent 的任务要尽量聚焦。你让它一次干太多事，上下文膨胀得快，效果反而差。拆成几个小任务分次跑，往往又快又省。

5. TUI 交互设计：终端里的 agent 体验怎么做才顺手

5.1 TUI 布局与信息层级

pi 的 TUI 是它区别于其他 agent 工具的门面。一个好的 TUI 布局要让用户一眼看清三件事：agent 在干什么、干到哪一步了、有没有需要我介入的。

典型的 pi TUI 布局分几个区域。主对话区占最大面积，滚动展示 agent 的思考、工具调用、执行结果。输入区在底部，你在这里敲指令。状态栏显示当前模型、token 消耗、循环轮数、运行状态。工具调用面板（有些实现有）单独列出当前正在执行的工具和参数。

信息层级的设计原则是：重要的、需要用户注意的信息要突出。比如 agent 要执行一个危险命令（rm、覆盖写文件），TUI 应该用醒目的颜色和确认提示拦住你。而普通的读文件操作，可以低调展示，不打断你的阅读流。

我特别喜欢 pi 的一点是它把 agent 的"思考"和"行动"分开显示。思考是 LLM 的推理文本，行动是工具调用。这样你能看出 agent 的逻辑链条——它为什么决定读这个文件、为什么决定改那行代码。调试的时候这个信息太有用了。

5.2 快捷键与交互效率

终端用户对快捷键有执念，pi 的 TUI 快捷键设计直接影响使用效率。常用的几个：

• Enter提交输入
• Ctrl+C中断当前循环
• Ctrl+D退出
• ↑/↓浏览历史输入
• Tab自动补全（比如补全文件路径）
• Ctrl+L清屏
• PageUp/PageDown滚动对话区

这些是基础。进阶的还有：切换模型、查看 token 统计、导出对话记录、切换 auto_approve 模式。这些操作如果都要敲命令就太慢了，做成快捷键或者快捷命令（比如输入/model切换）体验好很多。

我个人的使用习惯是：把最常用的三四个快捷键练成肌肉记忆，其余的用/开头的斜杠命令。pi 一般支持斜杠命令体系，比如/help、/clear、/model、/cost，这些不占用快捷键位，又能快速调用。

5.3 流式输出与实时反馈

LLM 的响应是流式的，一个字一个字吐出来。TUI 要能实时渲染这个流，而不是等全部生成完再显示。这对体验影响巨大——你看着 agent 的思考过程实时展开，能提前判断它方向对不对，不对就赶紧中断，省 token 省时间。

工具执行也要有实时反馈。比如 agent 跑一个耗时的构建命令，TUI 应该实时显示命令的输出，而不是等命令结束才一次性显示。这样你能看到进度，知道它没卡死。

pi 在这块的处理一般是：LLM 流式输出直接渲染到对话区；工具执行时，stdout/stderr 实时追加显示，同时状态栏显示"执行中"和已耗时。命令结束后，显示退出码和总耗时。

注意：流式渲染在 SSH 弱网环境下可能卡顿。如果遇到，可以在配置里关掉流式，改成批量渲染。牺牲一点实时性换流畅度。

5.4 多会话与状态持久化

实际使用中，你往往同时进行多个任务。pi 一般支持多会话——每个会话有独立的对话历史和上下文。你可以开一个会话做重构，另一个会话查 bug，互不干扰。

会话的持久化也很重要。跑到一半关掉终端，下次打开还能接着跑。pi 会把会话状态存到本地（一般在~/.config/pi/sessions/或项目目录下），包括对话历史、工具调用记录、当前状态。恢复会话时，agent 能接着之前的上下文继续。

这个功能在长任务上特别有用。比如一个大规模重构要跑很久，你不可能一直守着，存下来分几次跑，每次接着上次的进度。

6. 常见问题与排查技巧实录

6.1 安装与配置类问题

问题一：pi命令找不到。全局安装后命令不可用，八成是 npm 的全局 bin 目录不在 PATH 里。用npm config get prefix看全局目录，把它加到 PATH。或者直接用npx pi绕过。

问题二：API 调用报 401/403。key 无效或权限不足。先确认 key 没写错、没过期，再确认这个 key 有没有调用目标模型的权限。有些服务的 key 是分模型的，你拿 A 模型的 key 调 B 模型就会 403。

问题三：连接超时。endpoint 写错、网络不通、或者服务端限流。先用 curl 手动测一下 endpoint 通不通，排除网络问题。如果是限流，降低请求频率或换个时间段。

问题四：模型返回格式不符合预期。如果你用的模型不支持 function calling，pi 可能解析失败。换支持 function calling 的模型，或者在配置里切换到文本解析模式。

6.2 Agent 行为异常类问题

问题五：agent 反复读同一个文件。这是典型的上下文管理问题——agent 读完文件后，文件内容被压缩掉了，它"忘了"读过，又去读。解决办法是调大上下文保留窗口，或者把任务拆细减少轮数。

问题六：agent 改代码改错地方。多半是任务描述不够精确，或者 agent 没先读文件就动手。在系统提示词里强化"改动前必须先读文件确认"的规则，任务描述里给足上下文（比如指明具体函数名、行号范围）。

问题七：agent 陷入错误重试循环。比如一个命令一直失败，agent 反复重试同样的命令。pi 的重复检测应该能拦住，但如果没拦住，手动中断，然后分析为什么失败——多半是环境问题（缺依赖、权限不足），agent 自己解决不了，需要你先修好环境。

问题八：token 消耗异常高。检查是不是任务太宽泛导致轮数太多，或者上下文没压缩导致每轮都发大量历史。用/cost类命令看 token 统计，定位消耗大头。

6.3 性能与稳定性问题

问题九：TUI 卡顿。对话历史太长、流式渲染太频繁、或者终端本身性能差。清理历史、关流式、换个轻量终端。

问题十：工具执行卡死。某个命令 hang 住了。配置工具级超时，超时自动杀掉。同时检查是不是命令本身有问题（比如等待输入、死锁）。

问题十一：会话恢复后状态错乱。持久化数据损坏或版本不兼容。删掉会话文件重开，或者升级 pi 到最新版。

我把这些整理成速查表：

6.4 我的独家避坑心得

踩了这么多坑，有几条经验是文档里不会写的。

第一条，先小后大。新上手 pi，别一上来就让它重构整个项目。先拿单个文件、单个函数练手，摸清它的行为模式、工具集、出错方式。等你有把握了，再上大任务。

第二条，任务描述要像给实习生派活。你给实习生派活会说清楚背景、目标、约束、验收标准。给 agent 也一样。"改一下这个函数"太模糊，"把 formatDate 改成接受第二个可选参数 timezone，默认 UTC，改动后保证现有调用不报错"就清楚多了。

第三条，盯着前几轮。agent 跑起来后，前几轮一定要盯着看。如果方向错了，前几轮就能看出来，赶紧中断，改描述重来。等它跑了二十轮你才发现错了，token 白烧。

第四条，危险操作手动确认。auto_approve 再爽，涉及删除、覆盖、执行系统命令的操作，一律手动确认。我见过太多"agent 把我文件删了"的惨案。

第五条，保留对话记录。pi 的对话记录是宝贵的调试资料。任务失败时，翻记录看 agent 在哪一步走偏的，比凭空猜有效得多。有些实现支持导出记录，善用这个功能。

7. 扩展玩法：把 pi 用出花来

7.1 自定义工具接入内部工作流

pi 的工具集是开放的，这是它最有想象力的地方。你可以给它加自定义工具，让它对接你们团队内部的系统。

比如加一个query_docs工具，让 agent 能查内部文档；加一个deploy工具，让 agent 能触发部署；加一个query_db工具，让 agent 能查数据库。这样 pi 就不只是通用编程助手，而是深度嵌入你工作流的智能体。

自定义工具的实现一般是一个函数加一个 schema 声明。函数负责实际执行，schema 告诉 LLM 这个工具怎么用。写好之后注册到 pi 的工具列表里，agent 就能调用了。

提示：自定义工具的描述要写清楚使用场景和参数含义，这直接决定 LLM 会不会在正确的时机调用它。描述写得含糊，LLM 要么不用，要么乱用。

7.2 多 agent 协作与任务编排

单个 agent 能力有限，复杂任务可以拆给多个 agent 协作。比如一个 agent 负责分析需求、一个负责写代码、一个负责测试。pi 如果支持多会话或者多实例，你可以手动编排这种协作。

更进阶的是任务编排——把一个大任务拆成有依赖关系的子任务，让 agent 按顺序或并行执行。这块 pi 本身可能不直接支持，但你可以用脚本把多个 pi 调用串起来，或者基于 pi 的 API 自己写编排层。

7.3 与 CI/CD 和自动化流程集成

pi 的 CLI 形态让它天然适合集成到自动化流程里。比如在 CI 里跑 pi 做代码审查、做自动化修复、做文档生成。

集成方式一般是：在 CI 脚本里调用 pi 的命令行接口，传入任务描述，pi 跑完返回结果，CI 根据结果决定后续步骤。注意 CI 环境是无头的，TUI 用不了，得用 pi 的非交互模式（如果支持的话），或者用它的 API 直接调用。

这块的坑在于：CI 环境没有你的本地配置，API key 要通过 CI 的密钥管理注入；CI 环境可能没有你本地的工具链，agent 调用的命令可能不存在。集成前先在 CI 环境里手动跑一遍，确认环境齐全。

7.4 基于 pi 做二次开发

如果你想基于 pi 做自己的 agent 产品，它的三层架构是很好的起点。你可以复用它的 agent loop 和 LLM API 抽象层，只替换 TUI 层做成 Web UI，或者只替换工具集做成垂直领域的 agent。

二次开发前建议先通读 pi 的源码，理解它的 loop 实现、工具注册机制、配置系统。然后从最小的改动开始——比如加一个自定义工具，跑通了再动更大的部分。直接大改容易迷失在代码里。

8. 关于 pi 这类工具的一点个人判断

用了一段时间 pi，我最大的感受是：这类 coding agent CLI 的价值不在于"替代程序员"，而在于"把程序员从上下文切换里解放出来"。你想想，一天工作里有多少时间花在"打开文件、找到位置、改一行、切到终端、跑一下、切回来"这种琐碎循环上？pi 这类工具把这些循环自动化了，你只需要描述意图，剩下的它来跑。省下来的注意力，可以放在真正需要思考的地方。

但也要清醒：agent 不是万能的。它擅长的是有明确模式、有清晰验收标准的任务，比如批量替换、格式转换、按模板生成。它不擅长的是需要深层领域判断、需要权衡取舍、需要创造性设计的任务。把合适的任务交给它，不合适的自己来，这才是正确的用法。

pi 的命名我很喜欢——像圆周率一样，是个基础常数。它不花哨，不喧宾夺主，就是安安静静地待在终端里，你需要的时候拉起来用一下。这种工具哲学，比那些恨不得接管你整个工作流的"全能平台"要克制得多，也实用得多。我后续还会继续折腾它的自定义工具和多 agent 编排，有新发现再分享。