AI 技术问答汇总

序言

这半年在「AI技术」这个分类下写了十篇长文，从 RAG 讲到 MCP，从 Harness Engineering 讲到 Agent 治理平台。有意思的是，读者在评论区、私信、以及线下的技术交流里问的问题，重复率非常高——翻来覆去就那么二十来个。

长文的好处是讲得透，坏处是想查一个具体结论要翻五千字。所以这篇做一次汇总：把散在十篇里的判断收成一份问答集，按「基础概念 → 协议接口 → Agent 架构 → 工程治理 → 工具选型」五层排下来，每个问题给一段能直接拿去用的答案，末尾标明深挖该看哪一篇。

一个说明：这份汇总里的数字都来自原文引用的公开资料和实测，凡是口径不确定的地方我都写了「量级」而不是精确值。结论会过时，判断标准不会，所以我在每个答案里尽量把「为什么这么判断」也留下。

1、先给一张地图

层次	回答的问题	涉及篇目
基础概念层	RAG、Context、Harness 这些词到底指什么	RAG 搭建指南、Context Engineering、Harness Engineering
协议接口层	模型怎么接工具、请求怎么接模型	MCP 黄昏还是重生、云原生 AI 网关横评
Agent 架构层	一个 Agent 不够时怎么拆、拆完怎么组装	三层多智能体方法论、框架选型
工程治理层	跑起来之后怎么管、怎么省钱、怎么不越权	Agent 治理平台、Nacos AI Registry
工具选型层	人怎么和这套东西协作	代码编辑器全横评

这张图最有用的一句提醒是：大部分人卡住，不是因为某一层没学好，而是拿错了层的答案。 比如「模型答不准」，可能根本不是模型问题，是上下文喂错了；「成本失控」，可能不是模型贵，是工具 schema 常驻吃掉了 72% 的窗口。

2、基础概念层

Q1：RAG 到底是什么？它和微调是替代关系吗？

不是替代，是分工。RAG 解决的是「模型不知道你的私有知识」，微调解决的是「模型不会按你的方式说话办事」。前者管知识，后者管行为。

工程上的直接后果是：知识天天变、还要能溯源、要能按权限过滤，这三件事微调一件都做不到，所以企业内部知识问答的默认解永远是 RAG。反过来，如果知识是稳定的、你要的是固定的输出格式和语气，微调更划算——因为 RAG 每次都要把检索结果塞进上下文，那是持续付费。

延伸：企业级智能助手 RAG 搭建指南

Q2：什么情况下反而不该用 RAG？

三种情况，用了就是给自己找麻烦：

知识量很小——几页 FAQ 直接塞进系统提示词比搭一套向量库便宜得多，检索反而引入了召回失败这个新的故障点；
问题需要全局推理——「总结这份合同里的三个风险点」这类任务，检索回来的碎片会切断上下文，长上下文直接读全文更准；
答案必须绝对精确且可计算——金额、库存、账期这类，该查数据库就查数据库，让模型做 SQL 生成而不是语义检索。

判断标准可以简化成一句：RAG 擅长「找到那一段」，不擅长「算出那个数」。

Q3：Context、Context Window、Token 到底什么关系？

Token 是计量单位（一个 token 大约 1.5 个汉字或 0.75 个单词）；Context 是模型这一次看到的全部输入，包括你的问题、工具列表、检索结果、历史对话，全都算；Context Window 是这个输入最多能装多少 token，也就是那个硬上限。

三者串起来就是所有上下文工程的起点：Context 的构成可以设计，Context Window 的上限不能谈判。 一旦你把 Context 当成「能塞多少塞多少」的容器，问题就从「贵」变成「不准」。

Q4：Context Engineering 和 Prompt Engineering 差在哪？

Prompt Engineering 优化的是「那一段话怎么写」，Context Engineering 优化的是「窗口里到底该出现哪些东西」。

层级也不一样：Prompt 是最小单位，Context 是中间层，Harness 是最大的一层。LangChain 给的四策略可以直接背下来——Write（写到窗口外）、Select（按需拉进来）、Compress（只留必需的）、Isolate（切开，别互相污染）。

