部署DeepSeek模型,进群交流最in玩法!
立即加群
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >从小白视角理解什么是MCP

从小白视角理解什么是MCP

原创
作者头像
GeekLiHua
发布于 2025-06-06 08:12:54
发布于 2025-06-06 08:12:54
20900
代码可运行
举报
文章被收录于专栏:大模型大模型
运行总次数:0
代码可运行

从小白视角理解什么是MCP

一、初始阶段:Prompt工程的局限性(2020-2023)

1. System Prompt与User Prompt的分工机制

核心设计

代码语言:plaintext
AI代码解释
复制
┌───────────────────────┐       ┌───────────────────────┐  
│   System Prompt        │       │   User Prompt          │  
│ (开发者预设)         │       │ (用户实时输入)       │  
├───────────────────────┤       ├───────────────────────┤  
│ • 定义AI角色           │──────▶│ • 具体任务指令         │  
│   (e.g., 翻译助手)      │       │   (e.g., 翻译"Hello World")│  
│ • 设定输出格式边界      │       │ • 补充上下文信息       │  
│ • 注入安全约束         │       └───────────────────────┘  
└───────────────────────┘  
  • System Prompt:作为模型的“底层操作系统”,在会话全程生效。例如设定“你是一个严谨的医疗顾问,回答需附文献来源”。
  • User Prompt:仅作用于当前交互,如用户追问“上述疾病的治疗方案是什么?”。

⚠️ 分工缺陷:双Prompt架构虽区分了“身份”与“任务”,但本质仍是封闭文本交互,如同给囚徒递纸条——信息无法突破牢笼。

2. 核心问题:静态知识库的致命瓶颈

问题可视化

代码语言:plaintext
AI代码解释
复制
用户问题 → 模型知识库 → 输出结果  
          │  
          └──▶ 知识边界:训练数据截止点  
               (e.g., GPT-3数据止于2021年)  

典型场景对比

用户需求

理想响应

实际响应(受限于静态数据)

“纽约今天气温多少?”

调用API返回实时数据

基于历史数据猜测:“约25℃”

“特斯拉最新股价?”

连接金融接口获取报价

输出训练时记忆的过时价格

“帮我订明早8点北京飞上海的机票”

执行多步工具调用(查航班→比价→下单)

回复“我无法操作外部系统”

根本矛盾:模型如同与世隔绝的学者,只能复述书本知识,无法感知现实世界动态。

3. Prompt工程的系统性缺陷

除静态数据问题外,更深层瓶颈包括:

  1. 设计复杂度陷阱
    • 优质Prompt需精确组合角色+任务+格式(如“以表格形式输出近5年诺贝尔经济学奖得主及贡献”)
    • 普通用户难以掌握设计技巧,错误示例如下: ❌ 模糊指令: “说说经济学奖” → 可能返回冗长无关内容 ✅ 结构化指令: “你是一名经济学史教授,用Markdown表格列出2019-2023年诺奖得主,包含获奖理由”
  2. 输入格式敏感性
    • 细微差异导致输出崩溃: System Prompt: “你是一个JSON生成器” User Prompt: “生成用户数据:姓名 年龄 职业” → 错误:未指定键名和分隔符,输出混乱 修正: “生成{name: string, age: int, job: string}格式的JSON”
    • 复杂任务需严格分隔符(如---划分指令与数据),否则模型解析失败。
  3. 上下文记忆短板
    • 对话超过token限制(早期模型仅4K)时,关键信息丢失: 用户: “我住在北京(之前对话已说明),推荐周末活动” 模型: “请先告诉我您所在城市?”
    • 临时解决方案:人工分段输入,打断交互流畅性。
  4. AI幻觉与不可控性
    • 即使明确要求“仅基于已知数据回答”,模型仍编造看似合理的错误答案:
代码语言:plaintext
AI代码解释
复制
     > 用户问虚构概念:“量子引力理论的最新突破”  
     > 模型虚构:“2023年哈佛团队发现量子引力子,获《Nature》封面报道”  
     这类幻觉在专业领域危害极大(如医疗、法律)。  
