24小时热榜

<a href="https://archive.ph/rP4cb" rel="nofollow">https://archive.ph/rP4cb</a> （文本在底部）<p><a href="https://x.com/elonmusk/status/2032201568335044978" rel="nofollow">https://x.com/elonmusk/status/2032201568335044978</a>，<a href="https://xcancel.com/elonmusk/status/2032201568335044978" rel="nofollow">https://xcancel.com/elonmusk/status/2032201568335044978</a><p><a href="https://economictimes.indiatimes.com/tech/artificial-intelligence/musk-ousts-more-xai-founders-as-ai-coding-effort-falters-ft-reports/articleshow/129560405.cms" rel="nofollow">https://economictimes.indiatimes.com/tech/artificial-intelli...</a><p><a href="https://futurism.com/artificial-intelligence/elon-musk-screwed-up-xai-rebuilding" rel="nofollow">https://futurism.com/artificial-intelligence/elon-musk-screw...</a>

<a href="https://xcancel.com/id_aa_carmack/status/2032460578669691171" rel="nofollow">https://xcancel.com/id_aa_carmack/status/2032460578669691171</a>

我发现这个项目是因为突然间，Logi Options Plus 软件更新器开始占用我 Intel Macbook Pro 的 40-60% 的资源，直到我结束了这个进程（当然，它会重新启动）。在我的搜索过程中，我发现了一个 Reddit 讨论，里面有其他人也遇到了同样的问题。 我在这个项目中是一个小贡献者，但它的目标是减少或消除使用 Logitech 专有软件和遥测的需求。如果其他人对此感兴趣，我们非常欢迎帮助。 请查看 GitHub 链接，以获取更详细的动机（消除遥测），作为这个项目的一部分。链接如下： [https://github.com/TomBadash/MouseControl](https://github.com/TomBadash/MouseControl)

我们构建了一个开源代理，位于编码代理（如 Claude Code、OpenClaw 等）与大语言模型（LLM）之间，在工具输出进入上下文窗口之前进行压缩。 演示链接：<a href="https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s" rel="nofollow">https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s</a>。 动机：代理在管理上下文方面表现不佳。单个文件读取或 grep 操作可能会将成千上万的标记输入窗口，其中大部分是噪声。这不仅成本高昂，还会主动降低质量。长期上下文基准测试一致显示，随着上下文的增加，准确率急剧下降（OpenAI 的 GPT-5.4 评估在 32k 时为 97.2%，而在 1M 时降至 36.6% <a href="https://openai.com/index/introducing-gpt-5-4/" rel="nofollow">https://openai.com/index/introducing-gpt-5-4/</a>）。 我们的解决方案使用小型语言模型（SLMs）：我们查看模型内部，并训练分类器以检测上下文中哪些部分携带最多信号。当工具返回输出时，我们根据工具调用的意图进行压缩——例如，如果代理调用 grep 寻找错误处理模式，SLM 会保留相关匹配项并去除其余部分。 如果模型后来需要我们移除的内容，它会调用 expand() 来获取原始输出。我们还在窗口容量达到 85% 时进行后台压缩，并懒加载工具描述，以便模型仅看到与当前步骤相关的工具。 该代理还提供支出上限、用于跟踪当前和过去会话的仪表板，以及当代理在等待您时的 Slack 提醒。 代码库在这里：<a href="https://github.com/Compresr-ai/Context-Gateway" rel="nofollow">https://github.com/Compresr-ai/Context-Gateway</a>。您可以尝试以下命令： <pre><code> curl -fsSL https://compresr.ai/api/install | sh </code></pre> 如果您对压缩模型、懒加载工具的工作原理或关于网关的其他任何内容有兴趣，欢迎深入交流。试试看，并告诉我们您的使用体验！

嘿，HN， 我和我的联合创始人对 CC 忽视我们的 Markdown 文件感到厌倦，因此我们花了 4 天时间开发了一个插件，能够根据我们之前的会话自动引导 CC。问题通常出现在计划模式之后。 我们尝试过的方式： - 大量使用计划模式（效果很好） - CLAUDE.md、AGENTS.md、MEMORY.md - 本地上下文文件夹（维护起来很麻烦） - 光标规则（针对光标） - claude-mem（开源）——实现会话连续性，但不进行引导 我们使用融合搜索来找到你的 CC 引导修正。 - 用户提示嵌入 + bm25 - 修正嵌入 + bm25 - 时间衰减 - 目标查询嵌入 - 排除项 - 元数据硬过滤器（例如文件） CC 插件： - 自动捕捉记忆/修正，无需你提醒 CC - 自动注入修正，无需你提醒 CC 去做 该插件会合并、更新并提炼你的记忆，然后在你每次提示后注入最相关的内容。 我们不确定是否只有我们在做这个。我们正在进行一些基准测试，以查看上下文注入在引导 CC 方面的实际效果，并且我们知道需要继续改进提取、搜索，并增加更多集成。 我们对为代理提供实时和个性化的上下文层充满热情。让代理理解你说的“这个”或“那个”的意思。将你世界的上下文带入一个安全、结构化、实时的层面，所有代理都可以访问。 希望能得到你们的反馈，关于你们如何让 CC 实际遵循你的 Markdown 文件，理解你的工作方式，关于插件的反馈，或任何其他关于实时记忆和上下文的内容。 - Ankur