纸白微明，未成篇章。
本文侧重错误治理。完整的资料准备、分块、Embedding、BM25、重排和 GraphRAG，可以先读 RAG 概念专题；整个系列入口是 Ai Agent概念扫盲。 大模型最麻烦的时刻，不是它说不知道。 而是它给出一个语气笃定、结构完整、甚至带着出处的答案，等你真的去查，才发现内容根本不存在。 这种现象通常被叫作幻觉。 模型不是在主观撒谎。它的核心任务是根据上下文预测接下来最可能出现的内容。当可
这篇可以接着 Ai Agent概念扫盲 阅读。想把 ACP、A2A、LSP 和 Code Mode 一起弄清楚，可以看 工具与协议专题。 最近看 Agent 相关的项目，经常会同时碰到三个词，Function Calling、MCP 和 Skill。 它们看起来都和「让模型做事」有关，于是很容易混在一起。有人把 MCP 当成更高级的 Function Calling，也有人觉得有了 Skill 就
做混合检索时，会碰到一个很朴素的问题。 BM25 说某篇文档得了 18.6 分，向量检索说另一篇文档的相似度是 0.83。到底谁应该排在前面？ 18.6 看起来比 0.83 大得多，但这两个数字根本不在同一把尺子上。直接相加没有意义，随手归一化又会受到查询、模型和数据分布影响。 RRF 提供了一个很省心的思路。 既然各路分数不好比较，那就不比较分数，只比较排名。 为什么混合检索需要结果融合 关键词
Kimi K3 的技术博客里，有一个很容易被忽略、但很关键的细节： K3 对「思考历史」极度敏感。harness 如果没有完整传回之前的 thinking 内容，生成质量会严重不稳定。 原文大致写了两个触发条件： 1. harness 没有完整回传历史 thinking 内容 2. 会话中途从别的模型切换到 K3 博客对原因也做了解释。大多数 reasoning 模型，比如 Claude 的 ex
AIO BIO NIO区别？ BIO（同步阻塞 I/O） BIO 是传统的 I/O 模式，全称为 Block I/O，也叫同步阻塞 I/O。在 BIO 模式下，当我们执行 I/O 操作时，比如读取文件或者网络请求，程序会 阻塞，直到 I/O 操作完成后，才能继续执行后面的代码。也就是说，当一个线程在等待 I/O 完成时，它是处于阻塞状态的，不能做其他事情。 NIO（同步非阻塞 I/O） 一个线程管
在 Pi Agent 的工具系统中，工具的抽象和执行机制是整个架构的核心。本文系统梳理工具定义的三层类型、调用时的五步管道、并行执行策略，以及错误处理的特殊设计。 一、三层类型：为什么”一个工具”要分三层来定义？ 在 Pi Agent 里，一个完整的工具定义被拆成了三层，目的是让不同层职责清晰、扩展性强： 第一层：Tool（一张”名片”） 这是最基础的一层，只定义工具的基本信息： - toolNa
在 Pi Agent 的工具系统中，Operations 抽象 是核心设计之一。它把工具的执行逻辑与具体文件系统实现解耦，让 Agent 可以在本地、SSH、Docker 等不同环境中灵活切换。 本文主要分享工具架构的核心设计思路，包括抽象接口、依赖注入、闭包固定实例，以及 Workspace 切换机制。 为什么不直接使用 Node.js fs？ 很多人第一反应是直接调用 ： 这种写法存在几个明显
Pi Agent 给人的一个错觉是，它好像记得整个项目。 你让它读文件、跑测试、修改实现，再回头问它为什么这样改，它通常还能接上前面的工作。但打开源码会发现，Pi 并没有给模型一块无限记忆。每次调用模型之前，它都会从会话、工具结果、项目规则和当前输入里，重新裁出一份可以发送的消息。 所以真正值得研究的问题不是模型能记住多少，而是这一轮请求发出之前，Pi 决定让模型看到什么，又把什么留在了上下文之外
一、引子：大模型的三种用法 在聊 Agent Loop 之前，我们先退一步，看看”使用大模型”这件事本身有几种模式。这对理解”为什么需要循环”至关重要。 模式 1：直接调用 —— “模型，回答我” 最原始、最直觉的用法。你构建好提示词，调用一次 API，拿到结果，完事。 核心工作在于”构建提示词” 。提示词写得好，结果就好。一次调用，一次输出，没有来回。 适用场景：翻译、摘要、问答、代码补全——凡
最近 GPT-6.1 Sol 实在是有点慢，想着既然要等那么久，不如换 Kimi 试试，刚好搭配 Kimi Code 用了一下。 用的过程中发现，Kimi Code 的 设计和 Codex 不太一样。 Codex 主要采用 ，让模型通过 Patch 描述文件修改；而 Kimi Code 用的是传统的 字符串替换。 另外还有一个让我感兴趣的设计：Codex 在 GPT-6 Astra 上就已经使用