最新

大家好，HN。<p>我是滑铁卢大学的一名工程系学生，正在构建有状态的 AI 代理，我一直遇到同样的问题：每当我的 Python 脚本崩溃或断开连接时，底层的 Puppeteer 或 Ollama 进程就会一直孤零零地运行，占用 RAM，直到节点因内存溢出而自我终止。标准的负载均衡器会破坏粘性会话，而被动的 HTTP 超时对于清理来说又太慢了。<p>我找不到一个好的本地进程池，能够真正可靠地清理已死的有状态会话，所以我用 Go 语言构建了 Herd。<p>它使用一个持久流（gRPC/Unix 套接字）严格地作为“死亡男人开关”。如果你的客户端脚本死亡，流就会中断。Herd 会注册 EOF 并立即向工作进程发送 SIGKILL 信号（依赖于 Linux 上的 Pdeathsig）。对于实际的繁重数据，你只需通过 Herd 的内部代理发送 HTTP 流量，它会将流量直接路由到活动进程端口。<p>我的实际目标是将其变成一个多节点分布式网格，带有 Redis 注册中心，客户端可以退出，边缘网关会将它们路由回持有其有状态内存的确切 pod。<p>但我知道在有漏洞的本地引擎之上构建分布式网格是死路一条。单节点清理必须首先做到完美。<p>我很乐意让你们来“吐槽”这个架构。具体来说：在生产环境中，依赖 Pdeathsig 作为本地“死亡男人开关”是否足够健壮，还是我太天真了，现在就得咬紧牙关，把所有东西都封装在 cgroups 和微型虚拟机中？<p>代码库链接：<a href="https://github.com/herd-core/herd" rel="nofollow">https://github.com/herd-core/herd</a>

大家好，希望大家都安好！ 我看到很多评论和帖子，人们声称他们“真的”再也不写代码了，我很好奇大家在说这话时具体指的是什么。 我之所以这么说，是因为我每天都在使用 Claude 代码，而且是最高级套餐用户，所以我也不是在抨击 LLM 或者使用它们的人。我只是觉得很难理解，把 _所有_ 编码工作都外包出去怎么能提高生产力，尤其是在已有项目上。 我这么说的原因是，我经常需要调试和处理问题。通常，我的问题处理和诊断会让我发现，这个问题只需要几行代码就能简单修复。 当然，Claude 也可以修复这个问题，但提示、等待它给出方案、评估方案、等待它完成方案的实施，然后再评估工作，所花费的时间会比我快速做出更改并自己提交 PR 要长得多。 显然，也可以把问题处理和诊断也外包给 Claude，但我个人认为这没有效率，因为它最终会导致 LLM 更有可能出错，并更改代码库中不相关的部分。