我喜欢算法，它让我感到耳目一新。然而，现在做算法就像是为了娱乐而做数学，我看不出它对我的日常工作有什么帮助 :(
返回首页
一周热榜
我认识的大多数开发者都转向了 Cursor 或 Codex。不过我还是时不时看到有人提到 Windsurf。
我理解为什么有人会继续使用它——JetBrains 的支持、稍微便宜一些、在大型代码库上表现不错。但在 Cognition 收购之后，我不太确定它的未来。
所以我真的很好奇，你还在使用 Windsurf 吗？是什么让你继续使用它？有没有什么让你后悔没有换的事情？
<a href="https://en.wiktionary.org/wiki/molly-guard" rel="nofollow">https://en.wiktionary.org/wiki/molly-guard</a>
他们的DNS解析已经严重下降超过2小时，影响了网站的正常访问，现在他们的状态页面也在随机崩溃。
https://status.godaddy.com
作为一个实验，我开始让Claude用虚构故事来向我解释事物，结果效果非常好。因此，我开始探索这个方法的极限，以及需要什么才能将其打磨到足以公开分享的程度。<p>在过去的几个月里，我为这个项目构建了世界观手册、撰写了视觉风格指南以及其他相关文档……可以把它们想象成我们现在用于代理开发的所有Markdown文件的虚构等价物。在此之后，我又花了大约两周的时间进行额外的打磨工作，以去除许多冗余内容和LLM特有的表达方式。如果有人对此过程感兴趣，我也很乐意回答任何问题。
我对在大型语言模型（LLM）时代，科技行业的人们是如何避免技能退化的很感兴趣。
我们都看到了这个争论的两种观点，一方面是“让他们退化，LLM是未来，看看算盘就知道了！”另一方面是“我不使用LLM，它们会出错并且妨碍工作”。但对许多人来说，现实是LLM确实提供了真正的性能提升，并承担了许多任务，即使它们会出错并需要人们的监督。
我倾向于谨慎对待技能的退化，因为在中长期内，LLM将如何影响工作场所以及哪些技能会被使用仍有太多未知。因此，我想知道你们是如何在面对“让它实现”的诱惑时，保持现有技能不退化的？
我构建了一个大小为6832字节的AI代理。整个运行时（包括二进制文件、桥接、工具和配置）大约为23KB。
PlanckClaw是用x86-64汇编语言编写的（显然是通过AI辅助代码生成的），仅使用了7个Linux系统调用。没有libc，没有分配器，没有运行时。这个二进制文件是一个纯路由器：它从命名管道读取消息，询问另一个管道有哪些工具，构建一个JSON提示，将其写入第三个管道，解析响应，调度工具调用，并转发答案。它从不接触网络或直接执行工具。
其他所有部分都通过shell脚本组合在一起（总共约460行）：
- bridge_brain.sh：调用Anthropic API（约90行）
- bridge_discord.sh：通过WebSocket连接Discord网关（约180行）
- bridge_cli.sh：终端接口（约40行）
- bridge_claw.sh：工具发现和调度（约50行）
四个进程，六个命名FIFO，零共享状态。添加一个工具意味着只需将一个shell脚本放入claws/目录中。无需重启、重新编译或更改配置。
它可以执行真实的操作：使用工具（通过Claude的tool_use协议）、以追加模式存储的持久对话历史（JSONL格式）、当历史记录过长时自动进行内存压缩，以及可更换的个性文件（soul.md）。
这一切始于一个思想实验：现代代理框架拉取超过400个传递依赖，并在生成一个令牌之前就需要发送超过100MB的运行时。我发现了多个极简主义的项目，如picoclaw、nanoclaw或zeroclaw。我想找到最小可行的代理（AI代理的普朗克长度），看看仅用管道和系统调用能构建出什么。
这不是生产软件。缓冲区是固定大小的（大于4KB的消息会被截断），它仅在Linux x86-64上运行，错误处理也很基础。但它运行得非常完美，整个代码库（包括汇编语言约2800行）也很容易审核。
如果你想编写自己的桥接，所有三个扩展点（交互、脑、爪）的线级协议规范都记录在PROTOCOL.md中。
大家好，我们是Jie Shen、Charles、Andreas和Shaocheng。我们开发了Chamber（<a href="https://usechamber.io">https://usechamber.io</a>），这是一个管理GPU基础设施的AI代理。您可以在团队已经使用的任何地方与它对话，它会处理集群配置、故障诊断、工作负载管理等任务。演示视频：<a href="https://www.youtube.com/watch?v=xdqh2C_hif4" rel="nofollow">https://www.youtube.com/watch?v=xdqh2C_hif4</a>
我们四个人都曾在亚马逊从事GPU基础设施的工作。我们在这个问题上花费了多年的时间——监控GPU集群、调试大规模故障、构建相关工具。在离开后，我们与许多AI团队进行了交流，发现大家面临着相同的问题。平台工程师一半的时间都在处理基础设施的日常运维：构建仪表板、编写调度配置、整天回答“我的工作什么时候开始？”等问题。当训练任务失败时，研究人员需要花费数小时来查找原因，因为这意味着要在完全不同的工具中查找Kubernetes事件、节点日志和GPU指标。几乎每个人都在拼凑Prometheus、Grafana、Kubernetes调度策略和一堆自制脚本，他们花在维护这些工具上的时间和实际使用它们的时间几乎是一样的。
我们注意到，这些工作大多遵循一定的模式。首先对故障进行分类，关联一些信号，然后找出解决方案。如果您有一个平台，可以结构化地访问GPU环境的完整状态，您就可以让代理为您完成这些工作。
这就是我们所构建的。Chamber是一个控制平面，实时维护您的GPU集群模型：节点、工作负载、团队结构、集群健康。它支持的每个操作都被暴露为代理可以调用的工具。检查节点健康、读取集群拓扑、管理工作负载生命周期、调整资源配置、配置基础设施。这些都是经过验证和回滚的结构化操作，而不仅仅是原始的Shell命令。当我们向平台添加新功能时，它们也会自动成为代理可以执行的任务。
我们在安全性方面花了很多时间，因为我们见证了基础设施自动化出错时的后果。一个错误的调用可能会导致多天的训练任务中断，或者在集群中引发连锁反应。因此，代理具有渐进式自主权。常规任务由它自行处理：诊断失败的工作、使用更正的资源重新提交、隔离故障节点。但任何涉及其他团队工作负载或生产任务的操作都需要先获得人工批准。每个操作都会记录代理所看到的内容、其行动原因以及所做的更改。
底层平台实际上使得故障诊断得以实现。当代理调查故障时，它会查询GPU状态、工作负载历史、节点健康时间线和集群拓扑。这就是“您的工作因内存不足而失败”和“您的工作因批量大小超过该节点可用的VRAM而失败，这里是更正的配置。”之间的区别。不同的根本原因需要不同的解决方案。
让我们感到惊讶的是，即使我们来自亚马逊，见过大型GPU集群，许多团队仍然无法告诉您现在有多少GPU在使用。监控根本不存在。他们在最昂贵的硬件上“盲飞”。
我们已经与一些早期客户启动了合作，并正在为新团队提供服务。我们仍在完善定价，目前正在评估按管理GPU数量计费和分级计划等模型。我们计划在验证最适合客户的方案后发布透明的定价信息。与此同时，我们知道“联系我们”并不是理想的选择。
我们非常希望听到任何运行GPU集群的人的反馈。您设置中最繁琐的部分是什么？您希望代理实际执行哪些任务？有哪些是禁止的？期待您的反馈！
每个评论线程都变成了这样：<p>> 关于X的想法<p>>> X很棒，但请看看我在GitHub上的糟糕项目。
我从来没有能够坚持写日记。尝试过纸质笔记本、日记应用和每日模板。总是同样的情形：一周的热情，然后就没下文了。最忙碌的日子最先消失，因为我忙于生活，根本没时间写下任何东西。
某个时刻，我注意到我已经在不经意间记录着我的生活。我的日历上有每一个会议，Slack上有每一次对话，GitHub上有每一次提交。原材料都在，只是散落在十几个API中。因此，我写了一套收集器和一个定时任务，每天早上将这些信息汇总，并利用大型语言模型（LLM）从原始数据中生成日记条目。
最近，我与OpenClaw的对话也被记录在日记中，老实说，那些是一些最精彩的条目。那些傻乎乎的来回对话，还有我在凌晨两点问的问题。这种事情我自己绝对不会写下来，但在一年后再读时一定会很喜欢。
这个原型运作得相当不错，我希望其他人也能使用它。这意味着要将一个个人的定时任务转变为一个能够可靠处理多个用户、多个集成和多个时区的管道，每天早上都能正常运行。这才是真正的复杂之处，也是我过去一个月以来一直在构建的内容。
服务网站： [https://deariary.com](https://deariary.com)
由deariary本身生成的公开开发日记：[https://app.deariary.com/u/deariaryapp](https://app.deariary.com/u/deariaryapp)
很高兴能谈论这个方法或其他任何事情。
附言：我连接了我的Steam账号，日记随意提到我已经连续好几个星期每天玩《超级拼图生成器》60到120分钟。我完全不知道我在做这个。这个应用真是个告密者。