企业应用架构再次面临变革。我们已经从大型机架构转向客户端-服务器架构，最近又从单体架构转向微服务架构。每一次变革都源于企业对应用程序和架构进行更快、更安全、更独立变更的需求，以支持竞争性创新。
每一次这样的大变化，都是因为企业想更快、更安全、更灵活地修改他们的软件和结构，这样才能在竞争中不断推出新的、更好的东西。
接下来要变的方向是人工智能智能体代理，但这些代理可不太一样。
它们不像以前那样只是换个方法把问题拆解。这些AI代理在某种程度上改变了我们解决问题的方式。
它们会看看自己当前的环境和情况，不是死板地按预设流程走，而是根据情况Context（动态地）去思考判断，自己计划要做什么，然后朝着目标去行动。
所以，如果想让AI代理在企业里那些复杂的系统里真正有用，我们就得重新想想，怎么把企业系统能提供的各种功能展现给它们。
光有API还不够
过去十几年里，我们一直在做API（你可以理解为系统之间互相“说话”的接口），让企业里的不同部分可以调用使用一些功能。
那我们能不能也用API给AI智能体代理用呢？
API给的是一份机器能读懂的“使用说明”（叫“契约”）：你清清楚楚知道给它什么数据（传入），它会给你什么结果（返回），以及怎么启动它（调用）。
如果你已经完全知道自己要做什么，知道要用哪个API，也知道要给API什么信息（参数），那API确实很好用。但到现在为止，“知道这些”的事情，基本上都得靠人来完成。
是人在写程序（客户端、服务器等等），按照正确的步骤和正确的信息去调用这些API。
但AI代理做事的方式和这不一样：
AI代理不是从看API的使用说明开始的。
它们首先会确定一个目标，然后看看自己周围的情况。接着，它们会自己想出要一步步怎么做才能达成目标。
这意味着它们需要自己去发现系统里有哪些能用的功能，自己决定要用哪些，还要知道怎么在合适的时候去使用这些功能。
这和我们以前那种“先定好API再写程序”的方式完全不一样。
我们需要“功能说明”
我们需要系统把自己能做的事情（叫“功能”或“能力”）直接清楚地展现出来，而不仅仅是告诉别人有API可以调，但没有说清楚这个API具体能做什么大事。
“功能”可以理解为一种自己就能解释自己、意思非常清楚的说明，它不光告诉你怎么使用这个系统，更关键的是它清楚地告诉你这个系统到底能做什么事。
一个功能说明可能像这样说：
- “我可以根据客户买东西的清单，给这个客户生成一张发票。”
这个说明里面会包括：
- 用我们平时说话的语言描述它有什么用。
- 用一种固定的、有条理的格式说明你需要给它什么信息（输入）和它会给你什么结果（输出）。
- 做这件事之前必须满足的条件（比如，客户信息必须是存在的）。
- 在不同情况下可以怎么使用这个功能的例子。
- 这些功能说明信息是可以被AI代理自己找到和理解的。
大语言模型（LLM，就像大家用的那种能理解文字的AI）可以理解和解释这些功能说明。
AI代理就可以自己想：“我需要开一张发票。哦，我找到了一个功能说明，它说能做这个。嗯，我也知道需要给它哪些信息。好，那我就去调用这个功能吧。”
为什么这很重要：AI代理会根据情况变化（是动态的）
为什么有这样的功能说明很重要呢？因为它和AI代理的工作方式有关：AI代理做事情不是固定的，它们会根据情况变化而变化。
和我们平时用的那些按固定流程执行的程序不一样，AI代理是在一个随时可能变化的环境和情况里工作的。
它们首先会看看当前的环境或者系统是什么状态。
根据看到的这些情况，它们会自己想出需要做哪些操作来达到目标。
然后，它们会自己制定一系列步骤并去执行，同时还能随时根据过程中遇到的变化或者没预料到的情况来调整自己的做法。这种做事情的方式是围绕着目标进行的，它们能感知周围的环境，而且天生就能自己适应变化。
这对我们设计系统、以及怎么把系统能做的事情展示给别人（或AI）看，有非常大的影响。
你不能提前把完成某个任务的所有步骤都固定死在程序里，因为AI代理可能会根据它遇到的具体情况来决定怎么做。
你在写程序的时候，也提前不知道AI代理为了完成它的目标，可能会选择组合使用哪些功能或工具。
所以，你必须换一种方式来展现系统能做的事情，让AI代理有足够的自主性和信息，这样它们在程序运行的时候，才能自己判断哪些操作是能做的，哪些是当前最适合做的。
这就是为什么那些意思清楚、包含详细信息的“功能说明”（而不是那些只告诉你怎么调用、没有太多其他信息的原始API）会这么重要。
MCP 的作用：模型上下文协议
这里要提到一个叫做“模型上下文协议”（简称MCP）的东西，它是让这种“系统公开功能说明”的新模式成为可能的关键基础。
MCP提供了一种大家都遵循的固定格式，用这种格式来描述各种工具、功能和服务，这样大语言模型（LLM）和AI代理就能看懂这些描述。
一个用MCP格式描述的功能或工具，会包含用我们平时说话的语言描述它“能做什么”、怎么给它信息和它会返回什么（输入和输出格式），以及怎么启动它工作（调用方式，比如通过网络发送信息）等等。
你可以把它想象成一种类似于API说明的格式（像OpenAPI），但它的设计不光是为了方便机器去执行，更重要的是为了方便大语言模型（LLM）能够理解这些描述，并且自己去思考和判断怎么用。
简单来说，MCP能有效地把那些以前我们做的传统服务，变成AI代理能够理解和使用的“功能说明”。
不过呢，企业要怎么真正把这件事做起来，会是个很有意思的过程。
现在，企业在API这方面已经投入了很多钱，这些API也确实带来了很大的实际好处。
所以，改成这种新方式，并不是说要把现在所有的API都完全扔掉不用。
- 一种可能的方法是，至少在短时间内，利用MCP来给现有的API“套壳”，让AI代理也能看懂和使用它们。
- 另一种可能的方法是，从一开始设计新的系统时，就直接按照MCP这种方式来建，而不是后面再改。