从检索到编排：2026年大模型系统工程的四个收敛点

2023 年的大模型技术叙事以“模型能力”为中心：更大的参数、更长的上下文、更强的 benchmark 分数。到了 2026 年，主线已经明显偏移。单纯的模型能力提升仍在继续，但真正决定系统可用性的，是模型之外的那一层——检索如何结构化、Agent 如何被约束和编排、推理算力如何按需分配、工具与上下文如何以标准化方式接入。这四个问题看似分属不同子领域，却在 2026 年不约而同地指向同一个方向：从“把模型跑起来”走向“把系统管起来”。

一、RAG 不再只是“向量检索 + 拼接”

检索增强生成在 2026 年经历了一次静默但深刻的结构调整。早期的 RAG 范式——固定 top-k 余弦相似度检索、将片段直接拼入 prompt——正在被两类更具工程意识的方法取代。

第一类是结构感知的检索。 TopoRAG 的出发点很直接：传统 RAG 的朴素文本分块会破坏企业合同、制度文档中固有的层级结构，导致语义碎片化和跨章节依赖丢失；而全量构建知识图谱的 Graph RAG 又过于昂贵。TopoRAG 的解法是双图架构：一张图捕捉文档的物理版面布局，另一张图编码逻辑语义关系，再通过 Context-Enriched Embedding 策略将两者对齐。这样既保留了跨章节的结构信息，又避免了全图抽取的计算开销。在专有企业合同数据集和 QASPER 基准上，TopoRAG 的检索准确率和答案保真度显著优于传统基线和近期层级方法。这背后的判断是：对于准确性关键的领域，文档的“形状”本身就是信号，把它丢掉再让模型从碎片中“猜”结构，代价比保留结构更高。

第二类是复杂度感知的自适应检索。 Keiro 指出了一个被长期忽视的浪费：固定检索策略对简单查询过度检索，对复杂查询又提供不足的上下文。Keiro 在运行时将查询分为三个复杂度层级：简单查询走 top-2 直取，复杂查询走八块 MMR 多样性过滤加交叉编码器重排，多跳查询走三轮迭代检索加 LLM 驱动的查询重构。在 EU AI Act 和 Basel III 框架的 180 个问题上，自适应路由将复杂查询的上下文召回率提升了最多 5.4 个百分点，多跳查询提升了 6.1 个百分点，代价是各层级 17% 到 39% 的 token 成本。Keiro 自己也诚实地标注了瓶颈：复杂与多跳边界的分类器准确率只有 10%，导致简单查询因过度路由而出现 8 个百分点的额外失败率。这说明自适应检索的收益是真实的，但它把工程重心从“检索质量”转移到了“路由决策质量”上。

两篇工作合在一起，勾勒出 2026 年 RAG 的收敛方向：检索系统的核心设计变量不再是单一的相似度函数，而是“结构保留”与“计算分配”之间的权衡。 把每一份上下文都当成同等价值的 token 来处理，在成本和质量两个维度上都已经不再成立。

二、Agent 的工程化，落在 Harness 与协议上

如果说 2024—2025 年的 Agent 讨论集中在“能不能规划、能不能调用工具”，那么 2026 年的讨论几乎完全转向了另一个问题：如何让一个会规划、会调用工具的模型，在真实业务中稳定地走到可验收的结果。

自如的租房 Agent 演进提供了一个清晰的样本。1.0 阶段是 16 个固定步骤的工作流，跑通了找房、咨询、预约的主流程；2.0 阶段拆分 Java 业务服务与 Python 语义处理，将地点表达细化为正向、排除、多地点等含义，引入覆盖 400 多万实体的地点库，位置召回率从 86% 提升到 98%；3.0 阶段则围绕任务构建 Harness，采用规划与执行分离的方式，将固定步骤重组为 16 个 Skills，以 AgentScope 作为运行时——模型先提出对意图和条件的理解，系统进行策略校验、地点核验和计划差异比对，再调用业务工具，输出前再次检查结果。这条路径的关键判断是：Agent 的演进不是“换更强的模型”，而是把模型嵌入一个带有校验、追踪和回滚能力的执行框架中。

这一判断在更系统的层面得到了呼应。一本 2026 年出版的 Agentic AI 系统工程专著将 Agent 系统拆解为六层栈：基础模型、Agent–计算机接口、记忆系统、认知循环、多智能体编排、生产治理。其中几个设计约束值得单独提出：上下文窗口被视为有限的注意力预算，存在“上下文腐化”和位置敏感性；工具应当为“非人类消费者”设计，优先任务形状的工具而非裸 API，输出要有界、可分页，错误信息要可操作；多智能体拓扑涵盖层级式、对等式、黑板式和 DAG 式，而 MCP 与 A2A 分别承担工具集成和跨厂商 Agent 通信的协议角色。

