福大大架构师每日一题

go-zero v1.9.4 版本发布详解：云原生适配升级与稳定性性能全面提升一、版本概览go-zero v1.9.4 包含如下整体信息：• 发布时间：2025 年 12 月 24 日• 提交数量：24• 变更文件数：39• 覆盖模块：zrpc、配置中心、日志系统、定时器、服务发现、Redis 客户端封装、文档与依赖管理等整体更新节奏清晰，从 11 月中下旬开始逐步修复和增强功能，在 12 月下旬集中完成核心问题修复并发布稳定版本。二、新特性详解1、Kubernetes EndpointSlice 支持在本次版本中，zrpc 的 Kubernetes 服务解析器完成了一次重要升级，从已被 Kubernetes 标记为废弃的 Endpoints API 迁移至 EndpointSlice API。Endpoints API 在服务数量和实例规模较小时可以正常工作，但在大规模集群中容易出现性能瓶颈，并且维护成本较高。EndpointSlice API 是 Kubernetes 官方为解决这些问题而提供的新机制，它通过更细粒度的数据切分方式提升了服务发现的可扩展性和性能表现。此次迁移意味着 go-zero 在 Kubernetes 场景下的服务发现能力更加符合当前和未来的云原生标准，在高并发、高实例数量的微服务部署环境中能够更加稳定地运行，同时也降低了因 API 过时带来的潜在风险。2、Redis GETEX 命令支持v1.9.4 新增了对 Redis GETEX 命令的支持。GETEX 是 Redis 提供的一条复合型命令，支持在获取键值的同时设置或更新过期时间。在实际业务中，开发者常常需要在读取缓存数据后顺便刷新过期时间，以延长热点数据的生命周期。传统做法通常需要两次命令调用，既增加了网络开销，也存在并发一致性问题。GETEX 命令通过原子操作的方式解决了这一问题。go-zero 对该命令的封装，使得在框架内使用 Redis 进行缓存管理时更加简洁、高效，也更符合高并发微服务架构对性能和一致性的要求。三、日志系统改进日志模块在 v1.9.4 中得到了多项修复和优化，主要集中在以下几个方面：首先，修复了 levelSevere 日志级别在输出时缺少颜色标识的问题。由于不同日志级别往往用于区分严重程度，颜色缺失会影响问题排查时的直观性。本次修复使日志输出更加清晰，有助于在终端和日志系统中快速定位关键问题。其次，修复了测试日志中与时间调度相关的不一致问题。此前在某些测试场景下，日志时间与调度次数存在不匹配的情况，可能导致测试结果不稳定。本次修复提升了日志测试的准确性和可预期性，为持续集成和回归测试提供了更可靠的基础。四、Timing Wheel 定时器优化时间轮是 go-zero 中用于定时任务调度的重要组件。在 v1.9.4 中，对该模块进行了针对性的修正和整理。本次更新补充了缺失的 Wait 调用，避免在特定条件下出现等待不充分或资源提前释放的问题。同时对相关代码结构进行了优化，使逻辑更加清晰，降低后续维护和排查问题的成本。这些调整虽然不会直接改变对外接口，但对于保证定时任务在高并发和复杂调度场景下的稳定运行具有重要意义。五、服务发现机制增强在基于 etcd 的服务发现模块中，本次版本引入了重试冷却机制。在实际运行过程中，当认证信息异常或权限配置错误时，客户端可能会频繁尝试重新连接和认证。如果缺乏有效的限制机制，这种行为可能导致 CPU 和磁盘 IO 被大量占用，进而影响整个系统的稳定性。v1.9.4 通过增加重试冷却策略，在认证错误场景下对重试行为进行限制，从机制层面防止资源被无意义地消耗。这一改进提升了服务发现组件在异常场景下的自我保护能力。六、配置中心修复与性能优化配置中心是 go-zero 微服务体系中非常关键的基础组件。本次版本修复了配置更新过程中出现的错误值通知问题。在此前版本中，部分场景下配置变更后下发的值与实际配置内容不一致，可能导致服务使用了错误的运行参数。v1.9.4 对这一问题进行了修复，确保配置更新通知的准确性和一致性。同时还针对配置获取过程中的逻辑进行了性能优化，减少不必要的计算开销，在配置项较多或频繁访问的场景中能够带来更好的性能表现。七、RPC 指标与拦截器修正在 zrpc 的统计拦截器中，本次版本修复了慢调用阈值优先级处理不正确的问题。慢调用统计是性能分析和问题定位的重要依据，如果阈值判断逻辑存在问题，可能会导致指标失真，影响监控和告警系统的准确性。修复之后，慢调用的判断逻辑更加符合预期，有助于运维和开发人员更准确地识别性能瓶颈。八、性能与代码质量优化除了上述功能性修复之外，v1.9.4 还包含多项细节层面的优化：• 在数据映射处理中，通过更高效的字符串比较方式优化了布尔值解析性能• 对部分代码进行了重构，提升整体可读性和可维护性• 修复并统一了多处注释中的拼写和语法问题，提升源码质量• 对文档结构进行了简化和整理，在保持原有结构的前提下提高可读性这些改动虽然相对细节，但从长期来看，有助于项目的持续演进和社区维护。九、依赖与生态更新v1.9.4 同步升级了多项第三方依赖，包括 Redis 客户端、MongoDB 驱动、命令行工具库以及部分构建和自动化相关组件。依赖升级能够及时引入上游库的 bug 修复和性能改进，同时避免因依赖过旧而产生的兼容性或安全风险。这些调整体现了对框架长期稳定运行的重视。十、版本总结整体来看，go-zero v1.9.4 是一次偏向工程质量和云原生适配能力提升的版本更新。通过引入 Kubernetes EndpointSlice 支持，框架在容器编排环境中的前瞻性进一步增强；通过补充 Redis GETEX 命令，缓存操作更加高效和安全；而围绕日志、定时器、服务发现、配置中心和 RPC 指标的一系列修复，则显著提升了在复杂生产环境中的稳定性和可控性。

agno v2.3.21版本发布详解：AgentOS全面支持Agent As Judge评测与多项稳定性增强1. 功能概述“Agent as Judge”是一种先进的评估范式，它使用一个专门的智能体（Judge Agent）来评估另一个智能体（或团队）在给定任务上的输出质量。这通常用于衡量响应的准确性、相关性、完整性等主观性较强的指标。与传统的基于规则或简单字符串匹配的评估方式相比，Agent as Judge能够利用大语言模型的理解能力，进行更接近人类判断的评估。2. 集成详情在v2.3.21之前，开发者可能已经能够在Agno框架内创建Agent as Judge评估逻辑，但管理和运行这些评估可能不够便捷。本次更新后，这一功能在AgentOS中获得了完整的官方支持：• 配置与触发：用户现在可以直接在AgentOS的Evals（评估）页面中，配置新的Agent as Judge评估任务并触发其运行。这为评估工作流提供了统一的图形化界面。• 统一管理：Agent as Judge评估的运行记录将与现有的准确性、性能、可靠性等评估结果一同，集中展示在Evals页面中。这实现了对所有类型评估的集中监控和管理，极大地提升了操作效率。• API端点增强：对应的GET API端点也已更新，现在可以返回Agent as Judge评估的相关数据，确保了控制平面与后端服务的数据一致性。

