你会认为军方能够远程关闭它们，不是吗？
返回首页
一周热榜
Claude目前有一个促销活动（3月13日至27日），在工作日的早上8点到下午2点（东部时间）之外，您可以享受双倍使用。我（实际上是Claude）制作了一个单页工具，可以将高峰时段转换为您的时区，并显示剩余的日程安排。这个工具是一个HTML文件，没有任何依赖。
嗨，HN，
Sulcus将AI记忆从一个被动的数据库（仅搜索）转变为一个主动的操作系统（自动管理）。
核心转变
当前的记忆（向量数据库）是静态的。Sulcus将记忆视为大型语言模型（LLM）的虚拟内存管理单元（VMMU），利用“热力学”特性自动管理代理的记忆与遗忘。
主要特点
反应触发：记忆系统根据规则“回应”代理，而不是让代理手动搜索（例如，自动固定偏好，当记忆即将“衰退”时通知代理）。
热力学衰退：记忆具有“热量”（相关性）和“半衰期”。频繁回忆会增强记忆；忽视则会导致删除或归档。
令牌效率：通过智能分页声称减少90%的令牌消耗——仅向LLM提供当前“热门”的内容。
技术：使用Rust和PostgreSQL构建；作为MCP（模型上下文协议）侧车运行。
[https://sulcus.dforge.ca/membench](https://sulcus.dforge.ca/membench)
我需要找一个合作伙伴来推出我的应用程序。我是一名建筑专业人士，开发了一款处于未开发领域的应用。这是一款出色的工具，完全离线使用，不需要云端、不需要账户，也没有订阅。没有人想要那些麻烦的东西！为我们建筑专业人士开发的所有移动应用都很糟糕，我试过它们所有的。<p>我接触了许多移动应用开发者，但他们都没有咨询或合作推出应用的途径。在开发之前，他们都收取高额费用。<p>我们该去哪里找到你！
标签、分屏和tmux在你打开多个项目时工作良好，但当有日志、测试和长时间运行的shell时，我总是重新构建上下文，而不是继续工作。Horizon将shell放在一个无限的画布上。你可以将它们整理成工作区，稍后重新打开时布局、滚动记录和历史记录都保持不变。<p>这个项目在3天内使用Claude/Codex构建而成，在此过程中我也在实际使用这个工作流程。欢迎反馈和贡献。
大家好，
我们开发了 FireClaw，因为我们注意到 AI 代理在网页内容中遭遇提示注入攻击。代理获取一个页面，页面上写着“忽略之前的指令”，结果你的代理突然开始泄露数据或执行不该执行的命令。
现有的解决方案是在事后检测注入攻击。我们希望能够加以预防。
FireClaw 是一个安全代理，位于你的 AI 代理与网络之间。每次请求都经过四个阶段的处理：
1. DNS 黑名单检查（URLhaus、PhishTank、社区数据源）
2. 结构化清理（去除隐藏的 CSS、零宽度 Unicode、编码技巧）
3. 隔离的 LLM 摘要（强化的子进程，没有工具或内存）
4. 输出扫描，使用金丝雀令牌（检测内容是否绕过摘要处理）
关键的见解是：即使第三阶段的 LLM 被注入，它也没有工具、没有内存，并且无法访问你的数据。它只能返回文本——而这些文本在第四阶段仍会被扫描。攻击者会陷入死胡同。
其他设计决策：
- 没有旁路模式。处理流程是固定的。如果你的代理被攻陷，它无法禁用 FireClaw。
- 社区威胁数据源——实例匿名共享检测元数据（域名、严重性、检测次数），以建立共享黑名单。绝不会发送页面内容。
- 作为物理设备在 Raspberry Pi 上运行，配有 OLED 显示屏，实时显示统计信息，并在捕获到威胁时点亮动画火焰。
我们广泛搜索了文献和开源项目——没有其他人正在进行基于代理的防御以应对代理提示注入。虽然存在检测和沙箱技术，但没有一个可以在内容到达代理上下文之前进行清理的内联代理？我们找不到这样的解决方案。
提供了 200 多种检测模式、JSONL 审计日志、域名信任等级、速率限制和成本控制。采用 AGPLv3 许可证。
网站： [https://fireclaw.app](https://fireclaw.app)
希望能收到任何从事 AI 代理安全工作的人的反馈。我们还缺少什么？我们应该将哪些攻击向量添加到模式数据库中？
当PG取消了公众的点赞和点踩时，是为了消除偏见和投票的惯性。然而，这些反馈在事后仍然对研究有用。关于标记数量也是如此——了解哪些帖子被标记得最多会很有趣。<p>我也很乐意听到其他更具深度的建议。
Cala的团队在LinkedIn上分享了一项值得深入思考的发现。他们推出了一款MCP服务器，支持三种知识图谱的访问模式：自然语言查询、结构化查询语言和直接的实体/关系遍历。
他们原本预期代理会默认使用自然语言。然而，实际上大多数代理自主切换到了结构化查询和图谱遍历。没有任何提示，也没有任何引导。
显而易见的解释是“代理更喜欢效率。”我认为这并不完全正确。他们真正偏好的其实是确定性。
自然语言查询引入了两个解释层次：代理生成一条散文形式的查询，系统对这段散文进行解释，然后返回一个结果，代理需要解析这个结果。在这个过程中，代理无法验证查询是否被正确理解。而使用结构化查询时，契约是明确的。代理确切知道自己请求了什么，并且可以验证返回的结果。
这并不是对效率的自发偏好，而是工具使用的思维链条在正常发挥作用：选择一个代理可以最可靠地确认自己得到了正确答案的路径，然后再进行下一步。
如果这一点成立，可能会有几个影响：
- 以自然语言为首的工具接口可能在为错误的用户优化。人类操作员想要自然语言，而代理并不需要。
- 仅暴露自然语言端点的MCP服务器正在迫使代理通过一个非确定性的瓶颈，而如果有选择的话，他们会避免这个瓶颈。
- 针对代理的工具设计应该默认使用结构化访问，以自然语言作为备用，而不是反过来。
嗨，HN！我是Ezra，MDX Docs的创建者。
我之所以开发这个工具，是因为我想要一个快速、简单的方法来使用Markdown和React结合MDX来记录组件。
我的目标是保持事情的简单明了：页面只是MDX文件，并且它们直接映射到路由。你可以编写文档，并在旁边直接插入React组件，而无需太多设置。
它还包括一个命令行工具：
```
npx create-mdx-docs@latest my-docs
```
我一直在用它快速搭建文档网站，到目前为止，这个工作流程非常顺畅。
我很好奇现在其他人是如何处理组件和内部工具的文档的。如果有任何问题，欢迎提问。
昨天在工作中，我和我的同事在他们的系统中测试我库的更改。作为AI驱动的工程师，我们只是让Claude（一个AI工具）来推动进展。在让AI运行测试、进行更改和修复错误的两个小时后，我突然决定自己来做最后的更改。你知道的，比如移动代码、修复错误、重命名函数、运行格式化工具，甚至写提交信息并推送到上游。然后我看着我的同事，开玩笑地说：“你会喜欢我最后的更改，因为它终于能正常工作了，这是一种有机提交。”这让我开始思考，难道现在已经是时候在编码中使用“有机”这个术语了吗？