比如，在一个长达一小时的视频中：第 5 分钟，一个「穿蓝色衬衫的男人」出现；第 25 分钟，一个「戴着眼镜的男人」发表了讲话。对于人类观察者而言，很容易判断他们是同一个人。

但对于 AI 系统，这却是一个难题，因为AI自身是没有对自己已经处理过的知识信息进行提取处理的流程，因此AI是一个健忘的，没有记忆的人，它的记忆力始终停留在模型厂商训练它所使用的知识的阶段，无法进阶到使用者投喂给它的知识的这个阶段。

这个问题非常影响实际的质量，如果不解决这个问题，会导致智能应用最佳效果是上线那一刻，随着使用的时间增加，质量会越来越差，除非投入更庞大的维护成本，前几天字节出了M3 agent,刚好解决的是类似的问题：

M3 Agent的解决思路是由一个多模态大语言模型（MLLM）和一个外部的长期记忆模块构成。其运作通过两个并行且持续进行的过程实现：记忆化 (Memorization) 和 控制 (Control) 。

简单来说其实就是把知识提取出来后，从原始的数据中进行分层，再由控制器提供检索，而提取后又基于实体信息构建了一个知识网，而这和我正在尝试在外围构建一个服务,作为另一种类型的知识库，用于大模型自身的记忆模块的思路几乎一致。只不过M3 Agent目前是在多模态下做的尝试，而我则想构建一个更加通用的体系可以适应于不同的数据集，在大模型的问答之上，构建一个知识流转模块。

从长远来说，这个能力我认为大概率会被模型厂商给实现掉，因为如果模型在落地过程中如果不能解决记忆的问题，那么意味着每一个智能应用随着时间的推移，越使用维护成本会越高，这不太符合发展的规律。

在我看来，大模型自身的记忆能力和外围知识库的关系，并不是单纯的存储类型不同。

当我们在做存储系统,比如存算分离的情况下，通常会有一个本地缓存,将远端的数据缓存在本地,当查询的时候直接从本地读取则会大大提升加载速度。

这种情况下要求本地缓存和远端数据具有严格的一致性，然而在大模型和知识库之间，并非这样的关系，如果完全依靠大模型自身的能力去问答，显然会缺失很多内部的数据知识，导致答案质量不符合预期，如果外挂知识库,随着时间的推移，知识库会越来越庞大，必然导致检索时间增强，上下文内容过大,出现无法回答问题的情况。

为了解决这个问题,会做很多额外操作，比如知识的压缩,历史记录的对齐，甚至做部分微调来降低知识库的内容。

可以发现知识库的企业自有知识和大模型自身的知识之间并不是完全的一一对等，那么什么应该放在知识库，什么应该去微调，什么又是大模型的记忆数据,就必须定义的清清楚楚。

我认为从用户输入问题开始到模型产生输出，在这个过程中涉及到的数据的流转，经历的是知识的加工过程，而非数据存储的转移，应该遵循漏斗筛选的去转移知识。

也就是需要在用户的聊天记录+外挂知识库+大模型自身内置的知识中间形成一个流转和淘汰的机制。

而要形成这个机制，首先就需要对知识进行分层,比如最简单的知识分层：

• 用于存储历史记录的知识库。
• 用于存储领域知识的知识库。
• 用于存储问答所需要的知识的知识库。
• 用于存储微调数据的知识库。

在我开始设计UniverAI这个平台UniverAI一款企业AI员工协作平台的知识库的时候，我就首先考虑了领域知识和业务的数据知识。

在这多层知识库之间还需要有一个流动机制，当知识从上层流转至下层后，还需要进行清理,类似层级缓存的淘汰机制一样。

一个合理的，健康的，质量还不错的智能应用，应该是左边的这样一个知识分布，但是随着使用时间的增加，知识的变多，逐步会变成后边这种头头重脚轻的结构，导致大量的信息堆砌在了前端，需要借助庞大的上下文才能获得较好的质量，甚至都不能获得较好的质量，这时候整个应用会出现使用上体验变慢，知识维护麻烦，问答幻觉非常严重，问答质量非常差的情况。

因此需要一直机制，将起从后边拉回左边的结构，回归一个高质量应用的本体，而这个拉回的动作，实际上就是让上层知识流动到下层进行固化，因为固化了，自然就记忆到了下层，从而能解决大模型本身的记忆的问题。

而这个记忆管理模块，就需要负责全方位观察用户的输入和产生问题的答案的信息来源，从中整理出整个数据流向，因为这个模块不单要做知识的流转，还需要做知识的加工淘汰，就像人的记忆一样，有些错误的无用的信息，是没有必要保留的，需要适当的遗忘。

关于这个记忆模块的设计，后面的篇章再逐步展开。。。

几乎行业对AI的需求从来没有发生过较大的变化，那就是降低门槛，让能力不强的人，也可以干要求很高的事。

对于这种认知，我是不太同意的，我认为当AI能独立干很多事的时候，人的作用几乎会浓缩成一个：

处理异常情况。

这就像很多流水线的机器旁边总有一个人，在出现意外的时候立马去处理，这个人能力弱吗？错了，反而这个人的能力要求很高，因为只有能力很高的人，才能在极短的时间内去找到问题，解决问题。

而很多事AI能独立干了之后，其实就没有一般人的事儿了，也就是未来的淘汰链路和形态会是：

10个10块成本，共计100成本的团队，在引入AI后，会变成AI干掉所有的事，然后重新招聘一个80块成本的人过来充当异常处理者。

而要降低异常处理者的成本，那就是只有一个：培训。

将所有异常流程由非标转标，然后形成完备的培训机制，否则这个异常处理的成本会变的很高，虽然可能99%的时间都用不上，但是却无法淘汰，就像消防设施，可能用不到，但是谁敢说不需要，或者用廉价的呢。

发现问题->设计出方案->抽象成产品功能->卖出去。

在这样的一个链路下反复打磨，UniverAI这款产品越来越完善，生命力也越来越强，目前也已经在商业环境下运作良好，然而几乎没有时间来仔细回顾建造它的过程。

产品的打磨本身就是一件非常痛苦的事，除了设计本身外，还需要考虑市场端，如何卖，卖给谁。
虽然目前经过反复打磨和市场的验证，产品本身已经具备完整的商业能力，但是一个不能和行业深度绑定的产品，是很难直接对齐到业务价值，只是用什么样的形式去绑定。

未来我的主要精力会在于如何将这样的一个能力，和行业属性进行深入的绑定，我并不介意平台自身丧失部分通用性的能力，去换取具有更深价值的行业贴合度。

在今天来说，AI开发平台本身，已经不具有稀缺性，无论是私有化的，还是公有云的，无论是开源免费的，还是闭源收费的。
然而我相信即便如此，每一款产品依旧有它不一样的地方，这取决于设计者，取决于它的创造者对它赋予的期待，就像每一个小孩初步一看，都有手有脚有五官，但是细致去接触会发现一个个体都有完全不可替代的部分。

产品依旧如此，对于AI平台，在GPT刚出来的时候，我便直观的认为当AI的能力足够强的时候，它会作为一种基础设施存在，如同曾经的IAAS，而围绕IAAS的云化诞生出了一系列的PAAS服务。
同样当AI能力成为基础设施的IAAS层后，必然需要一种AI 的PAAS的形态去支撑企业新的应用形态的开发，到今天这个方向已经有无数的产品崭露头角，无论是Dify还是Coze本质上都在这个区间进行对齐。

就算是全民都在进行AI的基建，从产品设计的角度来说，也会有非常多的问题是尚未被标准化的，这也是我多次将大量的代码删了又写，写了又改，改了又删，只为找到一个走的通的逻辑，讲的明白的思路。
我曾经写过一篇文章：AI Agent骗局，AI Agent是个筐，什么都往里装 在这个概念被用烂的时间点，要自洽一个思路并不容易。

从整个产品设计的角度来说，AI落地核心其实就是：

大模型+知识+工作场景。

不外乎是怎么样落地，用什么样的形式落地，比如大模型+知识，可以是Rag，也可以是微调，而大模型和知识结合后所展现出来的理解力，再配合周边的系统集成，打包都叫智能体。
要拟人化的话，智能体会更加容易被类比成人。

那么接下来的问题就是如何让人工作起来，在这个问题上，UniverAI 重新实现了概念的映射，具体的逻辑为：

