创万联技术分享

随风

物联网发展了这么多年，Aiot的概念也提出了很长的时间，但是却并没有掀起多少风浪，随着风口的退去，万物互联的时代仍然遥遥无期。数字世界，数字工厂仍旧没有到来，这究竟是为什么？我想其中最大的原因就是数据的处理不到位，大量的物联网数据并没有挖掘出应有的价值，这使得物联网系统变成了一个空架子，中看不中用。

随着大模型的发展，ChatGPT等生成形式AI的横空出世，人们对于非结构化数据的处理能力已经今非昔比。使用恰当的prompt工程和自主化Agent我们可以迅速的处理过去我们无法处理的东西。我们甚至还可以产生新的信息，去驱动我们的物联网系统，这一切将极大的推动了Aiot的发展。

我们从来没有想到，仅仅数年时间，科技的变化已经如此深刻。万物智联的时代似乎已经向我们招手，然而遗憾的是万物智联却远非将一个大模型缝合在物联网系统上，没有场景的理解大模型+物联网系统也将成为一个食之无味，弃之可惜的鸡肋产品。不少开发者尝试让大模型充当驱动智能音箱的新技术，然而很快便遭到了残酷的现实，大模型驱动的智能音箱体验不如传统的深度学习技术，响应缓慢而且执行准确率还不高，运行的成本却又比传统算法高出数倍，属实是一桩名副其实的赔本买卖。为什么开发者会进入此类误区呢，原因其实也无他，就是开发者执着于炫酷的技术而忽视了用户维度对产品交互的认识，因此才会导致了这类错误。当然随着新一代大模型的诞生，如Qwen3 Next已经实现了快速处理，成本大幅下降，智能体能力大幅提升的技术奇迹，智能音箱场景也许会重新变成“香饽饽”，大模型发展日新月异，开发者或创业者必须坚持不断学习，否则你今天的认知将会很快过时。

大模型+物联网的另一重挑战是协议。虽然MQTT在物联网具有了极为重要的地位，但物联网破碎的场景远非MQTT一种协议所能完全涵盖的。更糟糕的是MQTT协议过于宽松，即使全世界的物联网系统都使用MQTT那也同样无法实现万物互联的终极目标。因为其并没有定义其上层严格的数据交互规则，导致同样运行MQTT的系统无法实现无缝对接，MCP协议的出现本意是为了让大模型更方便的调用外部工具，却意外成了万物互联的新希望，海量的MCP工具和硬件支持正在谱写万物互联的新可能。

因此全新的开始，只意味着全新的可能，大模型强大的自主执行能力和情感理解给了开发者无穷的想象，然而大模型也不是万能的，更不是粘上点大模型技术就能成为赚钱的“银弹”，靠忽悠投资人和消费者的生意终究是不持久的，幸运的是不少公司和开发者已经找到了不少大模型落地的赛道，如情感陪伴和AI早教，这些领域虽然不是最佳的落地场景，却已经是迈出了坚实的步伐，我们坚信大模型+物联网将会书写像互联网时代一样的传奇。

随风

要问最近AI届什么最出圈，你一定能够脱口而出，没错它就是GPT5。过去了超过两年时间万众期待的GPT5终于亮相，尽管其性能可以称得上领先，但大家普遍的反馈仍然是非常失望，对于企业用户更是没有掀起多少波澜，大家仍然用着各种开源的模型做落地，用着Cluade模型进行AI编程。大家所期待的翻天覆地的变化不再出现。

GPT5模型并非单一架构，其内置的路由模块能够自动决策是否调用深度思考模型。这种设计乍看之下颇具威力，然而现实应用却并非如此理想。用户需求本就纷繁多样，这种看似智能的设定，恰恰因其不确定性成为了使用体验不稳定的根源。例如，当用户询问旅游攻略时，启用深度思考显然是合理的选择。然而，现实中的大部分场景远非如此简单易判。以智能家居垂直应用为例：用户发出“我回家了”的指令，模型究竟应该深度思考生成复杂响应，还是进行快速直觉性反应？事实上，这两种处理方式都只符合部分用户的需求。

问题的核心在于，当前的路由机制难以精准捕捉用户意图的微妙差异以及场景的复杂性。一刀切的“智能”决策，在需求边界模糊的日常场景中显得力不从心。用户可能希望“我回家了”触发一系列预设的快捷操作（如开灯、调温），此时深度思考反而显得冗余且迟缓；而在另一情境下，用户或许期待模型能基于当前环境（如天气、时间、家庭成员状态）进行更深层次的推断与个性化响应（比如询问“是否要播放放松音乐？”或“晚餐有什么建议？”）。这种“应该深度思考还是快速响应”的模糊地带，恰恰是路由模块最易出错之处。

