一周热榜

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

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

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

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

我构建了一个 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 中。

大家好，我们是沈杰、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 集群的人的意见。您设置中最繁琐的部分是什么？您实际上会信任智能体做什么？哪些是禁区？期待您的反馈！

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

我从未能坚持写日记。试过纸质笔记本、日记应用、每日模板。结果总是相同的：坚持一周，然后就没了。最忙碌的日子最先消失，因为我忙于生活，根本没时间写下任何东西。 后来我注意到，我已经在不知不觉中记录我的生活了。我的日历里有每一次会议。Slack 里有每一次对话。GitHub 里有每一次提交。原始材料都在那里，只是分散在十几个 API 中。所以我写了一组收集器和一个 cron 任务，每天早上将所有数据整合在一起，并让一个 LLM（大型语言模型）根据原始数据写一篇日记。 最近，我与 OpenClaw 的对话也出现在了日记里，说实话，这些是最好的条目之一。那些傻乎乎的来回对话，凌晨两点我问的问题。这些是我永远不会自己写下来的东西，但一年后会喜欢重读。 这个原型运行得很好，我想让其他人也能使用它。这意味着要把一个个人 cron 任务变成一个管道，每天早上可靠地处理多个用户、多个集成和多个时区。这才是真正的复杂所在，也是我过去一个月一直在构建的东西。 服务网站：<a href="https:&#x2F;&#x2F;deariary.com" rel="nofollow">https:&#x2F;&#x2F;deariary.com</a> 由 deariary 自身生成的公开开发日记：<a href="https:&#x2F;&#x2F;app.deariary.com&#x2F;u&#x2F;deariaryapp" rel="nofollow">https:&#x2F;&#x2F;app.deariary.com&#x2F;u&#x2F;deariaryapp</a> 很乐意讨论这个方法或任何其他问题。 附注：我连接了我的 Steam 账号，我的日记随意提到我连续几周每天都在玩《超级拼图世代》60-120 分钟。我不知道我一直在这么做。这个应用真是个告密者。

我花了几个星期的时间，整理了关于人工智能（AI）在职场应用方面的纵向研究的实际发现，而不是像大多数报道中那样乐观地看待生产力提升。