风过空庭，字句正徐来。
4 篇文稿
今天看到了 Claude 的一篇文章，介绍重新设计后的 Claude Code Projects。 我觉得这个功能挺有意思：它在 Claude Code Session 之上增加了一个项目级 Coordinator（协调 Agent），用统一的项目对话来管理多个独立的 Claude Code Session。 用户只需要在一个对话框里持续提出需求，Coordinator 就可以根据任务情况创建或复
Pi Agent 给人的一个错觉是，它好像记得整个项目。 你让它读文件、跑测试、修改实现，再回头问它为什么这样改，它通常还能接上前面的工作。但打开源码会发现，Pi 并没有给模型一块无限记忆。每次调用模型之前，它都会从会话、工具结果、项目规则和当前输入里，重新裁出一份可以发送的消息。 所以真正值得研究的问题不是模型能记住多少，而是这一轮请求发出之前，Pi 决定让模型看到什么，又把什么留在了上下文之外
在 Pi Agent 的工具系统中，工具的抽象和执行机制是整个架构的核心。本文系统梳理工具定义的三层类型、调用时的五步管道、并行执行策略，以及错误处理的特殊设计。 一、三层类型：为什么”一个工具”要分三层来定义？ 在 Pi Agent 里，一个完整的工具定义被拆成了三层，目的是让不同层职责清晰、扩展性强： 第一层：Tool（一张”名片”） 这是最基础的一层，只定义工具的基本信息： - toolNa
在 Pi Agent 的工具系统中，Operations 抽象 是核心设计之一。它把工具的执行逻辑与具体文件系统实现解耦，让 Agent 可以在本地、SSH、Docker 等不同环境中灵活切换。 本文主要分享工具架构的核心设计思路，包括抽象接口、依赖注入、闭包固定实例，以及 Workspace 切换机制。 为什么不直接使用 Node.js fs？ 很多人第一反应是直接调用 ： 这种写法存在几个明显