最新

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

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

LocalAgent 是一个以本地为先的 Rust 代理运行时，专注于工具调用、信任和审批门、可重放的运行以及基准限制的编码工作流程。<p>最近的 v0.5.0 版本的工作主要集中在加强编码任务的行为、改善验证和完成行为，以及减少评估被操控的方式。<p>在这项工作中，有一点特别引人注目，那就是 OmniCoder-9B Q8_0。我更关心的是小模型在真实代码库任务、明确验证、可重放的运行以及更严格的任务合同下是否仍然表现良好，而不是“在演示中看起来不错”。<p>OmniCoder-9B Q8_0 是我认为在这种环境中表现真正稳健的少数小型本地模型之一。我并不是在做广泛的“最佳模型”声明，但它在通常会暴露出推理薄弱、虚假进展或污染的约束下表现得更为稳定。<p>我很好奇其他进行真实本地编码工作流程的人是否也在 OmniCoder 或其他小模型上看到了类似的结果。