当前位置：

社区首页

电脑数码

软件应用

服务软件

AIGC文章详情

A-RAG效果封神！手把手教你构建会思考、能决策的智能检索系统

源自64位全网作者

04-08 14:59

精选参考来源

对话云栖大会：下一个AI爆款、大模型进化与Agent万亿级企业市场

#技术巡猎# #小鹏汽车# “车辆终端的交互处理方法、装置和电子设备”。主旨比较明确，“用户吐槽”在这里，可以直接变成“可定位、可分发、可闭环”的缺陷数据。这件事其实就有点像医院急诊的分诊台了，问问症状，看看你的体征，然后最后该挂哪个科、谁来处理，系统在这里做个初判。它的输入主要有两路，一条是用户在车机交互组件里说出来的“问题描述数据”，另一条是车辆同步组件实时抓到的“多维运行数据”。多维数据怎么来呢？软件配置信息（典型就是OTA版本特征）、运行状态（静止/行驶/充电/上下电）、交互记录（大屏日志）、以及总线通信信号（CAN状态变化）。实操的时候，单靠一句“音乐播不了”很难判断是网络、是版权、还是你点错了，或者是升级把兼容性搞崩了；把这些上下文一起带上，才有可能讲清楚“问题”到底是啥。专利里提到了一个规则引擎，它是一个“适配器+调度器+多个执行单元”的并行结构，单机脚本那套思路在这里不够用：适配器把自然语言做语义拆解，映射到预定义诊断维度，形成结构化特征向量；调度器把请求拆成调度任务集合；多个执行单元并行跑规则匹配。专利里甚至写了每个并行执行单元可以维护20条规则，靠多节点把规则命中做成毫秒级。规则还分三类：静态匹配规则、多维联合条件规则、历史行为时序规则；然后聚合命中结果，给不同类型规则分权重（举例0.4/0.3/0.3），最后算一个总置信度；置信度高于阈值（例子里是0.7）就给主标签，低一点就当次标签。也给了一个很“医生”的例子：如果OTA版本+某个CAN地址状态一起命中，就把候选先指向OTA模块异常。这个环节的意义很简单：先把候选池缩小，否则后面再上机器学习、图模型、GNN，算力也只会用来“认真地胡说八道”。再往后是更像“算法层”的部分：基于软件配置、状态、日志、CAN这些维度，构建多维异常评分模型，对不同匹配类型打异常置信度分；根据评分对匹配结果做置信度调整；最后用目标归因算法做归因判定。专利给了一些输出字段：问题类型、可能故障模块、概率/评分、建议措施，还包括故障代码、归因逻辑说明、以及后续建工单需要的字段（业务线、来源、关联版本、发现阶段等）。甚至强调了前置过滤、二次校验、降权规则、补充规则这些“防误判护栏”---很明显是怕系统一上来就把工单打爆，最后工程团队只会选择关掉它。真正改变用户感知的，是它可以把结果“当场说出来”。专利举了一个例子：用户反馈娱乐系统播放异常，系统把原因归到最近一次OTA兼容性问题，于是几秒内在大屏弹窗解释并给建议（比如先重启试试），同时后台自动创建缺陷工单、做属性分类、分发到处理终端；车机和手机APP还能同步状态，显示“已创建/处理中/修复测试中/已解决”，用户也能补充信息。它最聪明的点反而是“主标签/次标签”这种表达方式---系统敢给结论，但也承认不确定性，把话说死的风险交给置信度去管理，用户体验会稳定很多。这其实是一套非常考验体系的存在。你得有稳定的日志口径、版本标识、CAN信号字典、缺陷字段治理；你得持续维护规则库和故障知识库，不然新版本一上线，命中率就像抽盲盒一样；你还得把合规做扎实---专利在末尾专门写了用户授权、提供入口可授权或拒绝、遵守各国家地区法律标准---这已经考虑到“很市场”的情况了。再现实一点：它也要求你把车端、云端、缺陷系统全部打通，工单状态能返回到车里让用户看到，“人盯人”的客服模式，在这里可以推向“系统盯系统”的质量运维模式。

全部
来源

内容由AI生成

1. 对话云栖大会：下一个AI爆款、大模型进化与Agent万亿级企业市场

2. #技术巡猎# #小鹏汽车# “车辆终端的交互处理方法、装置和电子设备”。主旨比较明确，“用户吐槽”在这里，可以直接变成“可定位、可分发、可闭环”的缺陷数据。这件事其实就有点像医院急诊的分诊台了，问问症状，看看你的体征，然后最后该挂哪个科、谁来处理，系统在这里做个初判。它的输入主要有两路，一条是用户在车机交互组件里说出来的“问题描述数据”，另一条是车辆同步组件实时抓到的“多维运行数据”。多维数据怎么来呢？软件配置信息（典型就是OTA版本特征）、运行状态（静止/行驶/充电/上下电）、交互记录（大屏日志）、以及总线通信信号（CAN状态变化）。实操的时候，单靠一句“音乐播不了”很难判断是网络、是版权、还是你点错了，或者是升级把兼容性搞崩了；把这些上下文一起带上，才有可能讲清楚“问题”到底是啥。专利里提到了一个规则引擎，它是一个“适配器+调度器+多个执行单元”的并行结构，单机脚本那套思路在这里不够用：适配器把自然语言做语义拆解，映射到预定义诊断维度，形成结构化特征向量；调度器把请求拆成调度任务集合；多个执行单元并行跑规则匹配。专利里甚至写了每个并行执行单元可以维护20条规则，靠多节点把规则命中做成毫秒级。规则还分三类：静态匹配规则、多维联合条件规则、历史行为时序规则；然后聚合命中结果，给不同类型规则分权重（举例0.4/0.3/0.3），最后算一个总置信度；置信度高于阈值（例子里是0.7）就给主标签，低一点就当次标签。也给了一个很“医生”的例子：如果OTA版本+某个CAN地址状态一起命中，就把候选先指向OTA模块异常。这个环节的意义很简单：先把候选池缩小，否则后面再上机器学习、图模型、GNN，算力也只会用来“认真地胡说八道”。再往后是更像“算法层”的部分：基于软件配置、状态、日志、CAN这些维度，构建多维异常评分模型，对不同匹配类型打异常置信度分；根据评分对匹配结果做置信度调整；最后用目标归因算法做归因判定。专利给了一些输出字段：问题类型、可能故障模块、概率/评分、建议措施，还包括故障代码、归因逻辑说明、以及后续建工单需要的字段（业务线、来源、关联版本、发现阶段等）。甚至强调了前置过滤、二次校验、降权规则、补充规则这些“防误判护栏”---很明显是怕系统一上来就把工单打爆，最后工程团队只会选择关掉它。真正改变用户感知的，是它可以把结果“当场说出来”。专利举了一个例子：用户反馈娱乐系统播放异常，系统把原因归到最近一次OTA兼容性问题，于是几秒内在大屏弹窗解释并给建议（比如先重启试试），同时后台自动创建缺陷工单、做属性分类、分发到处理终端；车机和手机APP还能同步状态，显示“已创建/处理中/修复测试中/已解决”，用户也能补充信息。它最聪明的点反而是“主标签/次标签”这种表达方式---系统敢给结论，但也承认不确定性，把话说死的风险交给置信度去管理，用户体验会稳定很多。这其实是一套非常考验体系的存在。你得有稳定的日志口径、版本标识、CAN信号字典、缺陷字段治理；你得持续维护规则库和故障知识库，不然新版本一上线，命中率就像抽盲盒一样；你还得把合规做扎实---专利在末尾专门写了用户授权、提供入口可授权或拒绝、遵守各国家地区法律标准---这已经考虑到“很市场”的情况了。再现实一点：它也要求你把车端、云端、缺陷系统全部打通，工单状态能返回到车里让用户看到，“人盯人”的客服模式，在这里可以推向“系统盯系统”的质量运维模式。

