课代表立正的官方Podcast
深度访谈,有用干货,亲身验证的「真本事」
Superlinear Academy创始人,Maven Top AI Instructor
前Statsig布道师(OpenAI收购),腾讯副总监,Meta,Amazon;康奈尔经济学博士
社区:Superlinear.Academy
课程:ai-builders.com
个人:lizheng.ai
MCP MCP
server MCP
server. Awesome MCP servers.
Ripple MCP
servers. MCP.
AI
agent autogench
MCP MCP server.
for
desktop. Anthropic
Fore matrix.
Foreign speech. Foreign speech.
YouTube
MCP model context
protocol
MCP opens
GPTS GP
store GPT
plugin MCP
RMCP MCP server.
AI
agents, AI agents,
contact MCP.
MCP server.
cursor
versus anti patent.
Fascinating. MC MCP
server. MCP
server.
Right. Distraction.
The AI agents
are
framework. Paradigm shift.
learn. AI
agents
agents design philosophy.
Design
philosophy
agent framework
The philosophy design
pattern
framework
framework framework.
and learn.
Learn office
hour.
MCP I think we also promised to teach
MCP server or talk about that. Yeah,
that's a very good question. In order to
answer this question, we need to think
about like why why is there such a thing
of MCP? Um, if you do agent development,
you will soon notice that different AIs
actually have different interfaces. For
example, for OpenAI, they expect some
JSON like language. Probably I can do a
live demo here.
Um, if you go to a platform OpenAI,
there is also something called a
playground. In the playground, you can
um plug in a lot of different things
directly interact with their model. For
example, this is GBD40. You can just say
hello GD40 will say, "Hi there, how can
I assist you today?" In addition to
general text prompt, you could also make
it uh let's make it a chat information
API. And there's something called
functions. This is how you specify a
tool to open AI. It's a JSON. It has the
name, description, parameters of the
tools so that the the GPT knows how to
invoke that. More specifically, uh we
can oh I can examples get weather. Okay,
for example, we could get it give it a
tool called get weather and press save.
Uh, it's nothing more than get some the
weather from a certain location and then
you can ask it what's the weather like
in
Seattle. Then the output it produces a
it's a special type of of message or or
response. Specifically, it's a function
call. It's it's the name is get weather.
It has two parameters which we described
here. It expects to uh we expect to
receive two parameters for the tool
which is called location and unit. And
here it is specify location as Seattle
WA and unit at Fahrenheit. Then what we
will do in the real production is we
will call some get weather API but here
we'll skip this step and uh directly say
uh Seattle is 300 degrees uh and submit.
So and then uh the genai will take this
and generate some new pro some new
responses based on that uh temperature
300 fah seems unusually high maybe
incorrect verify an estimation. So this
is this is essentially how we build a
genetic AI. It's that simple.
is nothing more than you give the
AI
a some some spec of a tool or a set of
tools. Then AI decides which tool to
call and which which parameter to put in
and then you call the tool for the AI
and put back the
response. Imagine this could be say save
some content to a file or run some
command and that's cursor. So this is
the the general foundation of how you
would build an engineer AI. And then the
moment you you begin trying to build for
different AIs, you will find a problem
here. This is the the format for open
AI. A cloud has a different format for
like
anopic. Gemini has entirely different
format as well. So it's really
miserable. It's pretty much like the pre
USB um pre- USB era. You have all the
different kind of ports. PS2 port,
firewire port, all different kinds of
ports and it's you need to make for in
order to onboard every new AI you need
to make a new port and new abstraction
layer and that's why people are
desperate about having something like
MCP is a protocol pretty much like a USB
for for the the standard and I want to
say that MCP is not the earliest or the
best. Um there are a bunch of efforts
even before MCP. OpenAI has something
called OpenAI plugin. It's a lot like
MCP but it already got killed. It wasn't
it was rolled out like two years ago and
people were not really a fan of it
because of some limitations. And we also
have Pantic that that famous Python data
library. it use some Python decorator
try to um encapsulate this abstraction
and in the back end it communicate with
all different kinds of AIS. We also have
some uh lchain lchain also have its own
version of MCP and Anthropic has MCP. If
we step back and think about what would
make a library successful in this we
would think about several several
criteria. It has to be abstract. That's
the major motivation so that I could
implement once wrong everywhere. That's
important. It shouldn't be over abstract
because if you use land chain or similar
l graph you will know over extraction is
a main pain point. If you want to change
something you need to track it down into
like 800 different abstract classes and
finally make figure out where to make
the change. And it needs to have some
kind of um expressiveness so that you
don't you have all the major needs
captured by the library and don't need
to switch to different libraries for
different features and it also needs to
have good debugability. That's very
important because in the case that your
debugging is usually more time consuming
compared with development. So that's
that's the important part. If you really
take a look at all the current options
around those four dimensions, you will
notice that there are no perfect
solution like pi pitantic uh it's easy
to debug. It's nothing more than python.
But it's not very general. It's not very
expressive. What if I use moodjs? I
don't use python. What shall I do? And
uh tragt's plugin is very closed. It's
it's not open standard that's supported
by everyone. That's also its drawback.
MCP is like in the sweet spot. It it's
it's not over abstracted. It's somehow
abstracted. It's expressive, although
sometimes it's a bit more too heavy. Uh
but it doesn't really have too big too
good debugability. So that's the that's
the the location in ecosystem of MCP
about why and what it is. So why MCP
succeeded or is succeeding? This is
because there is no perfect technical
solution yet and everyone in the market
is not perfect. MCP is one of them. But
the unique part of MCP is it's backed by
an experienced
um I would say company like
Anthropic and so people have confidence
that oh it will have it will be
insightful for future will be reliable
there will be consistent investment in
this project. So people are more
confident on that and they're gradually
getting some competitive advantage in
this market. That's that's basically it.
But MCP is nothing more than a protocol.
When we talk about MCP is pretty much
like uh it's it's it doesn't really have
anything to do with the features. So
when we when we talk about uh adding
some new features to cursor, it could be
done by natural language actually. So
here how we add this search engine
cursor is we ask the cursor to write
this 100 line command line utility for
duck.go code API is a Python program and
then in cursor's prompt we just teach it
using natural language about how to use
this tool for example uh I think it
should be here search engine you could
use this to f to search the web and this
is a command line and this is the
example output it's it's nothing more
than this so compared with MCP this kind
of development is as you can see here is
much more efficient it's very agile
because for MCP you need to set up the
client set up the uh set up the the
server you need to hook them up using
some certain protocol and you need to uh
using some SDK for example it's very
heavy duty this is uh this is factor one
factor two is it's also very hard to
debug in the case that oh my search
engine has some issues it crashes it's
nothing more than a Python script cursor
would easily do the job for me do the
trick for me debug it out but MCP is
also it's it's a micros service pretty
much like microser it server and a
separate client you need to have
visibility on both sides and the
communicating using some some uh JSON
RPC very heavy and even with the
inspector MCP does provide an inspector
for for the ease of debugging even with
it it's still ah sometimes a nightmare
to debug uh anyone with like microser
debugging experience easy to understand
that so essentially my take on MCP is
MCP is is good for um distribution For
example, in cursor, if you want to use
some MCP, you can add it here. It's just
a oneliner. Then you get access to some
certain tools, but it's not good for
development. And here, our approach
using natural language and Python
scripts are good for fast iteration. You
probe the MC uh the MVP, you figure out
customer like it, but it's it's bad for
distribution because you need to ask the
users to download this, download that,
put it in some certain location. It's
troublesome. So my suggestion for cursor
specific is MCB development is agent
development is you got uh the you use
this kind of command line with natural
language to fast iterate and after you
figure out u oh this is good I want
distribute it then use MCP to distribute
it that's my suggestion for cursor
specific and for MCP per se it has
nothing to do with the actual features
it's just the one potential way uh to or
a a protocol
to ease the distribution. That's my
take. All right. And let's take a look
at the questions. Uh AI soft skills,
reasoning tools, hard skills, reading,
GitHub, knowledge, memory,
information.
[Music]
Um yeah, I think YZ already replied
that. We also had a quite in-depth
discussion our agent AI course which
everyone has free access to. MCP is an
API spec. We still need to build our own
function. Exactly. Yes, it's nothing
more than m API spec. You still need to
build your own functions. Uh it's based
on JSON RPC. That's pretty similar with
JSON RPC. You can use JSON RPC as the
protocol, but you still need do the
heavy lifting to implement the core
function. Any MCP platform has reliable
MCP ready to use. There are so when we
talk about MCP, we need to distinguish
between MCP server and MCP client. The
Sukon MCP server is an it's pretty much
like a agent. You could connect to it.
Uh it's like a server on the internet.
You could you could treat it as an API
server. Uh then you connect to it, ask
it questions, send it out requests, then
it's able to give you the responses.
This is called MCB server. There's also
something called MCB client. It's like
claw desktop. That's an MCP client. Uh
cursor, that's MCP client. So for MCP
client my general recommendation is
cloud desktop. It had it seems to have
the best support. Cursor according to my
experience it doesn't support MCP too
well. Actually if you take a look at
their release uh release log they had a
lot of bug fixes about MCP and I often
got all the weird uh bugs around MCP and
cursor here and there. So I don't
recommend cursor at least it's current
version for a reliable MCP platform or
MCP client and for the MCP server there
is something called awesome MCP servers
you can take a look at this GitHub it's
it's nothing more than a markdown file
um feel free to check it out there this
a set of all the different MCP resources
not necessarily very good ones but
hopefully that will be inspire inspiring
for you I think maybe a good place to
talk about why we don't teach any
specific framework.
Um for agenti framework uh yes it's it
might be a the principle behind it. Yes,
actually we don't talk about a lot of
things. We actually just explain why we
didn't talk about M teach about MCP
because it's there are a lot of
uncertainties and it's has nothing to do
with the core functionality and we also
didn't talk about regular augmented
generation. The reason is it it's like a
short-term solution. uh as long as we
have better long context AI which is
happening and agentic AI which
fundamentally changes the fixed workflow
we don't need that and we also don't
teach about specific framework of
agentic AI for example autogen or small
agent uh although it gets asked a lot by
our students and there's a reason for
that uh there are the reason is we are
in a
specific specific
um like uh time of the agentic AI that
is developing too fast. When we talk
about adopting some framework, we are t
we are not only using a set of utility
functions. We are trying to adopt its
own perspectives. Let's take several
examples for autogen from Microsoft.
It's a very classical multi- aent
framework for building a but it
basically formulates everything the
agents the interaction between agents as
a synchronous messagebased
communication. That's a big assumption.
So you you need to have like a popsub uh
that kind of
framework. If you really like this kind
of framework like you you share this
perspective, you believe in this
formulation, you will use it very
happily. But if you don't like it, it
will be very miserable. You will need to
have a lot of heavy customization on the
library to make it work. Similarly, um
small agent from hugging face assumes
that every single agent is a coding
agent. If you like it, you believe in
it, you will be happy. If you don't
believe in it, you will be miserable.
Uh, and land chain, land graph assumes
that everything like the interaction
between agents could be formulated as a
graph. And obviously it's not true.
That's the reason why they invented
something like dynamic graph,
conditional age, a lot of patches. So if
you like this D viewpoint, you again you
will be happy. If you don't like it, you
will be miserable. So when we use some
framework or library it's more than
adopting their functions it's like
adopting their perspective on the future
of engineic AI and now because agentic
AI is is developing so fast it's totally
possible that tomorrow there will be a
recognition revolution and we need to
shift to another perspective of AI
that's totally possible in the case that
you make too big commitment to a certain
perspective it will be very hard for you
to change everything and onboard board
another platform. Think about if you
previously use small agent and you try
to onboard on board I don't know L land
lang graph how troublesome that is and
so at least in this stage I think this
is more important to keep our
flexibility compared with oh having that
the small improvement on the development
productivity especially considering AI
assisted development is so popular for
now having a certain level of library
functions probably is not that
beneficial for you that's the the
inherent logic of why we didn't teach
all this probably in a few years we can
we can teach so but now it's not good
timing and I I want to call out the
unlearn right in the first uh session we
talk about the paradigm shift it's not
because paradigm shift is cool but uh
there are certain challenges in paradigm
shift especially for people who have
development experiences
uh to unlearn right to uh remove like
what do you think is the best practices
like going to a framework is a typical
kind of best practice uh when you were
learning the last generation uh
programming or development and you
naturally assume that is the best way to
learn generative AI you have to
challenge that assumption and really go
back to the p first principles and think
about why you learned framework in the
first place that does that still apply
in the age of AI we are giving you the
answer by saying you know it doesn't
matter
But that is our opinion. So develop your
own opinion and apply your own critical
think critical thinking. And u yeah but
I I do want to call out that we have to
unlearn a lot of things. Uh Yen
summarized this as being flexible but I
think there the unlearn comes before
that because Yen already unlearned a lot
of things. He has the habit of uh
thinking from the first principle but
most of us do not. So we have to
remember that we have to you know
challenge the best practices.
Yeah, that's a good quote. I really like
the on perspective.