MCP、RAG和Agent到底有什么区别？一张图看懂AI系统的“大脑、手脚与外脑”_服务软件

1. LLM，RAG和Agent不是割裂的，而是一个整体。如果把 AI 系统比作一个生命体，那么 LLM = 大脑，RAG = 记忆，Agent = 执行系统。LLM 像是大脑的皮层，擅长理解、联想和表达。它能在复杂的语言世界中“即兴发挥”，像人类一样推理、总结、编故事。也会在需要时做出“认知上的决策”——比如分析问题的思路、选择回答的方向。然而，大脑并不擅长记住具体事实。它能推断“苹果会掉下来”，却未必记得“牛顿是什么时候发现的万有引力”。这时，就需要「RAG」登场。RAG 相当于一个“外接记忆系统”。当大脑想不起细节时，它能立刻翻查资料库，把相关的事实、文档、图像调出来，再交还给大脑整合成一段有根据的回答。于是，大脑不再是“瞎编”，而是“有据可依”。从技术上讲，这就像给模型装上一个搜索引擎——但比搜索更聪明，因为它能理解上下文、筛选关键信息、甚至融合多个来源的内容。Agent 则像是神经系统中的“执行层”。大脑想出了计划，记忆提供了依据，而真正“去行动”的，是 Agent。它决定什么时候要产生计划，要不要调用工具、查阅资料、生成报告，甚至与外部世界互动。可以说，LLM 负责“想”，RAG 负责“记”，Agent 负责“做”。当这三者协同工作时，AI 便不再是一个“聊天机器人”，而是一个有意识、有记忆、有行动能力的“数字生命”。#ai创造营##科技#

2. 如何系统性的学习RAG、Agent、MCP?

3. RAG、LangChain、Agent 到底有什么关系？

4. 对于向深入学习上下文工程（Context Engineering）的同学，Anthropic刚发的这篇《Code execution with MCP: Building more efficient agents》又是一篇必看的文章。这篇文章讲的是如何解决 MCP 工具太多的问题，但凡你做过 Agent 开发，用了大量 MCP 工具，就会知道 MCP 工具多了后最大的问题就是上下文占用太多，不仅导致成本高，还会影响推理和生成质量。另外一个问题就是 MCP 工具返回的中间结果也会挤占大量的上下文空间。看这文章的时候忍不住夸了一下 Manus，他们确实在上下文工程方面探索的很深入了，里面的工程技巧和他们以前分享过的很类似。> Manus 把工具分成了 3 层，预定义了很多 Shell 工具，也是让 Agent 通过文件系统直接检索，另外也会实时编写 Python 代码来创造工具网页链接> Manus 《AI 智能体的上下文工程：构建 Manus 的经验教训》解读网页链接Anthropic 的方案也很简单直接，就是把“代码”也当作工具的一种，然后从代码中去调用 MCP。这样做有很多好处：1. 解决了系统提示词中工具定义太多的问题不需要在系统提示词中加载所有 MCP 工具，只需要定义一个“代码”工具。那需要工具了怎么办呢？这些代码都保存在统一的目录下，去目录检索下就能找到合适的工具了，比如这是文中的一个目录示例：servers├── google-drive│ ├── getDocument.ts│ ├── ... (other tools)│ └── index.ts├── salesforce│ ├── updateRecord.ts│ ├── ... (other tools)│ └── index.ts└── ... (other servers)找不到现成的工具怎么办？直接现写一个！写完了还可以保存起来下次继续用。2. 解决了 MCP 工具返回结果太长的问题比如说我们要用 MPC 工具获取 1 万行数据后筛选转换出合格的数据，就可以先从代码中调用 MCP 工具获取这 1 万行数据，然后从代码中去筛选过滤，最后只返回 5 条数据，这样上下文中就只需要保留那 5 条过滤的数据，而不是像以前一样有 1 万条数据在里面。3. 解决了数据隐私问题如果你直接使用 MCP 工具，工具返回的数据都要加载到上下文每次上传给 LLM，用代码就可以对敏感数据先二次处理再加到上下文4. 中间结果持久化和技能沉淀代码可以把一些中间结果写入文件保存到硬盘，一方面可以不占用上下文空间，另一方面也可以随时从硬盘避免反复调用 MCP。还有就是虽然很多代码是临时生成的，但是这些临时生成的代码可以保存下来，沉淀为“技能”（Skill），加上 SKILL .MD 文件就和 Claude Code 的技能一样可以被反复使用了。可能有人还记得 2023 年 Jim Fan 他们团队做的一个玩 Minecraft 的 Agent Voyager，就能把玩游戏的技能写成代码，保存起来后续使用，最终让 Agent 在 Minecraft 中做很多事。现在想想还是蛮超前的。网页链接原文：网页链接翻译：网页链接

5. 一文读懂Skills、Prompts、Projects、Subagents、MCP区别与落地实战 http://t.cn/AX2gcs78 “在MCP推出一周年之际，Anthropic 发了篇博客，大意是MCP工具很好，但是会让大模型把大量token浪费在定义MCP工具上。尤其遇到有大量中间工具的情况，这个情况会更明显：比如，把一个会议记录下载然后转存到另一个软件中，那么整个会议记录会被计算两次，token消耗会直接爆炸。为了解决这个问题，Anthropic 推出了个新工具—— Claude Skills 。简单来说， Claude Skills 是一个Markdown 文件，里面有预先编写好的脚本、指令文档、资源，作用是告诉模型什么情况下调用，以及怎么执行某项任务。如此一来，模型在决定如何调用工具之前，会先读取所有工具 Markdown 文件的YAML（只有几十token），然后决定是否对其进行调取。那么问题来了， Skills 会取代 MCP吗？很显然，答案是否定的。接下来，本文将对skills在内claude生态工具做一个详细解读，并附带Milvus体系内skills+MCP实操。” #科技先锋官##微博兴趣创作计划#

6. 要是真的教授“如何用 AI 做任何事”。。。我首先要示范的，就是如何用 AI 教授课程吧。。。我会把教案 upload 到一个 RAG 系统里面。然后放一个 URL 出来。AI QA 不了的，或者明显不对劲的，再来问我。完了。。。传统教育，真的被 AI 摧毁了。虽然不会很快消失，但是学校这个东西未来的价值，更多的是一个圈起来只能把时间用来学习的酒店了。。。