一句话区分：Prompt Engineering 是修辞学，Context Engineering 是内存调度。

Q5：Harness Engineering 又是什么？是不是新瓶装旧酒？

Harness 的本义是马具——缰绳、马鞍、挽具。放到 Agent 语境里，它是模型之外那一整套让模型能稳定把事做完的工程装置：工具、沙箱、验证器、重试机制、交接班协议、成本闸门。

它和 Context Engineering 的关系是包含而非并列：Context 管「模型每一步看到什么」，Harness 管「整个循环怎么转、什么时候停、错了怎么回」。Karpathy 把 LLM 比作 CPU、把上下文窗口比作 RAM 之后，Harness 大概相当于主板和散热——不决定算力上限，但决定你能不能长时间跑满。

至于「新瓶装旧酒」的质疑，我的看法是：概念可能是新的，但每个组件都编码了一条「模型当前做不到 X」的假设，而模型每次升级都会作废其中一部分。所以 harness 是易耗品，不是固定资产——要建的不是完美 harness，而是持续做减法的机制。

延伸：Harness Engineering：当工程师的核心工作从写代码变成造环境

3、RAG相关

Q1：RAG系统是如何进行Query改写？

检索结果不好，不一定是知识库不好，很有可能是大模型没听懂用户在问什么。Query 改写就是在检索之前，先把「用户说的话」翻译成「知识库里写的话」——聚焦于怎么把话说明白，属于 Prompt Engineering。

① 首先要明动机：为什么要改写？

三个绕不开的问题，回答时先摆出来，面试官就知道你不是在背名词：

语义鸿沟：用户问「房源怎么看不到了」，知识库写的是「房源帖下架问题分析」，两句没有一个关键词重合，要解决：意思一样，表述不一致的情况。
意图模糊：「那个政策怎么说」——可能是报销、也可能是请假，一句话里藏着多种理解，而单个查询只能覆盖其中一种角度。
历史关联：多轮对话里「那它的保修呢」，这个「它」根本不在当前这句话里，脱离上下文去检索必然检索错。

一句话收口：改写要消灭的是「问法」和「写法」之间的失配。

② 分维度：怎么改写？

按由浅入深，三条技术路径：

第一，语义增强——补信息、换说法。

指代消解与省略补全：把「那它的保修呢」补成「XX 型号手机的保修期是多久」，多轮场景必做；
同义扩展与术语规范化：「咋退钱」→「退款流程」，解决词汇失配，可以用领域词表也可以用小模型；
关键词抽取与去噪：剥掉寒暄和情绪，只留检索真正需要的词。这一招对 BM25 分支的收益比对向量检索还大，因为 BM25 对噪声词极其敏感；
HyDE：反直觉但有效——不让模型改问题，先让它编一段「假答案」，拿假答案去检索真文档。因为答案和答案在向量空间里更近，这招绕开了「用问题向量找答案向量」天然不同构的问题；
多查询改写 + RRF：一次生成 3–5 个不同角度的变体并行检索，再用倒数排名融合（RRF）按排名投票合并。对表述模糊的 query 收益最大，也是生产环境性价比最高的一招。

第二，任务分解——拆问题。

这里其实藏着两种方向完全相反的拆法，很多资料把它们混着讲，所以看着乱。分开讲就清楚了：一种是「横向拆开」，一种是「纵向抬高」。

Query 改写中任务分解的两种方向：横向拆与纵向升

1️⃣横向拆：子查询分解（Sub-query Decomposition）

适用场景：一句话里并列了多个对象，或者包含多个独立子问题。

举个例子，用户问：

「iPhone 17 Pro 和华为 Mate 80 的保修期差多少？」

为什么直接检索不行？ 因为这句话要的是「差多少」，但你的知识库里根本不会有任何一篇文档写着两者的差值——文档只会各自写各自的保修政策。拿这一整句去检索，向量会同时被「iPhone」和「华为」两个方向拉扯，结果两边都排不进 top-K，最后两边都召回不全。

拆开之后：

