夜退星沉，此页初醒。
17 篇文稿
从分层记忆、事实抽取与语义召回，到每日 Sleep 的去重、合并与并发保护，聊聊 Biny Agent 记忆系统的设计与边界。
按术语逐项解释 Skill、MCP、ACP、Code Mode、RAG、Memory、Harness 等 Agent 概念，每项附对应专题入口。
模型是什么，Token 怎么数，Inference 和 Reasoning 为什么都叫推理，以及 Prompt、RAG 和微调分别改变了什么。
用一次代码审查串起工具调用、结构化输出、Skill、工具发现、MCP、ACP、A2A、LSP 和程序化编排。
Agent 怎样根据反馈行动，任务状态存在哪里，断连和恢复有什么区别，以及为什么超时后不能盲目重试。
保存的信息怎样进入模型，历史、状态、记忆和缓存有什么区别，长对话怎样压缩，以及记忆怎样更新和遗忘。
用一次报销文档查询，串起资料解析、分块、索引、召回、融合、重排、证据组织、RAG 进阶与分层评测。
多 Agent 怎样分工、交接和汇总，编码工具怎样观察与修改代码，浏览器和电脑操作怎样确认真正成功。
区分八类缓存，解释命中与上下文的关系，再用 Logs、Metrics、Trace 和延迟指标找出时间花在哪里。
区分认证、授权、单次批准和沙箱，说明外部资料为何不能授予权限，再把任务验收、测试、评测和发布术语串起来。
今天看到了 Claude 的一篇文章，介绍重新设计后的 Claude Code Projects。 我觉得这个功能挺有意思：它在 Claude Code Session 之上增加了一个项目级 Coordinator（协调 Agent），用统一的项目对话来管理多个独立的 Claude Code Session。 用户只需要在一个对话框里持续提出需求，Coordinator 就可以根据任务情况创建或复
一、引子：大模型的三种用法 在聊 Agent Loop 之前，我们先退一步，看看”使用大模型”这件事本身有几种模式。这对理解”为什么需要循环”至关重要。 模式 1：直接调用 —— “模型，回答我” 最原始、最直觉的用法。你构建好提示词，调用一次 API，拿到结果，完事。 核心工作在于”构建提示词” 。提示词写得好，结果就好。一次调用，一次输出，没有来回。 适用场景：翻译、摘要、问答、代码补全——凡
Pi Agent 给人的一个错觉是，它好像记得整个项目。 你让它读文件、跑测试、修改实现，再回头问它为什么这样改，它通常还能接上前面的工作。但打开源码会发现，Pi 并没有给模型一块无限记忆。每次调用模型之前，它都会从会话、工具结果、项目规则和当前输入里，重新裁出一份可以发送的消息。 所以真正值得研究的问题不是模型能记住多少，而是这一轮请求发出之前，Pi 决定让模型看到什么，又把什么留在了上下文之外
在 Pi Agent 的工具系统中，工具的抽象和执行机制是整个架构的核心。本文系统梳理工具定义的三层类型、调用时的五步管道、并行执行策略，以及错误处理的特殊设计。 一、三层类型：为什么”一个工具”要分三层来定义？ 在 Pi Agent 里，一个完整的工具定义被拆成了三层，目的是让不同层职责清晰、扩展性强： 第一层：Tool（一张”名片”） 这是最基础的一层，只定义工具的基本信息： - toolNa
在 Pi Agent 的工具系统中，Operations 抽象 是核心设计之一。它把工具的执行逻辑与具体文件系统实现解耦，让 Agent 可以在本地、SSH、Docker 等不同环境中灵活切换。 本文主要分享工具架构的核心设计思路，包括抽象接口、依赖注入、闭包固定实例，以及 Workspace 切换机制。 为什么不直接使用 Node.js fs？ 很多人第一反应是直接调用 ： 这种写法存在几个明显
Kimi K3 的技术博客里，有一个很容易被忽略、但很关键的细节： K3 对「思考历史」极度敏感。harness 如果没有完整传回之前的 thinking 内容，生成质量会严重不稳定。 原文大致写了两个触发条件： 1. harness 没有完整回传历史 thinking 内容 2. 会话中途从别的模型切换到 K3 博客对原因也做了解释。大多数 reasoning 模型，比如 Claude 的 ex
这篇可以接着 Ai Agent概念扫盲 阅读。想把 ACP、A2A、LSP 和 Code Mode 一起弄清楚，可以看 工具与协议专题。 最近看 Agent 相关的项目，经常会同时碰到三个词，Function Calling、MCP 和 Skill。 它们看起来都和「让模型做事」有关，于是很容易混在一起。有人把 MCP 当成更高级的 Function Calling，也有人觉得有了 Skill 就