Roger-Lv's space

OpenClaw解析 https://zhuanlan.zhihu.com/p/2000850539936765122 记忆系统尤其关注下 https://zhuanlan.zhihu.com/p/1999989672403812713

OpenClaw记忆系统深度解析：构建AI代理的长期记忆能力 摘要 OpenClaw作为一个多通道AI代理平台，其核心能力之一就是为AI代理提供长期记忆功能。本文深入分析OpenClaw记忆系统的架构设计、实现原理和技术细节，涵盖从本地向量存储到外部记忆系统集成的完整技术栈。 1. 记忆系统架构概览 OpenClaw的记忆系统采用分层架构设计，主要包含以下核心组件： 1.1 核心架构图 graph TB A[记忆系统] --> B[MemoryIndexManager] B --> C[嵌入向量层] B --> D[存储引擎层] B --> E[搜索算法层] C --> C1[OpenAI嵌入] C --> C2[Gemini嵌入] C --> C3[本地模型] D --> D1[SQLite向量存储] D --> D2[FTS5全文检索] D --> D3[文件系统索引] E --> E1[混合搜索算法] E --> E2[相关性排序] E --...

AI Infra相关 K8S 异构容错 会有一些挑战： 大规模分布式训练任务为了适应国产芯片需要更大规模 原因在于国产卡的算力比不上N卡，自然需要更大规模 大模型分布式训练任务频繁中断 目前几乎所有的大模型训练方式都是同步训练（DDP/MPI），训练的进程共同使用一个通信拓扑，当某一个进程发生错误时，其他进程也会相继退出 异构芯片及服务器集群的故障率与集群规模成正比，且随着集群规模的扩大训练任务的中断次数成倍增加 BLOOM 176B的训练， 在大约400个GPU的新集群上，平均每周都会遇到1-2个GPU故障。 字节的大规模训练也呈现相应的特征。[from MegaScale] 大模型分布式训练任务出错原因难排查 net ib? socket timeout gpu ecc error 这些问题靠重新调度是无法解决的，需要准确定位到节点出错的位置，这需要花费数小时甚至数天的时间（可观测性建设） ![image-20260120112002896](/Users/lvzhongrenjie/Library/Application Support/typora-...

告别 Device Plugin: Kubernetes 下一代异构资源管理利器 —— DRA 在 AI 和 GPU 计算盛行的今天，如何高效地在 Kubernetes 中调度显卡、FPGA 等硬件资源，一直是开发者关注的焦点。过去，我们依赖 Device Plugin 框架，但随着业务复杂化，其局限性（如无法动态共享、缺乏复杂的调度参数）日益凸显。 为了解决这些痛点，Kubernetes 推出了 Dynamic Resource Allocation (DRA)。该特性在 v1.34 版本中已正式进入 GA（General Availability） 阶段，标志着 K8s 进入了异构资源管理的 2.0 时代。 一、 为什么需要 DRA？（痛点分析） 在 DRA 出现之前，Device Plugin 是管理硬件的主力，但它有三个致命伤： 静态分配：资源请求只能是整数（如 nvidia.com/gpu: 1），难以实现 GPU 分片或复杂的组合请求。 网络与存储隔离：硬件驱动无法深度参与调度决策，导致调度器可能把 Pod 调度到一个虽然有 GPU 但网络带宽不足的节点上。 API...

万亿参数大模型训练的网络架构革新：Rail-only 旋转星云式拓扑深度解读 随着生成式人工智能（GenAI）的爆发，大型语言模型（LLM）的参数规模已从百亿量级迅速跨越至万亿量级 1。2020 年发布的 GPT-3 模型需要 NVIDIA V100 GPU 运行 355 个 GPU 年才能完成训练，而当前的 GPT-4 等模型估计拥有超过一万亿个参数，训练周期长达数月 1。在摩尔定律放缓的背景下，单枚加速器的算力增长速度已无法跟上模型规模及计算需求的指数级飙升，这使得超大规模 GPU 集群的部署成为必然趋势。行业领先的机器学习架构师预测，下一代 LLM 训练可能需要超过 30,000 个 GPU 的计算能力才能在合理时间内完成 1。然而，如何高效、低成本地连接这些数以万计的 GPU，已成为制约人工智能发展的关键基础设施瓶颈。 算力中心的基石：GPU 互连域的划分 在理解 Rail-only 架构之前，必须深入剖析当前超大规模 GPU 数据中心的设计范式。现代 GPU 集群通常被划分为两个截然不同的通信域：高带宽域（High-Bandwidth Domain, HBD）和网络接口...

MOE混合专家模型总结 https://zhuanlan.zhihu.com/p/721410980

Tongyi DeepResearch技术报告解读及源码分析 https://github.com/Alibaba-NLP/DeepResearch https://zhuanlan.zhihu.com/p/1966914265899329009

OpenSkills深度解析：如何让Claude Code获得超能力 引言：AI编程助手的新纪元 在AI编程助手日益普及的今天，Claude Code作为Anthropic推出的专业编程助手，其技能系统（Skills System）为用户提供了强大的扩展能力。然而，原生的技能系统存在一些限制：只能从官方市场安装、无法使用私有技能、难以跨项目共享等。 OpenSkills项目应运而生，它完美复刻了Claude Code的技能系统，同时提供了更大的灵活性和控制权。本文将深入解析OpenSkills的技术架构，并详细说明如何让Claude Code使用这个项目作为技能。 一、OpenSkills项目核心价值 1.1 什么是OpenSkills？ OpenSkills是一个开源命令行工具，实现了与Claude Code 100%兼容的技能系统。它允许用户： ✅ 从任何GitHub仓库安装技能（不仅仅是官方市场） ✅ 安装本地路径或私有Git仓库的技能 ✅ 跨多个AI代理共享技能 ✅ 在项目中版本控制技能 ✅ 通过符号链接进行本地技能开发 1.2 技术架构概览 graph TB ...

Context as a Tool: Context Management for Long-Horizon SWE-Agents 在软件工程（SWE）领域，大型语言模型（LLM）驱动的自主代理正逐渐从简单的代码生成器演变为能够处理复杂、长程任务的系统性实体。然而，随着任务复杂度的提升，代理在与大规模代码库进行长达数百轮的交互时，面临着严峻的上下文管理挑战。传统的“追加式”上下文维护策略往往导致上下文爆炸、语义偏移以及推理崩溃 1。近期由 Liu 等人提出的 CAT（Context as a Tool）框架，通过将上下文维护提升为一种可调用、可规划的工具能力，为长程代理的稳定性与可扩展性提供了新的范式 1。本报告旨在深入探讨 CAT 框架的技术架构、数据生成管线、实验表现及其在 2025 年智能代理生态系统中的战略地位。 长程交互中上下文失效的根源分析 在软件工程任务中，如修复 GitHub 存储库级别的 issue，代理通常需要执行数十次甚至数百次的环境交互，包括文件读取、搜索、代码编辑和测试运行 1。大多数现有的代理架构，如 ReAct 框架，采用的是一种被动且线性的上下文增...

MEMORY-T1: REINFORCEMENT LEARNING FOR TEMPORAL REASONING IN MULTI-SESSION AGENTS 这里其实就是对自己跨对话的的上下文（即对话历史）做智能过滤和选择。 从历史中 选出最相关的部分，丢弃无关内容。 主要应对 时间错乱、证据不精准 的问题。 输入：全部对话历史（很长很乱） 处理：先按时间过滤，再按内容过滤，最后用强化学习选出最佳证据子集 输出：只把精选后的上下文片段喂给模型生成答案 在当代人工智能的研究范式中，大型语言模型（LLM）已逐步从单纯的文本生成工具演化为具备长期记忆与复杂规划能力的自主智能体。然而，当这些智能体被部署于现实世界中需要跨越数周、数月甚至数年的多会话（Multi-session）交互场景时，一个核心的技术瓶颈凸显出来：如何精准地理解和推理对话历史中的时间维度信息 1。现有的长文本模型虽然在处理数十万字的技术文档时表现优异，但在处理充满噪音、非结构化且具有复杂时间依赖性的多会话对话时，往往会表现出显著的性能衰退，无法准确识别时间相关的关键证据，导致回答出现逻辑冲突或事实性错误 1...