Pi

参考 Pi 的精简 Agent 核心、扩展包与基础库，设计适合自己的工作流。区分哪些问题可以通过任务说明解决，哪些需要运行层定制，以及执行环境应提供哪些边界。

关于 Pi

Pi 明确将自己定位为精简、可扩展的 Agent Harness。项目把交互式编程 Agent 与模型访问、Agent 执行、对话状态和终端界面等基础库放在一起，既能作为工具使用，也能为其他应用提供构建模块。

Pi 适合作为“精简核心、按需增加能力”的设计参考。围绕 Floatboat 的工作，可以用它区分可复用任务说明、新工具和运行层行为：部分优化只需更好的 Skills，另一些才值得评估扩展或基础库。

当前仓库为 earendil-works/pi，原地址为 badlogic/pi-mono，采用 MIT 许可。项目也明确说明自身没有限制文件、进程、网络和凭证访问的内置权限系统；所需隔离边界应由实际运行环境提供。

先理解项目展示了什么机制，再判断它能解决自己工作流中的哪个具体问题。

将这些场景作为 Floatboat 中任务设计的参考；具体软件接入仍需单独核对兼容性与权限。

围绕上下文、工具执行和结果审阅设计集中流程，不从庞大功能集合开始。

在引入新的可执行扩展前，先判断任务是否只需要更清晰的说明与参考资料。

当业务流程需要自己的模型接口或执行方式时，以基础库结构作为研究参考。

从具体任务和可验证的小改动开始，判断需要优化说明、连接工具，还是复用运行组件。

Pi 官方是否将自己称为 harness？

是。README 明确将 Pi 称为精简、可扩展的 Agent Harness，同时提供编程 CLI 和可复用基础库，范围不止一个终端界面。

为什么旧资料使用 badlogic/pi-mono？

那是旧仓库地址，目前会转向 earendil-works/pi。归属与文档应以当前上游为准，复用旧资料前也要确认包名和接口是否变化。

Pi 是否自带权限沙箱？

README 说明 Pi 没有用于限制文件、进程、网络和凭证访问的内置权限系统。需要的隔离应由环境提供，不能假定所有 harness 都自带沙箱。

子 Agent 和规划模式默认就有吗？

项目有意不将这类能力作为核心默认功能。扩展或包可以补充，是否可用取决于所选扩展、包和会话配置。

Skill 与扩展在 Pi 中有什么区别？

Skill 提供可复用的任务说明与资料，扩展则通过扩展机制改变或增加工具行为。两者可以配合，但执行方式与信任边界不同。

借鉴这些机制是否需要更换工作工具？

不需要。可以先将 Pi 作为任务结构、工具边界和结果审阅的设计参考，在已有工作流中验证思路。软件复用是另一项选择，需要核对兼容性、权限与许可；借鉴设计思路不会自动完成软件与 Floatboat 的连接。