所有的文章会迁移到微信公众号，如果对我的文章和分享感兴趣的可以关注一下我的公众号，后续的文章会同步在公众号中分享和发表。

再次感谢大家的关注，谢谢！

coze 工作流的原理与发展趋势

Coze 工作流：概念与原理

概念定位

• Coze 是一个 AI 智能体 / Agent 开发平台，将大语言模型、插件、记忆、知识库、代码节点等能力整合起来。
• 在该平台中，“工作流”（workflow）是用于把多个能力模块（如插件、LLM、代码、判断条件、知识库等）以可视化的节点方式组合起来，形成一个有控制逻辑、有数据流转、可执行的业务流程。
• 工作流可以看作是“业务逻辑编排层”，在 Bot / Agent 接收输入之后，根据需要调用工作流来完成具体的功能。Chatflow（聊天流程）可以被视为一种有专门交互流程的工作流。

Mysql8.0介绍

MySQL 8.0 是 Oracle 公司在 2018 年正式发布的主流开源关系型数据库版本，相比 5.7 有 跨时代的改进。它在性能、可扩展性、安全性、JSON 处理、事务特性以及可观测性等方面都做了很大升级，目前已成为互联网、金融、电商等领域最常用的数据库之一。

大模型私有化部署的意义、场景与整体流程

为什么要进行大模型私有化部署？

当前大语言模型（LLMs）如 ChatGPT、DeepSeek、Qwen、Claude 等迅速发展，在自然语言处理、知识问答、代码生成、办公助手等方面展现出强大能力。然而，很多企业、高校和组织在应用这些模型时，会面临以下问题：

1. 数据隐私与安全
   • 对话内容、业务数据传输至公有云存在泄密风险。
   • 合规要求限制外部数据传输（如《数据安全法》《个人信息保护法》）。
2. 稳定性与成本控制
   • 公有 API 的调用成本昂贵，且调用次数或速率受限。
   • 外部模型可能因网络波动、访问限制而无法使用。
3. 对边缘计算和本地部署的需求
   • 一些工业、政务、医疗等场景下只能部署在本地或内网。

因此，大模型私有化部署应运而生：将开源模型部署在本地服务器、GPU 算力平台、云原生平台或边缘设备中，构建独立的智能服务系统。

项目介绍

本项目旨在构建一个“语音驱动的数字人”，通过语音识别、自然语言理解与语音合成，实现与用户的自然对话交互。用户只需对着麦克风说话，系统即可自动识别语音内容，通过大语言模型生成回答，并将结果实时语音播放，提供类人对话体验。

核心流程如下：

1. 用户说话
2. Whisper 识别语音转文本（ASR）
3. 使用 Ollama 本地大模型理解/回答问题（LLM）
4. 使用 EdgeTTS 语音合成回答内容（TTS）
5. 播放生成的语音回应

该系统适用于智能助手、教育机器人、客户服务等场景，支持本地部署，保障数据安全与响应速度。

随着人工智能（AI）技术的迅猛发展，AI助手与应用程序之间的高效通信变得尤为重要。模型上下文协议（Model Context Protocol，简称MCP）应运而生，旨在为大型语言模型（LLMs）与外部数据源和工具之间提供标准化的接口。在MCP的众多特性中，Streamable HTTP传输机制作为一种现代化的通信方式，正在逐渐取代传统的Server-Sent Events（SSE）传输方式，成为AI通信的新标准。

今天，Cursor 官方宣布了一个好消息。Cursor 现在对学生免费开放一年。

这一消息就像一颗石子投入平静的湖面，在编程教育领域激起了层层涟漪。Cursor这么做，就是为了让学生们能更轻松地用上AI编程工具，给编程教育和创新发展添把火。

大模型原生支持MCP协议是什么意思？

