一键闪烁：通过浏览器刷新您的ESP32。无需工具链，无需终端，无需ESP-IDF。只需点击即可运行。 完整代理循环：OpenClaw推理引擎：递归工具调用、上下文压缩、双循环架构。C原生SSE流，实现实时token传输。 硬件控制：直接控制LED、显示屏、传感器。LVGL触摸屏UI。GPIO、CAN、I2C——代理控制板子。 多渠道聊天：通过Telegram、Scripto Studio或任何未来渠道进行对话。您的代理始终在线。 持久内存：混合TF-IDF + 向量搜索。跨重启记忆。支持SD卡备份。您的代理了解您。 ScriptOs技能：从ScriptoHub安装和运行技能。嵌入式AI市场。代理也可以自行编写技能。
每日HackerNews RSS
## pycoClaw：基于ESP32的自主代理
pycoClaw 能够在低成本的 MicroPython 硬件（如 ESP32）上运行“OpenClaw级别”的自主代理，这些代理由 LLM 驱动。开发者构建此工具是为了克服现有工具在将 AI 直接部署到裸机设备方面的局限性。
该系统包含三个关键组件：一个 26k 行代码的代理（PFC Agent），它使用 LLM 为本地执行自编程 MicroPython 脚本；ScriptoStudio – 一个带有调试器的 PWA IDE，用于快速迭代；以及 ScriptoHub，一个精选的可重用“技能”仓库，并具有自动恶意软件检查。定制的 WebSocket 协议确保了与 IDE 的快速可靠通信。
该项目利用约 18k 行代码的自定义 C 扩展来优化 MicroPython 的性能。应用场景包括：能够适应未知硬件（如电动车电机）的自编程机器人，存储用户数据于本地的个性化、注重隐私的数字助手，甚至简单的交互式设备。其核心思想是创建一个“LLM 硬件控制平台”，允许 LLM 实时控制和调整设备行为，并通过暴露为 Python 的基于 C 的快速路径来实现速度。
针对`.env`和`.git`等敏感文件的自动化扫描是常见的服务器安全问题。一种诱人的反制措施——提供大量垃圾数据填充的这些文件以浪费攻击者的资源——在法律上存在问题。美国、德国和奥地利的法律普遍禁止故意干扰*任何*计算机系统，即使是正在攻击你的系统；“他们先动手的”辩护不适用。这类似于设置陷阱，可能面临刑事处罚。 虽然“拖延战术”（严重降低连接速度）在法律上是一种更安全的选择，但它对复杂的分布式扫描越来越无效。更强大的防御需要分层方法：速率限制、地理封锁、WAF和威胁情报。 一个关键问题是法律框架的不对称性。合法的网络爬虫不会扫描`.env`文件，但当前的法律没有区分，阻碍了主动防御。探索一种细化的法律标准，允许对*特定恶意*扫描做出相称的回应，可以将优势恢复给防御者，但这仍然是一个未解决的挑战。
## 是否应该允许“反击”？ - Hacker News 讨论摘要
Hacker News 的讨论围绕“反击”的合法性和伦理问题——主动对攻击者进行报复。 担忧集中在错误识别攻击者，以及通过受损代理可能伤害无辜方。 一个关键点是，有效反击通常需要利用漏洞，从而激励行为者*维持*弱点用于攻击目的，最终增加全球不安全因素。
一些人认为应该允许对容纳大量欺诈的国家进行“数字私掠”，认为经济压力可以起到威慑作用。 然而，另一些人指出，这些司法管辖区通常会忽视问题或默许，并且更倾向于政权更迭或金融起诉等替代方法。
辩论还涉及定义合法的安全测试与恶意活动之间的困难，以及自动化系统过度反应导致附带损害的可能性。 一个反复出现的主题是参与此类活动所涉及的风险——包括法律风险和人身风险，尤其是在面对资源充足的对手（如外国情报机构或犯罪企业）时。 最终，讨论强调了将攻击性网络能力合法化的复杂挑战和潜在的意外后果。
## LLM 忽略“禁止”指令 - Hacker News 讨论摘要
最近一篇 Hacker News 帖子强调了大型语言模型 (LLM) 的一个问题：它们倾向于忽略否定指令。一位用户要求 LLM 不要实现代码更改，但 LLM 仍然继续执行，引发了关于 LLM 设计根本缺陷的讨论。
许多评论员指出，LLM 被“调优”为*采取行动*，并且难以处理否定。一些人认为这个问题源于 Transformer 架构本身，而另一些人则认为当前模型已经“修复”了这个问题，但仍存在疑问。人们对安全隐患表示担忧，并将这种情况与涉及武器系统，甚至科幻小说中机器人无视直接命令的经典情节相提并论。
普遍的共识是，LLM 不可靠，需要持续的人工监督。用户强调了验证 LLM 输出的重要性，并建议提供清晰的肯定指令，而不是依赖“禁止”命令。 许多评论员分享了类似的经验，即 LLM 无视明确的否定请求，这进一步强化了在将它们集成到工作流程中时需要谨慎。
RAG 系统中的文档污染：攻击者如何破坏人工智能的信息来源
Document poisoning in RAG systems: How attackers corrupt AI's sources
19 天前
## RAG系统漏洞：知识库投毒 最近的实验表明，检索增强生成 (RAG) 系统存在一个显著的安全漏洞：**知识库投毒**。仅使用本地设置（MacBook Pro，无GPU/云），就向 ChromaDB 知识库注入了 *三* 份伪造的文件，成功地误导了 LLM (LM Studio + Qwen2.5)，使其报告了某公司的虚假财务数据。 攻击成功报告了 47% 的收入下降和重组计划，尽管实际数据表明该公司盈利。这并非软件漏洞或提示注入——仅仅是添加了具有误导性的信息。成功的关键在于制作既能在检索中获得高排名*又*能影响 LLM 生成的文档，这一概念被“PoisonedRAG”研究正式化。 虽然使用小型数据集可以轻松复现，但该原理可以扩展到更大的知识库。**在摄取时进行嵌入异常检测被证明是最有效的防御手段**，显著降低了成功率。其他防御措施，如清理和提示加固，提供的保护有限。 这种攻击危险在于其持久性、隐蔽性和低准入门槛。组织应映射所有写入知识库的路径，实施摄取时异常检测，并利用快照进行快速恢复。此漏洞强调了保护 *知识库本身* 的必要性，而不仅仅是 LLM。 **实验室代码及进一步研究：** [https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security](https://github.com/aminrj-labs/mcp-attack-labs/labs/04-rag-security)
## RAG系统漏洞：文档投毒
最近的讨论强调了检索增强生成 (RAG) 系统中的一个关键漏洞：**文档投毒**，恶意行为者破坏人工智能依赖的来源。虽然通常被描述为有针对性的“攻击”，但更常见的风险是**有机知识库退化**——随着时间的推移，过时或矛盾的信息不断积累。
核心问题在于，RAG 系统将所有检索到的上下文都视为同等权威，无论来源的可靠性或时间。讨论的解决方案包括**基于熵的衰减**（降低较旧/矛盾文档的权重）以及在提示中呈现**元数据溯源**（摄取时间戳、来源权威），以便模型能够推理可信度。
然而，仅仅提高模型的鲁棒性是不够的。一个关键的结论是将检索到的内容视为**不受信任的输入**，并在架构上将其与系统指令分离。 这包括防止外部来源的文档产生过大的影响，并专注于在*检索之前*检测异常模式，例如协同注入。最终，强大的 RAG 系统需要对数据流有深刻的理解、细致的来源跟踪以及纵深防御方法，类似于 SQL 注入预防等安全最佳实践。
## TPU 与 GPU：深入探讨 Flash Attention
本文详细介绍了将为 GPU 开发的 Flash Attention 内核（在第 4 部分中）移植到 TPU 的尝试，揭示了令人惊讶的性能差异。虽然算法保持不变，但底层的硬件和编译器优化却极大地改变了结果。
最初移植到 JAX/TPU 的版本比融合的标准注意力实现要慢得多。这被追溯到 TPU 的架构：其矩阵乘法单元 (MXU) 专为平铺矩阵运算而设计，并且其大型片上存储器 (VMEM) 允许完整的注意力矩阵驻留在其中，用于较短的序列长度。最初的 JAX 实现，使用 `fori_loop`，阻碍了编译器优化并行性的能力。
切换到 `jax.vmap` – 信号查询块之间的独立性 – 释放了显著的性能提升，最终超越了融合的标准注意力，用于更长的序列。这突出了向编译器传达意图的重要性。关键要点是：TPU 硬件和 XLA 编译器通常会自动处理平铺和优化，使得手动干预变得不必要甚至有害。
进一步的研究表明，TPU 的收缩阵列设计本质上可以有效地执行平铺矩阵乘法。虽然通过 Pallas 进行自定义内核提供了细粒度的控制（DMA 流水线，显式内存放置），但对于许多用例，利用 XLA 的自动优化可以提供最佳性能。该项目强调，在 GPU 上有效的优化策略不一定对 TPU 有益，并且理解底层硬件对于编写高效代码至关重要。
## 黑客新闻讨论：TPU上的Flash Attention & AI辅助写作
最近黑客新闻上出现了一场讨论，围绕一篇详细介绍了在TPU（张量处理单元）上优化Flash Attention的挑战的博客文章展开。虽然这项技术工作本身很有价值——专注于索引、分区和加速器性能的基准测试——但对话的很大一部分集中在文章的*写作*上。
许多评论者表达了对写作风格的沮丧，认为这是使用了AI（特别是Claude）造成的。担忧包括句子过于冗长、措辞生硬（“Claude式”表达）、以及Markdown格式不一致。一些人认为，如果作者懒得清晰写作，读者就不应该费心阅读。另一些人则认为使用AI来总结工作是有益的，可以解放工程师专注于构建。
一个关键点是内容创作周围的社会契约正在发生变化：随着AI使写作变得更容易，阅读现在需要更多的努力，作者有责任以深思熟虑的原创文笔来尊重他们的读者。 许多评论员指出，虽然底层信息很有用，但AI生成的风格降低了阅读体验，并使理解技术细节更加困难。
莉比·科普和她的男友雅各布·阿诺德，在TikTok和Instagram上发布了一段他们跑步时制作黄油的视频，迅速走红。这对来自俄勒冈州的夫妇将浓奶油和盐装入密封袋，固定在他们的跑步背心上，然后开始在小路上跑步，利用运动将奶油搅打成黄油。
这个想法源于科普对乳制品的热爱，以及阿诺德发现奶油在摇晃时很容易起泡。在确认了科学原理——剧烈搅拌可以分离脂肪分子形成黄油后，他们开始实验，最初使用了过多的奶油，甚至试图在河里冷却密封袋。他们后来改进了技术，发现50-55°F（约10-13°C）的温度最理想。
他们的视频获得了数百万次观看，并激励了其他人尝试“搅打跑步”，出现了各种变化，包括调味黄油，甚至在旅途中制作冰淇淋。科普强调，除了新奇之外，这次经历让她回忆起跑步的简单乐趣，她说：“只是为了氛围。只是为了黄油。”
## 跑步与制黄油：一种古怪的趋势
一位跑者分享了他们不同寻常的爱好：在跑步*的同时*制作黄油，灵感来自斯堪的纳维亚烹饪节目。这个过程包括将奶油密封在袋子里，利用跑步的运动搅动奶油使其变成黄油——大约需要25分钟。
评论者们热情地分享了他们自己的制黄油经验，指出自制黄油由于水分含量较低和风味更浓郁，味道比商店购买的黄油更好。许多人还详细描述了通过用酪乳制作意大利乳清干酪，甚至用乳清制作类似软糖的奶酪来延长这个过程。虽然清理工作很麻烦，但成本可能低于购买黄油，尤其是在添加其他产品的情况下。
讨论还涉及黄油的保存（冷冻或加盐）、温度影响搅打的原理，以及黄油可能通过类似意外搅动方式发明的历史可能性。这一趋势引发了与“跑步时做其他事情”活动（如制作冰淇淋）的比较，以及关于其实用性的幽默辩论。
错误：无法满足请求。请求被阻止。我们目前无法连接到此应用程序或网站的服务器。可能流量过多或配置错误。稍后重试，或联系应用程序或网站所有者。如果您通过 CloudFront 向客户提供内容，可以在 CloudFront 文档中找到故障排除步骤，以帮助防止此错误。由 cloudfront (CloudFront) 生成。请求 ID：yz2YhgkpmFKDVypzqjGb2Vtk7LbD4ZXN94Na284hGDrn5s25iJ1bkQ==
谷歌计划在2026年第二季度将Chrome浏览器带到ARM64 Linux设备上，此前已成功在macOS（2020年）和Windows（2024年）ARM平台上发布。此举旨在满足对功能齐全的浏览体验日益增长的需求，该体验将谷歌的服务与开源Chromium项目集成。 ARM64 Linux版本将提供与其他Chrome版本相同的安全性、稳定性以及丰富的功能，包括通过Google账户无缝同步、访问Chrome网上应用店扩展程序以及即时网页翻译。增强的安全功能，如带有AI保护的安全浏览、Google Pay集成以及Google密码管理器也包含在内。 谷歌正在与NVIDIA合作，简化DGX Spark用户的安装流程，其他用户可以直接从chrome.com/download下载。此发布标志着谷歌对Linux社区和不断扩展的Arm生态系统的承诺。
## Chrome 登陆 ARM64 Linux
谷歌官方宣布 Chrome 将登陆 ARM64 Linux 设备，预计于 2026 年第二季度发布。虽然 Chromium 已在 ARM64 Linux 上可用一段时间，但官方 Chrome 版本一直缺失，这让用户感到沮丧，尤其是那些使用基于 ARM 的工作站，例如 NVIDIA Spark 的用户。
此举弥补了长期存在的差距，因为 Chrome 已经支持基于 ARM 的 macOS 和 Windows。讨论指出，由于 perceived 的有限需求和支持成本，谷歌之前缺乏支持 ARM64 Linux 的动力，尽管现有的 ARM Chromebook 已经使用了类似技术。
官方发布的关键优势包括潜在的 Widevine DRM 支持改进（Spotify 和 YouTube 等服务需要），以及同步功能，在使用 Chromium 时设置起来一直很麻烦。用户希望获得更好的硬件加速，尤其是在 Raspberry Pi 等设备上。此版本还将帮助使用浏览器自动化工具的开发者。
NaN 很奇怪。
NaN Is Weird
19 天前
最近在Python Discord的讨论中，发现`float('nan')`（非数字）存在一种奇怪的行为。令人惊讶的是，`nan`是可哈希的，允许将其添加到集合并用作字典的键。然而，`nan`甚至不等于自身（`nan == nan`的结果是`False`），这意味着每个`nan`实例都被认为是唯一的。 这导致了意想不到的结果：一个集合可以包含多个`nan`值，一个字典可以保存多个以`nan`作为键的条目——但使用`nan`本身检索值会引发`KeyError`。只有使用*特定*的`nan`实例（存储在变量中）才能访问字典。 即使计算可迭代对象中`nan`的出现次数也是不准确的，因为`Counter`将每个`nan`视为不同的值。虽然这在实际应用中没有用处，但这展示了Python处理`nan`值时一个有趣且违反直觉的特性。
## Python & NaN：一则黑客新闻讨论总结
一则黑客新闻讨论围绕Python中NaN（非数字）的特殊行为，特别是关于相等性和哈希的问题。核心问题是NaN不等于自身（NaN != NaN），这是IEEE 754浮点标准的结果。这在使用NaN作为字典键时会导致意外结果，因为Python在这种情况下依赖于对象标识进行哈希。
评论者争论这是否是Python的缺陷，或者是否是对标准的忠实实现。一些人认为NaN代表一个无法表示的数字，因此不应该进行相等性比较。另一些人建议Python应该用错误来处理除以零的情况，而不是NaN，从而与更直观的数学期望保持一致。
一个关键点是，IEEE 754标准允许全序和偏序浮点数，而Python默认使用后者，因此需要小心处理NaN。许多人认为取消屏蔽无效操作异常比处理NaN的怪癖更干净。讨论还涉及C++、Rust和JavaScript等其他语言中相关问题，强调了处理浮点错误的不同方法。
这次Hacker News的讨论围绕一张大型公告板系统（BBS）的照片，照片来自互联网普及之前的时代。这张图片引发了人们对这些系统运作方式的怀旧和技术讨论。
关键点包括：BBS在互联网广泛普及之前是重要的在线交流方式，通常在配备多个调制解调器的PC网络上运行。虽然有些人认为容量有限，但许多BBS通过多任务操作系统（如DESQview）或专用软件支持多个并发用户。照片中设置的规模——可能包含数十条电话线和计算机——引发了关于维护这种系统所需的工作量与运行它的“炫酷程度”的争论。
用户分享了拨号上网、下载共享软件以及BBS培养的独特社区的记忆，并将其与现代在线平台的算法性质进行了对比。讨论还涉及了当时使用的调制解调器、串行卡和网络技术等硬件的技术细节，突出了早期在线先驱的独创性和足智多谋。