一周热榜

想收集一些因为 AI 被解雇的人的故事。不是那种新闻稿里常见的、笼统的“组织架构调整”，而是真正因为 AI 被解雇的。有什么证据吗？

用 OpenClaw 运行 Anthropic API，一天就烧掉了大约 50 美元。<p>其他 OpenClaw 用户的情况如何？有人找到有效的降低成本的方法（模型分层、缓存等）吗？

大家好， 我正在开发 Persona，一个将邮件排程委托给 AI 的平台。最近，我一直在努力争取第一批用户，但这颇具挑战性。 我已经尝试了大家常说的那些典型策略：冷邮件、LinkedIn InMail、精准定向、不错的文案。但结果大多是死路一条。开信率低，几乎无人回复。 现在，我不想听那些在博客文章或 Reddit 上常见的建议。我特别想知道那些对你们早期有用的、非传统或不明显的策略，尤其是那些当时感觉有点草根、奇怪或违反直觉的策略。 如果你们经历过这个阶段，什么方法真正有效，并为你们带来了第一批用户？

还在看论坛的朋友们，你们好！ 我最近刚从大学毕业，开始担任初级开发工程师（目前正努力从资深同事那里汲取尽可能多的知识）。但似乎现实世界和大学里的实践大相径庭。 在大学里，我们学习了设计模式，以及领域层、应用层、基础设施层、UI层等各种职责。领域层不应依赖基础设施层或应用层，等等。但我在实际项目中遇到的情况是，领域层依赖于基础设施层，还有个项目应用层直接引用了基础设施层，而且他们还告诉我这是正确的实现方式…… 唉…… 我觉得我上课听得还不错，但现在我开始怀疑，学习这些东西到底值不值得，因为现实世界的情况如此矛盾。当然，我没有资格质疑资深开发人员，但你们觉得呢——大学里那些所谓的“最佳实践”真的都直接被扔进垃圾桶了吗？还是我只是误解了真实的工作环境？

“每请求的Token数” 这种计费模式对我们的生产环境来说一直具有误导性。真正的成本驱动因素似乎是以下几个乘数：重试/429错误、工具扇出、P95上下文增长以及安全检查。 在你的生产LLM系统中，最大的成本乘数是什么？哪些策略有效（限制、降级模式、回退、硬性失败）？

过去几天，我提交的任何链接都停留在“加载中”的转圈状态，似乎无法进入队列。而且，HN（Hacker News）上新文章的提交也没有发布任何存档链接。

我一直在努力让 NixBSD（Nix 包管理器 + FreeBSD）与 NixOS 在共享的 ZFS 存储池上一起启动。结果是一个 &lt;2GB 的磁盘镜像，你可以在 QEMU 或 virt-manager 中尝试。<p>目前可用的功能：<p><pre><code> - GRUB 链式加载 FreeBSD 的引导程序 - 两个系统共享一个 ZFS 存储池 - 所有内容都在一个 Nix flake 中定义 - 完全可复现的构建（一些依赖项现在缓存在 Cachix 上） </code></pre> 计划中的功能：<p><pre><code> - 支持 NixBSD 的原生编译（目前在 Linux 上交叉编译） - 为了使其工作，采取了许多捷径，需要大量清理 - 添加一个半自动安装程序，如 nixos-wizard </code></pre> 尝试一下：<p><pre><code> qemu-system-x86_64 -enable-kvm -m 2048 \ -bios &#x2F;usr&#x2F;share&#x2F;ovmf&#x2F;OVMF.fd \ -drive file=nixos.root.img,format=raw </code></pre> 登录：nixos&#x2F;nixos 或 root&#x2F;toor<p>最困难的部分是让挂载在启动时工作，使引导程序设置具有幂等性，以及调试早期初始化。这个磁盘镜像可能在 USB 闪存盘上也能工作，只需要做一些额外的工作。<p>这还处于实验阶段。我的目标是最终制作一个合适的 NixBSD 安装 ISO，并将所有配置整合到一个存储库中，同时仍然将上游 NixBSD 作为 flake 使用。<p>下载：<a href="https:&#x2F;&#x2F;github.com&#x2F;jonhermansen&#x2F;nixbsd-demo&#x2F;releases&#x2F;tag&#x2F;build-1" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonhermansen&#x2F;nixbsd-demo&#x2F;releases&#x2F;tag&#x2F;bui...</a><p>欢迎在此处或 GitHub 上留下反馈！谢谢！

