MCP一周年——与David Soria Parra及来自OpenAI、Goose、Linux基金会的AAIF领导者们

你实际上所做的，就是这种组合性——模型本来就会通过调用工具A，获取结果，再回到推理过程调用工具B，然后将结果合并为调用C。

And what you're effectively doing is this composability that the the model would have done anyway by, like, call tool a, you know, get the result, go back to inference to call bool b, and then combine it into call three.

你现在所做的，只是让模型提前优化，把它们变成一系列代码，在沙箱中执行：调用一，把结果传给二，再传给三，得到最终结果，归根结底，你只是做了一次优化。

Now you all you've done is you let the model optimise it in advance and put them into a bunch of code that is just executed in a sandbox and go, like, call one, put it into two, put the results into three, get a result, and all you've done is an optimization at the end of the day.

但MTP的好处在于，它为你完成了身份验证，提供了适合LLM的工具，并且自动可发现、自文档化。

But the the benefits of MTP of having authentication done for you, having something that is that is suited for the LLM, something that is automatically is discoverable and self documenting.

这一点并没有消失。

This thing has not gone away.

这对你来说仍然是MCP。

That's still MCP for you.

对吧？

Right?

你只是以不同的频率在使用它。

You're just using it at a different rate.

所以每当有人跟我说‘但MCPs，为什么它告诉我这个不行’，我就有点困惑，这并不意味着你不能用MCPs。

So I'm always a little bit confused when people go like, but MCPs, why why does it tell me that that that does not that doesn't mean MCPs use it.

不。

No.

这仍然只是不同的用法。

It's still it's just a different use.

对吧？

Right?

随着我们对这些模型及其周边基础设施的使用越来越熟练，我认为你会看到一些演变。

And I think you will see evolutions as we're getting better of, like, how we use these models and the infrastructure around it gets a bit more mature.

你突然可以假设，大多数AI应用都会具备某种形式的执行沙箱。

You suddenly can assume that most model, like, AI applications will have some form of, like, sandboxing for execution.

你可以做更多类似这样有趣的事情。

You can do a lot more fun stuff like that.

但我认为，连接模型与外部世界的协议的价值并没有因此消失，如果这说得通的话。

But I don't think that the value of, like, an a protocol that connects the model to the outside world is is gone because of it, if that makes sense.

老实说，我只把它看作一种优化，一种令牌优化。

I see it purely as an optimization, honestly, a token optimization.

现在是提出技能的好时机吗？

Is this a good time to bring up skills?

任何时候都是。

It's Always.

太棒了。

So awesome.

所以，技能是一个更近期的概念。

So we skills is a more recent concept.

是的。

Yeah.

我之所以提到它，是因为在我的脑海中，它与渐进式披露、添加预设代码脚本等紧密关联。

We I only bring it up because it's mentally linked in my mind to progressive disclosure and to adding preset code scripts and and all that.

技能还可以创建技能，这非常有趣。

Skills can also create Skills, which is very fun.

是的。

Yeah.

嗯，我觉得很多人在试图区分MCP和技能。

Well, I think a lot of people are trying to place MCP versus Skills.

显然，它们并不重叠，但你怎么看？

Obviously, they're not overlapping, but how do you view it?

是的。

Yeah.

我同意。

I agree.

我觉得这才是有趣的部分。

I I think that's the interesting part.

它们并不重叠。

It's like, they're not overlapping.

我认为它们解决的是不同的问题。

I think they they solve different things.

我觉得技能非常棒，而且你知道，它们从一开始就基于渐进式发现的原则来构建。

I think Skills are super great, And, you know, they're I think that the first that really, like they're being built from the principle is progressive discovery.

但我认为，渐进式发现的机制是适用于你用模型做的任何事情的普遍原理。

But I think the mechanism of progressive discovery, that's just universal to any type of thing you can do with the model.

而技能的作用是为你提供特定任务集的领域知识，比如作为数据科学家，模型应该如何表现，或者作为会计师，模型又该如何表现，等等。

But what skills do, they, like, they give you the domain knowledge for, like, a specific set of tasks, like, how you are, how you behave, how should the model behave as a data scientist, or how should the model this behave as, I don't an accountant or whatever.

但MCP让你能够连接起与外部世界交互的实际操作。

But MCP gives you the connectiveness of the actual actions that you can take with the outside world.

因此，我认为它们在某种程度上是正交的：技能主要提供这种垂直的领域知识，而MCP则提供这种横向的能力——比如，给我那个具体的动作。

And so I think they're somewhat orthogonal in, like, in terms of, like, the skills really gives you this domain knowledge that's, like, kind of vertical, and then, like, MCP gives you this horizontal of, like, okay, you know, give me that one action.

当然，技能也可以执行操作。

And of course, skills can take actions.

它们可以执行操作，因为你可以在其中加入代码和脚本。

They can take actions because you can have code and scripts in there.

这很棒，但它有两个我認為人們忽略了的有趣方面。

And that's great, but it has two interesting aspects that I think people got.

第一个是，你需要一个执行环境。

The first one is you need an execution environment.

所以你需要一种方式

So you need to you need to Use a way

来访问你的机器。

to access your machine.

是的。

Yeah.

对。

Yes.

如果你运行本地的云代码之类的东西，那这就完全没问题了，我们可以谈谈像命令行工具这样的东西。

And that that's that's perfectly fine for, you know, if you like run a local, like, you know, cloud code or something, then we can talk about like CLIs, for example.

在那些拥有执行环境的场景中，这些方法非常合理，而且效果很好。

In those scenarios where you have, like, an execution environment, these things make a lot of sense and and and then it's great.

或者如果你有远程执行环境，那也非常好用。

Or if you have a remote execution environment, then it make a lot of sense.

但你仍然无法获得这方面的身份验证。

But you still don't get authentication in that regard.

所以我认为NCP带来的正是身份验证这一部分。

And so what I think NCP brings is the authentication piece.

它解决了你不必让外部人员，比如你有一个Linear MCP服务器时，他们可以改进服务器的问题。

It brings the piece that you don't have to that this like, an external, like, person, like, for example, if you have, like, a linear MCP server, they can improve the server.

你在自己的技能中不需要处理这些。

You don't have to deal with that in your skill.

对吧？

Right?

它并不是固定在某个地方的。

It's not fixed in space.

第三点是，你并不一定需要执行环境，因为执行环境实际上位于服务器的其他地方。

And then the third part is that you don't necessarily need execution environment because the execution environment is effectively somewhere else on the server.

所以，如果你构建了一个网页应用或移动应用，这些功能在某些方面会表现得更好。

