MCP on 小盒子的技术分享

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

Sat, 11 Apr 2026 10:50:21 +0000

事情是这样的。

最近我几乎每天都在用Claude Code写东西。用得越多，我越产生一种奇怪的感觉。

就是你给它下完一个任务之后，它开始一步一步地干活。先是啪，读了一个文件。然后哒，想了几秒。然后啪，又打开一个文件。再想几秒。再打开一个文件。就这么一直持续下去。

你坐在椅子上看着进度条一格一格地亮起来，心里清楚得不能再清楚，这十个文件它明明可以一起读的，它们之间根本没有任何依赖关系。

但它就是不。它就是要一个接一个地来。

一时间无语凝噎。

后来我跟几个同样重度用Agent的朋友聊了一下，他们也都有这个感受。说真的我始终觉得这是现在所有Agent产品共同的一个病，不管是 Claude Code、Cursor、Manus还是那些MCP插件，只要你让它干稍微复杂一点的活，你就会看到它在那里慢悠悠地一步一步走，像一个做事非常有耐心但完全不会一心二用的老实人。

前两天跟朋友吐槽这事的时候，我又想起了两年前Berkeley那帮人写的一篇论文。论文叫LLMCompiler，2024年就发在ICML上了，现在回头看它也不算新东西。但每次我被Agent气到的时候都会想起它，觉得它的思路到今天都没过时，甚至越品越有味道。

它当时就已经把这个病的根源讲得很清楚了，这个慢不是LLM的错，也不是任务复杂度的错，是我们给它用的那套调度系统，还停留在1960年代的水平。

这篇论文的名字挺干的，叫**《An LLM Compiler for Parallel Function Calling》**，ICML 2024。作者是Sehoon Kim、Amir Gholami那帮人，都在Berkeley和LBNL。它不是今年的新论文，但在我心里一直是Agent方向上最被低估的几篇之一。

它在做的事其实非常cool。

它在把大学一年级《计算机组成原理》那本书里的东西，原样搬到LLM的世界里。

坦率的讲，你想想看过去60年整个计算机体系结构的历史，其实就是一部「怎么让本来是串行的指令跑得更并行」的历史。指令流水线、乱序执行、超标量、分支预测，这些听着就头大的名词，说到底都是在干一件事，就是让CPU不要一条指令一条指令傻乎乎地等，能同时干的活就一起干。

这套东西人类已经研究得非常透了。透到什么程度呢？透到你今天买一颗普通的i5芯片，它每个时钟周期能同时发射的指令数，大概是80年代那种整栋楼的超级计算机的水平。

但是。

当我们把LLM当成一种新型处理器去用的时候，这套智慧全忘了。

现在几乎所有的Agent框架，底层都是一个叫ReAct的东西。它是Yao等人2022年提的，全称是Reason + Act。工作方式非常朴素，想一步，做一步，看结果，再想一步，再做一步，再看结果。它是一个循环。

听着很自然对吧？它确实自然。但你仔细看就会发现，这玩意从执行效率上来说，跟那种每次只能执行一条指令、做完一条才开始下一条的远古处理器，是一样的。

一次一条。干等。

而且这个问题在越来越多的Agent场景里暴露得越来越厉害，因为我们现在给Agent的活越来越复杂，一次要调用的工具越来越多。ReAct的串行执行就成了一个越来越重的镣铐。

回到LLMCompiler这块。

作者的思路简单粗暴，既然Agent执行工具调用的过程跟CPU执行指令长得一样，那就直接套编译器的架构好了。他们搞了三个组件。

第一个叫 Function Calling Planner，函数调用规划器。你可以把它想象成编译器里那个分析语义、构建依赖图的部分。用户给了一个问题，比如论文里举的那个例子，「微软的市值需要涨多少才能超过苹果？」，Planner要做的事情是先把这个问题拆成几个独立的任务，再搞清楚这些任务之间谁依赖谁。

它会拆成三步。

一，去查微软的市值。二，去查苹果的市值。三，用一个数学工具做减法，把差值算出来。

然后它会发现一件事，任务1和任务2，彼此没有任何关系。它们完全可以同时去查。只有任务3需要等前两个都拿到结果。

这就是一张 DAG，有向无环图，编译器里最核心的数据结构之一。

第二个组件叫 Task Fetching Unit，任务获取单元。这个名字直接就是从CPU里偷来的。

在现代CPU里有一个东西叫指令获取单元，它的任务是一旦前一条指令把某个寄存器的值算出来了，立刻把依赖这个寄存器的下一条指令发射出去，别等一整串指令都准备好再开搞，那样太慢。

LLMCompiler的Task Fetching Unit做的事完全一样。Planner一吐出DAG，它就开始扫描，发现哪些任务的依赖已经解决了，立刻往下扔。任务1和任务2没有依赖？好，同时发射，两个搜索并行执行。任务3等着1和2的结果？好，等它们回来我再把结果塞进任务3里，然后发射。

整个过程是流式的。Planner一边在吐计划，执行器一边在干活，中间没有「等Planner把所有计划全想完再开始」这种停顿。论文里专门做了个消融实验，流式处理本身就贡献了一个量级的加速。

第三个组件叫 Executor，执行器。这个没啥好说的，它就是真正去调工具的那个家伙。Task Fetching Unit告诉它哪个工具可以调了，它就调。

三个东西加起来，整个架构就跟一台小号的CPU一模一样。有人分析程序，有人调度，有人执行。

说到这我真的有点被打动。你知道我为啥被打动吗？因为这个思路其实任何一个学过编译原理的本科生都能想到。它没有任何复杂的数学，没有什么神秘的训练技巧，就是把一个用了60年的老配方，拿来炒一道新菜。

但它偏偏有效。而且效果好到离谱。

顺着上面的再聊聊，这篇论文最让我兴奋的其实是实验结果部分。

作者用了四个benchmark来测试LLMCompiler。这四个测试排起来有一个隐藏的升番结构，从最简单的场景到最复杂的场景，效果一个比一个炸。我逐个说一下。

第一个叫HotpotQA。这是个很经典的多跳问答数据集，论文的Figure 1就举了一个例子，「斯科特·德瑞克森和埃德·伍德是不是同一个国籍？」这种问题。用ReAct的话就是一步一步来，先搜A，拿到结果，再搜B，拿到结果，再对比。用LLMCompiler的话，A和B可以同时搜。

速度快了1.8倍。成本降了3.37倍。准确率基本一样。

就这个结果拎出来看已经很能打了，但它只是开胃菜。

第二个叫Movie Recommendation。这个更有意思，它每次要你从8部电影里找出跟某部电影最像的那部。也就是要对8部电影分别做独立的搜索和分析。

ReAct在这里干了一件特别傻的事。论文附录里有一张图我看完直接笑出声，它显示有大约85%的样本，ReAct根本没搜完8部就结束了。它搜到第五部就停下来，觉得「我好像够了」，然后给一个答案。

你敢信？？？

一个号称能干活的Agent，居然连把活干完都做不到。它会提前认输。

LLMCompiler在这里就完全没这个问题，因为Planner一开始就把8个任务全部规划好了，Executor必须全部执行完才能汇总。结果是速度快了3.74倍，成本降了6.73倍，准确率还反超ReAct 7个多点。

第三个叫Game of 24。这游戏你们可能玩过，给你4个数字让你用加减乘除搞出24。之前最强的解法叫Tree-of-Thoughts，让LLM自己去搜索各种可能的组合。LLMCompiler在这里做了一个很骚的事，它把「Tree-of-Thoughts的一次尝试」当成一个工具，然后让Planner去并行调度这些尝试。

速度快了2倍。

到这里我已经觉得够牛了。

但是真正让我给整不会的是第四个benchmark，WebShop。这是一个模拟网上购物的环境，你要在一堆商品里找到符合某些需求的那一个。典型的操作是搜索→看结果→再搜索→再看结果。

LLMCompiler在这里直接跑出了101.7倍的加速。

不是10倍，不是50倍，是一百零一点七倍。

而且成功率还比ReAct高了25.7个百分点。

我第一次看到这个数字的时候真的愣住了。我来回看了好几遍论文的表格，生怕自己看错了小数点。101.7x。

它的原因其实非常直观。WebShop里有大量「先广撒网再选最优」的搜索动作。LLMCompiler可以一口气把所有候选搜索并行发射出去，而ReAct得一个一个搜。你想想，如果你在淘宝上找一个东西，你是一次打开十几个标签页横向对比，还是一个一个点开再返回再点开？

答案很明显。

但前者需要你有一个「规划」的能力，得先知道哪十几个是值得看的。这恰好就是LLMCompiler在做的事。

这块需要注意一下。LLMCompiler的意义不只是快，还有一个更深的点，它顺手救了准确率。

这个我刚才提到了一嘴，但值得展开说说。作者分析了ReAct失败的案例之后发现，这些失败的绝大多数其实跟智力无关，跟纪律有关。

两种典型的失败场景。一种是提前收工，它只搜了部分信息就觉得够了，开始瞎答。另一种更惨，是它会在同一个查询上无限循环，因为Wikipedia返回的信息不够精确，它就一直搜一直搜一直搜，直到context window爆掉。

这两种失败加起来，贡献了ReAct绝大部分的失败样本。

为啥会这样？我自己的理解是，ReAct是一种即兴架构。它没有全局视野，每一步都是基于上一步的观察临时决策的。这种即兴决策模式很像我们人脑，但它也天然带着人脑即兴决策的毛病，容易累、容易放弃、容易走进死胡同。

LLMCompiler强迫模型在一开始就把所有要做的事列出来，这等于逼着它做一次系统性的规划。规划好了之后，执行阶段就只负责执行，不再思考。

我觉得这里有一个非常深的启发。我们过去几年一直在迷信让LLM多想一步，搞出了Chain-of-Thought、Tree-of-Thoughts、Self-Reflection各种花活，都是在鼓励模型「思考得更细、更久、更多」。但其实有时候反过来，让它先想一次然后别再想了，反而更管用。

CPU的设计哲学其实也是这样。现代CPU里最快的指令是那些不需要跳转、不需要预测、不需要动态决策的指令。凡是涉及到走一步看一步的指令，都会拖慢整条流水线。

计算机硬件的人早就发现了，即兴决策是昂贵的。

而这个老道理，现在又回到了AI Agent这边。

坦率的讲，我觉得LLMCompiler这篇论文本身可能不是最大的新闻。真正的新闻是它揭示的那个更大的趋势。

我们正在把整个计算机体系结构，重新发明一遍。

你仔细想想这几年LLM推理和Agent方向上那些最亮眼的突破，几乎每一个都能在老教科书里找到原型。

Speculative decoding，是把CPU的分支预测搬到了LLM推理。 KV cache，是把CPU的cache机制搬到了LLM推理。 Continuous batching，是把操作系统的进程调度搬到了LLM推理。现在LLMCompiler，是把编译器的指令调度搬到了LLM Agent。

每一个都在发生。每一个都带来10倍甚至100倍的加速。每一个的核心创意都不是横空出世的神来之笔，而是一句「等等，这个问题我们在硬件/OS层面已经解决过了，直接拿来用就好」。

卡帕西前阵子说过一句我记了很久的话，他说LLM是一种新的计算机，一种以自然语言为指令集的计算机。这句话如果你真的认真对待，那它的所有推论都是自洽的。既然它是一种新的计算机，那我们给旧计算机发明的所有优化技巧，理论上都应该能再用一次。

我有时候会觉得，我们这一代做AI的人特别幸运。我们在亲眼看一部已经拍过一遍的电影，被用新的道具重新拍摄。剧本是一样的，角色是一样的，剧情走向都是一样的。但因为道具全换了，看起来就像一部全新的片子。而且你手里只要有一本原版的剧本，你就能提前知道下一幕会发生什么。

回到这篇论文本身。

我觉得它最重要的贡献其实不是那些benchmark数字，而是它开了一个非常清晰的方向。那就是Agent的慢不是不可解决的。

你今天用Claude Code等十分钟，不是因为LLM笨，也不是因为你的任务太复杂。是因为底下那套调度系统还在用ReAct这种20世纪60年代级别的执行模式。只要换上哪怕一个粗糙的编译器思路，立刻就能快10倍、快100倍。

其实这两年已经有不少框架在往这个方向走了，LangGraph、LlamaIndex都陆陆续续搞过类似的planner组件，多Agent框架里的并发调度也都能看到这套思路的影子。但奇怪的是，我们日常在用的那些最主流的Agent产品，Claude Code、Cursor这些，还是没有把这套东西吃得特别透。你还是经常能看到它们在那里一步一步串行地跑，跑得你抓狂。

我始终觉得这是一件很可惜的事。一个两年前就该被充分吸收的好思路，到今天还只在部分框架里存在，绝大多数用户还是在吃ReAct的苦。

其实之前OpenAI做过一个简化版，它叫Parallel Function Calling。但这篇论文里也明确对比了，OpenAI那个只能处理最简单的、完全独立的并行任务，一碰到有依赖关系的就歇菜了。LLMCompiler能处理有依赖的完整DAG，这是质变。而且论文在ParallelQA这个他们自己造的benchmark上，直接把OpenAI的并行函数调用给干穿了。

还有一个让我很开心的点，LLMCompiler不依赖特定模型。它能跑在闭源的GPT系列上，也能跑在开源的LLaMA-2 70B上，效果都很好。这意味着你要用它，不需要求爷爷告奶奶去办一个特殊API，自己拿个开源模型搭一套就能跑。对整个开源生态是实实在在的利好。

论文的代码早就开源在 https://github.com/SqueezeAILab/LLMCompiler ，这两年我零零散散跑过一些例子，整体感觉是它确实好使，但对Planner的prompt质量非常敏感，稍微写粗糙一点就容易崩。这大概也是为啥它没在主流产品里全面铺开的原因之一，论文里优雅的架构，落到工程上总会多出一堆脏活。

最后说点题外话。

我一直觉得AI这个行业最迷人的地方，就在于它需要你是一个杂食动物。你得懂一点机器学习，懂一点系统，懂一点产品，懂一点用户。因为AI正在跟所有领域发生化学反应，任何一个你以为已经过时的角落，都可能突然长出一个全新的方向。

LLMCompiler这篇论文就是一个典型的例子。它既不需要你是最顶尖的ML研究员，也不需要你是最强的系统工程师。它需要你有一个能从「我的LLM Agent跑得好慢啊」跳到「诶等等，CPU当年也有这个问题，是怎么解决的来着？」的跨界联想能力。

我始终觉得这种联想能力，比任何单一领域的深度都重要。