3. Genome Biology | 香港城市大学孙燕妮团队提出 PlasRAG：基于序列-文本对齐的全面质粒表征与检索工具

4. 在线文档智能检索新利器——OpenRAG（GitHub: github.com/langflow-ai/openrag）是一款集成Langflow、Docling和OpenSearch的Retrieval-Augmented Generation平台，专为实现智能问答和文档搜索设计。OpenRAG核心优势：- 一键安装即用，所有核心组件无缝对接，开箱即用体验。- 支持多文档快速索引，能处理复杂的真实世界数据，实现精准语义检索。- 集成Langflow的可视化拖拽流程编辑器，方便快速搭建和调试RAG工作流。- 以OpenSearch为底层引擎，保证企业级海量数据检索的高性能和稳定性。- 多agent智能协调和重排序机制，提升问答质量和响应智能度。- 提供Python和TypeScript官方SDK，方便开发者灵活集成入自有应用系统。快速上手：1️⃣ 部署OpenRAG（支持Docker、一键安装）2️⃣ 导入文档进行智能语义索引3️⃣ 即刻开始基于大模型的智能聊天问答体验OpenRAG将文档检索和生成式AI完美结合，助力企业和开发者打造强大的智能知识库和客服机器人，体验未来智能搜索的无限可能。#AI创造营##人工智能#

5. 使用 Claude Code 进行长周期开发时，上下文的自动压缩（Compaction）往往会导致关键细节丢失，随着对话增长，模型容易产生幻觉或遗忘之前的决策。Continuous Claude 是一个专为 Claude Code 打造的上下文管理工具包，核心理念是“清理而非压缩”，通过账本和交接机制确保开发状态的无损延续。它不仅提供了自动化的状态保存功能，还整合了高效的 MCP 执行环境和多智能体协作流，让 Claude 在处理复杂任务时始终保持高清晰度的上下文。GitHub：github.com/parcadei/Continuous-Claude主要功能：- 连续性账本系统，在清理上下文前后自动保存和恢复任务目标与进度；- 自动化钩子（Hooks），在会话启动、工具调用和上下文压缩等关键节点自动执行状态维护；- 令牌高效的 MCP 执行，通过脚本化工具调用减少上下文污染，提升响应质量；- 智能体编排工作流，支持计划制定、方案验证、实施及 TDD 驱动的开发模式；- 本地构件索引，使用 SQLite 存储交接文档和计划，支持快速检索历史决策；- 深度集成代码质量工具，支持自动格式化、静态检查及 TypeScript 预检。该项目支持全局安装或单项目配置，通过 uv 管理 Python 依赖，适合需要使用 Claude Code 进行深度编程和复杂架构设计的开发者。

6. 开发者在使用 Claude Code 编写代码时，想要自动保存每次操作的上下文和工具使用情况，方便后续继续工作。Claude-Mem 是一款为 Claude Code 打造的持久化记忆压缩插件，能抓取工具执行的观察数据，通过 AI 进行语义压缩，并将相关上下文注入到未来的编码会话中。它支持跨会话保持上下文连贯，内置智能搜索功能，能用自然语言查询历史操作，极大提升项目管理和代码回溯的效率。插件提供 Web UI 实时查看记忆流，并可配置隐私标签过滤敏感信息。更有实验性的“无限模式”，通过压缩和分层存储实现更长的会话记忆，适合复杂项目的持续开发。主要功能：- 自动捕获并压缩会话数据，实现跨会话记忆延续- 语义搜索工具，快速定位历史决策和代码修改- Web 界面实时展示记忆流和搜索结果- 灵活配置隐私控制和上下文注入策略- 支持实验性无限扩展会话长度的“Endless Mode”- 基于 SQLite 和向量数据库结合实现高效存储和检索适用于需要在多次编码会话中保持项目上下文连续的开发者，尤其是使用 Claude Code 进行 AI 辅助编程的用户。项目地址：github.com/thedotmack/claude-mem安装简单，启动后自动生效，无需手动操作。想让 AI 更懂你的代码历史，这个开源插件值得一试。

7. 构建和部署AI智能代理和工作流，Langflow提供了一个强大的可视化开发平台。它不仅支持拖拽式流程设计，还内置API和多方通信服务器，让每个工作流都能轻松集成到各种应用中。主要功能包括：- 直观的可视化编辑界面，快速上手与迭代；- 完全开源，支持用Python自定义组件；- 交互式调试环境，逐步测试和优化流程；- 多智能体协作与对话管理；- 支持API部署，也能导出JSON供Python调用；- 作为多方通信服务器（MCP）运行，扩展灵活；- 集成多种监控工具，保障安全与性能；- 跨平台桌面客户端，支持Windows和macOS。无论是构建复杂的AI代理，还是搭建多步骤自动化流程，Langflow都能极大提升开发效率和灵活性。适合AI开发者、数据科学家及产品团队使用。GitHub：github.com/langflow-ai/langflow 官网：www.langflow.org

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

9. 【AI人工智能】题库:纯公益分享【就业+考研】笔试+面试必会【小白从小学Python,C,Java】知识点名称AI中RAG检索增强生成知识点讲解检索增强生成（Retrieval-Augmented Generation，RAG）是一种将检索系统与生成模型结合的架构，模型在生成答案前先从外部知识库（如文档、数据库）检索相关内容，再基于检索结果生成响应，从而缓解大语言模型的幻觉问题、提升答案的事实性和时效性。它通常包括检索器（Retriever，如Dense Passage Retrieval）和生成器（Generator，如LLM）两部分。例题（单选题）RAG的主要优势是什么？A选项：结合外部知识减少幻觉提升事实性B选项：取代模型的参数化知识C选项：仅依赖模型内部参数生成D选项：减少模型参数量压缩体积答案与题解答案、题解：见评论区温馨期待期待大家提出宝贵建议，互相交流，收获更大，助教：lxy#AI创造营# #科技风向标# 网页链接

10. 【向量数据库被颠覆？一个无需嵌入的RAG新思路】最近开源社区出现了一个有意思的项目PageIndex，它提出了一种完全不同的RAG实现路径：用文档树结构替代传统的向量嵌入，在FinanceBench基准测试上达到了98.7%的准确率。这个方案的核心理念是让大模型直接在文档结构上进行推理，而不是通过关键词匹配来检索。不需要嵌入，不需要分块，完全开源。听起来很激进，但仔细想想，这其实回归了一个朴素的问题：人类阅读文档时，依赖的是什么？是语义相似度，还是章节、标题、表格这些结构化线索？对于金融报告、法律合同、合规文档这类天然具有清晰层级结构的内容，让模型沿着文档树进行推理，确实比把文档切成碎片再用向量匹配更符合直觉。结构优先的检索方式，也让引用溯源变得更加可靠。但社区的实测反馈也很真实。有人指出它目前只能处理单个文档，跨文档比较和相似性匹配这类场景还是需要向量数据库。也有人反映速度偏慢，对于简单查询来说，逐层遍历节点的开销不小。还有人质疑：面对大规模非结构化数据，这种方案能否扩展？一位开发者的评论很中肯：向量数据库能用廉价的数学运算实现毫秒级检索，而PageIndex依赖的是昂贵且缓慢的大模型推理，在需要扫描海量文档的场景下，可行性存疑。所以这不是一个“谁取代谁”的故事。更准确的理解是：RAG的工具箱里多了一件趁手的武器。结构化文档用文档树，非结构化内容用向量嵌入，复杂场景可能需要混合方案。技术选型从来不是非此即彼。真正的答案永远是：在你自己的数据上跑一遍基准测试。 GitHub：github.com/VectifyAI/PageIndex x.com/dr_cintas/status/2019045152350756869