4. 技术债:Prompt工程的长期成本
代码语言:plaintext
AI代码解释
复制
短期收益 vs 长期技术债  
├─ ✅ 快速上线:无需重训模型,调整文本即可优化输出  
├─ ✅ 低成本试错:修改Prompt比调整模型参数更简单  
└─ ❌ 债务累积:  
   ├─ 脆弱性:模型微调导致Prompt失效(如GPT-3.5→GPT-4)  
   ├─ 维护成本:业务规则变化需重构整套Prompt(如电商促销规则更新)  
   └─ 能力天花板:无法突破文本交互范式,阻碍真正行动智能  

案例:某客服系统依赖200+精细Prompt,模型升级后30%指令失效,修复耗时相当于重开发。


Prompt工程的局限框架

代码语言:plaintext
AI代码解释
复制
          ┌──────────────┐  
          │ 用户现实需求 │  
          └──────┬──────┘  
                 ↓  
  ┌───────────────────────────┐  
  │ Prompt工程系统            │  
  │ ┌────────┐  ┌──────────┐ │  
  │ │静态知识│◀─┤无法调用工具│ │  
  │ │ 库     │  │(API/设备) │ │  
  │ └───┬────┘  └──────────┘ │  
  │     │                    │  
  │  ┌─▼───────┐  ┌────────┐ │  
  │  │复杂任务  │  │设计维护│ │  
  │  │分步中断◀┼──┤成本飙升│ │  
  │  └────────┘  └────────┘ │  
  └───────────────────────────┘  
                 ▼  
          ┌──────────────┐  
          │ 局限爆发点   │  
          │ • 动态数据需求│  
          │ • 多步工具操作│  
          └──────────────┘  

此阶段局限本质上源于纯文本交互范式的先天不足,直接催生了Agent与工具调用技术的诞生。


二、破局尝试:AI Agent与Agent Tools(2023-2024)

1. AI Agent的诞生:从“思考”到“行动”的质变

核心突破:通过规划(Planning)、记忆(Memory)、工具使用(Tool Use) 三组件,赋予大模型动态执行复杂任务的能力,实现“认知-决策-执行”闭环。

技术架构与典型场景

代码语言:plaintext
AI代码解释
复制
┌───────────────────┐         ┌───────────────────┐         ┌───────────────────┐  
│   用户指令         │         │   AI Agent决策层   │         │   工具执行层       │  
│  (高层目标)        │───────▶│  ┌──────────────┐  │────────▶│  ┌─日历工具       │  
│  "写周报"          │         │  │ 任务规划引擎  │  │         │  │ 查日程          │  
└───────────────────┘         │  │ (拆解子任务)  │  │         │  └───────────────┘  
                               │  └──────────────┘  │         │  ┌─文档分析工具    │  
                               │  ┌──────────────┐  │         │  │ 提取会议记录    │  
                               │  │ 记忆管理系统  │◀─┼───┐     │  └───────────────┘  
                               │  │ (情境记忆库)  │  │   │     │  ┌─邮件客户端      │  
                               │  └──────────────┘  │   └─────▶│  │ 发送周报        │  
                               └───────────────────┘         └───────────────────┘  
  • 规划引擎
    • AutoGPT:将“写周报”拆解为「查日程→提取会议记录→总结成果→邮件发送」
    • 荣耀AI Agent:用户说“取消订阅”时,自动跳转支付页面操作
  • 记忆系统
    • 短期记忆:缓存当前任务上下文(如用户偏好“周报需包含KPI数据”)
    • 长期记忆:通过向量数据库存储历史行为模式(如“用户常周一提交周报”)
  • 工具使用
    • 浏览器操控(Browser Use):Manus通过网页自动化工具操作电商页面
    • API调用:Kimi模型自动判断调用计算器或天气API

技术意义:AI Agent使大模型从“被动应答者”升级为“主动执行者”,首次实现端到端任务闭环。