• 模型：刚毕业的学生，不同的参数的学生，具有不同的能力，类似于博士生，本科生，专科生。
• 智能体：将企业的知识和知识与模型进行了融合，约等于一个入职后且经过培训，可直接上岗的员工。
• 工作空间：员工可工作的岗位。

UniverAI提供以上整体端到端的构建能力的支撑，而这里的核心重点便是工作空间，我曾在仔细思考，所谓的A2A，multi agent system，到底有何意义，这种通信到底解决什么问题，从技术角度来说，单纯的通信不解决任何问题。
而无论A2A，还是MAS，本质上都是在为一堆智能体创造一个可以开展工作的环境，因此UniverAI抽象出了工作空间这个重要的模块，不同于其他产品的概念，UniverAI的工作空间，核心是基于业务场景下的工作空间，并非单纯的群聊，或者一堆能力的堆砌。

在工作空间内，有非常多的场景，每一个场景都基于行业特有的属性进行细节打磨，而场景下如何开展工作，已经被清晰的定义，这就意味着每一个场景都是直接对齐到业务的。

在工作空间内，是一群智能体的工作场合，是一堆员工上岗的工作岗位，是最终在业务角度对齐的交付产物。
而在这样的一个场景下，不同能力的智能体，可以协同完成该场景下的业务，且智能体可以自由搭配和组合。

也就是在UniverAI下，通过工作空间的属性，和行业形成了深度的绑定，UniverAI不单纯是一个开发平台，而是一款智能体的协作平台，在UniverAI下，可完成智能体的构建外，还可以完成多个智能体在行业场景下的协作办公。

所谓的深度pair，就是完成不用顾及成本，只需要关心效果，但凡有需要就提问，就和身边真正做了一个人一样，甚至还能抽空聊聊天，把沟通的频率加快到无时无刻不在发生，让对话保持和自己思路同步的节奏，不用瞻前顾后，替AI考虑。这成本似乎看起来不可思议，似乎看起来不可想象，但是实实在在就是花了这么多。

整个结果下来给我一个非常深的感受，那就是当一个项目在1万行代码以下，当一个项目不需要上下文，彻底从头开始，大模型能带来非常好的效果和体验，而这两个条件的约束下，我仅仅称之为入门的教程，使用if else也能达到类似的效果，不外乎穷举逻辑复杂些。

其次一个肤浅的认知，但凡月花费token在5千以下的，都没资格说自己体验过把AI作为生产力工具。

当一个项目的代码量在一万行以上的时候，哪怕这个项目是完全使用大模型从0开始编写的，它依旧会表现的一脸懵圈。而这，让我觉得大模型的记忆能力，一定需要发生质的改变，才能彻底解决一个核心问题，那就是：

大模型根本必须区分哪些东西是它自己写的，而这种区分不能是上下文记录的方式。

这就相当于一个人能一眼看出签名是不是自己写的，这本书是不是自己写的，只需要看目录就能知道自己书写的内容是什么，而这种记忆是大模型不具备的，这种能力的缺失会导致大模型完全无法驾驭大型项目，单纯依靠rag或者微调，都是死胡同。
目前我正在设想一种架构，用新的工程能力去解决两个问题：

• 如何让大模型能一眼识别这是自己的产出，从而快速会议起整个项目的上下文，避免大幅度的无用代码的重播。
• 如何让大模型的接口标注化，避免出错的时候才知道能力缺失，比如一个大模型是否支持图像输入，只有调用接口的时候报错才知道，否则需要人提前基于模型名字手工去登记约束，而这，明显是在开历史倒车。

在Agent流行的今天，到底花多少token，并不取决于用户本身的问题输入，因为Agent会基于自己的逻辑进行反复的思考和推理，多次与大模型交互，可能用户的问题只输入了一个字，但是发生了1000次和大模型的交互，而这1000次则是由Agent自由发挥出来的。
这也是我消耗token量最大的原因，当然，这并没有什么问题，因为我自己做Agent的时候也是这样干的，甚是Agent能自我思考，还会成为销售的卖点之一。

在这个月的时间内，我和AI进行深度Pair的代码工程量大概在20万行代码左右，刚好最近我又重新思考大数据的一些内容，而Hadoop 3.3.1整个工程已然超三百万行代码，我尝试过使用和他进行深度Pair，然后放弃了，因为如果使用Hadoop的话，一周可能3.5万就花光了。

我所选择的项目大约20万行代码，且将我所不擅长的领域，前端开发丢给AI去搞，虽然不擅长，但是如果AI写出来，我依旧能读的懂，能修改，这样AI则能完全弥补我所面对的能力不足的短板问题。

在这个过程中我无时无刻不面临一个非常痛苦的问题，就是如何让大模型知道，这个事它已经干过，这是一个非常痛苦的事情。当然很多搞过Agent的人会嗤之以鼻说这不就是Agent自己的历史记录，或者自己做一个历史记录，再结合大模型自身的Cache能力，能保留历史记录的同时，还能降低Token的成本。

这当然是一种缓和的方案，但是这种固化，低效，且不具备任何智能的硬记忆丝毫不能让大模型有进化的能力，它永远像一个5岁的小孩，我告诉他1+1等于2，它知道了，我告诉它3+4等于7，它也知道了，但是当他知道3+4等于7的时候，它已经忘掉了1+1等于2。

对我来说，我不是获得了智能，我是获得了智能在某一个时间的快照。

这个快照永远是在那个时间点，无论我如何优化处理，它的智商永远无法跃级。

回到最痛苦的这个问题上来说，我希望大模型是在一个连续的思路下我和进行Pair，而不是在背诵文章一样在一个连续的文本复制列表的场景下和我进行Pair。

这就导致每次我和它沟通的时候表达出：基于上一个修改的思路进行调整的时候，它都无法准确的定义出上一个修改的思路到底是什么，哪怕曾经我告诉过它这个思路是什么。我需要继续附带无数的样例和源码去解释这个思路是什么，不厌其烦的讲述。

而这，好歹还能通过连篇的废话去反复告诉他，能解决，紧接着一个更麻烦的问题是，目前并没有特别好的读代码的功能，大模型具备语言层面的能力，但是并不具备非常友好的代码阅读能力。

而这个阅读能力的构建，除了考验大模型自身之外，也考验工具本身的查找能力，比如我尝试让AI帮我解决一个问题：

将整个工程中使用到await axios.post和await fetch发起网络请求的地方都添加一个header xxx=xx。

在这个任务下，修改非常简单，难的是需要找到使用的地方，我将循环次数设置到1000次以上去，在20多万行代码中，AI狂奔了大半小时，成功找到且改掉的地方也寥寥无几。

在反复多次调整话术，甚至指导它定向去找之后，效果依旧没有达到预期。最后只能自己上手去修改，而在这多次来回，几个小时的AI自由发挥之后，几千块的Token没了。

中间本质的问题在于，如果要完成这样一个相对简单的问题来说，AI首先需要做到：找到位置->修改代码，而找到位置AI自身无法直接实现，需要借助工具，而不同工具呈现出来的查找能力是不一样的，特别是在海量的工程内进行搜索，虽然这只是IDE的一个control+shift+F的功能而已。

其次受限于窗口大小的限制，就算找到了也不见的能直接发送所有片段，只能逐个修改，对于无法的代码片段，会直接导致上下文不足从而引起质量不符合预期的问题，且在这样的问题下，由Agent发挥一堆之后，不但质量不行，成本还非常高。在这个过程中我无数次遇到出现上下文超长，直接导致Agent宕掉，既没有获得结果，费用也消耗了情况。

我认为一个Agent未来在商业逻辑上应该发生调整，那就是Agent的收费不应该和LLM绑定，应该完全解耦合。

因为目前所有Agent在收费上有一个很反常的逻辑就是无论Agent是否成功解决问题，甚至可能中途直接挂掉了，但是依旧需要付费，因为消费了Token，而Token是LLM收的，LLM只要使用就会产生Token，那么购买Agent到底是购买的什么？这是所有做Agent的场景下需要仔细思考的商业逻辑。

AI对于存量知识的理解，是难以跨越的门槛，这个门槛随着项目复杂度的上升，会出现指数级的增长，当我和AI进行深度Pair的时候，最严重的时候是下发一个修改命令后，吃顿饭回来，AI还在那读代码呢。。费用到是水涨船高。

当然因为我用的是成品面向C端的AI工具，对于企业来说，或者有企业服务经验的人会直观认识到说，这种情况下，典型应该构建企业内部代码知识库，提升代码效果，将企业知识，包括代码，文档，构建于一个知识库内，提升AI对存量知识的理解能力，加速查找过程，可以深度解决上下文的问题。

