最新

我之所以构建这个，是因为我想要一个简单的、类型安全的 Java 客户端，用于 Google Gemini，能够原生支持 ReAct 代理，而不需要 LangChain4j 的繁重框架。现在它还支持本地 ONNX 嵌入和 pgvector。欢迎反馈！

我不是技术专家，也不在科技行业工作，因此这是一个外部观察者的视角。关于通用人工智能（AGI）的市场宣传承诺了斯皮尔曼的g：一种能够适应新问题、未见问题的通用流动智能。然而，工程方面——特别是“专家混合模型”和独立模块——看起来与J.P.吉尔福德的智力结构完全相同。吉尔福德将智力视为大约150种具体的、独立的能力的集合。 问题不仅在于这些部分是如何拼接在一起的。我看到的问题是：当模型面临一个不符合其预定义部分的问题时，会发生什么？他们将如何确保输出不会显得支离破碎，而架构又依赖于在专门“专家”之间切换，而不是使用统一的推理核心？ 具体技能的集合（吉尔福德）与适应任何事物的能力（斯皮尔曼）并不相同。通过优化特定组件，我们正在构建一个在已知任务上表现出色的系统，但可能在真正的通用智能所需的流动推理方面根本缺乏能力。我并不是反对人工智能；我只是觉得我们可能需要重新审视我们的做法。我们不能指望在错误的高速公路上到达正确的目的地。

我已经使用Claude Code运行长时间的编码代理大约六个月了。Steve Yegge在十月份发布了Beads，我发现为Claude提供适当的任务跟踪工具是一个巨大的突破。然而，Beads在短时间内迅速增长，每次发布都使其变得更加缓慢和令人沮丧。我开始每周多次与它斗争，因为它的后台守护进程在错误的时间同步错误的内容。 在假期期间，我终于将其移除，并编写了ticket作为替代。它保留了我真正关心的核心概念（基于图的任务依赖关系），但去掉了其他所有内容。 ticket是一个基于coreutils的单文件bash脚本，用于管理平面文件。当你有awk时，不需要用SQLite对所有内容进行索引。它只是一个小型的管道工具，能够让你专注于工作。 我很想听听大家对不足之处的反馈。我是为自己的代理工作流程构建这个工具的，所以可能还有一些用例我没有考虑到。