7. 通俗易懂的解释 LLM，RAG 和 AI Agent 的差别，以下内容为原推的翻译：我终于明白了LLM、RAG和AI智能体的区别过去两年里，我一直在搭建真正落地的AI系统。现在，我终于清楚了：LLM（大语言模型）、RAG（检索增强生成）和AI智能体（AI Agents），根本不是互相竞争的技术，而是构成同一个AI智能系统的三个层次。很多人用错了方法，把它们当成互斥的工具。---> 大语言模型是“大脑” <LLM 就像AI的脑子，它会思考，会写作，也懂语言。但问题来了：它是冻结在某个时间点的。比如 GPT-4，它的知识截止到训练结束的那一天。你问它昨天的新闻发生了什么？那可就瞎编了。大语言模型很聪明，但却不了解“现在”正在发生的事。---> RAG是AI的“记忆” <这时候就需要 RAG（Retrieval-Augmented Generation，检索增强生成）了，它相当于给大脑接入了“外置内存”。当你提问时，RAG会先去外部数据库或文档里搜索，把相关资料抓出来，再丢给大语言模型作为上下文。这样一来，原本静态的模型一下子就“活”了：- 有最新的数据- 有真实的事实- 完全不需要重新训练模型最关键的是，准确率立刻就提高了。大语言模型不用再靠记忆乱猜，而是真正地在实时检索到的信息上进行推理。你甚至还能追溯每个答案到底用了哪些文档。---## > AI智能体是AI的“行动力” <尽管LLM能思考，RAG能提供新鲜的数据，但它们都缺乏真正的行动能力。这时，AI智能体（AI Agents）出场了。它在大语言模型的外面套上了一个控制循环：- 设定目标- 规划步骤- 执行行动- 回顾反思AI智能体并不仅仅是回答问题那么简单，它能自主地去研究一个话题、收集数据、撰写报告，甚至帮你发邮件，全程自动化。---> 真正的生产级AI，要同时用好这三者 <很多酷炫的AI展示，其实只是单纯用了LLM再配上花里胡哨的提示词。但真正能落地的AI系统，往往同时结合了这三个要素：- LLM 提供推理和思考能力- RAG 确保知识准确而新鲜- AI智能体则提供行动和决策能力---> 如何选用这三者？ <- 只用LLM 如果你需要纯语言的任务，比如写作、摘要、解释。- LLM + RAG 如果你需要回答涉及特定文档、技术手册、专业领域知识的问题，并确保答案准确无误。- LLM + RAG + AI 智能体如果你需要真正的自主行动，比如系统自己决策、执行任务、管理复杂流程。---> AI的未来，不是选哪一种，而是如何把这三层架构起来 <记住这个公式：- LLM负责思考- RAG负责知识- AI智能体负责行动真正的AI智能系统，就是这三者协同起来，形成一个完整的智能架构。来源：x.com/connordavis_ai/status/1985663551697273216

8. 【最新玩法】n8n工作流秒变MCP工具，直连各种MCP客户端，零代码实操！

9. 《MCP协议与AI Agent开发》006-MCP的基本原理（MCP概述）

10. 继昨天Google Agents 白皮书（网页链接），我们今天把mcp的白皮书也总结一下。 Agent Tools & Interoperability with Model Context Protocol (MCP)这应该是目前 MCP 体系最系统的白皮书（之一）了吧，通篇结构清晰，既讲了工具在智能体系统中的定义和设计原则，又深入分析了 MCP 在技术架构、安全与治理方面的优势与风险。1. 工具是智能体的“手与眼”。大模型本质上只是一个模式预测引擎，不能主动感知世界或执行动作。工具让模型拥有了外部交互能力，也因此成为智能体系统的核心组件。文中对工具类型有很清晰的划分：Function Tools（函数调用型）、Built-in Tools（内置工具）和 Agent Tools（智能体级调用）。特别有意思的是，Agent 本身也可以被封装成一个 Tool，这意味着多智能体系统可以通过“工具接口”彼此互操作。2. 工具设计的关键是可解释与细粒度。文档强调“Describe actions, not implementations”，也就是工具描述应聚焦行为语义，而非实现细节。并提出几个值得长期遵守的设计准则：文档清晰、输入输出有 schema 验证、输出简洁、错误信息具引导性。这些看似“文档规范”的建议，其实是让 LLM 能在推理过程中正确选择与调用工具的前提。3. MCP 出现的根本原因，是为了解决“N×M 集成问题”。过去模型和外部系统之间的连接高度碎片化，每个工具都要单独适配。MCP 通过标准化接口和通信协议把模型、工具和数据源解耦，形成“Host–Client–Server”的三层结构，从而实现了可复用、可组合、可动态发现的工具生态。4. MCP 的优势在于生态与扩展性。它让工具注册、发现与调用变得统一，支持动态工具加载，这使得智能体系统不再需要在部署前定义好所有能力。文中提到 MCP Registry 的构想（类似 npm 或 PyPI），也许会形成 AI 工具层的“包管理体系”。这将极大加速企业级智能体生态的互通。5. 但 MCP 也带来了新的安全威胁。白皮书后半部分几乎一半篇幅都在讨论风险，包括： 1）Dynamic Capability Injection：服务器可动态更改工具集，导致智能体意外获得高危能力； 2）Tool Shadowing：恶意工具通过相似描述“抢占”合法工具调用； 3）Confused Deputy 问题：智能体误用自身权限代替用户执行越权操作； 4）数据泄露与 prompt 注入：通过工具输入输出通道泄露敏感信息。文中提出的防御策略（如工具白名单、版本固定、mTLS、HIL 审批、输出净化、最小权限原则等）都是非常实用的企业级落地建议。6. MCP 的发展路径很可能会复现云计算早期的模式——底层协议开放，但企业实际使用都建立在“托管与治理层”之上。未来我们也许会看到“安全版 MCP 平台”，它提供身份管理、审计追踪、工具签名验证、访问控制等功能，就像当年的 API Gateway 成为了 REST 的守门人。7. 另一点值得注意的是“上下文膨胀”问题。文中指出，当 MCP 工具数量增多时，所有工具定义都要塞入模型上下文，会导致 tokens 暴涨、推理性能下降。文中提出用“RAG 化的工具检索”替代预加载——先检索，再动态注入。有个名词叫“ToolRAG”。MCP 已经成为智能体生态走向工业级互操作的关键里程碑，但它还远没到“可直接上生产”的成熟阶段。未来的重点不在于“协议标准”，而在于“安全与治理层”的建设。只有当工具、智能体与企业系统之间的边界被有效约束，Agent 才能在真正意义上成为可信的“行动者”。#ai创造营# #程序员#

