Langchain谁开发

别再纠结 diffi 还是 linchain 了，原声 api 才是 llm 开发的第一性原理。开发 ai 应用，该选 diffi 还是 linchain？ 这个问题在技术圈吵翻了， 但我要说一个可能扎心的观点，如果你想真正掌握 llm 开发，这两个暂时都别碰。最好的方式是直接用 python 调用原声 api。 为什么？因为框架的约束往往大于赋能。 我们先理清一个常识，框架是为了解决什么问题诞生的， spring 解决 java、 ae 的 繁琐配置， react 解决复杂的状态管理。它们的共同点是，所在领域已经高度成熟，最佳实践已经固化。 此时框架通过强约束让开发者遵循标准动作。但 l l m 领域完全不同。 现在的 ai 技术站是以周围单位在迭代 open ai， 今天推出 structured outputs antropic， 明天更新 context caching， google 后天搞出原声多模态流逝输出。这时候你用 linchang 会怎样？ 第一，等社区适配新特性，通常滞后好几周。第二，学习各种新名词，智能体，上下文记忆工具包装一个本来很简单的 api 调用。 第三，代码报错时，堆栈信息被层层抽象掩盖，你根本不知道是 prompt 错了，还是框架参数传丢了。在这个阶段，框架跟不上技术迭代，用静态的框架封装动态的底层技术，结果就是削足适履。 很多开发者怕裸写 api， 觉得处理 h t t p 请求很麻烦，但在 l l m 开发中，这种麻烦恰恰是核心竞争力。先说第一点， prompt 是 唯一的源代码。在传统编程中，原代码是逻辑。在 ai 编程中， prompt 加 context 是 逻辑。 当你用 open a chat completion 是 多少， system prompt 是 什么？ 而你调用 sum 下划线 change run 时，你失去了这种掌控，很多框架会在背后悄悄塞入默认 prompt， 比如 you are helpful assistant， 这往往是输出不服预期的元凶。直接调用 api， 意味着你对输入输出有百分之一百的解释权。 第二点，调试的便利性。没什么比看着原始 g s o n 响应更让工程师安心的了。原声代码出错报错指向第几行就是第几行框架出错，你得深入阅读原码，理解作者的设计哲学，才能找到 bug。 第三点，快速适配新特性。想试用 openai 的 realtime api 原声 python， 照着官方文档写个 web socket 客户端半小时搞定，等框架封装，可能两周后还在看 github issue 的 争吵。 当然，我不是全盘否定这两个工具，而是要否定把他们当默认其手势的思维懒惰。 先说 land chain， 它最大的问题是过度抽象，试图用传统的面向对象编程思想去封装不确定的自然语言逻辑，导致创造了大量非必要的概念。对初学者来说，学 land chain 的 难度甚至高于学 l l m 本身， 但它也有价值。它是极好的教科书和组建库。你不需要用它的全套架构，但可以参考它的文档提取器和文本切分器，把 land chain 当做工具箱，而不是框架。再说 diffy， 很多开发者试图在 diffy 上拖拽，实现复杂业务逻辑，最后发现连个简单循环都极其别扭。 diffy 不是 万能的低代码平台，它的价值在哪？它是极佳的 best 和 mvp 验证工具，产品经理想快速验证 idea， 用 diffy 十分钟搞定， 需要快速交付企业知识库。 diffy 的 red 流水线是现成的最佳实践，它的核心价值在于服务化和可式化，而不是灵活性。基于上面的分析，我建议的最佳时间路径是这样的， 第一阶段，原型与探索工具很简单， python 加 open a 官方 sdk， 再加 pedantic。 做法是手写 prompt， 手动管理 chat history 列表。目的是什么？深刻理解 l l m 的 无状态特性， context window 的 限制， prompt engineering 的 技巧， 这是基本功，不可逾越。第二阶段，工程化与结构化。这时候痛点来了，原声 api 返回的是字符串，难以集成到系统中，怎么办？引入轻量级工具，比如 instructor 或 light l l m， 做法是强依赖 structured output， 将 l l m 的 输出强制转换为 j， s， o， n 或 pedantic 对 象， 目的是让不确定的 a， a， i 变成确定的函数。调用。第三阶段，复杂编排。这时候业务逻辑变复杂了，需要多步推理工具调用。 rack 怎么选？如果是标准的 rack 或客服机器人，直接部署 dfi， 不要重复造轮子。 如果是深度定制的垂直 agent， 比如代码审计，法律文书生成，自己写编排逻辑，参考 line， graph 的 图概念，但尽量用原声 python 的 if else well 来控制流程，而不是用复杂的 chain 类 软件。工程界有句名言，如无必要误增实体，避免引入复杂性。 ai 上在抢宝，所有的 best practice 都还在定义中，过早绑定在某个框架上，不仅限制视野，还会让你变得被动。反扑归真，回到 python， 回到 h t t p， 回到 prompt， 在那里你将看到 ai 最真实的模样。也只有在那里，你才能构建出真正属于你的核心壁垒。你怎么看评论区聊聊。