这种不稳定性不仅可能导致响应延迟（深度思考耗时），更会带来预期之外的交互结果，破坏用户体验的连贯性和可预测性。用户无法建立稳定的心智模型去理解GPT5在不同时刻的行为逻辑，每一次交互都可能是一次“开盲盒”。在强调效率与确定性的垂直领域（如智能家居、客服、生产力工具），这种不确定性尤为致命。它削弱了用户对模型的信任感，也阻碍了其在关键场景的深度集成。

因此，仅仅依赖模型内部“黑盒”式的路由决策是远远不够的。未来的优化方向可能需要引入更精细化的用户意图识别技术、结合显性的用户偏好设置（允许用户预设特定场景的处理倾向），或者发展更强大的上下文感知能力，使模型能动态理解当前对话的“深度需求临界点”。否则，路由模块的“智能”设计，反而可能成为制约GPT5真正理解并高效服务用户的瓶颈。更要命的是GPT5一旦路由模块出现故障还可能引起智商大规模降低，本应智能分配问题至快速响应或深度思考模式的系统失灵，使 GPT-5 在简单任务中表现迟滞。

事实上我们并非反对GPT5的实时路由设计，恰恰是我们是实时路由系统的较早拥抱者，我们很早提出了实时语义路由系统，进行智能家居场景的智能体加速方案，但在长期实践中我们遇到了各种问题，本以为能够显著降低成本和延时，然而实际上并未如同我们想像一般强大，反而遇到了许多问题，那么如何使得实时语义路由系统发挥出其本应显现的威力呢，我想答案就藏在我们的标题里面——“没有免费的午餐”，即不存在一种强大的单一的智能模型解决所有问题，因此个性化和用户偏好设置在AI时代仍需存在，不能指望AI系统能理解我们所有的请求，事实上即使是人本身也不可能做到，你无法百分百的满足你父母和身边人的期望，我们只能通过沟通与交流进行尽可能的做到完美，也不存在一个全知全能的人，这不正是 “没有免费的午餐” 定理的生动写照嘛。

因此所谓的AGI即通用人工智能很可能永远无法实现，通用人工智能满足了全知全能的特性，这不就是赛博上帝吗？AGI之路注定不可能是一��风顺的，也许会彻底失败，就像永动机一样被证伪，也可能像室温超导一样陷入“罗生门”，最好的结果就是人类取得了突破，但无论结果如何GPT5表现不佳恐怕已经是板上钉钉，那么接下来的GPT6会不会取得新的突破呢？那我们就拭目以待吧。

社区开源AI智能体项目链接 ：https://github.com/ruanrongman/IntelliConnect

随风

随着大模型的飞速发展，大模型对于现实世界的交互也有了长足的进步，Langchain成为打响这一战役的第一枪，其使用提示词的方式率先使得大模型得以与现实世界交互，随后OpenAi推出了具有代表意义的Function Calling技术，这项技术使得模型���以“调用”外部函数，它成为了模型与外界交互的新选择，随后智能体技术得到了巨大的发展，Agently和Promptulate等智能体框架飞速发展，使其成为2024年AI应用的宠儿。随后Dify和Coze等智能体应用也应运而生，它们的特点都是针对AI的不稳定性质，对其使用人工编排的WorkFlow即工作流替代，使其成为企业落地的首选。按照这个发展趋势，统一的智能体或者框架类似web世界的各种框架应当得到巨大发展，极大减少人们开发AI应用的成本。

然而故事却在2025年发生了巨大的变化，智能体框架不再成为大家落地AI应用讨论最多的点，业界开始着眼于工具调用统一协议这个问题，于是mcp协议开始走向大众视野，一时间各种营销号开始疯狂鼓吹mcp能够实现的各种强大功能。然而很多人却没有理解mcp的本质。MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。

MCP协议的飞速发展，衍生出了各种MCP服务提供者，其后形成了MCP市场生态，这极大的丰富了AI应用的能力边界。而后MCP协议开始进军传统的物联网行业，开始成为控制万物的新协议，著名的开源项目小智AI就全面拥抱了MCP协议，使得其可以轻松扩展各种丰富有趣的功能。然而MCP协议获得巨大成功的同时却又由于自身设计的局限，对其进一步发展产生了限制，比如MCP协议的服务端，其设计初期MCP服务器运行多在本地，用于给克劳德客户端使用，然而对于云服务提供的开发者来讲却出现了一些困难。SSE协议的不稳定，随后虽然有stremable http的替代但是至今未形成强大的生态。小智不得不破坏了一些MCP规范来获得远程服务端的支持，小智AI具体方案是将MCP服务端视为客户端，创造了一个新的管道链路层，这种办法虽然能够解决当下的问题，然而属实是不够优雅，需要开发者重新适配，造成了当今大家都是MCP协议却无法互通的尴尬局面，多少与Type C有些类似了。

