最新

嘿，HN。 我是一名在滑铁卢大学学习的工程学生，正在构建有状态的人工智能代理，但我一直遇到同样的问题：每当我的 Python 脚本崩溃或断开连接时，底层的 Puppeteer 或 Ollama 进程就会孤立无援地存在，占用内存，直到节点因内存不足被杀掉。标准的负载均衡器会破坏粘性会话，而被动的 HTTP 超时又太慢，无法及时清理。 我找不到一个能够可靠清理死掉的有状态会话的本地进程池，所以我用 Go 构建了 Herd。 它使用持久化的流（gRPC/Unix 套接字）作为一个死人的开关。如果你的客户端脚本崩溃，流就会中断。Herd 会注册 EOF，并立即向工作进程发送 SIGKILL（在 Linux 上依赖 Pdeathsig）。对于实际的大量数据，你只需通过 Herd 的内部代理发送 HTTP 流量，代理会将其直接路由到活动进程的端口。 我真正的目标是将其转变为一个多节点的分布式网格，配备 Redis 注册表，客户端可以掉线，边缘网关将其路由回持有其有状态内存的确切 pod。 但我知道在一个有漏洞的本地引擎上构建分布式网格是自杀行为。单节点的清理必须首先做到完美。 我希望你们能对这个架构进行批评。具体来说：依赖 Pdeathsig 作为本地死人的开关在生产环境中是否足够稳健，还是我太天真了，需要咬紧牙关，把一切都包裹在 cgroups 和微虚拟机中？ 代码库链接：[https://github.com/herd-core/herd](https://github.com/herd-core/herd)

大家好，希望大家都很好！<p>我看到很多评论和帖子，人们表示他们“根本”不再写代码了，我对此感到好奇，想知道大家在说这句话时是什么意思。<p>我之所以这样说，是因为我每天都在使用Claude代码，且使用的是高级计划，所以我并不是在批评大型语言模型（LLMs）或使用它们的人。我只是觉得很难理解将_所有_编码工作都外包出去，尤其是在已有项目上，如何能提高生产力。<p>我这样说的原因是，我经常需要调试和处理问题。通常我的处理和诊断会让我发现，问题其实是可以用几行代码简单修复的。<p>当然，Claude可以解决这个问题，但从提示、等待它输出计划、评估该计划、等待它完成实施，再到评估工作所花的时间，显然会比我自己快速修改并提交PR要长得多。<p>当然，也可以将处理和诊断的工作完全交给Claude，但我个人觉得这样效率不高，因为这很可能导致大型语言模型出现问题，修改与代码库无关的部分。