最新

大家好，我是 Mario。我最近和一位同事聊了关于 AI、智能体以及软件开发未来将如何变化的话题。我们一直在思考，既然 AI 智能体已经可以通过提示词很好地实现软件，为什么我们还要分享代码呢？为什么每个人不能通过提示词获得定制的软件呢？ “分享提示词，而不是代码。” 嗯，我想，好主意，让我们试试。这就是我创建 Open Prompt Hub 的原因：[https://openprompthub.io](https://openprompthub.io)。 可以把它想象成专门为提示词打造的 GitHub。 这个想法很简单：用户可以上传提示词，然后你和你的 AI 工具就可以使用这些提示词来生成脚本、应用程序或 Web 服务（或者为你的智能体准备特定任务）：只需将其粘贴到你的智能体或 IDE 中，然后看着它为你构建。如果提示词不能 100% 满足你的用例，就 Fork 它，调整它，然后就大功告成了：量身定制的软件就可以使用了！ 这些提示词是简单的 Markdown 文件，带有用于元信息的 frontmatter 块。（规范可以在这里找到：[https://openprompthub.io/docs](https://openprompthub.io/docs)）它们有版本控制，包含关于哪些 AI 模型成功构建了它的信息，以及关于 AI 智能体如何测试生成的软件的说明。 用户可以提及他们使用哪些模型成功或不成功地执行了提示词（构建或失败）。这有助于评估提示词是否提供可靠的输出。 想创建一个开放提示词文件吗？这里有一个提示词可以引导你完成：[https://openprompthub.io/open-prompt-hub/create-open-prompt](https://openprompthub.io/open-prompt-hub/create-open-prompt) 安全性！在处理 AI 和提示词时，这总是一个话题？我添加了几个安全检查，用于检查每个提示词的注入和恶意行为。包括统计分析以及针对 LLM 的两次检查，用于行为分类和提示词注入检测。 目前它还是一个 MVP（最小可行产品）。但所有提到的功能都已包含在内。 如果这听起来不错，请告诉我。试用一个提示词，Fork 它，或者告诉我你希望在规范或安全扫描器中更改什么。我真的很好奇什么能让你信任和重用提示词。或者，如果你喜欢这个总体想法...

AI 智能体正在快速涌现（LangChain, CrewAI, MCP 服务器, OpenAI Agents SDK），但缺乏统一的安全和治理方法。我们构建了 g0，旨在成为这一控制层。 g0 在智能体生命周期中的作用： * **g0 scan - 静态 + 行为分析智能体代码。** 涵盖 12 个安全域的 1180 条规则，支持 10 个框架（LangChain, CrewAI, MCP, OpenAI, Vercel AI, Bedrock, AutoGen, LangChain4j, Spring AI, Go AI），5 种语言。检测有毒工具链、污点流、权限过高的描述、缺失的沙盒。集成的威胁情报会针对 55+ IOC 和已知 CVE 检查工具 URL 和依赖项。 * **g0 test - 动态对抗性红队测试。** 对正在运行的智能体发起提示注入、数据泄露尝试、工具滥用序列、越狱和目标劫持攻击。采用 3 级渐进式判断（确定性、启发式、LLM）。通过 HTTP 和 MCP 工作。 * **g0 endpoint - 发现机器上的每个 AI 工具（Claude Code, Cursor, Windsurf, Zed，15+ 工具），清点 MCP 服务器，并揭示配置错误。** 就像针对 AI 开发人员界面的 nmap。 * **g0 daemon - 持续运行时监控。** 行为基线与异常检测、成本断路器、关联引擎将来自不同来源的事件链接成攻击链，以及在情况失控时的紧急停止开关。 * **g0 detect - MDM 注册检测（Jamf, Intune, Mosyle, Kandji 等），运行中的 AI 智能体发现，以及主机加固审计，一览无余。** * **一流的 OpenClaw 支持。** g0 是唯一理解 OpenClaw 架构的安全工具：网关加固（18 个探测器），SKILL.md/SOUL.md/MEMORY.md 分析，通过 SHA-256 基线进行认知漂移监控，部署审计，配置加固，以及 ClawSec CVE 订阅集成。如果您在生产环境中运行 OpenClaw，g0 会捕获通用扫描程序遗漏的内容。 * **内置合规性，而非事后添加。** 每个发现都映射到 10 个标准：OWASP Agentic Top 10, OWASP LLM Top 10, NIST AI RMF, ISO 42001, EU AI Act, MITRE ATLAS 等。生成证据记录、合规性报告，并通过 .g0-policy.yaml 和 CI 门控支持执行策略。 * **输出：** 终端、JSON、SARIF 2.1.0、HTML、CycloneDX AI-BOM、Markdown。可插入 GitHub Actions、GitLab CI 或任何管道。 * **一键启动：** npx @guard0/g0 scan . * **GitHub：** [https://github.com/guard0-ai/g0](https://github.com/guard0-ai/g0) 我们认为 AI 智能体生态系统需要与 Web 应用程序通过 Burp Suite 和 Semgrep 获得的相同的安全工具成熟度，但专为智能体量身定制。 欢迎就架构或威胁模型提出问题。

大家好，我们是 Jeet 和 Husain，来自 Modulus (<a href="https://modulus.so" rel="nofollow">https://modulus.so</a>) - 一款桌面应用程序，让您可以使用共享项目记忆运行多个编码代理。 我们构建它的目的是为了解决我们反复遇到的两个问题： * 跨仓库上下文断裂。当跨多个代码仓库工作时，代理无法理解它们之间的依赖关系。即使我们在单独的 Cursor 窗口中打开两个仓库，在前端仓库中进行更改时，我们仍然需要手动解释后端 API 模式。 * 代理会丢失上下文。在不同的编码代理之间切换通常意味着丢失上下文并重复相同的指令。 Modulus 在代理和仓库之间共享记忆，这样它们就可以理解您的整个系统。 它是一种替代工具，例如 Conductor，用于编排 AI 编码代理来构建产品，但我们特别关注多仓库工作流程（例如，后端仓库 + 客户端仓库 + 共享库仓库 + AI 代理仓库）。我们从头开始构建了自己的记忆和上下文引擎，专门用于编码代理。 为什么要构建另一个代理编排工具？这源于我们自己的问题。在从事我们上一家初创公司的工作时，Husain 和我跨越了两个不同的代码仓库。跨仓库工作意味着手动在 Cursor 窗口之间粘贴 API 模式——一遍又一遍地告诉前端代理后端 API 的样子。所以我们构建了一个小的上下文引擎来跨仓库共享知识，并通过 MCP 将其连接到 Cursor。后来，它变成了 Modulus。 很快，Modulus 将允许团队与他人共享知识，以改善他们使用 AI 编码代理的工作流程——在 AI 编码时代实现团队协作。我们的 API 将允许开发人员在编码代理或 IDE 之间切换，而不会丢失任何上下文。 如果您想在尝试之前观看快速演示，这是我们的发布帖子 - <a href="https://x.com/subhajitsh/status/2024202076293841208" rel="nofollow">https://x.com/subhajitsh/status/2024202076293841208</a> 我们非常感谢您提供的任何反馈，并希望您有机会试用 Modulus。

使用 Vibe 编码工具，添加多语言支持变得出乎意料地简单。如果你要求模型添加西班牙语、葡萄牙语、德语或法语等语言，它通常可以很快地设置 i18n 结构，即使对于包含大量文本的项目也是如此。 我注意到的一件事是，一旦网站被 Google 索引，流量并不总是主要来自美国。有时，很大一部分流量来自其他国家，通过搜索而来。但大多数发布平台或目录都是纯英文的，因此它们在其他语言的可发现性方面并没有真正提供帮助。 因此，我尝试了名为 LeanVibe 的项目，做了一些不同的事情。这个想法很简单：你用你喜欢的任何语言提交你的产品一次。然后，平台会自动将内容翻译成支持的语言，访问者默认会看到他们本地语言的界面和产品描述。 顺便说一句，LeanVibe 不仅仅是一个发布平台。它更像是一个社区空间，有博客、论坛，可以关注人或产品，以及寻找合作者的方式。我目前的想法是将自动翻译扩展到博客文章和论坛讨论。 缺点是此功能会消耗大量 LLM 代币，并且比平台上的大多数其他功能更耗费资源。 我很好奇这里的人怎么看。自动多语言支持真的有助于早期产品的发现和增长吗，还是对于这样的平台来说，这是一种不必要的复杂性？