「Agent 为什么都用 fetch + ReadableStream 读流？EventSource 不是也能收 SSE 吗？」

这个问题问得对，但流传的答案「大厂从 SSE 换成了 ReadableStream」说得不准。真实情况是：

EventSource 是浏览器内置的 SSE 客户端，它在「打开一个 URL、持续收通知」这件事上是满分答案。但 Agent 场景需要的几件事——发 POST、带请求头、看状态码——它一件也做不到，重连语义也完全不由你控制。于是大家保留了 SSE 的帧格式，只把「读它的那只手」换成了 fetch + ReadableStream。

这篇按这条线讲透：① EventSource 到底是什么 → ② 为什么 Agent 场景要换掉它 → ③ 换成 fetch + ReadableStream 之后怎么写（含可跑的最小实现）→ ④ 流式端点的三个生产雷区 → ⑤ 这套也不够用时，什么时候必须上 WebSocket / WebRTC。

正文的实测都在本机 Node 上跑出来，脚本随仓库留档在 source/stream-lab/。

上一篇 开源 RAG 知识库横评 解决的是「底座用什么」。这篇往上走一层：底座之上，哪些 Agent 场景真的能赚钱。

这篇做四件事：先给一把判断「高 ROI」的尺子（厂商数字有三个系统性偏差）→ 深挖智能客服（含那个被反复引用的「76% 解决率」到底怎么回事）→ 深挖商业尽调（真实账本 + 一条不能碰的合规红线）→ 另外 8 个场景的落地水位表。

文中数字分三级标注：[已核实]（直接读到原始文件/论文/采购公示）、[二手]（权威第三方转述）、[厂商自述]（厂商官网或案例页，无第三方验证）。标 [厂商自述] 的数字请勿当作 ROI 证据使用——这篇的大半篇幅其实是在解释为什么。

舱壁模式原理极简，属于 “知道了就觉得理所当然” 的知识；但它属于典型的「简单但极易被忽略」的稳定性手段。 就像保险丝，原理一点不复杂，但是不装，电路一过载就烧设备。

很多稳定性模式都是这个味道：思想朴素，价值巨大，难在主动落地，而不是理解。

舱壁（Bulkhead）来自造船：把船体隔成若干水密舱，一个舱进水，船不沉。搬到软件里，它只有一句话——**给资源划边界：让 A 的故障、拥堵、突发，物理上占不到 B 的资源。**但这句话在 Node.js 里的落点和 Java 生态很不一样。Java 谈舱壁，默认是「线程池隔离」（Hystrix 那套）；Node 是单线程的，所以除了连接池，你还得隔离「事件循环」本身——一个 JSON.parse 大字符串或一次同步循环，就能把整个进程的所有接口一起拖下水。

这篇把 Node 里的四道舱壁逐个落成代码 + 本机实测。四组实验的效果都很干净（最夸张的一组是 1416 ms → 2.3 ms）

上一篇聊了 RAG 的现状与那条「像素方案」，那是「技术面」。这篇落到选型：中小企业想私有一部署一套 RAG 知识库，市面上这十几个开源项目到底怎么挑。

这篇做四件事：先把它们分类（它们根本不在一个赛道）→ 逐家拆解（含停更避坑区）→ 一张实测横评表 → 三个必须读 LICENSE 原文的坑。文中的 star 数、协议原文、最新版本、容器数全部是 2026-09-19 用 GitHub API 与 docker-compose 原文实测，不是二手转述；一手核不到的地方我直接标注「未证实」。

一句话先给结论：要编排能力 → Dify；要文档解析精度 → RAGFlow；要最省运维 → MaxKB；要开箱即用 → AnythingLLM；要把知识库嵌进现有系统 → AnythingLLM / LightRAG 这类「引擎」而不是「平台」。

「我该用 LangChain 还是自己写 / 换别的？」——这是开始做 Agent 时最常见的纠结。这篇把 LangChain（JS） 和 pi-agent 摆在一起比：不是比谁的 API 漂亮，而是比它们对「Agent 应该由谁来管」这件事的答案。

