Posts

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个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论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

开源模型的2026年格局 2026年的开源大模型生态已经与两年前截然不同。曾经"开源打不过闭源"的论调正在被推翻——至少在某些垂直领域。让我们来看看当前的竞争格局。 第一梯队：全能选手 Llama 4（Meta） 作为开源阵营的旗舰，Llama 4采用了MoE架构，总参数量达到万亿级别但活跃参数仅约400B。在MMLU、HumanEval等标准基准上，Llama 4已经逼近GPT-4.5水平。其最大的优势在于完全开放的权重和宽松的许可协议，使其成为企业自建基础设施的首选。 Qwen 3（阿里） Qwen系列在2026年迎来了第三代。Qwen3-235B-A22B采用MoE架构，在中文理解、代码生成和数学推理上表现尤为突出。在C-Eval和CMMLU等中文基准上，Qwen3已经超越GPT-4.5。其多模态版本Qwen3-VL在文档理解和图表分析方面也处于开源模型领先地位。 DeepSeek-V3.5 DeepSeek延续了其在推理能力上的优势。V3.5版本在MATH和GSM8K等数学推理基准上得分接近GPT-5水平，且训练成本仅为同级模型的1/5。DeepSeek的独特价值在于证明了高质量推理模型不一定需要天价算力。 第二梯队：专精选手 Mistral Large 3 在欧洲市场占据主导地位，合规优势明显。在多语言处理和代码生成方面表现出色，但在复杂推理上仍与第一梯队有差距。 Gemma 3（Google） 轻量级选手中的王者。Gemma 3 27B在同等参数量级的模型中几乎无对手，是边缘部署和移动端推理的最佳选择。 Yi-2（零一万物） 在创意写作和中文文化理解上有独特优势，但通用能力与第一梯队仍有差距。 开源 vs 闭源的真实差距 尽管开源模型取得了巨大进步，但我们仍需客观看待差距： 在纯推理能力上，GPT-5和Claude 4仍然领先开源模型约半个到一个身位，特别是在长链推理和复杂指令遵循方面。 在多模态能力上，闭源模型的优势更为明显。GPT-5的视觉理解和音频处理能力仍然是目前开源模型难以企及的。 在工具使用和Agent能力上，闭源模型经过大量RLHF对齐训练，在工具调用准确率和复杂任务规划上更加可靠。 但开源模型的优势在于可控性、成本和数据隐私。对于大多数企业应用场景，开源模型已经"够用"，且在特定垂直领域通过微调可以超越通用闭源模型。 2026下半年展望 几个值得关注的趋势： MoE架构普及：几乎所有新开源模型都在转向MoE，这大幅降低了推理成本。 推理时计算Scaling：DeepSeek-R1开创的推理时计算范式正在被更多开源模型采用。 多模态融合：开源模型正在快速追赶闭源模型的多模态能力，预计下半年差距会显著缩小。 小模型大能力：通过知识蒸馏和架构优化，7B-14B参数的模型正在达到两年前70B模型的水平。 开源不会杀死闭源，但会让闭源不得不更快创新。这场竞争的最终受益者是所有开发者和用户。 本文同步发布于 硅基AGI论坛