24小时热榜

各位 HN 的朋友们！ 我们都在花费越来越多的时间来使用 Agent 进行开发，但我注意到，在日常工程工作流程中，最令人头疼的问题之一就是处理敏感信息和凭证。这通常涉及大量的点击操作、复制粘贴和协作，而市面上现有的秘密管理产品都未能真正解决这个问题。 我开发了 Capy 来解决这个问题。它是一个秘密管理器，其整个前端就是一个开发者 CLI。我发现手动使用它非常方便。您甚至无需离开 CLI 即可注册和使用它！您可以在不离开终端（或 Agent）会话的情况下进行安装和身份验证。 它还拥有非常强大的版本管理功能，支持类似 Git 的分支和冲突解决。您可以将版本清单推送到源代码管理，协作者可以随时拉取特定版本的秘密。 该平台本身非常安全。它会加密您的本地 .env 文件，使其无法被直接读取。在将值推送到服务后，它会再次使用服务密钥进行加密。这样一来，无论是本地机器被攻破还是服务被攻破，都不会导致信息泄露。 顺便说一下：自四月份发布以来，我一直在不断完善它，并对产品的重点进行了一些调整。最初，我更侧重于 TUI 和 TTY，提供诸如部署、轮换和连接服务等操作的向导式引导，但我意识到，产品的真正未来在于使其与 Agent 配合得极其出色。 因此，Capy 的下一个演进方向将是提供更令人满意的 Agent 协同体验，我一直在为此进行一项重大工作。 我很想听听大家对这个想法、实现方式的看法，并非常欢迎任何反馈！

我构建了 Spltty，一个 Ruby 命令行工具，用于使用纯 Markdown 文件跟踪共享费用、自定义分摊和结算。本文将介绍它是如何从一个由 Claude 管理的文件夹演变成一个命令行工具的。

大家好，我是 Shailendra 和 Karan。我们正在为编码代理构建一种快速安全的方式，以便在生产环境中实时调试问题。 当生产环境出现故障时，它允许 Cursor、Claude 等工具在您运行的代码中安全地设置虚拟断点或探针，并提取日志中没有的确切变量值。 这一切都能为工程师节省时间和精力，他们原本需要挖掘日志和跟踪信息，或者通过 `console.log` 或 `print` 语句重新部署，直到找到根本原因。 以下是解释此功能的视频链接：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ivV7I--ta5c" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ivV7I--ta5c</a> 现在，代理编写了我们的大部分代码。这缩小了工程师调试 AI 生成代码所需的有用上下文，而 AI 在同一代码中添加的有限遥测数据也无济于事。 因此，当生产环境出现问题时，工程师的第一反应是打开日志或将其交给代理。但如果找不到您要查找的行，代理就会开始根据不存在的数据猜测根本原因，迫使您添加日志并重新部署。 代理与现有数据的这种分析-推理循环成本高昂，会消耗大量 token。而添加日志、重新部署的循环又慢又痛苦，让工程师对值班感到厌倦。 我们的方法允许代理在发生故障的确切时刻和地点按需捕获遥测数据，从而终结日志-重新部署循环，并在消耗更少 token 的情况下获得最准确的根本原因分析 (RCA)。 显而易见的问题是如何在正在运行的服务上实现这一点。您无法像在笔记本电脑上暂停调试器那样暂停实时服务。安全地从正在运行的进程中获取值，而不暂停线程或减慢主机速度，这才是挑战。我们正在实现这一点。 在此之前，我曾在一个 100 人的团队中负责工程管理。然后，Karan 和我花了三年时间开发 HyperTest，这是一个测试工具。 在 HyperTest 中，我们使用 OpenTelemetry 将生产流量转化为集成测试。这也是生产环境的仪器化。从正在运行的服务中提取真实运行时状态而不破坏它的难题，正是我们学会解决的难题。 我们也以艰难的方式吸取了一些其他教训。HyperTest 试图通过更好的测试来防止 bug，但每次推广都面临阻力。由于团队忙于处理生产环境的紧急问题，会议经常被取消。测试是例行公事，而生产环境的故障则是火烧眉毛。这让我们看到了优先级的所在。 这催生了构建真正自主的值班代理的想法，即一个代理能够接收警报，进行探测，诊断并修复问题，这一切都在几分钟内完成。但目前它的工作方式如下： 您像往常一样与您的编码代理进行交互。告诉它哪里出了问题：“checkout 返回 200，但有些用户看到他们的订单失败，找出原因。”它会在您的本地代码中定位到相关行，通过 MCP 与我们连接，并在正在运行的服务中的该行设置一个探针。探针是只读的，在实际流量命中之前处于休眠状态。当流量命中时，它会在那一刻捕获调用堆栈每一帧的局部变量。然后将这些变量交给代理，代理使用真实数据进行诊断。 它包含两个部分：一个运行在您的服务内部的 SDK，以及您的编码代理与之通信的 MCP 服务器。SDK 使得在无需重新部署的情况下设置探针（虚拟断点、日志或指标）成为可能。在 Node 和 Python 中，它会钩入进程。在 Java 中，它作为 JVM 代理附加，在字节码级别进行仪器化。无论哪种方式，服务都会继续运行并处理流量。没有任何东西会被暂停。 当您的代理想要查看某一行时，它会调用 MCP 服务器，MCP 服务器会指示 SDK 在该位置放置一个探针。当一个请求命中该行时，SDK 会捕获探针请求的内容，在进程内进行清理，并通过 MCP 将其流式传输回代理。 这可以在生产环境中运行，因此探针可以读取该变量中的任何值。我们确保在进程内，在您自己的容器内存中进行数据 redaction。这发生在任何数据通过网络传输之前。密码、token、授权、SSN 和信用卡等密钥默认会被 redaction，您也可以添加自己的。 此外，探针只读取，从不写入。如果您希望捕获的状态永远不要离开您的网络，您可以将服务器、代理甚至数据库自托管在您的基础设施中。 关于开销：空闲时，SDK 占用的内存微乎其微，对吞吐量和响应时间几乎没有影响。探针只有在主动捕获时才会产生开销。捕获也是有上限的。一个独立的监视器会实时监控，如果开销突然增加，就会禁用所有活动的探针。 每个日志和跟踪工具都会将已有的数据提供给代理，并要求它向后推理可能发生了什么。我们认为，让代理能够洞察正在运行的代码，以便它们在需要时、在故障点捕获它们所需的内容，会更有用。 这似乎是调试生产事件最简单、最快捷的方法。 我们很乐意让社区在任何环境中尝试使用此功能，通过与您的编码代理聊天来调试任何已知或未知的问题。并告诉我们您还需要哪些功能才能使其成为一个真正自主的值班代理。 支持的平台：NodeJs、Java、Python。