11. Manus 的上下文工程

12. 做了个RAG评估小框架开源做RAG时发现，麻烦的往往是数据处理到评估的那条流水线。所以顺手写了个工具，用中文数据集做基准，内置标准流程，方便快速试不同的检索和生成方案平时主要用它两件事，一是快速验证新想法，不用重复写脚本，二是在同一套指标下对比不同策略，看问题出在哪#rag#

13. 「Github一周热点107期」OpenAI收购的AI安全工具、AI代理事务所、OpenClaw技能库、claude code插件和上下文数据库

14. 盘点一周AI大事(4月5日)｜叫AI老公多干活 OpenAI内测下一代生图模型「GPT-Image-2」 OpenAI工匠计划「Project Stagecraft」曝光 Google发布最强开源小模型「Gemma 4」 Anthropic研究发现Claude有170种情绪向量阿里发布最强开源多模态大模型「Qwen3.5-Omni」 Sakana AI 发布AI战略官「Marlin」微软发布最强语音识别模型「MAI-Transcribe-1」研究员开源最强声音克隆模型「LongCat-AudioDiT」研究员开源最强语音合成模型「OmniVoice」工程师开源AI同事「同事.skill」爆火首个一人独角兽公司「Medvi」诞生 #前沿科技趋势发布月 #AI新星计划 #AI #OpenAI #AIGC

15. 常见面试题：在构建知识库时，文本切块策略至关重要。你会如何选择合适的切块大小和重叠长度？这背后有什么权衡？这是一个典型但非常容易被低估的问题，尤其在偏工程、偏系统构建的场景里，切块策略几乎决定了 RAG / 知识库的“上限”。可以分三个层次开展开：如何选切块大小、如何选重叠长度、背后的核心权衡逻辑。一、切块大小怎么选，本质看三件事切块大小从来不是一个“经验数值”，而是由下面三件事共同决定的。 1. 语义完整性需求切块必须是一个最小可独立理解的语义单元。如果一个 chunk 本身就需要依赖前后内容才能理解，那它再怎么被召回都没有意义。 a. API 文档、函数说明一个函数 + 参数说明 + 返回值，通常是一个完整语义单元这种场景下，切块可以偏大 b. 论文、技术文章、设计文档一个自然段往往只表达一个子观点，但真正可用的信息常跨 2–3 段这种场景下，切块不能太小核心判断标准只有一句话：这个 chunk 被单独喂给 LLM，能不能完成一次有价值的推理？ 2. 嵌入模型的表达能力嵌入模型并不是“越长越好”。 a. chunk 太小向量只捕捉局部词义，语义密度低相似度搜索容易命中“看起来相关、实际没用”的片段 b. chunk 太大向量会被多个主题平均真正关键的信号被稀释，召回精度反而下降所以切块大小通常要落在嵌入模型的“有效语义压缩区间”内。以当前主流 embedding 模型为例，一个经验区间是：大约 300–800 tokens 属于比较稳定的区间不是硬规则，而是一个“风险较低的甜点区” 3. 下游 LLM 的上下文预算 chunk 大小 × 召回数量 = 上下文占用你最终不是在优化“向量库”，而是在优化：被召回内容 + 用户问题 + 系统指令 + 推理空间如果 chunk 太大，你只能召回很少的条目如果 chunk 太小，你需要召回很多条目才能拼出完整信息这会直接影响回答稳定性和可控性。二、重叠长度怎么选，它解决的是什么问题重叠并不是为了“多一点信息”，而是为了防止语义被切断。 1. 重叠解决的核心问题自然语言的语义边界，几乎从不等于固定 token 边界。常见断裂点包括： a. 段落结尾提出问题，下一段才给答案 b. 本段定义概念，下一段才给约束条件 c. 列表或推导跨段完成如果不重叠，你会制造大量“半残废 chunk”。 2. 重叠长度的经验原则重叠长度通常只需要覆盖： “一个最小跨段依赖窗口” 经验上可以这样理解：重叠 ≈ chunk 大小的 10%–30% 举例： 500 tokens 的 chunk 50–150 tokens 的 overlap 就已经能解决 80% 的断裂问题 3. 重叠太大的副作用 a. 向量高度相似，召回时产生冗余 b. 有效信息密度下降 c. 排序时多个 chunk 竞争同一个语义位置所以重叠不是越大越安全，而是“刚好不断”。三、真正的权衡：你在优化什么系统目标切块策略背后，其实是三个目标在互相拉扯。 1. 召回精度更小、更聚焦的 chunk，有利于精确匹配查询意图 2. 语义完整性更大的 chunk，更容易提供完整上下文，减少幻觉和误解 3. 系统效率与稳定性 chunk 数量、向量库规模、召回冗余、上下文占用都会影响系统成本和稳定性这三者不可能同时最大化。四、举个例子如果让我在真实系统里做，我通常是这样定策略的。 1. 先按自然结构切优先按标题、段落、代码块、函数定义切，而不是按 token 切 2. 再设一个“软上限” 比如：单 chunk 超过某个 token 数，就再二次拆分而不是一开始就硬切 3. 最后用 overlap 做兜底只在自然边界处加 overlap，而不是机械地滑窗 4. 用真实查询回放验证不是看“看起来合不合理”，而是看： a. 命中率 b. 是否需要多 chunk 拼接才能回答 c. LLM 是否经常“答非所问但语义相关” #ai创造营# #程序员#

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

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

18. 很多家庭中发生的故事是这样的：父母制定规则 → 孩子做出承诺 → 孩子违约 → 父母加强控制。这是一个两败俱伤的权力螺旋。如何避免这种情况的发生？维吉尼亚·萨提亚（Virginia Satir，1916-1988）在她的体系中提出了“一致性沟通”的概念。如果我们把这个概念引入父母和孩子的关系中，尤其是针对处在青春期的孩子，就会形成一套反内耗、反权力对抗的相处模式。青春期冲突，本质不是“不沟通”，而是家庭还在用儿童期的结构，处理一个正在成年的个体。一致性沟通 + 可修订承诺，可以逐步把“管控关系”，升级为“协作关系”。家庭中的沟通与承诺

19. AnythingLLM是开源企业级私有知识库工具，核心基于检索增强生成（RAG）技术，专注本地文档语义解析与安全问答，无需依赖公网服务，适配企业内部知识沉淀、合规场景问答、跨部门信息共享等需求。 GitHub:github.com/Mintplex-Labs/anything-llm 主要功能： 1. 多格式文档兼容：自动解析PDF、Word、TXT等主流文档格式，批量构建结构化知识库；2. 全链路本地化：支持Ollama等本地模型部署，文档与对话数据不上云，完全保障隐私；3. 精准语义检索：基于向量数据库实现深度语义匹配，答案附带原文溯源，避免AI幻觉；4. 多端灵活部署：支持Docker自托管、服务器部署与桌面端运行，适配不同企业环境；5. 无代码快速搭建：可视化界面管理知识库，无需专业AI知识即可完成部署与维护；6. 生态扩展能力：支持自定义向量数据库接入、模型切换，可嵌入CRM等现有业务系统。操作门槛低，企业无需组建专业AI团队。实际使用中，跨部门文档检索效率提升80%+，合规场景下可满足数据本地化要求，是解决企业知识分散、检索低效且注重隐私安全的核心工具。

