最新

标题：展示 HN：PageAgent，一个嵌入在你网页应用中的图形用户界面代理 大家好， 我正在构建 PageAgent，这是一个开源（MIT）库，可以将 AI 代理直接嵌入到你的前端中。 我之所以开发这个，是因为我相信在我们已经使用的网页应用中，原生部署通用代理的设计空间非常广阔，而不是仅仅将网页视为孤立机器人的无脑目标。 目前，大多数 AI 代理都是通过外部客户端或服务器端程序运行的，这使得网页开发在 AI 生态系统中被排除在外。我正在尝试一种“自内而外”的范式。通过将这个库放入页面中，你将获得一个客户端代理，它可以原生地与实时的 DOM 树进行交互，并且可以直接继承用户的活动会话，这对于单页应用（SPA）来说非常有效。 为了处理跨页面的任务，我构建了一个可选的浏览器扩展，它充当“桥梁”。这使得网页代理能够在明确的用户授权下控制整个浏览器。与其让桌面应用控制你的浏览器，不如让你的网页应用成为一个通用代理，能够在更广泛的网络中进行导航。 我很想开始讨论这种架构的可行性，以及大家对应用内通用代理未来的看法。欢迎提出任何问题！

嗨，HN，我开发了Sokuji，这是一个开源的实时语音翻译应用程序，既可以作为Electron桌面应用运行，也可以作为Chrome/Edge浏览器扩展使用。 最新版本（v0.15）增加了本地推理模式——完全在设备上进行的自动语音识别（ASR）、翻译和文本转语音（TTS），使用WASM和WebGPU。无需API密钥，无需互联网，数据不会离开您的设备。它包含： - 48种ASR模型，覆盖99种以上语言（sherpa-onnx WASM + Whisper WebGPU） - 55个以上的翻译语言对（Opus-MT），以及通过WebGPU支持的多语言大型语言模型（Qwen 2.5/3/3.5） - 136个TTS模型，涵盖53种语言（Piper, Coqui, Mimic3, Matcha） 对于喜欢云服务的用户，它还支持OpenAI实时API、Google Gemini Live、Palabra.ai、Volcengine ST、Doubao AST 2.0，以及任何与OpenAI兼容的端点。 该浏览器扩展与Google Meet、Teams、Zoom、Discord、Slack等集成——它可以捕获参与者的音频，并通过虚拟麦克风注入翻译后的语音。 技术栈：React + Zustand + Vite，Electron Forge，sherpa-onnx编译为WASM，HuggingFace Transformers.js用于WebGPU推理。模型按需下载并缓存于IndexedDB。 我开发这个工具是因为现有的翻译工具要么需要昂贵的API密钥，要么将您的音频发送到云端，或者不支持足够多的语言。本地推理模式使其适用于对隐私敏感的使用场景以及没有可靠互联网的人群。 采用AGPL-3.0许可证。可在Windows、macOS、Linux、Chrome Web Store和Edge附加组件中使用。 GitHub: [https://github.com/kizuna-ai-lab/sokuji](https://github.com/kizuna-ai-lab/sokuji) 官方网站: [https://sokuji.kizuna.ai](https://sokuji.kizuna.ai)

看起来 GitHub Actions 又出现故障了： https://www.githubstatus.com/ 我们已经使用 Blacksmith 来避免使用 GitHub Runners。如果你还没有尝试过，强烈推荐。不过，我们仍然依赖 GitHub 来实际触发工作流。考虑到他们频繁的故障，我在想是否有其他可用的替代方案？迁移到 GitLab 是一个相当大的工程，因此我想知道是否有办法暂时缓解这个问题，而不依赖 GitHub Actions 定期触发工作流和在某些操作（例如合并到主分支时）上触发工作流？

我创建了Entropy是为了针对一个特定问题：传统的API扫描器常常因为依赖静态攻击列表而忽视业务逻辑缺陷。Entropy利用大语言模型（LLMs）分析您的API架构（OpenAPI/GraphQL），并像对手一样思考，以生成定制的攻击序列。注意：我目前正在修复一个小的打包问题，因此“pip install”在接下来的几个小时内可能暂时不可用。与此同时，您可以通过克隆代码库直接从源代码运行它。我非常期待听到您的想法和反馈！

嗨，HN， 我觉得将 traceroute 绘制在地图上，直观地展示数据包的传输路径会很有趣。我知道这个想法之前已经有人做过，但我还是想尝试一下。 最初的版本只是让你粘贴一个 traceroute，然后在地图上绘制跳数。后来我发现了 Globalping（[https://globalping.io](https://globalping.io)），它允许你从全球的探测器运行 traceroute 和 MTR，因此我将其整合到了这个工具中。 在使用过程中，我注意到了一些有趣的事情： • 很容易发现不正确的 IP 地理定位。如果某个跳数显示延迟为 1-2 毫秒，但却看起来跨越了几个大陆，那么这个地理定位可能是错误的。 • 有时候，次优路由在视觉上比仅仅查看延迟数字更容易被注意到。 • 即使使用像 IPinfo 这样非常好的数据库，IP 地理定位仍然不是完美的，因此路径的某些部分有时可能会产生误导。 非常感谢 Globalping 和 IPinfo 背后的团队——Globalping 提供了测量基础设施，IPinfo 提供了地理定位数据。 欢迎反馈。

AI 编程代理可以生成不错的代码，但问题在于代码周围的一切——检查进度、捕捉偏差、判断是否真的完成。我花了几个月的时间尝试让自主代理正常工作，但瓶颈始终是我自己。 尝试 1 - Claude/GPT 直接使用：适用于小项目，但你需要不断重新解释上下文。 尝试 2 - Copilot/Cursor：自动补全效果很好，但仍然需要自己进行 95% 的思考。 尝试 3 - 持续代理：在没有提示的情况下持续工作，但“没有错误”并不意味着“功能正常”。 尝试 4 - 并行代理：时钟速度更快，但现在你需要手动审查更多的输出。 共同的问题是：没有人验证输出是否满足目标，而这个人一直是我。所以我自动化了这个工作。 OmoiOS 是一个基于规范驱动的编排系统。你描述一个功能，它会： 1. 运行一个多阶段的规范管道（探索 > 需求 > 设计 > 任务），使用 LLM 评估器对每个阶段进行评分。失败时重试，成功时推进。在代理编码之前，需求已经有了机器可检查的验收标准。 2. 为每个任务生成独立的云沙箱。你的本地环境不会受到影响。代理获得具有完整 git 访问权限的临时容器。 3. 持续验证——一个独立的验证代理会根据验收标准检查每个任务。失败会反馈以便重试。步骤之间没有人参与。 4. 发现新工作——当代理发现缺失的边缘案例时，验证可以生成新任务。随着代理的学习，任务图不断增长。 诚实地说，困难在于： - 规范质量是瓶颈。模糊的规范会导致代理无所作为。 - 验证是领域特定的。API 的正确性较易验证，但 UI 质量则不然。 - 发现分支可能会意外地增加任务图的复杂性。 - 沙箱开销为每个任务增加了延迟。虽然值得，但这是一个权衡。 - 合并具有实际冲突的并行分支是最困难的问题。 - 监控（每个代理的轨迹分析）仍然存在一些粗糙之处。 技术栈：Python/FastAPI，PostgreSQL+pgvector，Redis（约 19 万行）。Next.js 15 + React Flow（约 8.3 万行 TS）。Claude Agent SDK + Daytona Cloud。自 2025 年 11 月以来进行了 686 次提交，独立构建。Apache 2.0。 我不断回到同一个问题：结构化规范生成，能够产生真正机器可检查的验收标准。是否有人找到适用于非平凡功能的有效方法，还是这根本就是一个困难的问题？ GitHub: [https://github.com/kivo360/OmoiOS](https://github.com/kivo360/OmoiOS) 在线演示: [https://omoios.dev](https://omoios.dev)

我花了过去几年的时间来构建 AgnosticUI。最初它是一个以 CSS 为主的单一代码库，逻辑在不同框架的包中手动重复。这导致了维护上的噩梦。 最近，我完成了对其的全面重写，采用了 Lit，以符合网络标准并统一核心。一个主要的架构转变是转向“源优先”模型。与其将 UI 源代码放在 node_modules 中的黑箱里，不如将其置于本地项目工作区中。 这使得组件对大型语言模型（LLMs）完全可见，从而避免了 AI 在尝试猜测隐藏库 API 时常见的幻觉。我在 Frontend Masters 上撰写了一篇技术事后分析，详细说明了这次迁移的挑战（包括 Shadow DOM 可访问性、表单参与以及 @lit/react 与 React 19 的对比）：<a href="https://frontendmasters.com/blog/post-mortem-rewriting-agnosticui-with-lit-web-components/" rel="nofollow">https://frontendmasters.com/blog/post-mortem-rewriting-agnos...</a>