大模型通识 / 大模型技术演进

20. 应用变复杂之后，开发框架怎样演进

本篇目录 · 8 节

来源：大模型技术演进

2023 年 7 月 18 日，LangChain 团队发布 LangSmith 的封闭测试公告。它没有宣布一个更强的新模型，而是指出了开发者正在遭遇的落差：几行代码可以搭出原型，真正把应用交到用户手里，却远没有那么容易。开发者需要看清模型究竟收到了什么、哪一步出了错，以及一次修改有没有改善结果。LangSmith 最初公告

这个节点很能说明当时的变化。ChatGPT 已经让人们看见了大模型的潜力，模型 API 又让个人开发者有机会把这种能力放进自己的产品。接下来，问题从“我能不能调用 AI”，迅速变成了“我怎样让整个应用正常工作”。

前面的文章已经遇到过这些问题：知识库要读取和检索资料，工作流要组织多个步骤，Agent 要运行工具、接受反馈，持续任务还要保存状态。模型每扩展一步能力，应用往往就多出一批需要连接和管理的环节。

本篇回看从 2022 年末到 2026 年 10 月 3 日的开发框架演进。读完后，你不必记住每个库的接口，但应该能够判断：一个框架替你解决了哪类问题，它与模型、Agent 产品和部署平台有什么区别。

第一批框架，让模型接上应用的其他部分

LangChain 的 Python 包最初发布于 2022 年 10 月 24 日，比 ChatGPT 上线还早。团队后来回顾其初衷时，强调的就是把语言模型与其他组件组合起来。LangChain 早期回顾

这件事为什么值得专门做一个框架？因为真实应用很少只有“发送一句话，打印一句回答”。你可能需要读取文件，把问题填进提示词，调用模型，再把输出转成程序能够继续处理的数据。换一个模型或数据来源，接口和返回格式又可能不同。

把反复出现的连接工作做成可复用组件，就能减少重复代码。一个“链”，可以先理解为按照一定关系组合起来的一组处理步骤。例如，先取出相关笔记，再组织问题，最后让模型依据笔记作答。

框架在这里提供的是程序结构，并没有凭空增加模型知识，也没有训练出一个新的模型。相同的模型，放进不同的应用结构里，可能因为获得了不同资料和工具而表现不同。

这里也顺便分清 SDK 和框架。SDK 是软件开发工具包，常见的模型 SDK 帮你发送请求、处理认证、读取返回结果。框架通常还会约定怎样组织组件与执行流程。不过名称没有严格分界：一个叫 SDK 的工具包，也可能已经包含完整的 Agent 循环。判断它管理什么，比看名字更可靠。

RAG 热潮，把数据处理推到了中心

2023 年，围绕个人文件和内部资料提问，成为很有代表性的应用方向。模型会回答一般知识，却不知道你的课程笔记、产品文档和项目记录，开发者需要先把这些资料送到它能使用的位置。

LlamaIndex 的侧重点正是在这里。2023 年 6 月，创始团队将它描述为连接私有数据与大模型的数据框架：不只是发起模型请求，还要处理资料的接入、组织与查询。LlamaIndex 的数据框架定位

回想第 5 篇的知识库问答：文档要被读取和切分，片段要进入索引，用户提问后要找出相关内容，最后才能生成带依据的回答。这些步骤可以由自己编写的程序完成，也可以借助框架的组件。

因此，选择数据框架时，问题不是“它会不会让模型更聪明”，而是“它是否帮我把正确资料送进了正确步骤”。如果 PDF 表格一开始就解析错了，后面换一个更强的生成模型，未必能还原缺失的信息。

Haystack 提供了另一条有前史的路线。它在 2020 年就已发布，早期服务于搜索、检索和抽取式问答。2024 年 3 月 11 日的 Haystack 2.0 稳定版，重做了组件与流水线结构，以适应生成式模型及更灵活的流程。Haystack 2.0 公告

“流水线”听起来像只能从头走到尾，但不能据此判断一个框架的能力。Haystack 2.0 已允许循环和条件路由。检索不到足够资料时，可以改写查询再找一次；输出格式不合格时，可以带着错误反馈重试。这里只是在说明当年的关键版本，并非说 2.0 是观察截止时的最新版本。