yolo v8.3.241：macOS CoreML 推理加速、ExecuTorch 导出稳定性提升与边缘硬件支持扩展一、版本概述yolo v8.3.241 是一个以后端性能优化与兼容性增强为核心的版本更新，重点围绕 macOS 平台的 ONNX Runtime 推理加速、ExecuTorch 导出的稳定性、边缘硬件支持扩展以及可视化与文档体系的完善展开。该版本在不改变现有 CUDA 行为的前提下，为 Apple 硬件用户和嵌入式部署场景带来了明显收益。二、macOS 上 ONNX Runtime 的 CoreML 优先策略在 macOS 环境中，当使用 device="mps" 进行推理时，yolo v8.3.241 现在会优先使用 CoreML 执行提供器，而不是回退到 CPU。新的执行提供器选择顺序为：CUDA > CoreML（MPS） > CPU同时，日志输出更加清晰，能够明确提示当前实际使用的执行提供器，方便排查和性能分析。此外，IO Binding 现在仅在被支持的情况下使用（例如 CUDA 场景），避免了在 CoreML 执行时可能引发的兼容性问题。在实际应用中，这一改动可显著提升 macOS 上的推理性能，在部分测试场景中，单次推理耗时可从约 20 毫秒降低至 9 毫秒左右，接近 2 倍性能提升。三、ExecuTorch 导出稳定性改进针对 ExecuTorch 导出过程中偶发的失败问题，本版本进行了多项修复与优化：1. 在导出路径中对 NumPy 版本进行了限制，固定为不高于 2.3.5，以规避新版本 NumPy 与 CoreML 工具链之间的已知不兼容问题。2. 清理了导出流程中冗余的 torch 导入，使导出逻辑更加简洁。这些调整显著降低了在 CoreML 与移动端部署场景中出现“无法解释的导出失败”概率，使 ExecuTorch 的使用体验更加稳定可靠。四、Rockchip 硬件支持扩展yolo v8.3.241 新增对 Rockchip RV1126B 芯片的支持，并在代码与文档中明确标注该处理器为受支持目标。这意味着用户可以更直接地将 Ultralytics 模型导出并部署到 RV1126B 平台，无需额外的自定义补丁或修改配置，从而拓展了在边缘计算设备上的应用范围。五、2 通道图像可视化支持增强在可视化方面，Annotator 现已支持 2 通道的 numpy 图像数据。当输入为 2 通道图像时，会在绘制与保存之前自动转换为 3 通道格式，确保标注流程正常运行。这一改进使得非标准图像数据（如光谱数据或自定义传感器输入）在推理与可视化环节中更加顺畅，与 1 通道、3 通道以及多光谱数据的支持保持一致。六、TensorRT 与 TensorFlow 后端清理本次更新对推理后端相关代码进行了进一步梳理：1. TensorFlow SavedModel 的加载路径统一使用标准的加载方式，逻辑更加清晰。2. TensorRT 引擎解析过程进行了重构，更好地处理不同 TensorRT 版本下的动态形状与数据类型差异。这些改动提升了不同版本环境下后端行为的一致性与可维护性。七、文档与使用示例优化文档层面也进行了多项同步更新：1. SAM 3 相关示例修正了保存参数的使用方式，明确应在初始化阶段进行配置。2. Sony IMX500 相关示例代码进行了整理与排版优化。3. 自动标注、解决方案参数、跟踪与可视化参数、验证参数等文档描述更加准确、易读。4. 文档站点的工具与组件进行了版本更新，整体使用体验更加顺畅。八、版本总结yolo v8.3.241 是一次以性能与稳定性为导向的重要更新。它在 macOS 平台显著提升了 ONNX Runtime 推理速度，在移动与嵌入式场景中增强了 ExecuTorch 导出的可靠性，同时扩展了对边缘硬件和特殊图像数据格式的支持。配合后端清理和文档改进，该版本在训练、推理与部署的整体体验上更加成熟、可控，适合希望在多平台环境中稳定使用 YOLO 的用户升级采用。

2025年12月TIOBE编程语言排行榜，Go语言排名第15，Rust语言排名17。编程语言 R 重返前十。本月头条：编程语言 R 重返前十编程语言 R 以非常契合统计学家和数据科学家的特点而闻名。随着统计分析和大规模数据可视化的重要性不断提升，R 的受欢迎程度再次上升。例如，这一趋势也反映在 Wolfram/Mathematica（另一种具有类似能力的工具）上，本月该工具重新进入了前 50 名。在一些“传统”软件工程师眼中，R 因其非传统的语法以及在大型生产系统中的有限可扩展性而受到质疑。但对于特定领域的专家来说，它仍然是一个功能强大且优雅的工具。R 在大学以及科研驱动型行业中依旧蓬勃发展。过去，R 和 Python 常被视为竞争对手，而这场竞争最终在普遍采用度上由 Python 取胜。然而，R 依然开辟了一个稳固且持久的细分领域。它在快速实验、统计建模以及探索性数据分析方面表现突出。我们已经见证了许多 TIOBE 指数前十的语言此起彼伏，值得关注的是 R 是否能够保持目前的位置。另一条值得关注的消息是：下个月我们将公布 2025 年度 TIOBE 年度编程语言。目前来看，C# 似乎是这一头衔的最有力竞争者。TIOBE 编程社区指数是衡量编程语言流行度的一个指标。该指数每月更新一次。排名依据是全球范围内的专业工程师人数、相关课程数量以及第三方供应商的情况。计算排名时会使用包括 Google、Amazon、Wikipedia、Bing 在内的 20 多个知名网站的统计数据。需要注意的是，TIOBE 指数并不是评判“最好的”编程语言，也不是根据某种语言编写代码的总行数来排名。该指数可以用来检验你的编程技能是否仍然保持最新状态，或者在开始构建新的软件系统时，帮助你做出关于采用哪种编程语言的战略决策。其他编程语言完整的前 50 名编程语言榜单如下所示。此概览为非正式发布，因为有可能我们遗漏了某种编程语言。接下来的 50 种编程语言以下语言列表对应排名 第 51 位到第 100 位。由于这些语言之间的差距相对较小，这里仅按字母顺序列出：ActionScript、Algol、Alice、Awk、B4X、Caml、CLIPS、Clojure、Common Lisp、Crystal、D、Elm、F#、Forth、GAMS、Groovy、Hack、Icon、Inform、Io、J、JScript、Logo、Maple、Modula-2、Mojo、MQL5、NATURAL、Nim、Oberon、OCaml、Occam、OpenCL、PL/I、Q、REXX、S、Scheme、Simulink、Smalltalk、SPARK、SPSS、Stata、SystemVerilog、Tcl、Transact-SQL、V、VHDL、X++、Xojo。本月指数中的变化本月对指数的定义进行了如下调整：• Johann Weiser 建议将 LEAN 编程语言加入 TIOBE 指数。• LEAN 符合所有收录标准，因此已被加入到监测列表中。• LEAN 在指数中的首秀排名为 第 145 位。长期历史趋势为了更好地了解整体趋势，以下表格展示了过去多年 前十种编程语言 的排名情况。请注意，这些排名是 12 个月平均位置。重要说明：• 2001 年之前的数据并非基于网络搜索引擎的统计结果，而是基于 Usenet 新闻组的命中次数，这些数据是通过回溯计算得出的。• 在上表中，“Visual Basic” 与 “(Visual) Basic” 是不同的概念。直到 2010 年，“(Visual) Basic” 指的是所有可能的 Basic 方言，包括 Visual Basic。经过讨论，决定将“(Visual) Basic”拆分为不同的方言，例如 Visual Basic .NET、经典 Visual Basic、PureBasic、Small Basic 等。由于 Visual Basic .NET 已经成为 Visual Basic 的主要实现版本，现在它被称为 “Visual Basic”。• SQL 编程语言是在 2018 年才被纳入 TIOBE 指数，因为有人指出 SQL 是图灵完备的。因此，尽管这门语言非常古老，但它在指数中只有很短的历史。编程语言名人堂下面的名人堂列出了历届“年度编程语言”奖项的获奖者。该奖项授予的是在一年内排名上升幅度最大的编程语言。缺陷与变更请求以下是最常被提出的 前 5 项改进或缺陷修复请求。1. 除了 “<语言> programming” 之外，还应该尝试其他查询，例如 “programming with <语言>”、“<语言> development” 和 “<语言> coding”。2. 添加其他自然语言（不仅限于英文）的查询。计划首先从中文搜索引擎 百度 开始。这一功能已部分实现，并将在未来几个月内完成。3. 增加一个已被拒绝的搜索关键词列表，以减少重复收到关于 Rails、jQuery、JSP 等的邮件。4. 启动面向数据库、软件配置管理系统和应用框架的 TIOBE 指数。5. 一些搜索引擎允许查询过去一年内新增的页面。TIOBE 指数应仅跟踪这些最近新增的页面。

