🔥 热门话题
1. OpenClaw 超越 React，成为 GitHub 历史上 Star 最多的软件项目
来源: HN #47217812 · star-history.com 时间: 2026-03-03 热度: 252 pts · 298 评论
摘要: OpenClaw 本周超越 React，成为 GitHub 史上 Star 数最多的开源项目。HN 上引发大规模讨论（298 条评论），焦点集中在：Star 是否被 OpenClaw 代理自动打出？项目真实使用率有多高？与 Zapier/Automator 等传统自动化工具的对比。尽管存在争议，这一里程碑标志着 OpenClaw 已达到空前的社区曝光度。
2. "沙盒无法保护你免受 OpenClaw 威胁"——安全批评文章走红
来源: HN #47154803 · tachyon.so 时间: 2026-02-26（文章发布于 2026-02-24） 热度: 112 pts
摘要: 文章指出：即便将 OpenClaw 运行在沙盒中，也无法完全消除其对外部系统的攻击面——代理可通过合法的网络调用、MCP 工具、API 凭证等途径造成危害。作者认为沙盒只是"感觉安全"，而非实质性防护。社区对此反应两极：部分人认为"不要给它邮件写权限"就够了，另一部分人则认为这是对代理系统性安全边界缺失的精准预判。
3. Palo Alto $4 亿扫描器将 91% 已知 OpenClaw 威胁标记为"安全"
来源: HN #47168777 · oathe.ai 时间: 2026-02-26 热度: 6 pts
摘要: 安全研究团队 oathe.ai 审计了 1620 个 OpenClaw Skills，发现 Palo Alto 的商业扫描器（号称行业标杆）对其中 91% 的真实威胁失效。该报告继上周 ClawHavoc 事件后进一步加剧了社区对 Skills 供应链安全的担忧。
🔄 上期遗留问题跟进
4. [已解决🎉] 推理内容泄露到 Discord — Issue #6470
来源: Issue #6470 时间: 2026-02-25（steipete 验证并关闭）
摘要: 困扰多个 Claude 模型版本的推理内容泄露问题（Opus 4.6 adaptive thinking、Kimi K2.5、Gemini 2.5 Fast 均受影响）已被正式关闭。修复包含三层防护：src/discord/monitor/message-handler.process.ts 投递前硬性过滤 isReasoning 载荷；reply-payloads.ts 回复管道级抑制；get-reply-run.ts 注入 enforceFinalTag: true 。steipete 在 main 分支本地验证通过，回归测试覆盖 Discord & dispatch 两条路径。
5. [已解决🎉] Chrome 扩展 relay 认证永久失败 — Issue #25137
来源: Issue #25137 时间: 2026-02-24（steipete 关闭）
摘要: Chrome 扩展 relay 因 HMAC 派生令牌与原始令牌不匹配导致 100% 认证失败。修复方式：服务端 resolveRelayAcceptedTokensForPort 现同时接受派生 relay token 和原始 gateway token，两种方式均可授权。测试文件 extension-relay-auth.test.ts 覆盖兼容性验证。
6. [已解决🎉] config.get 泄露 API 密钥 — Issue #25133
来源: Issue #25133 时间: 2026-02-24（steipete 关闭）
摘要: gateway config.get 调用在 resolved/config 段返回明文 API 密钥的安全漏洞已修复。src/config/redact-snapshot.ts 及 schema.hints.ts 现统一对所有敏感路径（含 env var 支撑的 secret）启用脱敏。涉及会话上下文污染和 LLM 提供商的潜在密钥外泄风险消除。
🚀 新功能 / 合并的 PR
7. fix(slack): 恢复每频道持久 session 路由 — PR #32320
来源: PR #32320 时间: 2026-03-03（合并）
摘要: 修复 Slack 频道 session 路由退化问题——长时间会话中代理丢失频道上下文，导致回复被路由到错误频道或默认 session。PR 描述为恢复持久化的"per-channel session routing"，影响所有使用 Slack 频道的 OpenClaw 实例。
8. fix(discord): Discord 语音消息重采样至 48kHz — PR #32298
来源: PR #32298 时间: 2026-03-03（合并）
摘要: Discord 语音消息（Voice PTT）长期因采样率不匹配导致音质失真或处理失败。本 PR 将音频强制重采样到 Discord 要求的 48kHz，属于 trusted-contributor 提交的稳定性修复。
9. fix(memoryFlush): 防止重复强制 flush — PR #32358
来源: PR #32358 时间: 2026-03-03（合并）
摘要: 修复当 transcript 大小超过 soft threshold 时，memoryFlush 被多次重复触发的问题。此前在 token 接近上限的高负载对话中有概率出现 flush 风暴，导致不必要的摘要重写和 session 状态混乱。
10. fix(discord): gateway 已连接时推送 connected 状态 — PR #32336
来源: PR #32336 时间: 2026-03-03（合并）
摘要: 修复 Discord gateway 在生命周期启动时若已处于连接状态无法推送 connected 状态的问题，影响所有依赖 Discord 状态回调的插件和监控逻辑。
🛠️ 重要进行中 PR
11. hooks: 统一内外 hook 注册表、修复 5 个系统级 Bug — PR #30853
来源: PR #30853 时间: 2026-03-02（开放，审查中）
摘要: 大型重构 PR，将 internal-hooks.ts 和 hook-runner-global.ts 的单例状态迁移到 globalThis[Symbol.for()]，修复 Rolldown 模块分割导致的 hook 丢失、gateway:startup race condition（移除 setTimeout(250)）、sessions.reset 缺失 before_reset hook、以及 after_compaction 的 sessionKey 缺失等 5 个系统级 Bug。Aisle 安全 bot 发现 2 个中危问题（事件循环阻塞、plugin hooks 在进程重启后幸存），多条 review 意见已被作者修复（3 个追加 commit）。最新评论 @mcaxtr 提出 7 处架构建议，PR 尚待 merge。
12. Security: 综合安全审计修复（Discord 系统所有者绕过 / webhook SSRF / 路径遍历）— PR #32345
来源: PR #32345 时间: 2026-03-03（开放）
摘要: 大范围安全修复 PR，覆盖 4 类漏洞：Discord 系统所有者权限绕过、webhook SSRF 防护、路径遍历、内存错误日志泄露。22 个任务清单，目前完成 12 个，17 条评论，活跃审查中。
13. feat(secrets): 全渠道 SecretRef 凭证加密扩展 — PR #29580
来源: PR #29580 时间: 2026-02-26 起活跃
摘要: 跨渠道大型 PR，为 Slack、Discord、Signal、MS Teams、Mattermost、Matrix、IRC、Feishu、Google Chat、Nextcloud Talk、WhatsApp、BlueBoubbles、macOS App、Web UI 等 14 个渠道的用户提供的凭证（API keys、bot tokens 等）添加 SecretRef 支持，实现统一加密存储，避免明文出现在配置文件中。
🐛 活跃 Bug
14. Context Compaction 破坏 thinking blocks → HTTP 400 循环 — Issue #24558
来源: Issue #24558 · 关联 PR #25396 时间: 2026-02-24（仍开放）
摘要: 在 contextPruning 触发后，最后一条助手消息的 thinking/redacted_thinking 块被 stripped，导致 Anthropic API 返回 HTTP 400 invalid_request_error——每约 5 天在高负载 Discord 长会话中循环出现。相关修复 PR #25396 已关闭但主 issue 仍开放，#25598 标注为 "not planned"。临时绕过方案：在 agents.defaults 中设置 "thinking": "off"。
💬 社区讨论
15. [Security] 恶意 Skill 事件（ClawHavoc）+ Windows PATH 检测 Bug
来源: Discussion #7606 时间: 2026-02-03（持续活跃）
摘要: 社区披露恶意 Skill "ClawHavoc" 能通过 Windows PATH 检测漏洞劫持可执行文件路径，实现权限提升。此讨论与上期跟踪的 ClawShell 安全工具、Palo Alto 审计报告等形成本周安全话题集群，显示 Skills 生态安全标准亟待制度化。
❓ 未解答社区问题
16. MS Teams 连接器 EINVAL 错误 — Discussion #12275
来源: Discussion #12275 时间: 2026-02-10（仍无回答）
摘要: 用户在 Windows 上通过 openclaw channels add 安装 MS Teams 插件时一直遇到 spawn EINVAL 错误。唯一社区回应称 macOS 上正常（一个 gateway 实例对应一个 Teams 频道），Windows 平台暂无官方解答或修复。
17. Reddit: Qwen 模型 API rate limit 问题
来源: r/LocalLLaMA 时间: 2026-03-03，12 评论
摘要: 用户以为 Qwen 本地模式可免费无限使用，但 OpenClaw 配置的是 Qwen 云端 API 而非本地推理，触发 API rate limit。引发社区关于本地模型与云端 API 配置区别、以及 OpenClaw 默认模型选择的广泛讨论。
🌍 生态动态
18. FemtoClaw：OpenClaw/PicoClaw 的 ESP32 & Raspberry Pi Pico 超轻量移植
来源: HN #47184082 · GitHub 时间: 2026-02-28，3 pts
摘要: 社区开发者将 OpenClaw 核心协议移植到 ESP32 和 Raspberry Pi Pico 等嵌入式平台，产物名曰 FemtoClaw。这意味着 AI agent 的 webhook/skill 接入能力将延伸至 IoT 硬件层，对无网关方案的边缘场景有潜在价值。
19. Librarian：为 LangGraph / OpenClaw 提供上下文管理，减少 85% token 消耗
来源: HN Show HN · uselibrarian.dev 时间: 2026-03-03（HN Show HN）
摘要: Librarian 是一个开源（MIT）上下文管理库，通过「索引→选择→注水」三阶段替代暴力传入全部历史，在 50 轮基准测试中将 token 消耗从 2000+ 降至 ~800，同时将准确率从 78% 提升至 82%。目前提供 LangGraph 和 OpenClaw 的 drop-in 集成，对 token 成本敏感的部署具有直接价值。
📊 数据概览
| 维度 | 数据 |
|---|---|
| GitHub 活跃 Issues | ~4500 open；本周批量关闭若干旧 bug（包括 Telegram 流式 #31061/#32202、workspace bootstrap #18542 等） |
| GitHub PRs 动态 | 本周合并：#32320、#32298、#32358、#32336 等；开放 ~5115；大型 PR #30853、#32345、#29580 审查中 |
| 上期遗留问题 | 3 项关闭（#6470、#25137、#25133）✅；1 项持续开放（#24558）；1 项 Discussion 仍无答案（#12275） |
| HN 最热讨论 | "OpenClaw surpasses React" (252 pts, 298 评论) |
| 本周核心主题 | GitHub 里程碑 · Reasoning 泄露修复 · Hook 系统重构 · 安全审计集中爆发 |
🔬 深度分析
深度 A：沙盒无法保护你免受 OpenClaw 威胁
🌈
来源文章：Sandboxes won't save you from OpenClaw · 作者：Aakash Japi（Tachyon 安全）· 发布：2026-02-24 · HN 讨论：#47154803（112 pts）
📋 背景与问题描述
2026 年头两个月，OpenClaw 已造成一系列真实安全事故：Meta 对齐负责人 Summer Yue 的收件箱被清空、一个 Solana AI Agent（使用 OpenClaw 协议）将 45 万美元加密货币转给陌生人、多起恶意软件安装事件、一名 OSS 维护者被勒索。
主流"防御"建议集中在沙盒（Seatbelt、bubblewrap、Docker、VM）。Tachyon 安全研究员 Aakash Japi 发表文章，系统性地指出这种思路的根本局限：沙盒保护的是本地文件系统和网络隔离，但 OpenClaw 最危险的操作恰恰来自它被明确授予的第三方账户访问权——邮件、银行、日历、API 凭证。这些访问是用户主动配置的合法权限，沙盒无从拦截。
🛠 方案与技术细节
现有方案的致命缺陷：OAuth 权限粒度太粗
- Gmail 的 OAuth scope "send emails" 是全有或全无——无法限制只给某几个联系人发
- 信用卡 API 无法事先设置"单笔额度上限 + 指定商家"的一次性卡号
- 结果：给 OpenClaw 必要权限的瞬间，就给了它造成全部危害的能力
提出的解决方向："代理权限（Agentic Permissions）"模型
| 服务 | 当前 OAuth | 提议的代理权限 |
|---|---|---|
| Gmail | "发送邮件"（所有人） | 预审批联系人白名单；陌生联系人进审批队列 |
| 信用卡 | 给明文卡号 | 每笔交易生成一次性卡号，含金额 + 商家限制，卡号不暴露给代理 |
| 文件系统 | 读/写（全局） | 按目录的 capability，只读 vs 读写分开授权 |
作者将这一缺失的基础设施定义为"下一个 Plaid"——一个跨服务、标准化的代理授权中间层。预计金融领域会率先落地（资金风险最高、合规压力最大）。
⚙️ 操作过程（HN 社区实践汇总）
HN 讨论中涌现了大量来自一线实践者的解法：
-
@buremba（构建 OpenClaw 多租户沙盒）的 4 条操作建议：
- 只让代理起草邮件，输出分享链接，人工触发发送
- 使用增量快照 +
/revert，代理搞乱配置时一键回退（Kubernetes VolumeSnapshot） - 不让代理看到任何 secret——在 proxy 层用占位符替换，人工审批后置换
- 对出站网络做严格白名单域名，超出白名单的域名设置时间窗口限制
-
@tonymet 的三种授权架构：
- Scoped roles（最常见，但粒度有限）
- PAM/Entitlements（B2B 场景，含审批额度 + 供应商白名单）
- 事务审批（Transaction Approval） ：所有写操作进队列待审，人工触发后执行——本质上是在代理操作上加 shadow/copy-on-write，类似 undo log 的思路
-
@dinklerberg 的最佳实践：OpenClaw 运行在独立服务器，第二台服务器提供 Gitea 等服务，仅通过 Tailnet 互联；需要外部服务时为 OpenClaw 创建独立的受限账户，绝不共享个人账户
💡 核心观点与结论
结论 1：沙盒是最低卫生标准，不是安全解决方案。Seatbelt / bubblewrap / landlock 防的是 rm -rf /，防不了合法 API 调用造成的危害。"我们绝对不需要又一个 agent 沙盒产品。"
结论 2：真正的威胁面是已授权的账户访问。要 OpenClaw 有用，就必须给它账户权限；这和让它"能造成危害"是同一件事。这不是 bug，这是信任模型本身的设计问题。
结论 3：当前 LLM 在上下文窗口扩大后会"忘记"指令（"不要自动提交"写了三遍也没用），因此人工审批节点不能依赖 prompt，必须是确定性的技术约束。
结论 4："The next Plaid" 是一个真实的市场机会——率先为代理提供细粒度权限 API 的服务商，将占据代理生态的关键基础设施位置。
👥 影响人群与范围
| 人群 | 影响 |
|---|---|
| 个人用户 | 向 OpenClaw 授予邮件/财务/日历权限的所有人 |
| Skills 开发者 | 设计 Skill 时需遵循最小权限原则；恶意 Skill 可利用过度权限 |
| SaaS 服务商 | 需要提供细粒度的代理权限 API（否则代理只能拿全部权限） |
| OpenClaw 官方 | PR #32345 在本周开放，覆盖 4 类权限相关漏洞，是体系性应对的开始 |
| 安全工具开发者 | 纯沙盒方向价值下降；host 监控（clawmoat）+ 权限中间层是更有前景的方向 |
📈 当前状态
- 文章发布：2026-02-24；HN 提交：2026-02-26；112 pts，社区热度持续
- OpenClaw PR #32345（综合安全审计修复，4 类漏洞）于 2026-03-03 开放，22 项任务已完成 12 项
- PR #29580（全渠道 SecretRef 加密）是朝"不让代理看到明文 secret"方向的工程实践
- 官方尚无"细粒度代理权限"路线图，由第三方工具（clawmoat、grith.ai）在填补
🔗 资源链接
- 原文：tachyon.so/blog/sandbo…
- HN 讨论（112 pts）：news.ycombinator.com/item?id=471…
- clawmoat（host 层防护工具）：github.com/darfaz/claw…
- grith.ai（多过滤层本地代理）：grith.ai
- PR #32345（安全审计修复）：github.com/openclaw/op…
- PR #29580（SecretRef 加密）：github.com/openclaw/op…
深度 B：Librarian — 为 LangGraph / OpenClaw 提供智能上下文管理
🌈
来源：uselibrarian.dev · HN Show HN #47217812 · 开发者：Pinkert7 · 许可证：MIT
📋 背景与问题描述
OpenClaw 长会话（50+ 轮）面临两个对立的压力：
- 暴力方案：把全部历史传给 LLM——token 成本随轮次线性增长，在 100K tokens 时慢到不可用
- 截断/滚动窗口：丢弃早期上下文——关键状态丢失，导致代理"失忆"
Issue #24558 正是这个矛盾的具体体现：contextPruning 触发时，thinking blocks 被截断，导致 Anthropic API 返回 HTTP 400 循环无法自恢复。现有 compaction 策略是破坏性的——它不知道什么值得保留。
Librarian 的出发点：用结构化摘要索引 + 推理驱动选择替代暴力截断，实现"压缩但不失真"。
🛠 方案与技术细节
三阶段架构
历史消息（原始，2000+ tokens）
↓
[Index] 每条消息后，轻量模型异步生成 ~100 token 摘要
↓
[Select] 新消息到来时，模型读取摘要索引，推理相关性
（理解"步骤 3 依赖步骤 1 的输出"这类时序逻辑）
↓
[Hydrate] 仅拉取被选中的原始消息
→ ~800 tokens 精选上下文
为什么优于向量搜索
向量相似度擅长"语义相关"，但无法理解时序依赖（"先做 A，A 的输出传给 B，B 失败了，要回看 A"）。摘要索引 + 推理模型可以捕获这类逻辑链。
性能基准（50 轮对话测试）
| 指标 | 暴力方案 | Librarian | 变化 |
|---|---|---|---|
| Token 消耗 | 2000+ tokens | ~800 tokens | -85% |
| 准确率 | 78% | 82% | +4pp |
| 速度（100K tokens） | baseline | 3-4x 更快 | +200-300% |
准确率不降反升的原因：暴力传入全部历史会引入噪音，智能选择反而让模型更专注。
集成方式
pip install librarian-context
from librarian import Librarian
librarian = Librarian(model="gpt-4o-mini") # 轻量索引器
# Drop-in 替换 MemorySaver（LangGraph）或 session handler（OpenClaw）
⚙️ 操作过程（与 OpenClaw 的关联）
Librarian 与 OpenClaw 的 contextPruning/compaction 机制形成互补而非替代关系：
- 当前 OpenClaw 策略（截断型） ：超限后强制截断早期消息，不判断重要性，副作用是破坏 thinking block 完整性（Issue #24558 中的 HTTP 400 根本原因）
- Librarian 策略（摘要索引型） ：在消息写入时就建立摘要索引，检索时按相关性精选，不破坏消息的结构完整性
实践建议：将 Librarian 接入 OpenClaw 的 session handler，在 contextPruning 触发前就缩减上下文体积，从根本上减少 compaction 发生的频率，间接降低 #24558 类错误的概率。
💡 核心观点与结论
结论 1：token 成本是规模化部署的主要瓶颈。-85% 的削减对运行数百实例的 OpenClaw 部署意味着直接的财务影响。
结论 2： "智能选择优于暴力传入"已有基准数据支撑。82% vs 78% 的准确率提升（+4pp）说明更少的上下文不一定更差，噪音消除有帮助。
结论 3：索引开销可控。轻量模型（如 gpt-4o-mini）异步生成 100-token 摘要，不阻塞主流程。即将推出的专用 fine-tuned 端点将上下文构建时间压缩到 1.3 秒，token 成本再降 84%。
结论 4：向量搜索不适合 agent 上下文管理。agent 执行流程有因果依赖链，必须用能理解逻辑顺序的模型来做选择。
👥 影响人群与范围
| 人群 | 影响 |
|---|---|
| OpenClaw 重度用户 | 50+ 轮长会话场景，直接受益于 token 削减 + 速度提升 |
| LangGraph 用户 | Drop-in 集成，无需改架构 |
| OpenClaw 核心维护者 | 可参考 Librarian 的摘要索引方法改善官方 contextPruning 策略，从根源上解决 #24558 |
| 企业部署团队 | token 成本下降 85% 的规模效应在高吞吐部署中显著 |
📈 当前状态
-
HN Show HN 提交：2026-03-03
-
GitHub 仓库：
- 集成：Pinkert7/langgraph-librarian
- OpenClaw Fork：Pinkert7/openclaw
- 基准测试：Pinkert7/librarian-benchmark
-
即将推出：Fine-tuned Librarian 端点（1.3s 上下文构建，比通用模型快 84%）——时间线未公布
-
社区：GitHub Discussions + Discord 服务器活跃
数据截至： 2026-03-03