And so if you build a web application or a, like, like, a a mobile application, you these things come you know, work better in in some of these regards.

因此，我认为在很大程度上它们是正交的，我也见过一些非常酷的部署案例，人们使用技能来探索不同的功能，比如会计、工程师、数据科学家，然后通过MCP服务器将这些技能连接到公司内部的实际数据源。

So I think they are orthogonal in that regard for the most part, and they are and I've seen some quite cool deployments where people use skills to explore of, like, different functions, different, like, you know, the accountant, the engineer, the the data scientist, and then use MCP server to connect these skills to the actual, like, data sources within the company.

我认为这是一个非常有趣的模型，这也是我思考这个问题时最接近的方式。

And I think that's actually a really fun model, and I think that's the closest how I think about this.

对。

Yeah.

所以MCP是连接层，我想这是你选择的词。

So MCP is the connectivity layer, I think is the word that you choose.

通信层。

The communication layer.

通信层。

Communication layer.

是的。

Yeah.

对。

Yeah.

那么从架构上讲，我想知道是每个技能内部都有MCP客户端，还是有一个可以发现技能的共享客户端？

So is is it architecturally, I'm I'm wondering if it's like the MCP's client inside of each skill, or is there a shared client that can discover skills?

我们将其作为共享的。

We do that as shared.

我们将其作为一个共享的。

We do that as a shared one.

我认为从技术上讲，你希望有更多的共享组件，因为共享得越多，你能做的事情就越多，比如发现功能。

I think you technically want a bit more shared ones, because you do the more shared you have, the better the more you can do, like, discovery things.

你可以做这样的事情：比如，我有连接池，我可以自动发现服务，甚至在某个技能中，你只需非常宽松地描述你的需求，我就可以查看我有权访问的注册表，为你找到一个MCP服务器。

You can do things like, okay, I have connection pooling, I have this I can do automatic discovery of things, I can even, like, you know, in a skill you might just very loosely describe what you want, and I can look into the registry that I have access to and get an MCP server for you.

对吧？

Right?

当你这样做的时候，这些功能都是可以实现的。

These things can you do can do when you do it.

但归根结底，两种方式都可行。

But I think both works at the end of the day.

是的。

Yeah.

但这些都是值得尝试的事情。

But these this is things to experiment with.

我想提醒一下可能错过这一点的人。

I do wanna highlight for people who might have missed it.

你说我们做这个那个的。

You say we do blah blah blah.

实际上，我认为没人充分理解Anthropic的MCP有多依赖内部使用。

Actually, I think nobody understands enough how much anthropic dog food's MCP.

是的。

Yeah.

我是在看了约翰·威尔奇的演讲后才明白的。

And I only understood this when I watched John Welch do his talk

对。

Yeah.

在AIE上，他说我们有一个MCP网关，所有东西都通过它。

At AIE, where he was like, yeah, we have MCP gateway, everything goes through this.

是的。

Yeah.

而且，你能再多说一点吗？

And like well, can you say more

关于这个？

about that?

对。

Yeah.

我的意思是，你知道，我们两种都用。

Mean, like, you know, we we use both.

对吧？

Right?

我们内部用了很多技能。

We use a lot of like, we use a lot of skills internally.

我们内部用了大量的MCP服务器，因为，你知道，显然，你希望让人们能够轻松地部署MCP。

We use a lot of MCP servers internally because, like, we have you know, obviously, you know, you wanna make it very easy for people to deploy MCP.

你希望与你的身份提供商等实现某种形式的集成。

You wanna, like, have some form of, like, integration with your IDPs and so on.

所以我们自己开发了一个网关，你只需要部署你的MCP服务器即可。

So we have a gateway that we have built custom purpose for ourselves, you just gotta, like, deploy your MCP servers.

这些都是内部应用吗？

It it is all internal apps?

全是内部的东西。

It's all internal stuff.

是的。

Yeah.

对。

Yeah.

有些是外部的，比如技术上属于外部服务，但因为它们没有提供官方的一体化方案，所以我们自己做了。

Some of them are, like, external things, like like, technically external things, but in the lack of them offering a first party one, we have our own.

比如我们有一个Slack MCP服务器，我特别喜欢用，它能用Claude帮我总结Slack消息。

Like, we have a Slack MCP server, which I love to use, that have Claude, like, summarize my Slack for me.

因此，这方面有很多使用场景。

And so there there's quite a lot of usage for that.

比如，我们甚至有一个MCP服务器，用于每半年做一次调查，了解大家对公司、未来、人工智能、安全等方面的看法。

Like, we we even have, like, an MCP server where, like, we're doing, like, a semi a biannual, survey, for example, around, like, how we how we feel, like, about the company, about the future, about AI, about safety, these type of things.

我们为这个调查专门设了一个MCP服务器，大家可以根据结果提出问题，这非常有趣。

And we have an MCP server for that, and they can ask clock questions around the results, which is really fun.

是你们团队在维护吗？

Is it your team maintaining it?

不是。

No.

我们维护的是网关，但有趣的是，我们早在开源MCP之前就开始用了，MCP的诞生源于这样一个想法：我所在的公司正在疯狂扩张。

We maintain a gateway, but, like, I think one of the fun part is, like, we started MCP, it was always like, MCP before we even open sourced it, it was born of the idea of, like, I'm in a company that is growing crazy.

我负责的是开发和开发工具这一块。

I'm in the development side of things, development tooling side of things.

我的成长速度会比其他部分慢一些。

I will grow slower than the rest.

我该如何构建一个让他们都能为自己打造的东西？

How can I build something that they can all build for themselves?

这正是MCP的起源故事。

And that's really the origin story of MCP.

所以看到一年后，事情真的变成了这样，真的很有趣。

And so it's fun to see a year later, like, that's what's actually going on.

人们都在为自己构建MCP服务器。

It's like people build MCP servers for themselves.

我可能连Tropic上90%的MCP服务器都不知道，因为它们可能存在于研究领域，我根本看不到，或者我只是不知道，因为人们都在为自己构建。

I probably don't even know 90% of the MCP servers that are on Tropic, because, you know, they might be in research, and I might not even see them, or I just don't know, because people build for themselves.

但他们自己托管吗？

But do they do they host it themselves?

有远程服务吗？

Is there a remote?

他们实际上有一个命令来启动它，它就会在他们的Kinesis集群中直接启动。

They effectively have a command to launch it, and it just launches in like a like a Kinesis cluster for them.

所以这算是部分托管的。

So it's like, partially managed.

是的。

Yeah.

这对任何大型公司的人都很有参考价值。