11. 请教一下各位关于RAG（检索增强生成）的几个问题？

12. 怎么让大模型的RAG迅速落地，看这一篇就够了（附AI项目落地实操经验+技巧+资料）

13. 配50个Claude项目手改mcp.json？这招让你永远只改1次

14. 论文 Fundamentals of Building Autonomous LLM Agents，系统性地梳理 “如何构建一个真正具备自主性的 LLM 智能体”，也就是从「语言模型」走向「智能体」（而不仅仅是增强的聊天机器人／工具调用系统）。论文提出希望解答以下几个研究问题（RQs）：（1）设计空间（Design space）：核心子系统（感知／推理／记忆／执行）有哪些可选方案？如何系统化组织？（2）子系统整合（Integration）：在现实软件环境（比如 GUI、web 任务）中，这些子系统如何闭环协作？（3）推理效能（Reasoning efficacy）：不同推理策略（如 Chain-of-Thought、Tree-of-Thought、并行规划等）对任务成功率、效率、成本有什么影响？（4）记忆影响（Memory impact）：短期／长期记忆机制（例如 RAG、上下文管理）怎样提升模型在长时程任务或大上下文任务中的表现？（5）失败模式与缓解（Failures & mitigation）：代理在哪些方面容易失败（如幻觉、GUI误定位、重复循环、工具误用）？有哪些缓解技术？（6）评估与泛化（Evaluation & generalization）：有哪些基准／指标适用于评估此类代理？代理能在多任务、多界面条件下泛化吗？★ 核心架构论文将一个具备自主能力的 LLM 智能体拆解为以下四大模块：1. 感知（Perception）系统2. 推理／规划（Reasoning／Planning）系统3. 记忆（Memory）系统4. 执行（Execution）系统★ 感知系统感知系统是智能体“看／听／感知环境”的部分。论文提及四种主要方式：文本感知、多模态感知、结构化数据／信息树感知、工具辅助感知。- 文本感知（Text-Based）：环境以纯文本形式输入，LLM 直接处理。这种方式代价最低，但只适用于文本驱动的场景。- 多模态感知（Multimodal）：环境包含图像／视频＋文字，使用视觉‐语言模型（VLM）或多模态 LLM（MM-LLM）将视觉输入编码为与文本兼容的向量。- 结构化数据／信息树（Information Tree / Structured Data）：例如 GUI 的 Accessibility Tree、HTML DOM 树，将界面元素结构化地输入模型。- 工具辅助感知（Tool-based）：智能体调用外部 API／工具获取环境信息（如网页检索、数据库查询、传感器数据等）然后将结果反馈给 LLM。论文还指出感知系统的关键挑战：例如图像识别中模型可能“幻觉”对象、上下文窗口受限、高计算／延迟成本、数据收集困难等。★ 推理系统推理系统是智能体“思考／规划／决策”那部分。论文讨论了多种方法：- 任务分解（Task decomposition）：把大任务拆成子任务。包括“先分解再规划”（Decomposition first）和“交错分解”（Interleaved decomposition）两类。- 多方案生成与选择（Multi-plan generation & selection）：代理生成多个可能方案（如通过 Tree-of-Thought, Graph-of-Thought, LLM-MCTS 等）然后选择最优一个。- 反思（Reflection）：智能体在执行后或执行途中反思自己的决策／行动，识别错误并改进。甚至“预反思”（anticipatory reflection）在执行前预测失败。- 多智能体系统（Multi-agent systems）：将推理分为多个“专家”模块（Planning Expert、Memory Expert、Error Handling Expert 等），各司其职、协同完成。★ 记忆系统记忆系统使智能体不仅“即时反应”，还能“记住过去、用过去指导未来”。论文区分短期记忆与长期记忆。- 长期记忆（Long-term memory）：如将经验固化、使用 Retrieval-Augmented Generation（RAG）从外部知识库检索、将结构化数据（如 SQL 数据库）用于查询。- 短期记忆（Short-term memory）：通常是 LLM 的上下文窗口中的“当前任务状态”。- 应存储的数据类型：成功经验、失败经验、动作轨迹、环境反馈等。将“失败”经验也显式记录有助于避免重复错误。- 记忆系统的挑战包括：上下文窗口限制、检索噪声、长期记忆如何更新与维护、如何避免“记忆漂移”等。★ 执行系统执行系统是智能体“将内部决策落实为环境动作”的部分。论文谈到执行系统要支持工具调用、API／代码生成、物理操作、GUI 控制等。具体维度包括：- 工具与 API 集成（Tool and API Integration）- 多模态行动空间（Multimodal Action Spaces）——例如 GUI 控制、视觉界面操作、机器人控制、代码执行等。- 整合挑战（Integration Challenges）——例如如何让决策结果真正映射到动作、如何反馈结果、如何监控执行失败／成功。论文：arxiv.org/abs/2510.09244#ai创造营##程序员#

15. 深度解析RAG、LangChain、Agent三者间的关系（附应用案例+大厂内部资源合集）

16. 我常用的一个MCP宝藏库，有点东西

17. 如何实现 AI Agent 自主发现和使用 MCP 服务 —— Nacos MCP Router 部署最佳实践