nats v2.12.3 正式发布：JetStream、Raft 与 MQTT 稳定性和性能的全面提升nats-server v2.12.3 版本已于 2025 年 12 月 17 日正式发布。本次版本在保持与 2.11.x 系列兼容的前提下，对底层依赖、JetStream、Raft 共识机制、WebSocket 以及 MQTT 功能进行了大量优化和问题修复，是一次以稳定性、性能和健壮性为核心的维护型升级。以下内容基于官方更新日志，对 v2.12.3 的改动进行详细说明。一、版本与基础环境更新1. Go 版本本次发布将构建所使用的 Go 版本升级至 1.25.5，为整体性能与运行时稳定性提供了更加坚实的基础。2. 依赖库升级多个关键依赖完成升级，包括：• go-tpm 升级至 v0.9.7• nkeys 升级至 v0.4.12• golang.org/x/crypto 分别升级至 v0.45.0 和 v0.46.0• golang.org/x/sys 升级至 v0.39.0• klauspost/compress 升级至 v1.18.2• antithesis-sdk-go 升级至 v0.5.0 的默认 no-op 版本这些依赖更新主要集中在安全性、压缩性能以及系统调用兼容性方面。二、新增功能1. WebSocket 配置增强在 WebSocket 配置块中新增了专用的心跳参数 ping_internal。该配置允许针对 WebSocket 连接单独设置 Ping 发送间隔，有助于更精确地控制连接保活策略，适合高并发或弱网络环境下使用。三、功能改进（一）JetStream 改进1. 更快的源序列扫描在设置带有 subject 过滤条件的 source 时，服务器对最后一条源消息序列的扫描速度显著提升，减少了流初始化和恢复过程中的等待时间。2. Meta Layer 启动行为优化在服务器启动时，Meta Layer 现在会对恢复操作进行分阶段处理并进行去重，而不再出现先快速应用再撤销冲突分配的情况，从而降低启动阶段的不稳定风险。3. Interest-based Stream 性能提升当 interest-based stream 存在较大兴趣空洞时，消费者兴趣检查逻辑得到了显著优化，大幅提高性能。（二）MQTT 改进1. 保留消息跨账号支持增强当保留消息来源于不同账号并且带有 subject 转换时，现在可以正常工作，解决了此前在复杂账号结构下的使用限制。四、问题修复（一）通用问题修复1. WebSocket 解压缓冲限制修复了 WebSocket 连接在进行解压时未正确限制缓冲区大小的问题，有效避免潜在的内存风险。（二）JetStream 与 Raft 相关修复这是本次版本中修复内容最为集中的部分，主要集中在一致性、数据安全和集群稳定性上：1. 修复因网关连接中 ACK 回复 subject 变换无效而触发的协议错误问题。2. Meta Layer 仅在达到法定人数后才会响应 peer remove 请求。3. 非终结型全通配符的非法 subject 过滤器不再产生异常匹配结果。4. 修复集群模式下创建 Stream 时可能产生的数据竞争问题。5. Raft 不再允许并发执行多个成员变更操作。6. 修复在处理缺失节点或分配信息的快照时可能触发的 panic。7. 在整块消息被 purge 时，subject 跟踪信息和定时消息能够正确更新。8. Raft 在计算法定人数时不再统计已被移除节点的响应。9. 修复 AsyncFlush 在进程暂停后可能导致 filestore 丢失写入的问题。10. Filestore 在更新统计信息前会优先处理磁盘上的消息移除，提高错误处理可靠性。11. Raft 法定人数计数逻辑重构，仅在 Leader 仍属于成员时才隐式计入确认。12. 在处理 peer remove 时立即写入 peer 状态，避免重启后被移除节点意外重新出现。13. DiscardNewPerSubject 保留策略现在由 Leader 在提议阶段统一执行，减少副本间状态不一致的可能。14. Raft 不再允许移除仅剩的最后一个节点。15. 修复 Stream 健康检查中的数据竞争问题。16. 在 compact 或 purge 几乎为空的 Stream 到序列 2 时，能够正确写入 tombstone 用于序列恢复。17. 修复在同时使用 skip sequence 与 compact 时可能导致块偏移错误并引发数据损坏的问题。18. 当 compact 回收空间超过一半时，采用原子写入以避免进程被终止时丢失消息。19. Filestore 查询在遇到缓存错误时会正确使缓存失效。20. 改进消息块加载过程中的错误处理逻辑。21. 新增 Raft 成员操作不再导致多数派被分裂。22. Filestore compaction 不再出现 idx 缓存缺失错误，并能正确调整消息块的高低序列及删除映射。23. 修复在 peer remove 与领导权转移期间，因心跳导致已移除节点被重新接纳的问题。24. 修复在 Stream 快照期间可能发生的潜在数据不同步问题。（三）MQTT 修复1. MQTT 客户端的最大 payload 大小现在能够被正确限制。2. 修复重新加载配置时，在无权限访问保留消息的情况下可能触发的 panic。3. 修复在跨非 JetStream 启用服务器时，JetStream API 请求的账号映射问题。4. QoS0 消息在跨账号 import/export 并带有 subject 映射时能够正确处理。5. 修复服务器重启后因最后序列检查导致加载保留消息失败的问题。6. 修复集群环境下可能导致保留消息损坏的缺陷。7. 对 $MQTT. subscriptions 的权限处理进行了优化，默认隐式允许，仅 deny ACL 仍可进行限制。8. 修复服务器重启后 QoS2 消息无法恢复获取的问题。五、总结nats v2.12.3 是一次以稳定性、性能和一致性为核心目标的重要更新。JetStream 在存储安全、恢复流程和高并发场景下的表现得到显著增强；Raft 在成员变更和法定人数计算方面更加严谨；MQTT 功能在集群和跨账号场景下的可靠性进一步提升。对于正在使用 2.11.x 或 2.12.x 早期版本的用户，该版本非常值得在充分验证后进行升级。

