一周热榜

大多数文件转换网站会将你的文件上传到它们的服务器。File Converter Free 使用 WebAssembly 在客户端运行所有操作——你的文件永远不会离开你的设备。 支持 215 种以上的格式转换和压缩，75 种以上的基于浏览器的工具，包括 PDF、开发工具、文本、计算器和网络诊断——所有这些都提供 9 种语言版本。 我独自完成了这个项目。你希望哪些工具能在客户端运行，但目前还不能呢？ [https://file-converter-free.com/en/tools](https://file-converter-free.com/en/tools)

适用于商业网站的可嵌入地图小部件。只需一个脚本标签，无需谷歌账号，不使用 Cookie。<p>OpenStreetMap 地图瓦片通过 Protomaps PMTiles 从 Cloudflare R2 提供。整个服务层在边缘运行，无需瓦片服务器。基础设施成本约为每月 7 欧元，与流量无关，因为 R2 没有出口费用。<p>构建它的原因是，在欧洲嵌入谷歌地图会带来 GDPR 合规问题（Cookie、第三方域名、同意障碍），而且它们会在你的网站上显示你的竞争对手。

大家好，我是 Budibase 的 Mike。<p>继我们现有的开源应用构建和自动化工具之后，我们最近推出了 AI Agents 的 Beta 版。<p>我们构建 Budibase Agents 是为了帮助团队在实际工作流程中利用 AI，使用他们自己的 LLM、数据和 API。因此，我们的 Agents 可以由任何具有 OpenAI 兼容 API 的 LLM 提供支持，包括开源和本地托管的模型。这意味着您可以构建连接到现有工具栈的 Agents，并在您自己的环境中运行。<p>更多详细信息： - Agents 的行为在现有的 Budibase 工作区中使用自然语言指令进行配置。 - 您可以明确控制 Agent 可以访问哪些数据源、API 和自动化。 - 最终用户可以通过 Budibase Chat 或使用现有的聊天工具（如 Slack 和 Discord）与您的 Agents 交互。 - Agents 可以从 Automations 中调用，反之亦然，从而实现复杂的工作流程，包括与最终用户应用程序交互以进行手动人工审批。<p>Budibase Agents Beta 版现已向所有自托管和云用户开放。<p>由于这是 Beta 版发布，我们正在积极寻求关于如何改进 Agents 的意见和反馈，包括在实际工作流程中使用 AI 进行构建的体验和功能方面。<p>欢迎通过我们的 GitHub 讨论区告诉我们：<a href="https:&#x2F;&#x2F;github.com&#x2F;budibase&#x2F;budibase&#x2F;discussions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;budibase&#x2F;budibase&#x2F;discussions</a>

不知道这场战争会不会迫使公司重新推行居家办公，以应对油价上涨和燃油供应问题。如果加油站没油或者要等一个小时才能加到油，上班就太难了。

我认识的大部分开发者都转向了 Cursor 或 Codex。但偶尔还能看到有人提到 Windsurf。<p>我理解为什么有人会继续使用它——JetBrains 的支持、价格稍低、对大型代码库表现不错。但在 Cognition 收购之后，我不确定它是否还有未来。<p>所以，我真心好奇，你们还在用 Windsurf 吗？是什么让你们坚持使用它的？有没有什么让你们后悔没有切换的？

我喜欢算法，它让我感觉很新鲜。但现在做算法就像是纯粹为了乐趣而做数学，我看不出它对我的日常工作有什么帮助 :(

作为一次实验，我开始让 Claude 用虚构故事来向我解释事情，结果效果非常好。于是我开始探索能做到什么程度，以及需要多少打磨才能公开分享。<p>在过去的几个月里，我一直在为这个项目构建世界设定、撰写视觉风格指南和其他文档……可以把它想象成所有我们现在用于智能体开发的 Markdown 文件的虚构版本。在那之后，又花了大约两周的时间进行额外的润色，以去除大量冗余内容和 LLM 的“机器味”。如果有人感兴趣的话，我很乐意回答关于这个过程的任何问题。

我对科技行业从业者在当前大语言模型（LLM）时代如何避免技能退化很感兴趣？ 我们都听过两种截然不同的观点，一种是“让他们退化吧，LLM才是未来，看看算盘就知道了！”；另一种是“我不使用LLM，它们会犯错，还会碍事”。但对许多人来说，现实情况是，即使LLM会犯错，需要人工干预，它们也能真正提高工作效率，并承担许多任务。 我倾向于谨慎对待技能落后。LLM在中长期内对工作场所的推动作用以及未来会用到哪些技能，都存在太多未知因素。所以，我想知道，当面对“一键生成”的诱惑时，你们是如何防止现有技能退化的？

他们的 DNS 解析已经严重退化超过 2 个小时，影响了网站访问，现在他们的状态页面也随机崩溃。 https://status.godaddy.com

大家好，我们是沈杰、Charles、Andreas 和 Shaocheng。我们开发了 Chamber (<a href="https:&#x2F;&#x2F;usechamber.io">https:&#x2F;&#x2F;usechamber.io</a>)，一个为您管理 GPU 基础设施的 AI 智能体。您可以在团队已经使用的任何地方与它对话，它会处理诸如配置集群、诊断失败作业、管理工作负载等任务。演示：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xdqh2C_hif4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=xdqh2C_hif4</a> 我们都曾在亚马逊从事 GPU 基础设施方面的工作。我们加起来花了数年时间解决这个问题——监控 GPU 资源池、大规模调试故障、构建相关的工具。离职后，我们与许多 AI 团队交流，并不断听到同样的问题。平台工程师们把一半的时间都花在维护系统运行上。他们整天都在构建仪表盘、编写调度配置、回答“我的作业什么时候开始？”之类的问题。研究人员会因为训练运行失败而损失数小时，因为要找出原因，就得在完全不同的工具中翻阅 Kubernetes 事件、节点日志和 GPU 指标。几乎每个人都拼凑了 Prometheus、Grafana、Kubernetes 调度策略以及一堆自制的脚本，而且他们花在维护所有这些东西上的时间，与实际使用它们的时间一样多。 我们一直注意到的是，大多数这类工作都遵循一定的模式。对故障进行分类，关联一些信号，然后确定如何处理。如果您有一个平台，可以结构化地访问 GPU 环境的完整状态，那么您就可以让一个智能体来为您完成这项工作。 所以，这就是我们构建的东西。Chamber 是一个控制平面，它维护着您的 GPU 资源池的实时模型：节点、工作负载、团队结构、集群健康状况。它支持的每个操作都作为智能体可以调用的工具公开。检查节点健康状况、读取集群拓扑、管理工作负载生命周期、调整资源配置、配置基础设施。这些都是具有验证和回滚功能的结构化操作，而不仅仅是原始的 shell 命令。当我们向平台添加新功能时，它们也会自动成为智能体可以执行的任务。 我们花了很多时间在安全性上，因为我们已经看到了基础设施自动化出错时会发生什么。一个错误的调用可能会中断一个为期数天的训练运行，或者在整个集群中引发连锁反应。因此，智能体具有渐进的自主性。它会自行处理日常事务：诊断失败的作业、使用更正后的资源重新提交、隔离故障节点。但是，任何涉及到其他团队的工作负载或生产作业的操作都需要先获得人工批准。每个操作都会记录智能体看到了什么、它为什么采取行动以及它更改了什么。 底层的平台才是真正让诊断工作发挥作用的关键。当智能体调查故障时，它会查询 GPU 状态、工作负载历史记录、节点健康状况时间线和集群拓扑。这与“您的作业 OOM”和“您的作业 OOM 是因为批处理大小超出了此节点上可用的 VRAM，这里有一个更正后的配置”的区别在于根本原因的不同，会得到不同的修复方案。 有一件事让我们感到惊讶，即使我们来自亚马逊，在那里我们见过大型 GPU 资源池：我们交谈过的大多数团队甚至无法告诉您现在正在使用多少个 GPU。监控根本不存在。他们对他们最昂贵的硬件一无所知。 我们已经与一些早期客户合作并正在为新团队提供支持。我们仍在完善定价，目前正在评估按 GPU 管理和分层计划等模式。我们计划在验证了哪种方案最适合客户后，发布透明的定价。与此同时，我们知道“联系我们”并不是一个理想的选择。 很乐意听取任何运行 GPU 集群的人的意见。您设置中最繁琐的部分是什么？您实际上会信任智能体做什么？哪些是禁区？期待您的反馈！

我构建了一个 AI 智能体，大小仅为 6,832 字节。整个运行时环境（二进制文件、桥接器、工具、配置）大约 23 KB。<p>PlanckClaw 用 x86-64 汇编语言编写（显然，这部分代码是 AI 辅助生成的），并且仅使用了 7 个 Linux 系统调用。没有 libc，没有分配器，没有运行时环境。这个二进制文件是一个纯粹的路由器：它从命名管道读取消息，询问另一个管道存在哪些工具，构建一个 JSON 提示，将其写入第三个管道，解析响应，分发工具调用，并转发答案。它从不触及网络，也不直接执行工具。<p>其他所有东西都通过 shell 脚本组合在一起（总共约 460 行）： - bridge_brain.sh：使用 curl 调用 Anthropic API（约 90 行） - bridge_discord.sh：通过 WebSocket 连接 Discord 网关（约 180 行） - bridge_cli.sh：终端界面（约 40 行） - bridge_claw.sh：工具发现和分发（约 50 行）<p>四个进程，六个命名 FIFO，零共享状态。添加一个工具意味着在 claws/ 目录下放置一个 shell 脚本。无需重启，无需重新编译，无需更改配置。<p>它能做真正的事情：工具使用（通过 Claude 的 tool_use 协议），在仅追加的 JSONL 文件中持久保存对话历史，当历史记录过长时自动进行内存压缩，以及可替换的个性文件（soul.md）。<p>这最初是一个思想实验：现代智能体框架在生成单个 token 之前，会引入 400 多个传递依赖项，并占用 100 多 MB 的运行时环境。我偶然发现了多个极简主义项目，例如 picoclaw、nanoclaw 或 zeroclaw。我想找到最小可行的智能体（AI 智能体的普朗克长度），看看仅使用管道和系统调用能构建出什么。<p>这不是生产级软件。缓冲区是固定大小的（消息超过 4 KB 会被截断），它仅在 Linux x86-64 上运行，并且错误处理很基础。但它运行完美，并且整个代码库（包括汇编语言，约 2,800 行）很容易审计。<p>如果你想编写自己的桥接器，所有三个扩展点（交互、大脑、爪子）的线级协议规范都记录在 PROTOCOL.md 中。

<a href="https://en.wiktionary.org/wiki/molly-guard" rel="nofollow">https://en.wiktionary.org/wiki/molly-guard</a>

每个评论区都变成了这样：<p>&gt; 关于 X 的想法<p>&gt;&gt; X 很棒，但来看看我在 GitHub 上的垃圾 vibecoded 项目吧