That's good info for anyone at a large company to build.

对。

Yeah.

有没有平台相关的资料？

Any platform info

有一些平台可以为你提供这个服务。

There are platforms that offer that to you.

从安全角度来看，我们希望自己构建这些系统。

For us, from a security perspective, we wanna build these ourselves.

对。

Yeah.

但比如，构建 FastMCP 的那个人，Jeremiah，是的。

But, like, they're, like, the person who built FastMCP, Jeremiah, like Yes.

有一家公司提供 FastMCP Cloud，有点像那样。

A company that offers, like, FastMCP Cloud, which is a little bit like that.

你只要输入两个命令，就能运行一个 MCP 服务器，它可以通过 HTTP 进行流式通信。

You just, like, two commands, and you have a running instance of an MCP server that does talk stream over HTTP.

然后很多企业内部会使用 Light LLM 这样的网关，甚至可以直接启动标准 IO 服务器，将其连接到网关，由网关负责所有认证和 MCP 的复杂部分。

And then a lot of internal like, lot of enterprises use things like Light LLM as a gateway, and then they can even do, like, just launch standard IO servers, attach them to the to the gateway, and the gateway does all the authentication, all the hard parts with MCP for them.

所以实现这种方式有很多途径。

And so there's a lot of ways to do this.

但如果你真的需要这样的基础设施，那就应该让它变得极其简单。

But if that's good infrastructure you really want to have, it's just, like, make it trivial.

只需一条命令就能启动一个标准 IO 服务器的 MCP 服务，瞬间就能集成 HTTP 服务器的认证功能，而你作为开发者，只需要完成标准 IO 部分即可。

Make it, like, one command to just launch an MCP server that was a standard IO server, and suddenly, the stream of HTTP server was authentication integrated, and you as a developer only had to do the standard IO part.

是的。

Yeah.

我喜欢指出这些内容，因为人们会采纳这些做法并真正应用到他们的公司中。

I love calling that stuff out because people will take that and actually put this into their companies.

是的。

So Yeah.

否则，另一种情况就是混乱。

Otherwise, also the alternative is chaos.

哦，一个小时。

Oh, One hour.

不。

No.

你是在重新发明一切。

You're reinventing everything.

向Jeremiah致敬。

Shout out to Jeremiah.

我其实确实邀请他来举办一场关于FastMCP的工作坊，是的。

I actually I did invite him to do a workshop on FastMCP Yeah.

在我纽约的峰会上。

At my New York summit.

是的。

Yeah.

他最近发表了一篇非常棒的博客文章，谈到你实际上看到的MCP使用场景，大多发生在公司内部。

He he he recently had a very great blog post about like, a lot of the usage of MCP you're actually seeing is internal in companies.

而这也是我们目前看到的情况，真的很棒。

And that's actually what we see at the moment too, which is really cool.

哪些公司？

In what companies?

公司内部。

Internally in companies.

在大型企业中，MCP无处不在，而且它的增长速度远超你的想象，因为它主要在公司内部使用，而外界几乎看不到。

In big enterprises, you see MCP everywhere, and it's it's actually way growing way faster than you would think because it's mostly internal to companies and without people seeing it.

关于Discovery，你推出了一个注册中心。

About Discovery, so you launched a registry.

是的

Yeah.

曾经有注册公司。

There were registry companies.

曾经有网关公司。

There were gateway companies.

官方注册表现在有其他注册表将自己的MCP接入你的官方注册表。

The official registry now has other registries putting their own MCP, getting in your official registry.

我们需要更多的注册表，伙计。

We need more registries, man.

我的意思是，

I mean,

再加一个就行，兄弟。

just one more, bro.

再加一个。

One more.

就只是是的。

Just Yeah.

什么是那个

What what's the

一个统治所有的注册中心。

A registry to rule them all.

从中学到什么了吗？

Any any learning from that?

比如为一项新技术推出一个注册中心，看看人们是否喜欢，比如史密瑟里就是一个例子。

Like launching a registry for like a new technology and like whether or not, you know, people like, you know, Smithery is one example.

对吧？

Right?

如果你去官方注册表，就会看到，哦，这些史密瑟里AI是的。

If you go on the official register, it's like, oh, these Smithery AI Yeah.

你需要通过它们进行认证的MTP。

MTPs that you need to authenticate through them.

是的。

Yeah.

所以这在某种程度上就像一个简单的转发注册表。

So it's kinda like just a pass through registry in a way.

你认为这会如何发展？

How do you see how does this gonna shake out?

我认为我们看到了许多不同的注册表涌现，我们确实感到有必要采用类似 NPM 或 PyPI 的方式来处理这个问题，即有一个更中心化的实体，所有人都可以将 MCP 服务器发布到那里，这正是原始注册表的由来。

I think we saw a lot of these, like, different registries come up, and we really felt that there is a need for, basically, like an NPM PyPI kind of approach to this, where, like, there's one more central entity that that that is the where everybody can publish an MCP server to, and that's really where the original registry came from.

我们非常希望确保至少能推动生态系统形成一个关于这些注册表如何通信的共同标准。

And we really wanted to make sure that at least we're encouraging the ecosystem to have a common standard of what these registries can talk to.

因为我们希望实现的是这样一个世界：模型能够从注册表中自动选择一个 MCP 服务器，安装它，然后根据你当前的任务直接使用它。

Because what we want to do, we want to live in a world where a model can auto select an MCP server from a registry, install it, and then or the given task that you have at hand, and then you just use it.

对吧？

Right?

它应该给人一种神奇的感觉。

It should kind of feel magic.

但要做到这一点，你需要某种标准化的接口。

But for that, you need, like, some form of standardized interface.

所以我们打算这么做，这其实是我们早期就开始与GitHub团队合作的转折点，甚至早在四月份就开始了，但后来我被其他事情分散了注意力，比如身份验证和相关工作。

And so we're gonna do and that was really the the inflection point of, like, we started quite early working with the GitHub folks even in April, and then I got distracted with other things, like authentication, and work on that.

所以我希望看到的，也是我们正在缓慢走向的方向，是一个拥有官方注册中心的世界，每个人都可以把自己的MCP服务器发布到这里，但这就像NPM一样，会面临NPM完全相同的问题。

And so what I wanna see, and I think where we slow slowly, but this is slowly heading, is a world where we have the official registry where everybody can put their MCP server, but this is the equivalent to an NPM, which has the exact same problems of an NPM.

每个人都可以把它发布上去。

Like, everybody can put it there.

基本上，你不知道该信任哪些，不该信任哪些。

Basically, you don't know what to trust and what not to trust.

