X/Twitter: https://x.com/i/status/2028004643486503013
在处理 100K 甚至 1M 超长上下文时，AI 算力正面临严重的”偏科”挑战：
目前没有任何单一架构能完美兼顾这两者。如何破局？答案指向了软硬协同的终极进化。
既然没有完美的单芯片，那就用架构来弥补。业界正转向一种跨硬件的异构协同模式：
这种”分工协作”架构实现了算力与延迟的最优平衡。
GPU 与 LPU 的结合并非拉一根网线那么简单：
Groq 的编译器将物理网卡视为一个带有已知延迟的虚拟节点：
如果说软件优化是极限微操，那么 TGV (玻璃通孔) 加持的 CoPoS 面板级封装，就是物理层面的降维打击。
| 传统 CoWoS | CoPoS (玻璃基板) |
|---|---|
| 12 英寸圆形硅晶圆 | 500mm+ 矩形玻璃面板 |
| 物理天花板限制 | 可高密度集成多种芯粒 |
| 机柜级异构系统 | 微缩成一块超级基板 |
这意味着：重型计算的 GPU 芯粒、极速生成的 LPU 芯粒，以及海量的 HBM 和 SRAM，可以像拼图一样全部封装在同一个超大模块内部。
大模型推理硬件的尽头，远不止先进制程的无脑堆砌。
依靠：
一个在同一块面板上完美融合极致吞吐与极致延迟的“算力奇点”即将到来。
| 术语 | 解释 |
|---|---|
| PD Disaggregation | Prefill-Decode 分离式架构，让不同芯片各司其职 |
| LPU | Language Processing Unit，Groq 推出的纯 SRAM 架构 AI 芯片 |
| TGV | Through Glass Via，玻璃通孔技术，实现玻璃基板上的高密度互联 |
| CoPoS | Chip-on-Panel-on-Substrate，面板级封装技术 |
| RDMA | Remote Direct Memory Access，远程直接内存访问，零拷贝传输 |
| KV Cache | 大模型推理中的键值缓存，存储注意力机制的中间结果 |
本文整理自 Max Lv 的 X 文章和博客。
]]>Background Agent 是一种在云端基础设施上自主运行的 AI 驱动软件代理——由事件、计划任务或系统信号触发，在无需开发者在键盘前的情况下，跨软件开发生命周期（SDLC）执行开发任务。
软件交付最初是围绕”人类在键盘前”的约束设计的。现在，代理可以在后台跨数千个仓库自主运行。这一趋势已在 Stripe（Minions 平台）和 Ramp 等公司落地。
我们的旧流程已经无法吸收这些变化。现在，每位工程领导者都在问同一个问题：我们如何从今天的交付流程演进为自动驾驶代码库？
自动补全 → 编码代理 → 三个并行运行的编码代理 → 工程师开始寻找变通方案：
任何能运行更多代理的方法。
但 localhost 不是为这种情况设计的。代理争夺机器状态、密钥暴露、机器休眠时一切停止。这对独立开发者有效，但对专业工程来说是不可持续的。
我们必须将工程师与工作站解耦。代理需要在后台安全、大规模地运行。
你推出了编码代理。工程师更快了。PR 如潮水般涌入。
然而，周期时间没有变化。DORA 指标持平。待办事项反而增加了。
因为收益是与个人复合的，而不是与组织。你在编码代理上投入的时间越长，而不解决周围的系统问题，你的根基就越深。
这就是虚假顶峰。
| 特性 | Coding Agent | Background Agent |
|---|---|---|
| 运行位置 | 你的笔记本或本地机器 | 云基础设施，远程触发 |
| 触发方式 | 你手动调用 | 事件、计划任务、Slack 消息、API 调用——任何信号 |
| 范围 | 单个仓库的单个任务 | 跨仓库、团队、整个 SDLC |
| 开发者角色 | 在循环中——观察、引导、迭代 | 在循环上——提示、离开、稍后审查 |
编码代理需要你的机器和你的注意力。后台代理两者都不需要。它在云端的独立开发环境中运行：完整的工具链、测试套件、一切。与你的设备和会话完全解耦。
从笔记本启动一个，用手机查看结果。从 PR、Slack 线程、Linear 工单、webhook 触发，或手动启动。
你不是在操控它。你不是在观察它。这是一个异步任务：委派、离开、稍后审查。它需要运行多久就运行多久。
自主代理需要笔记本上没有的基础设施：
代理需要一台计算机——具有完整工具链、运行测试能力、通过密钥访问系统的环境。环境应该隔离、可重现，与生产系统高度一致。
模式 1：代理拥有开发环境 代理拥有完整的开发环境。运行 dev container 的 VM，包含代码库、测试套件、数据库和内部网络访问。这是最接近人类开发者工作方式的模式。包括 Stripe 和 Ramp 在内的每家分享代理架构的企业都选择了这种模式。
模式 2：Sandbox 作为工具 代理在服务器或本地运行。需要执行代码时，通过 API 调用单独的远程 sandbox。Sandbox 运行代码并返回结果。这保持密钥和执行一定程度的隔离，但代理只能执行代码，无法完全开发。更适合构建代理产品的公司，而非优化自身工程工作流的组织。
代理是系统中的行动者。它们需要与人类贡献者相同的控制：身份、权限、审计跟踪。
区别在于：通过系统提示强制执行的治理（”请不要删除文件”）只是建议。在执行层强制执行的治理——拒绝列表、限定范围的凭证、确定性命令阻止——才是真正的治理。
没有它，安全团队会完全否决自主代理。他们是对的。
无法访问内部系统的 sandbox 只是玩具。代理需要承担 IAM 角色、查询数据库副本、访问内部 API、从私有 registry 拉取——所有这些都在你的网络内部完成。
上下文和连接性将隔离执行转化为真正的工作。
如果每次代理运行都以开发者输入提示开始，你没有自动化工作流——只是自动化了工作。触发器将代理连接到重要事件：计划任务、webhooks、系统信号。
触发模式：
更新一个仓库是编码代理任务。更新 500 个是舰队任务。相同的 sandbox，在需要更改的每个仓库中复制——并行配置、进度跟踪、聚合结果。这就是个人生产力转化为组织吞吐量的地方。
原语给你能力。你在哪里应用它们才重要。这意味着要做工作：调查开发者、与团队坐在一起、绘制时间流向。每个组织的瓶颈都不同。值得首先解决的并不总是显而易见的。
常见瓶颈：
工程组织是一个工业系统。今天，开发者站在每个站点：编写、审查、测试。后台代理改变了运营模式。工厂运行，但你的工程师在循环上而不是在循环中。
工厂车间正在运行。代码正在被编写、审查、测试、部署——持续地、自主地。你的工程师在观察。设置约束。验证结果。
后台代理如何在数百个仓库中自动化 CI 管道迁移——无需人工参与。
从披露到部署修复只需数小时，而非数周。后台代理在您的整个代码库中修补漏洞。
使用后台代理进行遗留现代化——来自企业迁移的真实模式，自主大规模运行。
本地开发的终结：localhost 无法支持大规模代理运行。云基础设施是必须的。
从”在循环中”到”在循环上”：开发者从实时操控转向异步审查和校准。
组织速度 > 个人速度：优化单个开发者效率不等于优化整个组织的交付速度。
治理必须内建：安全不能靠提示工程，必须在执行层强制执行。
触发器实现真正的自动化：没有事件触发，代理只是更快的手动工具。
本文整理自 background-agents.com，由 Ona 团队创建。
]]>本文深入解析 eue + Tape 架构设计理念，揭示其如何通过”磁带”隐喻实现 Agent 的自演进、上下文管理和长期记忆。
当前 AI Agent 面临一个核心困境：上下文窗口有限，但任务复杂度无限。
传统解决方案各有局限：
eue + Tape 架构 提出了一种全新的解决思路——将 Agent 的执行过程视为磁带记录，通过分层 Tape 管理、Handoff 分支机制和 Anchor 锚点系统，实现了执行、记忆、上下文的统一抽象。
Tape（磁带）是这个架构的核心隐喻。在计算机发展史上，磁带是最早的存储介质之一，它具有三个关键特性：
eue + Tape 将 Agent 的执行过程抽象为多条磁带的协作：
| Tape 类型 | 功能 | 生命周期 |
|---|---|---|
| Main Agent Tape | 记录主流程执行轨迹 | 与任务同生命周期 |
| Task Tape | 记录子任务执行细节 | 随子任务创建/销毁 |
| Memory Tape | 存储长期知识和经验 | 跨会话持久化 |
这种设计的优雅之处在于：执行即记录，记录即记忆。
┌─────────────────┐
│ eue │
├─────────────────┤
│ File Tool │ ← 文件操作（读/写/修改）
│ Shell Tool │ ← 系统命令执行
│ Dynamic Skills │ ← 动态可扩展技能
└─────────────────┘
Dynamic Skills 是最关键的设计——Agent 可以在运行过程中学习新技能并注册为可用工具。这是实现”自演进”（Self-Evolving）的基础。
位于架构中心，负责：
“Policy Engine”的命名借鉴了强化学习中的策略网络概念——它不是简单的问答，而是一个根据当前状态输出最优动作的决策器。
Handoff 是一种任务委托和上下文分支机制。当主 Agent 遇到需要独立处理的子任务时：
用户请求："重构这个项目，优化代码结构"
Main Agent Tape:
├── Step 1: 分析当前项目结构
├── Step 2: 制定重构计划
├── Step 3: [Handoff] → Task Tape "Code Update"
│ ├── Sub-Step 1: 修改 utils.py
│ ├── Sub-Step 2: 更新 main.py 的导入
│ ├── Sub-Step 3: 运行测试验证
│ └── [返回结果] → Main Tape
├── Step 4: 验收重构结果
├── Step 5: 回复用户完成
| 优势 | 说明 |
|---|---|
| 关注点分离 | 子任务细节不污染主流程，Main Tape 保持清晰 |
| 错误隔离 | 子任务失败不直接破坏主 Tape 状态 |
| 并行可能 | 不同 Task Tape 理论上可并行执行 |
| 可复用性 | 相同的 Task Tape 模板可重复使用 |
类比理解：类似于 Git 的分支机制，或操作系统的进程 fork。
Anchor 是一种上下文引用和注入机制。当 Agent 需要引用长期知识时：
LLM 的上下文窗口有限（如 128K tokens），但 Agent 的长期记忆可能包含数百万 tokens 的历史经验。Anchor 机制实现了类似操作系统虚拟内存的效果：
当前任务：修改数据库配置
Agent 执行过程：
1. 识别到需要数据库相关知识
2. 从 Memory Tape 中 Anchor 以下信息：
- "该项目使用 PostgreSQL 15"
- "配置文件位于 /config/db.yaml"
- "上次修改配置时遇到的权限问题及解决方案"
3. 将锚定的知识注入当前上下文
4. 基于这些知识执行修改
| 维度 | 传统 Prompt 工程 | RAG 检索 | OpenClaw Memory | eue + Tape |
|---|---|---|---|---|
| 上下文管理 | 一次性塞入 | 向量检索 | 文件化存储 | 分层 Tape |
| 可回溯性 | 差 | 无 | 部分 | 完整 Replay |
| 任务分解 | 手动 | 无 | 依赖外部 | Handoff 自动分支 |
| 长期记忆 | 无 | 依赖外部 | 文件分离 | Memory Tape 统一 |
| 可观测性 | 低 | 中 | 中 | 高（完整 Tape 记录） |
| 自演进能力 | 无 | 无 | 有限 | Dynamic Skills 支持 |
传统架构中，执行和记忆是分离的：
Tape 架构中，执行即记录，记录即记忆：
适合需要多步骤、长时间执行的任务：
Agent 可以从历史任务中学习并改进：
不同 Agent 可以通过 Tape 交接实现协作：
Tape 的只追加特性意味着存储会持续增长。需要设计：
Anchor 机制的效果取决于能否精准定位到相关知识。需要：
何时应该创建 Task Tape？这需要启发式规则：
eue + Tape 架构通过”磁带”这一优雅的隐喻，实现了 AI Agent 执行、记忆、上下文的统一抽象。
其核心创新点：
这种架构的本质是将时间的维度显式化——Agent 不再只是处理”当前状态”，而是在一条可追溯、可回放、可分支的时间线上工作。
正如计算机从批处理进化到交互式系统，AI Agent 也正在从”一次性问答”进化到”持续协作伙伴”。eue + Tape 架构或许代表了这一进化的重要方向。
参考
本文发表于 2026-02-27
]]>本文整理自 Twitter/X 讨论帖，原文作者：盐粒 Yanli (@beautyyuyanli)
「大模型能力的发展会碾压一切大模型应用工程吗？」
这是一个在 AI 圈内越来越被广泛讨论的问题。随着大模型能力的快速演进，许多人开始质疑：那些围绕大模型构建的应用工程（如 RAG、Agent 框架、特定领域优化）是否还有存在的价值？
GPT-4 从 8K 到 128K，Claude 从 100K 到 200K+… 上下文窗口的增长速度令人惊叹。
质疑声音：当模型可以直接处理整本书、整个代码库时，RAG（检索增强生成）还有必要吗？
以 Claude Code 为代表的新一代 coding agent 在过去一年里表现惊艳：
质疑声音：如果模型自己能搞定，我们还需要复杂的 Agent 框架吗？
作者观察到：
这暗示了一种行业共识的潜在转变。
这个问题本质上触及了 AI 发展的一个核心张力：
| 维度 | 模型能力提升 | 应用工程价值 |
|---|---|---|
| 短期 | 解决更多原需工程辅助的问题 | 在模型能力边界处提供支撑 |
| 长期 | 不断扩展能力边界 | 在新的边界处继续构建价值 |
回顾 AI 发展史，类似的讨论曾多次出现：
事实是：工程实践与技术能力一直在动态演化中寻求新的平衡点。
支持者认为：
反对者认为：
折中派认为：
这些问题或许比原问题本身更重要：
无论最终答案如何，这个问题本身就反映了 AI 行业正在经历的深刻变革。对于从业者而言，保持开放心态、持续关注能力边界的变化、并准备好调整自己的技术栈，或许是最务实的应对方式。
正如作者所说，这种观点正在从”外行”的质疑变成”内行”的共识——这本身就是一个值得关注的信号。
你怎么看？
欢迎在评论区分享你的观点。
参考
本文整理自 Twitter/X 公开讨论，仅供学习和思考参考
整理时间：2026-02-27
]]>只需与 Agent 对话，就能持续优化其行为——OpenClaw-RL 让个性化 AI 训练变得像聊天一样简单
想象一下：你正在使用一个 AI Agent 助手，每次对话后它都会记住你的偏好，逐渐学会你的工作方式，甚至能预判你的需求。这不是科幻，而是 OpenClaw-RL 正在实现的愿景。
OpenClaw-RL 是一个完全异步的强化学习框架，它最大的创新在于：将日常对话自动转化为训练信号，持续优化个性化 AI Agent。
现有的 RL 系统通常假设：
OpenClaw-RL 采取了完全不同的方法：
用户对话 → 实时拦截 → PRM 评估 → 自动训练 → 模型更新
↑ ↓
└──────────── 持续循环优化 ←───────────────────┘
关键特性：
OpenClaw-RL 将系统解耦为四个独立的异步循环，彼此之间不阻塞：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Agent 服务 │────→│ Rollout 收集 │────→│ PRM 评估 │────→│ 策略训练 │
│ (模型推理) │ │ (对话轨迹) │ │ (质量判断) │ │ (梯度更新) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
↑ ↓
└──────────────────── 更新后的模型 ←───────────────────────────┘
| 组件 | 功能 | 特点 |
|---|---|---|
| Agent Serving | 提供 OpenAI-compatible API 服务 | 不阻塞训练 |
| Rollout Collection | 收集多轮对话轨迹 | 自动分类主线/支线对话 |
| PRM Judging | 过程奖励模型评估 | 异步多数投票打分 |
| Policy Training | 策略网络训练 | 后台持续优化 |
OpenClaw-RL 提供了两种互补的训练方法：
适用场景：丰富的隐式反馈（如点赞/点踩、环境成功/失败）
工作原理：
示例反馈：
User: 👍 (表示满意)
System: PRM 评估 +1，更新策略
适用场景：丰富的文本反馈，需要方向性改进
工作原理：
示例反馈：
User: "你应该先检查文件再修改"
System: 提取 hint → 增强教师 → token 级蒸馏
OPD 的优势：
# 多轮对话按会话跟踪，保持回合顺序
session_id = "conv_001"
turns = [
{"role": "user", "content": "帮我写个 Python 脚本"},
{"role": "assistant", "content": "..."},
{"role": "user", "content": "👍"}, # 反馈信号
]
每个会话至少贡献一个有效训练样本，确保数据利用率。
# 从 m 个投票中选择最长、最丰富的 hint
def select_best_hint(hints):
return max(hints, key=lambda h: len(h) + information_content(h))
只计算响应后缀的 log-probs，降低峰值内存占用。
选项 A: Binary RL（适合隐式反馈）
cd slime
bash ../openclaw-rl/run_qwen3_4b_openclaw_rl.sh
选项 B: OPD（适合文本反馈）
cd slime
bash ../openclaw-opd/run_qwen3_4b_openclaw_opd.sh
服务启动后，API 端点：http://<HOST_IP>:30000/v1
{
"models": {
"providers": {
"qwen": {
"baseUrl": "http://<HOST_IP>:30000/v1",
"apiKey": "your_api_key",
"api": "openai-completions",
"models": [{
"id": "qwen3-4b",
"name": "Qwen3 4B",
"reasoning": true,
"contextWindow": 32768
}]
}
}
}
}
然后：正常使用 OpenClaw 对话，RL 服务器会自动收集轨迹、计算奖励、训练模型。
用户: "用 Python 写个爬虫"
Agent: 生成代码
用户: "不要用 requests，用 aiohttp" 👎
Agent: 学习偏好，下次主动使用 aiohttp
用户: "这篇总结太正式了，轻松一点" 👎
Agent: 学习用户的文风偏好
后续输出自动匹配用户风格
用户: "下次先检查依赖再建议方案" 📝
Agent: 通过 OPD 学习工作流程
后续主动先分析依赖关系
| 特性 | 传统 Fine-tuning | RAG | Prompt Engineering | OpenClaw-RL |
|---|---|---|---|---|
| 个性化程度 | 高（需大量数据） | 低 | 中 | 高（持续学习） |
| 数据需求 | 需要标注数据集 | 需要知识库 | 无需数据 | 对话即数据 |
| 实时性 | 离线训练 | 实时检索 | 实时 | 实时训练 |
| 隐私性 | 依赖外部服务 | 可自托管 | 依赖外部 | 完全自托管 |
| 使用门槛 | 高 | 中 | 低 | 低（只需对话） |
降低个性化门槛: 不需要 ML 专业知识，普通用户通过对话就能训练专属 Agent
持续进化: 不同于一次性的 fine-tuning，Agent 可以随着使用不断适应
隐私优先: 所有数据和训练都在本地完成，适合敏感场景
范式转变: 从”训练然后部署”到”部署即训练”
传统 RL: 收集数据 → 离线训练 → 部署模型 → 重复
↑___________________________↓
OpenClaw-RL: 部署模型 → 用户对话 → 实时训练 → 即时更新
↑___________________________↓
OpenClaw-RL 代表了一种新的 AI 交互范式：使用即训练，对话即优化。
它让我们看到了一个未来：每个人都有一个专属的 AI Agent，它不是一成不变的，而是在每次交互中不断学习、进化，最终成为真正理解你、适配你的工作方式的智能伙伴。
如果你正在使用 OpenClaw，不妨试试 OpenClaw-RL——让你的 Agent 真正”活”起来。
项目信息
参考论文
关键词: OpenClaw, RL, Agent, Personalization, GRPO, OPD, Self-hosted
本文整理自 OpenClaw-RL 开源项目文档
整理时间：2026-02-27
]]>论文解读：《Test-Time Training with KV Binding Is Secretly Linear Attention》
作者：Junchen Liu, Sven Elflein, Or Litany, Zan Gojcic, Ruilong Li (NVIDIA Research)
论文链接：arXiv:2602.21204
Test-Time Training (TTT) 作为 Transformer 的替代架构，被认为是一种测试时记忆机制——通过在推理时动态优化键值映射来适应输入序列。然而，NVIDIA 最新研究揭示了一个惊人发现：TTT 本质上是一种学习的线性注意力算子。
这一发现不仅解释了 TTT 的多个”反常”行为，还为架构简化和效率提升开辟了全新路径。
传统观点认为，TTT 通过内循环优化”记忆”键值关联：
研究团队发现了四个与”记忆”解释相矛盾的现象：
| 现象 | 预期（记忆解释） | 实际观察 |
|---|---|---|
| 分布不对称 | Query 和 Key 应该分布相似 | 两者分布显著不同 |
| 替换 Query | 用 Key 替换 Query 应该性能暴跌 | 性能几乎不变 |
| 优化 vs 性能 | 更好的内循环拟合 = 更好的下游性能 | 更多优化步骤反而降低性能 |
| 梯度上升异常 | 梯度上升应该完全破坏记忆 | 性能保持不变甚至提升 |
最惊人的是最后一点：即使将内循环的梯度下降改为梯度上升，模型依然表现良好！
论文证明了一个数学等价性：
具有多层级联 MLP 内循环的 TTT，可以等效重写为学习的线性注意力算子。
线性注意力的标准形式：
Output = Query × (State + Σ Keyᵀ × Value)
TTT 的内循环实际上定义了：
内循环不是在学习”记忆”，而是在参数化一个结构化的特征混合器。
从线性注意力视角，所有悖论都有自然解释：
研究发现许多复杂设计实际上是冗余的：
| 组件 | 作用 | 是否必要 |
|---|---|---|
| 多层 MLP 内循环 | 复杂核函数 | 可选（某些任务有益） |
| 权重归一化 | 状态归一化 | 非必需 |
| 每 token 可学习学习率 | 可被吸收进 Value | 冗余 |
| 动量 SGD | 历史梯度混合 | 非必需 |
| 梯度正交化 | 状态更新变换 | 可选 |
最简形式：只更新最后一层参数的 TTT 性能最佳！
传统 TTT 是循环实现（逐个 token 更新）。但在简化形式下，可以重写为完全并行的版本：
不同的 TTT 变体（LaCT、ViTTT 等）都可以归约为统一的线性注意力形式，只是核函数 ϕ(·) 的选择不同。
以代表性 TTT 变体 LaCT 为例：
# SwiGLU MLP 作为内循环
f(x) = silu(x @ W0) ⊙ (x @ W2) @ W1
# 内循环优化（带动量、梯度正交化）
W_i = W_i - η * M(∇W_i L)
# 有效 Query/Key/Value
q̂ = ϕ(q) = silu(q @ W0) ⊙ (q @ W2)
k̂ = ϕ(k)
v̂ = m(k) # 动量加权的目标
# 输出
output = q̂ @ (W0 + Σ k̂ᵀ @ v̂)
这正是线性注意力的标准形式！
NVIDIA 这项研究通过严谨的数学分析和实验验证，颠覆了我们对 TTT 的理解。它揭示了一个深刻道理：有时候，看似复杂的机制背后隐藏着简单的数学结构。
当 TTT 褪去”测试时学习”的神秘外衣，显露出线性注意力的本质时，我们不仅获得了更高效的实现方式，更重要的是获得了统一的认知框架——这往往是科学进步的最美形态。
参考
本文发表于 2026-02-27
]]>