20. 刚刚，腾讯姚顺雨署名首篇论文发布，「下半场」先搞上下文学习

21. 通俗易懂的解释 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

22. #技术巡猎# #岚图汽车# “停车缴费方法、装置及设备”，啊……这个……车机到底敢不敢替你点开那个二维码？停车场扫码缴费大家都熟，掏手机，对准扫码，跳转连接，填车牌，付款，对吧？其实这件事本身不烦，往往真正让我烦躁的，是我后面有车催我呢，但是我扫完这个二维码各种广告业，然后钓鱼让我填什么优惠买保险，在你火急的时候不小心可能就付款错了。手机端来说，人还能凭经验“看一眼域名”，“感觉不对就关掉”，但如果真的交给车机了，它要是真“自动跳转”了，风险事实上就存在了。当把“自动扫码缴费”交给车的时候，天然就得先学会怀疑一切。这是岚图这个方案的核心动机，它是这么做的。车身摄像头采集停车缴费二维码，车机识别二维码里的目标信息（它这里默认目标信息是 URL 链接）---然后先做安全验证，验证通过才触发支付界面，让你最后点一下确认就付了。如果缴费网页要填车牌号，车机能调取预存车辆信息自动填写；支付可以预设微信/支付宝等应用，通过车机手机互联打通链路。体验层面的“少掏一次手机”，其实只是表面，真正的难点在“跳转之前那道门”，到底是什么。它把这道门拆成了三层。第一层是黑白名单校验模块。命中白名单直接放行，命中黑名单直接拒绝。白名单不仅来自“公司收集的有效停车缴费链接”，还包括一种比较现实的做法：个性化数据库---比如你在同一位置缴过费，车机会把“链接+地理位置”记下来，下次再遇到，就很有把握了。黑名单则收集恶意 URL（包含公司侧和用户侧可设定的那类）。这层本质上是“确定性优先”，速度快，对静态二维码也很友好。第二层是第一模型验证模块，专利举例叫“URL 监测器”。它做的是对 URL 的语义理解，然后输出两种置信度：认为安全的置信度、认为不安全的置信度。它设了两个阈值：安全置信度达到第一置信度就通过；不安全置信度达到第二置信度就拦。卡在中间---两边都不够高，就别猜了，交给第三层吧。第三层是第二模型验证模块（例子叫“网页监测器”），参数规模更大，速度更慢，但它更像安全工程：在分离环境里访问这个 URL，读取网页前端信息，再基于大模型甄别网页安全性，给出结论---遇到不确定的链接，就不只看字符串了，直接把网页打开“验尸”，但要在隔离环境里打开，如此，风险就不会带回车机系统本体。这套三段式验证，其实就是互联网安全在车上的落地：黑白名单是规则引擎，小模型是快速分类器，大模型是高成本仲裁者。它想要的不是“100% 不拦错”，只是把成本放在该放的地方：大模型只处理疑难样本，否则你每一次都在出口等它推理完，你没疯呢，后面等你的人疯了。它在采集二维码前，会先取车辆行驶速度---速度高于等于预设值就提示用户减速；低于预设值才会去采图，并且会把二维码图像亮度调到目标亮度再做采集。原因是清楚的：速度过高的话，摄像头抓不到；环境太暗或车灯打上去亮度过高也会影响清晰度。对图像的预处理也写了：降噪得到第一图像、去畸变得到第二图像，再去识别目标信息；并说明车身摄像头可能是鱼眼，所以要做去畸变---这就不是“演示版功能”了，它确实在认真处理“为什么扫不出来”这种低级但致命的问题。功能唤醒有两种情况：主动唤醒---语音或车机页面输入停车缴费指令；被动唤醒---车辆启动时，导航识别当前位置处于预设区域（停车场或导航收藏点），车机会先问一句要不要启动缴费功能，你确认后再走流程。它并不强行“全自动”，还是留了用户决策点，这点我觉得是对的：牵涉到支付的时候，越自作主张越容易翻车。当“扫码缴费”从一个交互问题，变成了一个安全系统问题的时候，很多车企做“无感”，就会把重点放在支付接入、车牌识别、停车场合作这些事情上面；岚图这份专利，更像是在面向“车端链接安全网关”做补课---只要你允许车机去打开外部链接，你就已经在做安全产品了，这些都躲不掉。真正的无感，绝对不是什么少掏一次手机而已。

23. 文档平台 Mintlify 发了一篇工程博客，讲了一件挺有意思的事：他们给自家 AI 文档助手造了一套假的文件系统，叫 ChromaFs，让 AI 以为自己在用 grep、cat、ls 这些命令浏览文件，实际上每个命令都被拦截、翻译成了数据库查询。效果很直接：会话启动时间从原来沙箱方案的 46 秒降到 100 毫秒，每次对话的边际计算成本几乎为零。Mintlify 之前的方案是标准的 RAG 流程：把文档切块、向量化、存进 Chroma 数据库，用户提问时检索最相关的片段喂给大模型。问题是，如果答案分散在好几个页面里，或者用户要的是某段精确的代码语法，向量检索经常找不对。他们想让 AI 像开发者翻代码一样翻文档，而不是靠语义相似度碰运气。核心思路是：AI 不需要真的操作系统，只需要一个足够逼真的幻觉。ChromaFs 基于 Vercel Labs 的开源项目 just-bash（一个用 TypeScript 重写的 bash 子集）构建。just-bash 提供了可插拔的文件系统接口，负责解析命令和管道逻辑，ChromaFs 则把所有底层文件操作翻译成 Chroma 数据库查询。每个文档页面变成一个"文件"，每个章节变成一个"目录"，AI 就可以用 grep 搜精确字符串、用 cat 读整页内容、用 find 遍历结构。之前用真沙箱的方案（给每个用户起一个微型虚拟机），按 Mintlify 月均 85 万次对话的量算，一年光计算成本就要 7 万美元以上。ChromaFs 复用了已有的数据库基础设施，这笔钱省了。grep 是最难虚拟化的命令。如果真让它逐文件扫描，走网络 IO 会很慢。ChromaFs 的做法是先把 grep 的参数解析出来，用 Chroma 的元数据查询做粗筛，找出可能命中的文件批量预取到缓存里，再让 just-bash 在内存中做精确匹配。权限控制也很优雅：初始化时根据用户身份裁剪文件树，没权限的路径直接从树里删掉，AI 连路径都看不到，不存在越权风险。所有写操作一律返回"只读文件系统"错误，AI 能随便看但改不了任何东西，整个系统无状态，不用担心清理和数据污染。这篇文章在 Hacker News 上引发了一个有意思的讨论。好几位开发者指出，大家不知不觉中把 RAG（检索增强生成）等同于了向量搜索，但 RAG 里的 R 是 Retrieval（检索），本来可以是任何方式：全文搜索、SQL 查询、甚至翻电话簿。把 RAG 绑死在向量数据库上，是早期技术路径的惯性。有人解释了这种惯性的由来：RAG 概念流行的时候，大模型还不太会用工具，多轮搜索和纠错能力也差，向量检索是当时最省事的方案。现在模型的工具调用和推理能力上来了，让 AI 自己决定用什么方式找信息，反而比预设一条检索管道更灵活。也有人提出了务实的质疑：Mintlify 的场景是结构化的技术文档，天然适合文件系统隐喻，但如果是组织内部那种乱七八糟、没有层级结构的知识库，这套方案未必好使。这个方向和 Claude Code 的做法有相通之处：与其把所有信息预检索好喂给模型，不如给模型一套探索工具，让它自己决定看什么、怎么找。对于正在搭建 AI 文档助手或内部知识库的开发者来说，Mintlify 的这套方案提供了一个向量检索之外的选项，尤其适合文档结构清晰、对精确匹配要求高的场景。

