最新

Thesys刚刚开源了他们的生成式用户界面渲染引擎。考虑到Google的a2ui和Vercel的json-render的发展方向，这个时机颇为有趣。值得注意的区别在于：a2ui和json-render都将JSONL视为大型语言模型（LLM）与渲染器之间的契约。而Thesys则认为这是错误的基础。他们的引擎使用类似代码的语法（OpenUI Lang）——由LLM编写，渲染器执行。其论点是，LLM在生成代码方面本质上比生成结构化数据更具优势，因此可以获得更干净的输出，并减少约67%的令牌使用量。 更广泛的愿景似乎是建立一个与模型无关、与设计系统无关的层，位于任何LLM与实际用户界面组件之间。用户可以自带组件和设计令牌，而引擎则负责将LLM的输出转换为渲染的界面——如图表、表单、表格和卡片。 作为一个类别，生成式用户界面仍在探索正确的抽象方式。这是对“JSON作为规范”这一观点的一个具体反对。

我本周深入研究了扩散语言模型，我认为这是目前人工智能领域中最被低估的方向。 自回归大型语言模型（LLMs）的核心问题： 如今的每个主要模型（如GPT、Claude、Gemini）都是一次生成一个标记，从左到右。每个标记都依赖于前一个标记。这一单一的架构限制塑造了整个人工智能行业： - 模型无法修改已生成的内容 → 我们构建了思维链、反思和多轮推理，迫使它们在“提交”之前进行思考。 - 每个标记只能进行一次前向传递 → 我们在推测解码、KV缓存和量化方面投入了大量资金，以使生成过程变得可接受。 - 无法在输出过程中进行编辑 → 我们构建了带有重试循环、工具调用和规划层的代理框架来绕过这一限制。 - 无法并行生成 → 我们构建了将多个缓慢调用串联在一起的协调系统。 我们今天所称的“人工智能工程”大部分都是围绕一个问题进行修补：模型无法回顾。 扩散语言模型颠覆了这一范式。它们从一个被遮蔽的标记画布开始，逐步并行地完善整个输出。每个位置同时更新，模型在每一步都能看到并编辑其所有输出。这一原理与图像扩散（如Stable Diffusion、DALL-E）相同，应用于文本。 我认为这一理论确实成立的原因： 1. 并行性是真实的，而非理论上的。Inception Labs的Mercury 2（闭源、基于扩散）已经在MMLU、HumanEval和MATH上的质量与GPT-4o mini相当，达到了约1000个标记每秒。这不是基准测试的技巧，而是因为没有受到顺序生成的瓶颈限制。 2. 复杂性大幅降低。如果模型能够一次性看到并编辑其整个输出，你就不需要我们构建的一半支架：反思提示变得原生（模型已经在自己的输出上进行迭代），重试循环变得不必要（就地编辑），规划代理变得更简单（模型可以重组，而不仅仅是附加）。整个架构变得扁平化。 3. 转换路径是存在的。你可以通过微调将现有的预训练自回归模型转换为扩散模型——无需从头开始预训练。这意味着已经在自回归预训练上投资的数十亿并没有浪费。这是一个升级路径，而不是重启。 目前的主要限制是：固定的输出长度。在生成开始之前，必须预先分配画布大小。块扩散（在顺序块中生成，在每个块内扩散）是一种解决方案。分层生成——先绘制大纲，再并行扩展各部分——是另一种方法。具有讽刺意味的是，协调这一过程需要一个代理，因此扩散并没有消灭代理，而是改变了它们的工作方式。 坦诚地说：开放的扩散语言模型在知识和推理方面仍然落后于同规模的顶级自回归模型。但Mercury 2显示出上限很高，转换结果令人惊讶地好，架构消除了整个类别的工程复杂性。我认为在一年内，我们将看到扩散模型与前沿自回归模型竞争，当那时，许多当前的工具（代理框架、提示工程技术、推理优化堆栈）将变得显著简单或不再必要。 在研究这一切时，我发现了dLLM，这是一个开源库，统一了扩散语言模型的训练、推理和评估。它提供了LLaDA、Dream、块扩散的配方，以及将任何自回归模型转换为扩散模型的工具。如果你想进行实验，这是一个不错的起点。 论文链接：[https://arxiv.org/abs/2602.22661](https://arxiv.org/abs/2602.22661) 代码链接：[https://github.com/ZHZisZZ/dllm](https://github.com/ZHZisZZ/dllm) 模型链接：[https://huggingface.co/dllm-hub](https://huggingface.co/dllm-hub)

你是如何度过你的日子的？几个月前，我还在提升技能并准备面试，但现在我已经失去了所有的动力。我对这一切都不感兴趣，人工智能已经彻底改变了整个生态，即使有人重新回到这个行业，一切似乎也都不再是过去的美好时光，而那些美好时光其实也并没有那么伟大。我比任何事情都更怀念有工资的日子，甚至是我曾经厌烦的每日站会，它们给了我结构和目标，而这些我现在无法替代。

嗨，HN，我 fork 了 Chromium，并构建了代理浏览器协议（ABP），因为我注意到大多数浏览器代理的失败并不是由于模型对页面的误解。相反，问题在于模型是基于过时的状态进行推理的。 ABP 的设计旨在确保代理在每一步都与浏览器保持同步。在每个操作（点击、输入等）之后，它会冻结 JavaScript 执行和渲染，然后捕获结果状态。它还会编译在该操作循环中发生的显著事件，例如导航、文件选择器、权限提示、警报和下载，并将这些信息连同冻结页面状态的截图一起发送回代理。 结果是，浏览器交互开始更像是一个多模态的聊天循环。代理采取行动，获取一个新的视觉状态和事件的结构化摘要，然后决定接下来该做什么。这与现代大型语言模型（LLMs）的工作方式更为契合。 ABP 有助消除的一些常见浏览器使用失败： * 在最后一次 Playwright 截图后出现模态窗口，阻塞了代理即将使用的输入 * 动态过滤器导致页面在步骤之间重新布局 * 自动完成下拉菜单打开并覆盖了代理打算点击的元素 * alert() / confirm() 中断了流程 * 下载被触发，但代理没有可靠的方法来知道何时完成 作为证明，使用 opus 4.6 作为驱动的 ABP 在 Online Mind2Web 基准测试中得分为 90.5%。我认为现代 LLM 已经理解网站，它们只需要一个更好的工具来与之互动。欢迎在下面的评论中提问关于架构、fork Chrome 或其他任何问题。 试试这个：`claude mcp add browser -- npx -y agent-browser-protocol --mcp`（文档中有 Codex/OpenCode 的说明） 演示视频： [https://www.loom.com/share/387f6349196f417d8b4b16a5452c3369](https://www.loom.com/share/387f6349196f417d8b4b16a5452c3369)

我在一个订阅上又开始遇到401错误，OAuth似乎在恢复会话方面遇到了困难。只有我这样吗？

我知道，这确实是一个非常发达国家的问题。但在我家，我们总是很难决定看什么。选择太多了！<p>所以我制作了这个工具，旨在为YouTube重现有线电视的体验。它可以在浏览器中运行。只需通过书签小工具快速导入你的订阅。无需账户，无需登录。只需快速在本地导入你的数据。

嘿，HN， 我开发了StreamHouse，这是一个开源流媒体平台，它用直接写入S3的方式替代了Kafka的代理管理存储。目标是：保持相同的语义，降低成本。 它是如何工作的：生产者批量并压缩记录，一个无状态的服务器管理分区路由和元数据（开发环境使用SQLite，生产环境使用PostgreSQL），而数据段直接存储在S3中。消费者通过本地段缓存从S3读取数据。无需管理代理磁盘，也不需要调整复制因子——S3提供了11个9的耐久性，开箱即用。 目前的功能包括： - 具有批处理、LZ4压缩和偏移量跟踪的生产者API（62K条记录/秒） - 具有消费者组、自动提交和多分区分发的消费者API（30K+条记录/秒） - 与Kafka兼容的协议（可与现有的Kafka客户端配合使用） - REST API、gRPC API、命令行接口和网页用户界面 - Docker Compose设置，可以在5分钟内本地试用 尚未实现的功能： - 经受考验的生产环境部署（目前只有我一个用户） - 连接器，供消费者立即连接（例如ClickHouse、Elasticsearch等） 成本模型是我开发这个平台的动力。Kafka的存储成本随着复制因子 × 保留时间 × 数据量而增加。使用S3，每GB每月$0.023，存储1TB事件的成本约为$23每月，而在代理EBS卷上则需要数百美元。 该项目使用Rust编写，目前有15个crate，采用Apache 2.0许可证。 GitHub链接：[https://github.com/gbram1/streamhouse](https://github.com/gbram1/streamhouse) 关于它是如何工作的博客在我的主网站上：[https://streamhouse.app/how-it-works](https://streamhouse.app/how-it-works) 欢迎提问有关架构、权衡或我在构建这个项目中学到的知识。