agent
这篇写什么 补齐主链路之外的包：tui、web-ui、mom、pods。它们不是前两层核心抽象，但决定了这套体系如何被真正使用、展示和部署。 快速定位 * tui：终端 UI 引擎（输入、渲染、选择器、弹层等体验基础设施） * web-ui：Web 场景的 chat/agent UI 组件库 * mom：Slack 里的 agent bot 产品 * pods：远程 GPU pod 上的模型部署与运行管理 packages/tui 它不参与模型调用和 agent loop，但决定 terminal 产品是否“像一个真正应用”而不是 stdout 脚本。 packages/web-ui
agent
这篇写什么 把两份偏方法论的笔记（主 Agent 设计、Tools 设计）合并成一篇：给出一套可迁移、可施工的 agent 产品设计方法，不依赖编程场景。 主 Agent：先设计任务闭环，不要先写 prompt 主 agent 不是“一个大 prompt”，而是：任务边界、角色定义、行为规则与闭环运行方式的组合。 一个可用的主 agent，首先要回答： * 核心目标是什么 * 完成标准是什么 * 默认怎么推进 * 何时继续、何时停止 * 遇到失败怎么处理 提示词只是这些设计的表达载体，不是起点。 主 Agent 的设计骨架（建议写清楚） * 目标定义 * 输入定义（用户通常怎么提任务） * 输出定义（你最终返回什么形态） * 完成条件与停止条件 * 默认策略（模糊时问还是猜、
agent
这篇写什么 讨论 packages/coding-agent 这一层如何把 pi-ai 与 pi-agent-core 装配成一个面向编程场景的真实产品：它关心 session、默认工具集、动态 prompt、扩展点，而不只是抽象。 先说结论 pi-coding-agent 的定位更准确地说是：面向编程场景的 agent 产品装配层。如果前两层分别是：pi-ai：统一模型调用pi-agent-core：统一 agent loop那么第三层做的是：把模型、runtime、prompt、tools、session、settings、extensions 与交互模式一起装配成一个终端里的 coding product。 为什么第三层才开始真正绑定编程场景 前两层更通用；第三层必须选择一个明确落点。这里的落点非常清晰：代码仓库工作流。默认工具集（read/write/edit/bash）就是最直接的场景宣言。 第三层的中心：
agent
这篇写什么 聚焦 pi-agent-core 最关键的运行机制：tool loop（闭环）与工具结果回灌，以及 runtime 如何决定“继续下一轮还是结束”。 先说结论：tool loop 才是 agent pi-agent-core 的核心不是“支持 tool calling”，而是把 tool calling 变成 tool loop： 模型提出工具调用 -> runtime 执行工具 -> 工具返回结果 -> 结果回灌上下文 -> 再次调用模型 -> 判断是否继续 只要这条链路成立，系统才真正像 agent；否则只是“会发工具意图的聊天模型”
agent
这篇写什么 只讲一个关键点：为什么“模型会吐 tool call”不等于“系统是 agent”，以及 pi-agent-core 这一层到底补上了什么。 先说结论 pi-agent-core 的本质不是“再包一层模型调用”，而是：把一次模型调用变成一个可以持续推进任务的运行时闭环。 * pi-ai 解决：怎么把不同模型统一接起来 * pi-agent-core 解决：怎么让模型不只是回答，而是真正持续工作 为什么第一层还不够 如果系统只有模型抽象层，能力更接近： * 把上下文发给模型 * 接收模型返回 * 把流式输出展示出来 即便模型支持 tool calling，这时也还没有“agent 感”。 因为“模型会吐出 tool call”不等于“系统能把任务做完”。 用户真正感知到的 agent 能力通常是： * 它会自己去查信息 * 它会自己调用工具 * 它会根据结果继续下一步 * 它不是一轮问答，
agent
这篇写什么 聚焦 pi-ai 的统一输入输出协议：为什么要把输出分成“事件流”和“最终消息”，以及为什么“可重放性”是 agent 系统的关键约束。 先说结论 pi-ai 的核心价值是：把多厂商模型调用统一成一套对 agent 友好的输入输出协议。 对 agent 友好意味着它要覆盖： * 多轮上下文 * 工具调用 * 流式增量输出 * thinking/reasoning * usage/cost * 失败与中断 * 跨模型继续对话 统一输入：上层真正需要表达的只有四类 1. 用哪个模型 2. 当前上下文是什么 3. 这轮可以用哪些工具 4. 这轮调用的运行参数是什么 模型输入不是字符串 模型对象应携带能力与调用语义：provider、协议类型、上下文窗口、是否支持 reasoning/多模态、成本与兼容配置等。
agent
这篇写什么 只讲 packages/ai（pi-ai）的设计动机与职责边界：它到底统一了什么、为什么对 agent 很关键、它和 pi-agent-core 的分工是什么。 先说结论 pi-ai 的本质不是“又一个模型 SDK”，而是：一个面向 agent 场景的多模型统一抽象层。 它的目标是把不同厂商、不同协议、不同风格的大模型调用方式，收敛成一套统一输入输出标准，让上层系统稳定工作。 为什么值得单独做一层 如果没有这一层，上层会直接面对： * 不同厂商的 API 结构、消息格式、流式协议差异 * tool calling 表达差异 * reasoning/thinking 支持差异 * usage / cost 统计差异 最终会导致： * agent 层被 provider 细节污染 * 每加一个
agent
这篇写什么 目标是建立一个稳定的全局理解框架：pi-mono 最核心的四层分别负责什么，以及一条“用户发一句话”会如何穿过这些层。 先记住四层 用最短的图记住： 第 4 层：pi-tui 第 3 层：pi-coding-agent 第 2 层：pi-agent-core 第 1 层：pi-ai 换个方向理解： 模型能力 -> agent 运行时 -> coding 产品 -> terminal 界面 一句话总结 pi-mono 的核心，是把大模型能力一步步落成一个能在终端里工作的编程代理： 统一模型调用 -> 让模型调用工具并循环工作 -> 做成面向编程场景的产品
agent
这是一组由源码阅读笔记整理出的博客草稿，尽量只基于原笔记内容做删减、合并与结构化，不额外虚构实现细节。 阅读顺序（建议） 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｜
MCP
https://github.com/jlowin/fastmcp 这篇文章是我学习 FastMCP 的一次系统整理：从 MCP 到 FastMCP 的组件设计，再到 Provider、Transform、Context、任务与部署方式。目标是把零散笔记变成一条能走通的理解路径。 1. 我先把 MCP 讲清楚：它解决的到底是什么问题？ 很多时候 AI “会想”，但它不会“做”。 * 想查数据库 * 想调用内部 API * 想发邮件或写文件 如果没有一套标准的协议，AI 客户端（Claude、Cursor 等）就很难稳定、安全、可扩展地调用你提供的能力。 MCP（Model Context Protocol）就是这套标准协议： * 客户端用统一的方式发起调用请求 * 服务器用统一的方式暴露工具、资源和提示词