在前面的文章中，我们一起从零开始搭建了适配所有大模型的MCP Client，无论我们选择什么大模型，都可以完成MCP工具的调用。由于我们实现的方式是通过在系统提示词中对大模型的输出内容进行限制，并强制规范了大模型的输出结果，当大模型要进行工具调用时，我们利用提示词要求大模型按照MCP协议输出对应的规范化结果。这样做虽然降低了我们大模型的选择门槛，但是同样会带来一些问题，其中最突出的一个问题就是，一但大模型没有按照MCP协议的要求输出规范化的结果，那么就会导致MCP工具调用失败，正是由于这种不确定性的存在，导致很多企业不放心真正在生产中去使用MCP相关工具，仍然停留在测试环节中。

随着大型语言模型（LLM）的进一步发展，大模型对于MCP协议的支持度，也成为了消费者在选择大模型的上的一个参考标准。大模型“原生支持MCP协议”意味着该模型自身具备内置的、遵循 MCP（Model Context Protocol，模型上下文协议）规范的能力，无需额外的适配层或中间件，就能直接与各种数据源、工具和服务进行双向、安全、高效的通信。这样的原生支持不仅提升了模型在调用外部接口时的速度和稳定性，也简化了开发者的集成工作，让模型与应用间的交互如同“开箱即用”般流畅。

说得通俗一点，原生支持MCP协议的大模型，就是模型在微调阶段，使用了MCP协议相关的数据对模型进行过微调，使得大模型原生就知道MCP协议的规范，那么在调用MCP工具时，大大降低大模型出错的可能性。

背景介绍

在当前大模型蓬勃发展的背景下，专为大模型调用设计的”API工具”——MCP，已成为研究领域的焦点。在之前的两个教程中，我们从零开始指导大家实现了MCP Server和MCP Client。通过这个过程，相信大家已经意识到MCP Server本质上是为大模型提供的一种格式化API接口。

说到这里，很多同学可能会思考：市场上已有海量API资源，但它们大多未被转化为MCP格式。如果想调用这些API，还需要重新编写一遍，确实比较繁琐。那么，有没有一种工具能够将我们现有的API一键转换为MCP格式呢？

答案是肯定的。今天我们要向大家介绍的正是这样一个项目——FastAPI-MCP。该项目实现了从FastAPI到MCP Server的无缝转换，让我们之前使用FastAPI开发的接口能够轻松转化为MCP Server，供大模型直接调用，大大提高了开发效率。

FastAPI-MCP项目地址：https://github.com/tadata-org/fastapi_mcp

什么是MCP-Client？

MCP-Client是Model Context Protocol（模型上下文协议）架构中的一个重要组件，用于连接AI模型（如Claude、GPT等大型语言模型）与外部数据源、工具和服务的桥梁。

MCP（Model Context Protocol）是由Anthropic公司在2024年底首次提出并开源的一种开放标准协议，旨在解决大语言模型（LLM）与外部世界的连接问题。这一协议的核心价值在于打破了AI模型的”信息孤岛”限制，使模型能够以标准化的方式访问和处理实时数据，显著扩展了大模型的应用场景。

在MCP架构中，有三个关键组件：

1. MCP服务器（Server）：轻量级服务程序，负责对接具体数据源或工具（如数据库、API等），并按照MCP规范提供标准化的功能接口。每个MCP服务器封装了特定的能力，如文件检索、数据库查询等。
2. MCP客户端（Client）：嵌入在AI应用中的连接器，与MCP服务器建立一对一连接，充当模型与服务器之间的桥梁。它负责发现可用服务、发送调用请求、获取结果，并将这些信息传递给AI模型。
3. 宿主应用（Host）：运行LLM的应用程序或环境，如Claude桌面应用、Cursor IDE等。宿主通过集成MCP客户端，使其内部的模型能够调用外部MCP服务器的能力。

MCP-Client的工作原理是基于JSON-RPC 2.0协议，通过标准化的接口与MCP服务器进行通信。它能够自动发现可用的MCP服务器及其提供的工具，并将这些信息以结构化的方式提供给大语言模型，使模型能够理解可用的工具及其功能，从而根据用户需求决定何时何地调用这些工具。