关于这个，下次有空再说了，我只能说，算了，算了，我在Hadoop这300万以上的代码工程中，尝试搞了这套，差点没累死。。

似乎真正的强人工智能到来了。

一切AI辅助都是伪生意

我认为，在B端市场下，一切以团队/组织 作为单位的AI辅助，都是伪生意，当一家企业引入一个所谓的AI辅助后，在管理者的视角下，如何度量这个东西产生了价值 ？非常简单，以前10个人的活现在5个人能不能做？如果能，那么被裁掉的那5个人是谁？对于甲方自己来说，如果要推行AI辅助，而又不进行减员，那么这个AI辅助引入就是纯成本，如果要减员，就需要确认AI辅助的引入是真的产生了价值，这本身就是利益矛盾。

老板问：AI有用吗？
员工异口同声回答：有用！
老板说：好，明天团队人员减半！

那么能不能先裁员呢？当然不能，因为这个板很大，并不是谁都敢拍。

所以AI辅助对于企业来说，永远只会是个额外新增成本，不会带来任何收益，这个AI能力没有关系，单纯利益而已。

甚至，AI辅助在B端市场是个双输的局面。

AI应用的平台生意

在我第一次使用GPT的时候，除了尬聊的场景外，如果考虑到工程落地，GPT给我的第一个感受并不是一个应用，而更像是数据库。距离应用之间还缺点什么东西，其次当企业在落地的时候，还面临内部信息需要让大模型感知到，才能准确的回答，这些都是问题。

而紧接着在后续的科技大爆发中，基于工程解决方案的RAG和基于模型本身的微调，都尝试提供一个适配接口，让大模型可以工作在一些特定的场景下，具备更好的灵活性。

然而这还不够，即便有RAG和微调，大模型距离变成应用，依旧有着遥远的距离，如同数据库一般，要做成应用，上层还需要一系列的工程框架，而首先需要的是一个应用平台。随着大模型的发展趋势，越来越多的企业采纳AI只是时间问题，虽然中间会面临非常多的问题，但是并不影响整个趋势的发展。

因此企业需要一个平台来构建和开发AI应用，似乎是一个必然的选项，但是AI应用又和业务应用不太一样，AI应用极度依赖数据本身，而在企业中数据通常又归属于数据平台中，且数据集不一定是为AI而准备。

然而一个AI应用开发平台必然需要打通企业的数据平台，且具备直接消费和加工数据的能力，基于这样的一个基础上，需要提供一套支持AI应用开发的体系，于是我尝试在数据平台的作为基础之上，引入模型管理的概念，且通过应用模板的概念来串通数据，模型和使用场景，而业务模板作为牵引，可直接对齐到业务，会更容易绕过企业IT带来的限制，基于这个思路，初步实现了整套原型验证。

得到一位大V的支持，进行了部分市场的验证，与此同时在北京和另一位老友进行了沟通，他也认可同样的方向，且进行着同样的事情，所不同的是在实施上，我沿着上层的应用往下走，而他更倾向于从下往上做，在寒冷的大冬天在北京的花园里探讨过数次关于整个平台的价值。

然而就算平台的价值非常被认可，在我看来，平台依旧不是一门好生意，因为目前来说平台无论怎么发展，平台的受众始终是企业IT，而企业IT是成本中心，而非利润中心，且非常重要的一点是IT并不控制预算，也不控制需求。和IT部门的合作更像是0.8*0.8=0.64，两两合作，两败俱伤。

也就是平台的价值始终需要间接的以工具的方式加入到企业中，平台本身并不直接创造业务价值，基于平台上做出的东西才是具有业务价值的东西。

要做的不是AI平台，而是用AI去做平台

AI平台本质上还是一门效能工具的生意，只是创造对象从应用系统变成了AI应用而已，并没有打破本身的业务模式，所以必然会面临平台同样的困境。

在AI平台的经验上，我认为似乎我们把AI想的太简单了，AI本身应该作为生产力对待，而非固化的工具箱。即便现在的AI达不到对应的要求，那么未来也必然只是个时间问题，要知道全球从能源到芯片全方位开展军备竞赛搞AI，不可能只是单纯的做一个聊天更好的模型。

AI成为生产力工具只是时间问题，大势所趋。

所以重新思考会平台本身，我认为平台价值并没有问题，但是平台的工作方式和受众应该发生变化，传统平台为什么需要面向IT，而不能直接面向终端使用者？

因为终端使用者不具备需求的实现能力，而IT团队为了实现需求需要一个趁手的工作台，而平台就是这个工作台，工作台加速了IT团队实现需求的效率。平台生意是给IT部门售卖了一个锤子，IT部门用这个锤子去敲出一朵花，这朵花如果不好看，不能满足需求，平台自然也会受到负面评价。

所以未来平台型的生意应该以终端需求方能接受的工作方式直接交付产物，这个产物是平台动态产生的，而能动态产生的核心引擎就是AI作为生产力。

这样会对企业的IT带来影响吗？并不会，因为这样的平台同样需要人来运维和服务，也就是平台从曾经定位成工具，由人去操作，变成了自动生产的引擎，由人来维护，带来的直接价值就是降低了交付周期，加快了业务流转，提升了企业的利润。

让参与方都能获利。

所谓的行业到底是什么

自古以来，对我来说行业知识，领域知识，一直是蒙着一层面纱，似乎总是隔着一层什么，很多时候总以缺乏行业知识聊以自慰，那么到底什么是 行业知识？什么是行业经验？

在这些年的逐步摸索和学习过程中，我认为所谓的行业知识，本质上是需要理解此行业下的商业运作模式和企业经营理念，而这套东西得融入到日常的工作中，才能有深刻的体会，其他途径是无法获取的。

对于很多不接触市场的产研团队来说，似乎销售就是靠吃吃喝喝，发发红包，就能拿下单子，照着吃吃喝喝去聊单子，基本上路子就跑偏了。

而一个AI平台要 发挥真正的价值，必然也得融入到一个聚焦的行业中，而要融入到一个行业中，自然也得贴合此行业的商业模式和企业经营理念。

任何一个通用到任何行业都能用的平台，平台本身几乎没有任何价值。

想了什么，做什么

在AI这个时代，围绕AI而出来的产品生意无数，但是生意模式上并没有发生本质的变化，依旧是用曾经的商业模式，在AI中重新做了一遍。

然而我认为，在一个平台上给不同行业做应用，提供一个通用的平台，显然不如给一个行业做平台，实现一个行业平台。

然而本质的区别还在于，这个平台是自工作的。

当我仔细看完后，发现他带来了MCP最大的误区。

原文：

误区 1：MCP 协议需要大模型支持

结论：MCP 协议不需要大模型支持，哪怕你使用古老的 gpt-2 作为问答模型，依然可以使用 MCP 协议补充上下文信息。

一叶扁舟，公众号：代码麻辣烫
关于 MCP 的几个理解误区

我的看法：

MCP的M是Model的意思，类比一下，智能汽车的车机系统只能在汽车上用吗？当然不是，比如车机可能采用Android的系统去构建，而手机也能使用Android去构建自己的系统，但是会有人把手机的系统叫做“车机”吗？

所以“汽车车载的车机可以不在汽车上使用”这句话错吗？其实也没有错，kernel可以到处移植，虽然都是同一个kernel，但是使用场景，实现的系统的目的，甚至提供的功能完全不一样，几乎没有任何类比，所以这个回答虽然没有错，但是有意义吗？毫无意义。。

原文：

误区 2：只有支持 Function Calling 的模型才支持 MCP 协议
聊 MCP 协议，必须要理解 Function Calling 机制。
结论：不支持 Function Calling 的模型，依然可以使用 MCP 协议补充上下文信息。
一叶扁舟，公众号：代码麻辣烫
关于 MCP 的几个理解误区

我的看法：

在MCP的官方定义中https://modelcontextprotocol.io/introduction的开头就直接清晰且直接的说了：

MCP is an open protocol that standardizes how applications provide context to LLMs.

什么意思？意思是MCP重点规范的就是模型上下文的使用方式，而这个使用方式就是Tools Call，然后这里直接抛弃这个前提，这和自媒体常用的“抛开事实不谈”几乎异曲同工之妙，都不提Tools Call，那还提啥MCP。且如果通过手写Prompt来解决问题，这就是MCP的话，那在外面挂个程序，提前通过传统方式处理一下音视频文件转成文本丢给gpt的chat模型，那么意味着gpt的chat模型也应该叫多模态模型。

