## 代理安全：从新奇到必要 (2025-2026) 近期事件表明一个关键转变：提示注入不再是理论风险，而是已部署AI代理面临的实际工程问题。2025年初出现了成功的攻击，利用了代理广泛的权限——包括访问私有仓库和浏览网页——即使*存在*现有缓解措施（如OpenAI的90%精确度检测器，仍然允许23%的成功率）。 核心问题不仅仅是错误的输入，而是代理*如何*处理它们。被污染的内容可能导致数据泄露、恶意代码执行和日益严重的危害，尤其是在具有网页浏览、内存存储和多代理交接等功能的情况下。OpenAI和Anthropic等公司承认这种风险，但继续部署，表明这是一种经过计算的权衡。 关键防御措施现在侧重于限制损害，而不仅仅是防止注入。这包括将工具描述和元数据视为不受信任的代码，严格限定权限（按任务、按仓库），以及稳健地跟踪数据来源。内存是一个特别令人担忧的问题，因为被污染的数据会影响未来的行动。 行业正在趋向于一种类似于应用程序安全的安全模型：清晰的输入标记、明确的危险操作，以及快速的反馈循环来监控不断演变的攻击模式。下一次重大事件很可能涉及多代理工作流程，凸显了对基础设施层面安全的需求，而不仅仅是模型层面的保障。
每日HackerNews RSS
## 代理安全与提示注入风险 - 摘要
最近的 Hacker News 讨论强调了赋予 AI 代理广泛凭证和网络访问权限所固有的安全风险。核心问题在于，给予代理“访问一切”会产生一个巨大的攻击面，容易受到恶意网页注入有害指令的影响。
许多评论者认为最简单的解决方案——限制代理访问权限并将所有网络内容视为不受信任的内容——常常被回避，因为它会限制功能。更深层的问题在于 LLM 架构本身，缺乏指令和数据之间的明确分离，从而使提示注入攻击成为可能。
现有的缓解尝试，例如 OpenAI 的权限链，依赖于 LLM 自我调节，但这并非万无一失。像 OpenGuard 这样的工具旨在提供协议级别的防火墙，而另一些工具，例如 AgentBlocks，则侧重于细粒度的访问控制，并要求对敏感操作进行人工许可。
一个关键的结论是需要一个“确定性门”来在执行*之前*验证操作，无论提示如何加固。 讨论还批评了一些技术博客内容的质量，指出缺乏清晰的人类思考，以及注重密度而非可读性。
## River：一种新的 Wayland 合成器方法
River 的最新版本 (v0.4.0) 通过将合成器和窗口管理器分离成不同的程序，引入了 Wayland 架构的重大转变。 传统上，Wayland 合成器是单体的，要求窗口管理器实现完整的合成器——这是一项巨大的工程。 River 的非单体设计简化了窗口管理器开发，允许专注于窗口管理策略，如定位和键绑定，而 River 处理渲染和底层功能。
这得益于稳定的 `river-window-management-v1` 协议，旨在避免性能损失并保持“帧完美”——确保即使在窗口重新排列期间也能获得流畅、一致的视觉效果。 该协议通过原子“管理”和“渲染”序列管理状态，最大限度地减少通信开销。
这种分离降低了 Wayland 窗口管理器创建的门槛，提高了稳定性（窗口管理器崩溃不会导致会话崩溃），并允许使用更高级的语言编写窗口管理器，而不会影响性能。 目前，已有 15 个窗口管理器与 River 兼容，展示了一个不断发展的生态系统。 虽然目前仅限于 2D 桌面范例，但该项目旨在改善管理窗口管理器的用户体验，并计划在未来发布 1.0 版本。
## Wayland 合成器/窗口管理器分离：摘要
一个名为 River 的新项目因分离 Wayland 合成器和窗口管理器而备受关注——这种设计选择最初在 Wayland 诞生时就已做出，但现在正在被重新审视。传统上，Wayland 将这些功能结合在一起，但 River 认为这增加了不必要的复杂性。这种分离旨在降低创建自定义 Wayland 窗口管理器的门槛，而无需完全重建合成器。
讨论强调了 Wayland 设计中长期存在的争论。一些用户认为 Wayland 是一次令人沮丧的演变，不断地重新发明 X11 中已有的解决方案。另一些人则赞扬 Wayland 的优势，例如改进的 HiDPI 缩放和安全性。
核心思想是允许更模块化和灵活性，使开发人员能够创建针对特定需求量身定制的专用窗口管理器。然而，如果不同的合成器采用不兼容的协议，碎片化仍然是一个令人担忧的问题。这种方法的成功取决于协作和标准化，可能由较小的合成器推动，而 GNOME 等大型项目可能会保持抵制。最终，River 代表着迈向更可定制和可能更高效的 Wayland 体验的一步。
帕兰蒂尔为自己在“杀伤链”中的作用辩护：“我们为此感到自豪”
Palantir defends its role in the kill chain: "We are proud of that"
13 天前
## Palantir 的扩张与坚定立场 在最近的 AIPCon 上，Palantir 展示了其数据分析平台在各个领域的应用——从军事行动和造船到医疗保健和航空，所有这些都围绕一个中心主题：连接数据以实现更快、更高效的决策。 首席执行官 Alex Karp 大胆捍卫了 Palantir 参与“致命”军事行动，表示该公司“非常、非常自豪”地支持作战人员并最大限度地减少己方伤亡，即使这意味着对手会遭受损失。 尽管承认人工智能的潜在危险和社会颠覆——特别是对受过教育的选民的经济状况产生影响，Karp 强调 Palantir 致力于提供解决方案，而不是争论其使用。演示包括用于军事目标定位的“Maven 项目”、用于海军生产的“ShipOS”以及简化医院流程和测量师安排的平台。 会议强调了 Palantir 成为关键基础设施提供商的雄心，充当医疗保健领域的“数据路由器”，并提供全面的运营系统。该公司普遍使用《指环王》的意象，强调了其通过数据驱动的洞察力揭示“所有秘密”的承诺和潜在威胁。
## 生成式人工智能与生产力幻觉 围绕生成式人工智能，特别是大型语言模型（LLM）的炒作，常常集中在它们能够产生的代码数量上。然而，作者认为，庆祝代码行数——无论是人工编写还是人工智能生成——都是衡量程序员生产力的一种根本性错误。 历史上，软件工程专家一直告诫人们不要将代码长度与价值划等号，认识到编程主要在于管理复杂性和表达抽象思想，而不仅仅是为机器生成指令。 LLM 能够加速*编写*代码，但它们无法解决软件开发的核心挑战：设计、规划和理解问题领域。 事实上，代码生成的便捷性可能会适得其反，导致过早实现、增加维护负担（更多代码意味着更多需要维护的内容），以及倾向于重建现有解决方案而不是利用已建立的库。 作者强调，LLM 经常生成需要大量改进的代码，其中充斥着诸如抽象性差、风格不一致以及未能利用现有代码库等问题。 最终，编程仍然是一个协作、由人类驱动的过程，将代码生成速度置于可读性、可维护性和周密设计之上，是对整个软件生命周期的损害。 关键不是*更多*代码，而是*更好*代码，这需要人类专业知识，而不仅仅是人工智能的输出。
## Hacker News 讨论：代码生成与生产力
一场 Hacker News 讨论围绕着一个观点，即尽管人工智能代码生成（“代码生成”）发展迅速，但它不一定能提高生产力。虽然人工智能擅长快速生成代码，尤其是在“原型”任务和学习新工具方面，但许多评论员认为**编写代码并非软件开发的主要瓶颈。**
核心争论在于代码生成的速度是否能抵消调试、理解不熟悉的 AI 生成代码以及处理意想不到的边缘情况所花费的额外时间。 许多用户强调，复杂项目需要仔细的设计、集成、测试和协作——而这些是人工智能目前无法胜任的领域。
一个关键点是，**人工智能可以加速想法的迭代，但不能取代强大的架构设计和对问题领域的深入理解。** 也有人担心人工智能可能会造成可维护性问题，以及调试缺乏明确“意图”的代码的困难。
最终，讨论表明，虽然人工智能提供了有价值的工具，但它对整体生产力的影响是微妙的，并且很大程度上取决于项目的范围、团队动态和用户的做法。 许多人同意，关注*构建什么*仍然比仅仅加速*如何构建*更为重要。
## 单向信任漏洞利用：通过TDO转储进行横向移动
本研究详细描述了Windows单向信任中的一项漏洞，攻击者可以利用该漏洞访问受信任域。单向信任允许从受信任域到信任域的身份验证，反之则不行。在创建信任关系时，会在受信任域中自动创建一个特殊的`TRUST_ACCOUNT`。
虽然看似无害，但此帐户的密码以明文形式存储在*信任域*上的“受信任域对象”（TDO）中。一个新的Python工具`tdo_dump.py`可以有效地提取此TDO，从而揭示在受信任域上以`TRUST_ACCOUNT`身份进行身份验证所需的Kerberos密钥。
这有效地绕过了预期的单向访问控制，从而实现了横向移动。攻陷信任域的攻击者可以在受信任域内执行典型的Active Directory攻击——例如请求票据授予票据（TGT）和创建计算机帐户。该研究强调，由于远程访问和密钥检索方面的限制，现有的工具（如Mimikatz）对于这种特定攻击效果较差。`tdo_dump.py`工具和相关发现可在GitHub上获取。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
不要相信任何人：单向信任真的是单向的吗？ (almond.consulting)
11点 由 notmine1337 1天前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
这篇帖子详细描述了作者构建编译器的惊人经历，并质疑现代编译器的规模。最初持怀疑态度，他们成功地创建了功能完善的C和Lisp编译器，分别仅用1500行和500行代码，且功能妥协最小。这让他们意识到，大型编译器（通常数百万行代码）中的许多复杂性并非任务本身固有的，而是源于大量的“接缝、景观和权宜之计”——不必要的添加和复杂性。 作者将这些大型编译器比作费力构建的、但无法居住的景观。他们自己较小的编译器代表着为一种新方法播下“早期种子”——一种“现代GDSL”，暗示着专注于基本功能和简洁性，而非庞大的功能集。这篇帖子标志着探索这一新方向的开始。
## GDSL：一个极简内核与编译器探索
FirTheMouse最近分享了GDSL，一个2600行C++项目，包含一个“内核”——定义为共享处理核心，而非完整的操作系统——以及Lisp（500行）和C（1300行）语言的子集编译器。该项目尚未实现自举，这意味着编译后的语言无法重新编译源代码。
核心思想是展示编译器复杂性的很大一部分源于管理“边界”——数据表示之间的转换——而不是编译过程本身。GDSL旨在贯穿整个编译过程，保留信息，从而大幅减少代码量，与GCC或LLVM等生产级编译器相比。例如，GDSL-C中的标识符处理需要80行代码，而GCC则需要超过1000行。
该项目目前专注于“MIX”层——代码转换的基本过程——并且缺乏代码生成后端（汇编/LLVM IR）。作者希望扩展GDSL，可能包含后端系统，并探索与其他语言（如Python或Rust）的统一，在易用性和基本理解之间取得平衡。其他人也分享了类似的项目，例如Mu，引发了关于编译器设计和复杂性的讨论。
马里兰大学科学家创造出“智能内衣”来测量人体肠胃气胀。
UMD Scientists Create 'Smart Underwear' to Measure Human Flatulence
13 天前
客户端挑战：您的浏览器已禁用 JavaScript。请启用 JavaScript 以继续。此网站的必要部分无法加载。这可能是由于浏览器扩展、网络问题或浏览器设置所致。请检查您的连接，禁用任何广告拦截器，或尝试使用不同的浏览器。
DR-DOS是Digital Research Inc.于1988年开发的操作系统的一个现代重新实现，作为MS-DOS的一个技术上更先进的替代品。与简单的克隆不同，DR-DOS 9.0是一个“洁净室”重建版本，尊重其创造者Gary Kildall的原始愿景，同时提供一个不受法律限制的平台。 最新版本（修订版330，发布于2026年3月）包含一套完整的文件管理、编辑和系统实用工具，以及十六进制转储和鼠标支持等高级工具。值得注意的是，它保留了低级访问命令（PEEK、POKE、JMP），吸引着黑客和对操作系统开发感兴趣的人。 DR-DOS面向复古计算爱好者、开发者、教育工作者以及任何寻求最小DOS环境的人——非常适合测试经典软件、嵌入式系统或仅仅探索个人电脑操作系统历史。
## 英特尔傲腾 SSD 总结 英特尔的傲腾系列，利用与美光联合开发的 3D XPoint 技术，在 2017 年发布时，融合了 DRAM 和 NAND 闪存的特性——超低延迟、高耐用性和强劲的性能。像 P4800X/P5800X（以及消费级产品）这样的型号在传统 SSD 难以处理的领域表现出色，尤其是在一致的写入性能和数据完整性方面，这得益于断电保护等功能。 然而，傲腾面临着成本高昂和容量有限的挑战。尽管在数据库、VDI 和缓存（Ceph、ZFS）等苛刻的工作负载中具有优势，但 NAND SSD 技术的快速进步以及 Compute eXpress Link (CXL) 的出现降低了其市场吸引力。 英特尔最终在 2022 年停止了傲腾的开发，退出闪存存储市场。尽管如此，傲腾产品仍然可用，包括于 2023 年初发布的新型持久内存 NV-DIMM 系列，以支持英特尔的 Sapphire Rapids CPU。虽然其未来有限，但傲腾展示了存储技术的一项重大创新，为特定高性能应用提供了无与伦比的耐用性和低延迟。
运行 清除 补丁 保存 加载 音垫 固定 复古 指南 自述文件 历史 · 运行 · 清除 加载wasm… 补丁 · octetta/k-synth 加载中… 音垫 鼓 旋律 播放 下载wav 重命名 设置基准速率 清除插槽 插槽 音高 取消 确定
## k-synth：APL 驱动的合成器
Octetta 构建了 “k-synth”，一个基于网页的合成器，它尝试使用一种极简的、K 风格的数组语言来绘制波形。目标不是取代 DAW，而是提供一种紧凑的方式来生成样本。用户可以在 [https://octetta.github.io/k-synth/](https://octetta.github.io/k-synth/) 现场试用 – 一个预制补丁 (“dm-bell.ks”) 是一个很好的起点。
该项目利用了一种简化的、右结合的数组语言（使用单字母命令，如 's' 代表正弦波，'p' 代表 pi），并使用 WASM 和 Web Audio 实现。值得注意的是，AI 代理被用来引导解析器和 Web 工具包的构建，从而加速了开发。
该项目是开源的（MIT 许可），并且在 GitHub 上可用 ([https://github.com/octetta/k-synth](https://github.com/octetta/k-synth))。Octetta 正在寻求来自数组语言和 DSP 社区的反馈，特别是关于运算符选择和从右到左的评估逻辑。相关项目如 BQN、Uiua 和 Strudel 也被提及为灵感来源，未来的计划包括从 Emacs 发送 UDP 控制以及一个跨平台的 MIDI 库。