步骤	检索的查询	拿到的证据
子查询 1	iPhone 17 Pro 整机保修期限	「自购买日起 12 个月」
子查询 2	华为 Mate 80 整机保修期限	「自激活日起 12 个月，电池 6 个月」
子查询 3	两家保修是否包含电池与屏幕	各自的除外条款

三个子查询互不相干，可以并行检索；各自拿到证据后，再由 LLM 汇总成答案。

这一招的关键认知是：「差多少」不是检索出来的，是汇总时算出来的。 检索只负责把两边的原始证据各自捞全，比较和计算交给生成阶段。想明白这一点，就知道什么时候该拆了。

还要区分两种子查询：

独立型（上例）：子问题之间没有依赖，可以并行，只是多花几次检索；
依赖型（多跳）：后一跳要查什么，取决于前一跳的答案。比如「我们公司现任 CTO 入职前在哪家公司」——第一跳先查「现任 CTO 是谁」，拿到名字后第二跳才能查「张三的履历」。依赖型必须串行，这也是它延迟最高的原因。

2️⃣纵向升：Step-back（退一步提问）

适用场景：问题太具体、太长尾，知识库里大概率没有精确匹配。

它的方向和横向拆正好相反——不是把问题拆细，而是把问题往上抽象一层。

举个例子，用户问：

「Mate 80 在 -20℃ 环境下电池续航会衰减多少？」

为什么直接检索不行？ 这是个「型号 × 温度 × 衰减率」的三元组合，属于典型的长尾问题。知识库里几乎不可能有一篇文档专门写「Mate 80 在 -20℃ 的衰减数据」，直接检索的结果要么是召回 0，要么是捞回一堆无关的环境测试报告。

退一步之后，分两步走：

第一步，问一个更泛的问题：「Mate 80 系列的电池规格与工作温度范围」——这一问命中率很高，能稳定拿到「电池容量 5000 mAh」「标称工作温度 0℃–35℃」「低温下锂电池放电能力下降」这类背景知识；
第二步，把背景知识和原问题一起交给模型：「已知该机型电池为 5000 mAh、标称工作温度 0–35℃，请回答 -20℃ 下的续航衰减情况」——模型基于原理做推断，并明确标注这是推算值而非官方数据。

这一招的关键认知是：具体答案不在库里，但能推导出答案的那层原理在库里。 Step-back 检索的不是答案本身，而是「能支撑答案的那个更上位的知识」。

3️⃣两种拆法怎么选

	横向拆（子查询分解）	纵向升（Step-back）
问题长什么样	一句话含多个并列对象/子问题	一句话过于具体、长尾、组合条件多
动作	拆成 N 个平级查询	抽象成 1 个更上位的问题
检索次数	N 次（独立型可并行）	2 次（先背景，再作答），串行
答案从哪来	各子查询的证据汇总后计算	用上位知识 + 原问题推断
典型例子	「A 和 B 的保修期差多少」	「Mate 80 在 -20℃ 衰减多少」

两者的共同代价是：都要多轮 LLM 调用加多轮检索，延迟和成本成倍上升。所以工程上一定要配意图路由——只有判定为复杂问题才走分解，简单问题单次检索就够了，否则就是在给 80% 的简单问题付复杂问题的钱。

第三，上下文压缩——压历史。

多轮场景下把最近几轮对话压成一句可以脱离上下文独立理解的完整 query。经验值是只带最近 2–3 轮，全量历史塞进去又贵又容易跑偏。这一层同时也是省钱的关键——先做意图路由，判断「要不要检索」，闲聊直接答、简单问题单次检索、复杂问题才走多步。

③ 论权衡：改一次就多一次代价

这一层是加分项，主动说出来比等面试官追问好：

延迟：多一次模型调用就多一份耗时；多查询改写会把检索量放大 N 倍，必须并行，串行就是 N 倍延迟。
漂移：最危险的坑。改写可能把约束条件泛化掉——「2024 年 Q3 华东区销售额」被改成「某时间段某区域的销售业绩」，检索精度直接崩。数字、型号、法条编号、地名、人名一旦被翻译掉就是线上事故，必须在 prompt 里明确要求保留所有限定词。
成本：常规打法是便宜的小模型做改写和路由，贵模型做最终生成。另外短 query（订单号、SKU、错误码）本来就靠关键词精确命中，改写反而引入噪声，该跳过就跳过。

