目前大多数大型语言模型（LLM）工作流程依赖于云API，这意味着需要将数据发送到系统外部。我们正在研发一种替代方案：一个完全本地的技术栈，让您可以在不依赖外部供应商的情况下运行和调整模型。这个想法不仅是为了在本地运行模型，还希望使其在特定领域（如法律、医疗、内部知识）中变得实用，同时保持足够小，以便能够在普通硬件上运行。
当前状态：
1) 本地推理引擎（GGUF，与现有工具兼容的API）
2) 带有REST端点和模型元数据的原型模型中心
3) 正在进行的管道，以将通用模型调整为特定领域的模型
我们正在尝试回答的开放性问题是，这个过程是否可以实现可重复性，而不仅仅是一次性的微调。如果成功，它可能会减少许多实际应用场景中对基于云的人工智能的需求。
代码库：<a href="https://github.com/eullm/eullm" rel="nofollow">https://github.com/eullm/eullm</a>
期待听到其他从事本地优先人工智能工作的人的想法。
返回首页
一周热榜
假设一款人工智能机器人，配备了高度耐用的身体（比如它是由钛制成的），明天真的获得了意识并具备了情感，那么它是否应该被赋予人权？
我一直称 eforge 为一种自主构建系统。传统的构建系统将源代码转换为工件，而 eforge 则将规范转换为源代码，然后验证其输出。
我构建它是因为我厌倦了将编排逻辑保存在脑海中——为盲审启动一个单独的会话，切换回实施会话以评估结果，决定接下来构建什么。我为各个部分开发了插件，但序列化的过程仍然由我来负责。我想要一个能够处理完整循环的工具，并且这个工具在不同项目中都能通用，而不是硬编码到特定的代码库中。
你只需提供一个规范——一个提示、一个计划文件或一个产品需求文档（PRD）——然后 eforge 会根据你的代码库评估复杂性，选择一个工作流（简单的更改走快速路径，复杂的则分解为子计划的依赖图），在隔离的 git 工作树中构建、审查和验证——这一切都无需监督。
我实际使用它的方式是：我在 Claude Code 中互动式地规划一个功能，然后运行 `/eforge:build`。插件会获取计划，将其排入队列，然后一个守护进程接管。eforge 从队列中提取计划，理解它们之间的依赖关系，尽可能并行执行，并按拓扑顺序合并。排队的工作在执行前会重新评估，以便考虑到早期构建的更改，而不是盲目地应用于已经变化的代码库。我在构建完成后检查结果——一个网络监控仪表板实时跟踪进度、成本和令牌使用情况。eforge 就是这样构建自己的。
每个构建阶段都有自己的代理——规划者、构建者、审查者、评估者和修复者。审查者在一个全新的上下文中运行，对代码的编写方式没有任何了解。Anthropic 的工程团队独立得出了相同的模式——他们的发现是：单独的代理会批准自己的工作；对抗性评估显著提高了质量。然后，评估者会应用每个块的裁决，接受严格的改进，同时拒绝任何改变意图的内容。