为了不空谈，我给同一类任务（一个会调工具的查天气 Agent）在两边各写了一份代码并真跑起来：pi 侧用内置的 fauxProvider（不需要 key），LangChain 侧用真实模型端点（DeepSeek 的 Anthropic 兼容接口）。文中的事件序列、消息序列、最终回答都是真实输出。

版本：@earendil-works/pi-ai / pi-agent-core 0.85.1；langchain 1.5.11 / @langchain/langgraph 1.4.15（2026-09 npm 实测）。本站已有两个系列：pi-agent 系列、LangChain + LangGraph 系列。

在 LangGraph 入门 那篇里，我把 reducer 一笔带过：「(a,b)=>b 是覆盖，a.concat(b) 是追加」。但那只是两种写法，不是全部模式——真正的问题是：

同一个 key 被写入多次时，状态该怎么合？

这就是 reducer 要回答的唯一问题。这篇把它讲全：Annotation 的完整用法、reducer 的几种模式、它什么时候被调用、调用几次、以及我把每种行为都真实跑出来的结果（含两个报错，都是实测）。

声明：以下行为全部在 @langchain/langgraph 1.4.15（Node 24）跑出来的，输出是真实的。不同版本行为可能微调，以你的实际运行为准。

「单路检索不够用，要上多路」——这话现在几乎是共识。但多路到底怎么融合、路怎么选、效果怎么证明，多数文章停在「向量 + 关键词，效果更好」。

这篇想把它做实。我做了一个可复现的三通道检索实验（向量 / 关键词 / 图谱，对应语义、精确、关系三条通道），把 RRF 的公式、k 常数、加权、以及查询路由都跑了一遍，然后用准确率/召回率逐查询拆开看——结果推翻了我自己一开始的预期：

融合的收益被均值严重高估了。 在这个语料上，三路等权 RRF 的平均 nDCG 只比最好的单通道高 1.8%；而在某一类查询上，等权 RRF 反而比单独用图谱通道差了将近一半。

命名说明：你说的「RFF 算法」，业界标准名是 RRF（Reciprocal Rank Fusion，互惠排名融合），本文统一用 RRF。

「RAG 已死」这种标题这两年轮着上：先是长上下文说要取代它，后来 Agent 说要吸收它。但把噪音去掉，真实情况更像一句评价：RAG 没死，它长大了——从「一条流水线」长成了「一个分层能力」。

这篇聊四件事：传统 RAG 的结构性毛病 → 2026 年的现状与主流解法 → 一个被低估的问题（解析损失） → 最近很热的「像素方案」（视觉/像素级 RAG）到底是什么、什么时候值得用。

文中行业数据来自公开资料（论文、厂商博客、技术评测），统计口径与时点不一，已尽量标注；相关结论请以原文为准。本文也会连到本站已有的 agent / 协议系列。

用 Coze（扣子）搭智能体时，第一道选择题就是模式：单 Agent（自主规划模式） 还是 单 Agent（对话流模式）。很多人凭感觉选，然后在做的过程中反复返工——要么「流程搭得死死的，模型完全没发挥」，要么「让模型自己决定，结果它乱调工具」。

这篇把两者的底层机制差异讲清楚，并给一张选型表和几个常见坑。

先排一个术语雷：「对话流模式」是「智能体的运行模式」之一；而「对话流（Chatflow）」本身是一种「编排类型」（与「工作流 Workflow」相对）。这两个轴经常被混为一谈——本文会分别讲清，因为它们影响的是不同的选择。

内容依据 Coze 官方文档与公开资料整理，平台版本迭代快、不同版本 UI 命名有差异，具体以你所用版本的官方文档为准。

微前端绕不开 Module Federation（MF）。它和 qiankun 那类方案常被放在一起比，但两者其实抽象层级不同：qiankun 管的是「应用怎么隔离地拼在一起」，MF 管的是「模块怎么跨应用加载与共享」。

这篇不空谈：我搭了两个最小应用（host / remote），用 webpack 5.111.0 + @module-federation/enhanced 2.9.0 真跑了一遍构建，把产物、stats、manifest 全抓出来给你看——MF 这套东西「到底生成了什么」，看完就有底了。

声明：本文配置与构建产物均为本机真实运行结果（含 mf-manifest.json 原文）。运行时（浏览器里加载远程模块）未实测，涉及运行时的部分我标明了依据，不编造效果。