你会遇到供应链攻击。

You have supply chain attacks.

这些都是公共注册中心固有的特性。

These are just fundamental properties of public registries.

我的意思是，这正是我们提出子注册中心概念的原因，未来Smithereys和其他人或许可以在此基础上进行过滤和精选。

I mean, that's why we have this concept of subregistries, which then, like, Smithereys and others hopefully can do, where they can filter and curate on top of it.

这正是我们想要生活的世界。

And that's the that's really the world we wanna live in.

我认为我们还没完全达到，但正在慢慢靠近。

I don't think we're quite there yet, but we're slowly getting there.

是的。

Yeah.

比如，GitHub 仓库是经过筛选的，或者使用与官方仓库相同的格式。

Like, the GitHub registry is is curated off the or speaks the same format as the as the official registry.

因此，我们希望的是，作为一家公司，你可以拥有一个内部仓库，它是官方仓库的精选版本，再加上你自己的仓库。

And so what we want is, like, you as an as a company can have an internal registry that is a curated form of the the the official one, plus maybe your own ones.

我的意思是，这才是你信任的仓库，而且它使用与官方仓库相同的 API。

I mean, that's the one you trust, and it speaks the same API than the official one.

如果你有 VS Code 或其他任何需要连接仓库的工具，你只需将其连接到你的仓库，就能顺利运行。

And if you have, like, a Versus code or anything else that wants to talk to a registry, you just connect it to yours, and you're you're good to go.

这正是我们真正想实现的目标。

And that's that's really what we wanna do.

这很有趣，因为从某种意义上说，NPM 几乎就像一个下载网关。

It's interesting because NPM, in a way, it's almost like a download gateway.

你知道的。

You know?

我其实并不经常用 NPM 来发现包。

It's like I'm not really using NPM for discovery that often.

我不会去 NPM 上搜索包。

I don't go to NPM and search for packages.

我通常是通过其他方式找到它们的。

It's kinda like I find them in other ways.

这是 Eden。

This is Eden.

是的。

Yeah.

对。

Yeah.

我很想知道，你是否认为发现机制是注册表的核心功能之一，或者你是否仍然假设会存在其他方式让智能体进行发现？

I'm interested if you see, like, discovery as like a core piece of, like, the registry, or like if you still assume that, like, there's gonna be some other way that the agent discovers.

我认为在AI模型的世界里，发现确实很重要，但我觉得这和NPM不同，因为我们构建的是以AI优先的东西，可以假设有智能模型知道自己想要什么。

I I do think discovery is important in the in the in the in the model world, but I think that that's where it's different from from NPM because we're building, like, something for AI first, and we can assume there's an intelligent model that knows what it wants.

我认为这是以前从未存在过的东西。

I think that's something that didn't exist before.

对吧？

Right?

嗯。

Mhmm.

如果你在设计现代包管理系统时以模型为核心，也许你会采用类似的方法：直接说明我想构建什么。

If you maybe, I don't know, if you would build modern package management systems with models at heart, maybe you would do a similar approach of just like, here's what I wanna build.

然后让它自己去解决。

Just figure out.

我不关心你能安装哪些包。

I don't care what what packages you can install.

就这么做。

Just do it.

对吧？

Right?

我的意思是，归根结底，这本质上是一回事。

I mean, that's equivalent at the end of the day.

但再说一次，对于公共注册表，你大概不应该这么做，因为这会向所有人开放，造成混乱。

But again, with the public registry, you should probably not do this because it's a it's dump a dumping run for everybody.

你应该针对经过筛选的、可信的注册表来操作。

You wanna do it against the as against the curated trusted registry.

我喜欢你所说的‘模型知道自己想要什么’这个说法。

I like your phrasing that the model knows what it wants.

是的。

Yeah.

因为我觉得，很多人有一个梦想，认为智能体可以利用MCP目录来发现新的服务器并自行安装。

Because I think there there's a lot of there's a dream that peep that agents can use the MCP directories to discover new new servers, install it for itself.

是的。

Yeah.

如果能实现，这看起来确实非常像AGI。

That that seems like very AGI if it works.

对。

Yes.

但它可能行不通。

But it may not work.

我想知道要实现这一点需要发生什么。

And I wonder what needs to happen in order to do that.

我认为一方面我们需要一个良好的注册表界面，另一方面，我们需要为此构建并观察它如何运作，以及我们需要什么样的信任级别？

I do think we need, like, a good registry interface on one hand, and then the second part is just like, we need to build for this and see how it works and what does We need, like, trust levels, maybe?

你肯定需要信任级别。

You will definitely need trust levels.

你需要信任级别。

You need trust levels.

你可能需要某种形式的，比如是的。

You might need some form of, like yeah.

你需要信任级别。

You need trust levels.

你可能需要某种形式的签名。

You might need some form of signatures.

例如，我有一个想法，不确定你是否会采用。

For example, like, one of the ideas I'm not sure if you're gonna do it.

这只是一个随机的想法，但我一直有的一个想法是，你可以附加来自不同模型提供商的签名，他们已经扫描过这个MTP服务器，并表示我们信任它。

It was just a random idea, but one of the ideas I always had is, like, you can attach, like, signatures from, like, different model providers that have scanned this MTP server and say, we trust this.

这是Anthropic的签名，说明这些工具描述是安全的，这是OpenAI的签名，说明它们得到了我们的信任，然后你可以自行决定。

Here's the signature from Anthropic that these tool descriptions are safe, and here's the, like, the signature from OpenAI that these are trusted by us, and then you can decide.

哦，哇。

Oh, wow.

所以我认为这些分布式冷签名让我们形成了一种循环。

So I think these distributed cold signing It made us a kilometre cycle.

而且这并不仅仅是分布式的。

And it's not just really distributed.

它在某种程度上是集中的。

It's just, like, central in a way.

对吧？

Right?

但我认为这就是你将需要的这类东西。

But I think this is the kind of stuff you will require.

或者，从最简单的形式来看，你可能首先会看到它在像公司内部这样的场景中，因为它们会使用私有注册表，从而具有固有的信任。

Or but I think in the simplest form, what you can do where you probably see it first is in in scenarios like low like, internally to a company where you have inherent trust because they will use a private registry.

它们已经在为 NPM 使用私有注册表了。

They're effectively using private registries already for NPM.

它们也在为 PyPI 使用私有注册表，并且也会为 MCP 服务器这样做。

They're using it for PyPI, and they will also do it for MCP servers.

在那里，你拥有隐含的信任，然后就可以直接搜索。

In there, you have implicit trust, and then you can just search.

是的

Yeah.

