最新

嘿，HN 多年来，我一直在管理多个远程服务器上的 Docker Compose 应用，但我对使用多个工具来处理简单任务感到厌倦。<p>我对现有的选项不满意，于是我构建了 Sencho。它是一个自托管的 Docker Compose 控制平面，适用于管理单台机器或小型集群的人，无需迁移到 Kubernetes，也无需在网络上暴露 Docker 套接字。<p>通过直接认证的 HTTP/WebSocket 代理或仅出站的 Pilot Agent 连接您的远程节点。连接节点的数量没有限制。<p>从一个中心位置管理整个 Compose 生命周期，最重要的是，您的 Compose 文件不会被“捕获”，而是作为真实来源保留在磁盘上。<p>GitHub: <a href="https://github.com/Studio-Saelix/sencho" rel="nofollow">https://github.com/Studio-Saelix/sencho</a><p>文档: <a href="https://docs.sencho.io" rel="nofollow">https://docs.sencho.io</a>

不久前，我构建了一个简单的应用程序，用于运行一群编码代理——我称之为“舰队”（<a href="https://news.ycombinator.com/item?id=48256389">https://news.ycombinator.com/item?id=48256389</a>）。它基于集中式的组件，使用Python作为协调者，可以运行任何编码器（Claude、agy、Codex）。最近，我添加了一个用户界面来管理整个代理生命周期：添加新任务、监控正在运行的任务，以及一个基于MCP的聊天界面，使用集中式SQLite数据库。从用户界面中，我可以在任何目录中启动代理，定义对其他任务的依赖关系，并指定哪个编码器/模型来完成工作。如今，我可以同时运行10到15个代理。在这样的规模下，你会很快达到限制，因此我花了一些时间调查这些限制的来源以及如何最大化效率。以下是我在运行舰队几周后总结的经验教训： - CLAUDE.md是一个糟糕的抽象。这些文件会无条件加载，通常包含与当前任务无关的描述，并且它们从你的工作目录向上堆叠。结果是浪费了令牌，并且因为将无关指令注入会话而造成混淆。 - 技能虽然不好，但比CLAUDE.md稍微好一点。它们采用渐进式披露的方法：只有技能描述会进入会话，而Claude在需要时会使用工具加载完整的技能文本。这虽然好了一些，但仍然无法扩展——你不能创建10K个技能，因为那会消耗掉你所有可用的上下文。Claude最近引入了技能预算，默默地将不常用的技能从会话中完全剔除。你仍然可以在交互式会话中调用它们，但模型无法在后台会话中调用它们。 - 一些插件可能会被安装多次。在清理过程中，我发现我的几个插件在多个位置被安装，导致重复指令消耗双倍的令牌。 - 在大规模操作中，将插件附加到每个会话是个坏主意。你需要准确了解哪些插件实际上是有用的，并按任务附加它们。 - 使用分层知识库代替CLAUDE.md / 技能 / 插件。这让你能够真正受益于渐进式披露：将你的指令和工具描述保存在其中，让Claude能够快速且廉价地浏览。 - 系统工具消耗约15K令牌（占会话的7%）。你无法管理这些——它们只是附加的，禁用工具并不会将其从上下文中移除。 - AskUserQuestion在后台会话中不可用。你需要实现自己的工具——基于MCP或CLI——以便让`claude -p`能够与你对话。 - 你会变得更加挑剔，选择哪个模型处理每个任务。将工作分解为更难和更简单的子任务，以便将简单的任务路由到较弱、成本更低的模型，从而节省令牌。 - 随着时间的推移，你的上下文切换能力会有所提高。 舰队仓库：<a href="https://github.com/sermakarevich/fleet" rel="nofollow">https://github.com/sermakarevich/fleet</a>

我想要一些方便的 JavaScript 工具来进行简单的文件操作，于是我开发了这个工具……然后我想把它交给我的代理……现在它已经发展成一个独立的项目了。你有什么工具或功能建议吗？