这篇写什么 目标是建立一个稳定的全局理解框架：pi-mono 最核心的四层分别负责什么，以及一条“用户发一句话”会如何穿过这些层。 先记住四层 用最短的图记住： 第 4 层：pi-tui 第 3 层：pi-coding-agent 第 2 层：pi-agent-core 第 1 层：pi-ai 换个方向理解： 模型能力 -> agent 运行时 -> coding 产品 -> terminal 界面 一句话总结 pi-mono 的核心，是把大模型能力一步步落成一个能在终端里工作的编程代理： 统一模型调用 -> 让模型调用工具并循环工作 -> 做成面向编程场景的产品
这是一组由源码阅读笔记整理出的博客草稿，尽量只基于原笔记内容做删减、合并与结构化，不额外虚构实现细节。 阅读顺序（建议） 1. 从零建立全局认识：四层架构是什么 2. pi-ai：统一模型调用这一层到底解决了什么 3. pi-ai：输入输出与事件流（为什么对 agent 友好） 4. pi-agent-core：为什么 tool calling 不等于 agent 5. pi-agent-core：闭环、回灌、继续/停止策略 6. pi-coding-agent：把前两层装配成“可用产品” 7. 主 Agent 与 Tools：可迁移的设计方法论 8. 其余包扫盲：tui / web-ui / mom / pods 文章列表（发布用链接待填） * 01｜
背景：一次从 SQLite 到 PostgreSQL 的 Open WebUI 搬迁 Open WebUI 默认用的是 SQLite，部署起来很省心。但当你开始把它跑在更“正式”的环境里（多用户、长期保留聊天记录、附件和标签等），SQLite 往往就会成为瓶颈：备份、迁移、并发、运维手段都不如 PostgreSQL 顺手。 这篇文章记录我把一套旧版 Open WebUI（SQLite）迁移到新版 Open WebUI v0.8.11（PostgreSQL 16）的完整过程。核心目标很明确： * 保留多用户登录信息 * 保留历史聊天、消息、标签、文件等业务数据 * 新环境使用 Docker Compose，
https://github.com/jlowin/fastmcp 这篇文章是我学习 FastMCP 的一次系统整理：从 MCP 到 FastMCP 的组件设计，再到 Provider、Transform、Context、任务与部署方式。目标是把零散笔记变成一条能走通的理解路径。 1. 我先把 MCP 讲清楚：它解决的到底是什么问题？ 很多时候 AI “会想”，但它不会“做”。 * 想查数据库 * 想调用内部 API * 想发邮件或写文件 如果没有一套标准的协议，AI 客户端（Claude、Cursor 等）就很难稳定、安全、可扩展地调用你提供的能力。 MCP（Model Context Protocol）就是这套标准协议： * 客户端用统一的方式发起调用请求 * 服务器用统一的方式暴露工具、资源和提示词
陕公网安备61011302002223号