24. 提示词工程、上下文工程都过时了，现在是 Harness Engineering 的时代

25. Agentic RAG 技术栈图谱，揭示构建智能代理系统的核心层级与关键组件：Level 0 部署与基础设施涵盖Groq、AWS、together.ai、Baseten、Modal、Fireworks AI、Replicate等，保障模型和系统的高效运行环境。Level 1 评估与监控 LangSmith、MLflow、Weights & Biases、Hugging Face、Deepchecks、Fairlearn等，负责模型性能、偏差与安全性监测。Level 2 基础模型包括Claude 3.7 Sonnet、Mistral AI、Cohere、Gemini 2.5 Pro、LLAMA 4、GPT-4等，提供强大的语言理解和生成能力。Level 3 编排框架 LangChain、DSPy、Microsoft AutoGen、Adaflow、LiteLLM、Ray、Haystack等，实现多模型、多任务的流程控制与协同。Level 4 向量数据库 Milvus、Redis、Pinecone、Elasticsearch、Chroma、Vald等，负责高效存储与检索海量向量化信息。Level 5 嵌入模型 Voyage AI、OpenAI、spaCy、FastText、Hugging Face、Cohere等，支持文本向量表示转换，为检索和推理提供基础。Level 6 数据摄取与提取 Scrapy、Firecrawl、Docling、Llamaparse、Amazon Textract、Apache Tika等，完成多源数据采集与结构化处理。Level 7 记忆与上下文管理 Letta、mem0、Zep、Chroma、Cognec、LangChain、LlamaIndex等，管理长期与短期记忆，提升对话连贯性。Level 8 安全与治理 Langfuse、Arize、Evalverse、Helicone、Guardrails AI、HELM、AI Explainability 360、AI Fairness 360等，保障系统透明、公平与安全，防止滥用。总结：这套Agentic RAG技术栈不仅涵盖了从底层基础设施到高层治理的全流程，也体现了智能代理对性能、数据、记忆与安全的多维度要求。掌握这张图谱，是迈向智能代理实用化的关键。

26. 「Github一周热点93期」多智能体舆情分析、桌面 AI 助手、自然语言画图、Rust桌面组件库、Linux服务器安全和GitHub绿墙

27. 「Github一周热点98期」AI文档检索框架、微软最新TTS、Claude Code 记忆插件、自动化备份、 jellyfin和linux桌面环境

28. 告别KV Cache枷锁，将长上下文压入权重，持续学习大模型有希望了？

29. 告别生成排队，彻底实现顶流模型创作自由

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

31. 向量数据库到底是怎么工作的？一、基础：向量嵌入（Vector Embeddings）首先，你的数据（无论是文本、图像还是音频）都会被转换成向量嵌入——也就是一组数字数组，用来表示内容的语义含义。可以把它想象成高维空间中的坐标点：含义相似的内容会聚集在一起，形成语义上的“簇”。二、挑战：规模（Scale）真正的难点在这里。如果你有上百万个向量，想找到与某个向量最相似的对象，逐个比较是不现实的——那会耗费巨大的时间。这就是**向量索引（Vector Indexing）**登场的地方。三、向量索引向量索引的作用是组织和优化这些嵌入，让相似向量可以被高效检索。本质上，它在搜索速度、准确率和资源占用三者之间寻找平衡。最常用的一种算法是 HNSW（Hierarchical Navigable Small World）。它会建立一个图结构，把相似的向量节点连接起来。当你查询时，系统就能在图中快速“跳跃”，找到与你的查询向量相似的那些节点。四、搜索过程当你在向量数据库中发出查询时，系统会经历以下步骤：1. 将查询内容转换为向量嵌入；2. 使用距离度量（如余弦相似度）来判断各向量之间的“接近程度”；3. 借助索引结构，快速定位最相似的向量；4. 返回最相关的结果，而不必遍历所有向量。五、权衡取舍不同的索引策略会有不同的取舍：有的更注重速度，但牺牲部分精确度（称为“近似最近邻”搜索）；有的追求完全准确，但耗时更长。六、总结令人着迷的是，这种“把语义表示为数字、再去寻找相似数字”的简单思想，支撑了如今的语义搜索、RAG 检索增强生成系统、推荐引擎等各种智能应用。#人工智能##程序员#

32. 「Github一周热点96期」Flux2绘图模型、腾讯的视频生成模型、AI记忆、开源Launchpad、笔记和知识库，Nginx可视化工具

33. #一分钟视频创作季# Andrej Karpathy：高质量交互环境才是AI发展的沃土Andrej Karpathy 指出“当前 AI只是统计专家而非真正的思考者。”脱离真实交互的 AI 终将局限于模仿人类已知知识，而构建多样化高质量交互环境，才是突破这一困局的关键。Karpathy 强调的，AI需在类真实场景中试错学习。例如虚拟物理实验室需精准还原力学定律，分子模拟环境要符合化学反应规律，就像 AlphaGo Zero 的围棋环境虽为虚拟，却严格遵循真实棋规，才能孕育出超越人类的策略。若环境与现实脱节，AI 习得的能力将无法迁移到实际任务中。环境需覆盖多领域场景与难度层级，从基础操作到复杂决策形成完整训练链条。PrimeIntellect 的环境中心理念给出了绝佳范例：将教科书习题重构为可交互环境，既包含基础数学演算，也涵盖高阶物理实验。这种设计能让 AI 像人类一样循序渐进学习，避免因场景单一导致的能力固化。环境必须提供清晰、及时的结果反馈，这是 AI 调整策略的核心依据。AlphaProof 在数学环境中通过证明有效性即时判断行动价值，生成数百万条新证明，正是得益于明确的反馈机制。Karpathy 特别提醒，模糊的奖励函数会误导学习，因此反馈需如科学实验结果般可验证、可量化。环境能精准模拟现实、覆盖多元任务、提供明确反馈时，通用智能体的诞生才真正具备了土壤。#有点东西##AI创造营##微博兴趣创作计划# 种斌Marco的微博视频

34. 同事.skill只是一个整活？其实已经落地了。我记得前几年还有程序员出主意说可以在代码里「埋雷」，包括但不限于多层嵌套、不写注释、故意加入只有自己才懂的触发条件等等，增加别人的接手成本，作为一种保护性的防裁员技巧。但AI来了之后也基本破除了这种自保心思，代码都不再是人来维护了，而模型管你这的那的，烧点Token就能全部清洗一遍，万物皆可蒸馏。

