最新

嗨，HN， 我的团队和我正在构建 Tabstack，以处理 AI 代理的“网络层”。发布文章链接： [https://tabstack.ai/blog/intro-browsing-infrastructure-ai-agents](https://tabstack.ai/blog/intro-browsing-infrastructure-ai-agents) 维护一个复杂的网络浏览基础设施是构建可靠代理的最大瓶颈之一。你可能从一个简单的请求开始，但很快就会陷入管理复杂的代理堆栈、处理客户端的水合（hydration）以及调试脆弱的选择器，还要为每个网站编写自定义解析逻辑的麻烦中。 Tabstack 是一个抽象化该基础设施的 API。你只需发送一个 URL 和一个意图，我们负责渲染并返回干净、结构化的数据供大型语言模型（LLM）使用。 它的工作原理如下： - 升级逻辑：我们不会为每个请求启动一个完整的浏览器实例（这既慢又昂贵）。我们首先尝试轻量级的请求，只有在网站需要执行 JavaScript 或水合时才升级到完整的浏览器自动化。 - 令牌优化：原始 HTML 内容杂乱无章，会消耗上下文窗口的令牌。我们处理 DOM，去除非内容元素，返回一种适合 LLM 消费的 Markdown 友好结构。 - 基础设施稳定性：扩展无头浏览器 notoriously 困难（僵尸进程、内存泄漏、崩溃实例）。我们管理整个集群的生命周期和编排，这样你就可以在不维护底层网格的情况下运行数千个并发请求。 关于伦理：由于我们得到了 Mozilla 的支持，我们对与开放网络的互动非常严格。 - 我们遵守 robots.txt 规则。 - 我们标识我们的用户代理。 - 我们不使用请求/内容来训练模型。 - 数据是短暂的，任务完成后会被丢弃。 链接的文章详细介绍了基础设施以及我们为何认为浏览需要在 AI 堆栈中成为一个独立层的原因。 这显然是一个非常新的领域，我们都在共同学习。在代理浏览方面有很多已知的未知（可能还有更多未知的未知），因此我们非常欢迎你的反馈、问题和建议。 欢迎提问关于我们的堆栈、架构或构建浏览器基础设施的挑战。

我在想，传统的差异比较是否越来越不适合AI辅助开发了。 最近，在审查时，当AI生成大量更改时，我感到很沮丧。即使差异“很小”，也很难理解实际在行为或结构上发生了什么变化。 我开始尝试一种不同的方法：比较代码的两个快照（基线和当前），而不是直接比较行差异。每个快照捕捉到一个粗略的API形状和从抽象语法树（AST）派生的行为信号。目标不是进行深入的语义分析，而是快速地发出信号，表明是否有任何有意义的变化发生。 这种方法故意保持表面化和非评判性——只是信号，而不是裁决。 与此同时，我看到越来越多基于大型语言模型（LLM）的工具在帮助进行PR审查。用概率工具审查概率变化让我觉得有点危险。 我很好奇这里的其他人对此怎么看： – 对于AI生成的更改，差异比较仍然有效吗？ – 你们今天是如何审查大规模AI辅助重构的？

有些东西出现了故障，我还不知道具体是什么，但有些服务正在经历停机，Chess.com 不断发送请求但没有得到回应 :c

在过去的一年里，我一直在重新思考Tavus中人工智能如何管理对话的时机。我花了很多时间倾听对话。今天，我们宣布发布Sparrow-1，这是世界上最先进的对话流模型。 一些技术细节： - 预测对话的发言权，而不是语音结束点 - 原生音频流模型，无需依赖自动语音识别（ASR） - 人工定时的响应，没有基于静默的延迟 - 在中位延迟低于100毫秒的情况下零中断 - 在基准测试中，Sparrow-1在现实世界的轮流发言基准上超越了所有现有模型 我在这里写了更多关于这项工作的内容： [https://www.tavus.io/post/sparrow-1-human-level-conversational-timing-in-real-time-voice](https://www.tavus.io/post/sparrow-1-human-level-conversational-timing-in-real-time-voice)

无论是什么领域，无论大小，都没有关系。

我最近在经历了一段时间的创业后，开始了一份新工作。有些方面我真的很喜欢，有些则不然。<p>究竟是什么让人们随着时间的推移对工作产生厌恶？是薪资、同事还是企业文化？当人们提到“文化”时，这到底意味着什么？

Linux桌面已经花费了十多年时间在新的图形栈上进行过渡。Wayland带来了许多优势，尤其是在移动设备风格的安全性和简洁性方面。但在这个过程中，我们悄然失去了一些宝贵的东西：曾经使Linux图形模型独特的分布式、基于协议、与传输无关的理念。 这并不是怀旧。这些能力对于远程工作、自动化、多机器工作流、瘦客户端、云桌面以及未来的分布式系统至关重要。它们并不是“遗留特性”；而是可能再次变得重要的架构优势。 问题不在于Wayland本身，而在于它从未被设计来支持这些用例。它的理念是故意局限于本地、单用户和以合成器为中心。这对于移动设备来说是完全合理的，但对于桌面和分布式环境来说却留下了空白。 另一方面，Xorg面临的是一个老化的实现，而不是过时的理念。它的核心思想——基于协议的渲染、远程执行、可组合性和传输独立性——依然相关。我们缺乏的是一个现代的、简约的、仅基于协议的继任者，能够保留这些优势而不带有Xorg的历史包袱。 这样的项目不需要复制Xorg的全部功能集。它不需要服务器端渲染、字体、输入法、窗口管理或安全策略。它只需定义一个干净、现代的协议和一个稳定的抽象层。现有的合成器可以实现它，现有的驱动程序无需更改，Mesa也不需要进行重大重设计。工程工作量远小于重写整个图形栈。 这并不是呼吁取代Wayland，而是呼吁承认Linux桌面可能需要不止一种图形模型。一个以协议为先、与实现无关的层可以与Wayland共存，互为补充，并保留那些否则会消失的能力。 如果没有人开始这项工作，行业将自然趋向于移动风格的图形架构，而过去的分布式能力可能会被遗忘很长时间。但如果有人开始一个现代的、仅基于协议的Xorg继任者，社区或许最终会找到一种平衡简洁性与桌面曾经拥有的灵活性——而这种灵活性可能再次变得必要。