原文：

误区 3：大模型原生支持 MCP 协议
结论：大模型原生支持 MCP 协议，这种说法是不专业的。大模型现阶段不可能原生支持 MCP。
一叶扁舟，公众号：代码麻辣烫
关于 MCP 的几个理解误区

我的看法：

大模型当然原生支持MCP协议，且非常专业，注意重点“协议”，这就像说Nginx支持HTTP协议，这个说法很专业，没有问题，且一般不会有人听到“Nginx支持HTTP协议”这句话的时候，会理解成Nginx要提供一堆带HTTP服务的应用程序。。

通常来说大模型在对MCP协议的支持上，重点的地方有2个：

一个是传输协议的支持，这个目前的模型来说，基本上都是复用了Tool Call的用法，然后通过外部的framework，例如langgraph这种框架提供面向应用程序的接口。

另一个是内容协议的支持，目前内容协议这部分，不同模型的实现几乎完全不一样，这一部分内容是需要继演进的。

所以这样一篇讲MCP误区的文章，带来了最大的误区。。

而另一方面，每一个概念必然有其边界和作用域，如果一个东西被泛化成什么都可以用它解释，那么这个东西大概率什么价值都没有。

一天，一位患有白血病的不速之客意外到访，打破了他的平凡人生，他从一个交不起房租、倒卖卖印度神油的商贩，一跃成为印度仿制药“格列宁”的独家代理商。收获巨额利润的他，生活剧烈变化，被病患们冠以“药神”的称号。

这个故事和AI有什么关系？格列宁，是经过了高额的研发成本，然后投放到市场，因此站在道德上格列宁卖高价，有一点不顾死活的感觉，但是站在商业上来看，如果格列宁卖低价，那么收入必然无法支撑高额的研发费用。

最终的结果就是再也不会有企业愿意投入研究，去研发新药。

AI也如同格列宁一样，投入了高额的研发成本，经历了漫长的研发周期，而相比格列宁还不如的地方是，格列宁一旦研发突破后，运维成本会大大降低，而AI在取得突破后，持续提供服务依旧需要非常高额的成本，就算是仿制，也无法做到格列宁仿制品那样的低廉。

所以如果站在成本的角度上来看，AI能带来的成本降低几乎微乎其微，甚至不但不会降低，还会造成更高的成本投入，有无数宣传AI的会使用马斯克裁员来证明AI带来的成本的降低。

但是仔细看马斯克的裁员过程会发现，其实和AI一毛钱关系都没有，马斯克是使用996,007的工作方式，营造危机感，让1个人干2个人活，但是工资并不会增加，其次X本身就非常冗余，没有新的赛道突破在成熟期本身就不需要这么多人。

也就是无论有没有AI，马斯克裁掉90%的员工，系统依旧可以运转，至于会不会崩，就听天由命了。还有不少人会拿着智能客服举例子，请仔细阅读这篇：《给我转人工，转人工」，AI客服把人逼疯》 https://mp.weixin.qq.com/s/_l93N0iWmktp2NDVscmgIg?poc_token=HM7T82ejDz2Rew-tWU6_BB6jvHYUsU4MoJTBRA5W

那么AI的价值在哪里？AI的价值在与增效，降本只是附属品，而增效的价值体现在曾经无法做到的事，可以使用AI做到了，仅此而以。

那么围绕曾经无法做到，而现在可以做到这一点来构建出来的业务，自然可以获得增效，而降本是怎么体现的呢？是这样体现的：

曾经想做的事，在没有AI的时候如果要去做，会投入大量的成本，甚至都无法取得令人满意的效果，这时候的成本就非常高。

现在有了AI，可以做到曾经无法做到的事，并且成本比曾经预期的低很多，这难道不是降本吗？

只有正确认识AI的价值，以及AI擅长的地方，才能更好的使用它，否则不过是盲目操盘，引入一场灾难而已。

所以企业在考虑AI的时候，如果是指望使用AI大幅度降低现有业务的成本，可能效果不会那么的符合预期。站在商业的角度，业务要发展，企业要做的更好，可以开源节流，而AI的价值是在与开源，而并非是节流。

这是因为这样的行业下的很多流程，大体可以被标准化，原因也在于输入和输出是标准化的，再配合多年以来的行为习惯和模式，以这样的方式来完成业务，基本上已经成了共识，这样的工作方式也确实可以提高效率，完全满足需求。

但是，当把这样的工作流的方式迁移到软件研发领域后，问题就会暴露的非常明显，在曾经的低代码时代，就有不少解决方案，尝试通过拖拉拽和流程编排处理的方式，构造一个可用的软件，到了AI时代，这样的工作方式更加盛行，仿佛已经是标配。

基于任何一个做生成似AI的平台，都有一个通过拖拉拽配置工作流，快速构建AI应用的引擎，然而这个东西真有那么好吗？

首先，从价值上来说，肯定有价值，只是价值多少的问题，对于工作流这样的引擎来说，投入产出比并不见的有多大。

站在目标群体的视角来看：

工作流引擎的目标群体始终是飘忽不定的，真正的终端用户，消费者，用的是应用的SAAS成品，根本不会去搞拖拉拽，给自己造一个应用。

真正具备研发实力的研发人员，面对各种各样的需求，从可控性和可交付性的角度来说，更愿意自己首先逻辑去开发一个AI 应用，以确保最终能够被交付。

如此看起来，似乎只有不会写代码，但是又要去做AI应用的群体，才会是这个东西的受众，那么这个群体，是否会承担企业开发生产级AI应用的职责？

当然不会。

所以会发现这样的软件，受众一直不明确，可能只有那种想快速demo一把的群体，或者尝鲜的群体，想自己体验一把动手能力的群体，会尝试使用一下这样的东西。

站在开发工作量的角度来看：

• 开发一款功能完备的工作流引擎，工作量非常大，除了穷举出所有所需要的节点之外，还需要考虑到不同节点之间的组合方式，从而让整个流程可以运行起来，无论是从前端体验较好的界面，还是整体工作流的执行，都会有非常大的工作量。
• 用超大的研发工作量，服务于一个不那么确定的群体，用不那么清晰的流程去解决一个不知道可能是什么的问题。

这样的方案，相对来说，真的糟糕透了。。

所以我向来非常反对这种拖拉拽进行编排的解决方案，因为它真的不会有想象中那么好，但是在AI领域下，类似comfyui就好评非常好，原因在于，comfyui所面对，或者目标群体本身就是影音范围，对于这个群体来说，工作流本身就是曾经的工作方式，只是平迁了而已。

但是抛开这个领域外，在研发领域，工作流真正的问题会在于，它既改变了曾经研发群体的工作方式，又没有办法完全保证所有场景都支持，这就导致整个方案会面临非常大的缺陷和不确定的未知风险，一旦出现这种风险，几乎没有解决方案。

• 条件苛刻，企业找外包，是因为想降低成本，用比自己还便宜的人去做自己做不出来的东西，接锅的外包团队基本就是火坑。
• 汇款周期慢，三年五年甚至十年才回款，是国内企业的主流。
• 非专业的过度干涉，按照对方自己的认知，会干扰到实施过程中的任何一个环节，对实施方的自主性带来很多约束。
• 极度不信任，外包属于廉价劳动力，长工，甚至短工，所以需要不断的监视，监控。

等等非常多的约束，导致B端的生意成为了一个非常难做的市场，甚至连李开复都喊出了“坚决做ToC，不做赔钱的ToB”的感悟，那么对于普通的B端供应商来说，日子自然不会更好过。

但是，反过来思考一下，什么是外包？

什么又不是外包？

有没有真正的甲方？

A企业给B企业做项目，这时候A企业对于B企业来说，就是外包，而B企业对A企业来说就是甲方。

但是B企业同样也有他的客户C，对C来说，B企业就是C的外包，而C企业就是B的甲方。

所以外包狗都不做，要去做甲方，到底什么才是甲方？

在国内的B端圈子，基本上形成了一个恶心循环，曾经我见到某企业对他的外包团队说：

“你就是我花钱买来的一条狗”，并且这种认知在国内算是所有甲方的主流认知，不过这家企业公开的说出来了而以。

那时以为这就是这家企业自身的问题，后面发现，因为他的甲方就是这样对他的，所以他自然也会这样对待他的外包，在这样的一条链路下，形成了一连串的鄙视链。

无论在哪一个环节，都免不了会成为某家企业的外包，同时也可能是某一家企业的甲方，具有双重身份。