对吧？

Right?

我认为这正是我们想要探索的有趣领域。

And I think that's really the interesting ground where we wanna where we wanna experiment.

而且我们实际上已经以一种有效的方式建立了内部注册中心，因为当你通过约翰的基础设施启动一个MCP服务器时，它就会被注册。

And that's like, we have our internal registry in an effective way, because when you launch, like, via John's infrastructure, like an MCP server, gets registered.

对吧？

Right?

所以我们也需要去探索这一点。

And so we we need to go in and experiment with that too.

好的。

Okay.

我其实还想问一下，你最近在伦敦举办了一些活动。

I actually wanted to also ask, you you started running some events over in London.

是的。

Yeah.

你举办了代理者黑客松，还提到了你时间线上的开发者峰会。

You had the Agents Hackathon, and you had Dev Summit that you called out on your timeline.

是的。

Yeah.

我只是想听听一些你观察到社区逐渐活跃起来时学到的亲身经历。

I just wanted to get anecdotal stories of stuff you learned as you as you saw the community swing to life.

今年我们举办了两次大型峰会。

So we had two big summits this year.

我们参加了在旧金山举行的MCP开发者峰会。

We're at the the MCP dev summit in San Francisco.

伦敦的那次也是。

And the one in London too.

是的。

Yeah.

还有伦敦的那场。

And the one in London.

我认为你学到的有几件事。

And I think what you learn is a few things.

我认为其中最重要的一点是，这些关于人们在公司内部如何使用它的故事，其他地方很难获取。

I think the the one thing is that you that's very hard to get otherwise is just like these stories around how people use it internally in their companies.

在那里，你不仅能看到一些挑战，也能看到一些成功案例。

In there, you see some of the struggles, but you see also some of the success stories.

其中一个特别有趣的地方是，尤其是在伦敦，那里有很多金融行业的人，因为伦敦显然是一个金融中心，整个会议甚至就在金融区举办。

And one of the interesting bits that that well, which I really loved is, like, particularly in London, you had a lot of financial people there because it's, like, clearly a financial hub, it was actually the the whole conference was in the financial district.

你了解到一些因为法律合同和金融监管而必须遵守的规范。

And learning just like the kind of problems of like things you need to enforce because you have legal contracts, because like financial like regulations.

这些是我以前不知道的事情，我学到了很多，比如在有这些在普通开发环境中不存在的限制时，像MCP这样的通信机制应该是什么样子？

These were things that were that I did not know before, and I learned a lot about, like, okay, what does, like, a thing like an MCP, like, communication there needs to look like if you have these, like, constraints that in a normal, like, development world doesn't exist?

我给你举个例子。

Like, I'll give you an example.

比如，如果你在金融服务行业，对外提供某些数据，这些数据可能来自第三方。

Like, if you are in in financial services and you're exposing some data, that data might be coming from a third party.

你必须保证注明数据的第三方来源，这是一项法律合同要求。

And you must guarantee that you attribute that third party, and that's a legal contract.

对吧？

Right?

当客户向你展示这些数据时，必须明确告诉你这些数据来自某个第三方。

You must like, they if the client displays this data to you, it must tell you this came from this third party.

对吧？

Right?

这些约束在普通的模型场景中是根本不存在的。

And these are constraints that just, like, in a normal model world don't really exist.

对吧？

Right?

但在金融行业，这些是法律强制要求的。

But, in the financial industry, this is, like, legally enforced.

所以这些就是你会觉得，好吧，需要注意的事情。

And so these are the things you're like, okay.

那么，在MCP的世界里，这到底会如何运作呢？

How how will the how will this work in a world where I'm where for MCP?

因此，我们开始创建这个金融服务入口小组，由彭博社牵头，来弄清楚：如果一个客户端想要与金融服务MCP服务器通信，它必须做哪些事情，以及哪些规则需要遵守。

And so now that's when we, like, started, like, creating this financial services entrance group that Bloomberg is heading up to, like, figure out, like, what are some of the things that you, like, a client must do if it wants to speak to a financial services MCP server, for example, and, you know, what are the things that need to be respected.

我认为，这些知识只能通过在会议现场与人交流才能真正学到。

And I think that's the kind of things you only learn on the ground in the conferences talking to people.

对吧？

Right?

所以我认为，当时确实学到了一些这样的经验。

So I think there was some of these learnings there.

我还注意到，有这么多人在积极构建，大家的热情和创造力真的让我非常欣赏。

I think the other things that you just see is, like, just how many people are building and just the excitement and, like, the creativity that some people bring to this, like, that I just love.

对吧？

Right?

就像我来自一些你意想不到的领域。

Like and and I'm from areas you didn't expect.

对吧？

Right?

我喜欢土耳其航空的那些人，他们直接搭建了土耳其航空的MCP服务器。

Like, I love the guys at Turkish Airlines who just built, like, the Turkish Airlines MCP servers.

你可以用它来搜索航班之类的。

You can search for flights and stuff like that.

所以这一直很有趣。

So that was always fun.

我喜欢当人们为MCP生态系统带来一些非常有创意的点子时。

I love when, like, people bring some really creative parts to to the MCP ecosystem.

我喜欢这个社区聚在一起的时候，因为你总会遇到一些超出你固有圈子的东西，能获得一些新的见解。

So I I love this community when they come together because you're just meeting things that are a little bit outside of your bubble, and I and you just get some input.

我觉得这里面有很多可以学习的地方。

And I think there's a lot of learning there.

所以我们还要再重复一次。

And so we're gonna repeat it again.

我们打算四月，或者三月，或者类似的时间在纽约再办一次。

We're do it in New York in April, I think, or or March or something like that.

我们将在六个月后再次举办。

And we're gonna do it again six months later.

我非常喜欢这一点。

And I absolutely love that.

你有没有发现什么好的采样用例？

Any good sampling use cases that you found?

没怎么发现。

Not so much.

好的。

K.

这总是像那样，你知道的，上次我们聊到这个的时候，是的。

And that that's always the like, you know, last time we talked about this Yeah.

人们应该更多地使用它。

People should use it more.

稍微做点采样吧，老兄。

Sampling a little bit, man.

我觉得从采样中学到的一点是，每个人都想在那些未通过MCP服务器暴露的工具中使用采样功能。

Like, I think one thing I learned from sampling, like, everyone wants to use tools with sampling in tools that are not exposed via the MCP server.

当你想做某件事时，你希望有一组仅在那次采样调用中使用的全新工具，而我们之前完全无法做到这一点。

Like, when you wanna do something, you wanna have a set of new tools that you only wanna use during that sample call, and we just had no ability to do it.

