最新

我一直在审计开源执行引擎如何处理提示词注入。 多数引擎（如 OpenClaw）依赖于三层静态防御：正则表达式黑名单、XML 标签和字符净化。 问题在于，正则表达式就像猫捉老鼠的游戏。它在寻找“忽略指令”时，会漏掉“无视之前的指令”。它在多语言攻击面前会彻底失效。一旦 Agent 获得了工具访问权限（shell、数据库），一个语义上的微小偏差就会变成 RCE（远程代码执行）。 所以我构建了 Prompt Inspector。它是一个语义检测引擎，旨在超越黑名单。 核心优势： 基于向量的检测：我们使用嵌入来映射提示词，而不是关键词。即使措辞独特或经过翻译，它也能捕捉到注入的意图。 自我演进循环：临界情况会触发异步 LLM 审查。如果是一种新的攻击模式，系统会自动提取嵌入并更新向量数据库。它会从新的攻击中学习。 设计上解耦：它返回置信度分数，而不是直接阻止。开发人员可以完全控制执行路由。 可插拔：最初使用谷歌最新的嵌入，但该架构允许自定义部署模型，以避免厂商锁定。 技术栈：FastAPI、向量数据库、谷歌嵌入模型和一个 LLM 循环审查器。 我目前为早期测试者和开源项目提供免费积分。我很想听听大家是如何在基本的提示词工程之外处理工具调用安全性的。 网址：https://promptinspector.io

我开发 Pano 是因为我总会遗失那些我真正想回过头来看的东西。<p>Pano 是一款互联网归档工具，可以让你将链接保存到书架上，进行整理和分享。<p>对我来说，问题从来不是找不到东西，而是如何保存它们。研究论文、食谱、旧博客文章、代码库、教程，以及深夜偶然发现的网站，最终都会散落在标签页、书签、截图、已保存的帖子和 PDF 文件中。几周后，它们就基本上消失了。<p>我想要的是一个地方，保存的链接可以保持井然有序，易于浏览，并且可以作为一个集合轻松分享。<p>我做了大量的工作，主要集中在两件事上：元数据提取和界面设计。如果保存的链接最终变成没有标签的书签，那么它们就失去了很多价值，因此 Pano 尝试提取结构化信息，如标题、描述、作者、日期和类型，并原生支持 YouTube、GitHub、Reddit、Substack、Spotify 等网站。我还花了很多时间在设计上，因为我希望保存的链接能够让人感觉可以浏览，值得再次访问；更像是一个书架，而不是一个实用的网址列表。<p>Pano 还有一个 Chrome 扩展程序，可以一键保存，以及一个批量导入现有书签的功能。<p>我特别感兴趣的是，“书架”模型是否比传统的书签感觉更好，以及保存/整理/分享的流程在哪些方面仍然感觉不够流畅。<p>目前是免费的：panoit.com

LocalAgent 是一个用 Rust 编写的、本地优先的 Agent 运行时，专注于工具调用、信任和审批门、可重放运行以及基准测试控制的编码工作流程。 最近 v0.5.0 版本的大量工作都集中在加强编码任务行为、改进验证和完成行为，以及减少评估被操纵的可能性。 在这项工作中，最引人注目的是 OmniCoder-9B Q8_0。我不太关心“在演示中看起来不错”，更关心的是一个小模型在真实代码库任务、显式验证、可重放运行和更严格的任务协议下是否仍然表现出色，而无需依赖特定于基准测试的技巧。 OmniCoder-9B Q8_0 是为数不多的几个在我看来在这个环境中真正稳健的小型本地模型之一。我并不是在做一个广泛的“最佳模型”声明，但它在通常会暴露推理薄弱、虚假进展或污染的约束条件下表现得更好。 很好奇其他进行真实本地编码工作流程的人是否在使用 OmniCoder 或其他小型模型时看到了类似的结果。