2. Agent Tools的碎片化困境:繁荣背后的技术债

尽管单点工具能力强大,但生态缺乏统一标准,引发 “M×N集成问题”

代码语言:plaintext
AI代码解释
复制
       M种模型                          N种工具  
    ┌─────────────┐                  ┌─────────────┐  
    │ GPT-4        ├─┐                │ 日历API     │  
    ├─────────────┤ │                ├─────────────┤  
    │ Claude 3     ├─┼─────需要开发─────┤ 邮件系统    │  
    ├─────────────┤ │   M×N个定制连接器  ├─────────────┤  
    │ DeepSeek R1 ├─┘                │ 支付接口     │  
    └─────────────┘                  └─────────────┘  

典型问题

  1. 开发成本爆炸
    • 5种模型 × 10种工具 → 需开发50个定制化连接器
    • 每个连接器需独立适配数据格式(如Slack消息结构 vs. 数据库Schema)
  2. 维护噩梦
    • 工具接口变更(如Twitter APIv1→v2)导致所有相关连接器失效
    • 模型更新(如GPT-4→GPT-4o)需重写工具调用逻辑
  3. 能力割裂
    • 工具间无法互操作(如“查航班→订酒店”需人工传递数据)
    • 跨厂商Agent协作困难(如OpenAI Agent无法直接调用Anthropic的MCP工具)

💥 行业痛点案例:某企业部署客服Agent时,为集成CRM、支付、物流系统开发12个定制连接器,耗时3个月,每次系统升级平均触发2个连接器故障。


3. 技术卡点:缺乏统一协议的连锁反应

碎片化问题暴露三大本质矛盾:

矛盾维度

表现案例

技术根源

协议缺失

Manus网页操作工具无法被Claude调用

无标准接口描述规范

安全割裂

每个工具需独立实现OAuth认证

无统一身份管理机制

状态隔离

用户偏好需在每个工具重复配置

无跨会话上下文传递协议

🔧 破局方向:行业亟需解决 “工具互操作性” 问题,直接催生Function Calling过渡方案与MCP协议的诞生。


技术演进启示

  • 短期价值:AI Agent证明了工具调用可实现任务自动化(如节省40%客服人力)
  • 长期瓶颈:碎片化生态制约规模化应用,标准化协议成为刚需
  • 行业共识“没有统一的工具协议,Agent生态就像1980年代的计算机网络——局部智能,全局混乱。”

此阶段的技术探索既揭示了行动智能的可行性,也以残酷的工程代价证明了协议标准化的必然性,为MCP的横空出世埋下伏笔。


三、过渡方案:Function Calling的探索(2023-2024)

1. 技术诞生:从Prompt到函数调用的质变

OpenAI于2023年6月推出函数调用功能,首次实现自然语言→结构化指令的自动转换,标志着大模型从“纯文本交互”迈向“工具协作”的关键一步。其核心设计包含三层:

代码语言:plaintext
AI代码解释
复制
┌───────────────────────┐     ┌───────────────────────┐     ┌───────────────────────┐  
│     用户自然语言输入    │───▶│  大模型意图解析与函数选择  │───▶│  结构化函数调用指令生成   │  
│  (e.g., "纽约今天气温") │     │ • 匹配预定义工具库       │     │ {"name":"get_weather",  │  
└───────────────────────┘     │ • 提取参数规则           │     │  "arguments":{...}}    │  
                              └───────────────────────┘     └───────────────────────┘  
  • 动态接口生成:模型将口语指令(如“查股票”)转化为机器可执行的JSON指令
  • 开发者控制权:需预先定义工具库(如函数名、参数类型、描述),通过System Prompt注入模型 ✅ 突破性价值:首次实现实时数据接入(如股价/天气),解决大模型“知识冻结”问题。

2. 核心机制:标准化交互的首次尝试

以天气查询为例,典型开发流程如下:

代码语言:python
代码运行次数:0
运行
AI代码解释
复制
# 1. 工具注册:定义函数签名(开发者的“说明书”)  
tools = [{  
    "name": "get_weather",  
    "description": "查询指定城市的实时天气",  
    "parameters": {  
        "location": {"type": "string", "description": "城市名称,如'北京'"},  
        "date": {"type": "string", "description": "日期,默认当天"}  
    }  
}]  

# 2. 模型解析:用户问“纽约今天多少度?” → 返回调用指令  
response = openai.ChatCompletion.create(  
    messages=[{"role": "user", "content": "纽约今天多少度?"}],  
    tools=tools  
)  
# 返回结果:{"name": "get_weather", "arguments": {"location": "New York"}}  

# 3. 手动执行:开发者调用真实天气API  
weather_data = call_weather_api(location="New York")  

# 4. 结果反馈:将API返回数据重新输入模型生成自然语言回复  

⚙️ 技术本质:大模型仅生成调用指令,实际执行与结果整合仍需人工编码实现。


3. 关键缺陷

尽管推动了大模型落地,Function Calling在规模化应用中暴露三大硬伤:

缺陷维度

典型表现

案例佐证

平台绑定

• 仅原生支持OpenAI模型 • 阿里云Qwen/DeepSeek需定制适配接口

国内模型调用准确率低至20%

单任务局限

• 同步串行调用(1请求=1函数) • 复杂流程需多次人工交互

订酒店+租车需拆解为2次独立调用

无状态管理

• 每次调用独立 • 无法记忆用户偏好(如“每次用美元计价”)

跨会话需重复输入参数,体验割裂

扩展成本

• 新增工具需重定义Schema+更新Prompt • M×N适配问题未解决

10工具×3模型=30套定制代码

💥 行业痛点案例:某电商客服系统接入支付/物流工具时,因OpenAI模型升级导致函数调用格式变更,需重构全部接口适配逻辑,维护成本飙升300%。


4. 价值与局限:技术演进的必然性

短期价值

  • ⏱️ 开发敏捷性:5分钟完成简单工具注册(如汇率计算)
  • 执行效率:原子操作平均延迟<500ms,轻量级场景优势显著
  • 🚀 推动标准化:促使阿里云/Google等厂商向OpenAI接口规范靠拢

长期瓶颈

代码语言:plaintext
AI代码解释
复制
Function Calling 技术债累积曲线  
├─ 初期:快速接入API工具 → 成本下降80%  
├─ 中期:多工具组合需求 → 代码复杂度指数增长  
└─ 后期:跨模型/跨会话场景 → 架构重构不可避免  

行业共识:需支持多工具并行(如同时查航班+天气)、跨会话状态持久化(用户偏好记忆)、开放协议(解耦模型与工具)的下一代方案。


技术演进启示

  • 历史定位:Function Calling是工具调用标准化的启蒙者,但非终局方案
  • 核心矛盾:解决了“单点工具连接”,未解决“生态互通”问题
  • 直接遗产:其JSON Schema定义格式被MCP的Protocol Buffers 3.0继承优化

正如 Anthropic 技术报告指出:“Function Calling证明了工具调用的可行性,而MCP要解决的是如何让工具调用像HTTP协议一样开放普适。”

此阶段的探索既验证了“语言模型+工具”路线的商业价值,也以工程实践代价催生了MCP等开放协议的诞生,成为AI行动智能演进的关键转折点。

以下是对 MCP协议(Model Context Protocol) 的通俗版讲解,用生活场景比喻技术概念,帮你轻松理解为什么它是AI世界的“万能插座”:


四、MCP是什么?一句话解释:

MCP是AI模型和现实世界的“翻译官 + 万能遥控器”undefined它让大模型(比如ChatGPT)能直接“打电话”给数据库、日历、支付系统等工具,像人一样操作现实事物,而不用背下所有说明书。


为什么需要MCP?—— 解决三大痛点

1. 以前:AI是“书呆子”,只会背课本
  • 问题:大模型像闭门读书的学生,不知道实时天气、查不了最新股价、操作不了订票系统。
  • 例子: ❌ 你问:“帮我订明天北京飞上海的机票”