而我们在这一轮中修复了这个问题，因此我们希望看到更多一些的采样使用案例。

And then we just fixed this in this iteration, and so we hope to see a little bit more a bit more sampling use cases.

你偶尔会遇到一个执行此功能的MCP服务器。

You will find every now and then an MCP server that does it.

但特别是随着MCP服务器从本地化转向远程化，在远程场景下，使用SDK通常对你更有利，因为你拥有完全的控制权。

But particularly as MCP servers have moved away from more local to be more remote, in remote cases, it's probably always better for you to bring an SDK because you have full control.

你可以部署它。

You can deploy it.

你可以部署一个API案例，甚至可能向别人收费。

You can deploy an API case and maybe even charge someone.

在本地情况下，当你要向很多人分发东西，而你并不知道他们配置的是什么模型，或者他们将其接入了什么应用时，这非常有用。

In a local case, where something is really powerful because you're shipping something to a lot of people and you don't know what is their what is the model that they have configured, what is the application they plug it in.

可能是VS Code，也可能是云桌面。

It might be Versus Code, might be Cloud Desktop.

对吧？

Right?

在这些情况下，这种功能很有用。

And in those cases, something is useful.

但同时，客户端根本不支持它。

But also, like, clients just don't support it.

所以，这正是我仍然感到遗憾的事情之一。

So something is one of these things I'm like, I'm still sad about it.

我仍然认为这是一个非常强大的想法。

I still think it's a very powerful idea.

但你知道，你总得赢一些，也得输一些，你知道的。

But, you know, you gotta you gotta win some, you gotta lose some, you know.

不。

No.

不。

No.

不。

No.

但你也知道，你正在升级它，而我呢，你知道的，

But you you're also, you know, upgrading it, and I'm, you know,

我的希望依然在那里。

in My hopes are still up there.

我只是觉得是这样。

I'm just like Yeah.

是的。

Yeah.

真奇怪。

Weird.

从某些方面来说，当你做对了，这将成为真正的代理间协议。

Like my in in some ways, you know, when you get it right, this will be the real agent to agent protocol.

是的。

Yes.

是的。

Yes.

大多数

Are most of

你看到的用例仍然是数据消费吗？

the use cases that you see still data consumption?

这一直是我的MCP主要用例。

That's been my use case for MCP mostly.

就像说对啊。

It's like Yeah.

这是上下文共享。

It's context sharing.

获取数据。

If Getting data.

MCP采取的最主要操作就是更新线性任务状态。

Well, the the most action MCP takes is, like, update the linear task status.

你有没有见过非常复杂的MCP操作流程，还是说人们主要用它来

Have you seen very complex, like, MCP taking action workflows, or are still people mostly using it for

上下文？

context?

大多数人用它来处理上下文。

Most people use it for context.

我认为这是绝大多数的使用场景。

I think that's the vast majority of usage.

名字里就写着‘模型上下文’呢。

It is in the name, model context.

是的

Yeah.

对

Yeah.

而且OpenAI的尼克·库珀总是告诉我，他说得对，MCP这个名字可能选得不太好，因为它感觉有点局限，我同意这一点。

And and Nick Cooper from from OpenAI always keeps telling me, rightfully so, that the name MCP was probably a little bit poorly chosen because it was like, it feels it restricted a little bit, which I agree with.

我主要看到的是数据用例。

I I it's mostly data use cases.

我见过有人用它进行深度研究。

I've seen, like, people doing deep research via it.

我认为人们通过它来暴露代理，因此它们稍微复杂一些。

I think people expose agents via it, and so they are a little bit more complex.

但这种情况并不常见。

But it's it's not super common.

人们喜欢拿它来做实验。

It's what people like to have experiment with it.

比如，深度研究这类使用场景我觉得很不错。

Like, have like, deep research use case, I think, is a good one.

这种定制化研究的情况其实并不少见，是的。

That is very, very that is that's not too uncommon where people do, like, custom research Yeah.

舒适。

Comfort.

除此之外，是的。

Beyond that yeah.

而其中大部分确实是数据相关。

And I most of it is really data.

除了数据和深度研究之外，现在还出现了新的一面，即人们会暴露一些UI组件，比如MCP UI，或者我们将来会称之为MCPI的东西。

Beyond data and deep research aspects now, you have also this new aspect where people expose, like, UI components or MCP UI or what we're gonna call MCPIs in the future.

我觉得这非常有前景，而且真的非常有趣。

And I think that's super super promising, and I think that's really quite fun.

现在你经常能在ChatGPT应用和一般的MCP UI中看到这一点。

That's actually you see a lot now with ChatGPT apps, with MCP UI in general, that you see a lot.

是的。

Yeah.

你还有上一次的那些任务。

And you have the tasks in the last In last.

我的意思是，我很好奇，因为如果大多数使用场景都是上下文，然后你再构建任务，那几乎就像人们并没有真正用它来做任务。

Well, I mean, I'm curious because, like, if most use cases are like context and then you build tasks, it's almost like people are not really using it for tasks.

所以我很好奇，你是怎么设计的，你期望人们怎么使用它？

So I'm curious, like, how you design it, like, you expect people to use.

我们设计任务是因为有人来找我们，说：好吧。

We design tasks because people come to us and go, like, okay.

我们真的需要长时间运行的操作，其实就是代理。

We really want long running operation, which is basically agents.

我们想要一个长时间、深入的研究任务，能持续一个小时。

We want like a long deep deep research task that that finishes in an hour.

我们想要一些可能一天都完不成的任务。

We want tasks that like might not finish within a day.

对吧？

Right?

人们曾用他们的工具笨拙地尝试过这种做法，理论上是可以的，因为工具本质上就是RPC接口，但很快就会变得很别扭，因为模型现在需要理解：‘哦，我得去拉取这个’，这根本就不好玩。

And people have like awkwardly tried to do this with their tools, and you can, because tools are effectively just an RPC interface at the end of the day, but it gets very quickly awkward because now the model needs to understand, oh, I need to pull this, and it it it's just not very fun.

这根本不是一个第一类原语，你会遇到很多限制。

Like, it's just not a first class primitive, and you run into a lot of limitations.

但这种需求源于人们希望拥有一个长时间运行的代理，我们从众多领域和试图实现这一点的人那里听到了太多这样的声音，以至于我们真的觉得必须像GitHub上的大公司问题那样，推出类似‘任务’的功能。

But it's it's come from the fact that people want to have a long running agent, and that's, like, something we heard from so many areas and and people trying to do this, that we, like, we really felt we needed to do something like tasks, on GitHub issues from big companies.