18. 《REFRAG: Rethinking RAG based Decoding》Meta最新发布的REFRAG技术，彻底解决了检索增强生成模型（RAG）最大的瓶颈：解码效率低下。相比传统RAG，REFRAG实现了30倍更快的首词生成速度，同时保持零准确率损失。问题核心在于：RAG在输入大量检索段落时，实际只有5-10段内容对生成有用，剩余多数成为计算负担，但模型仍对所有段落进行全面注意力计算，导致时间和内存资源巨大浪费。传统RAG用16K上下文时，首次输出延迟超过100秒，吞吐量下降10倍，内存消耗爆表。REFRAG通过将上下文块压缩成单一嵌入向量，避免了对全部16,384个token的逐一处理，仅需处理约1,024个压缩块嵌入，极大减少计算量。成果显著：- 首词生成速度提升30.85倍- 语义困惑度（perplexity）无损失- 上下文容量扩展16倍（4K token → 64K token）- 性能超越前沿技术3.75倍为何行得通？因为RAG的注意力模式稀疏，大多数检索段落间无交互。REFRAG通过以下三点巧妙利用这一点：1. 预计算并缓存嵌入，推理时重复使用2. 基于强化学习的压缩策略，智能决定哪些块需展开3. 不受位置限制，任意位置均可压缩实际应用优势：- 仅8段文本的延迟即可达到单段处理速度- 在检索器性能较弱时，依然提升准确率- 可支持无限长会话历史- 无需修改基础模型架构这项技术改变了RAG的计算经济学：更多上下文、更低延迟，且成本更优。REFRAG不仅是性能优化，更是RAG从“功能”向“基础设施”转型的关键一步。它告诉我们，提升AI系统效率的关键不在于盲目增加计算资源，而是精准减少无效计算，压缩信息冗余，从根本上优化流程。更多细节和论文链接见：arxiv.org/abs/2509.01092这背后，技术创新带来的不仅是速度，更是未来大规模长文本理解与生成的基石。希望更多开发者和研究者能从中得到启发，推动RAG技术应用迈入新阶段。

19. 三大MCP攻击面，揭示四种AI防护体系构建方式

20. 如何借助 ADK、A2A、MCP 和 Agent Engine 构建智能体？

21. 《扣子开发 AI Agent 智能体应用》014-基于大模型的企业知识库（知识库的理论基础 RAG）

22. 打破瓶颈，让RAG学会思考：中科大、智源等发布推理检索框架BGE-Reasoner

23. 构建智能问答系统通常面临查询模糊、上下文理解不足和检索效率低等挑战。Agentic RAG for Dummies 是一个基于 LangGraph 的极简 Agentic RAG（检索增强生成）框架，帮助你用最少代码快速搭建具备会话记忆和人机交互查询澄清能力的生产级系统。项目集成了多功能模块： - 会话记忆，保持对话上下文连贯； - 智能查询澄清，自动重写或请求补充信息； - 分层索引，实现精准且上下文丰富的检索； - 多Agent并行处理复杂多问； - 灵活切换多种大语言模型（Ollama、OpenAI、Google Gemini 等）； - 开箱即用的 Gradio Web UI，方便体验和部署。无论是学习 RAG 基础，还是构建定制化应用，这个项目都提供了交互式笔记本和模块化代码两条路径，助力开发者快速上手并轻松扩展。 GitHub 地址：github.com/GiovanniPasq/agentic-rag-for-dummies/ 主要功能： - 支持多轮对话记忆，提升问答自然度； - 自动拆分复杂查询，精准定位信息点； - 结合关键词稀疏向量和语义稠密向量的混合检索； - 内置人机交互机制，避免误解或无效查询； - 多Agent协同，提升复杂问题的处理效率； - 完整文档处理流水线，支持 PDF 转 Markdown 及分块索引。适合 AI 研究者、开发者及数据工程师，轻松构建满足生产需求的智能问答系统。

24. RAG 如何用 AI 赋能私有数据

