Posts

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 随着本地AI编程助手如Codex、Claude Code和Cursor的普及，开发者开始习惯让AI长时间在后台执行复杂任务：读取文件、运行测试、修改代码、等待权限批准。在这些场景中，你不得不反复切回终端或编辑器确认进度——是否有更直观的方式了解Agent的状态？ 你可能已经在朋友圈中看到，有人用类似信号灯的硬件，实时展示AI编程助手的状态。 AI编程助手的状态是如何采集并展示的呢？ 最近萌叔发现了一个纯软件实现的vibe coding信号灯 vearne/vibecoding-signal-light，通过悬浮三色灯、菜单栏图标和Touch Bar实时展示AI Agent的工作状态。 本文将深入剖析其技术实现，特别是如何从Cursor编辑器获取状态并映射为灯语。 2. 整体架构：双Swift进程协作 项目采用了清晰的双进程设计，全部基于Swift构建： Swift CLI（signal-light-cli）：无状态命令行工具，由Cursor/Codex/Claude Code的hook调用。负责解析事件、更新状态文件、发送跨进程通知。 Swift App（signal-light-mac）：macOS AppKit长驻应用。读取状态文件，通过动画定时器驱动三色灯UI渲染。 CLI写完状态后，并非只靠App轮询文件。它会双通道通知App立刻刷新： Darwin CFNotification（com.vibecoding.signal-light.status-changed）——跨进程、低延迟 DistributedNotificationCenter——同用户会话内的兜底通知 App侧同时监听这两种通知，并用文件系统监控作为最终兜底，因此灯语能接近实时变化。 2.1 配置Cursor Hook 应用安装时，会创建 ~/.cursor/hooks.json。 Cursor 的 hooks.json 是一套事件驱动的中间件机制，用来在 Cursor Agent（AI 助手）特定生命周期节点插入自定义脚本，从而观察、拦截、控制或扩展 AI 的行为。可以把它理解为挂在 AI 工作流流水线上的“钩子”。 内容大致如下： { "hooks": { "afterAgentResponse": [{ "command": "\/usr\/local\/bin\/cursor-signal-hook", "timeout": 5, "type": "command" }], "afterAgentThought": [{ "command": "\/usr\/local\/bin\/cursor-signal-hook", "timeout": 5, "type": "command" }], "afterFileEdit": [{ "command": "\/usr\/local\/bin\/cursor-signal-hook", "timeout": 5, "type": "command" }] ... }, "version": 1 } Cursor 侧注册了约 20+ 个 hook 事件（完整列表见附录）；高频几个包括 beforeSubmitPrompt、preToolUse / postToolUse、afterFileEdit、permissionRequest、stop 等。 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 0. 起因: 萌叔开发的某个MCP服务，在本地调试正常，然后当它在线上部署时，发出tool调用后，经常没有反应，使用 modelcontextprotocol/inspector 进行调试 发现 Error from MCP server: SseError: SSE error: Premature close MCP 服务器的 SSE 连接提前关闭错误。这个错误通常意味着客户端与服务器建立的 Server-Sent Events 长连接被意外中断了。 有可能MCP的Client和Server的连接被当成空闲连接给kill了。 这是否与协议的设计有某种联系，萌叔使用wireshark抓包发现了一些有趣的事情。 1. SSE 模式 HTTP+SSE 传输（需要 /sse和 /message两个端点） 并通过不同的 HTTP 方法来区分行为： POST 请求：客户端向该端点发送 JSON-RPC 消息（请求、通知或响应）。 GET 请求：客户端向该端点发起请求以建立 SSE（Server-Sent Events）流，用于接收服务端的长连接推送或流式数据。 DELETE 请求（可选）：可用于终止会话。 1.1【连接1】 专门用于MCP-Server向MCP-Client推送数据 请求 GET /sse HTTP/1.1 accept: text/event-stream accept-encoding: gzip, deflate, br user-agent: node-fetch Host: localhost:8080 Connection: keep-alive 响应 注意：【连接1】是长连接，且Content-Type: text/event-stream，连接不会被关闭。 text/event-stream ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 从内存、显卡到家用电器，一场由AI算力需求引爆的全产业链涨价潮正在重塑全球科技产品的价格体系。 2025年底，当游戏玩家们攒够钱准备升级电脑时，发现原本预算中的内存条价格已经翻倍。深圳华强北的柜台前，16G DDR4内存条从180元涨到400元以上，而一根256G的DDR5服务器内存条售价突破4万元。 同一时间，江苏一家制造业企业的采购总监收到通知：工业级芯片的交货周期从8周延长到26周，价格上调30%。美国弗吉尼亚州的数据中心运营商正在重新评估电力合同——当地电价在一年内上涨了13%，而他们的电力需求还在持续增长。 这些看似孤立的事件，都指向同一个源头：AI引发的全球产业链价值重估。 1. 价格雪崩的反面：存储芯片的"超级周期" 存储芯片市场曾以剧烈的周期性波动著称，但这一轮上涨与以往截然不同。 DDR5内存的现货价格在2025年7月至2026年1月间飙升至原来的4.4倍，而三星DDR5内存条在韩国分销渠道的价格更是达到了2025年11月的4倍。TrendForce预测，2026年第一季度的存储合约价将继续大幅上涨：DRAM涨幅达55%-60%，NAND闪存涨幅达33%-38%，远超此前预期。 芯片品类 具体涨幅 时间范围 关键影响因素 消费级DDR5内存 飙升至4.4倍 2025年7月 vs 2026年1月 AI服务器需求挤占产能 三星DDR5内存条 价格是4倍 2025年11月 vs 2026年1月 高端产能优先供应HBM 存储合约价（预测） DRAM涨55%-60% NAND涨33%-38% 2026年第一季度 TrendForce最新预测 服务器CPU 调涨10%-15% 2026年第一季度 英特尔、AMD产能紧张 涨价的根本逻辑是结构性失衡。一台AI服务器对DRAM内存的需求是普通服务器的8倍，对NAND闪存的需求是3倍。当存储巨头将超过70%的先进制程产能分配给利润更高的HBM（高带宽内存）时，消费级产品的供应自然被挤压。 2025年12月，美光宣布逐步退出消费级DRAM市场，将资源集中于数据中心和AI领域。这个决定像一块投入平静湖面的巨石，在整个产业链激起连锁反应。 2. 涟漪效应：半导体全产业链的共振 涨价浪潮从存储芯片开始，迅速蔓延至整个半导体产业链。 在芯片设计环节，亚德诺（ADI）宣布自2026年2月1日起全线产品涨价10%-15%，工业级产品涨幅更高。在制造端，中芯国际、台积电等代工厂在2025年第四季度陆续发出涨价通知，涨幅在5%-10%之间。 封装测试环节同样紧张，日月光、长电科技等厂商将封测价格调涨5%-20%，其中用于AI芯片的先进封装服务涨幅最大，部分订单排队时间超过一年。 半导体材料市场同步响应。用于芯片制造的12英寸硅片在2025年内价格上涨接近90%，特种气体如六氟化钨的市场报价普遍上调70%至90%。这些基础材料的涨价，进一步抬高了整个芯片制造环节的成本。 3. 终端产品的"成本病"：从B端到C端的传导 芯片和材料的涨价最终传导至消费者手中。小米最新款旗舰手机的起售价较上一代上调了500元，内存成本在手机总成本中的占比从10%-15%飙升至20%以上。 个人电脑市场同样承压，戴尔、惠普、联想等厂商已通知渠道伙伴，PC和服务器产品价格将上调15%-30%。一位代理商透露：“有厂商直接建议，如果半年内有采购计划，最好现在就下单锁定价格。” 汽车行业虽然单车芯片成本占比较低，但影响同样显著。蔚来创始人李斌坦言，内存涨价是2026年最大的成本压力之一，可能影响部分车型的交付周期。更深远的影响在于，当AI芯片与汽车芯片争夺同一批晶圆产能时，整个汽车行业的供应链稳定性面临挑战。 这场涨价潮的传导链条清晰而残酷：AI算力需求 → 存储芯片供应紧张 → 半导体全产业链涨价 → 终端电子产品成本上升 → 消费者支付更高价格。 4. 不只是芯片：电力、金属与连接的基础设施压力 AI的影响远不止半导体领域。训练大型AI模型的能耗惊人——GPT-4的单次训练耗电量相当于1.2万个美国家庭的年用电量。国际能源署预测，到2026年全球数据中心的电力需求将达到1000太瓦时，接近日本全国的年用电量。 电力需求的激增推高了相关地区的电价。美国数据中心密集的弗吉尼亚州，2025年电价上涨13%。2026年1月的寒潮期间，美国天然气价格一度暴涨140%，电网运营压力巨大。 金属市场同样受到影响。一台AI服务器的用铜量高达1.3吨，是传统服务器的400倍。伦敦金属交易所铜价在2025年上涨43%，创下2009年以来最大年度涨幅。这直接导致空调、家电等行业被迫采用"铝代铜"方案或直接提价。 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 建议阅读，萌叔之前的文章 OpenTelemetry原理及实战 OpenTelemetry个性化采样-根据特定Header决定是否采样 1. 前言 一些复杂的业务场景，会出现任务被从接口提交，并在后台进行异步执行的情况。 这种情况下可能需要引入消息队列，涉及TraceContext通过消息进行跨节点(服务)的传播。 参考： W3C TraceContext 规范 这篇文章萌叔以RocketMQ来举例，看trace信息如何传递。 2. Golang中的实现 手动埋点追踪RocketMQ。 由于目前Golang的RocketMQ客户端缺乏像Java那样的自动埋点支持， 我们需要在消息发送和消费处理的关键位置手动创建Span。 2.1 消息发送方（Producer） import ( "context" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/attribute" "go.opentelemetry.io/otel/trace" ) func sendMessageWithTracing(ctx context.Context, producer rocketmq.Producer, topic, body string) error { tracer := otel.Tracer("rocketmq-producer") // 创建一个新的Span，代表本次发送操作。这里的ctx可能是来自HTTP请求或上游服务的上下文。 _, span := tracer.Start(ctx, "rocketmq.send", trace.WithAttributes( attribute.String("messaging.system", "rocketmq"), // 语义约定：消息系统 attribute.String("messaging.destination", topic), // 语义约定：主题 attribute.String("messaging.rocketmq.message.tags", "your_tag"), // RocketMQ特定属性 // 可以根据需要添加更多属性，如keys )) defer span.End() // 确保Span最终会结束 // 准备消息 msg := primitive.NewMessage(topic, []byte(body)) // 关键步骤：将追踪上下文注入到消息属性中 carrier := NewMessageCarrier(msg) // 你需要实现一个Carrier，见下文说明 otel.GetTextMapPropagator().Inject(span.SpanContext(), carrier) // 发送消息 _, err := producer.SendSync(msg) if err != nil { // 记录错误 span.RecordError(err) span.SetStatus(codes.Error, "SendSync failed") return err } span.SetStatus(codes.Ok, "Success") return nil } 关于Carrier：你需要实现propagation.TextMapCarrier接口，以便将追踪信息（TraceID, SpanID等） 以键值对的形式存入RocketMQ消息的用户属性中。一个简单的实现示例如下： ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 建议阅读，萌叔2024年的文章 OpenTelemetry原理及实战 1.前言 统一术语: 采样: sample，在OpenTelemetry的语境下，是指收集tracing（包含span)信息，并上报 对于订单类的服务而言，由于服务特别重要，QPS不高，全量采样问题不大。 但是对于内容型的服务，比如微博、抖音服务，这类读多写少的服务，全量采样成本巨大， 不仅不现实，也没有必要。此时当然可以考虑按照百分比采样， 另一种更为保守的做法，只收集异常的请求(客户端收集，指标告警，客服报障)，进行流量重放， 并同时采集tracing信息。 2.根据特定Header决定是否采样 这时候我们需要特定的标识表明这个请求需要强制采样。 以HTTP请求为例，可以给定特殊的Header X-Force-Trace: 1 2.1 上游服务 OpenTelemetry的SDK预留了Sampler接口，用于定义个性化的采样需求(是否采样) // Sampler decides whether a trace should be sampled and exported. type Sampler interface { // DO NOT CHANGE: any modification will not be backwards compatible and // must never be done outside of a new major release. // ShouldSample returns a SamplingResult based on a decision made from the // passed parameters. ShouldSample(parameters SamplingParameters) SamplingResult // DO NOT CHANGE: any modification will not be backwards compatible and // must never be done outside of a new major release. // Description returns information describing the Sampler. Description() string // DO NOT CHANGE: any modification will not be backwards compatible and // must never be done outside of a new major release. } 完整代码见 vearne/otel-test ...

1. AI智能体 什么是智能体？ 智能体（AI Agent）是指能够感知环境、自主决策并执行任务以实现特定目标的智能实体 。它以大模型为智能底座，具备自主感知、理解、规划、决策、记忆和行动的能力，能够自动化执行复杂任务 智能体 = LLM + Prompt + 知识库(Retrievers, optional) + Tools(optional) + Memory(optional) + chain(optional) 可以参考LangChain 实现 1.1 RAG(知识库) 1.2 MCP 1.2.1 组成部分 Tools Resources Prompts 1.2.2 协议 stdio SSE(已废弃) Streamable HTTP 重要说明 Streamable HTTP是有状态的(也支持无状态) 引入Mcp-Session-Id和Last-Event-ID，支持断点续传 1.2.3 调试工具 npx -y @modelcontextprotocol/inspector 1.2.4 体系中的位置 1.2.5 演示 1.3 记忆(Memory) Mem0: Building Production- Ready AI Agents with Scalable Long-Term Memory cursor也引入Memory 2. 多智能体协作 2.1 原因 2.1.1 解决 认知过载和信息过载问题 ...

1. 引言 最近萌叔拆解了几个AI应用，其中包含coze和dify创建的工作流，也包含TradingAgents。 我发现它们中都包含 1）多个智能体的协作 2）一套预定义的工作流 多个智能体的角色划分和工作流与人类团队的组织架构和工作流程高度相似。 这种现象类似于人类社会的社会化分工。 这种现象是偶然的，还是有其必然性？它对AI应用的未来发展又有着怎样的深远影响？ 2. TradingAgents中的组织架构和工作流程 下面我们以TradingAgents为例，来看看在TradingAgents中，多个智能体是如何进行协作的。 2.1 组织架构 上图展示了TradingAgents的组织架构，其中每个角色都有明确的职责，并通过协作完成复杂的交易任务。 2.2 工作流程 可以明显想到组织架构和工作流程是必须配合使用的，单独存在并没有什么意义。 我们来看看整个工作流程 1)分析师（市场分析师，社交媒体分析师，新闻分析师，基本面分析师）进行信息收集 2)收集的信息交给研究员团队(看涨研究员，看跌研究员) 进行研究 3)研究经理针对研究员的辩论结果进行总结，得出研究报告 4)交易员针对研究报告，制定交易计划 5)交易计划提交给风险管理团队(激进分析师，保守分析师、中性分析师)进行风险评估 6)风险裁判针对风险分析师的辩论结果做出最终决策。 整个工作流中出现了13种不同的角色，角色使用langchain进行定义， 工作流使用langgraph定义。 注意：langgraph 是有向图，但是其中可能是有环的。 通过上述对TradingAgents的分析，我们可以看到多智能体协作的复杂性和有效性。 那么，这种现象背后的原因是什么呢？ 3. 推测的原因 萌叔推测可能有2个原因，导致AI应用中不自觉的出现了社会化分工，以及多智能体的协作。 3.1 克服 认知过载 目前主流的大型语言模型都是基于深度神经网络构建的，类似于隐马尔科夫链，模型是依据输入token，从统计学的角度来“预测”输出。 模型输出结果的准确性和输入token的数量大致符合下面的图 这里输入token的数量 其实反应的是某种限定性。 1) 第1阶段 随着输入token数量的增加，准确率越来越高 2) 第2阶段 准确率达到模型的最佳效果 3) 第3阶段 随着输入token数量的增加，准确率反而开始下降 举个示例 想想一个场景，你打算让AI画一幅画。(图片由豆包生成) a) 少量限定词 请帮我画一个动物。 由于没有足够的限定，随机性太强，AI画出来的可能是狗、兔子、鹦鹉… b) 进一步，你修改提示词 请帮画一只狗，狗是一只棕色的泰迪。它正在撕咬一个黄色的拖鞋。 显然这一次，结果是明确的了。 c) 进一步，增加输入 请帮画一只狗，狗是一只棕色的泰迪。它正在撕咬一个黄色的拖鞋。拖鞋上有米奇和米妮在跳舞。 上面的图，图2和图4已经出现了逻辑错误。原因是AI错误的理解我的意图。 上面的例子可能不算特别的恰当，但是过多的输入确实引入更多的不确定性，整体的准确率是下降的。 另外更多的输入，还可能导致选择性的遗忘。 就好比，你向家中幼小的孩子交代要去超市购买一系列的商品，那么当他兴致勃勃的回到家中时， 你会发现总有那么几样商品会被遗漏。并且我的实践表明，越是智商高的模型，遗忘的概率越低， 比如ChatGPT 4的表现就要优于ChatGPT 3.5。 ...