还有两条工程红线：改写失败或超时要能降级到原句直接检索，改写永远是增强项不是必经项；原句必须和改写句一起检索，只信改写句，一旦跑偏就全盘皆输。

④ 说闭环：怎么证明改写真的有用

别凭感觉。建一个 50–200 条真实 query 的小评测集，标注好每条对应的正确文档，改前改后各跑一遍：

检索侧看 Recall@K（该捞的捞进来没有）和 MRR / NDCG@10（捞进来的排得够不够前）——改写主要提升的就是 Recall@K；
端到端用 RAGAS 这类框架量化 Faithfulness（忠实度）、Answer Relevancy、Context Precision。

这里有个必须警惕的点：只看召回率涨了不够。改写把候选集撑大的同时会混进噪声，稀释上下文、拉低生成质量——所以改写必须和 Rerank 配套上：改写负责捞得多，Rerank 负责排得准，两次校正缺一不可。

总结：先理解意图，再对齐向量最后生成完美答案。

延伸：企业级智能助手 RAG 搭建指南

Q2：RAG 处理 Word 和扫描版 PDF 方案？

这个问题的胜负手不在检索算法，而在文档解析——喂给模型的如果是乱码、错位的文字、断掉的表格，后台算法再强也是垃圾进垃圾出。数据解析的上限，决定了 RAG 效果的上限。

① 先看清对手：两类文件，两种难法

Word（半结构化）：自带原生段落和标题层级，看起来简单，暗坑全在内部——嵌套图表、OLE 嵌入对象、复杂内联表格，解析不当极易丢失。

PDF（无序版式）：RAG 的修罗场。纯流式排版完全丧失结构逻辑；多栏布局直接读会导致左右栏文字首尾交叉混淆；扫描件干脆没有字符层，全靠硬啃。

② 解析层：五套武器按需选用

文档解析分流架构

1. Docling / Marker：开源首选。 2026 年的开源新星，摒弃老旧的无脑逐字读取，把 PDF/Word 精准转换为高保真 Markdown——这一点是关键，大模型对 Markdown 文档的亲和度最高，且能自动修复双栏逻辑。

2. LlamaParse：极复杂长文档的天花板。 托管级云解析，对极度复杂的树状层级、超长文档解析能力最佳，自带视觉辅助增强。

3. 表格终极破局。 绝不要把表格直接提取成纯文字——必须转成 HTML 或 JSON 再写入。大模型对 HTML 标签的结构推理能力远胜纯文本流。

4. ColPali：无 OCR 路线。 换一条路走：不提取文本，直接把 PDF/Word 渲染成高分辨率图像，通过视觉语言模型（VLM）提取版面视觉多向量，直接匹配与路由、检索「页面图景」。避开繁琐的 OCR 识别环节，复杂版面的检索精度成倍提升。

5. Agentic Parsing：智能解析路由。 2026 年不再推行一条路走到黑的流水线，而是采用 Agent 分流机制：第一步，轻量预检——用小视觉模型检测文档页面类别；第二步，精细分流——纯文字段落走高效率的 Docling 提取，复杂图表与扫描件路由至多模态大模型（VLM）强化理解。这种见机行事的架构，才是工业化落地的实际方案。

③ 切片层：拒绝粗暴截断

结构感知切片：传统硬伤是盲目按固定字数（如 512 字符）横切，会彻底撕碎句子结构和上下文。应依据 Markdown 中的 Heading、列表、段落边界做递归逻辑切片，确保每片都是语义完整的信息单元。

结构感知切片与混合检索

元数据注入：每个切片强制附加上级标题链路径，防止信息漂移孤立。例如：[产品手册 > 硬件规格 > 电池寿命]。

