多Agent场景下数据读写不同步的解决方案
本文探讨了在多Agent系统中，子Agent之间数据读写不同步的问题。根本原因在于单Agent场景设计的默认数据库一致性配置（如Milvus的Bounded级别）无法满足多Agent毫秒级的读写需求。文章详细解释了Milvus的写入机制和四档一致性级别，并通过实验证明将一致性级别从默认的Bounded切换为Strong可以有效解决“写后读空”的问题。
相关文档
开源｜我给 DeepSeek Harness 接入了 Milvus
作者为爆火的 DeepSeek Harness（DSH）开发了 Milvus 向量数据库插件 dsh-milvus 并开源。文章解析了 DSH 'Everything is a Plugin' 的微内核架构价值，说明为何将 Milvus 集成做成 Plugin 而非 Skill：Plugin 可硬性限制执行边界（如只读操作、limit 上限），避免模型幻觉带来的风险。文中还给出从 Docker 启动 Milvus、安装 DSH CLI 与插件、配置 Profile 到让 Agent 完成列表、Schema 描述、Scalar Query 和语义搜索的完整实战教程。
不做中转，不卖课，如何用 AI 月入 10万
作者分享了今年通过接企业知识库项目实现月入数万的实战经验。文章详细阐述了如何将基础 RAG 升级为企业级 RAG 系统，重点涵盖数据处理层面的文档切分策略（针对 PDF、Excel、代码等）、向量化模型选择及数据库选型；同时深入讲解了检索策略优化，包括长问题处理、混合检索、Rerank 精排及多因素加权排序等技术细节。
一家大型企业有几十万份文档，究竟应该怎样交给AI？
文章结合为大型国企交付几十万份文档知识库项目的实战经验，指出将文档导入知识库只是最容易的一步，真正难点在于知识分散在OA、ERP、CRM等多个系统中、文档质量参差不齐、版本与权限管理复杂、以及上线后的持续运营。作者提出企业真正需要的不是一个'AI知识仓库'，而是一条具备知识工程能力的企业知识供应链：通过Connector持续接入知识，经解析、清洗、结构化等知识工程加工后准入，并以检索前权限过滤保障安全，最终在Agent时代构建企业上下文层，让正确的知识在正确的时间以正确的权限交给AI。
如果你想做 AI 应用不妨考虑一下 Harness 开发
作者结合实际工作经验，整理出一份 AI Harness 开发的 11 条技能清单，涵盖后端与系统设计、RAG 与向量数据库、记忆与上下文管理、工具调用与 MCP、Agent 编排、护栏校验、评测、可观测性、模型路由降级、排队负载均衡以及推理部署引擎。作者指出 Harness 开发是硅谷热门方向（如 YC Demo Day 上大量项目），建议普通开发者从 AI 应用入手，把模型接入具体业务，并给出将清单交给 AI 逐项学习的 prompt 方法。
How to Build Agent Memory: Where Does Knowledge Live?
本文是 Agent 记忆系列文章的第二篇，探讨知识的存储位置与表示形式。作者将记忆拆解为表示与存储、提取、检索、维护四个环节，重点讨论第一个问题：知识存放在哪里。文章指出表示（知识形态）与物理存储是两个独立决策，文件系统因编程代理擅长 bash 而成为极佳起点。作者提出应区分“产物”（发生过的记录）与“知识”（当前应相信的事实），知识应像物化视图一样回指来源产物。知识会过时，需要版本控制、分支与合并机制；且知识应被视为缓存而非全量存储，因为维护成本高昂。
Memory Is a Compiler：记忆是一个编译器
作者通过一次融资会议记忆被重新解读的经历，指出记忆的本质不是固定表示，而是一个持久系统：保留过去的证据，并随新证据不断重新编译其意义。文章批评将向量数据库、知识图谱、上下文窗口等当作记忆的常见误解，认为它们只是从记忆编译出的临时表示。作者提出记忆编译产生三类产物：状态（按序折叠事件得到）、检索（查找相关证据的工具）和上下文（为单次调用组装的有界视图），并类比编译器的中间表示（IR），指出每种表示只适合特定操作，记忆本身应是唯一不可丢弃的持久层。
RAG架构详解：检索、增强与生成
本文深入解析了生产级RAG（检索增强生成）系统的完整架构。文章首先指出LLM的局限性——无法访问私有数据，而RAG通过外部知识检索来弥补这一缺陷。然后详细介绍了系统的两大核心平面：知识平面（离线索引）和运行时平面（在线问答）。知识平面涵盖数据源、解析-分块-嵌入流水线以及向量索引；运行时平面则描述了用户查询、检索重排、LLM生成和答案引用的完整流程。文章还逐步拆解了查询生命周期，包括查询嵌入、Top-K检索、重排增强和生成，并强调了监控指标的重要性。
重新理解企业 RAG：从知识工程到 AI 基础设施
本文指出企业级 RAG 绝不仅是简单的文档切块与向量检索，而是一项复杂的知识工程。文章详细拆解了知识入库与用户提问两条流水线，强调了 PDF 结构化解析、混合搜索及权限更新的重要性。在 AI Coding 时代，底层代码可交由 Agent 完成，开发者应更关注 RAG 的架构设计。最终，企业 RAG 的核心价值在于构建一层可被 AI 调用的知识基础设施，从而支撑各类业务 Agent。
用 FastAPI + pgvector 跑通最小可运行私有知识库
本文是一份实战教程，指导读者从零搭建一套最小可运行的 RAG（检索增强生成）私有知识库。技术栈采用 FastAPI 作为接口框架，PostgreSQL 配合 pgvector 扩展进行向量存储，并调用通义千问（Qwen）模型与 Embedding 服务。文章详细讲解了项目结构、依赖配置、数据库模型定义以及文档入库的完整代码实现，旨在构建一个可落地的工程底座。
私有知识库实战：查询改写、混合检索与重排优化 RAG
本文是私有知识库构建系列的第 3 篇，旨在解决基础 RAG 系统在短问题召回、关键词匹配及结果排序上的缺陷。作者详细介绍了通过 LLM 进行查询改写以补全上下文，利用 PostgreSQL 结合 Jieba 实现混合检索（向量+BM25），以及使用 RRF 算法融合检索结果，从而显著提升知识库的日常可用性。
阿里开源 Zvec：像 SQLite 一样极简的嵌入式向量数据库
阿里开源了一款名为 Zvec 的向量数据库项目，主打“纯本地、内嵌式”极简体验，号称向量界的 SQLite。该项目基于 C++ 编写，支持零配置安装，性能强悍（毫秒级搜索数十亿向量），同时兼容稠密、稀疏向量及全文检索。它非常适合本地大模型、RAG 和个人知识库开发，彻底免去了部署繁琐的后端向量服务。
Pydantic fixed my Agent's Memory
文章探讨了如何解决 AI Agent 记忆系统的多跳推理问题。传统的向量数据库在处理跨块事实连接时失效，而通用知识图谱常因缺乏结构导致查询噪音。作者提出的解决方案是使用 Pydantic 提前定义本体（Schema），明确实体类型、关系和属性。通过 Zep 框架强制执行这些约束，可以显著提升提取的准确性和数据的可查询性，从而实现有效的多跳推理。