1.简介 请注意，这里的ReAct并非指前端开发框架react，而是由reasoning（推理）和acting（行动）两个英文单词组合而成的术语。ReAct是一种创新的通用框架， 它将语言模型中的推理与行动相结合，旨在高效解决各类复杂的语言推理及决策任务。 2. ReAct实际过程 while 未达成目标 { // 1. 调用LLM进行推理 reasoning(); // 2. 调用外部工具采取行动，并将行动结果，放入与LLM交互的上下文中，作为LLM推理的素材 acting(); } 其本质是执行多轮 reasoning + acting，把acting的结果放入与LLM交互的上下文中，作为LLM下一轮推理的素材 ReAct克服了链式思考推理中普遍存在的幻觉和错误传播问题，生成了更具可解释性的类似人类思考过程的任务解决轨迹， 并能够提高大型语言模型在多种任务上的准确性。 3. 示例 3.1 迷宫说明 为了说明ReAct框架，萌叔构建了一个迷宫 🧱🧱🧱🧱🧱🧱🧱 🧱😎🛣️🧱🧱🧱🧱 🧱🧱🛣️🛣️🛣️🧱🧱 🧱🧱🧱🧱🛣️🧱🧱 🧱🧱🛣️🛣️🛣🧱🧱 🧱🧱🧱🧱🛣️🏁🧱 🧱🧱🧱🧱🧱🧱🧱 player当前的位置是(1,1), 终点的位置为(5,5) 每次可以移动一步，只能是下面4种动作之一 (1, 0) (0, 1) (-1, 0) (0, -1) 限制 player的视野是有限的，仅能观察到其周围的局部区域。 形如 🧱🧱🧱🏿🏿🏿🏿 🧱😎🛣️🏿🏿🏿🏿 🧱🧱🛣️🏿🏿🏿🏿 🏿🏿🏿🏿🏿🏿🏿 🏿🏿🏿🏿🏿🏿🏿 🏿🏿🏿🏿🏿🏿🏿 🏿🏿🏿🏿🏿🏿🏿 正因视野受限，player在迷宫中的行进过程只能是探索式的： 每走一步，便观察一下周围环境，再据此尝试下一步的行动，如此反复，直至抵达终点。 3.2 代码片段 完整代码 example # 初始化 Kimi 模型 llm = ChatOpenAI( model_name="gpt-3.5-turbo", # 或其他 Kimi 模型名 # openai_api_base=kimi_api_base, temperature=0.1 ) agent = initialize_agent( tools=[move_tool, observe_tool], # 工具列表 llm=llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, # 指定智能体类型 max_iterations = 200, verbose=True # verbose=True 可以打印出详细的推理过程 ) # 3. 运行智能体 - 使用新的invoke方法 question = """ 你作为player当前处于一个 7*7的 二维矩阵中，'X'是你的位置，'#' 都是墙体，只有 '0' 是通道， '-' 表示未知 初始坐标为(1，1)，你需要设法到达(5，5) 注意: 只能沿着通道移动 你每次可以移动一步，只能是下面4种动作之一 (1, 0), (0, 1), (-1, 0), (0, -1) 请你给出一个完整的移动轨迹，如果可以尝试推测一下矩阵的情况 """ response = agent.invoke({"input": question}) print(response) 注意: 复杂的任务可能需要修改 max_iterations ...

1.引言 2025年1月我曾经发起了一个投票预测TikTok在美国的前景。下面是当时投票结果。 只能说大多数时候真理掌握在大多数人手中，TikTok美国的结局和大家预测的完全一致。 美国总统特朗普周四（26日）签署行政命令，正式批准TikTok在美业务的重组交易，允许该短视频平台继续在美国运营，同时符合美国国家安全法规的要求。根据交易条款，TikTok美国业务将由新成立的合资公司接管，而中国母公司字节跳动的持股比例将降至20%以下，以避免被视为完全由中国企业控制。 据CNBC引述消息指出，美国软件巨头甲骨文（Oracle）、私募基金Silver Lake，以及阿布扎比主权基金支持的MGX，将共同投资TikTok美国业务，合计持股约45%。字节跳动则保留19.9%的股份，其余35%股权由字节跳动的现有投资者持有，包括红杉资本、泛大西洋投资等机构。 根据协议，TikTok美国业务将由新成立的合资公司独立运营，甲骨文将负责数据托管，以确保美国用户信息不流向中国。这项安排旨在缓解美国政府对数据安全的疑虑，并符合《保护美国人数据免受外国对手侵害法案》（Protecting Americans’ Data from Foreign Adversaries Act）的要求。 2. TikTok美国的重组方案不是“云上德州” 按照当前媒体公布的股权结构，字节跳动的持股比例将从39.1%下降到19.9%，控制力进一步减弱。 甲骨文继续负责数据托管。 3. TikTok美国的股权重组真的是因为数据安全吗？ 其实TikTok为了能够在海外运营，之前已经做了大量的合规工作。 数据合规措施 1) 数据存储与访问管理 2022年，TikTok成立了TikTok美国数据安全公司（TikTok U.S. Data Security Inc.），实施技术和运营保障措施。 美国用户的受保护数据默认存储于甲骨文的云服务器上，仅受批准的TikTok美国数据安全公司人员可访问。 2) 第三方代码审查 甲骨文在内的第三方已对TikTok进行了两年的代码审查，确保TikTok数据安全。 3) 透明度中心 2020年3月，TikTok建立了“透明度和问责中心”（Transparency and Accountability Center），并发布《透明度报告》。 受邀访客可以在这里参观TikTok的内容审核后台系统，看到APP的一些代码及其他数据管理操作。 4) 数据本地化存储 2025年2月，TikTok正式启用全新“数据本地化存储”方案，所有欧洲用户数据将完全迁移至爱尔兰与挪威的专属数据中心，并由第三方独立机构监督数据访问权限。 5) 用户控制权 TikTok赋予用户对自己数据的控制权。用户可以访问自己的个人资料，查看、编辑或删除个人信息。 6) 未成年人保护 针对未成年人用户，TikTok实施了更为严格的数据保护政策。平台限制了对未成年人数据的收集，并提供了家长控制功能，允许家长监督和管理孩子的账户活动。 TikTok美国股权重组之前和之后用户数据都是由甲骨文托管，怎么之前就不安全，重组完成之后就安全了？股权重组之前和股权重组之后的甲骨文是2个不同的甲骨文？ 4.总结 我更愿意用一个形象的小故事来形容TikTok美国股权重组的性质。 ① 旧社会的时候，你是一个外地来的生意人，在某条街上开了一间包子铺，客人盈门，生意很好。 ② 这时候街面上的混混出来了，跟你说“生意不错嘛？让我也入一股，有钱大家赚嘛” ③ 你不愿意，然后各种流言就起来了，什么“包子铺不卫生，肉都是馊的”，连卫生部门频繁来检查了。 ④ 没办法，强龙不压地头蛇，你只能让混混入股。 ⑤ 各种流言自动消失了，卫生部门也不来检查了。 好吧，股权重组之后。大家就都是自己人了。TikTok应该能够美国安心的运营下去了。 这应该算是众多结局中，最好的一个了吧。