MCP协议作为通用的协议，其始终也未能解决工具编写依赖精巧提示词设计的问题，这也不是MCP协议该解决的问题，更让人头疼的是MCP混乱的服务器命名和工具设计，导致其稳定性堪忧，在生产环境上无法有效运用的问题，在AIOT领域虽然其动态发现，动态注册的优势十分明显，但其却无法较好解决跨设备控制，以及更复杂的设备控制场景，究其原因还是因为其设计之初并没有考虑AIOT的应用场景，因此我觉得MCP协议作为智能体能力扩展本身意义非凡，但应用于AIOT领域则需要等待时间的验证。

很久没有写过这么长的随笔了，感谢大家看到这里，欢迎关注我们社区公众号，我们下期不见不散。

随风

使用硅基流动+chatbox的方式可以解决当前官网卡顿的问题，但是有些时候我们出外做项目或者是在需要保密的场景，我们可能无法使用联网的大模型，那怎么办呢？别急，本地部署大模型是你的最后选择，使用Lmstduio部署本地大模型是当前最简单的本地大模型部署方法，可以让你轻松尝试到不用联网也能畅快玩耍Ai的快感。

首先我们下载LM Studio – Discover, download, and run local LLMs软件。

安装完成后就会出现以下界面

我们点击左侧放大镜图标，根据自己电脑的性能，选择一款自己想下载的模型(我的电脑是Rtx4060，可以流畅运行7B的DeepSeek模型)其它配置的电脑可以点击尝试，如果可以运行的话LmStudio会出现绿色图标，表示可以运行。

下载完成后，回到主页面，设置好参数，可以按照我的配置进行设置（一般默认即可），点击加载模型(load model)。

然后就可以愉快玩耍了。

不得不说AI的进步真的是一日千里，DeepSeek将R1蒸馏成多个尺寸的版本使得总有一款模型适合你的电脑，开源模型将加速端侧AI时代的到来，也使得个人开发者和用户也能参与到AI的滚滚洪流之中，最后想说一句——开源力量是很难阻挡的。

随风

当前DeepSeek模型可谓是当红炸子鸡，其强大的性能，低廉的训练成本，使得其在AI界迅速走红，创万联在年初就已经基于其开发Ai原生应用 ruanrongman/IntelliConnect: A Powerful AI agent IoT platform core. 在开发中其强劲的模型能力带来了愉悦的开发体验，但最近由于用户激增，网络攻击等原因，官网使用经常出现访问不稳定，问一个问题很容易出现服务器限流，这严重影响了用户体验，但幸运的是 DeepSeek 是开源模型，因此许多第三方平台，或者是自己本地部署均可以实现 DeepSeek模型自由。

首先打开硅基流动官方，这里可以使用我的邀请链接，双方均可以获得更多免费额度。https://cloud.siliconflow.cn/i/dlfqbBUr，注册之后进入界面，点击左侧API密钥，进入到API密钥栏目，点击新建API密钥复制备用。

然后下载chatbox，这是一个第三方的界面友好的对话引擎，官网为Chatbox AI官网：办公学习的AI好助手，全平台AI客户端，官方免费下载，安装之后点击设置，输入自己的API密钥，选择v3或者思考模型R1即可流畅使用。

希望以上教程可以帮助到各位朋友流畅的使用DeepSeek模型。下期还会给大家介绍如何本地部署自己的DeepSeek模型，实现桌面AI时代。

研发部

随着chatgpt的发布，人工智能开始进入了大模型时代，2024年时毫无争议的AI应用元年，各种AI应用如雨后春笋般的产生。其中智能体技术堪称是开发的革命性技术，我们也由此推出了可能是首个专为智能体应用设计的物联网平台ruanrongman/IntelliConnect: A Powerful AI agent IoT platform core. 。但这物联网平台的落地远不是开发出来就结束，没有实际的落地应用就像设计精美但无人使用的操作系统一样没有任何价值。为此我们坚持与兴趣相投的各种组织开展各种合作活动，其中我们非常看重AI陪伴的未来价值，因此加入到了潦草小狗的开发计划中。详细可以观看：潦草小狗驱动开发入门教程 —— 发送外部音频数据至 CI1303 例程。

