有关智能体/Agent，和上下文协议/MCP的一些概念

摘要：AutoGPT 等开源项目的发布：这是第一批基于自然语言的 AI 自动化实践：你告诉它一个任务，它就会通过自然语言的自我对话，将这个任务进行拆分、规划并实现。你可以认为这是 Manus 的前辈：成功率极很低，能干的事儿很少斯坦福小镇一类的项目实践：给予不同的

这几天，Agent 的相关概念沸沸扬扬。

不做词义追源，仅从大众角度，这个事儿是前年初开始的，也就是 2023 年 2-3 月。标志性事件包括：

AutoGPT 等开源项目的发布：这是第一批基于自然语言的 AI 自动化实践：你告诉它一个任务，它就会通过自然语言的自我对话，将这个任务进行拆分、规划并实现。你可以认为这是 Manus 的前辈：成功率极很低，能干的事儿很少斯坦福小镇一类的项目实践：给予不同的 Bot 以不同的人格，搭配记忆窗口，让它们之间相互对话。发表于 2 月的论文《Toolformer: 大模型可以教自己使用工具》，以及 OpenAI 在 3 月底发布的插件计划：这意味着，大模型从原来的“思想家”，通过对外部工具的使用，变成了实干家。

《AI 学会使用工具了》

2023年2月14日，报道自赛博禅心

由于语言泛化，今天出现了很有趣的现象：「Agent 是什么」，这个问题没有了标准的定义。

一个常见的观点是：Agent 是一种让 AI 以类似人的工作和思考方式，来完成一系列的任务。一个 Agent 可以是一个 Bot，也可以是多个 Bot 的协同。就像是职场里，简单的工作独立完成，复杂的工作协作完成一样。

对于每个 Bot 来说，可能会包括：

一个大脑：判断和规划行为，这里通常需要 GPT-4或更高水平的 LLM；眼睛和手：确认信息和使用外部工具，一般是各种插件/action/api；工作纪要：储存已经发生的事，通常的媒介是上下文窗口，或者一个 todo 文件，也或者数据库；行为SOP：明确这个 Agent 的身份、任务、目标和机制。这个 SOP 可能是用户给的，也可能是由其它 Bot 给出的。

再具象一点，这里我从 GPTs 里截了个图：

GPTs，通常被认为是由 OpenAI 设计的最简版的 Agent。默认情况下，只能进行单 Bot 交互：

一个大脑：在 ChatGPT GPT Store 里，GPT-4 是唯一可选的 LLM；眼睛和手：可以在 Capabilities 里勾选由 OpenAI 提供的第一方能力，也可以通过Actions 来拓展更多的外部能力；工作纪要：一般来说就是对话记录，GPTs 可以回顾之前的对话，；行为SOP：存放在 Description, Instructions 以及 Knowledge 里。

在这里，大脑链接眼睛和手，需要一种神经信号，代码里叫做协议。

最早的协议是 OpenAI Plugin 协议，发布于 2 年前的差不多这个时候，定向邀请。

之后 Anthropic 在去年发布了 MCP 协议，是公开版的

当时我也做了个短评：

类比来说，可理解为 Claude 桌面版的插件系统（类比 OAI 去年3月的发布），不同点在于：

- Claude 的插件，暂还不能共享

- 只能在「Claude 桌面版」（网页版不行）、「Zed」、「Cody」里面使用

- 没有更新到接口（仍然没有正式的 Function Calling / JSON Mode / Sturctured Output）

- 早期版本，很多东西还是饼，比如 Sampling

从进步角度，一定程度上解决了 Claude 不能输出结构化信息的问题：之前 Claude 想要结构化输出，只能 prompt + prefill + regex

而下面，就让我们一起来看看这个 MCP 协议。

Norah Sakal 写了一篇不错的介绍，宝玉进行了翻译

什么是模型上下文协议（MCP）？它如何比传统API更简单地集成AI？https://norahsakal.com/blog/mcp-vs-api-model-context-Protocol-explained/

模型上下文协议（Model Context Protocol，简称MCP） 是一种全新的开放协议，专门用于标准化地为大语言模型（LLMs）提供应用场景和数据背景。

你可以把MCP想象成AI领域的“USB-C接口”，它能让不同的AI模型与外部工具和数据源轻松连接。

本文将清晰地解释MCP的价值、工作原理，以及它与传统API的关键区别。

模型上下文协议（MCP） 就像是为AI模型量身定制的“USB-C接口”，可以标准化地连接AI系统与各类外部工具和数据源。

什么是MCP？

就像USB-C接口让你的电脑更容易连接各种设备一样，MCP让AI模型更简单地获取数据、工具与服务。

通常，AI系统想连接外部工具时，需要单独整合多个不同的API。每个API都有独立的代码、文档、认证方式、错误处理和后续维护，极大地增加了开发复杂度。

打个比方： API就像不同的门，每扇门都需要自己的钥匙和特定的规则。

为什么使用MCP而非传统API？

MCP最早由Anthropic ↗[1]公司开发，目的是帮助AI模型（如Claude）更容易地连接工具和数据源。

但现在，MCP已经成为一个开放协议，越来越多的企业和开发者开始采用它，这也让它逐渐成为AI与工具互动的新标准。

想深入了解？可以访问官方的MCP规格文档 ↗[2]。

为什么要有双向通信？

MCP提供实时互动，模型能：

MCP采用简单的客户端-服务器架构：

MCP的工作架构

• MCP主机（Host）： 如Claude桌面应用或智能开发环境（IDE），需要访问外部数据或工具。• MCP客户端（Client）： 与MCP服务器建立一对一的稳定连接。• MCP服务器（Server）： 提供特定功能，连接本地或远程的数据源。• 本地数据源： 文件、数据库或服务。• 远程服务： 外部API或互联网服务。

简单说，MCP像一座桥梁： 它本身不处理复杂逻辑，只负责协调AI模型与工具之间的信息流动。

比如，一个Python脚本（client.py）作为MCP客户端，可以轻松连接MCP服务器，以控制Gmail、Slack或日历应用，无需每个工具单独编写代码。

如果你的应用场景需要精准且严格受控的交互方式，那么传统API可能更合适。MCP提供广泛而灵活的动态能力，更适合需要上下文理解的场景，但不一定适用于严格受控的场合。

• MCP： 为AI模型统一连接数据与工具的标准接口。• API： 传统的方式，每个服务单独连接，开发更复杂。