最新

嗨，HN，我创建了Ink，这是一个全栈部署平台，主要用户是AI代理，而不是人类。 我们都知道AI可以编写代码，但部署这些代码仍然需要人类来进行连接：托管、数据库、DNS和密钥。Ink直接为代理提供这些工具。 代理调用“部署”，平台会自动检测框架，构建它，部署它，并返回一个以*.ml.ink结尾的实时网址。这里有一个使用Claude Code的演示： [https://www.youtube.com/watch?v=F6ZM_RrIaC0](https://www.youtube.com/watch?v=F6ZM_RrIaC0)。 Ink提供了我在其他地方没有见过的功能： - 一个代理技能涵盖计算、数据库、DNS、密钥、域名、使用情况、指标、日志和扩展。代理不需要处理不同的服务提供商——一个账户、一个认证、一套工具。 - DNS区域委派。只需委派一个区域（例如dev.acme.com），代理就可以立即创建任何子域名——无需每次手动添加DNS记录，也不需要等待传播。 - 多个代理和人类共享一个工作空间并协作项目。我设想了一个未来，许多代理可以共同协作。我正在制作一个很酷的演示来分享。 - 内置的Git托管。代理可以推送代码并进行部署，而无需人类先设置GitHub。不需要外部账户。（当然，如果你是开发者，可以将代码存储在GitHub上——这是推荐的模式。） 你还会发现你所期望的功能： - 设计给人类使用的服务可观察性UI（日志、指标、DNS）。 - GitHub集成——推送触发自动重新部署。 - 按分钟计费的CPU、内存和出站流量。没有按席位计费，也没有按代理计费。 - 针对大型语言模型（LLMs）设计的错误响应。结构化的原因代码和建议的后续行动，而不是原始的堆栈跟踪。当部署失败时，代理会读取日志，修复问题，并自主重新部署。 试试吧：[https://ml.ink](https://ml.ink) 免费提供2美元的试用积分，无需信用卡。如果你想进一步尝试，这里有20%的优惠码“GOODFORTUNE”。

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)