返回首页
最新
我目前有一个Claude Pro的月度订阅（$20），主要用于编程。这个工具很有用，但我对在它的会话限制下优化工作感到疲惫。现在有很多选择和提供商，但很难找到可靠的信息来判断哪些是好的。我并不想要另一个Opus级别的模型，而是希望找到一个足够可靠的工具，能够很好地支持测试驱动开发（TDD）。
我们对工资、价格和住房的看法往往来自于直觉、头条新闻和轶事，而实际数字通常出乎意料。
“Off By”是一个每日游戏：提供五个真实的经济统计数据，你通过滑块猜测每一个，然后看看你猜得有多远。每个人在同一天玩相同的问题。
平均玩家的误差为25%。我通常也在这个范围内。
免费，无需注册账户。
我很好奇HN用户的准确性是否高于平均水平，并且总是在寻找那些令人惊讶但又无懈可击的统计数据。如果你知道一个好的，欢迎在评论中分享。
大约一个小时前，新版本已部署到PyPI。<p>我刚刚在设置一个新项目时，发现情况有些异常。我的笔记本电脑内存不足，看起来像是出现了叉炸弹（fork bomb）。<p>我进行了调查，发现proxy_server.py中添加了一个base64编码的二进制数据块。<p>它会写入并解码另一个文件，然后执行该文件。<p>我正在将此问题上报，但想在这里提前提醒大家。<p>该问题也在这个链接中报告过：
<a href="https://github.com/BerriAI/litellm/issues/24512" rel="nofollow">https://github.com/BerriAI/litellm/issues/24512</a>
嗨，HN的朋友们，
我已经构建AI代理有一段时间了。这个领域的变化经历了从LLM + 工具 → LLM工作流 → 代理 + 工具 + 内存，现在我们终于看到了真正的自主性出现：代理作为由工具、命令行访问、细粒度系统能力和内存组成的系统。
这种构建代理的方式非常强大，我相信它将会持续存在。但真正的问题是：支撑这些代理的系统是否准备好迎接未来？
我认为还没有。
使用Docker来运行单个代理并不适合扩展，因为代理需要轻量且快速。大型语言模型（LLM）已经增加了显著的延迟，因此在其基础上增加沉重的运行时开销只会使情况变得更糟。现有的解决方案在这里开始崩溃。
用Python构建的代理往往占用大量内存，当你想要扩展到数千个代理时，这将成为一个严重的问题。
而且，代理的开源生态仍然没有达到应有的水平。目前，我无法像重用开源软件那样轻松重用领域专家构建的代理。
这些问题让我感到困扰，我意识到如果代理要实现民主化，它们需要开放且易于使用。就像Docker解决了系统依赖问题一样，我们也需要类似的东西来支持代理。
这就是我开始用Rust构建代理框架的原因。它是模块化的，并遵循真正自主性的原则：代理是一个具有工具、内存和执行器的实体。在AutoAgents中，用户可以独立创建和修改工具、执行器和内存。
通过AutoAgents，我看到可以构建强大的代理，而不会像许多其他框架那样在性能或内存上妥协。
但其他问题仍然存在：代理的再共享、沙箱化以及扩展到数千个代理。
因此，我创建了Odyssey——一个基于AutoAgents的Rust编写的捆绑优先代理运行时。它允许你定义一个代理一次，将其打包为可移植的工件，并通过相同的执行模型在本地开发、嵌入式SDK使用、共享运行时服务器和终端工作流中运行。
AutoAgents和Odyssey都是完全开源的，并且都是用Rust构建的，我计划很快建立一个Odyssey代理中心，增加WASM工具、自定义内存层等功能。
我的愿景是让代理民主化，使其对每个人都可用——安全且高效。开放是不够的；代理也需要安全。
该项目仍处于alpha阶段，但已经处于可工作状态。
AutoAgents 仓库 -> [https://github.com/liquidos-ai/AutoAgents](https://github.com/liquidos-ai/AutoAgents)
Odyssey 仓库 -> [https://github.com/liquidos-ai/Odyssey](https://github.com/liquidos-ai/Odyssey)
我非常欢迎反馈——尤其是来自那些处理过类似问题的朋友。你的反馈将帮助我塑造产品。
感谢你们的时间！
嗨，HN，我创建Cortex是因为我厌倦了那些将你最私密数据发送到他人服务器的AI记忆解决方案。
Cortex是一个四层记忆引擎（情节性 → 语义性 → 程序性），完全在你的设备上运行。采用纯Rust编写，体积为3.8MB，数据摄取时间为62微秒。
LoCoMo基准测试：整体得分73.7%，在所有四个类别中超过了Mem0（66.9%）。
通过你自己的iCloud/GDrive/Dropbox进行AES-256-GCM加密同步。
GitHub链接：[https://github.com/gambletan/cortex](https://github.com/gambletan/cortex)
我对在 GitHub 上使用 Claude Code 生成的代码量感到好奇，因此我尝试寻找这个答案。
剧透警告：数量非常庞大——根据我的统计，大约有 1900 万次提交。
简而言之，这是一个仪表板，展示了一些关于在 GitHub 公共仓库中由 Claude Code 签名的提交的基本统计数据，希望这些数据能引起您的兴趣。
并不是所有的提交都有签名（通过作者字段或提交“尾部”），而且许多仓库是私有的，这意味着 Claude 的影响范围可能比您在这里看到的要广泛得多。但我认为这些数据足以展示其分布情况，并让我们了解它的使用情况。
在技术上，这只是一个相对基础的 Next.js 应用，使用 Recharts 进行图形展示，数据库则是 PostgreSQL。我最初使用 BigQuery，因为我估计需要分析规模，但最终转向了 Postgres，因为小规模写入和频繁读取去重的成本变得过高。
数据摄取/回填作业是更有趣的部分，因为我从严重低估其复杂性（从小规模开始）转变为最终建立了一个简单但功能齐全的 ETL 管道。
主要的挑战在于读取数据时要克服 GitHub 的速率限制——无论是在搜索 API 还是 GraphQL API 上。搜索的限制是每分钟 30 次请求，而 GraphQL 的限制是每小时 5000 次请求（每个访问令牌）。由于这些差异以及响应时间的不同，我将工作分为两部分：
1. 有一批搜索工作者将基本的提交信息写入一个表中——分页和拆分以尽可能多地找到提交。
2. 丰富工作者从该表中读取数据，并填充我们在搜索中无法看到的一些信息。通过这种方式添加了新增/删除的行和仓库信息。
目前读取这些提交时有些延迟，并且仍在拉取历史提交，这就是为什么最近的提交日期数量较少，以及某些仓库尚未设置语言的原因。
我不会说这个项目已经 100% 完成——我希望继续改进数据摄取，并且我认为我可以从数据中提取更多信息——但我确实很享受目前所看到的内容。
如果您有任何建议可以添加到仪表板上，或者想到其他我应该读取的内容，请告诉我。
有关我的方法论和回填作业演变的更多信息，请访问关于页面。:-)
有人知道为什么 archive.is 中的 inject.js/heuristic.js 会寻找 bitwarden 和 datalane 的内容吗？如果在 Chrome 中启用缓存保留功能，你会发现这些文件随着时间的推移“消失”了，但它们仍在进行多个请求。有人知道这是为什么吗？