2026-07-28 是截至 2026 年 8 月 MCP 的最新稳定规范。这次更新不是给旧协议添几个字段，而是重新划分了连接、状态和双向交互的边界：MCP 不再依赖连接级 Session 和初始化握手，每个请求都要带齐版本与能力信息。

如果你已经读过《MCP 协议简要介绍》，这篇可以当作更新补丁。旧版的 Host、Client、Server 以及 Tools、Resources、Prompts 仍然成立，但生命周期、服务端反向请求和 Streamable HTTP 的工作方式已经变了。

本文脉络：

• 一、先说版本：最新稳定版是 2026-07-28
• 二、这次更新到底改了什么
• 三、变化一：删除连接级 Session，协议转向无状态
• 四、变化二：用 server/discover 取代初始化握手
• 五、变化三：MRTR 取代服务端主动请求
• 六、变化四：统一订阅与通知通道
• 七、变化五：列表与读取结果支持标准缓存语义
• 八、变化六：Tasks 从实验能力变成官方扩展
• 九、哪些功能被弃用了
• 十、安全、Schema 与可观测性变化
• 十一、如何从旧版迁移
• 十二、常见问题

Agent Graph 不是“把几个 Agent 画在一张图上”，而是把一次智能任务明确建模成：状态在节点之间流动，边根据结果决定下一步，直到任务完成或被安全终止。

它解决的核心问题也不是让模型变聪明，而是让原本藏在 Prompt 和循环里的执行逻辑变得可见、可控、可恢复。

本文脉络：

• 一、为什么需要 Agent Graph
• 二、Agent Graph 到底是什么
• 三、四个核心元素：节点、边、状态、运行时
• 四、一个客服 Agent Graph 是怎么运行的
• 五、它与 Agent Loop、DAG、多智能体有什么区别
• 六、Agent Graph 真正带来了什么
• 七、什么时候值得用，什么时候别用
• 八、怎样设计一张靠谱的 Agent Graph
• 九、常见陷阱
• 十、常见问题

Pi Agent 的记忆机制更像一套上下文管理系统：完整历史保存在会话树里，当前模型只看到被挑选、压缩、转换后的上下文。

换句话说，Pi 的 memory 不是“模型自己记住了什么”，而是 Pi 在每次调用模型前，决定把哪些历史、规则、工具结果、摘要和动态上下文放到这一次请求里。

本文脉络：
  一    Pi Agent Memory 的五层结构
  二    工作记忆：当前 Context
  三    情景记忆：JSONL Session Tree
  四    摘要记忆：Compaction
  五    程序性记忆：AGENTS、Skills 与 Prompt Templates
  六    可插拔记忆：Extension context hook
  七    一次调用前，Memory 如何变成 Context
  八    Pi 这套设计的取舍
  九    常见问题

用户在 iPad 上离线写了三页笔记，同时又在 Mac 上改了标题、移动了页面。两台设备重新联网后，服务端应该接收什么、客户端应该拉什么，数据库又该存哪些字段，才能既不丢数据又不把整份文档反复上传？

这是 Goodnotes 类产品很典型的一道后端系统设计题。真正的难点不在 WebSocket，而在三个地方：同步粒度、增量日志和冲突语义。本文按面试推导顺序，把表结构、Push/Pull 协议、离线恢复、幂等和冲突解决串成一套可落地的设计。

本文脉络：
  一    先问清楚题目：到底要同步什么
  二    核心判断：同步操作，不同步整篇文档
  三    系统架构与数据分层
  四    数据库字段怎么设计
  五    正常在线时的 Push / Pull 协议
  六    设备离线后重新上线，完整流程是什么
  七    两台设备同时修改，冲突怎么解决
  八    删除、乱序、重复请求这些坑怎么处理
  九    全量同步、增量日志清理与扩展性
  十    面试时如何把这套方案讲清楚
  十一  常见问题

Skill 上线不是终点，而是它第一次接触真实任务的开始。真正难的工作不是把 SKILL.md 写出来，而是持续回答三个问题：它有没有被正确触发、有没有按预期执行、改完之后有没有伤到旧场景。

