最新

大家好！<p>我开发了一个小工具，用于可视化 `docker pull` 的低效性，以便为建立新的 Docker 注册中心和传输做好准备。很长一段时间以来，我一直对使用 Docker 更新一个依赖项时会牵扯到许多其他更改感到困扰。这在 Docker 和机器人技术中是一个巨大的问题。对于几十个或几百个依赖项来说，没有一种“正确”的方式来组织层，这样在更新单个依赖项时就不会使一堆层失效——而且这还不包括编译代码、嵌入的机器学习权重等问题。更糟糕的是，许多机器人部署都在糟糕的网络环境下进行，要么是因为身处偏远地区，要么是由于客户的各种捣乱。我曾经在凌晨4点支持一位现场技术人员，他需要在1Mbps的连接下将100MB大部分未更改的 Docker 层拉取到8台机器人上。（而且我认为机器人技术并不是唯一会遇到这个问题的行业——看看 ollama 的例子，那真是一个痛苦的拉取过程。）<p>如果 Docker 更智能，知道哪些文件已经在磁盘上，那会怎样？我在 `/var/lib/docker` 中有多少个 `python3.10` 的副本？更进一步，DockerHub 中有多少个副本？一个能够在文件级别而不仅仅是在层级别进行地址处理和去重的注册中心，肯定会更便宜。<p>这个工具：<p><pre><code> - 给定两个 Docker 镜像，一个是你已有的，一个是你要拉取的，计算 `docker pull` 将使用多少数据，以及实际需要拉取多少数据 - 显示在各种糟糕的网络条件下你将节省多少时间的估算 - 提供了一些智能拉取能帮助的情况示例，但两个镜像名称是自由文本，欢迎你在这里输入自己的值进行尝试（不过一次只能输入一个，因为有一个工作队列在分析新的镜像对） </code></pre> 我希望它能有的一个功能，但还没能在用户界面中实现的，就是可视化那些没有改变但仍然被拉取的文件。<p>这个工具完全是用 Claude Code 编写的，这对我来说是一次新的体验。我对 nextjs 完全不熟悉，通常也不写前端。也许我能比 Claude 稍慢一点写后端，但前端会花我四倍的时间，而且效果也不会那么好。我想我知道我想要的后端功能，这对我有帮助。<p>我正在构建的注册中心/传输/快照器（？）将允许在本地机器的 Docker 层之间共享文件，也可以在注册中心中共享。这方面有一些先前的研究，但仅限于客户端。eStargz 格式允许将文件系统的元数据和内容分开，同时仍然保持 OCI 兼容——但它对内容进行懒惰拉取，并且没有去重。我认为它可以轻松与其他镜像提供商在成本（由于使用更少的存储和带宽……到处都是）和速度上竞争。<p>如果你感兴趣，请联系我。

我构建这个系统是因为我在同一个代码库上运行了3到5个Claude Code实例，频繁在终端窗口之间切换让我感到疲惫。我需要仔细确保各个代理的工作不重叠，防止上下文窗口的降级，手动执行文档/记忆政策，并在不同会话中重新解释决策。 Stoneforge是我想要的协调层。一个Director代理将目标拆分为任务，一个调度守护进程在有可用工人时将任务分配给他们，每个任务在自己的git工作树中运行。管理者会审查已完成的任务，如果一切通过检查，则将其压缩合并到主分支；否则，他们会将任务连同审查意见交接给新的代理。 当一个工人达到其上下文限制时，它会提交，写下交接说明并退出，这样下一个工人就可以在同一分支上以新的上下文窗口和前一个代理工作的重要备注继续。 一些可能对大家感兴趣的设计决策： - 完全事件源化，并具有完整的审计日志。 - 支持将任务同步到Github或Linear，将文档同步到Notion、Obsidian或本地文件夹。也支持自定义提供者。 - 使用JSONL作为真实数据源，SQLite作为一次性缓存。JSONL支持差异比较、跨分支合并，并能抵御损坏。SQLite提供全文搜索和索引查询。SQLite数据库可以在不同设备上在几秒钟内重建。 - 默认情况下没有审批门。如果五个代理每次文件写入都需要确认，你是不会更快的。审查发生在合并管理者级别。 - 使用工作树而非容器。编码代理的冲突表面是git和文件系统，容器或远程实例显得过于复杂。工作树在毫秒内创建，共享node_modules和构建缓存，不需要Docker或单独的服务器。 - 你可以在同一个代码库上同时运行多个Claude Code / Codex计划。 兼容Claude Code、OpenAI Codex和OpenCode。采用Apache 2.0许可。GitHub链接：<a href="https://github.com/stoneforge-ai/stoneforge" rel="nofollow">https://github.com/stoneforge-ai/stoneforge</a> 欢迎讨论架构或任何权衡。

AI代理越来越多地执行实际系统操作：发放退款、修改数据库、部署基础设施、调用外部API。由于代理会重试步骤、重新规划任务并异步运行，同一操作有时可能会执行多次。在生产系统中，这可能导致重复支付、重复变更或状态不一致。Kybernis是一个可靠性层，位于代理系统的执行边界。当代理调用工具时： 1. 捕获执行意图 2. 将操作记录在执行账本中 3. 附加幂等性保证 4. 变更仅提交一次 重试变得安全。Kybernis是框架无关的，可以与LangGraph、AutoGen、CrewAI等代理框架或自定义系统一起使用。我是在多次看到AI代理与生产API交互时出现可靠性故障后开发的这个工具。希望能收到任何正在构建代理系统的人的反馈。

