最新

我构建这个项目，是因为我想要一个简单、基于类型的 Java 客户端，用于 Google Gemini，它原生支持 ReAct 代理，而且没有 LangChain4j 那么臃肿。现在，它还支持本地 ONNX 嵌入和 pgvector。欢迎提供反馈！

我不是技术专家，也没有在科技行业工作，所以这只是一个外行人的视角。 围绕通用人工智能（AGI）的营销承诺了斯皮尔曼的 g 因素：一种通用的、流畅的智能，能够适应新的、未曾遇到的问题。 但其工程设计——特别是“专家混合”和不同的模块——看起来完全像是 J.P. 吉尔福德的智力结构。吉尔福德将智力视为大约 150 种特定、独立能力的集合。 问题不仅仅在于这些部分是如何组合在一起的。我看到的问题是：当模型面临一个不适合其预定义部分的问题时会发生什么？当架构依赖于在专业的“专家”之间切换，而不是使用统一的推理核心时，他们将如何确保输出不会显得支离破碎？ 特定技能的集合（吉尔福德）与适应任何事物的能力（斯皮尔曼）是不同的。通过优化特定组件，我们正在构建一个擅长已知任务的系统，但可能从根本上缺乏真正通用智能所需的流畅推理能力。 我并不反对人工智能；我只是觉得我们可能需要重新审视我们的方法。我们不能指望在错误的道路上到达正确的目的地。

我用 Claude Code 运行长时间的编码代理已经大约 6 个月了。Steve Yegge 在去年 10 月发布了 Beads，我发现给 Claude 提供合适的任务跟踪工具是一个巨大的突破。但 Beads 在短时间内迅速膨胀，每次发布都让它变得更慢，使用起来也更令人沮丧。我每周都会和它斗争好几次，因为它的后台守护进程总是会在错误的时间同步错误的内容。<p>在假期里，我终于把它彻底移除，并用 ticket 替代。它保留了我真正关心的核心概念（基于图的任务依赖关系），但去掉了其他所有东西。<p>ticket 是一个基于 coreutils 构建的单文件 bash 脚本，用于管理平面文件。当你有了 awk，就不需要用 SQLite 来索引所有东西。它只是一个小的管道工具，不会妨碍你工作。<p>很希望得到关于不足之处的反馈。我为自己的代理工作流程构建了这个工具，所以可能还有我没有考虑到的用例。