很多朋友问我怎么跟上AI的发展。我有时候觉得，与其拼命去看最新的模型发布，不如回头去翻翻那些老的、经典的、看起来跟AI毫无关系的书。编译原理、操作系统、计算机网络、数据库系统、图形学。这些书里有太多你以为已经过时的东西，在LLM时代突然又活了过来。

你读过的每一本旧书，都可能在未来某天变成一枚重新上膛的子弹。

前提是你得先把枪挂在墙上。

以上。

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

OpenAI DevDay [2025] 概览

Tue, 07 Oct 2025 04:46:54 +0000

来源：https://openai.com/devday/ 本文我们针对 DevDay[2025] 中涉及的以下内容进行简要介绍

Apps in ChatGPT

Apps in ChatGPT 是 OpenAI 推出的一种新型交互式应用程序，用户可以直接在 ChatGPT 平台内通过自然语言与这些应用进行对话，从而提升创作、学习和生产力。

交互式应用集成

用户可以直接在 ChatGPT 对话中与新一代的应用程序进行交互。可以通过直接呼叫应用名称或在相关情境下由 ChatGPT 推荐来启动这些应用。这些应用拥有可在聊天中直接使用的交互式界面。

自然语言启动

用户可以通过自然语言指令来使用应用。

例如，直接对 Spotify 说 “Expedia 帮我订一张明天从北京飞往东京的机票”。

例如，直接对 Canva 说: “Canva 请帮我做一个宠物商店的海报，要明亮背景”。

开发者工具 (Apps SDK)

OpenAI 发布了新的 Apps SDK（应用程序开发工具包）预览版，让开发者可以开始构建这些应用。该 SDK 是一个基于模型上下文协议（MCP）的开放标准。

Apps SDK 是开源的，文档和示例可在 https://developers.openai.com/apps-sdk 获取。对开发者来说，可触达超过 8 亿 ChatGPT 用户，并在未来实现变现。

首批合作伙伴

●首批上线的应用来自 Booking.com、Canva、Coursera、Expedia、Figma、Spotify 和 Zillow 等合作伙伴。

●即将推出的合作伙伴包括 AllTrails、Peloton、OpenTable、Target、theFork、Uber 等，今年晚些时候上线。它们涵盖了旅行、食物外卖、教育、健身、零售和本地服务等类别，旨在使 ChatGPT 成为处理日常任务的更通用平台。

安全与隐私

所有应用都必须遵守 OpenAI 的使用政策。在用户首次使用某款应用时，系统会提示用户进行连接，并明确告知哪些数据可能会被共享。

未来规划

未来，OpenAI 计划将应用推广到商业版、企业版和教育版 ChatGPT，并开放应用提交通道，建立专门的应用目录。同时，还将公布关于应用变现的更多细节

AgentKit

AgentKit 是一套完整工具集，旨在帮助开发者和企业构建、部署和优化代理（agents）。它解决了代理开发中的碎片化问题，如复杂的编排、自定义连接器和手动评估管道。

工作原理

AgentKit 提供了一套集成工具，用于简化创建和管理代理的过程。它包括视觉和编程界面，用于设计工作流、嵌入聊天体验以及评估性能，支持拖拽节点、版本控制和自动化优化。

主要功能

Agent Builder

视觉画布，用于创建和版本化多代理工作流，支持拖拽节点、预览运行、内联评估配置，以及预构建模板。

可通过 https://platform.openai.com/agent-builder/edit 访问使用。

●截至 2025 年 10 月 7 日（当前日期），Agent Builder 暂不收费。计费将于 2025 年 11 月 1 日开始，在此之前不会产生任何费用。这意味着在 beta 期间，你可以免费使用它，但使用过程中涉及的 API 调用（如调用模型）会按照标准 API 定价计算（不过目前整体免计费）。

●从 11 月 1 日起，Agent Builder 的使用将基于 API 模型的查询定价，例如 GPT-4o 的搜索定价从每千查询 30 美元起。定价和功能可能在从 beta 转向正式可用时调整。

与 n8n 、Dify 的区别

以下表格对比三者的核心差异：

Agent Builder 确实像 n8n 的 “克隆” 版，更注重 OpenAI 内部优化，而 n8n 更通用、集成强；Dify 则更 AI 导向，与 Agent Builder 在代理开发上最相似，但独立于 OpenAI。如果用过 n8n 或 Dify，切换到 Agent Builder 可能很顺手，但取决于是否需要 OpenAI 的模型深度集成。Coze 危！

Connector Registry

中央管理面板，用于管理 OpenAI 产品中的数据和工具连接，包括预构建连接器如 Dropbox、Google Drive、Sharepoint 和 Microsoft Teams，以及第三方 MCP。

ChatKit

不用自己建聊天 UI，就能做出专业级助手。和 OpenAI 的其他工具无缝连用。

从整体定位看，ChatKit 作为 AgentKit 的一部分，专注于前端聊天界面的快速集成，降低了开发者构建 AI 驱动聊天应用的门槛。它强调无缝嵌入现有产品中，支持从简单聊天到复杂代理工作流的扩展，特别适合企业级应用。

简单说就是帮你快速在网站或 App 里加一个聊天窗口，让用户能和 AI 聊天办事。它不是从零自己写代码，而是像搭积木一样，轻松嵌入现有的产品里。想象一下，你想在你的网站上加个 AI 助手，能帮用户问问题、上传文件、甚至调用其他工具解决问题 ——ChatKit 就是干这个的。

怎么用？

ChatKit 有两种用法：

1.简单方式（推荐）：用 OpenAI 的 “Agent Builder”（另一个工具，像画图一样设计 AI 的工作流程）先搭好后端逻辑，然后把 ChatKit 嵌入前端。OpenAI 帮你管服务器，不用自己操心。

2.高级方式：如果你想自己控制一切，用 Python 代码在自家服务器跑 ChatKit，后端连你自己的 AI 系统。

核心是，它提供现成的聊天界面：用户输入文字、上传文件，AI 回应，还能显示 AI 的 “思考过程”（比如一步步推理），让一切更透明。

搭建步骤

更详细内容参考：https://platform.openai.com/docs/guides/chatkit

1.先搭 AI ：用 Agent Builder 设计 AI 的 “工作流程”（比如，如果用户问天气，就调用天气工具）。这步生成一个 ID。

2.设置聊天窗口：在你的服务器上创建 “会话”（用代码生成一个安全令牌），然后在网站前端安装 ChatKit 的 React 组件（一种网页代码框架）。加几行代码，就能看到聊天框了。

3.优化调整：试用后，改改外观、加自定义按钮，或优化 AI 的提示语，让它更聪明

Evals Capabilities

新功能包括数据集、跟踪评分、自动化提示优化，以及第三方模型支持，用于测量和改进代理性能。

Reinforcement Fine-Tuning (RFT)

自定义工具调用和自定义评分器，用于增强模型推理，在 OpenAI o4-mini 上可用，并在 GPT-5 的私有 beta 中。

Sora 2 API

Sora2 API 发布了，可以这样接入：

 1⚡ python片段from openai import OpenAI
 2
 3openai = OpenAI()
 4
 5video = openai.videos.create(
 6 model="sora-2",
 7 prompt="A video of a cool cat on a motorcycle in the night",
 8)
 9
10print("Video generation started:", video)

目前发布了两个模型：

●sora-2

●sora-2-pro

区别是：

总的来说，如果你只是玩玩或赶工，选 Sora 2；想出精品，Pro 更值。两者都通过 API 或 app 用，内容有严格限制。

使用指南

1.提交任务：用 POST /videos 接口发请求，带上模型（sora-2）、提示语、尺寸（如 1280x720）和时长（如 8 秒）。它会给你一个任务 ID。

2.检查进度：用 GET /videos/{id} 轮询状态，或者设置 webhook（一种自动通知）来收完成或失败的消息。

3.写好提示：要具体！比如描述镜头类型、主体、动作、场景和光线。比如：“广角镜头，一个小孩在草地公园放红风筝，金色夕阳光线，镜头慢慢向上摇。”

4.内容限制：适合 18 岁以下观众，不能用版权角色或音乐，不能生成真人（包括名人），输入图片不能有脸（以后可能有例外）。

5.用图片开头：可以上传图片作为第一帧，支持 JPEG、PNG、WebP 格式，但尺寸要匹配。

6.改视频（Remix）：用已生成的视频 ID 和新提示，针对性调整，比如改颜色或加元素。最好一次只改一件事，避免乱套

Codex 正式版发布

全球开发者爱用它，包括初创公司如 Duolingo 和 Vanta，大厂如 Cisco 和 Rakuten。甚至 OpenAI 自己内部，几乎所有工程师都靠它干活，比 7 月时多了 50%，每周合并的代码拉取请求（PR）多了 70%，几乎每个 PR 都自动审一遍。

主要新功能有：

●Slack 集成：直接在 Slack 频道或线程里扔任务，比如 “帮我修这个 bug”，它自动拉上下文、选环境、云端干活，然后发链接给你 —— 想合并代码或本地改，就点开继续。超方便，不用切工具。

●Codex SDK：一个工具包，能把 Codex 嵌入你的自定义流程、App 或脚本里（现在支持 TypeScript，更多语言快来了）。它优化了结构化输出和上下文管理，还带 GitHub Action，帮你塞进 CI / CD 管道（比如自动测试代码）。

●管理员工具：给企业用户的新面板，能管环境、监控使用、看分析仪表盘。比如删云环境、设安全默认值、跟踪 CLI/IDE/网页的使用情况。让大团队规模化用得安心。

从 2025 年 10 月 6 日起，ChatGPT Plus、Pro、Business、Edu 和 Enterprise 用户都能用 Slack 集成和 SDK。管理员工具限 Business、Edu 和 Enterprise。从 10 月 20 日起，云任务开始算使用量（之前免费）。

GPT-5 Pro

GPT-5 Pro 是 OpenAI 的 GPT-5 系列的一个 “加强版” 模型，专为处理难题设计的。它用更多计算资源 “多想一会儿”，输出更准、更靠谱。不同于普通版，它只通过 Responses API 用，支持多轮对话和未来高级功能。现在（2025 年 10 月）正式可用。

核心能力：

●上下文窗口大：能记住 40 万个 token 的上下文（相当于超长对话），输出最多 27.2 万 token（长文没问题）。

●支持模式：文字输入输出都行，图片只能输入（比如分析图），音频和视频暂不支持。

●推理模式：默认 “高强度思考”（reasoning.effort: high），带推理 token 支持，让它一步步推导问题。

●工具集成：能上网搜、搜文件、生成图片，还支持 MCP（模型控制面板）。但不支持代码解释器、电脑操作、流式输出、微调或蒸馏。

●其他：支持函数调用和结构化输出，适合复杂任务。

总之，它像个 “深度思考者”，不光聊天，还能帮你解难题，但专注文字和图片。

定价:

●文字 token：输入 $15/百万 token，输出 $120/百万 token（贵！比 GPT-5 的 $1.25/百万输入贵多了）。

●其他：工具调用额外收费，详情看定价页。比 o3-pro（输入 $20）也贵，适合高价值任务。

GPT-Realtime-Mini

GPT-Realtime-Mini 是 OpenAI 的一个 “轻量级” 实时 AI 模型，简单说就是个能快速聊天的 “语音助手”，专为低成本、实时互动设计。它能听你说话（或看图片）、实时回复文字或语音，适合建语音 App、客服机器人或游戏对话。

核心能力

●实时互动：通过 WebRTC、WebSocket 或 SIP 连接，处理音频 / 文本输入，瞬间输出回应。像视频通话里的 AI 伙伴。

●支持的东西：文本（输入/输出）、图像（只输入，比如描述图片）、音频（输入/输出，比如语音转文字或合成语音）。视频不支持。

●记忆力：上下文窗口 32,000 tokens（够聊长对话），最大输出 4,096 tokens。

●知识截止：到 2023 年 10 月 1 日（老了点，新事得靠工具补）。

●其他：有 “快照” 版本，能锁住模型不乱变。没高级玩意儿如函数调用、结构化输出、微调或预测。

定价（按百万 tokens）：

●文本：输入 $0.60，缓存输入 $0.06，输出 $2.40。

●音频：输入 $10，缓存 $0.30，输出 $20。

●图像：输入 $0.80，缓存 $0.08。总的贵在音频上，但比大模型便宜。

GPT-Image-1-Mini

GPT-Image-1-Mini 是 OpenAI 推出的一款 “经济实惠版” 图像生成模型，能用文字描述或现有图片快速生成或编辑图像。它是 GPT Image 1 的 “小弟”，更便宜、更高效，适合开发者嵌入到 App 里，比如设计工具或内容平台，不用花大钱就能玩转 AI 画图。

核心能力：

●生成新图：输入文字提示，就能吐出高质图片。比如 “一个可爱的猫咪在太空飞翔”，它会懂上下文，画出逼真或搞怪的图。

●编辑旧图：支持 “补画”（inpainting），用面具遮住部分区域改内容，比如加东西、删元素或换颜色。还能用参考图复制风格，确保一致性。

●输入输出：进货是文字 + 图片，出货是新图像。能调质量（低中高）、尺寸（比如 1024×1024 或长宽 1024×1536），还有 “输入保真度” 控制输出多像原图。

定价按 “token” 算（图像也转 token），超便宜：

●文字输入：$2 / 百万 token。

●图像输入（编辑用）：$2.50 / 百万 token。

●图像输出：$8 / 百万 token。实际一图成本：1024×1024 的低质只要 $0.005，中 $0.011，高 $0.036；大尺寸稍贵点，到 $0.052。比大模型便宜多了！

LangChain：是银弹，还是 “技术债”？

Tue, 23 Sep 2025 05:46:17 +0000

引言

当前，智能 Agent 的开发正面临两条截然不同的路径选择。一方面，高代码方式通过 SDK 和 API 编码提供灵活性，但带来了巨大的复杂性负担——开发者需要深入理解模型集成、工具调用、记忆管理和分布式协调等复杂概念，显著提高了开发门槛和维护成本。另一方面，像百炼，Dify、Coze 为代表的低代码平台以其出色的易用性迅速占领市场，通过可视化界面让用户能够快速构建 “Model+Prompt+MCP+RAG+Memory” 的标准 Agent 模式。

高代码与低代码

高代码

优势

●控制粒度高：检索、重排、记忆淘汰策略、工具容错、并发/一致性都能精细掌控。

●可移植/可替换：模型、向量库、存储、消息队列可按需换，避免深度锁定。

●性能上限高：可针对热路径做缓存/批量化/并行/算力亲和等优化。