RAG 因而推动了一批共同组件发展起来：数据读取、检索、排序、生成和评估。它们后来也能被 Agent 调用。应用形态发生变化，并不意味着这些数据基础工作可以省略。

从链到图与事件：流程需要回来再走一次

当模型开始使用工具，单向流程就不再覆盖所有需要。模型可能先检索，发现资料冲突后重新检索；也可能运行代码，读到报错后修改，再运行一次。

2024 年 1 月 17 日，LangChain 团队专门介绍 LangGraph，重点就是用可以形成循环的图来构建 Agent 运行流程，同时让开发者保留对执行路径的控制。LangGraph 最初公告

这里的“图”不是统计图表。可以把它理解为流程结构：节点代表处理步骤，连线表示下一步可以去哪里。与此同时，系统保存一份状态，记录已获得的资料、当前结果和下一步需要的条件。

以下是一个教学构造，沿用本系列的复习助手。它不是某个框架的直接运行结果：

flowchart LR
    A[接收笔记] --> B[检索相关资料]
    B --> C[生成卡片草稿]
    C --> D{来源和字段合格吗}
    D -->|不合格且仍可重试| B
    D -->|合格| E[用户查看草稿]
    D -->|不合格且达到重试上限| G[保留草稿并说明问题]
    E -->|确认| F[写入卡片库]

这个结构里，有的判断交给普通代码，例如字段是否齐全；有的判断可能使用模型，例如卡片是否准确概括了来源。框架负责组织执行，并不要求每个节点都调用 AI。

图也不是唯一方式。LlamaIndex 在 2024 年 8 月 1 日推出 Workflows 测试版，采用事件驱动的组织方式：某一步完成后发出事件，接收这种事件的步骤继续处理，也可以发出重试事件。LlamaIndex Workflows 公告

用上面的例子解释，生成步骤发出“草稿已完成”，校验步骤发现问题后发出“需要补充资料”。开发者可以围绕这些事件安排处理函数，而不必用同一种方式显式列出所有连线。

图和事件的差别，主要在于怎样表达程序结构。二者都可能支持状态、循环与分支；也都需要停止条件。不要把“能循环”理解为“应该一直让模型尝试下去”。

随着这些经验积累，LangChain 与 LangGraph 的关系也发生了变化。2025 年 10 月 22 日，两者发布 1.0：LangChain 更集中于常见 Agent 模式，LangGraph 提供更底层的流程控制与运行能力；LangChain 的 Agent 建立在 LangGraph 之上。当前 LangGraph 文档也明确，它可以不依赖 LangChain 使用。1.0 发布说明、LangGraph 定位

所以，旧教程里的“LangChain 组件库”和新教程里的“LangChain Agent”，不一定在讲相同版本的设计。理解演变关系，比机械复制旧代码更重要。

多 Agent：把协作方式也写进程序

除了安排步骤，开发者还尝试另一种组织方式：让多个 Agent 分工，通过消息交换完成任务。

微软研究院在 2023 年 9 月 25 日介绍 AutoGen，将多 Agent 对话作为组织复杂应用的方式。参与者可以结合模型、工具和人，并不要求每个角色都是一个独立训练的模型。AutoGen 最初介绍

一个教学例子是，让资料整理者收集证据，写作者生成草稿，检查者核对引用。它们可以使用同一个模型，却分别得到不同的任务说明、上下文和工具。应用需要决定谁先工作、把哪些结果传给谁，以及何时结束。

这种分工有时能减少单个 Agent 面对的上下文，让独立任务并行推进。但它也增加了沟通成本：资料可能在交接中丢失，多个角色可能重复搜索，检查者也可能接受写作者的错误说法。“三个 Agent 都同意”不能代替对原始证据的核查。

CrewAI 将角色、目标、任务和协作组织成 Crews。到本篇观察时，它的文档同时强调 Flows：由流程管理状态和执行顺序，再把需要自主协作的工作交给一个 Crew。CrewAI 架构说明