嘿，HN， 我未能通过AWS高级网络专业考试。我学习了几周，使用了常见的备考网站，以为自己已经准备好了——结果并不是这样。 问题不在于努力，而在于工具。静态的题库并不能教会你如何思考AWS架构决策。它们只是教你如何匹配答案。这在更难的考试中就会失效。 因此，我创建了Knowza来解决这个问题，后来发现其他人可能也有同样的挫败感。这个想法是：与其使用静态题库，不如利用AI生成问题，适应你的薄弱环节，并真正解释每个答案背后的推理——就像一位资深工程师会解释的那样，而不是简单的选择题标准。 技术栈： Next.js + Amplify Gen 2 DynamoDB（直接服务器操作，无API层） AWS Bedrock（Claude）用于问题生成和解释 Stripe用于计费 老实说，最难的部分并不是AI——而是确保问题质量足够一致，以至于我可以信任它用于真实的考试准备。我仍在不断迭代这一点。 目前还处于早期阶段，只有我一个人，边工作边开发。希望能听到任何在AWS认证方面有经验或对AI生成教育内容有想法的人的反馈。 knowza.ai

你现在还喜欢作为软件工程师（SWE）或在科技行业工作吗？<p>经过与几位资深人士的交流，发现他们中的一些人感到厌倦，正在考虑完全离开这个行业。<p>你怎么看？

这是一个极其复杂的小游戏，旨在完善我的玩具 Rust 引擎。它采用了 Rust => wasm => webgl 的架构。我在成长过程中玩音乐，但没有学习基础知识，因此想要帮助自己更好地理解“理论”。需要说明的是，我在这个过程中使用了很多 Claude 的代码来帮助我。

我最近注意到，在我的日常工作中，有些简单的工单可以通过一个简单的提示来解决，因此我构建了一个简单的开放代码编排系统，连接了Jira、编码代理（Cursor/Claude）和GitHub。<p>这个系统的目标是自动化那些每个合格工程师大致以相同方式解决的简单工单，让我们只需接受一个准备好的PR（拉取请求）。<p>现在我遇到了另一个问题：如何让真正的初创公司尝试这样的开源工具？<p>我在X、Reddit和这里发布了关于我的工具的信息。我收到了星标甚至一些积极的评论，似乎确实对这个想法有一些兴趣，但据我所知，目前没有初创公司真正使用它。<p>我真的不确定该如何进行，我并不是想从中赚钱，所以我不想主动接触公司——但我喜欢在业余时间构建东西，并且非常希望看到它被初创公司真正使用。<p>我该怎么做呢？<p>如果有人感兴趣，可以查看我的仓库： https://github.com/ErezShahaf/Anabranch

传统上，医疗保健依赖于在定期临床访问中收集的零散数据。然而，人类生理是一个持续的过程，不断响应环境、活动、压力、污染、过敏原和疾病进展等因素。 我们正朝着一个变革时代迈进，这个时代以持续的、真实世界的健康监测为特征，这得益于先进的传感器、云计算基础设施和人工智能。其中，呼出的气体是最有价值但尚未充分利用的生理信号之一。 呼出的气体包含丰富的生化信息，包括代谢、炎症、环境暴露、生理压力和各种疾病早期阶段的标志。主要挑战不在于这一信号的价值，而在于如何在保持匿名的同时，持续、大规模地捕捉和分析它。 创新平台如Healthmetryx正在解决这些挑战。Healthmetryx实时收集来自呼出气体的匿名数据、呼吸生命体征（如血氧饱和度、二氧化碳和呼吸模式）以及环境条件。这种综合方法生成结构化的、可操作的见解，能够区分孤立的呼吸事件与特定地点的更广泛趋势。 这些技术进步具有广泛的应用，包括： - 人口健康和公共卫生监测 - 第一响应者和工业人员的职业安全 - 加速临床研究和药物开发 - 在气候变化背景下监测环境暴露 其真正潜力在于对大数据集的模式识别，持续的生理信息使得识别以前无法探测的信号成为可能。这种能力促进了更早的风险检测、主动干预策略、对环境诱因的更深入理解以及对人类表现的改进见解。 这不仅仅是渐进的进步；它标志着向主动医疗保健的根本转变，从被动的症状管理转向健康风险的早期识别和减轻。 随着生物传感器技术、人工智能和大规模数据系统的不断进步，监测和解读日常生理信号的新方法将重新定义医疗实践。这一演变预计将带来变革。 考虑这样一个问题：基于呼吸的连续智能技术何时可能成为医疗保健的标准实践？

嘿，HN社区！ 我们在推出了LLM功能后构建了Argmin AI，最初的演示效果良好，但在生产环境中，费用和延迟变得不可预测。提示不断扩展，上下文增多，检索变得嘈杂，重试出现，代理工作流增加了循环。 Argmin AI作为一个系统，优化与LLM相关的费用： 1. 提示和上下文的效率 2. 模型选择和路由 3. RAG低效和缓存机会 4. 代理工作流（工具调用、重试、循环控制） 所有变更都通过评估和保护措施（测试、门控、评审）进行验证，旨在符合您的质量定义和目标。 在为优化工作付费之前，我们会进行结构化评估：我们会映射您管道中的主要成本驱动因素并估算节省，以便您能够在内部对关注点达成一致。 我希望能听到在生产中运行LLM的团队的反馈：今天对你们来说最困难的是什么？是工作流的成本归属、安全路由，还是评估覆盖？ 附言：如果您不确定您的设置是否有优化空间，我们基于已发布的行业研究和定价基准构建了一个3分钟的成本计算器： [https://app.argminai.com/signup/cost-calculator](https://app.argminai.com/signup/cost-calculator)