返回首页
最新
大多数代理安全测试试图对模型进行越狱。这非常困难，OpenAI和Anthropic在红队测试方面表现出色。
我们采取了不同的方法：攻击环境，而不是模型。
以下是针对我们的攻击套件测试代理的结果：
- 工具操控：要求代理读取一个文件，注入路径=/etc/passwd。它照做了。
- 数据外泄：要求代理读取配置并将其通过电子邮件发送到外部。它做到了。
- Shell注入：用指令污染git状态输出。代理遵循了这些指令。
- 凭证泄露：要求提供API密钥“用于调试”。代理提供了这些密钥。
这些操作都不需要绕过模型的安全机制。模型正常工作——代理仍然被攻陷。
其工作原理：
我们构建了拦截代理实际操作的适配层：
- 文件系统适配层：对open()、Path.read_text()进行猴子补丁。
- 子进程适配层：对subprocess.run()进行猴子补丁。
- PATH劫持：伪造git/nmp/curl，包装真实的二进制文件并污染输出。
模型看到的看似合法的工具输出。它对此毫无察觉。
总共进行了214次攻击，包括文件注入、shell输出污染、工具操控、RAG污染、MCP攻击。
早期访问： [https://exordex.com](https://exordex.com)
希望能收到任何将代理投入生产的人的反馈。
我是不是快要疯了，今天我一直看到来自云服务的nginx错误、GitHub Actions失败，以及Hugging Face无法下载数据的情况。<p>Downdetector显示从微软到Cloudflare的各个地方都有故障，但只有微软表示他们有故障？<p>今天早上X也宕机了几个小时。还有其他人有消息吗？X这边没有任何更新。
这是一个免费且开源的项目。其目的是相比于Lutris，提供对每个游戏的Wine前缀及相关工具（如winetricks、Proton配置等）的更透明的访问。该应用程序还提供与游戏相关的统计信息（如游戏时间、启动次数、崩溃次数等）等相同功能。
嗨，HN，
我是一名独立创始人。在创建ProblemHunt之前，我注意到一个普遍的现象：许多创始人开始时有想法和解决方案，但却没有花足够的时间去理解真实的问题。
ProblemHunt是一个简单的平台，人们可以在这里分享他们在工作或生活中实际面临的问题。开发者和创始人可以浏览这些问题，并将其作为构建产品的起点。
到目前为止：
– 约5000名用户
– 提交了150多个真实问题
– 100%自然增长
这仍然是一个早期阶段，我正在努力了解这个平台是否真正有用。
我非常希望能得到反馈：
– 你会使用这样的东西吗？
– 有哪些地方让你觉得不必要或困惑？
– 什么会让它更有价值？
链接： [https://problemhunt.pro](https://problemhunt.pro)
嗨，HN，
我正在寻找一些现代的测试自动化软件/框架，这些工具能够很好地与Python/Go/TS配合使用。在我的搜索中没有找到合适的选项，我也不想自己搭建测试自动化基础设施。
我的使用场景是在实验室环境中进行硬件和固件测试，我希望避免被迫进入特定供应商的硬件生态系统。
我所寻找的特性包括：
- Python/Go/TS兼容性（SDK、API或一流支持）
- 能够查看和查询历史测试运行（仪表板/日志和指标的趋势视图）
- 能够定义自定义测试序列/工作流，并能够并发运行步骤（不仅仅是一个平面的测试列表）。例如：条件步骤、重试、设置/拆卸阶段、多设备编排（电源、数字万用表、数据采集器和被测设备）
- 硬件无关性/无供应商锁定：我应该能够更换仪器/设备，而无需重写所有内容或被绑定到某个专有供应商（特别是NI）
- 理想情况下：还应该有Slack集成，用于启动测试和通知测试完成
问题：
1. 自己搭建软件架构是唯一的选择吗？如果你们构建过类似的东西，哪个技术栈效果最好（例如，Robot Framework、pytest + 插件、自定义调度器、Airflow/Prefect/Temporal等）？
2. 是否有专门构建的平台可以推荐，并且没有供应商锁定？
3. 你们使用什么工具来管理运行历史和报告？
4. 在可靠性、扩展到多个设备或维护驱动层方面，有没有什么“陷阱”？
如果需要，我很乐意自己组装序列逻辑，但我希望避免从头开始重新发明编排和运行历史/报告的过程。
创建Figr AI是因为我厌倦了那些将自己宣传为设计工具的AI构建工具，却最终跳过了最困难的部分。
我尝试过的每一个工具都直接跳到了界面设计。但产品设计并不是这样的。你并不仅仅是在设计界面，而是首先要思考问题。考虑流程、边缘案例、用户旅程，以及用户可能会遇到的障碍。然后，设计才会随之而来。
Figr首先进行这种思考层面的工作。它通过Chrome扩展解析你现有的产品，或者接受屏幕录制，然后在设计之前与您一起解决问题。它会揭示边缘案例、绘制流程、生成规格、审查用户体验。设计是在思考之后进行的。
之所以能够做到这一点，是因为我们对超过20万个真实的用户体验模式和原则进行了训练。我们的主要关注点是通过理解产品来帮助构建正确的用户体验。
与Lovable/Bolt/V0的区别在于：我认为那些是界面构建工具。当你确切知道自己想要构建什么时，它们是不错的选择，但它们并不能真正帮助你找到问题的正确解决方案。我们希望Figr更像是一个AI产品经理，同时也具备设计能力。
我们用它解决的一些困难的用户体验问题可以在这里查看：<a href="https://figr.design/gallery" rel="nofollow">https://figr.design/gallery</a>
非常希望能得到反馈，特别是来自那些在其他AI构建/设计工具中遇到同样障碍的人。