cczywyc

为什么又重新聊这几个概念？ 最近在系统性学习 AI Agent 的构建和落地，喂给了 GPT 一批资料，让它给我整理了一份详细的 roadmap，第一步便是应该先弄清楚这几个概念，GPT 建议我输出一份文档，于是便有了这个文章（但其实这篇文章也是我列好大纲让 AI 写的）。 一、为什么要区分这四个概念学 AI Agent 的第一步不是写代码，而是搞清楚边界。很多项目失败不是因为技术不行，而是用错了模式——该用 Workflow 的地方强上 Agent，该用 Agent 的地方只做了 RAG。理解这四个概念的区别和关系，是后续所有工程决策的基础。 二、一句话定义 Chatbot：基于 LLM 的对话系统，用户问一句答一句，不主动行动，不调用外部工具。 Workflow：预定义的固定流程，每一步做什么、调什么工具、输出什么格式都是开发者写死的。 RAG（Retrieval-Augmented Generation）：在生成回答前，先从外部知识库检索相关内容注入上下文，让模型基于检索结果回答。 Agent：具备自主决策循环的系统，能根据当前状态动态选择下一步行动，包括调用工具、检索信...

上一篇文章是关于 RAG 的一些基本介绍，这篇主要是根据上篇的流程来实现一个简易的 RAG 系统，进一步加深对 RAG 工作流程的理解。本文所列举的示例代码非常简单，完全是按照上篇文章中所划分的三个阶段来的，但是包含了 RAG 系统所有的必要步骤。 数据源加载与分块1234567891011from typing import Listdef split_into_chunks(doc_file: str) -> List[str]: with open(doc_file, 'r') as file: content = file.read() return [chunk for chunk in content.split("\n\n")]chunks = split_into_chunks("doc.md")for i, chunk in enumerate(chunks): print(f"[{i}] {chunk}\n&quo...

基础原理RAG（Retrieval-Augmented Generation）中文叫做检索增强生成，它是一种将外部知识库与大语言模型（LLM）相结合的技术。其核心思想是在大模型生成回答之前，先检索文档将检索到内容作为上下文输入给模型，从而提高回答的准确性和时效性。 在一个典型的 RAG 系统中，首先会对外部文档进行预处理并向量化存储形成知识库，当用户提出问题，系统会将问题转化成向量，并且计算出向量相似度，在知识库中找出与用户问题相近的片段，然后将用户问题和相似片段一起丢给大模型（prompt），大模型在此基础上生成答案。 总结上述过程，大致可以分为三个阶段： 准备阶段：分片、索引 检索阶段：召回、重排 生成阶段：生成 使用场景通过上述的介绍不难发现，RAG 适合用做智能客服或者企业内部知识库等私有化数据的场景。一般来说，传统的 LLM 通常都有上下文的限制（即使 Gemini 有百万的上下文），这就导致大模型在工作时始终有上下文局限，我们不可能把大量的私有数据一下子全部喂给大模型，而 RAG 通过分片、向量化存储和向量相似性等手段解决了 LLM 根本局限性。 总结一下，可以归...

模型上下文协议（MCP）是一个开放协议，用于标准化应用程序向大语言模型提供上下文的方式，由 Anthropic 于 2024 年 11 月推出。在 MCP 出现之前，将 AI 模型连接到各种数据源通常需要为每个源开发定制化的集成方案，导致系统碎片化、难以扩展且开发成本高昂，MCP 则通过提供一个通用的、标准化的协议来解决这个问题。 MCP 架构MCP 的核心架构遵循客户端-服务器模型，主要包含三个组件： MCP 主机（MCP Host）：指的是希望通过 MCP 利用外部数据或工具的应用程序。例如 AI 助手（如 Claude Desktop）、集成开发环境（IDE）、或其他 AI 工具。MCP Host 负责管理 MCP 客户端实例，并控制权限和安全策略。 MCP 客户端（MCP Client）：嵌入在主机应用程序中，是实现 MCP 协议客户端逻辑的部分。它负责与一个或多个 MCP 建立并维护安全、一对一的连接，管理通信、状态和能力协商。 MCP 服务器（MCP Server）：是实现协议服务器端逻辑的程序。它连接到具体的数据源（本地文件、数据库等）或远程服务（API），并通过...

Paxos 背景和介绍进入正文之前先来简单说一下几个概念和 Paxos 的由来。 分布式一致性问题在分布式计算领域，一个核心且基础的挑战是如何让一组独立的计算机（或称为节点、进程）在可能发生故障（如节点崩溃、网络消息丢失或延迟）的环境下，就某个值或状态达成一致 。这个问题被称为共识（Consensus）。达成共识的能力对于构建可靠的分布式系统至关重要，这些系统需要在多个副本之间维护数据一致性，例如分布式数据库、分布式锁服务、以及实现状态机复制（State Machine Replication）等场景 。状态机复制是一种强大的技术，它允许将任何单机上的确定性算法转化为一个容错的、分布式的实现，确保即使部分副本发生故障，整个系统对外也能表现得像一个永不宕机的单体服务 。 一个健壮的共识算法通常需要满足几个关键属性： 有效性（Validity）：最终被选定的值必须是某个进程实际提议过的值。 一致性（Agreement/Consistency）：所有做出决定的正常进程必须对同一个值达成一致 。这是共识最核心的保证。 完整性（Integrity）：每个进程最多只能决定一个值。...

MIT 6.824 课程的第二个 lab 是实现一个 key/value server，这里是官网的 实验说明。本篇文章是关于 key/value server 实验设计思路及实现过程。 实验概述本实验要求实现一个单机版的 kv server，支持 Put、Append 和 Get 三种操作。该服务保证所有的操作都必须是线性化（linearizable）的，确保操作顺序符合实时顺序，并且能够处理网络故障（例如消息丢失），保证操作只执行一次。实验目标是能够满足不同客户端以及不可靠网络等场景，确保服务器在并发和故障情况下都能够正常工作。 设计 线性化：通过使用 Go 的互斥锁（mutex）保护共享数据，确保并发访问时操作顺序一致。 网络故障处理：客户端为每个请求分配唯一序列号（sequence number），服务器通过客户端唯一标识（Client ID）和请求序列号检测重复请求，确保幂等性。 操作定义： Put(key, value): 将键 key 的值设置为 value，覆盖原有值。需确保线程安全，并记录序列号以防重复。 Append(key, arg): ...

MapReduce 是一种处理大量数据的编程模型以及实现，它使用 Map 和 Reduce 两个函数对于海量数据计算做了一次抽象，用于在集群上使用分布式算法处理和生成大数据集。MapReduce 最先由 Google 在 2004 年提出，并且在内部得到了大量的实践，简单说来，MapReduce 模型由一个 Map 函数处理一个基于 key/value pair 的数据集合，输出中间的基于 key/value pair 的数据集合，然后再由一个 Reduce 函数用来合并所有的具有相同中间 key 值的中间 value 值。 仔细分析发现，现实世界中有很多满足上述处理模型的例子，关于 MapReduce 的产生背景和详细的介绍本文不再详细叙述，强烈建议阅读 Google 的论文，一定会对 MapReduce 模型有更进一步的理解。 说起分布式系统，大家应该都知道 MIT 有一个明星课程 6.824，它是专门讲解分布式系统的，这个课程还设置了一系列非常有难度的实验来检验你对课程的掌握。为了进一步加深我对分布式系统的理解，前段时间我便开始完成 2024 年春季 6...

上篇文章，详细介绍了 WebRTC 技术。我们知道，WebRTC 标准中并没有规定信令服务器的实现，它把这部分的实现交给了程序开发者本身，一方面基于 WebRTC 的应用形态和技术栈可能是多种多样的，这样不但保持了技术中立性，还最大限度的确保了技术的灵活性和开放性；另外一方面，协议的设计是极其复杂的，要兼顾的场景很多，这样也保证了技术标准的简洁性。因此，只要符合 WebRTC 的通信流程和架构设计理念，信令服务器的实现方案应该是非常灵活的。 本文是此系列文章的第二篇，介绍 WebRTC 中信令服务器的设计。 信令介绍在 WebRTC 的技术栈里，详细定义了一整套的规范，例如它的接口设计，使用 SDP 进行媒体协商、使用 ICE 收集网络地址并进行联通性检测等，这些规范使得客户端与客户端之间的数据交换变得非常容易和方便，但是我们发现 WebRTC 并没有对客户端建立点对点连接之前的过程定义规范，“空缺”的这部分，其实就是信令服务器在发挥作用的地方。 概括来说，WebRTC 信令是设备通信和交换点对点连接所需的信息的方式，包括交换应用程序之间的网络信息、协商媒体格式并处理通信会话的各...

如题，最近在折腾一个文件传输工具，用于在多个不同设备间方便快速地传输文件。我的要求也很直接，这个文件传输工具，最好不需要繁琐的安装和配置过程，能够做到开箱即用，同时它还需要兼容我的 PC 设备和多个移动设备，经过一番调研之后，我决定把技术方案定为了 WebRTC。 本篇文章是此系列文章的第一篇，详细介绍 WebRTC 技术。 WebRTC 概述WebRTC（Web Real-Time Communication）是一个开源项目，旨在通过简单的应用程序接口（API）实现浏览器和移动应用之间的实时通信（RTC）。它允许网页浏览器进行语音通话、视频聊天和点对点文件分享，而无需用户安装特殊的插件或第三方软件。 简单来说，WebRTC 项目主要思想是定义 WebRTC API，该 API 允许浏览器安全地访问设备上的输入外设，如麦克风和网络摄像头，以点对点的方式与远程设备共享或交换媒体数据以及实时数据。借助 WebRTC，多个不同设备可以在一个平台上流畅地、安全地共享语音、视频和实时数据。 WebRTC 是 Google 在 2011 开源的项目，并将其纳入 Chrome 浏览器的开发计划...

临近年末，最近陆陆续续看到不少人公开了自己的年终总结，我也跟个风，总结一下即将过去的我的 2023 年。 一开始我在总结过去的一年的时候，发现并没有太多值得总结的事情，出于博客网站的需要，我决定还是开个好头，写下了这篇文章。需要特别说明的是，这是一篇流水账式的文章，并没有特别的干货，写的真的很烂。 既然说到这里，先来说一下我的个人网站，2023 年是我正式开始写博客的第一年，正如我在这篇文章中所说，以前我总是记录的很杂、很随意，我希望通过写博客的方式让自己养成记录的好习惯，并且借此得以规范我的记录，希望这是一个好的开始。截止到现在，整个 2023 年我一共正式写了 12 篇文章，算很少的了，其中有不少时间还花在个人网站的建设上，一开始我使用的是 hugo 来构建我的网站，苦于我使用的主题文档缺少，加上 hugo 可自定义性不高，在 12 月份的时候我把个人网站改为了 hexo 构建，并且使用了全新的主题，这套主题文档很详细，可配置性很高，比较适合作为我构建个人网站的选择，最后也就是你现在看到的这个样子。 去年 12 月，我跟妹子摇中了一个不错的盘，也算正式上车，成为房奴大队的一员...