最新

我们是 Bailey 和 Robbie，我们正在开发 Klaus (<a href="https:&#x2F;&#x2F;klausai.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;klausai.com/</a>)：一个开箱即用、安全且强大的托管 OpenClaw 平台。<p>运行 OpenClaw 需要设置云虚拟机或本地容器（很麻烦），或者授予 OpenClaw 对您机器的 root 访问权限（不安全）。许多基本集成（例如 Slack、Google Workspace）需要您创建自己的 OAuth 应用程序。<p>我们通过为每个用户提供自己的 EC2 实例来简化 OpenClaw 的运行，这些实例预先配置了 OpenRouter、AgentMail 和 Orthogonal 的密钥。我们还拥有 OAuth 应用程序，以便于与 Slack 和 Google Workspace 集成。<p>我们都是 HN 读者（Bailey 在这里已经有大约 10 年了），我们知道 OpenClaw 存在严重的安全性问题。我们做了很多工作来提高用户实例的安全性：我们在私有子网中运行，自动更新用户运行的 OpenClaw 版本，并且由于您默认在我们的虚拟机上，如果被黑客攻击，您泄露的唯一密钥属于我们。连接您的电子邮件仍然存在风险。我所知道的最佳防御方法是使用 Opus 4.6 来抵抗提示注入。如果您有更好的解决方案，我们很乐意听取！<p>在过去的一个月里，我们学到了很多关于基础设施管理的知识。Kimi K2.5 和 Mimimax M2.5 极擅长于幻觉出破坏 openclaw.json 的新方法，或者对 EC2 实例造成其他破坏。在发布后的一周，我们花了 20 多个小时手动修复损坏的机器。<p>我们在用户的 AGENTS.md 中编写了大量关于在 AWS Linux 上使用 OpenClaw 的最佳实践，非常擅长通过 SSM 修复 EC2 机器，为每个实例添加了一个命令和控制服务器以方便热修复和迁移，并设置了一个 Klaus 实例来回答 Discord 上的常见问题。<p>除了所有这些，我们还构建了 ClawBert，我们的 AI SRE，用于自动热修复 OpenClaw 实例：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=v65F6VBXqKY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com/watch?v=v65F6VBXqKY</a>。Clawbert 是一个 Claude Code 实例，每当健康检查失败或用户在 UI 中触发它时运行。它可以读取用户在我们的数据库中的条目，并在用户的实例上执行命令。我们向用户公开 Clawbert 的运行日志。<p>我们知道对于大多数 HN 读者来说，设置 OpenClaw 很容易，但我保证对于大多数人来说并非如此。Klaus 还有很长的路要走，但看到从未用过 Claude Code 的人第一次体验 AI 代理仍然非常有意义。<p>我们对 t4g.small 收费 19 美元/月，对 t4g.medium 收费 49 美元/月，对 t4g.xlarge 收费 200 美元/月，并提供优先支持。您将获得 15 美元的代币和 20 美元的 Orthogonal 积分（一次性）。<p>我们想知道您正在 OpenClaw 上构建什么，以便我们确保支持它。我们已经与 Orthogonal 和 Openrouter 等公司合作，这些公司正在构建使代理更有用的东西，我们确信还有更多我们不知道的工具。如果您构建了代理想要的东西，请告诉我们。欢迎评论！

大家好，我是 Ink 的开发者，Ink 是一个全栈部署平台，主要用户是 AI 智能体，而不是人类。 我们都知道 AI 可以编写代码，但部署它们仍然需要人类来配置：托管、数据库、DNS 和密钥。Ink 直接为智能体提供了这些工具。 智能体调用“deploy”，平台会自动检测框架、构建、部署，并返回一个 *.ml.ink 的实时 URL。这里有一个使用 Claude Code 的演示：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F6ZM_RrIaC0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F6ZM_RrIaC0</a>。 Ink 的独特之处在于： - 一个智能体技能包，涵盖计算 + 数据库 + DNS + 密钥 + 域名 + 使用情况 + 指标 + 日志 + 扩展。智能体无需处理不同的提供商——一个账户，一个身份验证，一套工具。 - DNS 区域委托。只需委托一次区域（例如 dev.acme.com），智能体即可立即创建任何子域名——无需每次手动添加 DNS 记录，无需等待传播。 - 多个智能体和人类共享一个工作区，并协作完成项目。我设想一个未来，许多智能体可以一起协作。我正在努力开发一个很棒的演示，稍后分享。 - 内置 Git 托管。智能体可以推送代码并部署，无需人类先设置 GitHub。无需外部账户。（当然，如果您是开发人员，您可以将代码存储在 GitHub 上——这是推荐模式。） 您还可以获得您期望的功能： - 专为人类设计的 UI，具有服务可观察性（日志、指标、DNS）。 - GitHub 集成——推送触发自动重新部署。 - 按分钟计费 CPU、内存和出口流量。没有按席位，没有按智能体。 - 专为 LLM 设计的错误响应。结构化的原因代码，并提供建议的后续操作，而不是原始的堆栈跟踪。当部署失败时，智能体会读取日志，修复它，并自主地重新部署。 试用：<a href="https:&#x2F;&#x2F;ml.ink" rel="nofollow">https:&#x2F;&#x2F;ml.ink</a> 免费提供 2 美元的试用积分，无需信用卡。如果您想进一步尝试，这里有一个 8 折优惠码“GOODFORTUNE”。

Thesys 刚刚开源了他们的生成式 UI 渲染引擎。考虑到 Google 的 a2ui 和 Vercel 的 json-render 的发展方向，这个时间点很有意思。 值得注意的是，a2ui 和 json-render 都将 JSONL 作为 LLM 和渲染器之间的契约。而 Thesys 认为这并非最佳选择。他们的引擎使用类似代码的语法（OpenUI Lang）—— LLM 编写，渲染器执行。他们的论点是，LLM 在生成代码方面比生成结构化数据更擅长，因此可以获得更清晰的输出，并减少约 67% 的 token 数量。 更广阔的愿景似乎是一个与模型无关、与设计系统无关的层，位于任何 LLM 和您的实际 UI 组件之间。您提供自己的组件和设计 token，引擎负责将 LLM 的输出转换为渲染的界面——图表、表单、表格、卡片。 生成式 UI 作为一个类别，仍在探索正确的抽象方式。 这标志着对 JSON 作为规范的明确挑战。

这周我一直在深入研究扩散语言模型，我认为这是目前 AI 领域被低估的方向。<p>自回归 LLM 的核心问题：<p>当今所有主流模型（GPT、Claude、Gemini）都一次生成一个 token，从左到右。每个 token 都依赖于前一个。这种单一的架构约束塑造了整个 AI 行业：<p>- 模型无法修改已写内容 → 我们构建了思维链、反思和多轮推理，迫使它们“三思而后行” - 每个 token 都需要一次前向传播 → 我们大力投资于推测性解码、KV 缓存和量化，以使生成过程可以接受 - 无法在输出中间进行编辑 → 我们构建了带有重试循环、工具调用和规划层的代理框架来解决这个问题 - 无法并行生成 → 我们构建了编排系统，将多个缓慢的调用链接在一起<p>我们今天所称的“AI 工程”的大部分工作都是在修补一件事：模型无法回溯。<p>扩散 LM 颠覆了这种范式。从一个被掩码的 token 画布开始，迭代地并行优化整个输出。每个位置同时更新，模型在每一步都能看到并编辑其所有输出。这与图像扩散（Stable Diffusion、DALL-E）的原理相同，应用于文本。<p>为什么我认为这个理论实际上是成立的：<p>1. 并行性是真实的，而非理论上的。Inception Labs 的 Mercury 2（闭源，基于扩散）在 MMLU、HumanEval、MATH 上的质量与 GPT-4o mini 相当，速度已达到约 1000 tok/s。这并非基准测试的技巧——这是没有被顺序生成所限制的直接结果。 2. 复杂性降低是巨大的。如果一个模型可以一次查看并编辑其所有输出，那么你就不需要我们构建的一半脚手架：反思提示变得原生（模型已经在迭代自己的输出），重试循环变得不必要（就地编辑），规划代理变得更简单（模型可以重组，而不仅仅是追加）。整个堆栈被简化。 3. 转换路径是存在的。你可以使用现有的预训练 AR 模型，仅通过微调将其转换为扩散模型——无需从头开始预训练。这意味着已经投入数十亿美元用于 AR 预训练的资金不会被浪费。这是一个升级路径，而不是重新开始。<p>目前的主要限制：固定输出长度。你必须在生成开始之前预先分配画布大小。块扩散（在每个块内进行扩散，顺序生成块）是一种解决方法。分层生成——先概述，然后并行展开各部分——是另一种方法。具有讽刺意味的是，编排它需要一个代理，所以扩散并没有杀死代理——它改变了它们的工作方式。<p>诚实地说：在可比规模下，开放扩散 LM 在知识和推理方面仍然落后于顶级的 AR 模型。但 Mercury 2 表明上限很高，转换结果出奇地好，并且该架构消除了整个类别的工程复杂性。我认为在一年之内，我们将看到扩散模型与前沿的 AR 模型竞争，当这种情况发生时，许多当前的工具（代理框架、提示工程技术、推理优化堆栈）将变得非常简单或不必要。<p>在研究这一切的过程中，我发现了 dLLM，这是一个开源库，它统一了扩散 LM 的训练、推理和评估。它有 LLaDA、Dream、块扩散的配方，以及将任何 AR 模型转换为扩散模型的方法。如果你想尝试，这是一个很好的起点。<p>论文：https://arxiv.org/abs/2602.22661<p>代码：https://github.com/ZHZisZZ/dllm<p>模型：https://huggingface.co/dllm-hub<p>你有什么看法？