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｜
陕公网安备61011302002223号