所以外包？

不存在，大家都是外包，甲方？

也不存在，所有企业都是甲方。

那么对于选择来说，真的是不进外包，进甲方吗？

非也。

在这个链路下，过得正常的节点，不是甲方也不是外包，而是话语权最大的那个，所以优先选择，应该选择话语权最大的那个节点，无论他是外包身份居多，还是甲方身份居多。

只要话语权足够大，外包又何妨？

是不是甲方又有何所谓？

至始至终可以按照自己的既定节奏走，而不受对方影响，这个才是最重要的。

在LLM起来后，又一个新的概念被提起来，那便是：AI原生应用。

然而很遗憾，到今天，不存在任何AI原生的应用，如果有谁提到自己能做AI原生应用，那一定是在忽悠，只是从能力储备的角度，储备AI原生应用可能需要的能力平台，是有可能做到的。

即便如今火热的Rag，Agent等实现，依旧和AI原生扯不上一丁点关系，只能说应用中使用到AI的能力。

要清晰认识到这一点，那么就必须知道什么叫：原生。

在AI原生之前，还有一个已经非常成熟的概念，叫：云原生应用。

而云原生中的核心是：云，而不是应用，那么同样，AI原生应用的重点也一定是AI而非应用，所以但凡从应用视角去讲述采纳了何种对话技术，搜索技术，做了何种模型优化手段，都是不合适的。

在云原生应用中，因为云提供了便利的基础设施，云所具有的弹性能力，以及内部预设的各种基础设施服务，可以让应用开发者完全只关心真正的业务逻辑，而无需关注组件依赖以及整体的运维。

典型的实施方式就是基于k8s的技术下，应用开发者只需要写自己业务的代码打包成docker images后，发布就可以使用，至于依赖的数据库，缓存等组建，已经被提前打包好，直接使用即可。

这便意味着云原生通过部署+预设穷举的方式，把应用开发者的环境隔离出去。提供了底层的基础设施，所以云原生的核心能力在于从运维入手，剥离开发者的运维工作。

那么在AI的概念下，如果需要实现AI原生，那么意味着AI一定是基础设施，什么样的AI才能成为基础设施？云原生已经解决了运维的问题，那么AI必须得解决生成的问题。

这就是意味着AI原生必须达到替换掉写代码的群体，才能称之为AI原生，在云原生下，每一个应用不再需要有专业的运维人员，统一收口到云上就行了，所有的运维都去云平台，让开发者开开用云平台。

同样对于AI原生来说，不在需要开发者，所有写代码的人都去AI原生的平台，做平台，让业务开发者来用AI原生平台。

但是到今天，AI能力依旧达不到完备的基础设施的程度，要完全取代程序员，直接生成软件，更是有一段距离。

所以在AI尚且不能成为基础设施之前，就谈不上AI原生应用，所以凡是宣称已经做了AI原生应用的，大概率都是在忽悠。。

甚至搞不清楚自己在做AI Agent，还是AI APP，如果认为自己是在做AI Agent，那么AI APP似乎就只是个前端页面？

如果业务视角交付的是AI APP，那么又何必大炒AI Agent这个概念，谁家在讲OA系统的故事时候会到处给人说自己在MySQL创建了一张表？

扯来扯去似乎就变成了，AI APP就等于AI Agent，造AI 应用，就是在造AI Agent，事实上的工作内容真的是这样吗？

对于实施方来说，重要的是脚踏实地的稳步前进，如果要炒概念讲业务故事，就老老实实的说应用，如果是搞技术的，就老老实实的去做Agent，非要把两者混为一谈。

似乎交付业务价值就是在交付AI Agent，但是又没法圆AI APP这个概念，于是就干脆把两者等价算了，这，是忽悠的表现。

在不少大忽悠的大V的热点文章中，把AI Agent称为大模型落地的最后一公里，且非常深奥的抽象出了Agent的落地架构：

包含规划（Planning）、记忆（Memory）、工具（Tools）、执行（Action）四大要素。

然后还费劲的做了非常高深的解释：

• 第一，感知环境。首先，AI Agent需要收集环境信息，可以使用传感器或从各种来源收集数据。
• 第二，处理输入数据。AI Agent处理前序环节收集到的知识，这可能包括组织数据、创建知识库，或创建AI Agent可以理解和使用的内部表征。
• 第三，决策制定。AI Agent使用逻辑或统计分析等推理技术，基于知识库和目标做出明智的决策，可能涉及应用预先设定的规则或机器学习算法。
• 第四，规划和执行行动。AI Agent制定实现目标的计划或一系列步骤，可能包括创建分步策略、优化资源分配或考虑各种限制和优先事项。根据计划，AI Agent执行所有步骤以实现预期目标。AI Agent还可以从环境中接收反馈或新信息，用于调整未来的行动或更新知识库。
• 第五，学习和改进。在采取行动后，AI Agent可以从经验中进行学习，通过反馈循环提高AI Agent的性能，并适应新的情况和环境。

这架构有问题吗？没问题，但是这哪是最后一公里，这简直就是二万五千里长征刚起步，遵义会议都还没开。。

甚至曾经的各种XX中台在这个要素下都得叫声哥。。。

在理解什么是AI Agent，以及什么是AI APP的时候，首先需要罗列清楚一个基于大模型去实现的应用，到底是一个什么样的工作流，而那些讲不清AI Agent的人，大概率就是做了个hello world就开始上路。。

如果是做一个demo，基于大模型的应用基本上会有如下流程：

• 用户上传个PDF
• 后端接收PDF并且做文本提取等操作
• 基于预设prompt与大模型对话
• 适当引入些COT类似的机制，多次思考再反复与大模型对话，确保答案符合预期，这个过程可能会用到一些工具。
• 后端组装结果，返回结果给页面

在这个过程中，大部分忽悠师傅把 2, 3, 4 全部囊括在Agent的范畴内，且做出了一些所谓的平台只需要在页面点点点就能完成：上传文件，与大模型对话 这件事。

然后就衍生出了前面的一系列Agent的高深定义，看起来似乎很合理？

那么如果是做一个生产应用呢？它会有如下流程：

1. 用户往数据平台上传1万个PDF，每个PDF 1个GB。
2. 采用 Spark或者Ray框架，对每个PDF进行加工处理，必要的时候会做向量化。
3. 在元数据管理系统构建整套非结构化数据的信息。
4. 做一个前端页面支持用户对话，对话的时候可以选择文件（而非直接上传）。
5. 后端接收用户输入的请求。
6. 基于预设prompt与大模型对话。
7. 适当引入些COT类似的机制，多次思考再反复与大模型对话，确保答案符合预期，这个过程可能会用到一些工具。
8. 后端组装结果，返回结果给页面。

那么在这个环节中，Agent应该包含哪几步呢？包含1和2吗？如果不包含，那么典型和那一套深奥的范围对不上，如果包含，那岂不是整个数据平台都可以叫Agent了？

反而这样一拆解之后，其实结论已经非常清晰了，Agent仅仅只是构建大模型应用中的一个非常细微的步骤，甚至都不是必须的步骤，比如：

微调了一个垂直模型，直接问答就能得到完全符合预期的答案。

那么基于这个模型只需要做一个非常简单的前后端，什么所谓的AI Agent框架都可以不要，这算不算AI APP？和Agent有关系吗？

所以从概念上来说，开发一个 XXX助手的描述 明显 是合理的，而 开发一个XXX Agent 明显是个骗子。

这就像 开发一个小程序的官网 听起来 就很合理，但是 开发一个小程序官网的数据库表结构 听起来是不是很不对劲？

因为小程序官网才是真正的业务，而创建数据库的表，只是完成这个官网开发中间的一个步骤，甚至都不是必须的，万一是个静态页面呢？

AI Agent不是筐，不能什么都往里装，老老实实去搞 AI 应用，不要造一些稀奇古怪的概念，反而让人很难理解。

甚至部分甲方会主动说，把这个实现可以带到其他客户那里，因为这是个行业痛点，作为和乙方进行价格谈判的一个筹码，而一旦乙方信了这个方向，便会陷入未来的辉煌想象中，从而觉得当前的一切都是值得投资的，于是开启了地狱般的交付模式。

实际上，这是一个非常不现实且想当然的做法，首先做项目和产品本身是冲突的，且不说项目解决的是眼前的苟且，产品是为了诗和远方，单纯从运作上来说，如果这样做能成功，那么世界上最伟大的产品一定出自外包公司，然而事实上并不是。

