最新

AI代理的开发速度很快（LangChain、CrewAI、MCP服务器、OpenAI Agents SDK），但目前还没有统一的方式来确保它们的安全和治理。我们构建了g0来作为这一控制层。 **g0在代理生命周期中的功能：** - **g0扫描** - 对代理代码进行静态和行为分析。涵盖12个安全领域的1,180条规则，支持10个框架（LangChain、CrewAI、MCP、OpenAI、Vercel AI、Bedrock、AutoGen、LangChain4j、Spring AI、Go AI），以及5种编程语言。能够检测有毒工具链、污点流、过度特权描述和缺失的沙箱保护。集成的威胁情报检查工具会将工具的URL和依赖项与55个以上的IOC和已知CVE进行比对。 - **g0测试** - 动态对抗性红队测试。对正在运行的代理发起提示注入、数据外泄尝试、工具滥用序列、越狱和目标劫持有效载荷的攻击。采用3级渐进判断（确定性、启发式、LLM）。支持HTTP和MCP协议。 - **g0端点** - 发现机器上的每个AI工具（Claude Code、Cursor、Windsurf、Zed及15个以上工具），清点MCP服务器，并揭示配置错误。可以将其视为针对AI开发者环境的nmap工具。 - **g0守护进程** - 持续运行时监控。建立行为基线并进行异常检测，具备成本断路器，关联引擎将不同来源的事件链接成攻击链，并在出现问题时提供紧急关闭开关。 - **g0检测** - MDM注册检测（Jamf、Intune、Mosyle、Kandji等）、运行中的AI代理发现以及主机加固审计一览。 - **一流的OpenClaw支持**。g0是唯一理解OpenClaw架构的安全工具：网关加固（18个探针）、SKILL.md/SOUL.md/MEMORY.md分析、通过SHA-256基线监测认知漂移、部署审计、配置加固，以及ClawSec CVE信息流集成。如果您在生产环境中运行OpenClaw，g0能够捕捉到通用扫描器遗漏的内容。 - **合规性内置，而非附加**。每个发现都映射到10个标准：OWASP代理十大、OWASP LLM十大、NIST AI RMF、ISO 42001、欧盟AI法案、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中获得的同样的安全工具成熟度，但这是专门为代理构建的。欢迎就架构或威胁模型提出问题。

你好，HN，我们是来自Modulus的Jeet和Husain（<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）结构，即使对于文本量较大的项目也是如此。 我注意到的一点是，一旦网站被谷歌索引，流量并不总是主要来自美国。有时，来自其他国家的流量通过搜索也占据了相当大的比例。然而，大多数启动平台或目录仅支持英语，因此在其他语言的可发现性方面并没有太大帮助。 因此，我尝试了一个名为LeanVibe的不同项目。这个想法很简单：你只需以你喜欢的语言提交一次产品。平台会自动将内容翻译成支持的语言，访客默认会看到他们本地语言的界面和产品描述。 顺便提一下，LeanVibe不仅仅是一个启动平台。它更像是一个社区空间，包含博客、论坛、关注人或产品的功能，以及寻找合作者的方式。我目前的想法是将自动翻译扩展到博客文章和论坛讨论中。 缺点是，这个功能消耗了相当多的LLM令牌，并且比平台上的大多数其他功能更重。 我很好奇这里的人们怎么看。自动多语言支持是否真的有助于早期产品的发现和增长，还是对这样的平台来说是多余的复杂性？