25. 什么因素让只有 5% 的 AI Agent 在生产环境中真正有效？What Makes 5% of AI Agents Actually Work in Production?作者 Oana Olteanu 在旧金山主持了一个座谈会，参与者包括 Uber、WisdomAI、EvenUp、Datastrato 的工程师和机器学习负责人。与会者中多数是创业者、工程师、早期 AI 产品构建者。讨论的重点并不是提示工程（prompt engineering），而是“上下文工程”（context engineering）、推理技术栈设计，以及在企业环境中扩展 agent 系统的难题。文章指出，目前有高达 95% 的 AI agent 部署在生产环境失败，失败并不是因为模型本身不聪明，而是因为支撑系统不够完善：上下文工程、安全性、记忆设计 (“memory design”) 等基础设施还未成熟。 1. 上下文工程 (Context Engineering) ≠ 提示调优（Prompt Hacking）在很多情况下，并不需要对 model 做 fine-tune；使用检索增强生成（RAG, Retrieval-Augmented Generation）如果做得好，就足够了。常见的失败模式包括：（1）把所有内容都索引 → 检索过多信息 → 模型被混淆；（2）索引太少 → 模型得不到足够信号；（3）混合结构化与非结构化数据 → 导致 embeddings 被破坏或 key schema 被“压平”。较好的上下文工程做法包括：特征选择、上下文验证（schema／类型／时间等校验）、上下文可观测性（context observability），以及使用 metadata 来增强 embeddings。上下文可以被视作可版本、可审计、可测试的资产，而不仅仅是一段 prompt 文本。 2. 语义 + 元数据分层（Semantic + Metadata Layering）架构一般包含两个层次：语义层（用于经典的向量检索），元数据层（基于文档类型、时间戳、访问权限或领域本体来过滤）。这种混合层可以规范不同格式的输入（PDF、音频、日志、指标等），确保检索的不仅是“相似内容”，而是“相关知识结构”。例如使用分类法、本体（ontology）、实体关联（entity linking）等在 embeddings 之上。 3. Text-to-SQL 的现实挑战在问观众有谁把 text-to-SQL 放到生产环境中时，没有人举手。不是问题小，而是理解自然语言查询非常难。业务术语非常领域化，模型不知道你公司里“revenue”“active user”等定义是什么，没有丰富的上下文就难以理解。成功的团队做的事情包括：构建业务词汇表（glossaries）和术语映射、用约束的查询模板、加入验证层以在执行前捕捉语义错误；还有持续的反馈回路来改善理解。 4. 治理与信任 (Governance & Trust) 并非只有大企业的问题安全性、数据溯源（lineage）、权限控制频频被提及，不只是“合规做一下”，而是生产部署的障碍。示例：用户权限不同，即使提问一样，回答也应不同；若无这些控制，系统即使在功能上是对的，也可能组织上出问题（比如数据泄露、合规问题）。人的信任问题胜过纯技术问题。即便是技术上能做到，用户是否信得过 AI？尤其当 AI 涉及安全、金钱、隐私或医疗这种非常敏感的领域。成功的 AI Agent 会有“human-in-the-loop”设计，让人可验证、可纠错、可覆盖。 5. 记忆（Memory）不仅是存储，而是架构设计记忆有多个层次：用户层面（偏好、写作风格等），团队层面（常用查询、仪表板、runbooks 等），组织层面（制度性知识、政策、之前的决策等）。最佳团队将记忆抽象为一个上下文层＋行为层，是可版本化、可组合的。不仅仅硬编码在本地存储或应用逻辑里。记忆在个性化上有两个作用：一是根据用户历史来定制行为（风格、格式等），二是基于事件或元数据主动提供帮助，而不仅仅被动响应。但也存在张力：过度个性化可能侵犯隐私；共享记忆可能破坏权限控制。作者提到一个缺失的原语（primitive）：一个安全、便携（portable）的记忆层，跨应用可用，并由用户掌控，而非被 vendor 锁定。 6. 多模型推理与编排（Multi-Model Inference & Orchestration Patterns）在生产中，不是所有任务都调用 GPT-4 或一个大 model。团队会根据任务复杂性、延迟要求（latency）、成本敏感性、数据局部性／法规要求、查询类型等来做模型路由。例如：简单的查询用本地模型；结构化查询用 DSL → SQL 翻译器；复杂分析调用大型边缘或云端模型；还有 fallback 或冗余机制（判断器 + 回答器）来校验或备份。 7. 什么时候 “聊天界面”（Chat）是合适的界面？并非所有任务都需要以聊天形式交互。文章中提及用户对于某些任务（比如叫车）更倾向于点击界面，不愿意通过对话。聊天界面适合那些能消除学习成本的场景，比如 BI 仪表板／数据分析这种需要技巧的工具，用自然语言可以降低门槛；但获取结果之后，用户通常希望有 GUI 控件来进一步细化和迭代。 8. 目前还缺什么／未来可赢的地方上下文可观测性：哪些输入持续改善输出、哪些上下文导致错误／幻觉，现在很多团队缺乏系统方式来衡量这些。可组合的记忆（composable memory）：记忆是否可以跟随用户，而不是锁在某个应用里；组织／团队／个人状态应有可选层级。这样用户无需在每个新工具里重建上下文；隐私和安全由用户控制。面向领域的 DSLs（Domain-aware DSLs）：很多业务用户的需求是结构化、重复性的，为什么还要一直把自然语言解析成脆弱的 SQL，而不是开发更高层次、安全有约束的领域语言？比如 “Q4 营收” 应该映射到一个被验证的计算，而不只是 raw SQL 生成。延迟感知的用户体验（Latency aware UX）：不同任务有不同的延迟要求。幽默类任务／日常小查询需要快速响应；深度分析／复杂任务可以接受稍长时间，但需要显示进度并让用户觉得系统在“动”。文章提到：AI agent 可以在你开文档时预备相关上下文，或者在你会议前准备摘要等；这种“异步、主动”的体验有潜力。 9. 发展趋势作者认为接下来基础设施层面 (infra tooling)、记忆工具包（memory kits）、编排层（orchestration layers）、上下文可观测性，以及信任 UX 将会是关键。这些东西现在还“杂乱无章、未被解决”，但未来会变得显而易见。 10. 给创始人／构建 AI Agent／系统工程者的五个问题（Five Hard Questions）1. 我的应用的上下文预算是多少？（理想的上下文窗口大小是多少，以及我如何优化哪些内容进入上下文？） 2. 我的记忆边界在哪里？（哪些属于用户层面／团队层面／组织层面？存在哪里？用户能看到吗？） 3. 我能追踪输出的来源吗？（能否调试模型的某个回应，知道是哪些输入导致的？） 4. 我是用一个模型还是多个模型？（我如何根据复杂性、延迟或成本来路由请求？） 5. 如果我的用户把金钱或医疗数据交给这个系统，会信任它吗？（如果不会，安全性或反馈回路中缺了什么？）访问：www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually#人工智能##程序员#

26. 在构建RAG Agent时，哪些场景应该用确定性逻辑判断取代LLM的概率推理，具体怎么实现？

27. Leonie Monigatti深入剖析了AI代理中的记忆演进，从最初的RAG（检索增强生成）到Agentic RAG，再到具备读写能力的Agent Memory，厘清了这一系列技术的核心逻辑与突破。RAG诞生于2020年，其核心是将离线存储的外部知识检索进LLM上下文，解决模型记忆有限带来的问题。但其“单次检索”与“只读”限制导致复杂场景下仍有误导风险。Agentic RAG引入了“工具调用”机制，允许智能体主动判断是否需要检索、选择检索工具，并评估检索结果相关性，显著提升了灵活性和准确性，但仍无法动态学习和更新信息。Agent Memory则迈出关键一步：支持智能体不仅读取，还能写入和管理外部记忆，实现基于历史交互的持续学习和个性化体验。它将记忆从“静态”转变为“动态”，但也带来了记忆管理和遗忘机制的新挑战。这三者共同体现了信息“存储-检索-编辑-删除”的完整闭环，也反映了AI系统从单点知识调用向复杂记忆体系演进的趋势。未来，如何设计高效的多源、多类型记忆管理策略，将是提升AI智能和人机交互体验的关键。详细内容及代码示例请见原文：leoniemonigatti.com/blog/from-rag-to-agent-memory.html

28. MCP、Skills、SubAgent 到底是啥？简单捋一下

29. 模型上下文协议(MCP)十大安全漏洞解析

30. 从第一性原理出发的RAG推理新范式来了，蚂蚁DIVER登顶权威基准