大家好，我们是 Haakam、Michael 和 Adi。我们正在构建 AgentMail (<a href="https://agentmail.to">https://agentmail.to</a>)，这是面向智能体的电子邮件收件箱 API。我们谈论的不是为您的电子邮件提供 AI，而是为您的 AI 提供电子邮件。<p>电子邮件是长期运行智能体的最佳界面。它支持多线程和异步操作，并完全支持富文本和文件。它是一个通用协议，内置了身份验证功能。此外，许多工作流程关键上下文已经存在于电子邮件中。<p>我们希望构建电子邮件智能体，您可以将您的工作转发给它们，并获得已完成的任务。这些智能体可以完全自主地行动，因为您无需委托您的身份。如果它们遇到问题，它们可以向您或其他人发送电子邮件。<p>在使用 Gmail 时，我们一直受限于其 API 的局限性。无法以编程方式创建收件箱。速率和发送限制。每个收件箱都需要 OAuth 授权。关键词搜索无法理解上下文。按席位定价不适用于智能体。<p>因此，我们构建了我们希望存在的东西：一个面向开发人员的电子邮件提供商。用于创建收件箱和配置域的 API。电子邮件解析和线程化。从附件中提取文本。实时 Webhook 和 Websocket。跨收件箱的语义搜索。按使用量付费的定价模式，适用于智能体。<p>开发人员、初创企业和企业已经在部署使用 AgentMail 的电子邮件智能体。这些智能体可以将对话和文档转换为结构化数据。智能体可以获取报价、协商价格并获得最优惠的价格。智能体可以模拟互联网用户，用于在端到端任务上训练模型。<p>以下是 Clawdbots 使用 AgentMail 进行通信的演示：<a href="https://youtu.be/Y0MfUWS3LKQ" rel="nofollow">https://youtu.be/Y0MfUWS3LKQ</a><p>您可以在 <a href="https://agentmail.to">https://agentmail.to</a> 免费开始使用 AgentMail<p>期待听到您的想法和反馈。

大家好，我们是 TensorPool。我们帮助企业获取和优化大规模计算资源，用于训练基础模型。 **问题** 自从我们完成 YC 项目至今已近一年，我们的平台已经运行了超过 10 万个多节点训练 GPU 小时。 在这些训练运行中，我们见证了无数次凌晨 3 点的作业崩溃，原因包括来自不稳定 GPU 的 Xid 错误，或导致检查点保存损坏的 S3 超时。等你醒来注意到时，你已经损失了 8 个小时以上的计算时间。你赶紧诊断问题，手动从最后一个检查点重新启动，并希望它不会再次发生。周而复始。 对于需要数天甚至数周的训练运行来说，这种持续的看护既令人疲惫又昂贵。失去的研发迭代周期也可能决定一个模型的发布成败（尤其是在短时间预留的情况下）。 **我们构建了什么** 这个代理程序会监控你的训练作业，并在出现问题时自动恢复它们。它与 Kubernetes、Slurm 和 TensorPool 作业兼容。 我们最初构建 TensorPool Agent 是一个内部工具，用于帮助我们调试客户遇到的故障。随着时间的推移，我们意识到它的性能非常好，可以自动化整个故障诊断过程。我们现在正在发布一个公开测试版供大家使用。 最佳情况：TensorPool Agent 检测到故障，诊断根本原因，修复它，并从最后一个检查点重新启动你的作业——所有这些都在你睡觉的时候完成 ;)<p>最坏情况：如果 TensorPool Agent 无法自动修复问题，它会提供初步的根本原因分析（RCA）以及它尝试过的操作列表，让你在调试时抢占先机。 **工作原理** 1) 注册 – 你通过我们的仪表板提供作业调度程序的凭据。权限基于白名单授予；你明确控制代理可以执行的操作。 2) 监控 – 代理持续监控你的作业，以查找故障情况。 3) 恢复 – 发生故障时，代理会分析日志并尝试诊断问题。如果成功，它会从最后一个检查点重新启动作业并恢复监控。如果失败，你将收到带有完整上下文的警报。 **目标故障模式** 该代理程序专为训练深入进行时发生的运行时错误而设计，例如： - CUDA OOM：内存泄漏、梯度爆炸 - Xid 错误：GPU 硬件故障（Xid 79、63、48 等） - 分布式通信故障：NCCL 超时、秩失败 - 存储 I/O 错误：检查点损坏 - 网络问题：挂载对象存储上的 S3 请求超时