这说明多 Agent 与明确工作流并不互斥。你可以把一个研究小组放在某个步骤里，外层仍然用程序决定什么时候保存文件、什么时候等用户查看、什么时候终止任务。角色分工是一种组织手段，不是所有项目都要达到的升级目标。

微软这条路线后来又出现了整合。Semantic Kernel 注重把模型与现有应用功能结合，AutoGen 积累了多 Agent 协作经验；Microsoft Agent Framework 汇集两者的设计，并在 2026 年 4 月 3 日发布面向 .NET 和 Python 的 1.0 版本。Microsoft Agent Framework 1.0 公告

截至观察日期，微软文档把 Agent Framework 定位为两者的下一代框架，并提供迁移路径。阅读历史资料时仍然需要认识 AutoGen 和 Semantic Kernel；开始新项目时，则应重新核对当前维护与迁移建议，不能因为旧教程很多，就假定生态从未改变。微软框架关系说明

框架也要进入开发者原有的语言和产品

大模型应用开发并不只发生在 Python 脚本里。一些人熟悉网页前端，另一些人已有 Java 后端。让他们在原有项目中接入模型，同样会推动框架发展。

2023 年 6 月 15 日，Vercel 发布 AI SDK，最初强调 JavaScript、TypeScript 应用中的流式响应与聊天界面。AI SDK 首发公告

“流式”就是结果生成一点，界面就显示一点，不必等全部完成。这看似只是体验细节，实际需要协调服务端响应、前端消息状态、错误和取消操作。模型回答再好，如果页面一直卡在加载中，用户也很难使用。

随着应用从对话走向行动，这条路线也向 Agent 扩展。2026 年 6 月 25 日的 AI SDK 7 公告，介绍了实验性的 HarnessAgent：通过统一接口运行 Claude Code、Codex 等已有 Agent 执行系统。AI SDK 7 公告

这里的 Harness 可以暂时理解为围绕模型组织工具调用、上下文和执行循环的配套系统。此时接入的已经不只是一份模型回答，而是一段能够继续工作的任务。实验性接口仍可能变化，不能把它当作从 2023 年首版就存在的能力。

Java 生态中的 Spring AI，则让熟悉 Spring 的开发者用相近的开发习惯接入模型、检索和工具。2025 年 5 月 20 日发布的 1.0 正式版，包含模型交互的 ChatClient、向量存储等接口。Spring AI 1.0 公告

它的意义不在于要求大家转向 Java，而在于大模型能力开始进入已有的软件体系。个人项目如果本来就是网页应用，不必为了“做 AI”先重写所有后端；已有 Java 服务，也不必默认额外搭一整套 Python 系统。

模型厂商也开始提供 Agent 开发工具

当工具使用、长任务和编程成为模型的重要能力，厂商自然也会提供更靠近这些能力的开发工具。

Google 在 2025 年 4 月 9 日发布开源 Agent Development Kit，简称 ADK，面向 Agent 和多 Agent 应用，强调编排、工具集成、评估与部署路径。它与 Google 生态紧密结合，但设计上也支持不同模型与部署环境。Google ADK 公告

OpenAI Agents SDK 则让开发者在自己的应用中组织 Agent、工具与任务交接，由运行器处理循环。它与直接调用模型的 API、由服务端管理的 Agent 运行服务，是不同层次的选择。OpenAI Agent 开发方式说明

Anthropic 在 2025 年 9 月 29 日介绍 Claude Agent SDK，将 Claude Code SDK 更名，表达的方向是：支撑编程助手的执行系统，也可以用于其他类型的工作。Claude Agent SDK 说明

这几条路线又把“SDK”的含义拉宽了。有的主要封装模型请求，有的已经管理完整行动循环，还有的提供较现成的工具与执行能力。选用之前，应先问清楚：循环在哪里运行，文件存在哪里，工具由谁执行，哪些状态需要自己保存。

厂商提供工具，并不意味着第三方框架失去价值。跨模型连接、已有数据组件、程序结构和部署方式，仍然可能影响选择。反过来，也不必因为项目叫“Agent”，就先套入一个庞大的通用框架。