31. 《What if you don't need MCP at all?》随着MCP服务器话题持续火热，作者从实用角度出发，提出了一个关键观点：在很多场景下，我们其实根本不需要复杂笨重的MCP服务器。相比之下，简单的Bash脚本+代码组合，不仅高效且灵活，完全能满足需求。以浏览器DevTools为例，常见MCP服务器为了覆盖所有功能，往往包含20+工具，消耗大量上下文资源（上万token），导致代理混乱且难以扩展。相比之下，作者只用了一套精简的Node.js脚本工具，包括启动浏览器、导航页面、执行JavaScript、截图四大核心功能。每个工具都用Bash调用，简单明了，README文档仅225个token，极大节省了上下文空间。这种方式还有天然的可组合性：工具输出可以直接保存文件，供后续处理，无需每次都在上下文中传递庞大数据。新增功能也非常方便，比如作者自制的“元素选择器”工具，可以通过页面点击快速定位DOM元素，极大提升爬取效率和灵活度。又如“Cookies”工具，解决了页面执行环境无法访问HTTP-only cookies的问题。作者进一步分享了如何将这些工具模块化管理，通过目录和环境变量整合到代理，保持了环境整洁又便于调用。相比MCP的封闭和臃肿，这种“代码即工具”的思路更贴合实际开发习惯，也更容易维护和升级。总结来看，这篇文章鼓励开发者跳出MCP的框架限制，拥抱简洁的Bash与代码组合。它不仅能提高代理运行效率，减少token消耗，还赋予开发者最大自由度去定制和扩展工具链。对任何需要代码执行环境的代理应用，这都是一条值得尝试的实用路径。阅读原文了解更多细节和代码示例： mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/

32. RAG（检索增强生成）会不会消亡呢？

33. Skills vs MCP，谁才是「大模型的 HTTP 时刻」？

34. DeepLearning AI 吴恩达和 Qdrant新出的这个课程看起来不错。Multi-Vector Image Retrieval，大多数检索系统都会用单个向量来表示一张图像。本课程展示了多向量方法如何将图像表示为由多个嵌入组成的集合，从而在文本查询与视觉内容之间实现更加精确的匹配，尤其适用于包含图片、图表和文字混合的文档场景。1 实现 ColBERT，用于理解多向量文本检索与延迟交互式搜索。2 应用 ColPali，从图像中提取更细粒度的局部补丁级特征，用于精细视觉检索。3 通过量化与池化技术优化内存占用。4 将多向量输出转换为 MUVERA 向量，以加速基于 HNSW 的快速检索。5 构建一个多模态 RAG 流水线，用于检索并推理复杂的视觉类文档。访问：learn.deeplearning.ai/courses/multi-vector-image-retrieval/#ai创造营# #程序员#

35. 关于 NotebookLM 植入 Gemini 这件事，我详细写了一篇自己的使用体验：网页链接NotebookLM 里的笔记本可以作为 Gemini 的外挂 RAG，Gemini 的答案会更加精准，幻觉会收敛，输出更加聚焦和有价值。而对于 NotebookLM 来说，Gemini 帮它搞定了多笔记本互通的事情，另外，NotebookLM 干不了的事儿，Gemini 可以代劳，比如 Deep Research，出图，做视频，写程序等等。这就有点像 Agentic RAG，当然，因为 Gemini 是面向所有互联网数据的，泛化的更厉害一些。目前墨问时间的知识库，还是经典 RAG，要升级成 Agentic RAG，本质是让模型从“只在生成参与”扩展到“全链路参与”，把检索变成一个可决策、可路由、可自我评估的系统，并引入可持久记忆与多源工具。这样不仅提升准确性与覆盖率，也能在复杂查询下保持稳健。还有很长的路要走……

36. MCP吃掉Claude 7%脑容量？手把手教你用Skill神器省90%，2小时测试变10分钟

37. Milvus 向量数据库实战：从零构建高性能 RAG 系统

38. 【保姆级】RAG智能体终极方案：n8n+Google File Search，零门槛搭建高精度RAG工作流！

39. 教程：All-in-RAG | 大模型应用开发实战一：RAG技术全栈指南网页链接本项目是一个面向大模型应用开发者的RAG（检索增强生成）技术全栈教程，旨在通过体系化的学习路径和动手实践项目，帮助开发者掌握基于大语言模型的RAG应用开发技能，构建生产级的智能问答和知识检索系统。主要内容包括： RAG技术基础：深入浅出地介绍RAG的核心概念、技术原理和应用场景数据处理全流程：从数据加载、清洗到文本分块的完整数据准备流程索引构建与优化：向量嵌入、多模态嵌入、向量数据库构建及索引优化技术检索技术进阶：混合检索、查询构建、Text2SQL等高级检索技术生成集成与评估：格式化生成、系统评估与优化方法项目实战：从基础到进阶的完整RAG应用开发实践#微博兴趣创作计划#

40. 通过 MCP 实现 AI Agent 目前有哪些最佳实践？

41. 基于 Nacos + Higress 的 MCP 开发新范式，手把手教程来了！

42. 管理复杂项目和任务，知识沉淀分散且难以高效协作？ATLAS MCP Server 提供了一套基于 Neo4j 图数据库的任务与知识管理解决方案，专为支持大语言模型（LLM）智能代理设计。ATLAS 采用三节点架构（项目、任务、知识），实现项目内任务细粒度跟踪与知识结构化管理，支持任务依赖关系和跨实体统一搜索。2.x 版本全面切换至 Neo4j，增强了数据一致性与查询性能，支持自托管（Docker）和云端 AuraDB。主要功能包括：- 项目全生命周期管理，支持状态、优先级、依赖等丰富属性；- 任务创建、更新、删除与批量操作，支持分配、标签和多维筛选；- 知识库支持领域分类、标签和引用，方便信息沉淀与复用；- 基于 Model Context Protocol (MCP) 的多种通信方式，方便 LLM 代理和各种客户端集成；- 深度研究工具，支持结构化调研计划生成与管理；- 数据库备份与恢复，保障数据安全可靠。GitHub 地址：github.com/cyanheads/atlas-mcp-server npm 包：www.npmjs.com/package/atlas-mcp-server适合需要结合 AI 助理进行复杂任务和知识管理的团队与开发者，支持灵活定制和扩展。

43. Figma MCP + GPT-Codex：新的 Vibe Coding 之王