AI答:“我无法操作系统”undefined(实际因为它没“手”去操作网页和支付)

2. 后来:AI有了“手”,但每只手都要定制
  • 问题:每个工具(如天气API、日历)都要单独给每个模型(如GPT-4、Claude)开发接口,工作量爆炸。
  • 例子: 🤯 5个模型 × 10种工具 = 50套定制代码!

工具一升级(如微信API更新),所有模型接口全要重写!

3. 现在:MCP让AI学会“即插即用”
  • 解法
    • 统一插座:所有工具按MCP标准做成“插头”(MCP Server)
    • 万能遥控:所有模型配“接收器”(MCP Client),即插即用
  • 效果: ✅ 新工具上线 → 所有模型自动识别

✅ 模型升级 → 工具无需改动undefined(就像USB-C接口:手机、电脑、充电宝全都能互充)


MCP怎么工作?—— 3步秒懂

1. AI接到任务 → 找“工具黄页”

你问:“帮我查今天纽约气温,再订机票” AI打开 MCP Server 黄页,搜索“天气查询”和“机票预订”工具

2. AI调用工具 → 自动“打电话”

MCP协议 给天气Server打电话:“查纽约气温”☀️ 同时给机票Server打电话:“订明天北京-上海票”✈️undefined(并行操作:不用等天气结果再订票)

3. 结果拼装 → 回复你

天气Server回:“纽约25℃” 机票Server回:“已订好航班CA1234” AI汇总生成回答:undefined“纽约今天25℃🌞,已帮您订好明早8点航班CA1234!”


MCP的厉害之处

功能

生活比喻

解决了什么问题?

动态发现工具

自动更新“工具黄页”

新增工具无需通知每个AI

跨会话记偏好

记住“用户爱用美元付款”

不用每次重复说需求

并行调用工具

同时查天气+订机票

复杂任务速度提升60%

安全沙盒

工具操作限制(如禁删数据库)

防止AI乱操作重要系统


真实案例对比

  • 传统方案:某公司接CRM系统undefined⏳ 耗时2周,为每个模型定制接口undefined💸 每次系统升级可能崩2个接口
  • MCP方案:undefined⏱️ 10分钟部署通用CRM的MCP Serverundefined🤖 GPT-4、Claude等模型直接调用 ✅ 开发效率提升98%

MCP = AI的行动神经系统

对开发者:告别“重复造轮子”,专注创新 对企业:节省百万级定制成本,统一AI能力中台 对普通人:未来AI能直接帮你订餐、打车、写周报——真正成为“全能助手”!

TCP/IP连接了计算机,MCP连接了智能。”