潦草小狗是陪伴型的桌面宠物，配合ic平台的功能，将有望能实现流畅的对话和各种控制和思考能力。ic平台和潦草小狗基本已经完成大半，目前最为困难的就是如何实现语音的双向传输，以及本地识别和云端能力的有机结合。为此我们选用了启英泰伦这款语音芯片，我们花了很多时间对其sdk进行仔细观看，按照如下方案启英泰伦 CI1303 算法 SDK 开发入门教程，对其进行配置，但播放功能一直出现芯片反复重启的问题，使用内部时钟源的时候， 开启播放外部音频宏， 自动校准波特率和开始两个中断会导致 flash 分配问题 芯片随即重启，我们对此非常困惑，最后rymcu的hugh大佬提出按如下修改了部分源码，该问题才得到一些改善，能够正常运行。

然而随即也开始面临芯片MP3解码的挑战，由于其仅支持16kbps，单声道串口传输。这种低码率的声音很少TTS模型能够支持，因而需要自行编写转换代码，测试了多种方案，目前仅如下方案，能够正常运作。使用pydub进行转码。

audio_segment = audio_segment.set_channels(1)
audio_segment = audio_segment.set_frame_rate(16000)  # 设置采样率为16 kHz
audio_segment = audio_segment.set_sample_width(1)  # 设置样本深度为8位（1字节）

但是较长语音问题仍旧非常困扰我们，猜测是解码器存在一些问题，我们将持续研究，期望能有所推进。

上述内容仅为本人实践日志，不涉及芯片本身的质量以及相关产品能力。

随风

转眼间创万联社区已经陪伴大家7年了，不知道朋友们是否还记得那个艳阳高照的下午，我们意气风发的在新会一中的操场上讨论着对未来科技的畅想。也许时间早就将一切抹平了，但我依旧清晰记得当时的愿景，希望做一个智能电梯系统或者是远程的煤气中毒报警系统。我和孙，李三人组成了最初的小组，我们奔走于化学实验室和简陋的杂物间，靠着市面上的物联网模块我们终于做出了能够检测和远程手机报警的模块，在孙的邀请下梁充当海报设计，随后余和进也加入到小组中，rslly小组正式形成，这就是我们域名rslly的来源。我们的产品虽然不是很新颖，但凭借着实用和高技术含量（高中生而言）我们顺利进入了区的比赛。成功晋级区的比赛后，我感到了自研的必要性，必须设计出一个属于我们自己的物联网平台和电路板。随后的故事大家也知道了我们凭借着自研的平台和微信交互电气的廉价理念我们拿到了省二的奖项，奠定了社区的基础。

高考之后大家相继进入了各大高校，我们原始的小组齐聚在一起的机会变得非常少了。但疫情阶段的新工具腾讯会议成为了我们新的交流方式，我们社区的性质也开始由比赛团队转变为开源社区，致力于构建Aiot的平台和解决方案。社区得到了比较大的发展，大约在我大三上学期阶段社区规模达到最大，社区设计出来的衍生产物和大量文章得到了比较好的应用和传播。这阶段虽然整体比较好，但却也逐渐显现出了内部团队的管理问题，人数的增多以及缺乏有效的组织，目标逐渐迷失，过大的目标和空的梦想逐渐使得人心离散。到了大三下学期的时候就业压力的逐渐增大，社区逐渐进入了休眠时期，物联网的普及化使得社区的技术已经显得不再先进，我们尝试过植物工厂，鱼菜共生等方案，甚至是数字孪生的激进方案，但团队本身的吸引力明显不如从前，也没有真正产生非常有价值的东西，社区事实上走到了迷茫时期。

随着大模型的横空出世，Zeeland等人的积极探索使得社区空前活跃，虽然由于就业影响，人数不如从前，但是Agent框架以及Ic平台等项目的出现，社区从事实上进入了全新的阶段，以开源项目为主导的阶段。Agent+Iot的构想使得通用Aiot平台成为了从梦想到现实的一大步。我们仍旧在迷雾中探索，但在探索中我们又认识了Rymcu的ronger等人，他们的言行给了我们极大的鼓励，也许我们未必能成为一个真正的开源社区，但这些探索亦足以使得我们感受到了作为一个程序员的浪漫，感谢大家的支持和鼓励，欢迎有同样爱好的朋友加入，我们期待你的加入。ruanrongman/IntelliConnect: A Powerful iot platform core.