用过 LangChain、Dify 之后，我发现原生 API 才是最优解

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/04fefb3b.html

你好，我是测试蔡坨坨。

在 AI 应用开发的“寒武纪大爆发”时代，开发者们曾疯狂追逐各种“脚手架”。从早期的 LangChain 到后来的低代码平台 Dify、Coze、n8n 等，我们试图通过这些工具简化开发流程。但在深度实践之后，我逐渐意识到：在目前的 AI 阶段，框架的“约束”往往大于“赋能”，回归原生 API 也许才是真正通往高效与精准的路径。

回想起我最开始搭建 RAG（检索增强生成）知识库时，也曾用过 LangChain 和 Streamlit 的组合。但由于缺乏专业的前端功底，加上框架本身的各种束缚，手搓出来的应用往往界面简陋、逻辑生硬，我甚至自嘲地称它们为“ugly-chatbot”。

为了追求更好的体验，我后来转向了 Dify 这种平台，不得不说，它们提供了非常好看且专业的界面，极大降低了 RAG 和工具调用的门槛，通过简单的“拖拉拽”就能快速搭建出原型。然而，在经历了从“裸写”到“套壳”的完整周期后，我发现我们似乎绕了一个大圈，也许最好的入门和进阶方式，是直接使用 Python 调用各大模型厂商的原生 API。于是乎，我们饶了一个大圈子，从写代码到低代码，最后又回到了代码，只不过这次，我们手里握着 AI 这把“作弊器”。

框架的“陷阱”：过度抽象与滞后

LangChain 的诞生背景是模型能力尚弱，需要人肉规范工作流来弥补模型规划能力的不足。然而，随着大模型能力的飞速演进，这种过度抽象的设计理念开始显露弊端：

  • 概念冗余： LangChain 试图用传统的面向对象思维去封装不确定的自然语言逻辑，发明了如 Chain, AgentExecutor, RunnableLambda 等大量新名词来包装这个本来很简单的 API 调用。这使得学习框架的难度甚至超过了学习大模型开发本身。
  • 调试噩梦： 当代码报错时，堆栈信息被层层抽象掩盖，开发者很难判断是 Prompt 的问题，还是框架层的参数传丢了。
  • 适配滞后： AI 技术以“周”为单位迭代，当 OpenAI 或 Anthropic 推出结构化输出或上下文缓存等新特性时，使用框架意味着你必须等待社区更新适配，通常会存在明显的滞后。试图用一套静态的、厚重的框架去封装一个动态的、快速变化的底层技术，结果往往是削足适履。

现在的大模型跟三年前已经完全不一样了，所以我觉得在现在这个时间点，回归模型本身去探索 prompt 和上下文，重新思考模型的能力边界还是很重要的。

低代码的瓶颈：从“提效”到“增熵”

Dify 和 Coze 确实极大降低了 RAG 和工具调用的门槛，是极佳的 BaaS（Backend as a Service）和 MVP（最小可行性产品）验证工具，如果你想快速验证一个 idea，用 Dify 10分钟就能搭出来 demo。但在面对复杂业务逻辑时，它们的短板非常明显：

  • 灵活度受限：仅靠“拖拉拽”很难解决复杂的逻辑。为了避免写代码，开发者不得不以极其拧巴的方式去实现几行代码就能搞定的功能，导致系统熵值剧增。
  • 黑盒操作：在可视化界面中，你很难进行 Token 级别的优化，也无法在流程图中打断点或查看每一步的原始 JSON 响应。
  • 上限较低：很多低代码平台被戏称为“玩具车”，虽然能快速出原型，但因为难以进行深度定制，往往无法支撑起真正能持续赚钱的商业化应用。
  • 性能问题：很多时候，框架为了通用性，牺牲了性能（例如多余的 Token 计算、不必要的中间步骤）。

原生 API 的“降维打击”：第一性原理的回归

为什么说原生 API 才是最优解？因为它遵循了 LLM 开发的“第一性原理”。

  1. 绝对的掌控力： Prompt 是唯一的“源代码”。通过原生调用（如 openai.chat.completions.create），你清楚地知道每一个 Token 是如何发送的，System Prompt 是什么，Temperature 设为多少。
  2. 透明且高效： 没有了框架的层层封装，报错信息直指向原始代码行，Debug 成本极低。
  3. AI 编程的助力： 随着 Cursor、Claude code、Trae 等 AI IDE 的进化，编写原生代码的门槛大幅拉低。AI 理解低熵的代码比理解高熵的配置文件（如 XML/YAML）要容易得多。
  4. Skills 模式的崛起： 未来可能会从僵硬的 Workflow 模式转向基于自然语言定义的 Skills 模式。通过说明文本定义流程并调用 MCP 执行，可以达到与工作流相似的鲁棒性，却拥有更强的灵活性。

渐进式开发路径建议

尽管原生 API 可能是最优解，但这并不意味着我们要全盘否定工具，而是要否定“将它们作为默认起手式”的思维懒惰，我们需要辩证地看待他们的定位。我建议采取以下路径：

  • 第一阶段：原型与探索（裸写打基础）

    直接使用官方 SDK（如 Python + OpenAI SDK），手写 Prompt 并手动管理上下文，深刻理解 LLM 的无状态特性、Context Window 的限制、Prompt Engineering 的技巧。

  • 第二阶段：工程化与结构化（引入轻量工具）

    原生 API 返回的是字符串，难以集成到系统中。当需要结构化输出时，引入 Instructor 或 LiteLLM 等轻量级工具，强依赖 Structured Output（结构化输出），将 LLM 的输出强制转换为 JSON/Pydantic 对象。将不确定的 AI 变成确定的函数调用。

  • 第三阶段：复杂编排（按需选型）

    如果是标准化的 RAG 或简单的客服机器人，选 Dify 避免重复造轮子。

    如果是深度定制的垂直 Agent（如法律文书生成、代码审计），坚持自己写编排逻辑，尽量用原生的 Python代码if/else/while 来控制流程，而不是复杂的 Chain 类。

结语

软件工程界有一句名言：“如无必要，勿增实体”，保持简洁以降低复杂度。

在 AI 技术尚未定型的今天，过早地绑定在某个厚重的框架上，很可能在下一次模型能力跃迁时背负沉重的技术债。正如许多开发者所经历的，从 LangChain 重构到 LangGraph，最后又回归原生 API，是因为核心逻辑必须“透明且硬核”。

我们必须意识到，传统的 Workflow（工作流）模式正在向 Skills（技能）模式演进。与其在低代码平台的“连连看”中挣扎于高熵且低效的配置文件，不如拥抱 Vibe Coding 的新时代。随着 Claude Code、Gemini 等 AI 编程工具的进化，我们手里握着 AI 这把“作弊器”，编写原生代码的门槛已降至冰点，其逻辑透明度和部署灵活性远超“黑盒”平台。

返璞归真，回到 Python，回到 HTTP，回到 Prompt。

不要让繁琐的中间层掩盖了 AI 最真实的模样。在这个“第一性原理”至上的时代，真正的护城河不是你对某个工具的熟练度，而是你对业务逻辑的深度理解（Know-How）以及对底层 API 的绝对掌控力。只有在最底层的调用中，你才能构建出真正属于自己的核心壁垒。