●合规友好：易于纯内网/私有化落地，满足数据边界与审计需求。

劣势

●上手成本高：需要理解模型行为、工具协议、状态管理、分布式、测试/评测。

●开发周期长：原型到生产的路径更长，对团队工程能力要求高。

●维护复杂：提示/数据/评测/日志/灰度与回滚都要自己做治理。

适用场景

●对稳定性、性能、合规要求高的核心业务流程（客服、风控、运维、知识中枢）。

●强定制：复杂工具链（多后端系统、定制检索策略、多段对话状态机）。

●内网/私有化：外网受限、需与既有基建深度耦合（监控、鉴权、审计）。

低代码

优势

●速度快：原型与迭代极快，业务同学也能参与搭建与验收。

●门槛低：抽象好了调用、编排、上下文缓存、简单评测与发布。

●运维成本低：平台内置监控/日志/版本管理（能力视平台而定）。

劣势

●可扩展性受限：复杂状态机、精细化检索/重排、跨域事务一致性等较难。

●性能上限有限：难做深度批处理、算力亲和、跨服务并行等工程优化。

●供应商/能力锁定：某些特性依赖平台实现，迁移成本较高。

●私有化差异：部分平台更偏 SaaS；若需纯内网，要筛选支持私有化/离线模型的方案。

适用场景

●探索/验证期：快速做 PoC、AB 实验、用户调研与演示。

●中轻量业务：知识问答、表单处理、运营活动、内部助理等非关键路径。

●混合团队：产品/运营可直接改提示与流程，工程只需提供数据/工具接口。

场景选型

高代码和低代码有各自的特点和适用场景，那我们该如何决策呢？下面是一个快速决策矩阵：

总结来说：要“快试错”选低代码，要“硬落地”选高代码；两者并不对立，适合“原型低代码 + 核心高代码”的混合路线。

具体来说：

●2 周内交付可用原型、验证需求是否真实 → 低代码

●承载 7×24 核心业务，SLA/审计/内网合规很硬 → 高代码

●大量业务同学参与、频繁改提示与流程 → 低代码 +（必要时）接入自研工具

●把 RAG/记忆/工具编排做成“组织级能力层” → 高代码（沉淀为平台/服务）

●先做 Demo，再逐步把关键链路“工程化” → 低→高的混合迁移

这里需要注意的是，要避免反模式：

●把复杂状态机硬堆在低代码画布里，后期难以维护与回放。

●过早全高代码，导致验证周期太长、需求未定先造轮子。

●忽视提示/知识/评测的版本化与可回滚。

混合实践

对于我们来说，现在正好处于一个 “混合迁移” 的阶段，我们即在使用低代码平台 Dify,也在某些具体的场景下感到了 Dify的不适。所以对于某些项目要进行必要的工程化迁移和改造，具体思路是：

●前台用低代码（业务侧快速改动、AB/评测、需求验证）；

●后台用高代码沉淀“能力层”（RAG 服务、工具/MCP、回溯评测、观测/追踪、策略引擎）。

●平台只做编排与呈现，能力层提供稳定 API。

●形成“能力可复用、前台可迭代、核心可控”的结构。

一句话总结：低代码赢在速度，高代码赢在确定性；用低代码把事儿“做成”，再用高代码把事儿“做稳且做大”。

LangChain

概念说明

提到 LangChain 我们要先厘清一下概念，因为这里有两个概念：

第一，LangChain Inc. 是一家总部位于美国旧金山的前沿人工智能技术公司。公司成立于 2022 年，由 Harrison Chase 和 Ankush Gola 共同创立，2023 年正式独立成立公司实体。公司注册于 2023 年 1 月 31 日，总部地址位于加利福尼亚州旧金山市 Decatur 街 42 号。

第二，LangChain 还是一个用来开发基于 LLM 的 AI 应用框架。

从 LangChain 公司官网和官方文档提供的产品架构图中可以看出，LangChain公司提供的主要产品有：

●开发框架

○LangChain（OSS-免费开源软件)

○LangGraph（OSS-免费开源软件）

●平台

○LangSmith (COMMERCIAL-商业收费)

○LangGraph Platform (COMMERCIAL-商业收费)

在下文中如无特殊说明，LangChain 一律指代第二个概念，即开源的开发框架。

大模型应用开发核心矛盾

当下的 LLM 本身如同一个 “博学但无手无脚的大脑”，它无法感知实时信息、无法操作外部工具、也无法与我们的私有数据交互。这个 “从 “模型能力” 到 “应用能力” 的鸿沟” 正是所有 LLM 应用开发者面临的首要难题。

LangChain 不是一个 “新发明”，而是一个 “高效的连接器和编排器”。它的战略价值在于，它是当前弥合 “模型能力” 与 “应用能力” 鸿沟的最成熟的工程化解决方案之一。

框架介绍

LangChain 的核心思想是“链”，它将 LLM 应用程序的各个组件连接在一起，形成一个完整的工作流。这种模块化的方法可以将复杂的人工智能系统分解为可重用的部分。LangChain 提供了一系列工具和抽象，帮助开发人员将 LLM 与外部数据源（如数据库、API等）连接起来，从而创建功能更强大的应用程序。

LangChain 能够解决的五类问题

LangChain 能够解决五个核心领域（按复杂度递增）

1. 模型与提示（I / O 层）

要解决什么？ 稳定、可替换地调用任意 LLM，并拿到可解析、可复用的输出。

关键点：BaseChatModel、ChatPromptTemplate、OutputParser、LCEL invoke/stream/batch。

一般来说入门 LangChain 都是从第一层起步：prompt | llm | parser

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.prompts import ChatPromptTemplate
 3from langchain_core.output_parsers import StrOutputParser
 4from langchain_openai import ChatOpenAI
 5
 6prompt = ChatPromptTemplate.from_messages([
 7 ("system", "你是精炼的中文助手。"),
 8 ("human", "用一句话解释：{topic}")
 9])
10
11chain = prompt | ChatOpenAI(model="gpt-4o-mini") | StrOutputParser()
12print(chain.invoke({"topic": "LCEL 是什么？"}))

2. 链式编排（流程层）

要解决什么？ 把多个步骤（清洗→生成→解析→后处理）按顺序 / 并行可靠执行。

关键点：Runnable 统一协议、| 管道、并行 map、重试与超时、缓存

适用：流程确定、依赖明确的任务（如格式转换、规则后处理、批处理）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.runnables import RunnableLambda
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain_openai import ChatOpenAI
 6
 7pre = RunnableLambda(lambda x: {"q": x["q"].strip()[:200]}) # 预处理：清理&截断
 8post = RunnableLambda(lambda s: s.rstrip("。") + "。") # 后处理：补全句号
 9
10prompt = ChatPromptTemplate.from_messages([
11 ("system", "用简洁中文回答。"),
12 ("human", "把这些要点合成一句话：{q}")
13])
14
15chain = pre | prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) | StrOutputParser() | post
16print(chain.invoke({"q": "LCEL, Runnable, invoke/batch/stream"}))

3. 检索增强生成 RAG（数据层）

要解决什么？ 当模型 “知道的不够”，要从外部资料中取对内容。

关键点：Loader/TextSplitter → Embeddings → VectorStore → Retriever（可带重排 / 压缩）。

 1⚡ python片段# pip install -U langchain langchain-openai langchain-community faiss-cpu
 2
 3from langchain_openai import ChatOpenAI, OpenAIEmbeddings
 4from langchain_core.prompts import ChatPromptTemplate
 5from langchain_core.output_parsers import StrOutputParser
 6from langchain_core.runnables import RunnablePassthrough, RunnableLambda
 7from langchain_community.vectorstores import FAISS
 8
 9# 1) 准备示例知识（演示使用；实际替换为你的文档）
10texts = [
11 "LCEL 是 LangChain 的可组合执行协议，用 | 串联组件（prompt、llm、parser）。",
12 "RAG（检索增强生成）通过向量检索把外部资料接入模型，以降低幻觉并注入最新知识。"
13]
14vs = FAISS.from_texts(texts, OpenAIEmbeddings())
15retriever = vs.as_retriever(k=3)
16
17# 2) RAG Prompt（把检索到的资料塞进上下文）
18prompt = ChatPromptTemplate.from_messages([
19 ("system", "你是知识助手，必须基于提供的资料回答。"),
20 ("human", "问题：{question}\n\n资料：\n{context}\n\n请用中文简洁作答，并在句末用[]引用关键词。")
21])
22
23# 3) 组合：question → retriever → prompt → llm → parser
24format_docs = RunnableLambda(lambda docs: "\n\n".join(d.page_content for d in docs))
25chain = (
26 {"context": retriever | format_docs, "question": RunnablePassthrough()}
27 | prompt
28 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
29 | StrOutputParser()
30)
31
32print(chain.invoke("什么是 RAG？"))

4. 智能代理（自主层）

要解决什么？ 目标不完全明确、步骤不固定，需要选择工具、反复试探（行动 - 观察 - 反思）。

关键点：BaseTool/工具调用、函数调用、AgentExecutor（或用 LangGraph 做有状态策略）、记忆 / 护栏。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.tools import tool
 4from langchain_core.messages import SystemMessage, HumanMessage, ToolMessage
 5
 6# 1) 定义一个可被模型调用的工具（OpenAI Tool Calling）
 7@tool
 8def multiply(a: int, b: int) -> int:
 9 "精确乘法"
10 return a * b
11
12# 2) 绑定工具，让模型自行决定是否调用
13llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools([multiply])
14
15# 3) 行动-观察-再思考（最小一次循环）
16msgs = [
17 SystemMessage("你是严谨助手，涉及计算必须调用工具，不要心算。"),
18 HumanMessage("先算 12×34，再把结果乘以 2，给出最终数值即可。"),
19]
20
21ai = llm.invoke(msgs) # 行动：模型决定要不要调用工具
22msgs.append(ai)
23for tc in ai.tool_calls: # 观察：执行工具并把结果回传给模型
24 out = multiply.invoke(tc["args"])
25 msgs.append(ToolMessage(str(out), tool_call_id=tc["id"]))
26
27final = llm.invoke(msgs) # 再思考：基于工具结果给最终答案
28print(final.content)

5. 评估与观测（质量层）

要解决什么？ 度量 “是否正确/有用/鲁棒”，以及在真实流量中看得见链路与瓶颈。

关键点：基准指标（EM/F1/检索命中率）、LLM 判分、回放/对比、LangSmith（或自建追踪）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain.evaluation import load_evaluator
 6
 7# 被评对象：最小 QA 链（LCEL）
 8qa = (ChatPromptTemplate.from_template("用一句话回答：{q}")
 9 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
10 | StrOutputParser())
11
12q = "LCEL 是什么？"
13ref = "LCEL 是 LangChain 的统一执行协议，用 | 将组件串联成可组合管道。"
14
15pred = qa.invoke({"q": q})
16
17# LangChain 自带评估器：按“准确&简洁”两条标准打分+给理由
18evaluator = load_evaluator(
19 "labeled_criteria",
20 llm=ChatOpenAI(model="gpt-4o-mini", temperature=0),
21 criteria={"accuracy": "是否与参考一致且不捏造", "conciseness": "是否一句话且清晰"}
22)
23grade = evaluator.evaluate_strings(input=q, prediction=pred, reference=ref)
24
25print("答案：", pred)
26print("评分：", grade.get("score"), "理由：", grade.get("reason"))

总结如下：

架构图

LangChain 是一个以组合性为核心哲学的大语言模型应用开发框架

其设计理念是 “通过组合性构建LLM应用”，具体来说：

1.可组合性 (Composability)：所有组件都是 Runnable，可以像乐高积木一样组合；使用 LCEL（LangChain Expression Language）轻松构建复杂流程

2.标准化接口 (Standardization)：统一的输入输出接口；一致的同步/异步/批处理/流式处理方法

3.可扩展性 (Extensibility)：通过继承基类轻松添加新实现；插件化架构，易于集成第三方服务

4.类型安全 (Type Safety)：使用泛型和类型提示；编译时类型检查，减少运行时错误

架构层次

LangChain 采用严格的分层架构，从底层的核心抽象到上层的应用组件，确保了良好的模块化和可扩展性。

 1⚡ text片段LangChain
 2├── langchain-core/ # 核心抽象层
 3│ ├── language_models/ # 基础模型抽象
 4│ ├── runnables/ # LCEL 核心
 5│ ├── prompts/ # 提示抽象
 6│ └── ...
 7│
 8├── langchain/ # 主实现层
 9│ ├── llms/ # LLM 实现
10│ ├── chat_models/ # Chat 实现
11│ ├── chains/ # 链实现
12│ └── ...
13│
14└── langchain-community/ # 社区集成
15 └── partners/ # 第三方集成
16 ├── openai/
17 ├── anthropic/
18 └── ...

模块结构

LangChain 主要包含以下模块：

1.核心语言模型模块

○llms/ - 传统 LLM（85+ 个实现）

○chat_models/ - 对话模型（35+ 个实现）

○embeddings/ - 嵌入模型（51+ 个实现）

2.输入输出模块

○prompts/ - 提示模板

○output_parsers/ - 输出解析器（23+ 种）

○prompt_values/ - 提示值处理

3.数据处理模块

○document_loaders/ - 文档加载器（166+ 种）

○document_transformers/ - 文档转换器

○text_splitter.py - 文本分割

○indexes/ - 索引管理

4.存储与检索模块

○vectorstores/ - 向量数据库（76+ 种）

○retrievers/ - 检索器（78+ 种）

○memory/ - 记忆管理（39+ 种）

○storage/ - 存储抽象

○docstore/ - 文档存储

5.链与编排模块

○chains/ - 各种链（144+ 个文件）

○runnables/ - 可运行组件

○agents/ - 智能体（146+ 个文件）

6.工具与集成模块

○tools/ - 工具集（186+ 种）

○agent_toolkits/ - 工具包

○utilities/ - 实用工具（59+ 个）

○utils/ - 辅助函数

7.回调与监控模块

○callbacks/ - 回调处理器（46+ 种）

○tracers/ - 追踪器

○evaluation/ - 评估工具（32+ 个）

8.特殊功能模块

○chat_loaders/ - 聊天记录加载

○graphs/ - 图处理

○sql_database.py - SQL 数据库支持

○cache.py - 缓存管理

Runnable 抽象

LangChain 的架构精髓在于 Runnable 接口 —— 一个"可以被调用、批处理、流化、转换和组合的工作单元" 。这个抽象提供了六种核心执行模式：

●invoke/ainvoke: 单次同步/异步执行

●batch/abatch: 并行同步/异步批处理执行