agno v2.3.18 版本更新详解：Vertex AI 显式凭证支持与数据库路由修复agno 在 2025 年 12 月 20 日正式发布 v2.3.18 版本。本次更新提交数量虽不多，但涵盖了对 Google Vertex AI 使用方式的重要改进，以及对 AgentOS 中数据库迁移路由的一项关键缺陷修复，整体提升了在生产环境和系统重同步场景下的稳定性与可配置性。一、版本基本信息版本号：v2.3.18发布日期：2025 年 12 月 20 日本次发布共包含 3 个提交，涉及 6 个文件变更，新增代码约 730 行，主要集中在模型能力扩展、系统路由修复和测试补充三个方面。二、主要改进内容1. Google Vertex AI 新增显式凭证文件支持在 v2.3.18 中，agno 的 Gemini 模型对 Vertex AI 的认证方式进行了增强，新增了对 google oauth2 凭证对象的直接支持。这意味着在使用 Vertex AI 模式时，不再只依赖环境变量或默认凭证，而可以显式传入一个凭证对象，用于精细化控制生产环境下的认证方式。核心变化点包括：• Gemini 模型新增 credentials 参数，用于接收 Google Cloud 的凭证对象• 当 vertexai 参数为 True 时，如果提供了 credentials，将其直接传入 genai Client• 在非 Vertex AI 模式（即 Google AI Studio 模式）下，即使提供了 credentials，也不会被传递，避免混用认证方式这种设计使得模型在不同运行环境下的行为更加明确，特别适合以下场景：• 多项目、多服务账号并存的生产环境• 容器化或 CI/CD 场景中需要显式加载服务账号 JSON 文件• 不方便或不允许使用全局默认凭证的部署环境官方示例中通过加载服务账号 JSON 文件创建凭证对象，并在初始化 Gemini 模型时传入，从而直接完成 Vertex AI 的身份认证配置。2. Gemini 客户端初始化逻辑完善在 Gemini 模型的 get_client 方法中，对 Client 初始化参数进行了细化处理：• Vertex AI 模式下，project 和 location 参数会被明确设置• 如果 credentials 不为空，则加入 Client 初始化参数• 最终统一过滤掉值为 None 的参数，保证 Client 初始化参数干净且可控同时补充了对应的单元测试，分别验证了以下情况：• Vertex AI 模式下传入 credentials 时，Client 能正确接收• Vertex AI 模式下未传入 credentials 时，不会错误传递该参数• 非 Vertex AI 模式下，即使传入 credentials，也不会传递给 Client这些测试确保了不同模式下 Gemini 客户端行为的一致性和可预期性。三、问题修复：数据库迁移路由无法重建本次版本还修复了一个在 AgentOS 重同步过程中存在的问题。此前在执行 resync 操作时，数据库迁移路由在某些情况下不会被正确重新注册，导致相关接口缺失。在 v2.3.18 中：• 重构了路由重新注册列表• 确保数据库路由在重同步时能够被正确重新 provision• 避免系统在重载配置或恢复状态后出现数据库相关功能不可用的问题这一修复对依赖 AgentOS 进行长期运行和热更新的场景尤为重要。四、测试与版本号更新为了保证上述改动的稳定性，本次更新新增了：• 针对 Gemini 模型凭证逻辑的单元测试• 针对 AgentOS resync 行为的集成测试同时，agno 的项目版本号在 pyproject.toml 中从 2.3.17 正式更新为 2.3.18，与发布版本保持一致。五、小结agno v2.3.18 是一次以稳定性和生产可用性为核心的版本更新：• 在模型层面，为 Vertex AI 提供了更灵活、安全的认证方式• 在系统层面，修复了数据库路由在重同步时的关键缺陷• 在工程层面，通过新增测试确保行为的一致性

ollama v0.13.5 发布详解：新模型接入、引擎升级与工具能力增强ollama v0.13.5 于 2025 年 12 月 19 日正式发布。本次版本更新规模较大，共合并 10 次提交，涉及约 150 个文件的调整，新增代码 10997 行，删除代码 6838 行。更新内容主要集中在模型支持、引擎能力、工具定义与解析、以及底层推理和运行时优化等方面。一、新模型支持：FunctionGemma 接入在 v0.13.5 中，ollama 正式引入了 Google 的 FunctionGemma 模型，并完成了对应的解析器和渲染器支持。这一更新使 FunctionGemma 能够在 ollama 生态中以原生方式运行，并正确处理函数声明、函数调用和函数响应等结构化内容。同时，SentencePiece 分词解析逻辑也进行了扩展，新增了对多种函数相关控制符号的识别，包括函数声明、函数调用、函数返回以及转义标记等。这保证了 FunctionGemma 在使用 spm 分词器时能够正确区分普通 token 与控制 token。二、BERT 架构模型全面切换至 Ollama 引擎本次更新的一个重要变化是：BERT 架构模型开始统一使用 Ollama 自研引擎运行，而不再依赖旧的执行路径。在架构判定与运行能力上完成了多项调整：• 将 bert 明确列为需要 Ollama Engine 的架构类型• 在特性判断中，bert 开始支持 flash attention• nomic-bert 等相关模型也统一纳入新的引擎判定逻辑这一变化为 BERT 及相关嵌入模型带来了更一致的执行方式，也为后续功能扩展提供了更稳定的基础。三、DeepSeek-V3.1 内置渲染与工具解析能力ollama v0.13.5 针对 DeepSeek-V3.1 增加了内置 renderer 和 tool parsing 能力，使模型在输出结构化结果时可直接由引擎完成解析和渲染。同时，补充并修复了工具定义中嵌套属性无法正确处理的问题，使 DeepSeek 系列模型在使用复杂工具参数结构时更加可靠。此外，还新增并完善了 DeepSeekV3 家族的专用解析器逻辑，进一步提升了该系列模型在 ollama 中的可用性与一致性。四、工具定义系统增强：支持嵌套属性在 API 类型层面，本次更新扩展了 ToolProperty 结构，新增了对 properties 字段的支持，使工具参数能够表达任意层级的嵌套对象结构。这一能力不仅支持简单对象嵌套，还支持深层多级嵌套，并通过新增的单元测试覆盖了以下场景：• 对象属性的嵌套定义• 多层对象中继续包含对象属性• JSON 的反序列化与序列化回环校验这使得 ollama 在函数调用和工具调用场景下，可以完整表达复杂参数定义，提升了与现代大模型工具调用规范的兼容性。五、GGML 与底层推理逻辑更新v0.13.5 更新了 GGML 版本引用，并同步调整了相关构建配置文件。Makefile 中的 GGML 上游提交指针发生变更，保证引擎使用最新的底层实现。在 KV Cache 和因果掩码构建逻辑中，也进行了精简和修复：• 移除了多余的 MaskBatchPadding 和 MaskDType 默认初始化逻辑• 简化了掩码构建过程，仅按当前 batch 大小生成 mask• 修复了 padding mask 计算中的冗余代码这些调整有助于减少不必要的内存占用，并提升推理阶段的稳定性。六、llama.cpp 集成与初始化流程整理在 llama.cpp 对接代码中，本次版本对模型初始化、上下文创建和采样器初始化流程进行了较大幅度的整理：• 引入了基于 impl 的封装结构来管理模型与上下文生命周期• 清理了重复的返回路径和无效代码• 修正了模型加载失败与上下文创建失败时的处理逻辑• 优化了采样器初始化与 logit bias 注入流程同时，在模型元信息解析中，采样参数读取逻辑被去重处理，避免重复判断配置标志，提高了代码可读性和一致性。七、其他杂项与维护性改进除核心功能外，v0.13.5 还包含一系列维护性更新，例如：• 清理不再需要的冗余代码• 调整类型定义，引入 ConfigV2 和 RootFS 相关类型• 回滚 granite-embedding 相关变更• 更新同步规则，补充 llama.cpp 中 mtmd 工具和模型源码的同步路径结语总体来看，ollama v0.13.5 是一次偏向基础能力增强与架构统一的版本更新。它在模型支持范围、工具系统表达能力以及底层执行稳定性方面都迈出了重要一步。对于使用 BERT、DeepSeek、FunctionGemma 等模型的用户而言，这一版本提供了更完善、更一致的运行体验，也为后续功能扩展奠定了坚实基础。

