最新

嗨，HN， 我开发了DiscoMonday，这是一款语音人工智能导览工具，让任何访客都能根据他们的位置获得实时解说——只需使用手机和耳机，无需硬件、无须安装应用程序，也不需要编写代码。 这只是核心引擎的技术预览，尚未推出完整的SaaS产品。您可以： - 使用GPS或点击地图设置您的位置 - 根据您的位置听到AI开始讲解 - 在讲解过程中打断并提出后续问题 - 通过OpenAI + LiveKit获得实时语音回复 试试演示： [https://discomonday.com](https://discomonday.com) 如果未启用GPS，请点击地图以模拟位置。 如果服务器过载，您仍会被加入等待名单（所有注册用户均如此）。 需要麦克风和位置权限——这是一个以音频为主的体验。 我为什么要开发这个： 在一次城市旅行中，我和妻子不断问“那座建筑是什么？”但没有任何应用能够回答。因此，我拼凑了一个原型。当前系统是朝着让基于语音的、位置感知的界面变得简单易用的一步——适用于博物馆、展览、旅游等多个场景。 我希望获得的反馈： - 语音听起来够快且自然吗？ - 有什么地方让您感到困惑或不顺畅吗？ - 您个人希望将其用于哪些场景？ 隐私说明： 您的隐私很重要。我们会剥离所有个人数据，仅保留匿名的使用统计数据以改善体验。 —— 我是Mark I. Matsushima，一名位于日本冲绳的独立创始人。 这个项目是使用Next.js、OpenAI的实时API、LiveKit和AWS Lambda/EC2构建的。 感谢您的反馈！

大家好，我是Tyler Flint，qtap的创始人之一。 一段时间以来，我和Qpoint.io的团队一直在努力解决一个挑战：理解我们生产系统中离开的加密流量到底发生了什么。现代应用程序在很大程度上依赖于第三方API（比如支付处理器、数据提供商等），但一旦启用TLS，准确了解发送了哪些数据、识别个人身份信息（PII）的暴露情况或调试集成问题就变得非常困难，往往需要依赖复杂且脆弱的解决方案。 传统的方法，如正向代理，需要终止TLS（中间人攻击），管理证书，并且通常会引入性能瓶颈或单点故障。网络防火墙通常在L3/L4层工作，缺乏有效的负载可见性。我们觉得应该有更好的解决方案。 这就是我们构建qtap的原因。它是一个轻量级代理，利用eBPF在内核级别捕获网络流量。关键思想是在加密前和解密后钩住常见的TLS库（如OpenSSL）。这使我们能够深入了解HTTPS/TLS流量的实际请求/响应负载，而无需终止连接或管理证书。由于利用了eBPF，性能影响相比传统方法微乎其微。 通过qtap，我们现在可以准确看到我们的应用程序与哪些外部服务进行通信，检查负载以进行调试或安全审计（例如，发现意外的PII泄露），监控第三方依赖的API性能/错误，并更清晰地了解我们的出口流量模式。 我们发现这种方法在提高可靠性和安全性方面非常有效。我们将qtap打包为Linux二进制文件、Docker容器和Helm图表以便部署。 这一切仍在不断发展，但我们对使用eBPF实现这种深度而非侵入式的可见性感到兴奋。 我们希望能听到HN社区的反馈： ``` 你们在监控加密出口流量时是否面临类似的挑战？ 相比其他方法，你们对使用eBPF有什么看法？ 有没有我们尚未考虑的建议或潜在用例？ ``` 欢迎随时提问！

想象一下，您可以输入任何问题，立即获得一个组织完善的答案，包含来源、摘要和知识图谱……这就是我们今天正在构建的AI研究助手的强大功能，利用Motia这一改变AI代理游戏规则的后端框架！ 这不仅仅是另一个教程——它是对AI工作流程未来的预览。 看看Motia的事件驱动魔法如何让您将复杂任务串联起来： - 接受您的查询， - 使用Gemini生成搜索思路， - 在网络上进行广泛搜索， - 深入内容分析， - 提取关键概念， - 提供完整的研究报告。 我们将开始实时编码（好吧，差不多！），您将看到启动一个强大代理是多么快速和简单。

请访问以下链接下载测试版：<a href="https://voideditor.com/download-beta">https://voideditor.com/download-beta</a>

大家好， 我们很高兴发布一个新的计算机使用基准测试。我们最初并没有计划开发一个基准测试，但发现当前的OSWorld环境非常难以使用，许多测试结果也存在问题。 OSUniverse旨在简单易用，只需安装Docker，并且可以通过一条命令运行。它提供了多个测试级别，复杂性逐渐增加，并且易于扩展。 我们已经对所有顶级代理进行了基准测试。随着新的图形用户界面代理的发布，我们将继续更新它们的性能。 祝您使用愉快！

这个 Playwright 测试脚本使用人工智能来测试西斯廷教堂烟囱是否冒烟，以及冒出的烟是否是白色的。只有当烟是白色时，测试才会通过。 目前设置为使用 Google Gemini Flash 2.0，但您可以通过在 GitHub Actions 工作流中设置环境变量来切换到其他大型语言模型提供者/模型：<a href="https://github.com/donobu-inc/donobu-papal-election-tests/blob/main/.github/workflows/tests.yaml">https://github.com/donobu-inc/donobu-papal-election-tests/blob/main/.github/workflows/tests.yaml</a> 我已设置在教宗选举期间每分钟运行一次 - <a href="https://github.com/donobu-inc/donobu-papal-election-tests/actions">https://github.com/donobu-inc/donobu-papal-election-tests/actions</a>

首先，我要为这个吸引眼球的标题道歉。Apache Flink并没有死——我们实际上非常喜欢它！事实上，ZephFlow正是源于我们对Flink强大能力的钦佩。 但在单实例、边缘计算和资源受限的环境中，我们发现Flink的架构引入了我们不需要的复杂性。 ZephFlow保留了Flink高性能、低延迟数据处理的核心原则，同时去除了所有使其难以操作的部分。 为什么ZephFlow在2025年如此重要： - 边缘优化：到2025年，75%的企业数据将转向边缘处理，像ZephFlow这样的轻量级框架变得至关重要。 - 5G就绪：为5G时代的超低延迟需求而设计，数据处理更接近生成源。 - AI管道集成：非常适合边缘AI应用的数据预处理。 - 双重部署：作为API后端或数据管道使用，代码库保持一致。 - 云成本优化：在边缘处理和过滤数据，仅将重要信息发送到云端。 “本地→分布式”的创新： 正如DuckDB通过让你在本地开发并扩展到分布式环境来彻底改变分析处理，ZephFlow将同样的概念引入流数据处理。你可以在单实例上开发和测试你的流处理管道，然后将完全相同的代码部署到分布式环境中。 我们一直在大规模使用ZephFlow进行日志和遥测处理，从本地开发到生产环境的无缝过渡对我们来说是一个游戏规则的改变。 我们希望听到你的意见： 我们正在努力发布一个保持相同简单性但可以横向扩展的分布式版本。哪些分布式功能对你来说最有价值？请在评论中告诉我们。 查看我们的项目，地址是<a href="https://github.com/fleaktech/zephflow-core">https://github.com/fleaktech/zephflow-core</a>，如果你觉得有用，请给我们一个星星！