35. github.com/Tencent/WeKnora 腾讯开源的RAG框架：WeKnora（维娜拉）这是一款基于大语言模型的文档理解与语义检索框架，专为结构复杂、内容异构的文档场景而打造。框架采用模块化架构，融合多模态预处理、语义向量索引、智能召回与大模型生成推理，构建起高效、可控的文档问答流程。核心检索流程基于 RAG（Retrieval-Augmented Generation）机制，将上下文相关片段与语言模型结合，实现更高质量的语义回答。核心特性 🤖 Agent模式：支持ReACT Agent模式，可调用内置工具检索知识库、MCP工具和网络搜索，通过多次迭代和反思给出全面总结报告 🔍 精准理解：支持 PDF、Word、图片等文档的结构化内容提取，统一构建语义视图 🧠 智能推理：借助大语言模型理解文档上下文与用户意图，支持精准问答与多轮对话 📚 多类型知识库：支持FAQ和文档两种类型知识库，支持文件夹导入、URL导入、标签管理和在线录入 🔧 灵活扩展：从解析、嵌入、召回到生成全流程解耦，便于灵活集成与定制扩展 ⚡ 高效检索：混合多种检索策略：关键词、向量、知识图谱，支持跨知识库检索 🌐 网络搜索：支持可扩展的网络搜索引擎，内置DuckDuckGo搜索引擎 🔌 MCP工具集成：支持通过MCP扩展Agent能力，内置uvx、npx启动工具，支持多种传输方式 ⚙️ 对话策略：支持配置Agent模型、普通模式模型、检索阈值和Prompt，精确控制多轮对话行为 🎯 简单易用：直观的Web界面与标准API，零技术门槛快速上手 🔒 安全可控：支持本地化与私有云部署，数据完全自主可控 #科技先锋官#

36. RAG退潮，“文件系统+grep”回归，智能体检索的返璞归真

37. 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

38. 在构建面向大语言模型（LLM）的长期记忆系统时，如何实现高效、可扩展的知识图谱存储与语义检索？Memento MCP 提供了一套完整解决方案。这是一个基于 Neo4j 的知识图谱记忆系统，支持实体与关系的版本管理、时间感知和置信度衰减，结合向量嵌入实现高质量的语义搜索。它兼容支持 Model Context Protocol 的 LLM 客户端，如 Claude Desktop、Cursor 等，能够为对话模型提供持久、上下文丰富的本体记忆。主要功能包括：- 实体和关系的完全版本历史追踪，支持任意时间点的图谱状态查询；- 结合向量搜索和关键词检索的混合语义搜索，提升查询准确度和覆盖率；- 关系强度与置信度动态衰减，保证记忆信息的时效性与可靠性；- 丰富的元数据支持，包括来源、标签和时间戳，方便分类与过滤；- 多平台兼容，支持通过 Neo4j Desktop 或 Docker 快速部署；- 提供命令行工具简化数据库管理与调试。适合需要构建智能助理、对话系统或知识管理应用的开发者使用。详细文档和源码请访问：GitHub：github.com/gannonh/memento-mcp可通过简单配置，即刻为你的 LLM 应用注入强大且灵活的知识图谱记忆能力。

39. #一分钟视频创作季# 突破 AI 算力瓶颈：英伟达 Spectrum-X 如何重构数据中心网络当万亿参数大模型训练时，数千张 GPU 协同产生的海量数据传输，常让传统以太网陷入带宽浪费困境，利用率仅 35%~40% 的网络成为算力释放的关键瓶颈。Spectrum-X 以太网解决方案破解了这一难题，将成为AI工厂的高性能神经系统。Spectrum-X三重突破：无损传输通过 PFC 流量控制与 ECN 拥塞通知，实现微秒级反馈避免数据包丢弃，彻底告别传统网络的丢包重传延迟；自适应路由采用逐包动态负载均衡，由 Spectrum-4 交换机实时选择最优路径，配合 BlueField-3 SuperNIC 完成乱序重组，让带宽利用率飙升至 95%。硬件级拥塞控制依托交换机内置遥测技术，精准调节数据注入速率，根除多 GPU 同步引发的 Incast 拥塞。在实际场景中，Spectrum-X 已展现硬核价值，在 Israel-1 超级计算机上将 800 GPU 集群的读带宽提升 48%，使 TB 级模型 Checkpoint 保存时间大幅缩短，避免训练中断导致的算力浪费。Oracle 用其构建十亿瓦级 AI 工厂，实现数百万 GPU 高效互连，加速生成式 AI 部署；Meta 则将其集成到 FBOSS 系统，为数十亿用户的 AI 服务提供稳定低延迟的网络支撑。对于检索增强生成场景，Spectrum-X 使向量数据库的检索延迟显著降低，助力多租户 AI 服务每秒处理数千查询。#有点东西##AI创造营##微博兴趣创作计划# 种斌Marco的微博视频

40. 突破一亿Token极限：EverMind提出MSA架构，实现大模型高效端到端长时记忆

41. Weaviate的免费电子书：《上下文工程（Context Engineering）》你是否也遇到过这样的问题？用强大的大语言模型（LLM）做应用时，模型能写能总结能推理，但面对你的专属数据却无能为力，甚至自信地“胡编乱造”。问题不在模型智能，而是它被“孤立”了——没有访问你的私有文档，没有实时信息，没有记忆。这正是“上下文工程”（Context Engineering）的核心挑战：设计系统，让模型在合适的时间获得正确的信息，连接外部知识库和工具，赋予它记忆，帮它在真实世界中可靠工作。这本电子书详细讲述了如何打造这样的系统：1. 智能代理（Agents）：它们不再盲目执行固定流程，而是动态判断、选择工具、调整策略，甚至修正错误，像个有头脑的“指挥官”。2. 上下文窗口的限制与管理：模型的工作记忆有限，不能简单扩容。要懂得剔除无关信息、压缩摘要、防止信息冲突和错误积累，才能保持“思路清晰”。3. 查询增强（Query Augmentation）：通过重写、扩展、拆解查询，提升检索准确度，让模型更懂你的问题。4. 文档切片（Chunking）策略：如何拆解文档成既精确又完整的小块，是检索表现好坏的关键。预切片和后切片各有利弊，复杂文档更需要层级和语义切片。5. 记忆管理：短期记忆为即时推理服务，长期记忆保存事实和经验。高效的记忆管理防止信息污染，支持多层次记忆结构，提升连贯性和智能度。6. 工具集成（Tools）：模型借助外部API和功能调用，才真正能够“动手”解决问题。精确的工具描述和合理的调用逻辑，是提升系统可靠性的秘诀。7. 编排挑战（Orchestration）：让代理知道何时用什么工具、如何构造参数、如何根据结果调整策略，形成“思考-行动-观察”的闭环。8. 未来趋势：Anthropic提出的“模型上下文协议”（Model Context Protocol，MCP）将实现AI应用与工具的标准化连接，告别碎片化集成，迈向模块化、组合式AI系统。总结来说，打造智能AI应用的关键不再是更大更复杂的模型，而是更精妙的上下文系统设计。上下文工程让我们从“给模型写提示词”升级为“构建模型的世界”。掌握代理、查询增强、检索、记忆和工具的协同，才能让AI真正“活”起来。🔗 weaviate.io/ebooks/the-context-engineering-guide这就是我们，构建未来AI的工程师，正在重新定义智能的边界。你准备好了吗？

