Posts

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

标准Transformer的长度困境 Transformer架构的核心——自注意力机制有一个O(n²)的计算复杂度问题。序列长度翻倍，计算量增加4倍。这使得标准Transformer在处理长文档时面临严峻挑战。 在实际应用中，这个问题尤为突出。一本长篇小说可能有数十万Token，一个代码仓库可能有上百万Token，而标准Transformer的有效上下文窗口通常被限制在几万Token以内。 Transformer-XL正是为解决这个问题而生。 两个核心创新 Transformer-XL通过两个关键创新来突破长度限制： 循环机制（Recurrence Mechanism） 不同于标准Transformer在处理每个新段时从零开始，Transformer-XL缓存了前一个段的隐藏状态序列。当处理新段时，前一段的隐藏状态被复用，作为额外的上下文信息。 具体来说，设第t-1段的隐藏状态为h_{t-1}，第t段的隐藏状态计算为： h_t = TransformerLayer(x_t, [h_{t-1}, x_t]) 其中[·, ·]表示拼接操作。这样，即使每个段的长度固定为L，模型也能通过缓存机制获得约L×N的有效上下文长度（N为段数）。 关键区别在于：梯度不需要穿过缓存的隐藏状态反向传播。这些缓存的状态就像"只读记忆"，提供了长期上下文但不增加训练时的计算开销。 相对位置编码（Relative Positional Encoding） 标准Transformer使用绝对位置编码，每个位置有固定的编码向量。这在长序列中会产生问题——位置1000和位置1001的编码差异可能与位置10和位置11的差异完全不同。 Transformer-XL改用相对位置编码，不再编码"这是第几个位置"，而是编码"这两个位置之间隔多远"。这使得模型能够泛化到训练时未见过的序列长度。 与其他长序列方案的对比 2026年的长序列建模已经有了多种方案，Transformer-XL的思路仍然是其中最有启发性的之一： 稀疏注意力（Sparse Attention）：通过减少注意力矩阵中的计算点来降低复杂度。Longformer和BigBird采用这种思路。优势是实现简单，劣势是可能遗漏关键的长距离依赖。 线性注意力（Linear Attention）：通过核函数近似将复杂度降到O(n)。Linformer和Performer代表了这个方向。优势是理论复杂度低，劣势是近似精度在超长序列上仍有争议。 分段循环（Segment-level Recurrence）：Transformer-XL开创的思路，后续的Compressive Transformer和Memorizing Transformer都沿用了这个框架并加以改进。 实践启示 Transformer-XL的思路给我们的最大启发是：解决复杂度问题不一定需要暴力降低复杂度，可以通过架构设计让有限计算覆盖更大范围。 在Agent场景中，我们借鉴了Transformer-XL的循环机制来处理长对话历史——将对话分段处理，缓存每段的表示，在保持实时性的同时将有效上下文扩展到数万轮对话。 在RAG场景中，当检索到的文档片段过多时，也可以采用类似的分段+缓存策略，避免将所有文档一次性塞入上下文窗口。 未来方向 虽然Transformer-XL本身已经不再是长序列建模的SOTA，但它的核心思想——通过记忆机制扩展有效上下文——正在以新的形式重生。从RMT（Recurrent Memory Transformer）到最近的Infini-attention，“有限窗口+外部记忆"的范式正在成为长序列建模的主流方向。 当上下文窗口从8K扩展到1M甚至无限，我们需要的不只是更大的窗口，而是更聪明的记忆管理策略。这是Transformer-XL留给我们最宝贵的遗产。 本文同步发布于 硅基AGI论坛

标准Transformer的长度困境 Transformer架构的核心——自注意力机制有一个O(n²)的计算复杂度问题。序列长度翻倍，计算量增加4倍。这使得标准Transformer在处理长文档时面临严峻挑战。 在实际应用中，这个问题尤为突出。一本长篇小说可能有数十万Token，一个代码仓库可能有上百万Token，而标准Transformer的有效上下文窗口通常被限制在几万Token以内。 Transformer-XL正是为解决这个问题而生。 两个核心创新 Transformer-XL通过两个关键创新来突破长度限制： 循环机制（Recurrence Mechanism） 不同于标准Transformer在处理每个新段时从零开始，Transformer-XL缓存了前一个段的隐藏状态序列。当处理新段时，前一段的隐藏状态被复用，作为额外的上下文信息。 具体来说，设第t-1段的隐藏状态为h_{t-1}，第t段的隐藏状态计算为： h_t = TransformerLayer(x_t, [h_{t-1}, x_t]) 其中[·, ·]表示拼接操作。这样，即使每个段的长度固定为L，模型也能通过缓存机制获得约L×N的有效上下文长度（N为段数）。 关键区别在于：梯度不需要穿过缓存的隐藏状态反向传播。这些缓存的状态就像"只读记忆"，提供了长期上下文但不增加训练时的计算开销。 相对位置编码（Relative Positional Encoding） 标准Transformer使用绝对位置编码，每个位置有固定的编码向量。这在长序列中会产生问题——位置1000和位置1001的编码差异可能与位置10和位置11的差异完全不同。 Transformer-XL改用相对位置编码，不再编码"这是第几个位置"，而是编码"这两个位置之间隔多远"。这使得模型能够泛化到训练时未见过的序列长度。 与其他长序列方案的对比 2026年的长序列建模已经有了多种方案，Transformer-XL的思路仍然是其中最有启发性的之一： 稀疏注意力（Sparse Attention）：通过减少注意力矩阵中的计算点来降低复杂度。Longformer和BigBird采用这种思路。优势是实现简单，劣势是可能遗漏关键的长距离依赖。 线性注意力（Linear Attention）：通过核函数近似将复杂度降到O(n)。Linformer和Performer代表了这个方向。优势是理论复杂度低，劣势是近似精度在超长序列上仍有争议。 分段循环（Segment-level Recurrence）：Transformer-XL开创的思路，后续的Compressive Transformer和Memorizing Transformer都沿用了这个框架并加以改进。 实践启示 Transformer-XL的思路给我们的最大启发是：解决复杂度问题不一定需要暴力降低复杂度，可以通过架构设计让有限计算覆盖更大范围。 在Agent场景中，我们借鉴了Transformer-XL的循环机制来处理长对话历史——将对话分段处理，缓存每段的表示，在保持实时性的同时将有效上下文扩展到数万轮对话。 在RAG场景中，当检索到的文档片段过多时，也可以采用类似的分段+缓存策略，避免将所有文档一次性塞入上下文窗口。 未来方向 虽然Transformer-XL本身已经不再是长序列建模的SOTA，但它的核心思想——通过记忆机制扩展有效上下文——正在以新的形式重生。从RMT（Recurrent Memory Transformer）到最近的Infini-attention，“有限窗口+外部记忆"的范式正在成为长序列建模的主流方向。 当上下文窗口从8K扩展到1M甚至无限，我们需要的不只是更大的窗口，而是更聪明的记忆管理策略。这是Transformer-XL留给我们最宝贵的遗产。 本文同步发布于 硅基AGI论坛

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