44. LlamaIndex 深度实战：用《长安的荔枝》学会构建智能问答系统网页链接“这篇文章兼顾了 RAG 的科普与 LlamaIndex 的实战。无论你处在哪个阶段，都能找到适合自己的阅读路径：1. 如果你是 RAG 或 AI 新手（👋 欢迎！）建议从第一部分：原理篇开始。这部分会用一个生动的比喻，帮你建立 RAG 的核心概念，理解 AI 是如何"读书"的。然后，你可以直接跳到第二部分：实战篇，快速体验用 30 行代码构建一个问答系统的乐趣。第三部分：优化篇和第四部分：架构篇可以先收藏，等有概念后再来深入。2. 如果你熟悉 RAG，想深入 LlamaIndex（🚀 进阶！）你可以快速浏览第一部分：原理篇，回顾一下核心概念。第二部分：实战篇值得一看，LlamaIndex 的 API 非常简洁高效。第三部分：优化篇是本文的精华。我们通过真实实验，展示了 chunk_size 和 top_k 等参数对结果的具体影响，这对于生产环境调优至关重要。第四部分：架构篇将帮你理解 LlamaIndex 的内部机制，为你的二次开发或深入定制打好基础。”

45. 小册子：MCP Workbook下载： www.byhand.ai/p/mcp-workbookMCP (Model Context Protocol) 的概念、架构、核心组件以及工作流程。文中详细阐述了 MCP 的核心架构（Host、Client、Server）以及服务器提供的三大基础能力：Tools（执行动作的工具）、Resources（只读数据资源）和 Prompts（预设提示词模板）。此外，文章还通过具体的医疗查询案例，展示了从服务发现、LLM 推理、安全审批到并行任务执行的完整工作流程，强调了 MCP 在标准化 AI 互联与安全控制中的关键作用。#科技先锋官#

46. 这里说的非常清楚，engram解决的问题就是HBM容量受限的问题，context直接耗费的就是HBM，而RAG采用的是通过检索的方式，动态把知识加载到context。engram的优势在于利用CPU+DDR，把知识存放在HOST侧，通过可预测的HOST侧与显卡的通信，来offload知识。

47. Google MCP（Model Context Protocol）提供了一套完整的协议和服务器资源，帮助开发者快速搭建和管理基于模型上下文的服务。这个开源项目收录了Google官方维护的远程MCP服务器列表，涵盖Google Maps、BigQuery、Firebase、Google Workspace等多个核心服务接口，同时支持本地或云端部署。项目不仅提供了详细的部署指南和示例代码，还包含丰富的工具箱，支持数据库管理、云端安全和多代理系统架构，适合需要集成Google多种云服务和AI模型的开发者使用。主要特点包括：- 官方远程MCP服务器，随时可用，保持最新；- 开源服务器代码，可本地运行或部署到Google Cloud Run、GKE等；- 支持多种Google云产品和服务的模型上下文调用；- 丰富的示例和工具，帮助快速上手和扩展；- 完善的文档和贡献指南，社区活跃。项目地址：github.com/google/mcp适合有云计算和大数据需求的开发者、企业及研究团队，助力构建智能、高效的分布式应用和服务。

48. 提示注入导致代码执行：Cursor代码编辑器曝出关键MCP漏洞

49. 评论区有个大神，理解了智障的谬误来自何处，可能智障自己也没闹明白，就盯住个hashhash就hash起来没完了，hash这种东西压根就不是要点啊。engram在推理阶段的作用就是和RAG类似的啊，也是一种retrieval啊！

50. 回复@祝威廉二世:脚本在我看来仍然是工具和参数的组织而且脚本运行空间应该与外界隔绝 call tools 仍然需要物理逻辑和权限的边界。mcp是一个rpc的边界命令工具调用的包也是 openapi的一个restful 也是//@祝威廉二世:skills 现在也带大大量的脚本，这里实际上就是类似MCP 了//@韦恩卑鄙:不太能同意。 mcp 和skills 本质上是两层的东西 skills 本质是subagent 带来的自动编排创建/编排/执行tools。mcp 是较为纯粹的tools封装，只要还有安全封装这件事情这俩就没有可比性。

51. MCP、Agent与RAG

52. [ClaudeCode] MCP (Model Context Protocol) 工作原理详解

53. 什么是 MCP（Model Context Protocol）？

54. AI智能体，第9章统一连接标准

55. 不要瞎编了，RAG一下吧。本集核心知识点

56. RAG架构详解

57. RAG的里程碑之作

58. RAG（Retrieval-Augmented Generation）

59. 浅谈 AI Agent 框架主流协议

60. Day 11:一篇搞明白MCP、RAG、Agent概念和关系

61. 一文搞懂

62. MCP、RAG、Agent

63. 终于有人讲清楚MCP、 RAG、 Agent之间的关系和概念了！

64. 一篇搞明白！agent、mcp、rag 关系

65. 大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏

66. AI工程 | MCP不是一天冒出来的

67. 大语言模型根本 “不懂” MCP，这事儿没你想的复杂

68. AI Agent 入门指南（三）

69. Model Context Protocol（MCP）初试