42. 免费电子书《The Context Engineering Guide》Context Engineering（上下文工程）远非简单往提示词里堆数据，而是设计智能系统，在恰当时间、用合适格式，动态提供精准信息。关键不在于单纯扩大模型上下文窗口，而是如何高效利用有限的“活跃上下文”。真正的挑战是“编排”——让系统内部各模块（提示设计、检索增强、代理协作、记忆管理等）无缝协作，抵御人类和模型本身的错误。只有这样，AI系统才能突破模型固有限制，变得稳健且实用。这就是为什么Context Engineering将成为AI应用开发的核心复杂性。你需要让系统智能决定：- 什么信息放入活跃上下文- 何时总结压缩节省空间- 什么内容外部存储并按需调取- 如何精准路由查询到合适工具- 代理之间如何协同完成专业任务Victoria团队发布了完整电子书，详解如何构建这样的高效系统：从代理（Agents）、记忆系统（Memory Systems）、查询增强（Query Augmentation）、检索策略（Retrieval）到工具调用与提示循环（Tools & Prompting）。书中包含实战案例和架构图，直击从模型到生产级应用的瓶颈。业内反馈一致认为，单纯扩大上下文窗口是“懒办法”，真正难点在于设计类似人类记忆的动态、分层记忆系统。Context Engineering是连接理论与落地的桥梁，是AI技术走向成熟的必由之路。这不仅是技术细节，更是AI系统设计的艺术和哲学。掌握它，才能构建出既聪明又稳健的智能应用。电子书下载（含架构详解与实操指南）：weaviate.io/ebooks/the-context-engineering-guide——思考：信息的力量不在于量多，而在于何时何地以何种方式被激活。未来AI的竞争，不是单纯模型大小，而是对“上下文生命线”的精妙编排。设计智能系统，就是设计未来人与机器共舞的节奏。

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

44. 【2026年AI工程师学习路线：从调用模型到构建系统的九个关键能力】AI工程和传统机器学习工程正在分道扬镳。机器学习工程师从零训练模型，AI工程师则在基础模型之上构建应用。这个转变意味着你需要学习的东西完全不同了。一、理解基础模型GPT、Claude、Gemini、Llama这些基础模型是现代AI应用的基石。你不需要从头训练，但必须深入理解它们的能力边界、分词机制、上下文窗口和定价策略。成本控制能力往往决定了一个AI应用能否活下去。入门项目：做一个模型对比笔记本，用同样的10个提示词测试不同模型，记录质量、速度和风格差异。二、提示词工程在AI工程领域，提示词就是你的代码。一个平庸的AI应用和一个优秀的AI应用，差距往往就在提示词设计上。少样本学习、思维链、结构化输出这些技术能大幅提升效果，而且不需要任何模型训练。入门项目：选一个任务，写五种不同风格的提示词，在电子表格里打分对比。三、检索增强生成大模型有知识截止日期，还会产生幻觉。RAG让它们扎根于你的数据。从客服机器人到内部知识助手，这是生产环境中最常见的AI应用模式。分块策略、嵌入模型、向量数据库、检索指标，这些都是必修课。入门项目：用你自己的笔记文件搭建一个简单的RAG应用，50行代码就能跑起来。四、评估与测试凭感觉评估无法规模化。你需要系统性的方法来衡量AI应用是否在进步：构建评估数据集、选择指标、跑AB测试、检测性能退化。没有好的评估体系，你就是在盲飞。入门项目：准备20个问答对，写个脚本自动评分，每次改提示词都跑一遍。五、智能体与工具调用智能体把大模型从文本生成器变成行动执行者。它们能浏览网页、执行代码、查询数据库、调用API。理解智能体架构、工具设计和失败模式，是构建自主AI系统的关键。入门项目：做一个计算器智能体，让它通过调用工具来回答数学问题。六、结构化输出与数据提取真实应用需要结构化数据，JSON、SQL、API调用，而非自由文本。JSON模式、函数调用、约束生成这些技术确保大模型输出能与下游系统对接。这是对话式AI和软件工程之间的桥梁。入门项目：做一个食谱提取器，把网页上的乱七八糟的文本变成干净的JSON结构。七、护栏与安全AI应用可能被越狱、产生有害内容、泄露敏感信息。输入输出护栏、隐私检测、内容过滤、对抗测试，这些在生产部署中不可或缺。入门项目：给你的聊天机器人加上简单的输入输出过滤，用关键词匹配检测提示词注入。八、可观测性与监控无法衡量就无法改进。生产级AI系统需要日志、追踪、成本跟踪、质量监控和告警。入门项目：给你的应用加上调用日志，记录时间戳、提示词、响应、延迟、token数量和估算成本。一周后分析数据，你会发现很多优化空间。九、AI系统架构真实的AI应用是多个组件的组合：检索器、模型、护栏、缓存、数据库。理解复合AI系统的设计模式，才能构建可维护、可测试、可扩展的架构。综合项目：做一个个人助手机器人，整合RAG、结构化输出、输入验证和日志记录，部署到免费平台上。这就是一个能展示真实能力的作品集项目。有评论提出了一个值得深思的观点：2026年AI工程师真正的核心能力，是知道哪些层该自己掌控，哪些层该交给框架处理。这个答案每个季度都在变。智能体正在以超出学习速度的节奏压缩技术栈，RAG、结构化输出、护栏越来越多地被内置到平台中。学会构建固然重要，学会判断何时不必亲自构建，可能更重要。x.com/manthanguptaa/status/2018297734995075200

45. AI学会“科学交接班”，解决上下文难题——Anthropic智能（牛马）方法论

46. 这个模型有机会成为世界模型的Deepseek#AI #大模型 #世界模型 #北京人形机器人创新中心 #北京人形WoW具身世界模型

47. 让AI帮你体验不同的人生！我用无代码开发做了个小程序，内置Nano Banana、Gemini等大模型

48. 说实话，我认为记忆力是目前持续学习的最大障碍。让我夜不能寐的问题是：我们如何利用记忆避免重蹈覆辙？我们如何教会模型有选择地记忆和遗忘？何时呈现正确的背景信息？人类通过记忆巩固、干扰管理和情境绑定自然而然地做到这一点，然而，我们尚未找到复制这种机制的方法。人类海马系统与当前LLM记忆架构之间的差距揭示了一个根本性的挑战：我们基本上构建了两个极端：要么是将所有信息都硬编码到参数中的模型（刚性模型），要么是使用RAG（随机数生成器）机械地检索信息（模糊模型）。真正的持续学习要求我们破解智能检索的密码；不仅要知道存储什么，还要知道抑制什么、何时强化，以及如何让旧知识优雅地消退而不造成灾难性的干扰。非常喜欢这篇调查，因为它从宏观角度展现了 LLM 和多模态模型中的记忆架构（也很喜欢其中受大脑启发的分类法，很棒！）。我会尽我所能系统地绘制出它的图谱。三部分框架：他们围绕新皮层-海马体-前额叶皮层的类比来构建记忆：内隐记忆/新皮层涵盖了嵌入模型权重中的参数知识，包括记忆编辑技术（如 ROME 和 MEMIT，它们通过精确修改权重来更新事实）、通过 LoRA 等适配器注入知识，以及通过记忆遗忘来删除有害内容。显性记忆/海马体研究外部检索系统；RAG架构、向量数据库、知识图谱。它们详细阐述了如何在不同的粒度（文档、组块、句子、图结构）和优化时间（无训练、联合预训练、SFT等）下组织记忆。智能体记忆/前额皮层探索自主智能体如何维持短期记忆（CoT++）与长期记忆（外部事实数据库、历史轨迹、用户反馈等）。我非常喜欢这个关于记忆的思考框架，但我认为除了分类之外，这项调查最大的贡献在于指出了尚未解决的问题：记忆污染/幻觉、大规模检索的计算负担、何时应该检索信息而不是依赖参数化知识，以及长时间交互过程中记忆一致性的挑战#科技先锋官##ai生活指南##ai创造营#

