聊聊老罗的十字路口

上个月写随笔《李想的理想》的时候其实已经了解到老罗要进军播客赛道。相较于早年创办锤子科技以及近期宣布的泡面而言,这次大众都异常默契的认为老罗选择了“正确的道路”。节目名称《罗永浩的十字路口》是对乔布斯科技与人文的致敬,另一方面也是老罗自我阶段性的自我调侃吧。

截至这个月底,已经出了两期节目,虽然先前肯定早有谋划筹备和存货,但长谈内容达到这个更新频率,老罗还是挺拼的,看后期这个节奏能保持多久。

陆陆续续看完了前两期节目,没有错过任何一秒内容,有些段落会倒退回放。本身就是长谈的节目,两期节目完整听下来。第一期李想,第二期小鹏。按说下一期应该是李斌了。如果真的如此,我倒有点期待老罗能否从没有未来的公司创始人那里聊出一些能影响自己先前认知和判断的内容。

回到已经看过的两期内容,李想的内容其实把我之前已知的内容进行了完整的串联,没有太多的补充内容。但是其在节目中完整的表述的自我强化学习的理论、实践,以及基于这套方法论下对未来AI、机器人的判断还是让自己非常惊奇。而关于AI的发展有两个看法还是洞见的,一个业界其实不太看得上的朴素而精准的是OpenAI的关于AI的chatBot, agent, 管理者, 组织者的阶段划分;一个是模型能力不断内化提升,落地场景不断外化为流程的双循环进化理论。而后者其实也是自己已知在一些工作落地场景里面一直有模糊思考,但是第一次听到这样精确表达,后面做的一些事情其实也在验证这个理论。

李想的思维其实非常理工科,很多兴趣和观点让自己有很深同频共鸣感。但是反观其事,又是一个不太理工科的方式。而他总结这一期都是一次次深刻的痛苦和教训带来的。老罗问及他为什么很早就明明有机会选择小富即安,但是偏偏走上了更加艰险的创业之路,两者都动容了。某种程度上,任何个体的选择,只要守住了底限,本身无可厚非,但是很多时候我们又何尝不是新时代的井底之蛙,自以为知道和了解全球的资讯、历史,任何信息都在指尖触手可达。但是我们真的知道吗?我们真的有必要知道吗?看完节目,我有点明白为什么Tim在100小时生存上岛以后,会在总结里面不断提及所谓的“知道”。

而第二期小鹏,因为之前并没有系统看过何小鹏的信息,很多内容对自己而言都是全新的。整体听感上,小鹏的思维和表达就是自己更加熟悉的很理工男,甚至可以更加精确到计算机科学专业男。直率,知道就给直球,不知道就承认没想清楚不知道。这里有老罗提问的功底,更多是小鹏的个人特质。但是,如果从企业经营上看,跟李想比较,小鹏无疑还处在更加前期的成长阶段。但是,显然他更加的知道和理解技术细节,但是也有一种之前履职过阿里带着的一点“废话文学”味道。因此,如果从钱包投资的角度看,我会毫不犹豫的继续追加前者,而会对后者一直保持关注。如果说有所失望的话,应该就是小鹏其实有点故意的在梳理技术,会更加在意自己在宏大叙事上的表达和铺陈,而没有太多的细节和实操内容的分享。而老罗的节目也专门安排了这个环节来迎合观众的胃口,也不是不能理解。只是从上一代互联网红利中投身实业,在国内真的没有几个,还是希望小鹏能够走得更高更远一些。

两期节目听下来老罗提问的节奏和套路已经非常成熟,甚至可以说是炉火纯青了。无论是对话题的把控,还是对嘉宾的引导,都非常到位。尤其是对李想的提问,几乎没有任何废话,都是直击要点。对小鹏的提问则稍微有点宽松和铺陈,但是也在情理之中。老罗的提问其实是有技巧的,既不会让嘉宾觉得被逼问,也不会让观众觉得无聊。尤其是他会在关键节点上进行一些总结和升华,让整个对话更加有层次感。也会简短的讲一些自己的经历和感受。可能前两期嘉宾的行业和话题重合度比较高,总觉得这两期节目多元化缺了点,就看下期嘉宾是谁。如果内容10期以后,都能达到这两期节目的声量和传播量,商业化应该是个水到渠成,也是老罗做起来很舒服的一件事了。

近期LLM的一些趋势之二——MCP

书接上回,文末提到一个点:

当然也有不变的点:工具的建设依然很重要。只不过,今年需要更多的思考如何将这些基建工具与上述的flowgraph结合起来。

当时没有展开写,而最近随着MCP(Managed Context Protocol)的逐步普及和应用,今天来补一下当时挖的坑。

什么是MCP

参考MCP的官方文档,MCP是一个用于管理和使用上下文的协议,旨在帮助开发者更好地与大型语言模型(LLM)进行交互。它提供了一种结构化的方法来处理上下文信息,使得在与LLM进行对话时,可以更有效地传递和管理信息。

它的工作流程也很简单(LLM以Claude为例):

When you submit a query:

  • The client gets the list of available tools from the server
  • Your query is sent to Claude along with tool descriptions
  • Claude decides which tools (if any) to use
  • The client executes any requested tool calls through the server
  • Results are sent back to Claude
  • Claude provides a natural language response
  • The response is displayed to you

从工作流程来看,是不是感觉跟我们熟悉的Function Calling有些类似?

MCP vs function calling