transformers v4.57.3 更新说明：修复本地模型加载隐藏问题并撤回上版本版本发布时间transformers v4.57.3 于 2025年11月25日正式发布。更新内容在本次更新中，主要修复了两个问题：1. 本地模型加载隐藏问题当使用 local_files_only=True 参数加载模型时，存在一个隐藏的 bug。该问题在此前版本中未被测试流程发现，对多个用户的模型加载造成影响。2. 近期补丁相关拼写错误对于此前补丁中出现的拼写错误进行了修正，以确保代码的正确性和稳定性。主要修复提交此次核心修复对应提交号为：b605555。撤回上个版本由于这些问题影响范围较大，且测试流程未能在发布前检测出来，官方宣布撤回上一版本，替换为当前版本。总结transformers v4.57.3 的更新重点在于解决本地加载模型时的隐藏 bug，并修正补丁代码的拼写问题，同时撤回上版本以确保用户的正常使用。建议升级至最新版本，以获得最佳的使用体验和稳定性。

pion/webrtc v4.1.8 版本更新详解：DTLS 指纹校验、Mux 超时机制与稳定性改进pion/webrtc v4.1.8 版本已正式发布，本次更新主要集中在安全性增强、网络传输可靠性优化以及事件回调行为修正等方面。整体更新内容不多，但每一项都对实际使用场景具有明确价值，下面对本次版本变更逐条进行详细说明。一、新增 DTLS 握手阶段指纹校验选项在 v4.1.8 中，新增了在 DTLS 握手过程中检查指纹的可选能力。DTLS 是 WebRTC 中用于保障数据通道和媒体传输安全的关键协议，而证书指纹校验是确认通信对端身份的重要手段。新增该选项后，开发者可以在 DTLS 握手过程中决定是否对证书指纹进行校验，从而进一步提升连接安全性。这一改动使 pion/webrtc 在安全策略配置方面更加灵活，适用于对安全要求较高的实时通信场景，同时也保持了对原有行为的兼容性。二、为 Mux 实现超时控制机制本次版本为 Mux 实现了 deadlines（超时）机制。Mux 在 pion/webrtc 中承担着多路复用网络数据的职责，如果在网络异常或对端响应缓慢的情况下缺乏超时控制，可能导致阻塞或资源长期占用。加入超时机制后，Mux 在读写操作中可以感知截止时间，当超过设定时间仍未完成操作时及时返回，从而提升系统的健壮性和可控性。这一优化对于高并发连接和复杂网络环境下的 WebRTC 应用尤为重要。三、升级 STUN 依赖模块至 v3.0.2在依赖管理方面，pion/webrtc v4.1.8 将 github.com/pion/stun/v3 模块升级到了 v3.0.2 版本。STUN 是 WebRTC 用于 NAT 穿透的重要协议组件，更新依赖可以带来更好的稳定性和潜在的问题修复。该升级属于内部依赖更新，对外 API 行为没有直接影响，但有助于确保 pion/webrtc 在网络连接建立过程中的可靠性和兼容性。四、关闭后不再触发 OnBufferedAmountLow 回调在本次更新中，还修复了一个事件回调行为问题：当连接已经关闭时，不再触发 OnBufferedAmountLow 回调。此前在特定情况下，即使底层资源已关闭，相关回调仍可能被调用，这容易导致业务层逻辑混乱甚至出现异常处理。修复后，回调触发时机更加符合生命周期预期，开发者可以更加放心地在回调中处理缓冲区相关逻辑，从而提升整体代码健壮性。总结pion/webrtc v4.1.8 虽然不是一次大规模功能更新，但在安全性、网络超时控制、依赖维护以及事件回调一致性方面均进行了有针对性的改进。这些优化有助于提升 WebRTC 应用在真实生产环境中的稳定性与可控性，推荐相关项目逐步升级并验证。

agno v2.3.13 发布：AgentOS 引入 RBAC 权限控制与安全机制升级2025年12月15日，agno 发布了最新版本 v2.3.13。此次更新在功能与安全层面都有显著提升，尤其是为 AgentOS 引入了 基于角色的访问控制（RBAC） 机制，为系统安全和资源管理带来了更强的灵活性与可扩展性。一、主要新特性1. AgentOS Role-Based Access Control (RBAC)本次版本最大的亮点是 AgentOS 支持了 RBAC 权限控制。通过该机制，可以在自动或手动配置下使用 JWT（JSON Web Token） 进行基于授权范围的访问控制。RBAC 相关功能包括：• 全局 JWT 验证机制所有访问 AgentOS 的流量都需要携带签名的 JWT Token，包含正确的用户权限范围（Scopes），系统会基于该 Token 进行验证与授权。• 按端点授权控制管理员可以根据 JWT Token 中的权限范围，定义各端点（endpoint）的访问策略。是否允许访问某个接口，将根据配置的 Scope 自动判断并执行。• 按代理资源控制RBAC 还允许通过配置特定的资源访问范围（如 agents:my-agent:read）来控制可使用的 Agent。例如：• 调用 POST /agents/my-agent/runs 时可以精确控制哪些用户能运行特定的 Agent。• 调用 GET /agents 或 GET /agents/{id} 时可控制返回哪些 Agent 数据。此机制实现了对用户可 使用与查看哪些 Agent、团队及工作流（Workflow） 的完全控制，安全性与精细化管理能力显著提升。此外，AgentOS UI 将在未来几天内发布兼容版本，以支持该 RBAC 功能的可视化配置与使用。二、JWTMiddleware 类更新说明在 JWTMiddleware 中进行了重要调整：• secret_key 已弃用原有参数仍受支持，但建议使用新的参数 verification_keys=[...] 进行配置，以便支持更安全的密钥验证机制。• 默认算法更新默认算法由 HS256 修改为 RS256，采用非对称加密形式，更适合生产环境中的安全验证需求。这一变化将使 AgentOS 在安全性方面与主流标准接轨，同时简化了分布式系统中多节点验证的部署。三、其他更新与修复• 修复 Redis 中的 Reranker 分配问题。• 重构知识内容新增逻辑，改为同步方式以提升稳定性。• 修复搜索查询在引用（citations）处理上的异常。• 发布稳定版本 2.3.13。四、总结agno v2.3.13 是一次重要的安全与架构升级版本。随着 AgentOS RBAC 的加入，开发者与团队可以实现更细粒度的权限控制、更安全的用户验证流程以及更可控的 Agent 资源管理。