本文是「AI Agent 技能（Skill）实战解析」的后续。上一篇讲怎么设计和编写 Skill，这一篇只谈上线之后：如何收集反馈、定位失败、建立评测、管理版本，以及在必要时安全地下线一个 Skill。

本文脉络：
  一    为什么 Skill 上线后一定会变
  二    先把失败分对类
  三    建立最小可用的反馈闭环
  四    用评测集守住质量底线
  五    版本管理：什么改动算破坏性变更
  六    发布策略：从本地验证到灰度上线
  七    依赖、兼容性与安全维护
  八    什么时候应该拆分、合并或退役
  九    一套可执行的维护节奏
  十    常见问题

写 Pi Agent Extension 时，真正容易卡住的不是 pi.on(...) 怎么写，而是“不知道该监听哪个事件”。同样是想加一条规则，有时应该拦 tool_call，有时应该改 before_agent_start，有时只是监听 agent_end 做通知。

这篇就是一份事件速查表：按 Pi 的运行链路分组，说明每个事件什么时候触发、适合做什么、哪些事件能返回结果改变流程。

本文脉络：
  一    怎么理解 Pi 的事件系统
  二    启动和资源发现事件
  三    Session 事件
  四    Agent 和 Provider 事件
  五    Turn 和 Message 事件
  六    Tool 事件
  七    模型设置事件
  八    最常用的监听写法
  九    选择事件的经验

Pi Agent Extension 开发指南：从工具、命令到事件拦截

Pi Agent 的核心很小，默认只提供读文件、写文件、改文件和执行命令这些基础能力。真正适配个人或团队工作流的部分，主要通过 Extension 完成。

Extension 是运行在 Pi 进程内的 TypeScript 模块。它可以注册新工具，让模型调用；也可以添加斜杠命令、快捷键、状态栏、弹窗、Provider、会话事件处理器，甚至拦截内置工具调用。

这篇文章不讲 Extension 系统为什么重要，而是从使用角度说明：扩展放在哪里、怎么写、怎么调试，以及什么时候应该用 Extension 而不是 Skill 或 Prompt Template。

Pi Agent 源码分析

Pi Agent 表面上是一个终端编码助手：用户输入任务，模型读取代码、执行命令、修改文件，最后给出结果。

但从源码看，Pi 是一套分层的 Agent Harness：底层统一不同模型的流式接口，中间层维护 Agent 状态并运行模型—工具循环，上层负责会话、扩展、上下文和终端交互。

本文将回答一个根本的问题：

当用户在终端中提交一条 Prompt 后，这条消息到底经过了哪些对象、函数和数据结构，最终如何驱动模型完成一系列真实操作？

mattpocock/skills 发布了 v1.1.0。本次更新重组了规划流程，加入 wayfinder 和 research，并调整了 grilling、tdd、code-review 等技能。

本文是「MattPocock Skills：给真实工程师的 AI Agent 工作流」的后续，主要介绍 v1.1.0 相比上一篇文章发生了哪些变化。

很多 Agent 看起来“不靠谱”，不一定是模型太弱。更常见的问题是：模型外面没有一套足够稳的执行框架。它不知道什么时候该停，不知道结果怎么验证，不知道登录这种确定性流程该交给代码处理，也不知道失败后怎么收尾。

这套包在模型外面的执行框架，可以叫 Harness。一句话说，模型像大脑，Harness 像身体和神经系统：模型负责理解和判断，Harness 负责工具、状态、循环、护栏、验证和真实世界里的异常流程。

本文脉络：

• 一、为什么需要 Harness
• 二、什么是 Agent Harness
• 三、用“知乎点赞”看一个裸 Agent 会怎么失败
• 四、第一层：工具注册表，先让 Agent 有手
• 五、第二层：Agent Loop，让任务一轮轮推进
• 六、第三层：上下文管理，别让历史把 Agent 淹没
• 七、第四层：护栏，让失败在可控范围内结束
• 八、第五层：验证步骤，不要只听模型说“完成了”
• 九、第六层：确定性接管，不是什么都该让模型做
• 十、可观测性：每一步都要能复盘
• 十一、常见问题