二零二六年 ai 开发智能体框架推荐二零二六年了，我们正式进入了全面的大模型人工智能年份。你看啊，现在的各行各业软件和平台都在进行智能化的改造。而在编程领域， python 依然是智能开发技术的核心，用它来开发 ai 智能体，也就是 agent， 绝对是首选技术。 在 python 的 生态里，目前有最主流的两大智能体开发框架，分别是，第一是国外的老牌强者 luncheon， 第二个是我们的国产之光阿里巴巴开源的 agent scope。 咱们先说 luncheon， 它的特点是生态极大，组建丰富。作为最早出圈的框架，它呢，就像是一个巨大的乐高积木库， 它拥有超过两百多个预制的组建，无论是连接各种大模型处理、文档解锁，也就是 reik， 还是调用外部工具，它呢，几乎全都封装好了。 它的优势在于社区活跃，教程多，你想实现什么功能，大概率都能找到现成的链条进行拼接，非常适合快速圆形的开发和单智能体的应用。 再看 in scope， 它的特点呢，是原生的多智能体，协助透明可控。这是阿里的通用实验室专为生产级应用所打造的。 它呢，最大的亮点在于支持复杂的多智能体对话和群体智能，让多个 ai 像人类团队一样分工合作。而且它拒绝黑盒，主打开发者透明，从调试、监控到部署全流程可塑化，特别是在高频发和长城任务的处理上，它的稳定性和容错率非常高，更适合企业级落地。 那这两者有什么区别呢？简单总结， roc 胜在广，生态成熟，适合单打独斗的快速创新，是入门和做 demo 的 神器。 innoscop 胜在深，它架构结构专为多智能体协助和生产环境设计，使搞定复杂业务流和大型项目的利器。如果说啊， linc 是 灵活的特种部队，那 innoscop 就是 纪律原明的集团军。 如果你想学习智能体的 ai 编程，现在立刻入手这两框架中的一个绝对没错。二零二六年大模型智能化的乘风车已经发车，别只在旁边看，选一个框架，动手写出你自己的第一个智能体。抓住这波技术红利，关注我，带你掌握更多的 ai 开发干货！