每个人都说：我们需要一个以长时间运行操作为核心的东西。

Everybody was like, we need we need something that long running operations is really top of mind.

所以我真的认为，现在我们会看到大量这样的应用。

So I really think now we're gonna see a lot of it.

但现在还太早，无法判断它会发展得多好，因为它刚被引入SNK，还需要集成到客户端中，之后我们才能看到更多应用。

Now but it's it's a little bit early to see how good it's gonna go because it just landed in the SNK, so it needs to land in the clients, and then we're gonna we're gonna see more of it.

但我肯定认为，你会看到很多基于它的自定义深度研究功能和其他用途。

But I will I definitely I think you will see a lot of the custom deep research parts with it and others.

是的。

Yeah.

我对任务非常看好。

I'm very bullish on tasks.

我觉得把这件事做对非常重要。

Think it was very important to get right.

基本上，每一种编排或协议都需要有同步版本和异步版本。

Basically, every orchestration or protocol needs has a sync version and an async version.

是的。

Yeah.

没错。

Exactly.

需要有异步版本。

Has an async version.

在测试的整体设计中，有没有什么你想要特别指出的设计选择？当时有两个方向，而你们选择了其中一个。

Any, like, design choices that you wanna call out that, you know, you there were there were two directions and you picked one in in just the overall design of tests?

是的。

Yeah.

在设计过程中，我们进行了大量讨论，比如有些人会问，这仅仅是异步工具吗？

In design, there was a lot of conversations, like, some some were like, okay, is this just asynchronous tools?

我们需要不同的原语吗？

Do we do a different primitives?

归根结底，这对我来说很重要。

In the end of the day, it was important for me.

我的判断标准一直是：如果我想把像云代码或任何其他编码代理暴露为MTP服务器，理论上这个方案必须能工作。

My litmus test for it was always, it needs to be able to, like if I wanna expose something like Cloud Code or like any other, like, like, coding agent as an MTP server, hypothetically, this needs to work.

而纯粹的异步工具调用根本无法实现这一点。

And a pure asynchronous tool call would just not do this.

你需要一种能够返回长期中间结果的操作形式。

You want some form of operation that can return, for example, intermediate results in the long term.

你需要这样一种情况，比如：

You want, like, okay.

我通过调用这个工具、这个工具、这个工具得到了这个结果。

I got to this result by calling this tool, this tool, this tool.

我还有另一个输入。

I had this other input.

我还有另一个工具。

I had this other tool.

我做了这个。

I did this.

现在这就是结果。

And now this is the result.

对吧？

Right?

这才是真正你需要暴露出来的。

That's really what you wanna expose.

任务功能还处于早期阶段，目前还做不到这一点，但它的设计方式使其足够通用，能够支持这种功能。

And task is is early, and it doesn't do that just yet, but it's built in a way that it will be generic enough to be able to support this.

所以这就是主要的限制。

So that was the main constraint.

另一个限制是确保它不是对现有工具的简单复制，比如你可能会想：‘好吧，我们再做一套工具，只是语义略有不同’，但实际上它的做法是：你可以通过调用一个工具并传入一组元数据字段来创建一个任务，然后系统会自动创建这个任务。

The other constraint was making sure it is it's it's not a copy of tools where you can you can think about, like, okay, we just do tools again, have slightly different semantics, but instead what it's doing is, like, just like, you can create a task by calling a tool with a certain set of, like, metadata fields, and then it automatically creates a task.

因此，任务本身只是一个容器的概念，可以异步地承载一条消息。

So the task itself is just the concept of, like, a container that can Is a message something asynchronously.

是的。

Yeah.

就像你从这里开始异步执行某个操作，直到那里结束，而我们正在做的就是调用一个工具。

Like, just like, you do something asynchronously from starting here into ending here, and the thing we're doing is a tool call.

这意味着为将来接入其他功能甚至其他任务打开了大门。

Mean, that opens the door to, like, later plug in other things, and maybe even other tasks.

还有可观测性。

Like observability as well

对。

Yeah.

有可能。

Potentially.

对。

Yeah.

显然会很重要。

Is obviously gonna be important.

所以我认为这确实是设计目标，这让它变得稍微更抽象、实现起来也更复杂，但这个问题会被SDK解决，因为SDK会为你处理这些。

So I think that was really the design goal, which makes it a little bit more abstract, a little bit more complicated to implement, but that goes away because the SDKs do it for you.

SDK，然后在那里，你只需要异步调用这个，对。

The SDK, and then over there, you're just gonna like, async call this Yeah.

然后你返回一些内容。

And you return something.

我的意思是，你开始与其他异步方案重叠了，比如JavaScript领域的tRPC，或者Go语言人群使用的Protocol Buffers之类的东西。

I mean, there you start to overlap with other async, like tRPC in in JavaScript land or, you know, whatever Gol Proto Buff stuff that Gol people have.

对。

Yeah.

归根结底，就是这样，是的。

In the end of the day, it's like it's Yeah.

它的设计就像一个经典的RPC。

It's it's designed like a classic RPC.

操作系统接口。

Operating system interface.

比如，你创建一个任务，不断轮询直到它完成，然后你可以进行优化，我们将在下一轮实现这个优化——如果我们没来得及做，那就意味着，与其每隔一分钟、一小时或你选择的任何间隔去轮询，服务器可以通过服务调用主动向我们发送事件。

Like, you create a task, you pull it until it's done, and then you can make an optimization, which we're gonna do in the next round, which if we didn't get around, it's like, okay, instead of having to pull every minute or hour or whatever interval you choose, the server can Service call us events.

像Webhook那样调用你，告诉你：我完成了。

Call call you like like a webhook or something and go like, I'm done.

对吧？

Right?

这就是优化，但核心接口始终是客户端可以轮询。

That's the optimization, but the actual core interface is always that the client can pull.

这实际上也是操作系统所有操作和操作系统本身的工作方式。

And that's actually how, like, operating all system operations and an operating system can work.

就像是，你不断轮询，检查文件是否已更改，文件是否已更改，但你也可以使用内核层面的现代接口，比如 inotify 或者 U ring 之类的机制，来通知你：‘好了，完成了。’

It's like, you pull, it has the file changed, has the file changed, but you can also use like a modern interface on the kernel, like, inotify or something like that, that tell or or U ring or something like that to tell you, oh, I'm done.

太好了。

Great.

是的。

Yeah.

文件已经更改了。

The file has changed.

我学到一个技巧：服务器可以保持 HTTP 连接打开，直到任务完成，然后断开连接，这本身就是给回调的一个信号。