MCP和Function Calling的区别在于:

  1. 功能范围:MCP不仅仅是一个函数调用的接口,它还包括了上下文管理、工具描述和结果处理等多个方面的功能。而Function Calling主要集中在函数调用本身。
  2. 上下文管理:MCP提供了更为全面的上下文管理功能,可以在多个工具之间共享和传递上下文信息。而Function Calling通常是针对单个函数的调用,缺乏跨函数的上下文管理能力。
  3. 工具描述:MCP允许开发者为每个工具提供详细的描述信息,以便LLM更好地理解如何使用这些工具。而Function Calling通常只提供函数名和参数,缺乏详细的描述信息。
  4. 结果处理:MCP在结果处理上也提供了更多的灵活性,可以根据不同的工具和上下文信息进行定制化的结果处理。而Function Calling通常是固定的结果处理方式,缺乏灵活性。
  5. 适用场景:MCP更适合于复杂的应用场景,尤其是需要多个工具协同工作的场景。而Function Calling更适合于简单的函数调用场景。
  6. 扩展性:MCP的设计考虑了未来的扩展性,可以方便地添加新的工具和功能。而Function Calling在扩展性上相对较弱,添加新功能可能需要较大的改动。
  7. 社区支持:MCP是一个开放的协议,得到了广泛的社区支持和参与。而Function Calling通常是由特定的公司或组织维护,缺乏广泛的社区支持。
  8. 文档和示例:MCP提供了详细的文档和示例,帮助开发者快速上手。而Function Calling的文档和示例相对较少,可能需要开发者自行摸索。
  9. 学习曲线:由于MCP的功能更为全面和复杂,学习曲线相对较陡。而Function Calling相对简单,学习曲线较平缓。
  10. 性能:在性能方面,MCP可能会因为其复杂性而引入一定的性能开销。而Function Calling通常是直接调用函数,性能较高。
  11. 安全性:MCP在设计上考虑了安全性,提供了一些安全机制来保护上下文信息。而Function Calling通常缺乏这样的安全机制,可能存在一定的安全隐患。
  12. 兼容性:MCP是一个开放的协议,可以与多种语言和平台兼容。而Function Calling通常是针对特定语言或平台的,兼容性较差。

此外,可以参考《MCP 与 Function Call 区别》。其中提到一个比喻非常形象:

  • MCP:通用协议层面的标准约定,就像给 LLM 使用的“USB-C规范”。
  • Function Call:特定大模型厂商提供的独特特性,就像某品牌手机的专属充电协议。

如何使用?

回到我们最开始的观点:不变的点:工具的建设依然很重要。对于MCP来说,主要是指MCP Server。作为一个gopher,推荐者以下两个项目:

两个项目都是golang传统的开箱即用。

要让LLM能够把提供工具、资源、prompt驱动起来,需要借助 MCP client 这个桥梁。而目前从官方推荐的Clients来看,MCP client 主要以两种形式出现:①面向普通用户的application应用,如Claude Desktop App;②面向开发者的agent框架库,如mcp-agent。这里推荐fast-agent.

MCP 的意义

MCP的意义在于它为开发者提供了一种结构化的方法来管理和使用上下文信息,使得与LLM的交互更加高效和灵活。通过MCP,开发者可以更好地利用LLM的能力,构建出更为复杂和智能的应用程序。

还是有点抽象,对不对?从过去技术发展历史来看,MCP跟当年的微服务架构有点类似。不同的是,微服务架构下更多的还是工程、业务逻辑驱动数据流和控制流,而MCP则是将LLM作为决策中枢。也就是说,MCP是一个面向LLM的微服务架构。

太阳底下没有新鲜事,以前微服务架构下的经验在MCP架构下会有一定的借鉴意义。另一方面,MCP的出现也意味着我们需要重新审视和设计我们的应用架构,以更好地适应LLM的特点和需求。

MacBook M1配置ESP32开发环境

兴趣使然,斥巨资25元淘宝了一块ESP32的开发版,也就是最“昂贵”的ESP32 DEVKIT V1。

已经有将近10年没有做嵌入式开发,正琢磨着要不要搞一个Windows环境做ESP32开发,搜索一圈以后发现,esp-idf对各个平台的支持居然都不错。因此尝试在M1上面配置了一下ESP32的开发环境。

esp-idf本质上是一个VS Code插件。因此,所谓的安装配置过程就是ESP-IDF VS Code 插件的安装过程。整体流程基本做到了一路下一步。如果你跟我一样是苹果M1的环境,有几个点需要在注意一下:

  • idf插件依赖python 3环境。macOS Monterey自带的python3会在一些路径识别上出现头文件无法找到的问题,导致安装失败。诸如:

clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64 -arch x86_64 -Werror=implicit-function-declaration -DCYTHON_CLINE_IN_TRACEBACK=0 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -Isrc -Isrc/lxml/includes -I/Users/liudanking/.espressif/python_env/idf4.4_py3.8_env/include -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -c src/lxml/etree.c -o build/temp.macosx-10.14-arm64-cpython-38/src/lxml/etree.o -w -flat_namespace

解决方式其实也很简单,从python官网下载一个python3版本手动安装一下即可。

  • 安装完成以后,直接使用USB线连接,电脑可能无法识别设备,需要安装CP2102芯片的usb-to-uart驱动
  • 根据范例,手动尝试点亮板载的蓝色LED,可能会出现无法点亮的问题。这是因为自己购买的开发版并不是官方版本,GPIO引脚并不是实例源码中的8,可以通过查看商家给的电路图的方式,确定正确的蓝色LED GPIO具体是多少。具体到我的情况,修改为GPIO 2即可。

初步体验下来,ESP32的示例代码挺齐全的,环境配置门槛也不够,开发版整体也足够便宜,再加上当前“万物互联”的概念,这几年能够拿下相当一部分市场也的确是软硬实力兼具的。接下来会用一些业余时间做一些有意思的玩具,不定期更新在博客。