这一年“RAG 已死”的说法甚嚣尘上，比如《长上下文窗口、Agent 崛起，RAG 已死？》、《The RAG Obituary: Killed by Agents》。而像 Claude Code、Codex 这类新一代 Agent CLI 也纷纷放弃了 embedding，官方直接承认：不建索引、不用向量库，靠 LLM 驱动 Grep 就够用。RAG 真的不适合现在的 Agent 了吗？围绕这个问题，我们展开了深入调研，同时对Claude Code 等前沿解决方案的源码进行了拆解，最终形成本文力求回答 RAG 在 Agent 时代是否还有一席之地这一核心关切点。
先做个自我介绍。我是一名游戏客户端开发工程师，日常工作在 Unity 引擎开发。从去年开始高强度使用 AI 辅助开发，一开始只是让它帮我补补代码、查查 API，后来越用越深入，逐渐突破了自己原有的技术边界——借助 AI 的能力和公司内网提供的工具链，我独立给项目组交付了 WPF 桌面启动器、好几个内部提效的 Web 站点、还有一堆企业微信机器人。这些东西放在以前，对一个纯客户端出身的人来说几乎不可能独自完成。正是这段经历让我对"如何高效驾驭 AI"这件事有了很多切身体会，也是写这篇文章的出发点。
2026 年 4 月 24 日上午，DeepSeek 又一次把"开源炸弹"丢进了大模型圈。没有预热，官微只有一句话：“今天，我们全新系列模型 DeepSeek-V4 的预览版本正式上线并同步开源”。从评分上看，这次的模型已经非常接近“闭源三巨头”的水平了，同时也是当之无愧的“地表最强开源模型”。但细读这份技术报告「DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence」，会发现DeepSeek的工作远比评分更硬核，无论是架构创新还是工程优化都是一如既往的精雕细琢。
当 Harness Engineering 成为 2026 年最热门的 AI 工程话题，业界争论焦点集中在"该用多大的模型"还是"该搭多复杂的工作流"时，我们团队在落地实践中发现了一个被低估的事实——构建 Harness 工作流不是最终目的，私域和团队知识的沉淀才是真正的技术护城河。本文分享我们在 AI Team 工程交付编排系统中，如何设计知识分层架构、如何让团队知识库共建共享、如何让工作流成为知识沉淀的载体、如何突破人机交互瓶颈实现随时随地的工作流流转，以及我们的落地经验和思考。
在AI 效率狂奔的时代，你有多久没有好好看完一本书了？「大厂书单」第一期，我们问了鹅厂员工们最近都在读什么书，他们来自不同的岗位，答案也出乎意料地丰富。
AI 正在深刻改变软件开发的方式。从最初的代码补全，到如今的自主式 AI Agent，开发者与 AI 的协作模式正在快速演进。在这个过程中，一种被称为 vibe coding 的实践模式率先流行——开发者将需求直接抛给 AI，不审查 diff、不理解生成的代码，凭直觉接受输出，以最快的速度得到"能跑"的结果。Vibe coding 在原型验证和个人项目中有其价值，但它的本质是用速度换取了理解和控制，无法承载生产级系统的质量要求。 Agentic Engineering 代表了一种截然不同的范式 [1]。它是一种工程师与 AI Agent 深度协作的模式——AI 不仅是代码的执行者，也是问题分析、方案设计等环节的思考伙伴；但最终的判断和决策权始终在工程师手中。它不是"让 AI 替你写代码"，而是将工程纪律与 AI 能力系统性地结合，在保持甚至提升质量标准的前提下，大幅提升研发效能。
Harness Engineering 的概念已经火了有一阵了，全网很多文章基本都是在讲理念，讲为什么今天做 AI 开发，不能只靠一段提示词，也不能把模型当一个“更聪明的代码补全”。
为什么Hermes的爆炸性增长让整个行业重新审视Agent的发展方向？对于正在技术选型中摇摆不定的开发者们，又该如何在Hermes和OpenClaw之间做出正确的决策？
当 AI Coding 的聚光灯几乎全部打在前端和客户端——生成一个页面、写一个 App......的时候，一个重要的问题却似乎被回避了：AI 能在真正"出事会炸"的后端系统里写代码吗？腾讯CDN LEGO项目就是这样一个系统。100万行核心代码、300万行深度改造的第三方库，服务亿级用户，承担流量调度、协议解析、安全防护、缓存加速等关键职责。它面对的不是确定性的输入输出，而是不可控的客户端、不可控的源站、多协议、多配置、公网全量攻击面——这些因素维度的叠加不是简单相加，而是乘积式的复杂度爆炸，理论组合路径高达 13,824 × N 种。在这样的复杂的系统里让 AI 写代码，一行失误就可能是一场全网事故。但正因为难，才值得做。