●stream/astream: 同步/异步流式输出执行

所有组件都实现 Runnable 接口，从检索器到代理系统，确保了组件间的无缝互操作性，使得 LangChain 组件具有极高的可组合性。

1⚡ 代码片段# 示例：链式组合
2chain = prompt | model | parser

LCEL：声明式表达语言

LangChain Expression Language (LCEL) 是框架的"声明式方法构建生产级程序" 。通过管道操作符（|）实现组件的优雅组合，天然支持异步、批处理和流式操作，这使得基于LCEL的程序能够更好地扩展以处理更高的并发负载。

LCEL 不仅仅是语法糖。它是一种声明式的编程范式。开发者只需声明 “数据如何流动”，而框架负责处理底层的执行、流式传输、并行化和日志记录。

 1⚡ python片段# pip install -U langchain langchain-openai
 2
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_openai import ChatOpenAI
 5from langchain_core.output_parsers import StrOutputParser
 6
 7# 1) Prompt：定义输入模板
 8prompt = ChatPromptTemplate.from_messages([
 9 ("system", "你是精炼、可靠的中文助手。"),
10 ("human", "用一句话回答：{question}")
11])
12
13# 2) LLM：任意 OpenAI 兼容服务均可（公有云/企业网关/vLLM 等）
14llm = ChatOpenAI(
15 model="gpt-4o-mini", # 换成你的模型名即可
16 api_key="YOUR_KEY", # 也可用环境变量 OPENAI_API_KEY
17 base_url="http://localhost:8000/v1" # 选填：本地或内网的 OpenAI 兼容地址
18)
19
20# 3) Parser：把模型返回的消息对象转成纯字符串
21parser = StrOutputParser()
22
23# LCEL：像搭乐高一样用“|”把组件串起来
24chain = prompt | llm | parser
25
26# ——最简单的单次调用（演示用）——
27print(chain.invoke({"question": "LCEL 是什么？"}))
28
29# ——可选：流式演示（边生成边打印）——
30for chunk in chain.stream({"question": "给出一条使用 LCEL 的建议"}):
31 print(chunk, end="")
32print()
33
34# ——可选：批量演示（一次处理多条）——
35print(chain.batch([
36 {"question": "一句话解释 LangChain"},
37 {"question": "一句话解释 LCEL 的优势"}
38]))

Schema 与类型系统

LangChain 的类型系统建立在 Python 的类型提示和 Pydantic模型之上，提供了一套完整的类型定义来支持 LLM 应用开发。LangChain 的类型系统具有以下特点：

1.强类型: 基于 Python 类型提示和 Pydantic，提供编译时和运行时类型检查

2.可组合: 通过 Runnable 接口实现组件的灵活组合

3.可序列化: 所有核心类型都继承自 Serializable

4.灵活性: 支持多种 Schema 定义方式（Pydantic、TypedDict、JSON Schema）

5.流式支持: 原生支持同步、异步、批处理和流式处理

6.标准化: 统一的输入输出类型定义，便于组件互操作

Pydantic 由 Samuel Colvin 创建，核心思想是：“使用类型注解定义数据模型，Pydantic 自动帮你验证和转换数据。” 它基于 Python 3.6+ 的类型提示系统（如 str, int, List, Optional 等），通过定义继承自 BaseModel 的类，来描述期望的数据结构。

想象一下，你正在指挥一个非常聪明但有点 “随心所欲” 的机器人。如果你只是模糊地说 “给我找点关于猫的资料”，它可能会给你一篇科学论文，一张猫的图片，或者一段猫叫的音频。这太不可预测了。LangChain 的 Schema 和类型系统，就像是给这个机器人的一套精确的 “指令图纸” 和 “数据表格”。它让你能够用一种机器人能精确理解的方式下达指令，并要求它以你想要的、规整的格式返回结果。下面我们通过几个场景和代码例子，来看看这些 “图纸” 和 “表格” 是怎么工作的。

场景 1: 从简单的闲聊到有角色区分的对话

一开始，我们和 AI 的交互很简单，就是 “一问一答”。

最基础的类型: Text (字符串): 这就是最原始的交互方式。

1⚡ 代码片段# 这其实就是最基础的文本 Schema
2my_question = "你好，你叫什么名字？"
3ai_response = "我是AI助手。"

但这很快就不够用了。在一个持续的对话中，AI 需要知道哪句话是谁说的，才能更好地理解上下文。

进阶类型: ChatMessage

ChatMessage 就是为了解决这个问题而生的 “对话表格”。它规定了每条消息都应该有 role (角色) 和 content (内容) 两列。主要角色有：

○SystemMessage: 系统指令。给 AI 设定一个 “人设” 或总体的行为准则。

○HumanMessage: 你的话。

○AIMessage: AI 的话。

每个元素都有明确的role 和content。这让 AI 不再混乱，能够更好地进行多轮对话。

场景 2: 我需要 AI 给我一个结构化的数据，而不是一段话

假设你想让 AI 帮你生成用户信息，并存入数据库。如果你只对它说 “生成一个用户，名叫张三，25 岁，邮箱是 zhangsan@email.com”，它可能会返回：

●" 好的，用户信息如下：姓名：张三，年龄：25，邮箱：zhangsan@email.com"

●" 张三，25 岁，邮箱 zhangsan@email.com"

●" 这是一个名叫张三的用户，他今年 25 岁了，你可以通过 zhangsan@email.com 联系到他。"

这些都是字符串，程序很难处理！我们需要的是一个干净的、可以直接用的 JSON 对象。这时，我们就要给 AI 一张 “图纸”，告诉它我们想要的输出格式。在 LangChain 中，最常用的 “绘图工具” 就是Pydantic 库。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.pydantic_v1 import BaseModel, Field
 3from langchain_core.output_parsers import JsonOutputParser
 4from langchain_openai import ChatOpenAI
 5from langchain_core.prompts import PromptTemplate
 6
 7# 1. 用 Pydantic 画一张“图纸”，定义你想要的输出结构
 8classUserProfile(BaseModel):
 9 name: str = Field(description="用户的全名")
10 age: int = Field(description="用户的年龄")
11 email: str = Field(description="用户的电子邮件地址")
12 is_active: bool = Field(description="用户账户是否活跃")
13
14# 2. 创建一个输出解析器，告诉它要用哪张“图纸”
15parser = JsonOutputParser(pydantic_object=UserProfile)
16
17# 3. 在提示中，告诉AI要按照“图纸”的格式来回答
18prompt = PromptTemplate(
19 template="""
20 根据下面的用户信息，生成一个JSON对象。
21 用户信息：{user_info}
22 {format_instructions}
23 """,
24 input_variables=["user_info"],
25 # 把“图纸”的说明书（格式指令）插入到提示中
26 partial_variables={"format_instructions": parser.get_format_instructions()}
27)
28
29# 4. 创建模型并链接所有部分
30# model = ChatOpenAI(temperature=0)
31# chain = prompt | model | parser
32#
33# response = chain.invoke({"user_info": "创建一个用户，名叫李四，30岁，邮箱是 lisi@email.com，账户是活跃的。"})
34
35# 期望的 response 会是一个干净的 Python 字典，而不是字符串
36# print(response)
37#
38# 输出:
39# {'name': '李四', 'age': 30, 'email': 'lisi@email.com', 'is_active': True}

看到妙处了吗？通过定义UserProfile 这个 Schema，我们强制 AI 的输出符合我们预设的结构，让它的输出变得 100% 可预测和可用。

场景 3: 让 AI 使用我们定义的工具

假设你想让 AI 能够查询天气。AI 本身是不知道今天天气的，但你可以提供一个查询天气的函数（工具）给它。但是，AI 怎么知道这个函数是干嘛的？需要哪些参数？

LangChain 的 @tool 装饰器可以自动读取你函数的 “类型提示”(Type Hinting) 和文档字符串 (docstring)，并把它们变成一份 AI 能看懂的 “工具说明书”。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.tools import tool
 3
 4@tool
 5def search_weather(city: str, unit: str = "celsius") -> str:
 6 """
 7 根据城市名称查询实时天气。
 8 :param city: 城市的名字，例如：北京
 9 :param unit: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
10 """
11 # 这里的代码会真实地去调用天气API
12 if city == "北京":
13 return f"北京现在的天气是 25°{unit}"
14 elif city == "上海":
15 return f"上海现在的天气是 28°{unit}"
16 else:
17 return f"抱歉，我查询不到 {city} 的天气。"
18
19# 当你把这个工具提供给一个支持工具调用的AI模型时，
20# LangChain会自动生成类似这样的“说明书”给AI看：
21# Tool Name: search_weather
22# Tool Description: 根据城市名称查询实时天气。
23# Tool Arguments:
24# - name: city, type: string, description: 城市的名字，例如：北京
25# - name: unit, type: string, description: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
26
27# 当你问AI：“北京今天天气怎么样？”
28# AI会分析你的问题，发现需要查询天气，然后查看它手上的“工具说明书”。
29# 它会找到 search_weather 工具，并自动生成调用参数：{"city": "北京", "unit": "celsius"}
30# 然后执行函数，得到结果，最后把结果用自然语言告诉你。

这里的 city: str 和 unit: str 就是 Schema 的一部分，它明确规定了工具需要什么类型的输入。文档字符串 “”"…""" 则成了 AI 理解工具功能的关键。

核心抽象组件

LangChain 的架构围绕以下几个基本抽象组件构建，这些抽象组件共同构成了 LangChain 的核心架构，让开发者能够快速构建复杂的 LLM 应用。每个组件都有明确的职责，通过 Runnable 接口相互连接，形成了一个强大而灵活的框架。

Language Models (语言模型)

提供文本生成、对话、推理等核心 AI 能力

●BaseLanguageModel: 所有语言模型的基类,它继承自 RunnableSerializable，并定义了语言模型交互的通用接口。它通过其 generate_prompt() 方法接受 PromptValue 对象。

●BaseChatModel: 对话模型（GPT-4、Claude）- 处理消息序列

●BaseLLM: 文本生成模型 - 处理字符串输入输出

Prompts (提示模板)

输入构造层，支持变量替换、少样本示例、消息格式化

●BasePromptTemplate: 动态构造模型输入

●ChatPromptTemplate: 构造对话消息序列

●PromptTemplate: 构造文本提示

Messages (消息)

对话交互的基本单元

●BaseMessage: 所有消息的基类

●HumanMessage: 用户消息

●AIMessage: AI 回复

●SystemMessage: 系统指令

●ToolMessage: 工具调用结果

Documents (文档)

知识存储的基本单元，是 RAG（检索增强生成）的基础数据结构

●Document: 包含 page_content（内容）和 metadata（元数据）

●用于表示任何文本数据：网页、PDF、数据库记录等

Retrievers (检索器)

知识检索层，RAG 架构的核心组件

●BaseRetriever: 是文档检索系统的抽象基类，它实现了 Runnable 接口以实现可组合性。它定义了基于查询检索相关文档的标准接口。

●连接向量数据库、搜索引擎、数据库等

Vector Stores (向量存储)

语义搜索的基础设施

●VectorStore: 向量数据库的抽象接口

●存储和检索文档的向量表示

●支持相似度搜索、混合搜索等

Embeddings (嵌入)

文本向量化，提供了嵌入模型的抽象接口，定义了将文本转换为向量表示的方法。它要求实现 embeddocuments() 和 embedquery() 方法。是语义搜索和相似度计算的基础。

●Embeddings: 将文本转换为向量表示

●支持各种嵌入模型（OpenAI、Hugging Face 等）

Output Parsers (输出解析器)

结构化输出，确保模型输出符合预期格式

●BaseOutputParser: 解析模型输出为结构化数据

●PydanticOutputParser: 解析为 Pydantic 模型

●JsonOutputParser: 解析为 JSON

Tools (工具)

BaseTool 是供智能体（Agents）使用的工具（Tools）的抽象基础，继承自 RunnableSerializable，并为与外部系统交互提供了标准化接口。是 Function Calling 和 Agent 的基础。

●BaseTool: 定义模型可调用的外部功能

●让模型能执行计算、查询数据库、调用 API 等

Callbacks (回调)

观察和控制执行流程，提供执行过程的可见性

●BaseCallbackHandler: 监听和响应执行事件

●用于日志记录、调试、监控、流式输出等

Memory/Cache (记忆/缓存)

状态管理，对话历史管理、会话状态保持

●BaseCache: 缓存 LLM 响应，避免重复调用

●BaseStore: 键值存储抽象

对照表

这里是一个快速对照表，来将上文的 LangChain 模块与核心抽象组件之间做个对应。

模块就像房间（客厅/厨房/卧室），抽象就像插座与标准接口（任意电器都能插上电并协同工作）。

●主要模块 = 按 “职能分区” 的功能板块（编排、模型、检索、Agent、记忆、部署等），回答 “系统里有哪些能力”。

●核心抽象 = 跨模块通用的接口 / 基类（如 Runnable、BaseChatModel、BaseRetriever…），回答 “各模块如何被替换与拼装”。

Agent

LangChain 框架完全可以构建 Agent，并且这是它自诞生以来最核心、最吸引人的功能之一。经典的 Agent（如 ReAct 范式）通过 AgentExecutor 实现一个 “思考 -> 行动 -> 观察” 的循环。LLM 在这个循环中扮演决策者，决定下一步调用哪个工具（Tool）。对于绝大多数单 Agent 任务，LangChain 的原生 Agent 完全够用。

但是，当 Agent 的逻辑变得极其复杂，例如：

1.需要循环和分支：当流程不是线性，而是需要在多个步骤之间来回跳转。

2.需要多 Agent 协作：例如，一个 “分析师 Agent” 生成报告，交给 “代码生成 Agent” 编写代码，再由 “测试 Agent” 进行验证，如果测试失败，流程需要返回给 “分析师 Agent” 重新分析。

3.需要持久化的状态管理：在复杂的交互中，需要精确控制每一步的状态。

这时 LangGraph 框架应运而生。它将 Agent 的工作流显式地定义为一个状态图 (State Graph)。每个节点是一个工作单元（一个 LLM 调用或一个工具调用），每条边是状态的转移。它不是取代了 LangChain Agent，而是为构建更强大、更可控的 “状态化 Agent 系统” 提供了新的范式。

LangGraph

LangGraph 可以独立使用，但它也可以无缝集成到任何 LangChain 产品中。

LangGraph 提供了比 LangChain 更底层、更灵活的控制能力，特别适合需要状态管理、人机协作和复杂流程编排的场景。而 LangChain 则更适合快速原型开发和简单的链式处理任务。两者可以协同使用：LangChain 的组件可以作为 LangGraph 的节点，但 LangGraph 也可以完全独立于 LangChain 使用。