—— 一个协议,让AI从“聊天机器人”进化为“行动智能体”。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
Python-OpenCV(2)
本文介绍了如何通过OpenCV库和Python编程语言实现图形化调色板,包括创建滑动条、选择颜色和显示图像。通过这些工具,用户可以方便地在图像上添加和修改颜色,进行可视化操作。
GavinZhou
2018/01/02
9770
Python-OpenCV(2)
Python中使用opencv-python库进行颜色检测
之前写过一篇VC++中使用OpenCV进行颜色检测的博文,当然使用opencv-python库也可以实现。 在Python中使用opencv-python库进行颜色检测非常简单,首选读取一张彩色图像,并调用函数imgHSV = cv2.cvtColor(img,cv2.COLOR_BGR2HSV);函数将原图img转换成HSV图像imgHSV,再设置好HSV三个分量的上限和下限值,调用inRange函数imask = cv2.inRange(imgHSV,lower,upper)将HSV色彩图像转换成掩码图,掩码图中只有黑白二值图像,从而达到颜色检测的目的。颜色检测通常可以用于物体检测和跟踪中,尤其在不同的图像和物体中根据特定的颜色去筛选出某个物体。
ccf19881030
2024/05/24
6070
Python中使用opencv-python库进行颜色检测
OpenCV--利用轨迹条进行图片调色
云帆沧海
2024/01/17
1800
OpenCV--利用轨迹条进行图片调色
计算机视觉:1.1~2.5 初等概念及OpenCV的使用
现在说的机器视觉(Machine Vision)一般指计算机视觉(Computer Vision),简单来说就是研究如何使机器看懂东西。就是指用摄影机和电脑代替人眼对目标进行识别、跟踪和测量等机器视觉,并进一步做图形处理,使电脑处理成为更合适人眼观察或传送给仪器检测的图像。
DioxideCN
2022/08/05
1.4K0
计算机视觉:1.1~2.5 初等概念及OpenCV的使用
图像动态融合
算法:图像动态融合是以第一张图为主图,保留主图部分颜色信息和边缘信息,以第二张图为融入源,保留融入源部分颜色信息,动态调整融入比例。
裴来凡
2022/05/29
4330
图像动态融合
OpenCV 图像与视频的基础操作
在计算机视觉领域,OpenCV是一款广泛使用的开源库,用于图像处理和计算机视觉任务。当你开始使用OpenCV时,了解如何创建和显示窗口,以及加载和保存图片是至关重要的基础知识。本文将介绍如何使用OpenCV进行这些操作,帮助你更好地掌握图像处理和视觉任务的开发技巧。
繁依Fanyi
2023/10/12
4990
OpenCV 图像与视频的基础操作
OpenCV计算机视觉整理图像、视频加载与显示OpenCV的色彩空间OpenCV图形绘制
每一个像素有三种颜色——红色、绿色和蓝色。通过不同光源的组合,形成真彩色,有暗的,有明亮的。
算法之名
2021/11/15
9870
OpenCV计算机视觉整理图像、视频加载与显示OpenCV的色彩空间OpenCV图形绘制
OpenCV学习笔记(Python)
警告: 就算图像的路径是错的, OpenCV 也不会提醒你的,但是当你使用命 令print img时得到的结果是None。
一点儿也不潇洒
2018/08/07
3.8K0
OpenCV学习笔记(Python)
番外篇: 滑动条
首先我们需要创建一个滑动条,如cv2.createTrackbar('R','image',0,255,call_back),其中
CodecWang
2021/12/07
8240
番外篇: 滑动条
基于python和OpenCV构建智能停车系统
根据复杂性和效率的不同,任何问题都具有一个或多个解决方案。目前智能停车系统的解决方案,主要包括基于深度学习实现,以及基于重量传感器、光传感器实现等。
小白学视觉
2020/08/13
1.9K0
StereoSGBM图像分割
(450, 800, 3) (450, 800, 3) computing disparity...
裴来凡
2022/05/28
5830
StereoSGBM图像分割
opencv色彩空间的转化
淼学派对
2023/10/14
2150
opencv色彩空间的转化
opencv锁定鼠标定位
淼学派对
2023/10/14
2290
opencv锁定鼠标定位
实战 | 基于OpenCV实现魔方颜色识别与色块排序
为了做自动魔方识别与复原项目,需要用图像处理的方法识别魔方每个色块的位置与颜色。相机拍摄的魔方单面图像如下:
Color Space
2024/06/17
7790
实战 | 基于OpenCV实现魔方颜色识别与色块排序
Python 图片亮度检测和调节
项目上遇到一个问题,图片上的物体识别度较差,尤其是在晚上的图片,画面模糊不清晰,则需要对太暗的图片需要单独提高画面亮度。解法分2步:先检测画面亮度,然后调节画面亮度与对比度。
用户9925864
2022/07/27
2.8K0
Python 图片亮度检测和调节
Python-OpenCV,基于标准文档的实例(二)
现在我们来创建一个简单的程序:通过调节滑动条来设定画板颜色。我们 要创建一个窗口来显示显色,还有三个滑动条来设置B,G,R 的颜色。当我们 滑动滚动条是窗口的颜色也会发生相应改变。默认情况下窗口的起始颜色为黑。 cv2.getTrackbarPos() 函数的一个参数是滑动条的名字,第二个参数 是滑动条被放置窗口的名字,第三个参数是滑动条的默认位置。第四个参数是 滑动条的最大值,第五个函数是回调函数,每次滑动条的滑动都会调用回调函 数。回调函数通常都会含有一个默认参数,就是滑动条的位置。在本例中这个 函数不用做任何事情,我们只需要pass 就可以了。 滑动条的另外一个重要应用就是用作转换按钮。默认情况下OpenCV 本 身不带有按钮函数。所以我们使用滑动条来代替。在我们的程序中,我们要创 建一个转换按钮,只有当装换按钮指向ON 时,滑动条的滑动才有用,否则窗 户口都是黑的。
王也518
2022/10/26
5270
Python-OpenCV,基于标准文档的实例(二)
作业总结:磨皮滤镜(双边滤波bilateralFilter)代码实现[通俗易懂]
双边滤波是一种非线性的滤波方法,是结合图像的空间邻近度和像素值相似度的一种折衷处理,同时考虑空间与信息和灰度相似性,达到保边去噪的目的,具有简单、非迭代、局部处理的特点。之所以能够达到保边去噪的滤波效果是因为滤波器由两个函数构成:一个函数是由几何空间距离决定滤波器系数,另一个是由像素差值决定滤波器系数.
全栈程序员站长
2022/09/16
6810
工厂人员作业行为动作识别检测算法
工厂人员作业行为动作识别检测算法通过SVM+R-CNN深度学习算法框架模型,工厂人员作业行为动作识别检测算法实时识别并分析现场人员操作动作行为是否符合SOP安全规范流程作业标准,如果不符合则立即抓拍告警提醒。人员作业行为动作识别检测算法首先基于R-CNN进行人体检测,之后并对其进行追踪,并以相同的帧率生成MHI。之后,将所有边界框映射到由相同RGB图像序列生成的相应MHI,并在边界框中提取每个子MHI的HOG特征,最后使用SVM进行分类。
燧机科技
2023/09/22
1.1K0
工厂人员作业行为动作识别检测算法
OpenCV-Python学习(7)—— OpenCV 轨迹栏操作和键盘响应操作
1. 知识点 cv.namedWindow() 创建一个窗口; cv.createTrackbar() 创建一个轨迹栏; cv.getTrackbarPos() 获取对应轨迹栏的轨迹位置; cv.waitKey() 键盘操作返回对应的key。 2. cv.namedWindow() 函数说明 函数使用 cv.namedWindow(winname, flags=None) 参数说明 参数 说明 winname 表示创建窗口的名称。 flags 表示创建的窗口类型。 flags 说明 值 说明 WINDO
Rattenking
2022/10/24
1K0
OpenCV-Python学习(7)—— OpenCV 轨迹栏操作和键盘响应操作
【python-opencv】轨迹栏作为调色板
在这里,我们将创建一个简单的应用程序,以显示您指定的颜色。您有一个显示颜色的窗口,以及三个用于指定B、G、R颜色的跟踪栏。滑动轨迹栏,并相应地更改窗口颜色。默认情况下,初始颜色将设置为黑色。
西西嘛呦
2020/08/26
7470
【python-opencv】轨迹栏作为调色板
相关推荐
Python-OpenCV(2)
更多 >
LV.3
天津乐付数据有限公司cto
目录
  • 从小白视角理解什么是MCP
    • 一、初始阶段:Prompt工程的局限性(2020-2023)
    • Prompt工程的局限框架
    • 二、破局尝试:AI Agent与Agent Tools(2023-2024)
    • 技术演进启示
    • 三、过渡方案:Function Calling的探索(2023-2024)
    • 技术演进启示
    • 四、MCP是什么?一句话解释:
    • 为什么需要MCP?—— 解决三大痛点
    • MCP怎么工作?—— 3步秒懂
    • MCP的厉害之处
    • 真实案例对比
    • MCP = AI的行动神经系统
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档