ollama v0.13.4 发布——全新模型与性能优化详解2025年12月13日，ollama v0.13.4版本预发布，随后于2025年12月16日正式发布。本次更新是一次重要的版本迭代，包含新模型的推出、引擎默认设置的调整、Flash Attention机制的自动化启用，以及一系列对Gemma 3架构模型的修复与增强。以下是详细更新内容。一、新增模型1. Nemotron 3 Nano这是一款全新的开放高效智能代理模型，定义了高性能标准，面向智能代理应用场景。2. Olmo 3 与 Olmo 3.1这一系列开放语言模型旨在推动语言模型研究科学化。其预训练基于 Dolma 3 数据集，后训练使用 Dolci 数据集，代表了更系统化的语言模型训练流程。二、主要更新内容• 默认启用 Ollama 引擎所有剩余模型均默认启用 Ollama 引擎，统一运行环境。• 默认启用 Flash Attention 自动模式模型将自动启用 Flash Attention，以优化注意力计算效率。• 修复 Gemma 3 长上下文处理问题解决了长文本情况下上下文处理异常的问题，使 Gemma 模型更加稳定。• 修复 Gemma 3 QAT 模型导入问题修复了 Gemma 3 架构在量化训练模型导入时可能出现的异常。三、代码更新与文档修订• 在 api/client.go 文件中修正了 Modelfile 的超链接后缀，将.md改为.mdx。• 删除了 macOS 与 Windows 平台中“发送 UI 请求消息”的冗余代码，使应用逻辑更简洁。• cocoa 对话框代码中增强了多文件处理机制，确保缓冲区内存安全。• Windows 文件对话框错误输出格式更准确。• server.go 修改了模型路径检查逻辑，在路径不可用时使用默认路径。• wintray/eventloop.go 改进了底层事件循环的内存安全处理，增加了注释控制。• 文档 docs/api.md 全面更新对 Modelfile.mdx 的链接引用，使说明一致化。• 新增工具文档与示例提取功能：新增目录：.docs/tools/extract-examples包含：提取后可执行：• README.md：介绍如何将 MDX 中的代码示例提取到临时目录运行。• main.go：示例提取脚本，支持自动生成 package.json 与 pyproject.toml 依赖文件。.cdnpm install  # JS示例node file.js 或 python file.py 或 bash file.sh四、环境配置与引擎优化• envconfig/config.go 调整了 OLLAMA_NEW_ENGINE 的默认值逻辑，引入 BoolWithDefault 方法，使引擎启用逻辑更灵活。• 增强了环境变量映射支持，结构更加全面。五、模型与计算优化1. Flash Attention 类型系统引入ml/device.go 新增 FlashAttentionType 枚举类型：• Auto• Disabled• Enabled此设计使 Flash Attention 模式控制更细化，支持自动适配硬件。2. GGML 图计算增强在 fs/ggml/ggml.go 中，Flash Attention 引入枚举类型接口，支持多种量化缓存类型检测与验证方法，提升兼容性。3. Llama 引擎增强llama/llama.go 重构了 Flash Attention 参数逻辑——支持自动、启用与禁用三种模式，适配不同模型及硬件环境。4. LLM 服务逻辑优化llm/server.go 增加了 Flash Attention 用户显式设置检测逻辑，并完善了 KV 缓存量化兼容性处理。当使用量化 KV 缓存类型时必须启用 Flash Attention。KV 缓存校验机制进一步完善，增加更详细的警告提示与逻辑分支。5. ML 后端结构改进ml/backend.go 与 ml/backend/ggml/ggml.go 中统一 Flash Attention 类型接口，并在注意力计算中使用新的枚举系统，实现高效的多设备内存调度与算子融合优化。六、Gemma 3 架构修复与改良model/models/gemma3/model_text.go对 Gemma 3 的旋转位置嵌入 (RoPE) 算法进行了调整：• 新增 ropeValuesForLayer 方法，按层返回位置嵌入基础值与缩放因子。• 修复 QAT 权重导致的错误缩放比问题，强制 ropeScale 为 1.0。• 优化滑动窗口注意力机制下的 softcap 和 rope 参数初始化逻辑，使注意力计算更加准确。七、OpenAI兼容层更新openai/responses.go调整了工具调用消息的合并逻辑：• 当助手消息存在时，将后续工具调用结果合并到上一条消息中，而非新建消息。• 保留思考过程（Thinking）内容的正确关联，确保连续对话上下文一致。同时新增全面的单元测试 openai/responses_test.go，覆盖函数调用与工具输出场景，验证新逻辑稳定性。八、贡献统计• 本次版本共有 9 次提交，22 个文件修改，涉及 6 位贡献者。• 修改代码约 812 行新增与 253 行删除，覆盖核心引擎、文档、模型逻辑与工具部分。九、总结ollama v0.13.4 是一次大幅度增强版发布，重点在于：• 增强引擎默认配置与性能自动化；• 推出新一代开放智能模型；• 完善 Gemma 与 Llama 架构的兼容性；• 引入更完整的 Flash Attention 类型系统；• 提高文档与开发工具的自动化程度。

DeepSpeed v0.18.3 发布：优化性能与稳定性，增强兼容性与调试体验DeepSpeed 正式发布了 v0.18.3 版本，本次更新重点围绕性能优化、调试工具增强、兼容性改进以及优化器与硬件支持拓展展开。该版本包含多个细节更新，进一步提升了分布式训练的稳定性与可扩展性。以下为本次版本的主要更新内容。一、系统与构建改进• 更新 version.txt 文件，确保版本管理一致性。• 更新模态持续集成逻辑（modal CI），修复并改进相关流程。• 解释并完善 leaf 模块说明，便于用户理解模块功能。• 禁用部分 nv-lightning 配置项，优化持续集成测试过程。• 使用 PyTorch 工具检测 ninja 构建工具，提高编译检测的可靠性。• 信任 Intel 服务器以进行 XPU 测试，增强跨硬件平台的测试安全性。• PyTorch 兼容的 backward API，进一步提升与 PyTorch 的接口一致性。• 启用 compiled autograd 进行反向传播，提升反向计算性能。二、优化器与学习率改进• Muon 优化器支持独立学习率参数：允许分别设置 “muon_lr” 和 “adam_lr”，以便更灵活地控制优化器的学习率。• Muon 优化器动量缓存在 GPU 上，减少主机与设备之间的数据传输，提高训练效率。• 低精度主参数/梯度/优化器状态支持，增强在 FP8、FP16 与 BF16 等低精度训练场景下的性能与稳定性。三、内存与性能优化• see_mem_usage 工具改进：确保无论何种情况下都能正确输出内存使用信息。• 使调试工具更加健壮，在异常和边界情况下保证运行稳定。• Zero Stage 1-2 优化：在未配置时不再固定内存，从而减少不必要的内存占用。• 修复在加载模型或 Zero 检查点时 ds_secondary_tensor 可能出现的数据污染问题，提高模型加载与恢复的正确性。• 在交换张量为空时跳过 aio wait 操作，进一步提升性能与资源利用效率。四、测试与数值稳定性改进• 改进 ROCm FP8 单元测试：对 FP16 和 BF16 情况放宽容差，以适应更多硬件环境。• 放宽低精度计算的限制，增强在 AMD GPU 等环境下的稳定性。五、功能拓展与社区支持• 新增 Qwen2.5 模型至 AutoTP 模型列表，支持更多自动并行模型配置。• 更新安全文档（SECURITY.md） 指向 GitHub 官方报告渠道，统一安全报告流程。• 新增关于 Ray 与 DeepSpeed 联合技术交流会的资讯，促进社区合作与技术传播。六、监控与性能分析• 新增 Wall Clock Timers API，为用户提供更精确的时间统计和性能分析接口，方便评估训练过程中的时间分布与瓶颈。总结：DeepSpeed v0.18.3 版本在保持高性能的同时，进一步提升了系统的稳定性、灵活性和兼容性。此次更新特别加强了优化器配置能力、内存管理与调试工具的可靠性，对于使用分布式训练的研究团队和开发者而言，将提供更高效、更可控的深度学习训练体验。