There's a trick I I learned where, like, servers can hold the HTTP connection until it's done, and then they terminate, and that's the signal to to the callback.

对。

Yeah.

但我们并不一定想这么做，因为这可能需要好几天，我不想帮人扛这种负担。

Which we do not necessarily wanna do because it might take a few days, and I don't wanna help people.

这非常不负责任，但确实很酷。

It's very irresponsible, but it's cool.

是的。

Yeah.

是的。

Yeah.

是的。

Yeah.

是的。

Yeah.

有很多方法。

There are plenty of ways.

我想我们只是

I think we were just

老实说，我们会选择Webhook的方式。

gonna go the webhook way, honestly.

任务非常有趣，我们在开发Devon API、Cognition时基本上得自己发明这套机制，我认为这也是对‘每个人都会需要某种长时间运行操作’这一需求的有趣再创造。

Tasks are really interesting, and we basically have to invent this when we did this at did like the Devon API, Cognition, and I think that's also like an interesting reinvention of of like, well, everyone is going to need some kind of long running operation.

而且当你调用一个代理时，你也需要这个。

And and this is well, when you're calling an agent, you also need this.

是的。

Yeah.

但对我们来说有趣的是，MCP 一直试图做的事情。

But the interesting part for us is think what what MCP is always trying to do.

MCP 总是试图封装当前人们正在尝试做的事情，而我们不希望规定你一年后应该做什么。

MCP always tries to encapsulate what currently people trying to do, and we not wanna be prescriptive what you're supposed to do in a year from now.

我们不知道，也无法预测。

We don't know if we don't predict.

我们做了任务，是因为人们说：我们现在就需要这个。

We we did tasks because people are like, we need this now.

对吧？

Right?

我们实际上六个月前就需要这个了。

We needed this basically six months ago.

我们就说，好吧。

And we're like, okay.

我想现在是时候做这件事了。

I guess now it's time to do this.

对吧？

Right?

我们不是试图预测未来，这就是为什么我们试图让协议保持相对简洁，并认为已经取得了一定程度的成效，尽管其他人可能会觉得协议中的基本元素已经太多了。

Instead of trying to do being predictive of of the future, which is why we're trying to keep the protocol somewhat minimal and have, I think, some degree, achieve this, although other people would think already there's too many primitives in the protocol.

还有一个小问题，比如说一个超长运行的路径。

One minor thing and so let's say let's say super long running path.

是的。

Yes.

会有大量消息来回传递。

Lots of messages go back and forth.

Anthropic 实际上是上下文压缩方面的先行者，没错。

Anthropic actually was a kind of leader in context compression or Yep.

在压缩过程中，也许，我们这么叫吧。

In compaction, maybe, let's let's call it.

我认为其他很多实验室也做同样的事情。

And I think a lot of the other labs also do the same thing.

有没有办法处理这种情况，还是我们只是无状态地直接截断上下文，这样就可以了？

Is there a way to handle that or do we just statelessly sort of cut context and it's fine?

你需要完整记录所有发生的事情吗？

Do you need a a full log of everything that happens?

或者不用。

Or No.

你只需要问一下对方。

You just ask the fellow.

是的。

Yeah.

对吧？

Right?

不。

No.

不。

No.

你不需要。

You don't.

我的意思是，我认为他们的情况就是这样。

Like, I think we I think they're this is the thing.

对吧？

Right?

我们还处于行业的早期阶段。

We're very early in the industry still.

我们正在学习很多关于模型需要什么的内容。

We're learning a lot about like, what does the model need?

它不需要什么？

What does it not need?

对吧？

Right?

即使是现在，有些智能体在几轮对话后就开始丢弃工具调用结果，因为它们不再需要这些信息了。

And even today, like, some agents start to like drop tool call results after a few rounds because then they don't need it anymore.

我认为这非常非常非常好。

And I think that's very very very good.

而且我认为除了压缩之外，你还会看到更好的机制，比如理解你需要什么和不需要什么。

And I think besides compaction, you will see just better mechanics of, like, understanding what you need and what you don't need.

比如，对于一个长时间的异步测试，你可能会有一种方式，比如，好吧，可能模型会暂时看到这些信息，但一旦你得到结果，就把其他所有东西都丢弃掉。

Like, for a long asynchronous test, you might have a way where, like, okay, maybe for a while the model sees it, but once you get the result, you just drop everything else.

或者你甚至可能会调用一个小型模型，比如一个俳句模型，然后问它，所有这些信息中我应该保留哪些？

Or you might might even call, like, a small model, like a haiku model and go, like, what all this I should retain?

告诉我。

Tell me.

对吧？

Right?

你会让它类似于AGI的方法，让模型自己决定需要保留什么。

You'd make it might be like the AGI approach where we just like, let the model figure out what it needs to retain.

对吧？

Right?

所以你可以看到它们两者中的两种方式。

And so you can you can see both worlds in them.

我觉得还有很多东西值得学习。

I think there's just lots to learn.

我觉得目前还没有一个标准答案，因为我们还在摸索这类问题，只是在不断改进。

I think there's not the one answer yet, because I think we're still figuring these type of things out, and we're just improving.

压缩确实是一个不错的步骤，但我认为这也不是最后一步。

And compaction compaction is is a good step for it, but I don't think it's the last step there either.

它确实是目前最明显的一个，但我不觉得这就是全部；如果你多加关注，特别是思考一下：‘你能训练模型在这里做什么？’

It is actually the the most obvious one, but I don't think it's like I think if you pay more attention to it, if you particularly think about like, okay, what could you train a model to do here?

我觉得我们能找到更好的方法来做这件事，但这些方法都独立于你如何获取上下文的方式。

I think we get to much better ways of doing that, but they're all, like, independent from how you obtain the context.

我认为 MCPI 始终看到的是，这本质上是一个应用层协议。

And I think MCPI always see is, like, back to, like, it's an application layer protocol.

这只是你获取上下文、选择上下文的方式，这是应用层面的问题。

That's just how you obtain the context, how you select the context, that's the problem for the application.

最终，所有智能体应用都会面临这个问题，而且会有很多不同的技术方案。

And that's the problem all the agent applications will have at the end of the day, and there will be a lot of different techniques.

一年前，每个人都会告诉你这是 RAG 那类东西，但现在可能已经过时了。

A year ago, everybody would have told you it's rag style stuff, but now probably dead.

对吧？

Right?

而现在我们确实使用了模型，也采用了压缩技术。

And now we do use models, we use compaction.

所以我不知道一年后会发生什么。

So I don't know what's gonna happen in a year from now.

好的。

Cool.