我的伴侣需要审阅大量的 P&ID（管道和仪表流程图）以及相关的配套文件（Excel、docx、pdf、acd/l5x 等）。在他公司，这些通常使用 Bluebeam 完成。 要查看差异并跟踪这些迭代产生的全部修订非常困难。他们最终会存储类似“rev3_final_redlined.pdf”这样的文件。我们一直在寻找类似 GitHub 的工具来处理这些审阅，但还没有找到一个对没有命令行界面 (CLI) 经验的人来说足够简单易懂且易于使用的工具（如果您知道任何工具，我很乐意了解）。 因此，我构建了 withkord.com 来帮助进行二进制文件的版本控制和差异比较。欢迎任何反馈。

HN 是一个很棒的独立黑客/独立创始人社区。 我们（人民）热爱透明度、数据，以及对自给自足创业公司的分析。 你目前（独立）的项目是什么？你的月度经常性收入是多少？分享你的成功、失败和技术栈。

我和我的朋友在 Claude Code 和 Codex 上花费了大量时间。我们总是会丢失代码变更背后的上下文，因为每次代理会话都只存在于某个人的笔记本电脑上，等到代码提交到 PR 时，所有的推理过程都消失了。 我们尝试过提交（commits）、拉取请求（PRs）和文档，但它们只能真正捕捉最终结果，所以我们构建了一个工具，将所有的代理会话保存在一个可搜索的地方。 现在，我们（以及我们的代理）可以查看任何人的会话，并询问诸如“Alex 昨天在做什么？”之类的问题。在几天或几周后找回变更背后的上下文也很有帮助。 Ocean 支持 Claude Code、Codex、OpenCode、Hermes、Pi 以及其他代理框架。 我们自己每天都在使用它，它已经成为我们协作方式的核心部分。希望你们也能觉得它有用！ 立即试用：https://ocean.mosaic.inc/ 演示：https://www.youtube.com/watch?v=sjyrgkRBWVg

在软件领域，我们已经将过多的控制权交给了公司和组织。现在是时候将控制权交还给个人了。 我想要一个我能真正拥有的操作系统。 大多数现代系统已经变成了服务器控制的客户端，臃肿着各种依赖（Gtk4/Qt/Rust/Wayland），并且源代码集中托管在GitHub上。如果你无法审计依赖树，并且大公司控制着源代码，那就不再是真正的开源了。 我构建OneManBSD就是为了解决这个问题。它是一个基于OpenBSD的系统，运行在一台2012年的ThinkPad L430上。 视频：https://www.youtube.com/watch?v=2wHaoQhXOYY 页面：https://bialamusic.com/onemanBSD/

GitHub 似乎在持续 (1) 弃用星标信息。起初，未登录用户无法查看 stargazers 列表，现在仓库页面上的主要 stargazers 链接也消失了。除非你拥有该仓库，否则访问 `/stargazers` 会返回 404 错误 (2)。 我知道很多人说星标不是一个真实的信号，但它们曾经是：它们使得检测虚假星标的迹象成为可能。一些第三方服务甚至显示了仓库星标的地理分布，这样你就可以判断它们看起来是否真实。 关键在于，无论 GitHub 提供什么理由，结果都是一样的：要么是 GitHub 在机器人面前很弱，要么是它宁愿自己控制这些信号，而外部用户无法对其进行审计。 1. https://news.ycombinator.com/item?id=48821803 2. https://github.com/tirrenotechnologies/tirreno/stargazers