从代码库到调试和部署，生态逐步补齐

我们现在可以回到开头的 LangSmith。编写流程解决“让哪些步骤运行”，观察工具解决“它刚才究竟怎样运行”。两件事相关，却不是同一件事。

以知识库回答错误为例，最终答案只告诉你结果不对。逐步记录可以帮助判断：文件没有读入，检索拿错了片段，提示词漏掉了限制，还是模型没有遵循已经提供的证据。这就是可观测性在这里的实际含义。评估则进一步用一组固定任务检查修改有没有改善效果，详细方法留到第 22 篇。

任务变长以后，部署也不能只理解为“给函数加一个网址”。用户关闭页面以后任务是否继续，服务重启以后怎样恢复，用户晚些时候确认草稿后怎样接着执行，都需要运行基础设施。

LangGraph Platform 在 2025 年 5 月 14 日正式可用，面向长时间、有状态的 Agent 部署；官方公告后来注明，它在同年 10 月更名为 LangSmith Deployment。部署产品的演进

由此可以把容易混在一起的几个名称分开：LangChain、LangGraph 是应用开发和执行框架；LangSmith 提供观察、评估等平台能力，其 Deployment 产品承担部署服务。它们可以配合，但安装一个开源库，不等于已经购买、配置或使用了云端平台。

同理，第 6 篇介绍的 Dify、Coze 等可视化平台，与这里的代码框架也有交集：都在组织模型、资料和步骤，只是提供的使用入口和产品配套不同。能够在画布上连接节点，不代表底层没有代码；能够用代码定义图，也不代表必须拥有一套可视化平台。

对个人项目，先找出真正缺少的那一层

看过这些演变以后，容易产生一种新的负担：是不是必须把所有框架都学会，才算会开发大模型应用？

可以回到一个很小的需求。如果复习助手目前只需要“输入笔记，生成三张卡片”，模型 SDK 加上普通程序可能就足够。你应当先看清请求、返回结果和保存的数据，再决定需要什么帮助。

随着需求增长，可以按下面的方式定位问题。这不是互斥选型表，同一产品可能覆盖多层，也不要求把列出的工具全部安装。

项目遇到的问题	需要理解的能力	本篇对应的代表路线
不同资料难以接入和检索	数据处理、索引、检索组件	LlamaIndex、Haystack，以及 LangChain 的相关集成
任务有分支、重试和人工查看	流程编排、状态与恢复	LangGraph、Workflows、CrewAI Flows、Agent Framework
希望按职责分工完成复杂任务	Agent 协作和结果交接	AutoGen 的历史路线、CrewAI、厂商 Agent SDK
需要接入已有网页或 Java 项目	界面、语言与后端集成	Vercel AI SDK、Spring AI
任务能运行，却难以定位错误或长期提供服务	观察、评估与部署	LangSmith 等配套工具与运行平台

继续用刚才的卡片流程做一次设计检查：草稿放在哪里，用户确认之前会不会写入正式卡片库，重试后是否会重复保存，关闭程序再打开是否还能找到待处理任务？这些问题的答案，比“我用了几个 Agent”更能说明架构是否清楚。

框架可以减少重复工作，但它也会带来需要理解的结构、版本和默认行为。真正有价值的选择，是引入之后你更容易解释程序怎样运行，也更容易检查它有没有做对。

从早期组件连接，到数据框架、循环编排、多 Agent，再到语言生态和运行平台，框架的发展一直追随应用的问题变化。更强的模型让更多任务成为可能，框架则帮助开发者把这些能力组织成可以使用的程序。

接下来还有一个问题：即使流程写好了，模型怎样认识外部工具，不同系统怎样交换任务，可复用的能力又怎样交给 Agent？下一篇将把 Function Calling、MCP、A2A、Skills、插件与连接器放在一起，分清它们各自连接的是什么。

上一篇：19｜截至 2026 年 10 月：模型能力与应用边界推进到了哪里

下一篇：21｜模型、工具与任务能力怎样连接起来

返回：第 0 部分大纲