如果不用 LangGraph 开发，选择其他框架，推荐使用 CrewAI。

LangGraph 架构

LangGraph 的执行流程遵循以下算法：

LangChain 与 LangGraph 适用场景对比：

LangChain 与 LangGraph 代码对比

LangChain（使用 AgentExecutor）:

 1⚡ python片段# pip install -U langchain langchain-openai
 2import os
 3from datetime import datetime
 4
 5from langchain_openai import ChatOpenAI
 6from langchain_core.tools import tool
 7from langchain_core.prompts import ChatPromptTemplate
 8from langchain.agents import create_tool_calling_agent, AgentExecutor
 9
10# ========== Tools ==========
11@tool
12def multiply(a: float, b: float) -> float:
13 """Return a*b."""
14 return a * b
15
16@tool
17def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str:
18 """Return current local time formatted by fmt."""
19 return datetime.now().strftime(fmt)
20
21tools = [multiply, get_time]
22
23# ========== LLM ==========
24llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
25
26# ========== Agent ==========
27prompt = ChatPromptTemplate.from_messages([
28 ("system", "You are a concise tool-using agent. Use the tools when helpful. Reply in Chinese."),
29 ("human", "{input}")
30])
31
32agent = create_tool_calling_agent(llm, tools, prompt)
33executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
34
35# ========== Demo ==========
36res = executor.invoke({
37 "input": "先用 multiply 计算 7×12，再调用 get_time 给出当前时间。答案只要一行。"
38})
39print("Final:", res["output"])

我来画出详细的流程图，展示这个 LangChain Agent 的执行过程：

LangGraph 代码：

 1⚡ python片段# pip install -U langgraph langchain langchain-openai
 2from datetime import datetime
 3from typing import Sequence
 4from typing_extensions import TypedDict
 5
 6from langchain_core.tools import tool
 7from langchain_core.messages import AnyMessage, HumanMessage
 8from langchain_openai import ChatOpenAI
 9
10from langgraph.graph import StateGraph, END # END 表示图的终点
11from langgraph.prebuilt import ToolNode, tools_condition # 预置的“工具节点”和“是否需要走工具”的路由函数
12
13# ===== 工具定义：用 @tool 自动生成 JSON Schema，便于模型函数调用 =====
14@tool
15def multiply(a: float, b: float) -> float: # 定义乘法工具
16 return a * b
17
18@tool
19def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str: # 定义获取时间工具
20 return datetime.now().strftime(fmt)
21
22tools = [multiply, get_time] # 工具列表（给模型/工具节点用）
23
24# ===== 绑定工具到模型：让 LLM 知道有哪些可调用的函数（工具） =====
25llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools(tools)
26# bind_tools(...) 的效果：
27# 1) 把 tools 的参数签名/描述转成 JSON Schema 给模型；
28# 2) 让模型在需要时产生 tool_calls（函数调用）结构，而不是直接“胡说答案”。
29
30# ===== 定义“状态”的数据结构：LangGraph 的节点之间传的就是这个 State =====
31classS(TypedDict):
32 messages: Sequence[AnyMessage] # 一串消息（人类/AI/工具消息），作为“对话上下文”
33
34# ===== 定义一个“模型节点”：输入 State，调用 LLM，输出一条 AI 消息 =====
35def agent_node(state: S):
36 # 关键：把现有 messages（含用户、人类消息、工具结果等）喂给 LLM
37 ai_msg = llm.invoke(state["messages"]) # 可能返回带 tool_calls 的 AIMessage
38 return {"messages": [ai_msg]} # LangGraph 会把这条消息合并到全局 state
39
40# ===== 搭建“有向图”：节点 + 边，决定执行路径 =====
41g = StateGraph(S) # 新建一个“状态图”，S 是状态类型（结构）
42
43# ——① 注册节点（起名叫 "agent" 和 "tools"）——
44g.add_node("agent", agent_node) # 把上面的函数包装成一个图节点
45g.add_node("tools", ToolNode(tools)) # 预置的工具节点：会读取 AI 的 tool_calls 并执行
46
47# ——② 设置“入口节点”：从哪个节点开始跑——
48g.set_entry_point("agent") # ★ 从 "agent" 开始（也就是先问一次模型）
49# 解释：这句相当于“第一步进图先走哪个节点”。如果不设，编译时会报错或不知道从哪开始。
50
51# ——③ 配置“条件边”：根据模型输出决定接下来走哪条边——
52g.add_conditional_edges(
53 "agent", # 从 "agent" 节点出来时
54 tools_condition, # 用预置的判断函数：看 AIMessage 是否包含 tool_calls
55 {"tools": "tools", "end": END} # 如果需要工具→去 "tools"；否则→直接结束
56)
57# 解释：tools_condition 会检查最新一条 AI 消息。
58# - 若模型产生了函数调用（tool_calls），返回路由键 "tools"
59# - 若没有需要的工具调用，返回路由键 "end"
60# 这行把路由键映射为真正的边：“tools”→去 tools 节点，“end”→走到 END（图的终点）。
61
62# ——④ 把工具节点执行完后的边接回“agent”，形成闭环——
63g.add_edge("tools", "agent")
64# 解释：当 tools 节点执行完所有函数调用，会把结果（ToolMessage）追加到 state.messages，
65# 然后回到 "agent" 再问一次模型。直到模型不再发起新的 tool_calls。
66
67# ——⑤ 编译成可运行的“应用”对象——
68app = g.compile()
69# 解释：compile() 会把上面定义的节点/边/合并策略等打包成可执行的图（可 invoke/stream）。
70
71# ===== 运行：给一条人类消息，按图的“入口节点”开始执行 =====
72final = app.invoke({
73 "messages": [HumanMessage(content="先用 multiply 计算 7×12，再调用 get_time 报当前时间。只要一行中文。")]
74})
75# 解释：invoke 会：
76# step1: 进入入口 "agent" → LLM 读到 HumanMessage，判断要不要调用工具；
77# step2: 如果需要工具 → 路由到 "tools" 执行（得到 ToolMessage）→ 回到 "agent"；
78# step3: 重复 step1~2，直到不需要工具 → 按条件边路由到 END → 返回最终状态。
79
80print(final["messages"][-1].content) # 打印最后一条 AI 的自然语言回复

LangGraph 详细执行流程：

竞品

如果不使用 LangChain 开发 AI/LLM 应用，以下是主要的替代框架选择：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LlamaIndex	RAG 与数据检索专家	Py/TS	多索引策略、查询路由、强检索、结构/非结构数据	知识库问答、文档分析、RAG	★★★★★	★★☆☆☆	★★★☆☆	★★☆☆☆	★★★☆☆
CrewAI	多智能体团队协作	Py	角色/任务、顺序/并行/层级协作、社区活跃	多智能体系统、内容流水线、任务分解	★★☆☆☆	★★★★★	★★★☆☆	★★☆☆☆	★★★☆☆
Semantic Kernel	企业级 AI 编排	C#/Py/Java	技能/规划器、Azure 深度集成、微软背书	企业应用、复杂规划、微软技术栈	★★★☆☆	★★★☆☆	★★★★★	★★☆☆☆	★★☆☆☆
Haystack	NLP/搜索系统专家	Py	Pipeline 清晰、文档处理强、评测完善、重隐私	QA 系统、语义搜索、信息抽取	★★★★☆	★★☆☆☆	★★★★☆	★★☆☆☆	★★★☆☆
AutoGen	自动化对话与代码生成	Py	代码生成/执行、多 Agent 对话、自动化流程、人机协作	代码生成、数据分析自动化、技术任务	★★☆☆☆	★★★★☆	★★★☆☆	★★☆☆☆	★★★☆☆
Guidance	精确输出控制	Py	模板语言、强格式约束、轻量高效	结构化输出、格式化生成、提示工程	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★★★★	★★★★☆

还有一些新兴 / 特色框架：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LiteLLM	统一 LLM API	Py	100+ 模型统一接口、超轻量、零依赖	简单 LLM 调用、多模型切换、原型	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★☆☆☆	★★★★★
DSPy	声明式/自动提示优化	Py	可学习模块、自动调参、学术完善	指标导向优化、研究/实验	★★★☆☆	★★☆☆☆	★★☆☆☆	★★★☆☆	★★★☆☆
txtai	轻量 Transformers 框架	Py	HF 生态、内置向量库、性能好	轻量语义搜索、嵌入式应用	★★★☆☆	★☆☆☆☆	★★☆☆☆	★★☆☆☆	★★★★☆
MetaGPT	“AI 软件公司”模拟	Py	角色分工、项目级生成、代码产出	自动化软件开发、代码生成	★☆☆☆☆	★★★★☆	★★☆☆☆	★★☆☆☆	★★☆☆☆

在实际开发中，如不用 LangChain，选型范围会缩小到最流行的几个竞品，比如：

●🦙 LlamaIndex：原名 GPT-Index，是一个开源的数据框架，专门用于构建大型语言模型 (LLM) 应用。它主要解决了如何将 LLM 与外部数据有效连接的问题，使开发者能够创建更强大的知识密集型应用。

●🚢 CrewAI：多智能体团队协作框架，CrewAI 是一个轻量、快速的 Python 框架，完全从零构建，与 LangChain 或其他代理框架完全无关。它为开发者提供高级别的简洁性和精确的底层控制，非常适合创建适用于任何场景的自主 AI 代理。

●🔧 Haystack：一个端到端的大型语言模型（LLM）框架，它允许你构建由 LLM、Transformer 模型、向量搜索等功能驱动的应用程序。

●🚀 AutoGen：用于创建能够自主行动或与人类协作的多智能体AI应用的框架

需要注意的是：这些框架不是互斥的，可以组合使用（如 LlamaIndex + CrewAI）

常见陷阱与挑战

抽象泄漏 (Leaky Abstraction)

定义: 一个 “抽象” 旨在隐藏底层实现的复杂性。当这个抽象无法完全隐藏底层细节，导致你必须理解底层是如何工作的才能正确地使用它或排查问题时，就发生了 “抽象泄漏”。

LangChain 中的具体例子 (以旧版的 RetrievalQA 链为例):

●美好的抽象: RetrievalQA 链看起来很简单，你只需要给它一个 llm 和一个 retriever，它就能帮你完成 RAG。你期望它能 “神奇地” 工作。

●泄漏的现实:

a.Prompt 在哪里？你发现问答效果不好。为什么？因为 RetrievalQA 内部使用了一个默认的、隐藏的 Prompt 模板 (类似 “Use the following pieces of context to answer the user’s question…")。这个默认模板可能不适合你的模型（比如某些中文模型），或者不符合你的业务场景。

b.文档如何组合？当 retriever 返回了 4 个文档块 (Chunks) 时，这些文档是如何被塞进最终的 Prompt 里的？是简单拼接吗？如果超过了模型的上下文窗口怎么办？RetrievalQA 有一个 chaintype 参数（如 stuff, mapreduce）来控制这个行为。

问题的根源: 为了解决上述问题，你被迫去阅读 LangChain 的源码，去理解 RetrievalQA 内部隐藏的 Prompt 和文档组合逻辑。这时，RetrievalQA 这个本应让你省心的 “高级抽象”，反而成了你理解和调试的障碍。抽象 “泄漏” 了底层的实现细节。

如何应对？

拥抱 LCEL: LCEL 在很大程度上解决了这个问题。通过 prompt | model | parser 的方式， Prompt 是显式的，数据流是清晰的。你可以完全控制每一个环节，没有 “魔法” 和隐藏的逻辑。这是一种更 “白盒” 的构建方式，虽然初看起来代码多了一点，但可控性和可调试性大大增强。当然还有一种方案就是 “取其精华，去其糟粕”，LangChain 框架引入后，只用必要的部分组件，其余需要灵活处理的部分，全手写。

调试的 “黑盒感”

问题: 链的最终输出不符合预期，但中间过程完全不可见，不知道是 Prompt 错了、检索出的文档错了，还是模型理解错了。

解决方案: LangSmith。这是解决此问题的标准答案。设置环境变量 LANGCHAINTRACINGV2=“true” 即可开始追踪。用不了 LangSmith 的话，也可以用开源的 langfuse 替代。

对简单任务过度设计

问题: 你的任务只是需要根据一个模板调用一次 OpenAI API。这种情况下，引入 LangChain 的 LLMChain 相比直接使用 openai 库的 client.chat.completions.create()，增加了不必要的复杂性。

解决方案: 保持务实。如果你的应用逻辑非常简单，就是一个单一的 LLM 调用，那么直接使用原生 SDK 可能更清晰、更轻量。当且仅当你需要编排多个步骤（如 RAG）、管理记忆、或使用 Agents 时，LangChain 的价值才能最大化。

LangChain 的版本演进

v1.0 alpha：和 v0.x 的关键差异

v1.0 alpha（2025-09）是 LangChain 的一次 “面向长期” 的大改版

核心变化

●消息模型统一：新增 .content_blocks（标准化的 “内容块” 视图），把不同厂商的 “推理、引用、服务端工具调用、多模态” 等表示成同一种类型，减少 provider 差异带来的胶水代码；对旧 .content 后向兼容。

●Agent 重心调整：create_agent() 成为默认入口，底层基于 LangGraph 的图式运行时（持久化、流式、人审 / 中断、错误处理更规范）。

●包面积极度收敛：langchain 更聚焦 “标准接口 + 预置 Agent / 链”；历史面迁到 langchain-legacy，便于兼容老代码再慢慢重构。

●默认行为与平台要求：

○Python 需 ≥3.10；Chat 模型返回类型固定为 AIMessage；OpenAI Responses API 的默认输出版本调整（可用 LCOUTPUTVERSION=v0 退回）；Anthropic max_tokens 默认值上调。

○JS / TS 侧：核心原语（createAgent、ToolNode、tool、消息类型）直接从 langchain 导出；Node.js 需 ≥20；大量老子路径导出清理。

三个常见场景

1.“会用工具、可结构化返回” 的 Agent

v0.x（典型写法）：构建 Agent + Executor，再自己管结构化解析 / 二次调用

 1⚡ python片段# 旧式（示意）：AgentExecutor + 自行处理结构化输出
 2from langchain_openai import ChatOpenAI
 3from langchain.agents import AgentExecutor, initialize_agent
 4from pydantic import BaseModel
 5
 6class Weather(BaseModel):
 7 temperature: float
 8 condition: str
 9
10llm = ChatOpenAI(model="gpt-4o-mini")
11tools = [get_weather]
12
13agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
14result = agent.run("What's the weather in SF?")
15# 再用正则/二次调用或手写解析把 result 转成 Weather(...)

v1.0 alpha（新写法）：一个入口 create_agent，在主循环里直接产出结构化结果（避免多一次 LLM 调用、少走弯路）

 1⚡ python片段from langchain.agents import create_agent
 2from pydantic import BaseModel
 3
 4class Weather(BaseModel):
 5 temperature: float
 6 condition: str
 7
 8agent = create_agent(
 9 "openai:gpt-4o-mini", # 也可传入已实例化 model
10 tools=[get_weather],
11 response_format=Weather # 结构化输出内建
12)
13out = agent.invoke({"messages": [{"role": "user", "content": "Weather in SF?"}]})
14print(out["structured_response"]) # -> Weather(...)

2.“跨厂商、多模态/推理/引用” 的消息处理

v0.x：不同厂商字段名不同（如 reasoning、thinking、citations、server tool 等），常见一堆 if provider == … 的分支。

v1.0 alpha：直接读 .content_blocks（统一、强类型），必要时再序列化回标准块。

1⚡ python片段from langchain_core.messages import AIMessage
2
3msg = some_llm.invoke("Explain with sources & brief reasoning")
4# v1 统一读取：
5for block in msg.content_blocks:
6 if block["type"] == "reasoning":
7 use_reasoning(block["reasoning"])
8 if block["type"] == "text" and "annotations" in block:
9 use_citations(block["annotations"])

3.“工具错误/人审/长对话摘要” 的生产级控制

v0.x：这些能力多靠自写回调或外层控制流拼起来。

v1.0 alpha：内置 Middleware 三钩子（beforemodel / modifymodelrequest / aftermodel）+ 现成中间件（摘要、人审、Anthropic Prompt Caching），还能 “跳转 / 中断”。

 1⚡ python片段from langchain.agents import create_agent
 2from langchain.agents.middleware import SummarizationMiddleware, HumanInTheLoopMiddleware
 3
 4agent = create_agent(
 5 "openai:gpt-4o",
 6 tools=[...],
 7 middleware=[
 8 SummarizationMiddleware(max_tokens_before_summary=4000),
 9 HumanInTheLoopMiddleware(tool_configs={"write_file": {"allow_approve": True}})
10 ],
11)

LangSmith 🦜️⚒️

●解决 LLM 应用开发中最头疼的调试、追踪和评估问题，这是其商业化的核心（收费）。一个应用越复杂，就越离不开 LangSmith，形成用户粘性。

●LangSmith = LLM 应用的 “一体化可观测 + 评测平台”：用来给 Agent / RAG / 多模态应用做全链路追踪（Tracing）、离 / 在线评测（Evals）、监控告警、成本与时延看板、Prompt 协作等；既可配合 LangChain / LangGraph，也支持非 LangChain 项目、OTEL 接入。

可以开源免费的 langfuse 替代 LangSmith

LangServe 🦜️🏓

●打通 “最后一公里”，让开发者能一键将用 LangChain 构建的应用 API 化

●LangServe 可以把 LangChain 的 Runnable/Chain 一键暴露成 REST API 的开源库，基于 FastAPI + Pydantic，自带 /invoke、/batch、/stream、/streamlog、/streamevents 等端点、自动推断 I / O Schema、内置 Playground，并可把追踪接到 LangSmith

收费吗？

库本身不收费。但其许可证限制：不得把 LangServe 作为托管 / 托管式服务提供给第三方（SaaS）。也就是说，你可以用它部署自己的应用，但不能把 “LangServe 平台” 卖给其他公司用。另外，LangChain 官方更推荐新项目用 LangGraph Platform（LangServe 只接受社区 bug 修，不再收新特性）。如果要 “托管式平台”，那是另一条产品线（付费）

LangChain 的使用争议

关于 LangChain 最开始的时候是一片盛赞，几乎全是正面评价，但随着开发者使用的深入，不断有负面评价出现。

LangChain 在使用上的主要争议，或者说让开发者后来“抛弃” 它的主要原因有：

1.API 频繁改、文档滞后，维护成本高

○2023–2025 年间最常见吐槽：接口 / 导入路径经常变、语义化版本执行不严、文档跟不上，导致线上项目要反复改代码与迁移；社区讨论与帖子里这一点重复被提及。官方后来在 0.2 才引入 “版本化文档”以缓解这个痛点。Reddit

2.抽象层过重/“抽象泄漏”

○本来想简化 LLM 应用，但层层抽象（Chains/Agents/Memory/Tools…）让简单事变复杂；当跨供应商（OpenAI/Anthropic）或多模态/工具调用时，还是要理解底层差异并写分支，抽象并未完全 “挡住细节”，很多人因此更倾向 “直接调 API / 自己拼装”。

3.性能 / 成本开销与 “隐形调用”

○经验帖里常见：token 使用低效、默认批量/重试/校验带来额外请求与延迟；默认设置偏原型友好，不一定适合生产（缓存、批处理、上下文裁剪都要自己细调）。DEV Community

4.调试与可观测性难（不用配套工具时）

○没接追踪时，多层封装中的报错 / 耗时难以定位，“像在雾里调试”；不少团队因此上了自家的可观测或放弃高阶封装。

5.学习曲线与 “过度框架化”

○许多工程团队反映：学习成本与收益不匹配，做简单的 RAG / 工作流时，直接 SDK + 少量自写代码更快可控；把 LangChain 当工具库（utility）用反而更顺。

6.生态分拆、选择困难与 “框架漂移”

○LangChain/ LangGraph/ LangServe/ LangSmith 产品边界不断演进；多数对比文章建议：流程化任务用 LangChain，复杂状态 / 多轮 agent 用 LangGraph—— 很多团队索性选更贴合场景的替代或 “手写”。DEV Community

上面这些点，不是说 LangChain “不能用”，而是在规模化、稳定性要求高的团队里，可预期性 / 可控性往往比 “快速堆组件” 更重要。

负面评价

这里我引用一些具体的负面评价，通过开发者真实的体验和文章来了解一下 LangChain 的问题。

为什么我们不再使用 langchain 来构建我们的AI代理

●来源： https://octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents

●结论：作者最初喜欢 LangChain 因为其丰富组件和易用性，但后来因其抽象复杂、灵活性差而不推荐。

初期为何喜欢使用 LangChain

作者在项目初期选择 LangChain，主要因为它具备以下优点：

●丰富的工具和组件：LangChain 提供了大量现成的模块，能快速搭建 LLM 应用。

●易于集成：框架承诺“让开发者一个下午就能从想法变成可运行代码”，适合原型开发和快速试错。

●人气高、社区活跃：2023 年 LangChain 热度很高，生态完善，容易找到资料和支持。

这些特性让作者在项目早期能专注于业务逻辑，而不用过多关心底层实现细节。

后期为何不再推荐 LangChain

随着项目复杂度提升，作者逐渐发现 LangChain 带来的问题：

1.抽象层级过多，代码复杂

○LangChain 引入了大量抽象（如 Prompt 模板、输出解析器、链等），让简单任务变得繁琐。

○代码难以理解和维护，调试时需要花大量时间研究框架内部逻辑。

2.灵活性不足，难以定制

○框架对底层细节封装过度，开发者很难根据实际需求修改或扩展功能。

○当需求超出 LangChain 设计假设时，反而成为限制，必须“将需求转化为适合 LangChain 的方案”，而不是直接实现业务逻辑。

3.适应快速变化的 AI 领域能力有限

○AI 和 LLM 领域变化极快，LangChain 的抽象和设计难以跟上新技术和新需求。

○框架的“嵌套抽象”导致开发者需要理解庞大的堆栈和内部机制，增加了认知负担。

4.团队协作和维护成本高

○团队成员需要花大量时间理解和调试 LangChain，而不是专注于功能开发。

○框架的复杂性让代码维护变得困难，影响开发效率。

反思与建议

作者认为，虽然 LangChain 在原型阶段有用，但长期来看，直接用基础库（如 OpenAI API）开发更简单、灵活。大多数 LLM 应用只需少量核心组件，无需复杂框架。对于 AI Agent 等复杂场景，建议在 Agent 模式成熟前保持简单，避免过度依赖抽象。

“一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。”

作者的经历体现了技术选型中“早期便利 vs. 长期灵活性”的权衡，也反映了 AI 应用开发领域对“抽象与简单”的持续思考。

2025 年了，LangChain 还是个无底洞。

https://www.reddit.com/r/LocalLLaMA/comments/1iudao8/langchainisstillarabbitholein_2025/?tl=zh-hans

给研发团队的建议

●“轻 LangChain”：保留少量 LCEL/Runnable 原语（或只用部分解析 / 工具封装），核心链路直接用供应商 SDK 实现，减少抽象层。

●“换轨到 LangGraph”：涉及复杂状态/长对话/人审/错误恢复的 agent，改用图式运行时（LangGraph / 其他工作流框架）。

●“专用 RAG 框架 / 自研”：检索、重排、结构化输出走 LlamaIndex / 自研管线

总之，手写代码是一条自主可控的道路，而梭哈 LangChain 可能会是一条不归路。

AI 编程工具使用有感

Thu, 26 Jun 2025 08:14:34 +0000

经过近 2 年的 AI 编程工具使用，积累了一些使用这些工具的经验和心得，本文分享出来。

以下分类纯属个人偏好，无任何客观依据，全是主观感受，仅供参考。

第一梯队

Claude Code、Cursor、Augement Code、Windsurf、Warp、Gemini CLI

第一梯队里的大家应该很熟悉，都是明星产品，我从接触时间的早晚来分别聊一下。

Cursor

Cursor 算是老朋友了，一直用。早期最令我兴奋的一款 AI 编程工具产品，还专门写了篇文章尬吹了一下 Cursor 一个真正让程序员产生危机感的 AI 编程工具，今天翻回去看，我觉得吹的内容用 Cursor 基本上都能实现了。

经过多次版本更新，Cursor 的使用模式稳定在了三种

用过 AI 工具的都知道，工具最核心的是底层使用的模型是什么，模型强不强决定着 “输出” 质量高不高，也就决定着代码质量。这跟开发者的切身利益可是息息相关的。

很多开发者使用 Cursor 最看重的就是它能够使用 Claude 家最能打的模型，过去是 claude-3.5-sonnet 现在是 claude-4-sonnet 以及 claude-4-opus 。这对于非专业开发者可能不够熟悉，大众更熟悉的是 OpenAI 的 4o 或者 Google 家的 gemini，无可厚非，但毋庸置疑的是，上面提到的 claude 家的一系列模型在编程领域就是最强的。不然广大开发者也不会心甘情愿的 “氪金” 来使用它。

越好的模型越受欢迎，自然价格也水涨船高，像下面这两个模型我一般不开，因为（Max Only）除了订阅费以外还要单独收费

除了常规的操作，Cursor 自然也加入了 MCP，你可以添加自定义的 MCP

不过从我的日常开发使用经验上来说，MCP 用的时候不多。Cursor 自己其实也内置了一些 MCP，比如它会读你的本地文件，新建终端并执行 CLI 命令，联网搜索相关问题的答案等。

Cursor 一直在更新，无论是添加新功能，还是改善老功能，总之肉眼可见的在进步，然而还是有一些常见的使用问题，它比较影响用户体验。比如使用 claude-4-sonnet 时经常报网络异常，你跟他开始聊得好好的，有时候就突然开始没法响应了，报网络异常，有些时候是真着急，因为你代码改到一半，消耗了那么多 token 和时间，总不能半途而费吧，可 Cursor 就是不给你响应了，等待让人焦虑和上火。这时候我通常会切换到其他模式试一试比如 gemini。gemini 的最大优点是上下文够长，1M 上下文一般一个 Thread 怎么也够用了。但这也有风险，就像你同时请教 2 位专家，一位说着说着停了，你转头问另一位，但关键是 2 个人就有可能有 2 种不同的思路，这时候修改代码就需要你特别注意了，不要被误导，因为第 2 位可能会完全颠覆第 1 位提供的代码和思路。（我已被坑过了 🤣）

其实这个问题我要反思，用 AI 工具开发，不能真的是 Vibe Coding ，因为我们是专业的开发人员，不能偷懒，否则容易被坑，得不偿失。**AI 要像 “领航员”、“辅助驾驶” 、“僚机” ，不能够完全托管给它，因为专业的开发人员写的代码不是玩具，也不是仅仅能 run 起来就行的代码。**我们要考虑的问题很多，比如架构、扩展性、易读性、性能、成本、团队情况等等。

如果你抱着谨慎的态度使用 AI编程工具和你一起编程的话，可能使用最多的就是 TAB ，而这一点 Cursor 做的相当不错，可以说是很神，你改了一个函数、参数、方法声明、方法实现，按一下 TAB 它是真的很智能，基本上能够想到你应该做的下一步是什么，这些本来就需要做的，比如重构，让它完美的提醒，这正是使用 Cursor 这种 AI 编程工具的一个非常适合的场景。

而如果你抱着宽容、放纵的态度使用 Cursor 的话就一定会被 AI 的另一面所伤，比如 “幻觉”，当然伤势情况根据你的宽容程度而定。如果你放手让他大刀阔斧的进行重构，它有可能删除很多文件，新建很多文件，理想的情况是完美的完成了，但前提也一定是你给他做好了任务规划，让他一次只完成一个具体的任务，而不是给一个比较笼统的要求，比如重构一下整个项目。

还有一种情况是上下文，虽然像 gemini 这种模型具有长上下文，我们在使用时也要脑子里有这根弦，上下文不能够太长，太长很容易产生幻觉和出一些意想不到的问题。我记得有一次我为了解决一个 bug，一直在一个 Thread 中和模型交互，模型最后的解决方案是把我 bug 相关的代码全部删除了，然后跟我说：“我保证，这次一定不会有问题了” 。 🤣 我是真谢了～

所以，我们到底应该抱以什么态度来使用 AI 编程工具是个关键的问题，我认为要具体问题具体分析，如果你真的是为了写一个 demo 而写代码，真的是能 run 就行，那可以采取比较激进和宽容的态度，放手让AI 实现，没什么大不了的，大不了就从头重写。而如果你写的是公司的生产级代码，那么就需要秉承谨慎和适当放手的策略，全程监督，让 AI 辅助你，而不是完全让他 “自动驾驶”。AI 越来越强大，但人类需要学习，哪怕慢一点，边学边干。否则……(此处省略一万字)

Windsurf

在早期，相对 Cursor,我更喜欢 Windsurf ，原因很简单，同样的底层模型，不知道为什么， Windsurf 给的结果就是更好，更实用、可用。其实发展到现在，从功能上讲它跟 Cursor 差别不大，但从我的使用习惯、使用频率、模型以及软件背后母公司的发展等多方面考虑，最后我还是选择使用 Cursor 作为主力 AI 编程工具。

后来的事情大家都知道了：“OpenAI 同意以 30 亿美元的价格收购Windsurf”

后来，Winsurf 发布了自己的新模型 : SWE-1

总之，Winsurf 并不是牛夫人，它是一个很不错的软件，我也表示对它的敬畏和欣赏，Cursor 有的问题它也有，Cursor 没有的问题它不见得没有，只不过是我使用的时间没有那么长而已。

也许有一天我还会转回使用 Winsurf，但现实就是如此，我不可能同时开那么多订阅，花那么多钱在多个 AI 编程工具上面。

Claude Code

就在 Cursor 等一众 AI Coding 工具大杀四方的时候 Claude 低调地推出了它的 Claude Code。起初非常不起眼，我甚至都没有兴趣试用一下，直到后来有很多人用过了以后开始对它大为赞赏这才引起了我的兴趣。

作为一个看起来有点儿 “土” 的工具，它是以终端命令的形式提供给用户使用的，不是 IDE，没有 GUI 界面，只有命令，你需要在终端使用命令和它交互。

其实作为专业的开发人员，对命令行并不陌生，反而会更亲近，这种形式没有 GUI，效率更高，但相对的是它对非专业人士没有 Cursor、VsCode 这种 IDE 友好。对于我来说，这无所谓，我都能接受。因为我看的是效果、结果、代码质量。

但另一个问题就是个很大的门槛了，那就是 Claude 的账户问题。无论使用 Cursor 还是 Claude Code，花钱订阅几乎是必须的，但 Claude 家对账号的管控几近变态，动不动账户就被 ban 了，你需要拥有一个 “稳定” 的干净的账号，然后再订阅，其实说难也不难，但处理起来比较麻烦。当然也有使用 API 中转的方式，相对方便，这里就不多说了。

我在深度体验了 2 天 Claude Code 后明白了为什么大家都想订阅 200每月的服务，因为真的很烧，而的是不限 token 的，而且服务比较稳定，不像 Cursor 时不时的会抽风。

我大致同意网上对 Claude Code 的赞美，但我也发现了很多无脑吹的，这和我的体验大相径庭，所以我得谈谈我的感受：

首先，Claude Code 内置了许多 tools，而且它对任务的规划比较完整，再加上 tools，这样它对任务的执行就比较完整，注意不是完美，而是完整，不会让一个任务 “缺胳膊少腿”，总是差一点儿。
完整的任务规划的代价就是烧 token，会用很多的 token，如果你没有订阅 200$ 这种无限量的，那可得省着点儿用。
会思考，根据上下文、程序的输出日志、执行情况推断任务是否完成，是否重新执行，是否修改任务重新执行等，你看这么多事儿都是要调用模型的，也是要烧 token 的。
无论哪个模型，仍然有幻觉，我们在其他 AI 工具上的经验可以移植，要谨慎，不要轻信它。
它看起来很强大，可以思考、规划并自动完成你指定的任务，即便是比较大的任务。但很慢，对于你自己能干的事情，没必要浪费时间让它干，之前我偷懒让它完善一下 .gitignore 文件，它花了好久才搞定，虽然正确，但我干只需要一秒。而它要动用很多工具进行全面的分析，最后得出一个只改一行代码的结论。有点儿坑。
对代码的管理依赖 git，虽然无可厚非，但确实不如 Cursor方便，鼠标点一下就能 restore 了。这一点儿我不争论，它是个习惯问题，就像不习惯使用 Vim 的虽然也承认 Vim 高效，但就是用不惯。
用最强的模型+最优的 prompt 自然能产生最好的结果，这是人和 AI 配合的结果，我不知道这个优点能不能算到 Claude Code 的头上，因为对于其他 AI Coding 工具也适用。我不知道能不能算的原因还有一个是我不并知道 Cursor 内部做了什么，Claude Code 内部又做了什么，我只能拿结果比较，事实是 Claude Code 略胜一筹，但却让我有一丝担忧，因为它总让我有种快控制不了它的感觉。（指不定什么时候要出事儿）

起初，我对 Claude Code 的热情是高涨的，但由于我的 2 个账号接连被 ban，订阅费又这么贵，合计了一下，还是回到 Cursor 了。这并不是说 Claude Code 不好，只不过对于我，这是个选择问题。

哦，对了，因为不是 IDE，纯命令行，所以如果你用习惯了 TAB ，Claude Code 可没有哈。使用模式要变。

Gemini CLI

Google 是一家任谁都不能忽视的公司，在科技领域遍布它的身影，自然 AI Coding 工具也少不了它的参与。

在我写这篇文章的上午，google 参战了，发布了 Gemini CLI，它是开源免费的，你用 Google 账号登录，就能直接使用，每天有 1000 次限额，够用了。

它的产品逻辑和 Claude Code 一样，你可以把它理解成 Claude Code 的平替。它是开源的。

从功能、使用体验、效果等各个角度来看，目前它确实都不如 Claude Code，但它的优势也是那么的明显：免费、gemini 2.5模型上下文够长，量大管饱、大厂背书可信赖、将来生态集成可期…

从我在 Cursor 使用 gemini 模型的经验来看，我对 Google , 不，应该是 gemini 是有强烈好感的，它确实强：比我命还长的上下文（1M），强大的推理和思考能力，不输给任何模型的基础能力，你还要什么自行车呢？用就好了。

Warp

Warp 最初是作为终端工具进入我的视野的，那时候我还在用 iTerm2，使用了 Warp 以后，被它良好的用户体验和优美的外观吸引。随着它不同的更新，在最近两年加入了 AI 功能，成为了一个智能开发工具。

由于我经常进行服务器的运维工作，终端工具的使用是非常频繁的，小到执行些基础的运维命令，大到写 shell 、python 脚本，进行服务器初始化、k8s 部署。

其实相比 Claude Code，Warp 新加的 AI 功能带给我的体验是很自然的。因为在命令行环境，我的输入、输出 Warp 都能捕获到，进而给我具体的建议和任务规划，当然，它背后仍然是大模型提供的能力。

在我敲命令时，它可以给我提示，当命令执行完成输出结果时，它可以指导我进行下一步的操作，如果我忘了命令该怎么写，它也可以完成命令，或者给出最合理的建议并自动执行。

当然用模型是要花钱的，它有一些免费的额度，用完了就需要付费了。最近它又加入了 “上下文” ，可以将你的代码工程作为上下文给他分析，同时与你一起结伴编程。

这就和 Claude Code 以及 Gemini CLI 很像了。不过说实话我用 Warp 还是基于命令行的场景，编程一般不会它，还是会用 Cursor。但它确实越来越强了，值得大家的关注。

Augement Code

无论 Cursor、Claude Code 如何优秀，都有令人不满的地方，在体验了这么多产品以后，我发现 Augement Code 比较适合我，虽然我还没有正式订阅，但它是目前为止我最满意的。

Augement Code 目前并不是一个独立的 IDE，而是一个插件，它可以在 IDEA 以及 VsCode 中安装使用。

作为一个 AI Coding 工具，它的基础功能和 Cursor 差不多，就不赘述了。下面说说它的特点：

你无法选用模型，从现在知道的资料来看，貌似使用的是 claude-3.5-sonnet ，但我觉得可能不是，很有可能是更强的。虽然无法选模型，但输出质量很高。不比 Cursor 这种可选模型的差。所以如果是 claude-3.5-sonnet 就能输出这样的质量，那 Augement Code 团队可真了不起。
会自动进行一系列的任务规划，并清楚地展示给你看具体细节

任务规划完成后，对于没有把握或你没有确认过的事项，更倾向于新建文件，而不是修改你原本的代码。这一点我很受用，因为 Cursor 经常在多轮对话中把代码越改越滥，最后迫不得已我点了 restore checkpoint
稳定，很少出网络异常
不便宜，需要订阅，比 Cursor 贵，每月 50$ 起，而且是限量的（600 次消息）

目前我还在试用中，从现在的使用情况看，后面很有可能会换用 Augement Code，退订 Cursor。不过我还是有点儿犹豫，因为 Cursor 不限量啊。

第二梯队

Cline、Copilot、firebase

从第二梯队开始，我在开发上的使用频率依次递减。

Copilot

应该是也不用过多介绍了。Github ，哦不，微软家的。

最开始是大哥，现在是小老弟了。平时几乎不用，偶尔测试一下，看看效果如何，一点儿都不能打，整体跟 Cursor 那一众差远了，

firebase

也是 Google 家的，但总感觉不是给开发者用的，全 web 的形式，不是 IDE，用起来别扭，但因为模型强大，所以做个前端 demo 什么的效果还不错，真正在开发场景我是不会用的。

Cline

开源免费，插件形式提供。自己通过 API 配置模型，整体效果还可以，但维护的心智成本略高，用了几天弃了，用回了 Cursor。不是人家不好啊，是我的选择问题。用的人还是很多的，整体成本小，对于用量不大的，你随便买个 API 一接就能使了。

第三梯队

Trae、通义灵码、MarsCode、微信开发者工具

Trae

字节家的，对于它，早期乃至现在的噱头都很足，可以在国内网络环境下使用世界最先进的模型。但是，我真的不知道是什么原因，同样的模型，比如 claude-4-sonnet Cursor 整体返回的结果就是 OK 的，Trae 就是稀烂。所以我怀疑不是模型的事儿，但又不知道是哪里出的问题。经过多次的尝试效果始终赶不上 Cursor，甚至还不如 Cline,弃了，以后也不会用。

不过它有它的市场，好好做也许会越来越好吧，谁知道呢？

通义灵码、MarsCode、微信开发者工具

这些产品我都是早期的使用者，开始都很惊艳，因为早期我也是土包子没见过世面，觉得 AI 工具真的很强大。后来被其他工具征服了以后对这些就没兴趣了。嗯，这些是真正的 “牛夫人”。如果有条件也不推荐别人用了，有更完善和强大的工具，没必要没苦硬吃。

第四梯队

DeepSeek、ChatGPT、Claude、通义千问、腾讯元宝等

理论上这些在我这里都不算 AI 编程工具，它们全部都是文生文的产品。只不过内置了可以预览和编程的工具。但那都仅仅限于代码片段。写个玩具还行，写项目？别闹。

最近 OpenAI 贼心不死，收了 winsurf 后还要搞编程工具，出了个 codex 集成在 ChatGPT中。说实话，玩玩儿还行，有点儿鸡肋。

其他

v0、bolt、Lovable

如何让 AI 编程赋能给普罗大众？以上这些产品给出了各自不同的答案。

v0

v0 是我使用最多的产品，一般画个架构图，写个页面 Demo，直接聊天就行了，效果也是越来越好。

bolt

bolt 由 Supabase 集成支持，支持上传图片/文件作为提示生成应用原型，适合快速开发应用。支持从设计稿到应用的一键生成。（是这么宣传的，但越是复杂的项目越不可能）

Lovable

支持通过自然语言生成交互式界面代码，与 v0 类似，但更侧重于低代码与 AI 结合的开发模式，适合非技术人员快速构建应用。尤其偏重于设计师群体。

设计这个领域不止是 Lovable，国人也有产品发布，比如 YouWare。

YouWare 拥有「代码快速转化与分享」「自然语言生成网站」「一键美化作品」「创意流动与共创」「和谐社区环境」「自主控制作品曝光」和「创作激励体系」七大产品亮点。

创始人明超平曾在一加手机担任手机影像产品经理，在字节跳动负责剪映 / Capcut 手机端工具，在月之暗面做过核心产品负责人。

YouWare 这个产品就是 帮助普通用户通过 AI Coding 将创意和灵感迅速转化为作品

最后

我将用一句话总结一下 AI Coding 的未来：帮助用户（专业的和普通的）通过 AI Coding 将想法利用代码作为媒介转化成产品。

无论是什么想法
无论是什么产品
无论是什么用户

AI Coding 未来的想象空间，理论上，是无限的。

从初始化一个现代 python 项目中学习到的东西

Sun, 27 Apr 2025 06:57:05 +0000

uv

我准备用 uv 初始化一个 python 项目

环境

我用的是苹果笔记本 MacBookPro ，具体的操作系统及硬件参数如下：

uv 的介绍与安装

“

uv 是一个使用 Rust 编写的工具，可以用来替代 pip、pipenv、pipx、poetry、virtualenv 等工具的使用，甚至还可以用来管理系统中所安装的 Python 发行版。uv 借鉴了很多现代语言中对于项目依赖的管理方式，项目中对于依赖的管理要远远优于使用 pip 和requirements.txt的方式。

我之前用过 pip 、pipx 等工具，发现 uv 确实要快不少。具体有多快呢？ github 上有个图：

🚀速度比传统 pip 快 10-100倍。

根据官网的介绍，uv 主要支持以下功能：

支持版本锁定的项目依赖管理。
支持直接运行 Python 脚本。
支持对系统中安装的 Python 进行管理，支持多版本 Python 共存。
支持 Python 包的发布和安装。
支持兼容 pip 的应用接口。
支持 Cargo 模式的项目工作区管理。
更优化的全局支持库缓存。
运行无需 Rust 或者 Python 支持。
支持 Windows、macOS 和 Linux 系统

uv 对多 python 版本和环境的管理很不错，这样你就可以一个项目指定一个特定的 Python 版本，放心使用，想怎么折腾怎么折腾，不会影响全局。

最近比较火的 MCP 很多也是用 uv 运行的，因为用 uv 命令可以直接运行 python 脚本。

uv 的安装非常简单：

1# macOS和Linux
2curl -LsSf https://astral.sh/uv/install.sh | sh
3
4# Windows PowerShell
5powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

uv 对 Python 的环境管理

首先用 uv 管理一下我们本机安装的 Python 环境。即到底安装了几个、哪些版本的 python。

可以用 uv python list 查看，像这样：

可以看到我已经安装了多个版本的 python。在后面建项目的时候，我选用 3.13 这个版本。当然你也可以根据你的情况下载新的需要使用的版本。这里给出一组相关命令：

1uv python install，安装指定版本的 Python。
2uv python list，列出系统中当前已经安装的 Python 版本。
3uv python find，查找一个已经安装的 Python 版本。
4uv python pin，固定当前项目使用指定的 Python 版本。
5uv python uninstall，卸载指定版本的 Python。

比如我要安装 3.12 这个版本，我就可以这样：

1uv python install 3.13

装好了不想要了，就可以这样卸载掉它：

1uv python uninstall 3.13

uv 进行项目管理

python 的环境有了以后，我们就可以新建项目了，建项目的时候也要用 uv 来进行初始化。

“

uv 的项目管理功能更多的借鉴了 Rust 中 Cargo 工具的项目管理理念。但主要区别是 uv 是通过项目目录中的pyproject.toml文件来完成项目管理的。

1uv init myproject

初始化后会生成以下几个文件：

虽然 uv init myproject 会帮你创建项目目录和 pyproject.toml，但默认不会自动创建虚拟环境（env），所以我们需要手动创建。

1# 手动创建虚拟环境
2uv venv --python 3.13
3# 激活虚拟环境
4source .venv/bin/activate

虚拟环境激活后，项目中会多一个.venv 文件夹。

接下来我们要自己创建一下源码目录和测试目录：

1mkdir -p src tests

到这里工程的相关目录我们就先到此为止，基本上创建完了，然后我们来编辑

pyproject.toml 配置文件。

toml 配置文件

我们先介绍一下 toml 文件，可能有些朋友不怎么了解它，比如搞 java 开发的。

TOML（Tom’s Obvious, Minimal Language）是一种配置文件格式，设计目标是易读、易写、易于解析，非常适合作为程序的配置语言，尤其是在现代的跨平台开发中被广泛采用。

你看这名字是不是觉得肯定跟 Tom 大哥有关系？

对，因为 TOML 由 GitHub 联合创始人 Tom Preston-Werner 在 2013 年发起，用以替代 JSON、INI 等配置格式在可读性和灵活性上的不足。

不过吧，后来这大哥（和她媳妇）不在 GitHub 干了，因为他们的一些不光彩的行为。具体是什么就不多说了，想八卦一下的可以去查查。

toml 配置文件用途广泛，常用于以下场景：

应用程序运行时配置
包管理工具（如 Python 的 pyproject.toml、Rust 的 Cargo.toml）
构建工具配置（如 poetry.toml, uv.toml）
数据库或服务连接信息等环境参数配置

举个例子吧：

 1# 数据库配置
 2[database]
 3server = "192.168.1.1"
 4ports = [ 8001, 8001, 8002 ]
 5enabled = true
 6
 7# 应用信息
 8[app]
 9name = "MyApp"
10version = "1.0.0"
11release_date = 2025-04-25T12:00:00Z

TOML 的特点可以总结为：

“

“比 JSON 更适合人读，比 YAML 更适合程序解析。”

它已经成为现代软件开发中最流行的配置文件格式之一，特别是在需要 清晰结构 + 丰富类型 + 可维护性 的场景中表现出色。

常见语言的支持情况：

Python：tomli / toml / pytoml / tomllib（Python 3.11 原生支持）
Rust：官方包管理工具 Cargo 就使用 TOML 格式的 Cargo.toml
Go：支持 BurntSushi/toml 库
Node.js：支持 @iarna/toml 等多个库

常见用途：

Python 包管理：pyproject.toml（PEP 518 标准）
Rust 项目管理：Cargo.toml
Web 项目配置：netlify.toml
DevOps 工具：例如 uv 的配置也是用 toml 文件

TOML 与其他格式的对比：

特性	TOML	JSON	YAML	INI
可读性	✅ 高	中	中高（但复杂）	中
注释支持	✅ 支持	❌ 不支持	✅ 支持	✅ 支持
数据类型支持	✅ 多	✅ 多	✅ 多	❌ 有限
库支持	✅ 常见语言皆支持	✅ 全面	✅ 全面	✅ 较好
学习曲线	✅ 低	✅ 低	❌ 偏高	✅ 极低

你看，TOML 作为配置文件感觉很不错对吧。

我们关于 TOML 的介绍就到此为止，现在来说一下我们这个初始化的新项目中的 pyproject.toml 文件要写成什么样。

就这样：

 1[build-system]
 2requires = ["hatchling"]
 3build-backend = "hatchling.build"
 4
 5[project]
 6name = "myproject"
 7version = "0.1.0"
 8description = "一个基于Python 3.13.3的项目"
 9readme = "README.md"
10requires-python = ">=3.13"
11authors = [
12 {name = "xiaobox", email = "xiaobox@gmail.com"}
13]
14dependencies = [
15 "pytest>=7.4.3",
16 "fastapi>=0.110.0",
17 "uvicorn>=0.27.0",
18 "httpx>=0.27.0",
19]
20classifiers = [
21 "Programming Language :: Python :: 3.13",
22 "License :: OSI Approved :: MIT License",
23 "Operating System :: OS Independent",
24]
25
26[project.scripts]
27myproject = "src.main:main"
28
29[project.urls]
30"Homepage" = "https://github.com/yourusername/myproject"
31"Bug Tracker" = "https://github.com/yourusername/myproject/issues"
32
33[project.optional-dependencies]
34dev = [
35 "black>=23.1.0",
36 "isort>=5.12.0",
37 "mypy>=1.5.1",
38]
39
40[tool.pytest]
41testpaths = ["tests"]
42
43[tool.black]
44line-length = 88
45target-version = ["py313"]
46
47[tool.isort]
48profile = "black"
49line_length = 88
50
51[tool.hatch.build.targets.wheel]
52packages = ["src"]

别小看了这个文件，它可是一个使用了 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。

所以我们得逐行解释一下这个重要的文件。

toml 配置文件的逐行解释

我们上面的配置文件是一个标准的 Python 项目使用 pyproject.toml 来管理构建系统、依赖、工具配置的典型示例。下面我们来拆解和解释一下。

✅ [build-system]：构建系统配置（PEP 517 标准）

1[build-system]
2requires = ["hatchling"]
3build-backend = "hatchling.build"

requires：构建该项目所需的构建工具，这里是 hatchling，必须先安装。
build-backend：指定用哪个构建后端来执行打包任务，这里是 hatchling.build。

hatchling 有点儿类似 java 中的 Maven 或 Gradle，都是用来执行自动化构建流程的。

Maven 是把 java 代码编译、构建成 jar 包，方便管理依赖、分发、版本控制
hatchling 是把 python 代码构建成 Wheel（.whl 文件）或 Source Distribution（.tar.gz 或 .zip 文件），也是为了做依赖管理、分发和版本控制。

总结来说：Python 的构建是将代码和依赖打包成 .whl 或 .tar.gz，类似于 Java 打包成 .jar。核心目的是简化分发、确保环境一致性、自动化依赖管理。

✅ [project]：项目的核心元信息（PEP 621 标准）

1[project]
2name = "myproject"

项目名称，最终发布到 PyPI 时会用这个名字。

1version = "0.1.0"

当前版本号。

1description = "一个基于Python 3.13.3的项目"

简短的项目说明。

1readme = "README.md"

指定项目的 README 文件，将作为 PyPI 上项目首页的介绍内容。

1requires-python = ">=3.13"

要求的 Python 版本最低为 3.13。

1authors = [
2 {name = "xiaobox", email = "xiaobox@gmail.com"}
3]

作者信息，支持多个，用列表表示。

1dependencies = [
2 "pytest>=7.4.3",
3 "fastapi>=0.110.0",
4 "uvicorn>=0.27.0",
5 "httpx>=0.27.0",
6]

项目的运行时依赖库，在安装时会自动安装这些包。这里我加入了 pytest、fastapi 的依赖，因为我想把这个项目作为一个 api 服务提供出去。

1classifiers = [
2 "Programming Language :: Python :: 3.13",
3 "License :: OSI Approved :: MIT License",
4 "Operating System :: OS Independent",
5]

用于 PyPI 分类（帮助搜索和筛选）。

✅ `[project.scripts]`：定义可执行命令（如 CLI）

1[project.scripts]
2myproject = "src.main:main"

安装后运行 myproject 命令会调用 src/main.py 中的 main() 函数。（我们需要提前把之前的 main.py 文件要先移动到 /src 目录下）

✅ `[project.urls]`：项目的相关链接（非必须）

1[project.urls]
2"Homepage" = "https://github.com/yourusername/myproject"
3"Bug Tracker" = "https://github.com/yourusername/myproject/issues"

为项目指定一些有用的链接，如主页、问题反馈页等。

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

1[project.optional-dependencies]
2dev = [
3 "black>=23.1.0",
4 "isort>=5.12.0",
5 "mypy>=1.5.1",
6]

我们为开发环境安装了三个库：black、isort 和 mypy

介绍一下这三个工具

black：是一个 Python 代码格式化工具。自动把你的 Python 代码排版成统一风格，比如：缩进、换行、空格都按标准格式处理，让你的 Python 代码看起来更整齐、统一，无需自己动手排版。
isort：是一个 Python 导入（import）语句自动排序工具。自动整理文件顶部的 import 语句，比如按字母顺序排列，分组标准库、第三方库、自定义模块，保持导入部分有序且规范。
mypy：是一个 Python 静态类型检查工具。检查你的代码里的类型注解（type hints）是不是正确，比如函数参数和返回值类型对不对，帮你在写代码时发现类型出错的地方，提前避免 bug。

✅ `[tool.pytest]`：Pytest 配置

1[tool.pytest]
2testpaths = ["tests"]

指定测试用例所在路径，pytest 会从 tests/ 目录开始查找测试文件。

✅ `[tool.black]`：代码格式化工具 Black 的配置

1[tool.black]
2line-length = 88
3target-version = ["py313"]

设置代码的行最大长度为 88（默认值），目标 Python 版本是 3.13。

✅ `[tool.isort]`：import 排序工具 isort 的配置

1[tool.isort]
2profile = "black"
3line_length = 88

使用 black 的风格对 import 排序。
设置行长度为 88，与 black 保持一致。

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置

1[tool.hatch.build.targets.wheel]
2packages = ["src"]

指定打包时要包含的代码目录为 src。

用一句话总结下这个 pyproject.toml 配置文件：

“这是一个使用 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。”

安装和更新依赖

上面这个文件编辑完成后，我们就可以安装项目和开发依赖了：

1uv pip install -e ".[dev]"

如果后面你更新了 pyproject.toml 文件可以执行以下命令来 “手动刷新” 一个依赖库：

1uv sync --extra dev

加入 --extra dev 参数是因为 uv sync 默认只安装 [project.dependencies] 中列出的正式依赖。

不会自动安装 [project.optional-dependencies]（比如 dev 里面的 black、isort、mypy）

uv sync --extra dev 的意思是：除了正式依赖，还要把 [project.optional-dependencies.dev] 里的东西也同步上

uv.lock

当执行完 uv sync --extra dev ，安装好依赖好， uv 会在项目根路径生成一个 uv.lock 文件。uv.lock 是锁定依赖版本的文件。

它的作用是：把 pyproject.toml 里描述的依赖（比如 “fastapi>=0.110.0” 这样比较宽松的范围），具体锁定成明确、唯一的版本（比如 “fastapi==0.110.1”）。

这样，每次安装时，不管谁来安装（你自己、你的同事、你的服务器），大家安装的依赖版本都是一模一样的，不会因为小版本不同导致奇怪的 bug。

uv.lock 是自动生成、自动管理的。不需手动编辑。

其他

其他的，如 fastapi 相关的、打 docker 镜像部署什么的相对本文主题超纲了，就不在本文中过多描述了。

总结

本文我们分享了用 uv 初始化和管理 Python 项目的完整流程。

从安装 uv 开始，我介绍了它为什么比传统工具（pip、pipx、poetry 等）更快更好用，以及 uv 在多 Python 版本管理、依赖锁定、项目初始化方面带来的便利。

随后，详细讲了如何用 uv 管理本地 Python 环境、新建项目、创建虚拟环境、编辑 pyproject.toml 配置，并逐步解释了各个配置项的作用

整体来看，uv 提供了一套现代、规范、高效的 Python 项目管理方案，非常适合用来打基础，后续无论是开发 API、打包 Docker 镜像，还是部署上线，都能有条不紊地进行。

同时我们通过在项目创建的过程中看到各语言（java、nodejs…）都相通或类似的工程 “最佳实践”，真是应了那句话：“大道至简，真理趋同”

MCP on 小盒子的技术分享

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

全程0人工写代码！干掉低级码农的不是大模型

全程0人工写代码！干掉低级码农的不是大模型

1 极致标准化的预热沙盒（Devboxes）

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

3 极其克制的上下文投喂：规则文件与 Toolshed

4 反馈左移（Shifting Feedback Left）：极速纠错循环

给我的启示

参考

OpenAI DevDay [2025] 概览

Apps in ChatGPT

交互式应用集成

自然语言启动

开发者工具 (Apps SDK)

首批合作伙伴

安全与隐私

未来规划

AgentKit

工作原理

主要功能

Agent Builder

与 n8n 、Dify 的区别

Connector Registry

ChatKit

Evals Capabilities

Reinforcement Fine-Tuning (RFT)

Sora 2 API

使用指南

Codex 正式版发布

GPT-5 Pro

GPT-Realtime-Mini

GPT-Image-1-Mini

LangChain：是银弹，还是 “技术债”？

引言

高代码与低代码

高代码

低代码

场景选型

混合实践

LangChain

概念说明

大模型应用开发核心矛盾

框架介绍

LangChain 能够解决的五类问题

1. 模型与提示（I / O 层）

2. 链式编排（流程层）

3. 检索增强生成 RAG（数据层）

4. 智能代理（自主层）

5. 评估与观测（质量层）

架构图

架构层次

模块结构

Runnable 抽象

LCEL：声明式表达语言

Schema 与类型系统

场景 1: 从简单的闲聊到有角色区分的对话

场景 2: 我需要 AI 给我一个结构化的数据，而不是一段话

场景 3: 让 AI 使用我们定义的工具

核心抽象组件

Language Models (语言模型)

Prompts (提示模板)

Messages (消息)

Documents (文档)

Retrievers (检索器)

Vector Stores (向量存储)

Embeddings (嵌入)

Output Parsers (输出解析器)

Tools (工具)

Callbacks (回调)

Memory/Cache (记忆/缓存)

对照表

Agent

LangGraph

LangGraph 架构

竞品

推荐学习路径

掌握灵魂 ——LCEL (LangChain Expression Language)

构建最核心的应用 ——RAG

进入高阶 ——Agents

✅ `[project.scripts]`：定义可执行命令（如 CLI）

✅ `[project.urls]`：项目的相关链接（非必须）

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

✅ `[tool.pytest]`：Pytest 配置

✅ `[tool.black]`：代码格式化工具 Black 的配置

✅ `[tool.isort]`：import 排序工具 isort 的配置

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置