dify 1.11.1 版本发布：重要安全更新、性能优化与新特性解析1. React 和 Next.js 安全升级将 react 与 react-dom 升级至 19.2.3，修复已知的 CVE 安全漏洞。同时，Next.js 也完成了安全更新，提升前端安全性。2. 凭证管理优化修复了 available_credentials 为空的问题，保证凭证的正常读取与使用。3. 描述长度限制自动生成的描述会进行截断，避免超过 400 字符限制导致提交失败，从而提升提交的顺畅度。4. 内容类型 Charset 设置响应内容类型中添加了 charset，保证数据格式的一致性与正确性。5. Flask-Restx 属性错误修复移除了 validate=True 参数，解决了在 flask-restx 中产生的 AttributeError。6. 文档处理优化优化了 save_document_with_dataset_id 函数的性能，并修复了 DOCX 文件中外部图片导致的提取失败问题。7. Token 获取优化当 access_token 为空时，不再抛出错误，而是返回 None，提高系统容错能力。8. Hit-Test 失败问题修复针对不存在的附件 ID 导致 hit-test 失败的问题进行了修复。

ollama v0.13.3 最新发布：新增模型与功能优化详细解读2025年12月12日，ollama v0.13.3 版本正式发布。本次更新引入了多款全新模型，并对现有功能进行了优化与修复，为开发者在代码分析、多语言检索以及软件工程领域提供了更高效的支持。一、全新模型1. Devstral-Small-2• 24B 参数模型• 擅长使用工具探索代码库• 支持多文件编辑• 为软件工程类智能代理提供强大能力支持2. rnj-1• 8B 参数开源权重、稠密模型• 由 Essential AI 从零开始训练• 针对代码及 STEM（科学、技术、工程、数学）领域优化• 性能可与当前开源权重领域的先进模型媲美3. nomic-embed-text-v2• 多语言 MoE（混合专家）文本嵌入模型• 出色的多语言检索能力二、功能优化与改进1. 嵌入接口优化• 改进了 /api/embed 与 /v1/embeddings 在使用时的截断逻辑2. 架构扩展• 在 Gemma 3 架构基础上扩展，支持 rnj-1 模型3. 模型输入修复• 修复了使用 qwen2.5vl 进行图像输入时出现的报错问题三、近期更新的具体改动• 截断逻辑优化：修正运行时截断逻辑，并移除服务器端截断• rope 重构：提升模型在长上下文处理中的性能稳定性• rnj-1 推理支持：新增对 rnj-1 模型的推理支持• qwen2.5vl metal argsort 修复• nomic-embed-text-v2 模型实现完善• UI优化：• 修复模型下载完成后能力不更新的问题• 使用 Ollama 接口进行用户认证与健康检查• 使用 requestAnimationFrame 防止文本底部被截断• 性能提升：升级 llama.cpp（17f7f4）版本，提升 SSM 性能• 命令行工具修复：• 修正 cmd/bench 下 README 中的选项表与二进制文件名• 路由优化：在工具调用中增加 logprobs 输出• 模型调整：更新 ministral 与 devstral 的转换与超参数设置• 模板功能增强：新增 yesterdayDate 辅助函数• 嵌入性能优化：调整 embeddings 的批量大小• API扩展：新增 v1/responses 接口支持• rotary embeddings 修复：解决 ministral 3 在旋转嵌入上的问题• 文档更新：调整 README 内容四、更新总结本次 ollama v0.13.3 发布，不仅带来了三款定位不同的新模型，覆盖了代码分析、科学工程以及多语言检索等多领域，同时对嵌入接口、模型架构、性能以及开发者工具进行了广泛优化，进一步提高了使用体验与运行稳定性。

eino v0.7.7 发布：新增文件系统中间件，优化序列化与反序列化，修复工具信息流问题2025年12月4日，CloudWeGo 开源项目 eino 正式发布了 v0.7.7 版本。本次更新主要围绕文件系统中间件支持、序列化处理范围扩展、反序列化稳定性提升以及工具信息流优化进行了改进。以下是更新详情：一、支持文件系统中间件（filesystem middleware）在本版本中，ADK 模块新增了对文件系统中间件的支持。这一特性使得在处理文件存储、读取、传输等场景时，能够通过中间件机制实现更加灵活、可扩展的处理逻辑，从而简化开发者在文件操作过程中的接口适配工作。二、增加序列化处理范围（serialization scope）持续优化 CI 流程的同时，这一版本扩展了序列化的处理范围，使得数据在持久化与传输过程中能够涵盖更广泛的类型与使用场景。这对大规模数据处理以及分布式环境下的任务执行具有积极作用。三、修复数组与切片反序列化异常针对反序列化环节中出现的 checkpoint 恢复时数组和切片解析过程中可能引发的崩溃问题，本次更新进行了修复。此改进有效提升了系统在复杂数据恢复场景下的稳定性与可靠性，减少了运行时的潜在风险。四、工具信息流中增加工具名称在 ADK 模块的流式工具消息（stream tool message）中，现在会附带工具名称信息。这一改动可帮助开发者在处理多工具协作或调试日志时，快速定位消息来源工具，提高问题排查与调试的效率。总结eino v0.7.7 的发布为开发者带来了以下关键改进：• 文件系统中间件支持，更好地集成文件处理逻辑• 序列化范围扩展，适应更广泛的数据场景• 反序列化稳定性增强，避免数组和切片解析崩溃• 工具信息流更明确，便于调试与维护

pion/webrtc v4.1.7 版本更新详解2025 年 12 月 5 日，pion/webrtc 发布了最新版本 v4.1.7。该版本在稳定性、性能和协议兼容性方面都有明显提升，同时对多个依赖模块进行了更新。本次更新的重点包括对 RTP、ICE、DTLS、SRTP 等模块的升级与新特性支持，以及对测试稳定性的改进。主要更新内容1. 新功能与选项支持• 增加忽略 rid 暂停的选项新增了在 a=simulcast:recv 中可选择忽略 rid 暂停的功能，使得在多码流接收场景下更加灵活。• 精准 RTP 时间戳支持引入 WithDirectPTS 选项，可实现更精确的 RTP 时间戳处理，提升音视频同步效果。• ICE 候选 Trickling 能力检测新增 CanTrickleICECandidates 方法，用于判断是否支持 ICE trickling，这对于减少连接建立时间非常有用。• 支持广播 ICE trickling 信息增强 SDP 中 ICE trickling 的能力声明。• DTLS Cipher Suites 可配置新增了配置 DTLS 密码套件的选项，让用户可根据安全性需求选择不同的加密算法。2. 协议与流处理改进• Simulcast 改进• 在探测过程中不再丢弃数据包，提高多码流切换的平滑度。• 考虑首个数据包读取 Simulcast IDs，改善媒体流识别性能。• NACK/RTX 重传测试优化• 增加了确定性 NACK/RTX 重现测试，提高重传机制的可预测性。3. 模块更新本次版本升级同步更新了多个依赖模块，确保性能与兼容性：• RTP 升级至 v1.8.26• ICE/v4 升级至 v4.0.13，并在此版本中多次小更新至 v4.0.12 与 v4.0.11• DTLS/v3 升级至 v3.0.8• SRTP/v3 升级至 v3.0.9• SCTP 升级至 v1.8.41• Interceptor 升级至 v0.1.42• TURN/v4 升级至 v4.1.3，以及 v4.1.2• Transport/v3 升级至 v3.1.1 与 v3.1.0• STUN/v3 升级至 v3.0.1• RTCP 升级至 v1.2.164. 测试与稳定性提升• 修复多个测试用例的竞争条件问题，减少测试过程中的偶发失败。• 改进 Trickling-ICE 示例代码，提升演示效果。• 增加简单的 datachannel 示例（含 demo.html），方便开发者快速上手。• 改进 datachannel 示例性能。• 增加自定义日志示例说明。• 多项 CI 配置更新，确保持续集成环境的稳定。总结pion/webrtc v4.1.7 在多媒体传输稳定性和协议兼容性上有显著提升，尤其是 Simulcast 优化、ICE trickling 支持、精准 RTP 时间戳以及可配置 DTLS 密码套件，为开发者提供了更多控制和优化的可能性。同时，此次更新同步维护了依赖库版本，保障了整体系统的安全与性能。

