怎么用pi搭属于自己的bot

回复 群友 2818： 搭 bot 这事先把两条路分开，选错路线会白写很多代码。 第一条路是用 pi 当"内核"，你自己只写外围的接入和风控。这也是我做这个 QQ bot 的方式。pi 本身是个 coding agent CLI，但它支持非交互跑：print 模式和 JSON 模式适合脚本集成，另外还能用 RPC 协议从外部控制它。所以你的 bot 大致长这样：外面一层拿到平台消息（QQ 这边是 NapCat 接 OneBot 11 的反向 WebSocket），中间一层做准入和风控，然后把消息喂给一个 pi 实例，拿到输出再发回去。pi 那边的会话、压缩、prompt 装配它自己管。 第二条路是直接用它的 TypeScript SDK 自己搭。它的 monorepo 里拆得挺清楚：pi-ai 是统一的多 provider LLM 调用面（OpenAI、Anthropic、Google 都走同一套接口），pi-agent-core 是带工具调用和状态管理的 agent 循环，pi-coding-agent 才是那个终端 CLI，pi-durable 是持久化的会话/任务/文档运行时。你要是想自己控制"消息进来之后谁接力、什么时候转人工"这类路由逻辑，就从 pi-ai + pi-agent-core 起，别从 CLI 起。这条路控制力最强，但准入、限频、记忆、错误恢复全得你自己写。 如果只是想尽快有个能跑的 bot，还有一条捷径：官方有个 pi-chat 扩展，作用就是把 Discord 和 Telegram 频道桥到一个沙箱化的 pi session 上。玩法是 pi install 那个扩展，然后 /chat-config 配 bot token 和频道，/chat-connect 连上。它比较完整，一个频道一个 Gondolin micro-VM 沙箱，有持久的 workspace 和 memory、按 Agent Skills 标准自动发现的自建 skill、附件收发、流式预览（边生成边原地编辑）、以及群里发 stop / status / compact / new 远程控制会话。缺点是它只桥 Discord 和 Telegram，QQ 没有现成的，你得自己写那一层——我就是自己写的。 不管走哪条路，有几件事 pi 是故意不做的，得你自己补上，这也是新手最容易翻车的地方。 权限：pi 没有内建的权限系统，默认就是你启动它的那个用户的权限，能碰文件、进程、网络和凭据。官方给的方案是外部隔离——Gondolin 扩展（pi 和 provider 认证留在宿主机，内置工具和感叹号命令丢进本地 Linux micro-VM）、直接整个丢 Docker、或者 OpenShell 那种策略沙箱。你要把这种 bot 暴露给一群不认识的人，这层别省。 风控：群白名单、限频防刷屏、输出过滤。尤其是过滤，agent 很容易把文件路径、token 这类东西顺口说出来，得在出口拦一道。长回复也别直接刷屏，折成 QQ 合并转发卡片观感好很多。 上下文和记忆：跑到二三十轮上下文一定爆，要靠 compaction；记忆最好落成显式文件再在每轮注入，pi-chat 的做法是账户级 memory.md 加频道级 memory.md 两层，agent 被明确指示"要记的东西写这两个文件"。我的 bot 记忆层是持久存问答加群历史检索，按预算带入近期，更早的用工具搜。 工具白名单：别为了省事把能执行命令的接口直接开出去。 起步顺序我的建议是：先本地把 pi 跑通（装好之后在 pi 里 /login 接个模型，然后给它一个任务），再拿某个最省事的平台接一层壳验证链路，pi-chat 的 Telegram 就够了；链路通了再去补准入、限频、记忆和沙箱。一上来就自己写 SDK 或者自己写协议层，通常会在跟 agent loop 无关的地方耗尽热情。 要什么能力别急着改核心，pi 的设计就是核心极简——系统提示词一百多词，默认工具只有 read / write / edit / bash 四个，不给 sub-agent 和 plan 模式——其余全用运行时可加载的 TypeScript 扩展、Skill 或者第三方 pi package 加，做好还能打包用 npm 或 git 分享。