在过去一段时间，我们分享了 entropic luncheon minus 在 上架文工程上的理论和实践，内容较为零散，需要系统总结。 前两天， luncheon 的 工程师 lansmartin 对 agent 的 上下文工程进行了系统梳理，恰好能串联我们之前的内容，呈现出一套业界顶尖团队正在趋同的上下文工程指南。 首先，我们必须理解问题的根源， agent 的 本质是在循环中调用工具的大语言模型模型调用工具工具返回观察结果，该过程不断循环。这个简单的循环在 agent 执行涨任务时会带来巨大挑战，那就是上下文爆炸。 menace 提到，一个典型任务平均需要五十次工具调用。 entropic 也佐证生产级 agent 的 对话轮次可能长达数百轮， 这意味着模型在每一步决策时都要背负之前所有轮次的工具。结果这不仅会导致成本和延迟急剧膨胀，更致命的是会引发我们此前在 encyclopedia 文章中学到的核心问题，也就是上下文腐烂。 上半页越长，模型在长距离推理、精确回忆方面的能力就越差。这形成了核心矛盾。 agent 因任务性质天然会产生巨量上下文，而模型在巨量上下文下性能会下降。为解决这一矛盾，上下文工程应运而生。正如 carpathia 所定义，它是一门精巧的艺术和科学， 只在用恰到好处下一步所需的正确信息填充向上纹窗口。在 lens martin 的 总结中，这门艺术被提炼为三个核心支柱。第一个是卸载， 将上下绳从 l l m 窗口转移到外部存储，比如文件系统，以便后续选择性解锁。第二个是缩减，减小每传递给模型的上下纹大小，比如通过压缩摘药。 第三个是隔离，为不同独立任务使用单独的上上窗口，也就是子 agent。 接下来，我们将深入解析这三大支柱在 menace blood code 等顶级 agent 中的具体应用。 首先是支柱一卸载，这部分已从卸载数据进化到卸载工具。卸载数据对应的正是我们精讲的文件系统及上下文。核心是赋予 agent 文件系统， 使其能在长任务中保存和回忆信息。一个经典应用是对抗目标漂移。在 anthropic 的 多 agent 研究中， agent 会将计划写入文件，执行完一系列子任务后再读回计划，确保不偏离目标。这正是我们精讲的 minus totalment 复述技巧的变体。另一个应用是跨绘画记忆， 比如 cloud code the cloud 点 md 文件，允许 agent 在 多次调用间持久化存储。用户偏好卸载工具是更深刻的进化，对应我们精讲的分层行动空间，核心问题是若有一百个工具都塞根 prompt， 会导致模型混淆和 prompt 的 臃肿。 manus 的 解决方案是保持函数调用层。第一层极简，只保留少数原子工具，比如 bash 和文件操作，将绝大多数动作卸载为文件系统中的脚本，这已成为一种业界共识。顶级 agent 的 原生工具级都极少， cloud code 仅约十二个， manus 不 到二十个。 lanchain 的 deep agents 仅十一个。卸载工具的最终眼镜是渐进式，譬如连脚本也不必一开始就全部告知模型，例如 antropic the skills 功能， agent 启动时仅加载每个 skill nbd 文件的标题。当 agent 决定使用某技能时，才会用 bench 工具完整读取该 skill or met 文件的全部内容。 minus 的 实现方式类似 agent 通过 bash 工具，比如 ls 和 help， 在 庞大的脚本目录中自主寻宝和阅读说明书。接下来是支柱二 缩减。这部分对于我们之前讲的 minus 联合创始人 peak g 的 分享，第一个技巧是压缩，且该操作可逆。 minus 的 做法是当工具结果变得陈旧时，将其完整内容卸载到文件，再再消息 历史中用一个指向该文件的指征替换它。核心价值在于背诊的未来仍可百分之一百恢复原始信息。第二个技巧是摘药，该操作不可灭。 minus 和 cloud code 都仅在压缩收益变小或上下文接近极限，比如说百分之九十五时才起用这个大招。 并且正如我们之前深入探讨的，执行摘药时应优先使用结构化 screen 而非自由格式，以保证关键信息不丢失。最后是支柱三 隔离，这对应我们精讲的多 agent 之间的信息同步模式。模式一，通过通信主 agent 给子 agent 传递简短指令，子 agent 在 隔离干净的上下文中完成任务，之后仅返回最终结果。该模式适合可清晰切分的简单任务。模式二， 通过共享上下文，此 agent 被允许访问副 agent 的 完整上下维历史，但在新的 system prompt 下行动。这种模式的核心权衡在于，此 agent 获得完整历史视野，能处理复杂任务， 但代价极高，因为更换 system prompt k 非缓存完全失效，必须支付全价的预填充成本。 landsmartin 此次分享的核心价值在于，让我们看到所有顶级生产级 agent 都带趋同于一套共同的经实战检验的架构。这套架构就是一个极简的原子的函数调用层，加上一个庞大的可供探索的外部文件系统与脚本库，它是整个行业为平衡无限的能力扩展与有限的上下文窗口这一核心矛盾共同引进而来的最优解， 将上善文工程从零散技巧提升为完整严谨的系统设计哲学。好了，今天的分享就在这里，希望这份极大成的指南能为你构建自己的 agent 提供清晰蓝图。若你觉得本期内容有帮助，别忘了点赞、收藏加关注，我们下期再见！