国内的乙方的定位只是廉价劳动力

鉴于国内特殊的环境下，所有的乙方都是廉价劳动力，以相对的角度来说，国外的企业在寻求乙方的时候，更多是能力上的补充，这也凸显出差异化的地方，就是国外的大厂无论是AWS还是Google，都会有比较聚焦的地方，也正以为如此，世界上才会有DataBricks这类优秀的企业的生存空间，而微软又和DataBricks形成了非常紧密的生态，其次AWS的Markplace中也有不少优秀的内容。

所以国外企业寻求乙方的时候更多时候是站在能力补充，这时候对乙方会相对友好，且更容易做成功事，乙方可以有更多的灵活性去做出更好的设计，其次更容易形成长期的合作，从而实现共赢的局面，甲方更多是Manager的角色。

而国内不一样，国内找乙方原因很简单：需要廉价劳动力，且甲方一定有一个所谓的“技术负责人”，写了张PPT自以为出了个解决方案，但是重点是他已经在内心敲定这个东西需要几天实现，工作量拍死了，基本上已完全框死了乙方的设计范围，乙方的定位就是：“甲方已经想清楚了这个事的复杂度，怎么做，都在脑子里面过了一遍，技术负责人也选好了，就差几个廉价劳动力。”，因此无论乙方如何定位自己，在甲方的眼里都是廉价劳动力，也正因为如此，国内的乙方是不可能结束到有意义的业务的，基本上都是些甲方不想做的，边角料和体力活，在这样的业务背景下，乙方就不可能获得所谓的行业知识。

因为如果这样业务很重要，技术要求很高，甲方为什么不自己招个团队？既要又要还要是国内所有企业的共识，这也是国内永远不会有DataBricks这类企业出现的原因之一。

项目是做加法

再从项目本身上来说，项目之所以会存在，本质上就是因为没有一个标品能直接开箱就满足要求，所以需要设立一个项目，完全贴合这个业务场景本身，这就意味着从项目去抽象通用功能本身就是一个不现实的做法，如果这个业务场景可以抽象出一个通用的产品，为什么不直接找个类似产品公司来二开？

所以始终要明白，项目的投入是成本，项目被认可的一个重要的因素是可以随着业务变动而快速响应，需要完全贴合业务，否则这个项目基本上就中道崩卒。

产品关注的是杠杆

从产品的角度来说，产品关注的是如何同一个相对通用的解决方案去撬动多方业务，从而实现一个比较好的杠杆，这就意味着产品一定是重设计，再实现，而项目优先是实现，其次才是设计，站在项目受众的角度来说，这个东西其他公司能不能用不重要，自己能用的舒服才重要，所以产品是无法先投入实现，再来抽象的，因为已经投入实现后，问题已经被具像化，没法再抽象了。

项目交付和产品规划是互斥的

如果一个项目组既承担了产品研发，又在负责一个具体的项目的交付，那么基本上团队很容易就人格分裂了，如果一个 需求这个业务场景下就是需要，但是产品完全完全不需要，怎么办？代码怎么管理？两套分之如何处理？从项目管理来说，管理一个项目的交付和管理一个产品的迭代是完全不一样的，因为两者衡量价值点是不一样的。

• 对于项目来说，衡量的点在于这个东西甲方是否喜欢？只要满足这一点，后面的预算就有着落，项目就能交付，其他不重要。
• 对于产品来说，衡量的点在于这个东西是否通用？能否卖给其他公司？如果不能，即便这个客户给再多的钱，也不一定会投入去做，因为这涉及到资源协调的问题，伺候好这一个客户，虽然一次性的赚到了100万，但是可能没有精力去支持那10个10万的通用客户，孰轻孰重很清晰就能看到。

更何况乙方做到了完全满足甲方业务要求，还能做出抽象这件事，大概率这个项目投入的成本会比预估超出一倍，因为抽象产品这个事的成本一定只能乙方自己承担，如果甲方以此作为条件，统一乙方去做，从而砍低了价格，那么亏的可能更多。

合规是很难定义的

站在甲方来说，甲方投钱找了乙方给自己的业务做了一个定制化的业务的项目，乙方抽象成了一个产品再卖给其他客户，如何定义这个版权的问题？如果一开始甲方就完全同意了这个事，那么意味着乙方大概率亏的很惨，如果不同意，那么基本上法律上就走不通。

项目和产品的运做模式不一样

项目在企业运作上，本质上是人力资源的管理，站在更高层次来看，一家服务型的外包公司的来源本质上是“人”，也就是只要“人”卖出去，在项目上，那么就有利润，至于这个人实际上做的是什么，其实不重要，因为赢利点不是事，而是人，只需要操控好人员资源协调即可，这也是很多外包公司在项目结束后就直接裁员或者只发底薪的原因之一。所以项目的经营本质上是围绕人建立一个良好的流动机制，让人可以刚好被使用满。

而产品的赢利点在物上，而非人，无论是谁，本质上对外透出都是物，这意味着需要围绕物建立一个循环机制，来辅助这个事可以持续运做，那么各种研发机制，解决方案机制就会持续被建立，且这个建立和人没有关系，哪怕人全走了，这个东西依旧可以持续卖。

在运做模式上，这两者有着本质的区别，做项目的企业也会关注新技术，本质上是为了人更好卖，而做产品的企业同样关注新技术，本质上是让物解决大范围的问题，让物变的更好卖。

所以无论从哪个角度来看，想从项目沉淀产品，都是一件非常不可行的事，那么是不是说产品就没有办法做出来呢？其实并不是。

做产品一定是先投资再实施见收益，而项目一定是先实施直接见收益，所以产品的生存风险一定高，项目的风险相对低，但是低风险和高收益的事不可能同时存在，企业之所以想从项目沉淀产品，就是因为已经有项目了，有了资金来源了，再去做产品，感觉风险就低了，再以此来博得高收益，实际上却忽视了交付风险和管理风险。

受众不同

产品和项目的受众其实是不一样的，站在乙方的角度，如果做项目，可以做到来者不拒，因为没有什么人是招聘不来的，如果不行，那就加工资，而产品不一样，做不了的就是做不了，无论如何改变也做不了，所以产品需要有取舍，恰巧难点就在于取舍，如何控制好权衡好这个取舍点在哪，就已经成功了一半，这决定了这个物应该怎么卖，卖给谁。

要有敬畏心

做产品的仪式感会远远大于项目，对于项目来说，做砸了再来一个就行了，至少有个首付款，而对产品来说，砸了，就啥也没了，所以产品不是一堆代码的堆砌，而是一套销售和运营模式的改变，想从人力资源运做为主的项目中提取出一个产品实现低风险高回报的事，是非常想当然的。

