别急着给 RAG 加 Agent，先看复杂性放错了没有

Mon, 29 Jun 2026 21:05:03 +0800

内部知识库上线以后，最怕的不是它直接说“不知道”。

最怕的是它回答得很顺。

用户问：“远程办公政策对外包同事怎么适用？”系统召回了远程办公制度，给了一段完整解释，甚至还附了引用。看起来没问题。但真正限制写在外包合同里，它没召回。

这时候团队很容易有一个冲动：加一个 agent，让它自己检查，自己重查，自己判断答案够不够。

听起来合理。

但你先别急。

很多 RAG 系统的问题，不是因为它还不够 agentic，而是最基础的检索账没算清楚：chunk 切得太粗，metadata 没用起来，rerank 没有，文档新旧混在一起，评估集也没有。这个时候上 Agentic RAG，只是让系统用更多 token、更长链路、更难调试的方式，继续召回错误材料。

RAG 选型里最容易误判的一点就在这里：标准 RAG、Graph RAG、Agentic RAG 不是从低级到高级的升级路线。

它们真正的区别，是复杂性放在哪里。

标准 RAG 把复杂性放在固定检索管线里。Graph RAG 把复杂性提前做成图谱和摘要这些索引资产。Agentic RAG 把复杂性放到运行时，让 agent 每次查询时做拆解、选源、判断和重试。

复杂性不会消失。你只是决定让谁承担它。

标准 RAG：如果答案就在文档里，它仍然是起点

标准 RAG 的基本流程，大多数人已经很熟：用户问题转成 embedding，到向量库里找相似片段，取 top-K chunks，塞给 LLM，让它基于上下文生成答案。

这套东西看起来简单，但简单不是缺点。

在很多企业知识库场景里，它反而是优势：路径短、成本低、延迟可预测，出了问题也比较容易定位。你能看到召回了哪些 chunks，能检查 prompt，能看 rerank 前后顺序，能把错误归到“没召回”“召回了但排序靠后”“上下文太长被淹没”“文档本身过期”。

这就是工程系统里很重要的一件事：可解释的失败，比聪明但黑盒的失败好处理得多。

标准 RAG 适合的问题，通常有几个特征：

用户问题比较明确。
答案通常就在少数文档片段里。
知识源比较干净，比如 FAQ、产品手册、内部制度、开发者文档。
业务更在意稳定、便宜、低延迟。

比如员工问“年假怎么折算”，客服问“退货周期是多少”，开发者问“这个 API 的鉴权参数怎么传”。这类问题不需要系统像侦探一样跨系统调查。它只需要把正确片段找出来，不要把相似但无关的片段拿回来。

标准 RAG 真正脆弱的地方也在这里。

它通常不会主动判断：我召回来的这些东西，真的回答了问题吗？

如果 top-K 错了，后面的 LLM 往往会基于错误上下文写出一个很像回事的答案。尤其是企业知识库，很多制度文档长得很像，标题也像，语气也像。相似不等于有用，但向量检索很容易把“相似”当成“答案”。

Go 后端转 AI Agent，值不值？我查了一圈招聘要求

Thu, 25 Jun 2026 13:30:00 +0800

网上说 Go 后端转 AI Agent，动不动 40K、60K。

我第一反应不是激动，是怀疑。

这类说法太容易变成培训班招生，也容易被技术圈一句“套壳”打掉。我去翻了一圈公开招聘页，结论比这两种都别扭一点：

30K-60K 的样本确实存在，但它买的不是“会写 prompt 的 Go 后端”。

它买的是另一种人：能把 LLM、RAG、工具调用、多步任务、权限、观测、成本和失败恢复，塞回一个真实后端系统里的人。

如果你是 3-8 年 Go 后端，做过微服务、Redis、MySQL、Kafka、K8s、限流、日志和监控，这件事值得认真看。

但不要看成“转行”。更准确地说：你的系统边界正在变大。

以前你的服务面对的是确定输入、确定逻辑、确定返回。Agent 系统里多了一个不确定的模型，它会规划、会犯错、会超时、会把成本打爆。

这才是企业愿意付钱的地方。

招聘页里反复出现的，不是 Transformer

先说薪资。

这次看的公开样本里，AI Agent / Go + Agent 岗位从 20K-40K 到 70K-100K 都有。普通工程岗、资深岗、架构岗混在一起，不能粗暴平均。

比较稳的说法是：40K-60K 不是纯编的，但也不是每个 Go 后端学三个月都能拿到。

上海样本写到 30-60K·18 薪，要求 LLM/RAG/Agent 工程方案、可靠性、成本、延迟、可观测和容量规划；北京样本能看到 40-70K，关键词是上下文、记忆、工具调用、多 Agent、评估体系；也有 20-40K 的行业 Agent 岗。

所以真正值得看的不是数字，而是岗位要求。

招聘页反复出现的词，不是 Transformer，不是反向传播，也不是“从零训练大模型”。

更高频的是这些：RAG、MCP、工具调用、上下文工程、任务调度、多 Agent、评测、可观测性、成本、延迟、Docker、K8s。

这很说明问题。

企业不是在找“懂 AI 概念的人”，而是在找能让 Agent 进入业务系统的人。

RAG on Zampo Blog

别急着给 RAG 加 Agent，先看复杂性放错了没有

标准 RAG：如果答案就在文档里，它仍然是起点

Go 后端转 AI Agent，值不值？我查了一圈招聘要求

招聘页里反复出现的，不是 Transformer