49. Agent 框架记忆问题的解法～用过 LangChain、CrewAI 这些 Agent 框架的都知道一个痛点：它们的记忆管理很鸡肋。大多数框架的做法是：短期放在列表里，长期靠 RAG 检索。听起来合理，实际很脆弱。问题在哪？1. 信息丢失。RAG 只会检索出片段，但对话的整体脉络、为什么重要、前后的因果关系都丢了。用户说"上次那个项目"，Agent 可能查出相关文档，但根本不知道用户为什么关心这个项目。2. 幻觉加倍。Agent 基于零碎的检索结果推理，没有全局认知，自然容易编造细节。3. 记忆冲突。同一件事在不同时间表述可能不一样，Agent 也不知道哪个才是"真相"，结果前后矛盾。核心问题：RAG 本质是"我记不全，就检索部分"——但这对需要全局一致性的 Agent 任务来说，根本不够。文章的解法：混合记忆架构，不是非此即彼，而是分层：第一层：实时记忆 —— 最近 N 轮对话完整保留，一个字都不丢。这保证了 Agent 对当前对话的理解是准确的。第二层：压缩记忆 —— 更早的对话不是直接存，而是压缩成摘要。比如 50 轮对话压缩成"5 个关键决定 + 3 个重要背景"。成本低，还保留了信息密度。第三层：语义检索 —— 用向量数据库索引压缩后的记忆。这样检索时找的是"高浓度摘要"，而不是淹没在海量文档里。第四层：验证 —— 最关键的一步。Agent 每次从记忆里检索出来东西，要自己验证一下："这个旧记忆和我现在的对话一致吗？"不盲目信任。为什么这个方案值得用？1. 解决了 RAG 的致命问题——记忆有连贯性，Agent 知道全局脉络，不再前后不一。2. 成本可控——压缩记忆大幅降低向量库规模和 token 消耗，相比把所有历史都存下来，省一个数量级的钱。3. 可验证——加验证层，Agent 不会死板地信任过期的记忆。适用场景：- 长期对话的 AI 助手（用户期望 Agent 真的"记得我们的历史"）- 复杂多轮谈判或诊断（需要一致决策，不能前后矛盾）- 需要积累知识的任务流不适用的场景：- 单轮或短对话（没必要这么复杂）- 纯知识库查询（RAG 本身够用）原文：dev.to/diego_falciola_02ab709202/every-ai-agent-framework-has-a-memory-problem-heres-how-i-fixed-mine-1ieo#HOW I AI# #程序员#

50. 盘点一周AI大事(3月8日)｜龙虾开公司30天狂赚8万刀工程师Nat Eliason开发出首个龙虾CEO「FelixCraftAI 」，全自主运营零人类公司，30天狂赚8万刀工程师开源龙虾公司框架Paperclip 工程师开源龙虾员工管理平台Clawith 工程师开源龙虾浏览器Pinchtab 老黄放话，龙虾是是历史上最重要的软件发布，通用型自主Agent终于迎来爆发拐点 OpenAI开源龙虾项目管理工具Symphony OpenAI发布最强龙虾基座模型GPT-5.4，地表最强大模型再次易主 Google发布最强龙虾辅助模型Gemini 3.1 Flash-Lite Lightricks发布最强开源视频模型LTX-2.3 Showlab推出最强开源视频编辑模型Kiwi Edit #抖音年味新知贺岁 #前沿科技趋势发布月 #AI新星计划 #龙虾 #OpenClaw

51. 日常与数据库打交道时，想直接用自然语言查询数据，写SQL总是费时费力。Vanna 是一款开源的 Python 框架，利用最新的检索增强生成（RAG）技术，帮你把自然语言自动转成精准的SQL语句，支持多种主流数据库和大语言模型。它不仅能训练专属的问答模型，还能直接执行生成的SQL，返回查询结果和数据可视化图表，极大提高数据分析效率。Vanna 支持PostgreSQL、MySQL、Oracle等数据库，兼容OpenAI、Anthropic等多种LLM，使用灵活且安全，数据不会外泄，所有SQL都在本地执行。安装简单，pip 一键搞定，文档详细，新手也能快速上手。无论是数据科学家、开发者，还是业务分析师，都能从中受益。项目地址：github.com/vanna-ai/vanna主要功能：- 自然语言转SQL，精确执行复杂查询- 支持多种数据库和主流大语言模型- 训练自定义RAG模型，提升问答准确度- 查询结果同步返回表格与可视化图表- 代码开源，MIT许可证，社区活跃- 多种用户接口示例，方便二次开发和集成想用更简单的方式跟数据库“对话”？Vanna 帮你开启智能数据查询新时代。

52. 构建智能问答系统通常面临查询模糊、上下文理解不足和检索效率低等挑战。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 研究者、开发者及数据工程师，轻松构建满足生产需求的智能问答系统。

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

54. LightRAG 是一个简单快速的检索增强生成（RAG）框架，能高效整合大语言模型和知识图谱，实现智能文档查询和多模态检索。LightRAG支持多种存储方案（PostgreSQL、Neo4j、Milvus、OpenSearch等），支持文本、图片、表格、公式等多种数据类型的端到端知识抽取和问答。还提供了丰富的示例代码、Web UI，以及支持OpenAI、Hugging Face、Ollama、Azure OpenAI等多家模型接口。项目亮点：- 灵活配置的多存储架构，适合大规模知识管理；- 深度集成知识图谱构建与编辑，支持实体关系管理、知识图谱可视化；- 支持强大的Reranker提升检索效果；- 新增RAG-Anything，打通多模态文档处理与检索能力；- 丰富文档导入格式、引用功能、缓存管理、Token使用统计；- 还支持Langfuse可观测性监控以及RAGAS自动评价指标。无论是科研研究、企业知识库、还是多模态智能问答应用，LightRAG都提供了极具扩展性且高性能的解决方案。GitHub：github.com/HKUDS/LightRAG#在线智能检索# #知识图谱# #大语言模型# #RAG# #开源项目#

55. 普通人如何充分利用AI！NAS部署AgentChat，打造最强知识库

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

57. 「Github一周热点105期」Rust 版openclaw，本地语音克隆工具，Qwen3.5， AI 渗透测试系统和精美源码图片生成工具

58. 3D打印不再翻车！大模型/手办打印超全指南

59. 数据科学工作流程复杂，涉及规划、执行、验证和反思多个环节，单靠传统工具难以高效协作和持续优化。Agentic Data Scientist 是一个基于多智能体架构的开源框架，利用 Google Agent Development Kit 和 Claude Agent SDK，实现了从智能规划到分阶段执行再到持续校验的闭环工作流。它能自动拆解任务，迭代优化方案，结合先进的科学技能库和模型上下文协议工具接口，帮助数据科学家高效完成复杂分析任务。主要功能包括：- 自适应多智能体协同工作，迭代规划与执行保障质量；- 任务分阶段管理，实时跟踪成功标准与进度；- 集成 Claude 科学技能库，支持多种科学计算和数据处理；- 文件管理与网络检索工具，方便数据导入与外部信息获取；- 灵活部署，支持命令行快速启动，满足多场景需求。适合需要系统化、多步骤数据分析的科研人员与工程师，项目地址：github.com/K-Dense-AI/agentic-data-scientist从规划到总结，Agentic Data Scientist 用智能化分工和不断的自我校正，助力数据科学项目更高效、更可靠地推进。

60. 四图搞懂 RAG、AI Agent、Agentic RAG!