ollama v0.13.1 发布：全新 Ministral-3 与 Mistral-Large-3 模型，增强工具调用与GPU兼容性Ollama 2025年12月3日发布了 v0.13.1 版本更新，本次更新重点引入了两个新的模型家族，并带来了多项功能增强、错误修复及底层改进，进一步提升了模型的部署灵活性与运行稳定性。一、 全新模型登场1. Ministral-3 系列：此系列模型专为边缘部署设计，能够在广泛的硬件设备上高效运行，为资源受限的环境提供了强大的本地AI能力。2. Mistral-Large-3 系列：这是一个通用的多模态混合专家（MoE）模型，旨在处理生产级任务和企业级工作负载，在复杂场景下表现出色。二、 核心功能与改进1. 引擎与工具调用：• nomic-embed-text 模型现在默认使用 Ollama 自身的引擎运行。• 为 cogito-v2.1 模型新增了工具调用（tool calling）支持。• 同样为 cogito-v2.1 模型添加了思维链（thinking）解析功能。2. GPU 与系统兼容性修复：• 修复了 CUDA VRAM 发现的相关问题。• 解决了在仅配备 CPU 的系统上，模型可能被错误驱逐（evict）的问题。• 修复了在某些旧款 GPU 上无法检测到 CUDA 的问题。• 改进了对 CUDA 计算能力（CC）与目标库版本的兼容性验证。• （Windows系统）增加了对 PATH 中潜在不兼容库文件（如 ggml-base.dll）的检测与警告。3. 错误处理与用户体验：• Ollama 现在能够更好地呈现和渲染错误信息，而非简单地显示 “Unmarshal: errors”。• API 客户端 (api/client) 增强了对非 JSON 格式流式错误响应的处理能力。4. 应用与文档：• 修复了应用内连接打开逻辑，优化了用户体验。• 更新了应用内帮助链接，使其指向官方文档网站。• 清理了文档中已弃用参数（如 mirostat, mirostat_eta, mirostat_tau）的说明。三、 重要代码变更摘要本次更新包含了 18个提交，涉及 33个文件 的更改，由 12位贡献者 共同完成。部分关键变更包括：• API/客户端：增强了错误处理逻辑，当服务器返回非JSON格式的错误响应（如纯文本或HTML）时，能正确传递状态码和错误信息。• 应用层：优化了 macOS 和 Windows 系统上处理自定义 URL 协议（如 ollama://）的逻辑。• 模型支持：• ministral-3：模型支持现已集成，并添加了相应的测试。• deepseek2：升级以支持运行 v3+ 版本的模型。• 模型解析器：新增了针对 cogito-v2.1 模型的专用解析器，以支持其独特的工具调用和思维格式。• mistral3 模型结构：在转换逻辑中增加了对 LLAMA 4 缩放因子等新 rope 参数的支持。• 底层与发现：• GPU 发现：改进了设备发现机制，避免库路径重叠，并加入了对 NVIDIA Jetson Jetpack 版本的更精确匹配要求。• KV 缓存：测试现在同时覆盖使用和不使用 PermutedV 的情况。• LLM 服务器：修正了在仅有 CPU 的系统上进行模型布局验证的逻辑，防止不必要的模型驱逐。四、 其他调整• 将 Vulkan 着色器文件标记为“已供应”文件。• 更新了 .gitattributes 以正确归类相关文件。• 移除了代码检查工具中的 gocritic 规则。总结Ollama v0.13.1 版本是一个以模型扩展和系统稳固性为主的更新。它不仅为用户带来了适用于边缘和企业场景的新模型选择，还通过一系列关键的缺陷修复和兼容性改进，显著提升了软件在各类硬件环境下的可靠性和用户体验。特别是对 cogito 和 ministral 系列模型支持的增强，展现了 Ollama 生态持续扩展对多样化模型架构的兼容能力。

DeepSeek-V3.2系列正式发布：开源模型首次达到GPT-5水平，斩获四项国际竞赛金牌继上周推出数学推理模型 DeepSeekMath-V2 之后，DeepSeek 再度更新，正式发布 V3.2 系列模型。这次一次带来两个版本，分别面向不同应用场景：日常使用与高难度推理。01 双模型定位与核心差异DeepSeek本次发布的V3.2系列包含两个定位分明的模型，以满足不同场景的需求 。DeepSeek-V3.2（标准版） 定位于日常使用场景，注重平衡推理能力与输出效率。该版本已全面部署于DeepSeek官方网页端、App和API服务 。在多项公开推理基准测试中，其表现接近GPT-5，仅略低于Gemini-3.0-Pro 。DeepSeek-V3.2-Speciale（研究版） 则专注于推动开源模型的极限推理能力边界。该模型是V3.2的长思考增强版，结合了DeepSeek-Math-V2的定理证明能力，在高度复杂任务上表现卓越 。02 卓越的性能表现DeepSeek-V3.2-Speciale在多项国际顶级竞赛中展现出惊人实力，成功斩获IMO2025（国际数学奥林匹克）、CMO2025（中国数学奥林匹克）、ICPCWorldFinals2025（国际大学生程序设计竞赛全球总决赛）及IOI2025（国际信息学奥林匹克）金牌 。其中，ICPC与IOI成绩分别达到了人类选手第二名与第十名的水平 。在主流推理基准测试上，Speciale模型的性能表现媲美Gemini-3.0-Pro，展现出强大的推理能力 。不过需要注意的是，该版本因推理链较长、Token消耗高，目前仅限研究使用 。

agno v2.3.4 发布：修复AsyncPostgresDB内存删除问题并新增Gemini 3示例Agent 示例功能概览• creative_studio_agent• 使用 NanoBanana 工具进行 AI 绘图• 增强提示词的光影、艺术风格、色彩等细节• 自动保存生成图片到本地• research_agent• 支持实时网络搜索• 自动添加来源与引用链接• 区分事实与观点，提示信息是否可能过时• product_comparison_agent• 自动分析 URL 中的产品信息• 搜索产品评测并生成对比表格、优劣势分析以及推荐人群