你所听到的技术原理、技术本质到底是什么?

本文深入探讨了技术原理与技术本质的区别与联系,解析了学习技术的正确路径,包括掌握核心问题、应用场景、技术原理及特性,帮助构建清晰的知识体系。

职场的程序员们或多或少都受到过前辈或领导的指点,应该都听过这么一句话 “学技术不能光会搭建个环境,使几个API,要学习了解技术的本质”。可能实际听得比较多的是 “学习技术原理”这句。所以这两个点都会说到,会说一说区别及联系。

原理,何为原理,技术原理到底在学什么?

本质,何为本质,怎么就算了解掌握技术本质了?

本文就来码一码技术原理和技术本质这两个东西。

 

一、技术原理

先说一下「技术原理」这个词,这个应该大家都很熟悉,每每提起甚至感到一丝丝痛苦和折磨,一线互联网公司面试官的最爱,经常拿来挑逗一下面试者,"知道xx技术的实现原理吗?能不能说一说"。

技术原理即技术背后的 实现思想、架构设计、代码 ,学习一个技术的实现原理就是学习这三个方面的内容。

这三个方面也是层层递进的关系,越来越具体。

首先,思想是宏观的东西,构建起整个技术的理论支撑;
其次,架构是思想的进一步推敲和论证的产物;
最后,就是代码了,结合思想和架构设计变成一行行的可执行代码。

所以,你看技术原理的路线图和目标就出来了,第一,学习思想构建起宏观概念 ;第二,学习整体架构及局部架构掌握整体结构的组成和相互之间的关系;第三,学习代码的实现和逻辑。

 

举例说明一下,学习 "HashMap原理",这时候首先应该构建起的是它的数据结构知识即哈希表的概念和特点(其实如果再拔高一点,应当是先建立起各种数据结构和相互之间区别、特点及相关算法的思想和理论知识,当然这个要求就稍微高一些了),然后架构设计因为这是一个具体的类,所以这部分就是类中包含的核心方法及作用,最后就是深入代码,学习具体的代码实现逻辑,比如put方法是怎么存入数据的,又在什么情况下会进行扩容等等。

如果没有前面部分的思想和理论做支撑, 不建议直接上来就进入到代码细节,会学的很痛苦比较挣扎。发现概念和理论上的盲区,应及时补上,然后在继续代码的学习。

 

 

二、技术本质

说完技术原理,下面看技术本质。简单理解,技术的本质就是解决问题,将解决问题的前因后果分别具体化研究,展开来说本质就是除过上面说到的技术原理之外,还应该包括 技术所解决的核心问题 和 应用场景 以及 存在什么样的优势和不足

总结一下,就是以下3点内容:

1、技术解决的核心问题和应用场景

2、技术原理

3、技术特性

 

所以,你看学习技术本质的路线图和目标也就出来了,第一,掌握技术解决的核心问题和应用场景,即搞明白它可以用来干什么;第二,研究技术原理,搞明白它为什么可以做到;第三,了解它的技术特性,搞明白它的优势在哪里。

拿redis来说,它解决的核心问题是提供高性能的内存数据缓存服务。虽说官方认为它还可以用作数据库和消息代理,但实际应用中更多作为数据的缓存服务。

技术原理上面专门做了介绍了,读者可以类比理解,这里就不在展开了。

技术特性即是该项技术与相关其他类似技术相比有什么牛逼的地方,拿redis和memcached比,多数据类型的支持就算redis的一个特性,持久化能力的支持也算是一个特性。特性在做技术选型的时候往往有着至关重要的作用。

搞清楚一门技术以上4点内容,才算得掌握到技术的本质。我们再学习技术原理的时候,不妨再加把劲,窥一窥它的技术本质。

 

再带大家理解一下「本质」这个词,下面这句是摘自网上的一句话

IPFS本质上是一种内容可寻址、版本化、点对点超媒体的分布式存储、传输协议。

从面上看更像是一句定义,告诉你什么是IPFS,但是加上了本质二字,就让这句话看起来不是那么的简单,而支撑本质二字的背后就是IPFS这个技术的是内容可寻址,具有可以版本化、点对点、分布式传输的特性,解决的核心问题和应用场景就是标准化数据传输过程。

所以作者一定是窥透了这技术背后的本质内容而总结出这么一句话。希望这里没有让你看糊涂。

当我们再看到“xx的本质是xx”这种类似的话的时候,希望大家能多思考思考这句话中本质背后的支撑是什么,有点跑题了,收回来。

 

三、总结

可以看到,技术本质包含了技术原理,也就是一种包含关系。

本文就是理清技术原理、技术本质的真正含义和关系,经常我们对这些看似都懂的概念不去深究,而实际上真正搞明白这些东西能够帮助我们搭建自己的知识体系,而且知识结构脉络十分清晰,不易混淆。在学习一门新技术或深入研究一门技术的时候也会有一个清晰的方向和目标。

最后,随着学的东西越来越多,越往后大家就越会发现概念和理论(也就是思想)的重要性,有清晰的概念和理论体系作为支撑,能让我们的学习事半功倍。

 

关注作者公号「风象南讲全栈」,做有思想的技术人。