70. (已离职）冒死上传！RAG全套教程已经替大家付费了！包含所有干货！七天就能从小白到大神！少走99%弯路！

71. MCP、Function Calling与Agent

72. LLM已死，Agent当立

73. LangChain V1 x OceanBase, Agentic RAG 实战(第二章)

74. 在C#中使用Semantic Kernel实现基于RAG和MCP Agent的销售业务智能应答系统

75. 从工具调用到代码编排

76. MCP

77. [资讯阅读1]Agent Tools & Interoperability with MCP

78. 深度｜从SaaS到Service

79. 【2025】MCP（模型上下文协议）从入门到精通，搭建智能体教程，让你少走99%的弯路！

80. 从RAG到Agent，是AI知识探索的内卷与进化

81. 为什么说从RAG升级到Agentic Search刻不容缓？

82. 从检索增强到深度研究

83. RAG 没有死，它只是进化了 —— 深度解析 Agentic Search

84. 大模型应用的三大核心方向及进化

85. Claude Code

86. 传统RAG查不准？Agentic RAG

87. RAG已然过时，Agentic RAG 与 Agent Memory 才是智能体未来发展的方向。

88. Agentic RAG基础入门

89. 大模型四大关键深度解析

90. 一文10分钟搞懂function call、mcp、agent、skills

91. MCP：大模型时代的“万能连接器”与AI基础设施新范式

92. 从零开始学大模型：LLM、ChatGPT、RAG、Agent、MCP核心技术详解，建议收藏！

93. 💻 MCP 服务端面试问答整理

94. MCP详解指南

95. Agent，MCP，Prompt，FunctionCalling是什么？

96. 【MCP】从零开始了解模型上下文协议MCP

97. 告别传统 RAG 低效！Agentic RAG 4 层架构拆解，企业 AI 落地准确率飙升 40%+

98. MCP 实战：使用 Go 快速构建 MCP Server

99. 技术人AI食堂：MCP、RAG、Agent、Function Call、AIGC这道菜该怎么点？

100. 深入理解MCP：构建下一代AI应用的标准化协议-讲座总结

101. MCP和A2A协议有什么区别？

102. LangGraph+MCP+ReactAgent技术组合，构建智能代理（Agent）系统

103. 深入剖析了AI Agent的五大核心要素：大模型、提示词、工具与MCP的完美协同！

104. 4种Web Agent架构对比：MCP vs RAG vs NLWeb vs HTML！

105. 必懂：工作流vs Agent、MCP vs Skills核心区别

106. 【MCP】MCP快速入门-MCP服务器介绍

107. 大模型开发完全指南：MCP、LangChain、LangGraph技术栈详解！

108. [完结20章]AI Agent+MCP从0到1打造个人专属编程智能体课 - 哔哩哔哩

109. 人人都在聊 MCP，它到底解决了什么？

110. Agent能做什么与不能做什么？

111. 智能体设计模式（10）Model Context Protocol（模型上下文协议）

112. Skills 与 Prompts、MCP 以及 Subagents 之间的对比说明

113. 保险企业基于DeepSeek底座+多智能体应用落地方案探讨

114. 实战：用 Spring Boot 搭建 Model Context Protocol (MCP) 服务

115. 🚀 MCP 系统知识分享：让 AI Agent 连接真实世界

116. 分不清RAG 、Function Call、MCP、Agent？一文秒懂它们的区别和联系

117. Anthropic重磅发布Advanced Tool Use：Agent终于不迷路了！

118. AI科研效率飙升！揭秘Model Context Protocol如何连接全球研究工具

119. 【必学收藏】MCP模型上下文协议：解锁AI Agent高效开发的核心技术，让大模型应用效率爆表！

120. agent应用标准详解：A2A & MCP & AG-UI

121. MCP构建与使用【MCP原理】

122. 教你打造一款 AI 安全助手 | 安全 MCP 的实践指南

123. 【必藏】Model Context Protocol (MCP)：AI应用与外部系统的连接桥梁，程序员必看指南

124. 基于 Go-Kratos 与 MCP 的推荐服务实战指南

125. MCP 与 A2A 正在重塑 AI Agent 的底层逻辑

126. .NET+AI | Agent | Agent as Function (14)

127. HoRain云--能力之源：模型、MCP 与工具系统核心解析

128. 智能体系统三大协议(MCP/A2A/AG-UI)详解：让AI"长手长脚"的企业落地指南！

129. 从零开始：构建你的第一个MCP服务器

130. 《MCP协议全解析：给AI装上“工具手”，问题一键解决》(上)

131. 【完结9章】AI Agent 开发新范式 MCP 从入门到多场景全链路实战

132. 从传统 RAG 到知识图谱+ Search Agent，RAG问答率达到95%+

133. UX设计师学AI-让AI agent跨服解决问题的MCP

134. OpenAI、Anthropic、Google 同步入场制定协议，AI Agent 生态或迎来首次实质性对齐

135. 一篇文章搞懂Prompt, Agent, MCP 是什么

136. MCP是什么？MCP很好，但它不是万灵药

137. 从ReAct Agent走向Tool Calling Agents - LangChain 104：Agent的演进

138. Agent Skill 和 MCP 到底什么区别？

139. MCP市场以及MCP评测

140. 8.3K Star！全栈MCP框架mcp-use：6行代码接入任意MCP服务器

141. AI的辅助利器MCP

142. 复盘我的第一个大模型Agent：从核心循环到模块化架构的演进之路

143. Prompt、Agent、MCP 到底是啥？

144. Agentgateway 代理 MCP 流量初探

145. Agent 生态爆发前夜：一文读懂《AI Agent Protocols》(含 7 大类型+未来趋势)

146. [MCP专题1] 一个让人眼前一亮的MCP平台

147. MCP基础技术回顾

148. 基于DWS MCP Server搭建数据分析Agent

149. 每天半小时 AI 知识｜KAGI：AI 的“逻辑脑”。KAG (Knowledge Augmented Generation) 将引入 “知识图谱 (Knowledge Graph)” 的概念，展示如何让 AI 不仅仅是“翻书”，而是像侦探一样通过“线索墙”进行逻辑推理。#AI #AI知识 #RAG #人工智能

150. RAG 与 Agentic RAG 的区别详解

151. 图解｜Go语言实现 Agent｜LLM+MCP+RAG

152. UXer学AI-Google Agent2Agent Protocol

153. Agent时代来临：一文读懂大模型Agentic Reasoning框架

154. MCP 网关，MCP 服务器的集中式管理

155. 使用RAG技术构建企业级文档问答系统：检索优化(13)Contextual Retrieval

156. 04 Contextual Retrieval（上下文检索）

157. FastMCP 入门：用 Python 快速搭建 MCP 服务器接入 LLM

158. AI Infra：纠缠不清的 Context、RAG、Memory

159. MCP 传输方式，stdio、HTTP SSE 和 Streamable HTTP

160. 原创案例 Agentic RAG智能学术助手完整流程拆解包含核心代码讲解基于清华UtralRAG MCP架构+YAML声明式编程｜大模型RAG｜Agent

161. MCP 网关，聚合多个 MCP 服务器使用了 MCP 网关之后，应用的 MCP 客户端连接到 MCP 网关，MCP 网关连接到实际的 MCP 服务器。客户端的配置简化了很多，只需要 MCP 网关的连接配置即可。网关可以提供 MCP 服务器的集中管理，包括 MCP 服务器的添加和删除，工具的过滤，服务器和工具的权限控制等。 #MCP #AI #人工智能

162. 【大模型实战】FastAPI-MCP，零配置几行代码将现有API升级为AI工具服务，保姆级教程，小白也能轻松学会！！

163. 使用RAG技术构建企业级文档问答系统：检索优化(9)Parent Document Retriever

164. MetaMCP: MCP聚合部署神器

165. MongoDB MCP服务器Docker部署完整指南

MCP、RAG和Agent到底有什么区别？一张图看懂AI系统的“大脑、手脚与外脑”

精选参考来源