混合召回 + 精细重排：Vector（稠密检索）抓主旨，BM25（稀疏匹配）定位精准产品型号，两路互补；再用 Reranker 重排，限制前置上下文噪声，确保最关键的知识碎片紧贴大模型上下文首部。

④ 总结

这个问题不关心 API 怎么调，关心的是数据怎么清洗、提取、重构。记住三件套：Docling / Marker 精细转换、ColPali 视觉检索、Agentic 分流解析——解析的上限，就是 RAG 的上限。

延伸：企业级智能助手 RAG 搭建指南

4、AI技术架构选型对比

Q1：LangChain和LangGraph的区别是什么？

先纠正一个最常见的误解：它们不是两个竞品，而是同一条抽象阶梯上的两层。 LangChain 是「框架」——负责把模型、检索、工具这些零件拼起来；LangGraph 是「运行时」——负责管这个流程怎么跑、跑崩了怎么续。官方自己的定位就是这么写的。

所以真正的分水岭只有一个问题：你的流程需不需要「回头」和「中断恢复」。

1. LangChain：流水线法则（DAG）

做 RAG 流程就像工厂里的零件加工：接收 → 检索 → 生成 → 解析，数据像离弦之箭，单向流动，走到头就结束。它的架构重心是 DAG（有向无环图）——每个节点只执行一次，没有回头路，也不存在「根据中间结果改流程」这回事。

最优场景：单次问答、企业 RAG、文本翻译这类一次跑完就结束的任务；
框架优势：响应敏捷、开发流程精简，几十行就能串出一条可用的链；
边界在哪：一旦需要「跑一半停下等人审批」「失败了从中间重试」「根据结果回到上一步」，DAG 就表达不了了；而且它没有内置的状态持久化，进程挂了就是从头再来。

2. LangGraph：循环状态机（Graph）

LangGraph 引入了循环图计算模型（Cyclic Graph） 与全局持久化状态机制，核心优势是支持复杂任务的原子化管理——通过 Checkpointer 机制实现任务的随时暂停、恢复与状态回溯。它带来的能力可以拆成五条：

能力	解决什么
Checkpointer	任务中断与状态续行，进程重启也不丢进度
时间旅行	节点级的历史追溯与重跑，可以回到任意一步换个分支再走
人机协同	严谨业务流程的审核点植入，关键决策由人把控
多智能体协同	多角色、多轮次的跨部门审批，不再是简单的一问一答
长流程容错	中间报错只重试出错的那一步，而不是整条重跑——这直接解决的是成本瓶颈

最优场景：代码修复、自动化工单、复杂中台这类长流程、强状态的任务；
框架优势：强容错性、逻辑高度灵活；
代价也要说：心智负担和代码量都上一个台阶。而且状态图怎么切分本身就是架构设计活，框架只提供机制，不替你做设计——选了 LangGraph 不等于解决了状态管理、补偿、幂等这些工程问题。

3. 2026 年的落地现状：它们在合流，不是在打架

补几条 2026 年的真实现状，这几条比框架对比本身更有用：

LangChain 1.0 与 LangGraph 1.0 在 2025 年 10 月同日发布，create_agent 抽象加 middleware 钩子体系定型，随后一年几乎所有主流框架都跟进了这个「agent 优先 + 中间件」的重写模式；
官方定位是一条三层栈：LangGraph 是运行时、LangChain 是框架、Deep Agents 是线束（harness）。同一家公司、同一条阶梯，上下移动不需要重写；
官方推荐的路径是反直觉的：从最高层起步，被需求逼着往下掉，而不是一上来就画状态机。我见过最典型的浪费，是一上来就 LangGraph 画状态机，结果 80% 的节点是空转；
真实项目大多是混用：LangChain 负责生态集成和组件，LangGraph 负责编排和持久化，两者压根不是二选一。

4. 怎么选

你的场景	建议
单次问答、企业 RAG、文本翻译	LangChain（LCEL）就够，别上状态机
多步业务流程 + 工具编排	LangChain + LangGraph 组合
强合规审计，每一步都要可举证	LangGraph（显式状态图 + checkpoint）
只想快速验证想法	从最高层起步，先用现成的线束