EREBOTS 4.0 则把这种“协议化编排”推到了可运行的形态：语言模型 Agent 负责规划和路由，确定性工具通过 MCP 计算精确结果，编排器按轮次选择一个或多个专家 Agent 并通过 A2A 协议调用；其 A2A 服务器在官方兼容性套件中通过了 97 项追踪需求，零失败。这组事实的意义不在于某个框架的优劣，而在于一个共识正在成型：Agent 的可靠性不来自模型本身，而来自模型之外的 Harness、协议和治理层。 黄佳在 CCF TF 的分享中把这一点表述得更直接：Agent 降低了部分编码成本，但并未消除系统复杂性，交接、验证和责任边界反而需要更细致的设计。

三、推理模型的下一步：学会“不推理”

推理模型（LRM）在 2025 年的主流叙事是“更长、更细的思维链带来更高准确率”。2026 年的研究则集中在一个更具工程价值的反命题上：当简单问题不需要显式推理时，模型应当有能力跳过它。

AutoThink 的发现颇具启发性：在 R1 风格蒸馏模型的 prompt 中插入一个简单的省略号（“…”），就可以随机触发“思考”或“不思考”两种模式，说明推理行为本身具有潜在的可控性。基于这一性质，AutoThink 用多阶段强化学习逐步塑造推理策略，让模型仅在必要时调用显式推理，简单任务则默认给出简洁回答。在 DeepSeek-R1-Distill-Qwen-1.5B 上，AutoThink 将相对准确率提升了 6.4%，同时将 token 用量减少了 52%。这意味着“是否推理”正在从一种 prompt 技巧变成一个可训练的决策变量。

RLTT 则从另一个方向切入。LoopLM 在生成 token 之前进行多步潜在推理，但标准的 GRPO 只对最终潜在状态分配信用，与模型内部的计算过程存在根本性错配。RLTT 将奖励分配到完整的潜在推理轨迹上，提供稠密的轨迹级信用分配，且不依赖外部验证器，可以直接替换 GRPO 而开销几乎可忽略。在 Ouro-1.4B/2.6B-Thinking 上，RLTT 在 MATH-500、AIME24/26 和 BeyondAIME 上的平均准确率分别提升了 5.8% 和 10.9%，并且尽管只在数学数据上训练，也有效迁移到了非数学推理基准。

更宏观的综述则给出了一个必要的清醒判断：推理时算力的回报是实例依赖的，不存在平滑的缩放律，甚至可能转为负值——已有分析报告准确率随推理长度增长而下降。把“想得更久”当作默认正确的策略，在系统层面是不成立的。2026 年推理模型研究的收敛点因此可以概括为：推理的粒度、深度和时机正在成为可训练、可调度的系统参数，而不是模型越大就越好的附带产物。

四、MCP：从有状态连接走向无状态基础设施

MCP 在 2026 年 7 月 28 日发布的第五版规范，可能是四个收敛点中最具基础设施意义的一个变化。核心改动可以用一句话概括：从双向有状态会话，转向请求/响应式的无状态核心。

这不是一次技术细节的微调。有状态协议要求服务器维护会话上下文，这在本地开发或小规模部署中不是问题，但一旦要部署到 serverless 或边缘环境，会话管理就成了绕不开的负担。无状态核心让 MCP 服务器可以像普通 HTTP 工作负载一样水平扩展，Netlify 的反馈很直接：“没有会话管理要绕过”。与此同时，授权机制对齐了生产级 OAuth 2.0 和 OIDC，MCP 服务器可以直接对接 Entra、Okta 等企业身份系统，而不需要变通方案。官方扩展框架则将 MCP Apps（交互式 UI）和 Tasks（长时运行操作）纳入版本化管理，使协议核心保持精简的同时允许能力模块化演进。

规模数据也说明了这条路径的采用速度：MCP 的月 SDK 下载量已超过 4 亿次，一年内增长了 4 倍；Anthropic 的 Tier 1 SDK 截至 2026 年 7 月月下载量接近 5 亿次，TypeScript 和 Python SDK 累计下载量均突破 10 亿次。一个协议能在两年内从提出走到这个量级，通常意味着它解决的已经不是“要不要标准化”的问题，而是“标准化之后如何承载生产负载”的问题。MCP 的无状态转向，正是对这一问题的回答。

结语：2026 年的核心工程矛盾是“可运维性”

把四条线索放在一起看，2026 年大模型系统工程的走向并不神秘。RAG 在结构保留和计算分配之间寻找平衡，Agent 把可靠性外化到 Harness 和协议上，推理模型学习按需分配思考，MCP 把工具接入变成可水平扩展的基础设施。它们各自的具体技术路径不同，但面对的是同一个约束：模型能力已经足够让系统“跑起来”，而系统的“可观测、可约束、可扩展、可回滚”正在成为真正的瓶颈。

TopoRAG 的双图和 Keiro 的三层路由是检索侧的运维性设计；自如的 16 个 Skills 加策略校验、EREBOTS 的 A2A 兼容性套件、六层 Agent 栈中的治理层，是编排侧的运维性设计；AutoThink 和 RLTT 把推理行为变成可训练的策略，是计算侧的运维性设计；MCP 的无状态核心则是连接层的运维性设计。它们不约而同地在回答同一个问题：当模型不再是唯一变量，系统工程应当把注意力放在哪里。

答案正在变得清晰：放在模型之外的那一层，放在那些让模型“出错时不至于失控、扩展时不至于重构”的结构上。