Category: AI

2026 年 9 月，NASA 与 IBM Research 正式发布 NASA-IBM Lunar Foundation Model（NASA-IBM LFM）。这是一个专门面向月球遥感科学设计的多模态、多分辨率人工智能基础模型。模型权重公开托管于 Hugging Face，微调和推理代码则开放在 GitHub，并采用 Apache 2.0 许可证。 它并不是类似 ChatGPT 的语言模型，也不是一个能够模拟整个月球的“数字月球”。更准确地说，它是一套专门学习月球表面遥感数据的视觉基础模型。 从“识别图片”到“理解月球遥感数据” 几十年来，人类已经通过大量探月任务积累了规模庞大的月球观测数据。 其中最重要的数据来源之一，是 NASA 于 2009 年发射的月球勘测轨道飞行器 Lunar Reconnaissance Orbiter，简称 LRO。经过十多年运行，LRO 已经获得覆盖月球大部分表面的高分辨率影像和多种遥感数据。 但数据越来越多之后，一个新的问题逐渐出现： 如何有效分析如此庞大的月球数据？ 如果研究人员希望寻找陨石坑、统计地貌、识别特殊火山结构或者分析极区水冰潜力，传统方法往往需要针对每一个研究任务重新建立算法和训练模型。 NASA 和 IBM 希望改变这种模式。 NASA-IBM Lunar Foundation Model 的思路与近年来人工智能领域的“基础模型”类似：先利用海量数据进行大规模预训练，让模型形成一种对月球表面结构的通用表示能力，然后再针对具体科学问题进行微调。 因此，它并不是一个只会“找陨石坑”的模型，而更像一个可以进一步训练成许多不同月球分析工具的基础平台。 近 200 万组月球数据 …

近年来，AI Agent 的能力正在快速从“会聊天”演变为“能够长期工作”。 它们开始拥有文件系统、Shell、浏览器、代码执行环境、外部 API、远程主机、数据库、记忆、插件、Skill，甚至能够把任务交给其他 Agent。 这带来了一个比“怎么写好 Prompt”更重要的问题： 当一个 AI Agent 真正开始长期运行时，它应该如何组织自己的知识、规则、上下文、记忆和工具？ 如果所有内容最终都堆进一个越来越长的 system prompt，系统很快就会遇到三个问题： 一个更成熟的方向，是把 Agent 看成一个长期运行的软件系统，而不是一段特别长的 Prompt。 本文讨论的正是这种演进过程。 一、研究 System Prompt，真正应该学习什么？ 收集 OpenAI、Anthropic、Google、Microsoft、Meta、xAI、Perplexity、Cursor、OpenCode 等不同 Agent 产品的 system prompt、CLI Agent 规则和工作流后，一个很容易出现的误区是： 把优秀句子复制出来，然后拼进自己的 system prompt。 这种方法短期看起来很强，长期却很容易失控。 因为不同公司的 Agent： 真正值得借鉴的，不是某一句具体措辞，而是多个独立系统反复出现的共同架构思想。 当这些产品横向放在一起比较时，会发现很多设计已经开始趋同。 例如： 这说明成熟 Agent 的核心已经不再是一个巨大 Prompt，而是一套分层知识系统。 二、第一原则：Bootstrap 是宪法，不是数据库 Agent 启动时会注入一部分固定上下文。 这部分内容非常宝贵。 …

前言 在一套长期运行的自建 AI Agent 环境中，OpenClaw 通过 Nextcloud Talk 接收消息，并借助 FRP、反向代理和 Webhook 与外部服务通信。 某次系统维护之后，Nextcloud Talk 中的机器人突然停止回复。与此同时，OpenClaw 此前还经历过一次失败的版本升级，因此最初很容易怀疑：是否升级失败破坏了插件、数据库或 Gateway 状态？ 最终调查表明： Talk 故障与失败升级没有直接关系。真正原因是 Nextcloud 公网域名迁移后，OpenClaw Talk Channel 中的 baseUrl 仍指向旧地址，导致 Webhook Backend 校验失败并返回 HTTP 401。 在修复 Talk 后，又对整个 OpenClaw 安装实例进行了完整的只读审计，清理了迁移残留、失败升级 candidate 和旧 SQLite snapshot cache，并验证 SQLite、插件、Gateway、FRP、Agent 数据库等核心组件均处于正常状态。 这次排查很适合作为一个复杂自托管系统的故障分析案例： 不要看到异常就立即修复，而应先确定故障边界，建立证据链，最后只修改真正错误的部分。 一、系统架构 为避免暴露真实基础设施信息，本文统一使用占位符。 典型架构如下： …

背景 某 AI 代理工具的工作区目录中，反复出现一个状态文件。即使手动删除，过一段时间后文件仍会重新生成。 工作区中同时还能看到另一个隐藏目录下的状态文件。经过人工对比，这两个文件内容完全相同。于是问题变成了： 现象 工作区中存在两个状态文件： 其中顶层的 state 文件删除后会再次出现。隐藏目录中的 state 文件一直存在。 两个文件内容相同，JSON 结构也相同，主要记录工作区初始化状态，例如： 这些字段看起来不像用户数据，也不像配置密钥，而是程序用于判断工作区是否完成初始化的运行状态信息。 排查方式 排查过程中保持只读原则，没有删除、移动、修改文件，也没有重启服务。 主要检查方向包括： 排查结果 结果显示，这两个文件都属于工具正常运行会产生的文件，但地位并不完全相同。 顶层的状态文件是当前版本代码中的 canonical 路径，也就是当前主状态文件。 隐藏目录中的状态文件是 legacy 兼容路径，也就是旧路径或兼容路径。当前代码仍然会读取它，并在需要时把里面的状态迁移回顶层的 canonical 文件。 换句话说，这不是两个互相冲突的状态文件，而是同一份工作区状态在新旧路径之间共存。 为什么删除后还会出现 删除顶层状态文件后，如果隐藏目录中的 legacy 状态文件仍然存在，那么下一次工具启动、工作区初始化、代理会话创建或 heartbeat 触发时，程序会重新读取 legacy 状态。 如果程序发现顶层 canonical 状态文件不存在，就会根据 legacy 状态重新生成顶层文件。 因此，文件并不是“神秘复活”，而是程序的兼容迁移逻辑主动恢复了它。 可以理解为： 是否属于异常 从排查结果看，没有明显异常迹象。 两个文件内容一致，权限正常，字段结构正常，也没有发现异常进程或可疑写入行为。顶层文件比隐藏目录中的文件更新，说明当前程序确实更偏向使用顶层 canonical 文件，而隐藏目录中的文件更像历史兼容残留。 这种情况更像是软件版本迁移期间的兼容设计，而不是数据损坏或异常垃圾文件。 …