原贴链接

我看到很多人抱怨像LangChain这样的框架太复杂了。假期里，我想探究一下如果去掉所有不必要的功能，一个大语言模型框架能精简到什么程度。例如，为什么大语言模型框架里要包含OpenAI的封装呢？一是OpenAI API在不断演变（0.27版本之后的客户端），官方库经常会引入难以维护的漏洞或依赖问题；二是自己构建封装很简单，只要把最新的供应商文档提供给大语言模型就行；三是扩展性方面，避免特定供应商的封装后，开发者能轻松切换到最新的开源或自行部署的模型。同样，我去掉了那些可以按需构建而非嵌入框架的功能。结果就是我创建了一个100行的大语言模型框架：https://github.com/miniLLMFlow/PocketFlow/。这100行代码体现了我认为大多数大语言模型框架的核心抽象：一个嵌套有向图，它将任务分解为多个大语言模型步骤，通过分支和递归来实现类似代理的决策。基于此，可以做如下事情：一是添加复杂功能，我给出了构建（多）代理、检索增强生成（RAG）、任务分解等示例；二是与编码助手无缝协作，因为框架很精简，所以它能很好地与ChatGPT、Claude和Cursor.ai等编码助手集成，只需分享相关文档（例如在Claude项目中），助手就能帮你即时构建新的工作流。我正在添加更多示例，欢迎反馈，如果有你希望看到的功能或者你认为缺失的特定用例，请告诉我！

讨论总结

原帖作者创建了一个100行的LLM框架，认为去除不必要功能后能体现LLM框架核心抽象。评论者们从多个方面进行讨论，包括认可这个想法但指出代码可读性问题，还有人对框架的具体用途提出疑问，也有人表达想借鉴这个框架，大家还讨论了与AI代理开发相关的API、文档等问题，整个讨论氛围较为积极，是对这个100行LLM框架的全面探讨。

主要观点

  1. 👍 认可构建100行LLM框架想法，但认为__init__.py代码可读性差
    • 支持理由：300行代码压缩到100行导致代码难以理解，不利于更多人使用
    • 反对声音：无
  2. 👍 建议将目标设定为500行清晰且文档完善的代码
    • 正方观点：有助于更多人理解和使用框架
    • 反方观点：无
  3. 🔥 认为不应过度关注代码行数，应关注功能最小集
    • [解释]：可以在不过度设计的情况下最大化可做的事情范围
  4. 💡 原框架构建者表示会推出扩展版本
    • [解释]：针对大家的讨论，原作者接受部分建议，会推出扩展版本
  5. 💡 会查看作者创建的框架
    • [解释]：被这个框架吸引，想要深入了解

金句与有趣评论

  1. “😂 300 LOC squished into 100 LOC that’s unreadable is not a huge win.”
    • 亮点：简洁地指出过度压缩代码行数带来的可读性问题
  2. “🤔 Instead of focusing on LOC, maybe focus on the minimal set of features you need to maximize the range of things you can do, without over engineering!”
    • 亮点：提出关注功能最小集而非代码行数的新颖观点
  3. “👀 One of the most frustrating things about doing any sort of AI agent development is the ever changing APIs, incomplete documentation etc. and using non - portable libraries (Langchain is the worst).”
    • 亮点：指出AI代理开发中的痛点，包括API、文档和库的问题

情感分析

总体情感倾向是积极的，大多数评论者对原帖作者构建100行LLM框架的想法表示认可或感兴趣。主要分歧点在于代码的行数与可读性方面，部分人认为100行代码虽然简洁但可读性差，建议增加行数并完善文档，而另一部分人则认为应关注功能最小集而不是代码行数。可能的原因是不同的人从不同的使用场景和目的出发，开发人员可能更注重功能实现的简洁性，而使用者可能更关注代码的易读性和可维护性。

趋势与预测

  • 新兴话题：框架在实际应用场景中的更多探索，如在笔记本电脑操作系统中的集成以及对多种模型的管理等。
  • 潜在影响：如果这个框架得到进一步完善和推广，可能会对LLM相关开发提供新的思路，简化开发流程，也可能促使更多人关注框架的功能最小集概念。

详细内容：

《100 行构建的 LLM 框架在 Reddit 引发热议》

在 Reddit 上，一篇题为“我在短短 100 行内构建了一个 LLM 框架！！”的帖子引起了众多关注。帖子中作者称在假期期间，鉴于对诸如 LangChain 等复杂框架的诸多抱怨，想探索去除所有不必要的功能后，LLM 框架能有多精简。此贴获得了大量的点赞和众多评论。

讨论的主要方向集中在该框架的代码简洁性、功能扩展性以及实际应用效果等方面。文章将要探讨的核心问题是，这个 100 行的 LLM 框架是否真的能满足开发者的需求，以及它在实际应用中的表现如何。

讨论焦点与观点分析

有人称赞道：“这个想法很棒，但__init__.py 中的代码简直是灾难！300 行的代码压缩到 100 行，根本无法读懂。有趣是有趣，但如果目标是让很多人使用，或许尝试 500 行真正干净且文档完善的代码会更好。请加上类型标注。不过还是要继续加油！我讨厌庞大又笨拙的包！”作者回应会发布扩展版本，并在开发中寻找更好的平衡点。

也有人表示：“不必要的约束用于激励可能有趣，但在实际中代码高尔夫很糟糕。不要专注于代码行数，而是关注所需的最小功能集，以在不过度设计的情况下最大化可做的事情范围！”作者对此完全同意。

还有人提到：“看起来很有趣，但我认为我需要更具可定制性的循环图（状态机），节点转换能更灵活一些。”

有人认为：“感谢，我会看一看。做任何一种 AI 代理开发时，最令人沮丧的事情之一就是不断变化的 API、不完整的文档等，以及使用不可移植的库（LangChain 是最差的）。能有这样一个基本方法来理解正在发生的事情是很好的。”

有人称赞这是个很好的想法，要构建足够简单、能让 LLM 完全理解的框架，并表示要借鉴代码和想法。

有人分享个人经历称：“多谢老兄提供的库。在我的几个项目中，技术文档和 API 的变化导致需要更改，这真的很令人沮丧。”

有人提问：“如何提高输出质量和精炼知识，以及可能的良好编码？我发现模型都很清楚自己能做什么，但需要非常具体的提示，否则就会偏离想要的结果。”

有人表示：“我要在当前项目中使用它。这是一个工具包，拥有我进行各种实验和快速迭代所需的一切。”

有人质疑：“不太理解代理如何决定下一步，以及如何在 PocketFlow 中表示？”作者给出相关链接并解释了其中的高级理念。

有人提出其他方案，比如更明确的方法链接方式或构建器模式。

有人称赞作者的愿景和实现，也有人询问代理生成正确格式输出的可靠性。

总体而言，讨论中既有对该框架的肯定和期待，也有对其不足和改进方向的探讨，共识在于大家都关注框架的简洁性、实用性和可扩展性。一些独特的观点如对代码简洁与可读性的平衡、不同模式的应用等，丰富了讨论的深度和广度。