self.client = OpenAI(base_url=self.endpoint, api_key=api_key)
  File "/app/.venv/lib/python3.10/site-packages/openai/_client.py", line 123, in __init__
    super().__init__(
  File "/app/.venv/lib/python3.10/site-packages/openai/_base_client.py", line 857, in __init__
    self._client = http_client or SyncHttpxClientWrapper(
  File "/app/.venv/lib/python3.10/site-packages/openai/_base_client.py", line 755, in __init__
    super().__init__(**kwargs)
TypeError: Client.__init__() got an unexpected keyword argument 'proxies'

从描述的问题来看，是sdk接口不兼容，然后跟了一把后发现是因为openai的sdk使用了httpx，openai传递了proxies参数来构造httpx的client，但是httpx里面却没有定义这个参数。

又仔细去看了下版本发布，原因是因为在httpx的0.28的版本开始，httpx移除了proxies参数来构造httpx的client，但是由于openai的版本管理是采用兼容高版本自动升级的方式，所以同样的openai的版本安装出来的httpx版本会不一样。

这就导致出现了不兼容的问题，既然知道了原因，解决方式就简单多了，降级httpx到0.28以下的版本就行了。

mlflow
boto3

设置环境变量：

AWS_ACCESS_KEY_ID=admin
AWS_SECRET_ACCESS_KEY=admin
MLFLOW_S3_ENDPOINT_URL=http://192.168.5.108:9000
MLFLOW_TRACKING_URI=http://192.168.5.108:15000/

例子：

import mlflow.sklearn
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression

# 加载数据集
iris = load_iris()
X, y = iris.data, iris.target

# 划分训练集和测试集
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# 训练模型
lr = LogisticRegression(max_iter=1000)
lr.fit(X_train, y_train)

# 设置 MLflow 运行
with mlflow.start_run():
    # 记录模型参数和性能指标（这里省略了具体指标的计算）
    mlflow.log_param("solver", lr.solver)
    mlflow.log_param("max_iter", lr.max_iter)

    # 保存模型到 MinIO
    mlflow.sklearn.log_model(sk_model=lr, artifact_path="iris_model", registered_model_name="iris-logistic-regression")

便可以在minio和mlflow里面看到对应的数据。

import mlflow.sklearn
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split

iris = load_iris()
X, y = iris.data, iris.target

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

loaded_model = mlflow.pyfunc.load_model("runs:/<run-id>/iris_model")

predictions = loaded_model.predict(X_test)
print(predictions)

在mlflow里面找到对应的run id，进行加载即可使用对应的模型。

经过分析，以及相关的搜索：

https://stackoverflow.com/questions/51050043/multiple-underscores-in-elasticsearch-field-name-with-python-elasticsearch-dsl

可以得知，es的py dsl在设计的时候，借鉴的是Django ORM 设计思路，而在Django ORM 的设计中，__ 也就是双下划线， 代表着嵌套查询，因为是嵌套查询了，那么a__b__c 自然也就会被翻译成 a.b.c 了。

https://github.com/elastic/elasticsearch-dsl-py/issues/28

在这个issue中，社区进行了大量讨论，不过都对要做转换这个结论是认可的。

具体到代码的位置：

https://github.com/elastic/elasticsearch-dsl-py/blob/605d7570e2a1501f319fdc74ad8d8270a5e61ea2/elasticsearch_dsl/utils.py#L222-L223

def __init__(self, _expand__to_dot=EXPAND__TO_DOT, **params):
        self._params = {}
        for pname, pvalue in iteritems(params):
            if '__' in pname and _expand__to_dot:
                pname = pname.replace('__', '.')
            self._setattr(pname, pvalue)

可以看到这里做了转换。

不过作为es的dsl库，约束不像es向下对齐，而是向上对齐，也是少见了。

通用场景：程序的运行不符合预期，我们知道再次调用大概率可以使之符合预期，这时就需要重试。

#!/bin/bash

# 最大重试次数
MAX_RETRY=5

# 当前重试次数
retry_count=0

# 循环执行命令，如果失败则重试
while true; do
    # 执行命令，可以将具体的命令替换为你需要执行的命令
    command_result=$(some_command)

    # 检查命令的返回值，如果成功则退出循环
    if [ $? -eq 0 ]; then
        echo "Command succeeded!"
        break
    fi

    # 命令执行失败，检查是否已达到最大重试次数
    if [ $retry_count -ge $MAX_RETRY ]; then
        echo "Command failed after $MAX_RETRY attempts."
        exit 1
    fi

    # 命令执行失败，增加重试次数，等待一段时间后再次执行命令
    echo "Command failed, retrying in 10 seconds..."
    retry_count=$((retry_count+1))
    sleep 10
done

在上面的脚本中，MAX_RETRY定义了最大重试次数，retry_count用于记录当前重试次数，while循环用于不断执行命令，if语句用于检查命令的返回值，如果成功则退出循环，否则增加重试次数，并等待一段时间后再次执行命令，直到命令成功或达到最大重试次数。如果命令在最大重试次数内执行失败，则脚本退出并返回错误码1。

几乎所有的企业，都开始考虑All in ai这一件事，这不单纯是炒作或者跟风，也不是在竞争某个新技术，比如出现过的区块链，元宇宙，VR/AR，都是非常优秀的技术，但是并没有企业喊出All in 区块链，唯一一家喊出all in 元宇宙，还改名的企业，现在已经全面拥抱大模型了。

这些企业之所以喊出All in AI的口号，虽然在动作上少有差异，但是如同张一鸣所说，一语点中了本质，因为 All in AI可以解决企业第二曲线增长困境，就是这么简单。

如果组织和企业能在第一曲线到达巅峰之前，找到带领企业二次腾飞的第二曲线，并且第二曲线必须在第一曲线达到顶点前开始增长，弥补第二曲线投入初期的资源消耗，那么企业永续增长愿景就能实现。

实现永续增长无非两种方式：

• 一是产品实际需求相对稳定，但公司具有持续的提价能力，比如奢侈品公司。
• 二是不断通过二次增长实现迭代增长，不断推出新产品和服务实现持续增长，比如苹果公司不断进行新产品迭代更新。

要形成持续的提价能力对许多行业和公司来说是比较困难的，大部分行业和企业要实现永续增长愿景一般都要依赖第二增长曲线。

我们再看看历史上为第二曲线做了选择的那些企业：

• 阿里是第二曲线做的最好的公司之一，最早是B2B，然后是淘宝，蚂蚁金服，阿里云到钉钉等，正是不断地找到这些第二增长曲线，阿里才能成长为今天市值万亿的巨无霸企业。
• 苹果的第一曲线是iMac，之后做的iPod、iPhone、iPad都是它的第二增长曲线。
• 亚马逊也是如此，第一曲线是网上书店，之后做电商，做云计算，做物流，始终保持增长，才成为全球市值最高的企业。

可见，企业要保持基业长青，永续经营，就要不断突破增长拐点，跨越非连续性，找到第二增长曲线。

再看上面的第二曲线，虽然不同企业的选择不同，比如阿里做淘宝，苹果做iPhone，看起来业务不太一样，但是背后实质性都是因为生产力的变化，移动互联网的出现，移动互联网才是第二增长的源动力。

同样在今天，几乎所有企业都认为GenAI是源动力，可以成为带领企业走出第二增长曲线的动力，于是围绕这个动力，不同企业扩展了自己的第二曲线业务，比如360做安全Agent，字节用抖音做防守，剪映博AI。

其中调用mlserver的推理服务的时候，涉及到传输参数的序列化，序列化的大概样例如下：

tools: list = None
df=pd.Series(
            [
                tools
            ],
            index=[     
                "tools"
            ],
        )
PandasCodec.encode_request(df, use_bytes=False)

其中PandasCodec是mlserver提供的序列化类，此代码在mlserver 1.4.0以前的版本下都没有问题，在1.4.0开始，包括1.4.0会出现如下问题：

TypeError: ufunc 'isnan' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

跟踪代码会发现：

https://github.com/SeldonIO/MLServer/blob/release/1.4.0/mlserver/codecs/numpy.py#L108

对于dataframe中的每列，会做是否非空的检查：

def _to_response_output(series: pd.Series, use_bytes: bool = True) -> ResponseOutput:
    datatype = to_datatype(series.dtype)
    data = series.tolist()

    # Replace NaN with null
    has_nan = series.isnull().any()
    if has_nan:
        data = list(map(convert_nan, data))

convert_nan的逻辑为：

def convert_nan(val):
    if np.isnan(val):
        return None

    return val

由于np的isnan是：

The `isnan` method doesn't work on Numpy arrays with non-numeric

这就意味着，对于前面的tools来说，是non-numeric类型，通过调试也可以看到，tools的类型为BYTES，这就导致np.isnan(val)直接抛出异常。

由于mlserver.1.4.0之前并无此校验，因此之前的代码不会有问题。

https://github.com/SeldonIO/MLServer/issues/1873 首先给他们挂了个issue描述了一下问题。

通过追踪mlserver的commit记录，可以看到：

https://github.com/SeldonIO/MLServer/commit/be8bab5938b478d68f3ac0da895a5e8af73c2586

在这个commit后，新增了这段逻辑，按照seldon自己的描述：

The NaN (Not a Number) value is used in Numpy and other scientific libraries to
describe an invalid or missing value (e.g. a division by zero).
In some scenarios, it may be desirable to let your models receive and / or
output NaN values (e.g. these can be useful sometimes with GBTs, like XGBoost
models).
This is why MLServer supports encoding NaN values on your request / response
payloads under some conditions.

In order to send / receive NaN values, you must ensure that:

- You are using the `REST` interface.
- The input / output entry containing NaN values uses either the `FP16`, `FP32`
  or `FP64` datatypes.
- You are either using the [Pandas codec](#pandas-dataframe) or the [Numpy
  codec](#numpy-array).

Assuming those conditions are satisfied, any `null` value within your tensor
payload will be converted to NaN.

For example, if you take the following Numpy array:

归纳下来就是因为如果对于非基本类型接收None，那么在某些模型下，比如XGBoost就会出现模型输出NAN，为了解决这个问题，就不再支持None。

搞清楚了原因，那么解决方案就明确了，按照官方的描述，既然他们是这样认定，基本上后续的版本中也不会做额外的处理。

于是我自己重写了一个codecs，重写了PandasCodec的方法：

from typing import List

import numpy as np
import pandas as pd
from mlserver.codecs import PandasCodec
from mlserver.codecs.numpy import to_datatype
from mlserver.codecs.pandas import _process_bytes
from mlserver.codecs.utils import inject_batch_dimension
from mlserver.types import InferenceRequest, Parameters, RequestInput, ResponseOutput, Datatype


def convert_nan(val):
    try:
        if np.isnan(val):
            return None
    except Exception:
        return val
    return val


def _to_response_output(series: pd.Series, use_bytes: bool = True) -> ResponseOutput:
    datatype = to_datatype(series.dtype)
    data = series.tolist()

    # Replace NaN with null
    has_nan = series.isnull().any()
    if has_nan:
        data = list(map(convert_nan, data))

    content_type = None
    if datatype == Datatype.BYTES:
        data, content_type = _process_bytes(data, use_bytes)

    shape = inject_batch_dimension(list(series.shape))
    parameters = None
    if content_type:
        parameters = Parameters(content_type=content_type)

    return ResponseOutput(
        name=series.name,
        shape=shape,
        data=data,
        datatype=datatype,
        parameters=parameters,
    )


class SeldonPandasCodec(PandasCodec):
    @classmethod
    def encode_outputs(
            cls, payload: pd.DataFrame, use_bytes: bool = True
    ) -> List[ResponseOutput]:
        return [
            _to_response_output(payload[col], use_bytes=use_bytes) for col in payload
        ]

    @classmethod
    def encode_request(
            cls, payload: pd.DataFrame, use_bytes: bool = True, **kwargs
    ) -> InferenceRequest:
        outputs = cls.encode_outputs(payload, use_bytes=use_bytes)

        return InferenceRequest(
            parameters=Parameters(content_type=cls.ContentType),
            inputs=[
                RequestInput(
                    name=output.name,
                    datatype=output.datatype,
                    shape=output.shape,
                    data=output.data,
                    parameters=output.parameters,
                )
                for output in outputs
            ],
        )

针对isnan的判断做了额外的处理，使用的时候由PandasCodec.encode_request换成SeldonPandasCodec.encode_request即可。

因此在docker container里面默认看不到别的地方启动的PID，而实际上实际上看不到才是正统的，因为docker container存在的价值就是进行多租户隔离，自己管自己，如果能看到别人，还能干掉别人的，实际上已经破坏多租户的概念了，这个隔离意义就不大，单纯就是个程序环境隔离了。

如果非要看到，也可以通过-pid=host 把物理机器的透过去，就能看到，不过这样来说，基本上就破坏了隔离性。

https://stackoverflow.com/questions/63654885/is-it-correct-that-nvidia-smi-on-docker-does-not-show-processes

https://github.com/NVIDIA/nvidia-docker/issues/179

最近大模型平台有个知识库模块，在对文件进行加工处理，进行embedding，逻辑上不复杂，基本就是对文本切片，再embedding，然后落库milvus。

不过出现一个现象就是当文本过大的时候，knowledge based的处理过程会卡住，且knowledge based停止服务，请求处于等待状态，由于knowledge based的整个服务是部署在docker中的，于是查看卡在哪儿，只能在docker中进行了。

首先通过：

docker exec  --privileged -it ID /bin/bash

进入容器，查找到PID：

root@815eb533c377:/app# ps -eaf
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 Jun12 ?        00:00:00 /bin/sh -c cd /app/src && poetry run alembic upgrade head && poetry run python main.py
root          57       1  0 Jun12 ?        00:05:24 /root/.cache/pypoetry/virtualenvs/knowledge-base-9TtSrW0h-py3.10/bin/python main.py

可以看到PID分别为1和57，这里需要调试的是PID 57。

通过：

gdb python 57

进行调试，碰到一个问题：

Attaching to process 57 
ptrace: Operation not permitted

看了下docker container里面的/proc/sys/kernel/yama/ptrace_scope 的值是1，1 意味着无法attach，对于docker来说，这个值是跟随宿主机走的，也就是需要修改宿主机的值，也就是执行：

echo 0 > /proc/sys/kernel/yama/ptrace_scope

对于默认是zsh的会碰到错误：

zsh: permission denied: /proc/sys/kernel/yama/ptrace_scope

这时候可以通过切换bash解决：

sudo bash -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"

再通过：

gdb python 57

进行调试，通过py-list查看当前执行的位置：

(gdb) py-list
 700            self._checkReadable()
 701            if self._timeout_occurred:
 702                raise OSError("cannot read from timed out object")
 703            while True:
 704                try:
>705                    return self._sock.recv_into(b)
 706                except timeout:
 707                    self._timeout_occurred = True
 708                    raise
 709                except error as e:
 710                    if e.errno in _blocking_errnos:

gdb -p pid
pid是指进程号，可以通过 ps -ef 查看，请替换为实际的进程号

步骤5: 打印信息
py-bt
解释: 查看当前进程的堆栈信息，这是很重要的命令，一般可以看到进程运行到哪里发生死锁或者卡住，进而可以回到python源码确定最终问题在哪里

py-list
解释: 显示python进程当前代码运行到哪里

py-locals
解释: 显示当前进程中的局部变量

py-print
解释: 打印python变量的值
用法: 例如
py-print self

info threads
thread
解释: 先查看线程信息，然后切换线程想要查看的线程

thread apply all py-list:
解释:查看所有进程执行位置

通过py-bt查看当前堆栈，除了使用gdb之外，还可以使用其他调试工具，比如pystack：

pip install pystack-debugger

执行pystack 57能看到：

 root@815eb533c377:/app# pystack 57
Dumping Threads....


  File "/usr/local/lib/python3.10/threading.py", line 973, in _bootstrap
    self._bootstrap_inner()
  File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/root/.cache/pypoetry/virtualenvs/knowledge-base-9TtSrW0h-py3.10/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 797, in run
    item = self.queue.get()
  File "/usr/local/lib/python3.10/queue.py", line 171, in get
    self.not_empty.wait()
  File "/usr/local/lib/python3.10/threading.py", line 320, in wait
    waiter.acquire()

---------------

也可以使用hypno:

pip install hypno

这个库的目标不太一样，主要是为了 inject 到正在运行的 Python 进程里跑一些代码，所以灵活性比单纯打 callstack 更高，比如可以打印一些变量之类。我们用如下的命令来实现获取 callstack 的功能：

hypno "import traceback; traceback.print_stack()"

还有py-spy：

pip install py-spy

获取 callstack 可以使用 dump 命令：

py-spy dump --pid 54

此外py-spy还支持top形式的实时 profiling，以及生成火焰图（操作稍麻烦）的功能，除了程序 hang 之外也能做性能优化的监控工具。不过易用性上来说比下面要介绍的austin还是稍微差了些。

conda install -c conda-forge austin-tui

这是一个集大成的 profiling 工具，不光可以看 callstack，还可以看对应的采样（近似理解为程序时间开销）百分占比信息，以及实时更新的 flamegraph 等，竟然还是跨平台的！官网上还有更多高级特性，感觉已经可以跟 JDK 里的 visualvm 来媲美了。

python 调试工具 pyrasite 可以附加到python进程中，在这个进程中打开一个python 命令行。然后再这个里面执行代码。

pyrasite-shell PID

（对于这种挂死问题通常是由于多进程和多线程混用导致的，多线程中如果有锁，在使用fork创建多进程的过程中fork出来的进程是单线程执行的，只会复制内存中的对象当前的信息，如果有一把锁被别的线程获取到，我们当前fork出的进程中的这个线程中，这把锁的状态只会是锁定状态，会导致子进程中再使用这个锁的时候会导致死锁。）

对于python进程中的挂死问题，我们需要对于进程中所有的线程查看它们卡死在了哪一个位置。

当我们进入这个进程中后，我们可以执行下面的代码查看进程的帧栈。

import sys
for threadid,stack in sys._current_frames().items():
    print(threadid,stack)

对于内存泄漏问题，我们可以使用objgraph来查看内存泄漏，对于python 代码造成的内存泄漏，我们可以很容易得看出来泄漏对象的引用关系。
但是对于C代码造成的泄漏，我们通常只能看出对象类型来，并不能看出泄漏对象的引用关系。所以还要一步一步排除。

py-spy 也可以看出进程是否挂死

使用方法 pip install py-spy

py-spy dump -p $pid

py-spy dump -l -p $pid