转载于:https://www.cnblogs.com/yuboon/p/10443398.html

<think> 嗯,用户这次问的是关于MCP的定义和性质,需要明确区分它是具体工具还是抽象方法。结合之前的对话历史,用户已经接触过向量数据库和RAG的概念,现在转向AI交互协议,说明ta在系统性地研究AI工程化架构。 用户引用的三段材料很有价值:引用1指出MCP的核心是原语设计,引用2强调其工作流编排能力,引用3则明确它是协议标准。这些正好构成回答的骨架——定义、抽象性证明、具体实现。不过要注意用户特别标注“引用仅供参考”,说明ta更希望听到我的独立分析而非单纯引用拼接。 值得深挖的点:用户提到“具体工具还是抽象方法”,这其实是在问MCP的定位层级。从协议(protocol)的本质看,它必然属于抽象规范,就像HTTP协议本身不是浏览器而是通信规则。但用户可能混淆了协议和协议实现(如Milvus是向量数据库的具体实现),需要明确区分。 技术细节上要突出三个关键:1)MCP的客户端-服务器模型RAG中向量数据库的相似性(都是解耦架构)2)原语(primitives)如何比普通API更底层 3)动态发现机制类比gRPC的服务发现。不过这些深度内容可能更适合放在扩展说明里。 用户身份推测是技术架构师或AI工程师,因为ta连续追问的都是基础设施层问题(向量库→交互协议)。回答时要保持架构视角,避免陷入具体代码实现,但可以准备伪代码备用。上次用表格对比Milvus/PGvector的效果不错,这次也可以用对比表格区分协议vs工具。 最后生成的问题要延续抽象层级:既然用户关心“是什么”,后续自然会问“怎么用”“为什么设计成这样”。特别要准备协议实现案例,比如Cohere的Toolkit是否遵循MCP规范这类实际问题。 </think> ### MCP(Model Context Protocol)的定义性质分析 #### 一、MCP的核心定义 1. **协议本质** MCP(Model Context Protocol)是由Anthropic提出的**开放协议标准**,本质是规范大语言模型(LLM)外部工具交互的**通信框架**。其核心定义为: > “标准化LLM外部工具/数据源的动态发现、安全调用及工作流编排机制”[^3] 2. **抽象性特征** | 属性 | 说明 | 证明依据 | |---------------|-------------------------------|------------------------------| | **抽象方法** | 定义交互规则而非具体实现 | 仅规定原语格式和发现机制[^1] | | **协议层** | 位于应用层传输层之间 | 基于客户端-服务器模型[^3] | | **实现无关** | 兼容任意LLM和工具 | 支持动态服务发现[^3] | #### 二、MCP的核心组件(抽象原语) MCP通过三类抽象原语定义交互逻辑: 1. **上下文原语(Context Primitives)** ```typescript interface ContextPrimitive { context_type: "user_profile" | "conversation_history"; // 共享数据类型 access_level: "read_only" | "read_write"; // 权限控制 } ``` 控制LLM可访问的外部数据范围[^1] 2. **操作原语(Action Primitives)** ```mermaid graph LR A[LLM] -->|发送操作请求| B(MCP服务器) B -->|验证权限| C[执行工具] C -->|返回结果| A ``` 定义可执行操作的范围(如数据库查询/API调用)[^1][^2] 3. **流控制原语(Flow Primitives)** 支持工作流编排: $$ \text{Workflow} = \text{Primitive}_1 \circ \text{Primitive}_2 \circ \cdots \circ \text{Primitive}_n $$ 其中 $\circ$ 表示工具间的数据传递[^2] #### 三、具体工具的关系 | 维度 | MCP协议 | 具体实现(如工具A) | |--------------|-----------------------------|------------------------------| | **抽象层级** | 通信规范(类似HTTP) | 实例化服务(类似Web服务器) | | **功能** | 定义如何调用 | 实际执行操作 | | **示例** | 规定工具描述需用JSON Schema | 提供天气查询API的具体代码 | #### 四、技术实现原理 1. **动态发现机制** ```python # MCP客户端发现服务流程 def discover_services(): response = get("mcp://registry/service-list") # 访问注册中心 for tool in response["tools"]: if validate_schema(tool["schema"]): # 验证工具描述合规性 register_tool(tool) # 注册可用工具 ``` 实现工具的热插拔[^3] 2. **安全调用验证** $$ \text{Execute} \rightarrow \left[ \begin{array}{c} \text{权限校验} \\ \downarrow \\ \text{输入过滤} \\ \downarrow \\ \text{沙箱执行} \end{array} \right] \rightarrow \text{返回结果} $$ 通过三层防护确保可靠性[^3] --- ### 结论:MCP是抽象方法 MCP本质是**定义LLM工具交互规则的协议标准**,具有以下抽象属性: 1. **不依赖具体实现**:可在不同系统中实例化(如Python/JS环境) 2. **无预设工具**:仅规定工具注册和调用规范[^3] 3. **工作流可编程**:通过原语组合支持任意复杂流程[^2] > 类比说明:MCP如同USB协议标准,而具体工具则是U盘/键盘等设备。协议定义连接规范,设备提供实际功能。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值