1.引言 最近有一个很火的开源项目小智机器人-xiaozhi-esp32。 类似于小度音箱和小爱音箱，你可以和小智进行语音沟通，但是小智的服务端对接了大模型（千问、DeepSeek等）。 所以它是一个智能体，可以和用户进行更丰富和有趣的对话。 2.特点 2.1 开源MIT协议，可以用于商用 2.2 支持语音唤醒 需要特定硬件 2.3 基于流式 ASR + LLM + TTS 架构的语音交互 2.4 OLED / LCD 显示屏，支持表情显示 2.5 设备端为ESP32-C3、ESP32-S3、ESP32-P4 芯片平台 价格低廉(最便宜大概50元左右，一般情况小于200元) 立创开发板 立创的这块开发板还带有摄像头，也就是说可以进行图像识别。爱动手的可以买元器件自己装，懒人可以直接在淘宝和京东上买成品。 2.6 后端也有开源实现 xinnan-tech/xiaozhi-esp32-server Python 服务器 joey-zhou/xiaozhi-esp32-server-java Java 服务器 AnimeAIChat/xiaozhi-server-go Golang 服务器 其实虾哥的版本，只开源了客户端和通讯协议，Server的实现都来自第三方 2.7 支持MCP扩展大模型能力 可以实现智能家居控制、PC桌面操作、知识搜索、邮件收发等 小智原生已经带有播放音乐、天气预报、新闻等功能 为了将MCP服务接入小智，萌叔开发了 vearne/xiaozhi-mcp-pipe，欢迎使用。 2.8 有记忆功能 参考 mem0 和 mem0-research 3. 原理&技术 3.1 原理 ESP32芯片的性能非常弱，几百MHz，<1MB的内存，因此几乎所有的功能都是在服务端实现的。 1）【Client】ESP32硬件通过麦克风采集原始音频数据，通过Websocket协议传到Server 2）【Server】对音频数据进行语音识别，转换为文字 3）【Server】使用文字与大模型进行交互，得到回答(文字)，回答可能包含指令(控制与之连接的其他外围设备或IoT设备,例如智能灯泡、传感器等) 4）【Server】文字通过TTS转成音频数据，通过Websocket协议再发到ESP32硬件 5）【Client】ESP32硬件通过扬声器播放给用户 3.2 技术 以xinnan-tech/xiaozhi-esp32-server为例说明 LLM 语言模型 使用方式 支持平台 免费平台 openai 接口调用 阿里百炼、火山引擎豆包、深度求索、智谱ChatGLM、Gemini 智谱ChatGLM、Gemini ollama 接口调用 Ollama - dify 接口调用 Dify - fastgpt 接口调用 Fastgpt - coze 接口调用 Coze - 实际上，任何支持 openai 接口调用的 LLM 均可接入使用。 ...