嗨，HN，我们是Sanchit和Shubham（YC W26）。我们为Apple Silicon构建了一个快速推理引擎。无论是大型语言模型（LLMs）、语音转文本（STT）还是文本转语音（TTS），MetalRT在我们测试的每种模式下都超越了llama.cpp、Apple的MLX、Ollama和sherpa-onnx。我们使用了自定义的Metal着色器，没有框架开销。 此外，我们还开源了RCLI，这是在Apple Silicon上最快的端到端语音AI管道。从麦克风到语音响应，完全在设备上运行。无需云端，无需API密钥。 开始使用的方法： ```bash brew tap RunanywhereAI/rcli https://github.com/RunanywhereAI/RCLI.git brew install rcli rcli setup # 下载约1 GB的模型 rcli # 交互模式，按下说话 ``` 或者： ```bash curl -fsSL https://raw.githubusercontent.com/RunanywhereAI/RCLI/main/install.sh | bash ``` 性能数据（M4 Max，64 GB，通过 `rcli bench` 可复现）： LLM解码 – 比llama.cpp快1.67倍，比Apple MLX快1.19倍（使用相同的模型文件）： - Qwen3-0.6B: 658 tok/s（vs mlx-lm 552，llama.cpp 295） - Qwen3-4B: 186 tok/s（vs mlx-lm 170，llama.cpp 87） - LFM2.5-1.2B: 570 tok/s（vs mlx-lm 509，llama.cpp 372） - 首个令牌时间：6.6毫秒 STT – 70秒的音频转录仅需*101毫秒*。这相当于714倍实时速度，比mlx-whisper快4.6倍。 TTS – 合成时间为178毫秒，比mlx-audio和sherpa-onnx快2.8倍。 我们之所以构建这个，是因为在设备上演示AI很简单，但将其投入实际使用却非常困难。语音是最难的测试：你需要依次连接STT、LLM和TTS，如果任何一个环节速度慢，用户都会感受到。大多数团队回退到云API，并不是因为本地模型不好，而是因为本地推理基础设施不足。 难以解决的问题是延迟叠加。在语音管道中，你需要依次堆叠三个模型。如果每个模型都增加200毫秒，那么在用户听到第一个词之前，你就已经达到了600毫秒，这种体验是不可接受的。你无法仅优化一个环节就认为完成了。每个环节都需要快速，在一台设备上运行，且没有网络往返延迟可以依赖。 我们直接使用了Metal。自定义GPU计算着色器，所有内存在初始化时预分配（推理过程中零分配），并且为所有三种模式提供一个统一的引擎，而不是将不同的运行时拼接在一起。 MetalRT是第一个在Apple Silicon上原生处理所有三种模式的引擎。完整的方法论： LLM基准测试：[https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-engine-apple-silicon](https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-engine-apple-silicon) 语音基准测试：[https://www.runanywhere.ai/blog/metalrt-speech-fastest-stt-tts-apple-silicon](https://www.runanywhere.ai/blog/metalrt-speech-fastest-stt-tts-apple-silicon) 如何做到：大多数推理引擎在你和GPU之间添加了许多层：图调度器、运行时调度器、内存管理器。MetalRT跳过了这些。自定义Metal计算着色器用于量化的矩阵乘法、注意力机制和激活函数——提前编译，直接调度。 语音管道优化的详细信息：[https://www.runanywhere.ai/blog/fastvoice-on-device-voice-ai-pipeline-apple-silicon](https://www.runanywhere.ai/blog/fastvoice-on-device-voice-ai-pipeline-apple-silicon) RAG优化：[https://www.runanywhere.ai/blog/fastvoice-rag-on-device-retrieval-augmented-voice-ai](https://www.runanywhere.ai/blog/fastvoice-rag-on-device-retrieval-augmented-voice-ai) RCLI是基于MetalRT构建的开源语音管道（MIT）：三个并发线程，使用无锁环形缓冲区，双缓冲TTS，通过语音执行38个macOS操作，本地RAG（约4毫秒，处理5000多个块），20个热插拔模型，以及一个具有每个操作延迟读数的全屏TUI。当MetalRT未安装时，回退到llama.cpp。 源代码：[https://github.com/RunanywhereAI/RCLI](https://github.com/RunanywhereAI/RCLI)（MIT） 演示：[https://www.youtube.com/watch?v=eTYwkgNoaKg](https://www.youtube.com/watch?v=eTYwkgNoaKg) 如果设备上的AI真的和云端一样快，你会构建什么？