大家好，如果你最近在关注人工智能，那你一定听说过大语言模型，也就是 l l m， 你 肯定也知道它们非常强大，但同时呢限制也很大。 今天我们就来深入解析一个关键的框架，它正在释放 l l m 的 真正潜力，这个框架就是烂券。 你想想看，像 g p t 四 o 这样的大语言模型， l m m， 它的能力确实很惊人，就像一个知识渊博的大脑。 但问题是，这个大脑有一个根本的限制，它被困在了一个盒子里，它是无状态的，也就是说它根本记不住你上一句话说了什么，而且它也接触不到任何在它训练数据之外的实时的，或者你自己的私有信息。 所以一个核心问题就摆在我们面前了，我们到底要怎么才能打破这个盒子，让这些强大的大脑能够连接到外部世界，能够跟我们自己的数据 api 和各种工具进行互动呢？ 嗯，正是像 luncheon 这样的编排框架，也就是 orchestration framework 要去解决的根本性难题。 好在今天的解析里，我们会这么一步步展开，首先我们会看看 llm 到底缺了点什么，然后呢，我们会介绍 luncheon 是 如何作为一个编排层来补上这些缺失的。 接着我们会深入它的核心模块儿，特别是看一看链，也就是 chance 和代理，也就是 agents 到底是怎么工作的。之后我们会了解一下，让它能够真正走向生产环境的整个生态系统。最后，我们会一起展望一个有组合性驱动的未来。 好的，我们先来看第一部分 l l m 缺失的那些环节，就像我们刚才提到的 l l m 它自己啊，是无状态的，也连不上外部数据。所以在我们要构建一个真正有用的应用的时候，这些就是我们必须要去补上的关键环节。 于是我们的主角就登场了。 lank chain， 你 可以把它看作是一个非常强大的编排层，一个 orchestration layer， 它的核心任务就是把 l l m 这个孤立的大脑变成一个能够和真实世界互动、功能完备的应用核心。 我们来看一下官方的定义是怎么说的。 lanchen 是 一个多功能模块化的框架，它覆盖了从开发、生产化到部署由 l l m 驱动应用的全过程。 这里的关键词一个是模块化，另一个就是覆盖了整个生命周期，这对于开发者来说，真的是极大地简化了工作。 蓝券的核心理念啊，其实可以用一个词来概括，那就是组合性 composure， 这就像玩了个积木一样， 你可以把 l l m 这个核心引擎跟数据源计算工具 api 这些不同的积木块自由地拼接组合，这样呢，就能创造出远远超过单个 l l m 能力的非常强大的应用。 那么接下来我们就来深入了解一下 line chain 到底是由哪些基木块儿构成的，我们会来剖析一下它最核心的几个构建模块儿，看看它们每一个都解决了什么样的问题。 longchain 的 核心呢？主要是由六大组建，也就是 components 构成的，我们快速看一下，有负责跟模型打交道的模型 i o， 有 负责接入外部数据的数据连接，还有让对话能记住上下文的记忆机制，这三个呢，可以说解决了 l l m 最基本的几个问题。 然后呢，我们还有更高级的组建，比如负责执行一系列步骤的练 chance， 还有负责自己做决策使用工具的代理 agents， 以及用于 monkey train monitoring 和励志几路的回调 callbacks。 接下来我们会重点解析前面几个。 这张表格就很好地整理了我们刚才提到的核心问题和人券提供的模块化解决方案。 你看，无论是怎么跟不同的 l l m 对 话，怎么访问外部数据，还是怎么实现对话的记忆蓝券都提供了专门的可以即插即用的组建来应对，这正是它设计上的优雅之处。 在数据连接这个环节，有一个概念，你必须要知道它直观重要，叫做解锁增强生成，也就是 r a g。 简单来说， r a g 就是 在让 l l m 回答问题之前，先去外部的知识库里帮他查一下资料。比如说，你问一个关于公司最新财报的问题， r a g 会先去找到财报文件，把关键数据给提取出来，然后再把这些数据连同你的问题一起交给 l l m， 让他根据这些准确的信息来回答。 我们跟着这张图走一遍，这个 r a g 的 工作流程就非常清楚了。你看左边，我们先把各种各样的文档进行预处理，把它们转换成像量，然后存进一个向量数据库，也就是 vector story。 当用户提出一个查询，一个 user query 时，系统就会从这个数据库里检查出跟问题最相关的那几段内容。 最后看到右边这些检查到的上下文，也就是 context 会和原始的问题打包在一起，为给 l l m， 这样它就能生成一个有事实依据的更可靠的答案了。 好了，了解了这些单个的组件之后，重点来了，我们怎么把它们串联起来，去构建出能执行复杂任务，甚至还能自己推理的工作流呢？嗯，这就要靠链 chains 和代理 agents 把所有组建粘合在一起的胶水就是 luncheon 表达誓言，我们一般叫它 l c e l luncheon expression language， 它引入了一个非常优雅的设计，就是一个管道操作符，也就是我们键盘上的那个竖线符号。 通过它，我们可以用一种声名式的方式，把数据流从一个组建清晰兮兮地传递到下一个组建，从而构建出一个调用序列。 用 l c e l 来构建一个链，这个过程非常直观。首先一个提示词模板把我们的输入格式化， 然后通过管道符把结果传给语言模型，模型处理完之后，再通过管道符把输出传给一个输出解析器，这样最终我们就能得到想要的结构化结果。你看，整个数据流从左到右一目了然。 如果说练是我们预先设定好步骤的一个确定性工作流，那么代理 agents 就是 一次巨大的飞跃。 在 agent 模式下， l l m 不 再是被动地执行指令了，而是扮演了一个能够自主决策的大脑， 他会根据你给的任务目标自己去思考，去规划，然后决定要调用哪些工具，比如说搜索引擎或者代码执行器，来一步步的解决复杂的问题，这可是从执行指令到真正推理的转变。 当然了，构建出一个强大的原型还只是第一步，一个优秀的框架还必须要能支持应用的稳定部署和长期维护。现在我们就来看看 lanchen 已经发展出的能够支持应用全生命周期的生产就绪生态系统。 首先是 lms， 你 可以把它理解成是给 l l m 应用装上了一个飞行记录仪和调试器， 特别是对于复杂的 agent， 它的决策过程很多时候就像一个黑盒， lansmith 就 能追踪并且记录下 agent 的 每一步思考和每一次工具调用，让我们能清晰地看到它内部到底发生了什么，这对于调试和优化生产环境里的应用来说直观重要。 其次是 long serve， 当你辛辛苦苦开发完一个应用之后，怎么把它快速部署成一个稳定可扩展的 api 服务呢？ long serve 就是 答案，它能让你用非常非常少的代码就把任何一个 linkchain 应用打包成一个生产级的 rest api， 大 大加快了从开发到上线的速度。 最后是 line graph， 当我们遇到的问题，用简单的现行链条或者单个 agent 已经搞不定的时候，比如说你需要构建一个可以循环、有条件分支，甚至是需要多个 agency 一 起协同工作的复杂系统时， line graph 就 派上用场了。 它允许你用图，也就是 graph 的 方式来定义和编排这些有状态的、多角色的复杂工作流。 好的，我们已经看过了 linchang 的 内部祖宗和它的生产生态系统，其实所有一切都指向了我们一开始提到的那个核心理念，那就是组合性。现在我们就以这个为核心来展望一下它将如何塑造人工智能的未来。 从这张时间线你就能感受到 lanchen 生态的引进速度有多么惊人。从二零二二年十月一个开源项目开始，到后来 l c e l lancherf lance smith 的 相机推出，再到 lancherf 平台的发布， 它在极短的时间内就构建起了一个从开发到部署再到运营的完整平台。 艾伦图林研究所的这组评价我觉得非常精准地概括了 long chain 的 价值。他说， long chain 的 变破可能性在于它弥合了大型语遥模型的强大能力与跨领域实际应用开发之间的鸿沟。 说得直白一点，就是它把 l l m 从一个实验室里的强带玩具变成了一个我们每个人都可以用来解决实际问题的强大工具。 那么最后我们留下一个开放性的问题来共同思考，当组合性发展到极致，当无数个专攻不同领域的智能代理，也就是 agents 能够像人类专家团队一样无缝协助时，一个由组合式智能驱动的全新 ai 技员将会是什么样子？感谢各位的收听！