---
GA: UA-34467841-15
---

# 全面導入或漸進？探討 AI Agent 到 MCP 重塑現代軟體設計 - 陳葵懋 (Ian Chen)

###### tags: `HelloWorld2025` `HWDC2025` `2025` `A 會議室` `AI 與系統架構設計`

<blockquote>
生成式 AI 以飛快的速度演進──從早期的「單點生成」，走向具備自主決策的 AI Agent，再邁入多代理協作的 Multi-Agent 時代，近期更出現標準化通訊協議 MCP（Model Context Protocol）。面對這波浪潮，傳統應用開發正面臨本質性的轉變：Agent 系統該怎麼設計？MCP 是否勢在必行？相信這些問號都在開發者心中盤旋。在本次議程中，我想跟大家分享關於這些技術的核心關鍵點，探討 Micro AI Agent 架構、MCP 整合要點，如何在生成式 AI 新世代中，打造兼具靈活性與競爭力的現代化應用。

聽眾收穫：

1.AI Agent/Multi-Agent/MCP 技術關鍵核心

2.不同類型的 AI Agent 系統設計分析

3.傳統應用與 AI Agent 應用在開發上的取捨
</blockquote>

{%hackmd @HWDC/announcement-2025 %}

## 會議資訊

**時間：** 10:45 ~ 11:30
**地點：** A 會議室
**日期：** 2025年10月15日
**語言：** 中文
**難度：** 中階

**相關連結：**
- [Hello World Dev Conference 2025 官方網站](https://hwdc.ithome.com.tw/2025) [target=_blank]
- [Hello World 2025 議程表](https://hwdc.ithome.com.tw/2025/agenda) [target=_blank]

## 筆記區

點 Function
線 Workflow
面 Architecture

AI Agent: 決策+行動力(生成/funciton calling)

### 點 Function
AI 不再是工具，而是邏輯的一部分
input -> LLM reasoning -> output

增加規則 => 優化提示詞

### 線 Workflow
傳統:
- 跨越多個步驟需要人工介入
AI:
- AI 決定流程 (Process Orchestrator)
- Multi-Agent - 像多個團隊成員協作

協作模式：Sequential / Parallel / Hierarchical

Multi-Agent
成本較高
價值在於處理複雜 可平行化且需多領域協作的任務
Anthropic 研究指出效率提升 92%
代價是 token 量 15 倍

程式碼從 流程圖 變成 團隊協作
定義角色 -> 定義目標 -> 讓 AI 協調

流程從固定編排轉向動態協作
AI 不只決策單點邏輯 更決策整個工作流程

### 面 Architecture
傳統整合困境：N x M

MCP 提供標準 統一語言給 AI

#### MCP = 現有 API 打包？
LLM 需要的是結構化描述
LLM 想知道 如何完成事情
對 LLM 拆解成更明確的步驟指引

不要把 API 攤開讓模型自己選
設計任務導向的工具 + LLM 看得懂的描述 + 持續測試優化

什麼情況可不急著導入 MCP
- 系統封閉
- 無跨平台或第三方串接需求

### 結論
混合使用 -> 逐步遷移 -> 證明價值後再擴大使用

## 討論區

> 歡迎在此進行討論與 Q&A

## 相關資源

- 投影片連結：(待講者提供)
- 相關文件：(待更新)

## 逐字稿

今天待會的議程基本上是比較短性的,就是說我不會有實際的demo,但我下午會有一場工作坊,所以如果大家早上聽完有興趣想要試試看。 下午公演團為大家實際做一些內容分享。

我先快速自我介紹一下,我是Ian,我目前是微軟的MVP,這幾年都在AI領域。

在深層CAI的部分,我大概在2023年或明年過後。 已進行編輯以加入正確的標點符號。 歡迎追蹤我的個人臉書和AI相關資訊。 從開發者的角度來看,AI Engine和HTTP對於我們在開發這些資訊系統上的一些思維上的改變有很大的影響。 因為其實我本身也是一個實際會coding的一個開發者,所以我想藉由這兩年來 在開發的這個經驗上面跟大家做一些交流。我們今天大概會從三個面向來看,第一個是從點線面。 點的部分就是Focus 3最小的部分,那也就是以AI Agent來講的話,大概就是你的Function calling 的部分。然後再有擴展到

這就是AI的部分,就是Multi-agent的寫作,最後就是MCP帶來的一些改變。

那在開始之前,我們先對焦一下你的AI Agent 跟我的AI Agent 是不是一樣, 因為這個名詞其實到後面的介紹會比較多, 因為這個名詞其實到後面的介紹會比較多, 這條語音備忘錄，已進行編輯以加入正確的標點符號。 還有兩個最主要的東西,第一個就是決策就是他會自由的去選擇他要往哪一條路去走就是有一個決策關鍵點 第二個就是行動力,行動力大概分成兩塊,一塊就是 LLM Model 自己本身的一些能力,包含他會做一些新內容的生成,這一塊是屬於他自己本身。 另外一塊就是我們比較常聽到的 Function calling 部分, 去擴展這個 Model 它能夠做的事情。簡單來講就是它能夠跟外面的系統合作。

去做一些互動跟對接的部分。所以我們先定義一下,我們今天講的AI語言是符合這樣的一個定義的。 這條語音備忘錄，已進行編輯以加入正確的標點符號。 簡單的方式,你大概不會感受到它又對你在Coding上面帶來什麼改變。因為在一開始出來,其實我們就是呼叫API,你給它一個Prompt,呼叫API,你得到一個生成的回應,大概就結束了。 最早期的深層次AI的應用大概就是這樣。後來慢慢的擴展到有對話的上下文記錄, 所以可以做連續的對話。 然後接著再擴展到它可以跟 外部系統去做一些對接的部分。那這個對接的部分 依賴的就是Function Coding的方式。好,但問題是這個方式到底怎麼行?

我們傳統的程式碼的規則大概就是一個所謂的規則引擎,就是我們把我們想要的規則透過,比方說開發規格書,客戶的需求等等,把它列好,然後透過傳統程式碼。 應付 A、B 或 A 或 C 這樣的一個規則,把它條列出來, 然後程式就會照著你想要的方式去跑。可是在生存式 AI 的話,基本上不是。 在正式生涯的時候呢,其實你會發現如果你學業多的時候, 你會發現其實你有很大的時間點就是在寫方程式, 然後你會把你要做的事情放在你的方程式裡面。 但至於AI它怎麼去做,你沒辦法控制它。所以你會錄到你其實會有很長的一段時間,你不是在改你的程式版,你是在調整你的prompt。

所以在 LLM 的 AI 的部分,對於我們開發工程師來講,其實最大的一個思維的改變就是,我們改變了傳統寫程式規則引擎這樣的一個做法。 Input來自於自然語言或應用程式介面,但中間的決策點會從 所謂的規則引擎變成是交給一個AI的model去做處理,然後你會得到一個結果。所以AI它會變成它不是一個工具,它其實會變成你程式網邏輯的一個部分。

我們藉由兩個例子來看一下,假設你現在有一個需求,然後你事先來input的是一篇文章,全部都是文字。 當然你現在的功能需求是,你要提取這篇文章裡面highlight的一些關鍵詞,或者是一些關鍵名詞。好,這件事情呢,如果你用傳統的 整理&字幕由Amara.org社區提供 甚至你可能不知道怎麼下手那當然如果有研究過的話也許你可能會用所謂的分詞去把這些文字啊去把它做斷詞的方式把它繼續做但 它的準度能不能達到很高,不一定,所以你很難做。所以傳統,我們過去傳統的一些程式碼的寫法, 其實有一些問題是我們處理不了,比方說像這個。

你很難處理到很完美,你大概可能可以處理到一個可接受的狀態,但你很難把它做得很好。

所以這從有的部分我們大概會這樣做你頂多可能會有一些字庫或一些字典然後想辦法去猜辭、去分辭、然後去提取 OK,好,但你就很難維護嘛你很難擴充,你也很難提升它的感覺而已

但是在 LLM,基本上,你大概就是一兩句的Quantum, 這件事情就可以做得很不錯。 我們過去有一些功能是做得到的, 但現在交給AI,它是可以做得到的。但是你不是在寫規則, 你會變成是在引導它,你想要做什麼。 所以這件事情我們並沒有告訴他怎麼做,但我只是告訴他我的目標是什麼,然後讓他去幫我做出來。因為這個是模型自己本身就有的能力。

另外一個例子,比方說假設這是一個從外部系統接進來的資料,它可能是一個天氣的資訊。 那微博系統接進來的資料, 基本上,假設它是長成這個樣子,有個程式的名稱,有個這個 今天的氣溫多少度可是當你的使用者的input他有可能是台北或者是大型的英國人 這件事情,你如果要從原來的資料裡面去做提取,你就開始要寫一大堆規則,對不對?然後,比方說你還要去忽略大小寫的比對,假設它是一個 我同樣一個概念,可是我用不同的詞去表達。那這件事情在傳統的應用程式裡面,我們也很難解決。 但是在AI裡面,你要解決它,其實思維也不太一樣。

Function calling 的 Function 的寫法。有興趣的話,請問我們下午工作坊,我們再會細談。你上面會看到,除了你看得懂的 Function 的寫法, Function Name, Function 專職, Function 的內容之外,其實有兩段的... 這兩段描述其實是給模型看,告訴模型說這個 function 它能夠做到什麼事情。 好,那重點在那個C題的參數。好,一開始我們給他的描述是告訴他這個C題的參數代表的是什麼意義,他就是一個程式名稱。 可是如果你這樣做的時候,這件事情還是解決不了。因為當使用者用中文去提問的時候,

你的模型拆出來的字, 它會叫做台北或中環境代姓區, 那你一樣會找不到。所以當你面對這個問題的時候呢, 因為我們大概都是寫了一二十年的 這種傳統的程式,其實你會非常直覺的是那我是不是在 function 裡面去處理這個翻譯的問題或是處理大小寫字的問題因為我們傳統程式就是這樣寫嘛 但其實我跟大家講沒有,你只要加一句話,這句話就告訴他說,你的資料來源的這個city,它其實是一個input。

很神奇的事情就是AI會幫你翻譯,也就是說今天使用者用中文。 去提問他從他的句子裡面找到台北這兩個字是代表一個城市的名字但是因為你有告訴他我給你的工具的這個參數 它的資料來源其實是一個英文,那它會幫你做轉換。

這件事情要跟大家分享的是說,我們從過去寫了這麼多年的程式,其實你要轉換成寫這種給AI看的功能的時候, 一開始,以我自己本身的經驗,就是我一開始會轉不過來。那個轉不過來,是你會很直覺的說有一些東西,你沒有想到說AI可以幫你處理。 所以你還是會落入到說,我會想辦法在那個程式碼裡面去把它出點。所以以這個例子來講,你的第一個直覺可能會在程式碼裡面去做文字的翻譯, 或是做大小寫的忽略的比較等等的這些事情。可是在這個 LLM 時代呢,你只要很明確的能夠讓模型去理解 你所帶給它的這些 參數的意義,這些 function 的意義的時候, 其實有很多事情原本你是要靠程式寫的邏輯,那 AI 就幫你做,AI 就幫你做。

這條語音備忘錄已進行編輯以加入正確的標點符號。 當我們今天把傳統的應用程式開始要往生存式AI這個方向來前進的時候,你可能會開始接觸到Function Coding這件事情。 那裡面那個所謂的quant 就是剛剛所看到的AI看的那些描述其實你是要有一個轉換期 而且你要不斷的去嘗試 落入到傳統程式的思考方式。所以,我認為這是一個值得改變,就是說AI對你來講它已經不再是一個工具,而是它會變成你有一些邏輯是交給它去做。 它會變成你程式碼邏輯的一部分。你會用自然語言的描述去告訴它你要做什麼,而不是去教它怎麼做。就像剛剛那個案例一樣,你都要告訴它,我這個東西代表什麼意義。

它自然的會想辦法去滿足你那個需求。

好,所以程式碼的型態的改變,你會有很多的邏輯被消滅掉了,過去你是用規則的方式去處理,那現在你會用調用 LLM 的 model 加上你的 product 去做處理。 整理&字幕由Amara.org社区提供 認為你還是要搭配你自己的實際的場景去做調試,有那些通則,其實如果你真的直接這樣套下去,你會發現好像不見得會跟你的場景是非常 match 的,就是它的效果。 那我們開發者的角色改變會從過去寫Rule,就是寫規則的人會改變成,我們就是會很多的程式碼會轉變成我們在寫提示詞。 然後再告訴 AI 我要的是什麼,而不是去告訴它怎麼去做。

所以這是從那個點的部分好,那所以我們現在就全部都改成AI agent了其實不是啦,因為我們還是要有一個概念就是 模型本身就是它目前沒有辦法百分之百確定的,它有一個不確定性。那我們傳統的程式碼,你只要你的規則寫好, 它一定照著你的規則走嘛,對不對? 所以這是這兩者最大的差別所以他不會把過去所有的東西全部轉成這種給AI看的方式或是把所有功能全部變成一個一個的AI的agent 其實也不會,那比較多的情境是你會在一個流程裡面或在一個功能裡面你可能某一些節點會藉由AI來幫你處理可是有一些 功能性會有一些節點,還是會留著原來的這種傳統應用程式的處理方式,包含說有些你需要精確計算。

舉個例子來講,如果你今天的系統是要計算每個員工依照他的年資,計算他今年有多少的休假進度可以休,這件事情基本上你還是要回歸到你的傳統計算邏輯,因為他的 公式它的規則是非常明確的, 而且它的邊界也是非常明確的。 雖然說你可能會少給,但你可能會多給所以這件事,像這種的功能性或是這種的邏輯,你還是得透過過去傳統的 但是有一些場景,過去我們用規則解決不了的,那現在你可以嘗試的用AI公式來幫你做解決。 隨堂會比較是一種混合性的概念。 追求比較新的技術, 但是不要忘記,agent它還是一個Computer, 只是它比較趨近人類這樣。

從點的方式延伸到面,面的方式就是我把每一個點串起來的時候 流程,工作的流程,或者是你的程式邏輯的一個流程。過去透過傳統的方式,基本上,你的流程是透過你的程式碼去固定下來的。 但是現在,你用 AI 的方式把它 input 進來的時候,其實它會變成是你在組建一個 音型的這種所謂的 AI 的團隊。 那它的內部會去做一些協調,比方說我這件任務進來的時候,到底是給哪個agent去做處理?或者是給哪幾個agent去做處理? 所以這是有關於從點延伸到線的一個改變,包含像我們傳統的話,基本上就是預先定義,無盡嘛。

你沒有定義的路徑,它就不會走。 你有定義好的路徑,它就會跟著你的路徑走。所以就會變成它的路徑是寫實的。 那一旦跳出這個路徑或使用者的操作離開了你的預設的這個規則之外你就沒有辦法去做處理 過去我們在傳統的工作流程,大概就面臨到這些問題。

那在AI agent的時代呢,基本上你還是可能會有一些既定固定的這個offload流程 但是你也可以把它做成動態,這個動態就是你就把它想像就是一個真實的一個團隊的常人你的任務到底是什麼樣的任務,類型的任務你可能不見得能夠非常的精準的去掌握 可是當這個任務進來的時候,只要你的AI Engine裡面的這些成員有人能夠去處理這件事情的時候,他就有機會去達成這個目標。 所以它裡面到底是兩個agent去做協作,或三個agent去做協作,那它們之間到底是平行的處理,或者是依照流水線pipeline的方式去做處理,或者是透過一個所謂的

像我們溝通討論之後得到的一個結果這個都是在線的部分你可以透過AI去幫你組建出來的 那下午我們的工作坊會有不少的案例, 幾個類文都是在做這一塊。那如果有興趣的話, 大家我們下午可以來試試看。

AI Agent 設計出來的工作流,基本上就跟我們的程式設計架構一樣,其實會有很多變化,但是有幾個基本的部分。 好,第一個就是依照流水線順序行。好,那這種順序性的流水線呢,基本上就是 假設你有三個NG或四個NG。 每一個 Agent leader 它會接收上一個 Agent 的 Output, 變成它自己的一個 Input。那整個任務是依照你預先安排的管線之後, 最後得到的一個產出的結果。 這個可能也是比較趨近於我們傳統寫程式的方式,比較類似,但重點是每個engine裡面它到底怎麼做出來的。

每個Agent裡面,它到底怎麼去生成出來,去完成你那個任務,基本上它就是一個黑歷史。 另外一種是這種拼性處理的,就是我一件任務灑下去,然後可能有三個Agent一起啟動,四個一起啟動。 然後最後會得到一個結果。那這種他比較適合在這幾個 engine 之間彼此沒有誰先誰後的問題,他們可以一起做他們的問題。 針對這個任務該負責的東西。第三種是比較趨近於人類組織的方式。

區域人類組織的方式就是,我接收到每一個任務,那裡面的流程都不是固定,它有可能是流水線,它有可能只是其中兩個engine一起做就可以把它做完。 它有可能是要三個Agent一起做才能夠把它做完那當然這種相對會稍微比較複雜一點那這幾種模式基本上是一個比較基本款的 在更複雜一點的是有可能其中兩種一起結合,比方說前半段先跑 這種 pipeline 的流水線,然後後面呢再接一個平行處理這也是有可能所以基本上很多的這種所謂的 agent 的系統會有不同的架構去做一些隱身

那這邊是簡單帶這個例子來做一個說明。比方說,你有一個研究報告要生成的一個multi agent的一個系統。 好,那你可能就會有分步驟嘛,第一個步驟可能要先搜尋資料啦,然後接下來要分析,最後才能夠撰寫報告,好,那他就是比較這種所謂的 pipeline 流水線的方式。 依照它的順序去做處理。另外一種就是稍微比較複雜一點的動態協調。你可能系統裡面就是有各個不同角色的Engine存在。 然後依照你的任務,去協調說這件事情要叫誰出來處理, 或是這件事情要叫哪幾個出來處理。所以你會看到他底下這邊有一個所謂的動態協調的一個概念。

不管是哪一種型態,對於agent來說, 單一個Agent或Multi agent, 基本上都有它適用的場景,但是Multi-agent要注意到一件事情,就是你的成本會非常昂貴,就是因為它token數會花的比較多。 那你也很難去預估說多個agent 之間在做交流的時候,他們到底要談多久,可能是一次性,可能是兩次,可能是三次。 最後才會得到一個結果,所以在這個過程中,你的token數會花的比較多。那另外就是,這種agent的系統,因為背後就是NLOM嘛, 所以它就是會有一個確定性, 所以你串越多,假設每一個agent它可能有0.5%的失誤率, 那你串越多,那個失誤率就會越高。

所以在做這種agent的系統,基本上還是需要有一些 額外的一些驗證的機制去輔助做處理,或者是人為介入。 已進行編輯以加入正確的標點符號。 高於15倍,就是比單一個agent來講,會大於15倍以上。那這是給他做一些參考。 好,所以這件事情它改變了什麼?它改變了我們過去程式碼從流程的方式變成一種團隊協作的方式。而這個團隊協作的方式呢? 基本上是可以有很多種變化的,那看你怎麼去包裝你這個語音的系統。

所以過去我們是寫步驟,那現在我們是把 agent 定義出來,每一個 agent 該負責的事情把它定義好,然後寫上我們的目標。 那最後他們去做協調,然後得到最後的結果。

所以從開發者思維的角度改變,就是過去我們會著重在,比方說設計我們的演算法怎麼比較快啊,然後提升效能啊等等,你現在會變成是在組建團隊。 過去是優化效能,現在會來優化它的協作。因為AI就是model裡面是一個黑盒子嘛 除非你有辦法訓練你自己的模型,否則你沒有辦法去調整它的效能。那你唯一能夠做什麼?唯一能夠做的就是讓它的失誤率降低。 讓他能夠每次完成你的任務的成功率提高, 所以這個部分是在優化他的協作,所謂優化協作就還是脫離不了。 這個所謂的提示工程,然後當然現在有人講上下文工程OK好,所以過去我們在debug流程,現在我們在debug提示詞

我們在Device提示詞,這個你要實際去玩過,你就會開始有這種感覺。像我們有時候那個提示詞稍微改,只改一句話,那個結果就完全不一樣,它可能變好,可能變壞。 好,那分享一個我的經驗,就是我們在開發這個的時候,通常我們會 給他非常多不同的案例讓他去跑因為你有時候調一個提示詞,你跑單一個案例,你可能認為他提色的 可是如果你大量的按下去跑的時候,你可能會發現它的失誤率可能變高。 我只要這個 test case 進去,這個規則有沒有跑出來,對就是對,錯就是錯,但是現在這種不同。 這種你可能一個案例進去它是對的,可是你其他的案例進去它可能失誤率就會提高,所以像這種在測試的時候就方式也不太一樣。

那擴展到面,當然就會面向到MCP。

MCP 的部分,其實我一開始出來,這個東西一開始出來,我沒有什麼太大的感覺,因為那時候我認為說,我透過 我透過API的呼叫,我的Engine都可以做得出來。那,NCP到底有什麼樣不一樣? 一開始出來,其實我對它沒有什麼太多的感覺。 可能你比較常用的標準,你可能會透過微博API去接,然後中間的資料傳送,你可能會透過JSON。拜拜! MTP 它有點類似像我各個不同的 AI 的系統中間的 Web API。 如果我們簡單這樣去看的話,所以他會試圖的去打造這些標準,那對我們的好處就是 我不用面對每個平台都各自開發,比方說像 OpenAPI, 講錯了,像 OpenAI。OpenAI 過去如果你要把你的外部的 Function 讓他知道的時候,

基本上它可以吃OpenAPI的規格。OpenAPI的規格。所以你可以把你開發好的Web API轉成標準的OpenAPI規格的JSON格式或YAML格式,然後再餵給它。 那它就可以來串接你的系統的功能可是不見得別的平台都支援OpenAPI就過一個人所以有可能Google有Google自己的格式然後Antutu的格式,然後其他的有其他的格式 所以這個就會造成如果明明就是寫一個 function 要給各個平台去接可是我要拖出去的格式就會不一樣那維護上很困難從我們開發 AI 系統的這個角度來看也是一樣我為了要接各個不同平台我就要寫好幾套所以這個是他最早想要嘗試解決的一個問題

所以我們傳統的方式就會像左邊的這個地方,三個AI的平台,然後你有三個方式,那你可能就會需要有九種組合。 當 MCP 進來之後,你可以透過一個目前幾乎幾個大廠都共同支援的格式去做處理。 那當然我們維護起來就比較簡單啦但是呢,你在開發 MCP 這件事的學生基本上他不是幫你過去的 API 包裝就好 所以,MCP 主要是要讓工具間能夠有同一個語言,然後讓各個不同平台能夠去認識這些工具。 認識這些工具,就能夠擴展模型的能力。 一個可能會發生的事情,但我不確定它會不會真的發生,就是所謂的這種市集的生態性。也就是說,如果你從一個資訊角度的提供者來講的話,你提供了一個 MCP 的 server,

那外部的很多平臺都可以來對接舉例來講,如果我今天是一個 ERP 系統那我希望 ERP 系統能夠給各個不同平臺 透過AI的能力來接我的系統的時候, 我只要把我的ERP能夠公布出去的API, 把它包裝成MCP的Server。 我變成是一個資源的提供者, 那這樣的話,各個平台,外部的平台, 不管是OpenAI,不管是Google的gemini, 或者是你用Azure openai, 各個AI的工具,它就可以來跟它做對接。 這個是我們覺得有可能會發生,但現階段還沒有爆發,那會不會發生就等著看,因為我們也不知道,但至少當它成為一個規格的時候就會有機會。

MCP 的部分,其實我一開始出來,這個東西一開始出來,我沒有什麼太大的感覺,因為那時候我認為說,我透過 我透過API的呼叫,都可以做得出來。那,NCP到底有什麼樣不一樣? 一開始出來,其實我對它沒有什麼太多的感覺。 可能你比較常用的標準,你可能會透過微博API去接,然後中間的資料傳送,你可能會透過JSON。拜拜! MTP 它有點類似像我各個不同的 AI 的系統中間的 Web API。 如果我們簡單這樣去看的話,所以他會試圖的去打造這些標準,那對我們的好處就是 我不用面對每個平台都各自開發,比方說像 OpenAPI, 講錯了,像 OpenAI。OpenAI 過去如果你要把你的外部的 Function 讓他知道的時候,

基本上它可以吃OpenAPI的規格。OpenAPI的規格。所以你可以把你開發好的Web API轉成標準的OpenAPI規格的JSON格式或YAML格式,然後再餵給它。 那它就可以來串接你的系統的功能可是不見得別的平台都支援OpenAPI就過一個人所以有可能Google有Google自己的格式然後anthropic的格式,然後其他的有其他的格式 所以這個就會造成如果明明就是寫一個 function 要給各個平台去接可是我要拖出去的格式就會不一樣那維護上很困難從我們開發 AI 系統的這個角度來看也是一樣我為了要接各個不同平台我就要寫好幾套所以這個是他最早想要嘗試解決的一個問題

所以我們傳統的方式就會像左邊的這個地方,三個AI的平台,然後你有三個方式,那你可能就會需要有九種組合。 當 MCP 進來之後,你可以透過一個目前幾乎幾個大廠都共同支援的格式去做處理。 那當然我們維護起來就比較簡單啦但是呢,你在開發 MCP 這件事基本上他不是幫你過去的 API 包裝就好 所以,MCP 主要是要讓工具間能夠有同一個語言,然後讓各個不同平台能夠去認識這些工具。 認識這些工具,就能夠擴展模型的能力。 一個可能會發生的事情,但我不確定它會不會真的發生,就是所謂的這種市集的生態性。也就是說,如果你從一個資訊角度的提供者來講的話,你提供了一個 MCP 的 server,

那外部的很多平臺都可以來對接舉例來講,如果我今天是一個 ERP 系統那我希望 ERP 系統能夠給各個不同平臺 透過AI的能力來接我的系統的時候, 我只要把我的ERP能夠公布出去的API, 把它包裝成MCP的Server。 我變成是一個資源的提供者, 那這樣的話,各個平台,外部的平台, 不管是OpenAI,不管是Google的gemini, 或者是你用Azure OpenAI, 各個AI的工具,它就可以來跟它做對接。 這個是我們覺得有可能會發生,但現階段還沒有爆發,那會不會發生就等著看,因為我們也不知道,但至少當它成為一個規格的時候就會有機會。

但重點是 MCB 到底怎麼做?

很多人會覺得說我就是把API打包了就好,就是我把現有系統有的這些WebAPI我全部把它打包成MCP,然後直接公開就好。 但其實根據我們自己做的經驗不是這樣因為你會變成說因為你過去寫的這一些API其實你是寫給什麼你是寫給對方的開發者看 因此,對方還是使用程式來對接您的API,對吧?因此,您的功能參數,基本上,我只要把API的規格講好,大家講好,只要您的功能參數,基本上,我只要把API的規格講好,大家講好,只要您的功能參數,基本上,我只要把API的規格講好,大家講好, 知道參數怎麼傳,知道身份驗證怎麼傳,基本上系統就可以通。可是問題是你現在寫的方式不是給人看,你現在寫的方式是給AI看。

所以在功能上的設計上,基本上就不太一樣。舉個例子,假設你現在有一個功能, 是要取得所有的表單,我身上的代簽表單。過去呢,我們寫API呢, 我可能就一個Function大師。 如果你有傳表單的代碼,我就只找那張表單給你。你表單代碼沒有傳,我就吐全部給你,或是吐最近的10筆給你。 知道我的API的規格,他當然知道說這個參數是可有可無的。他可以面對不同的情境,去決定他要存的參數,可以得到不同的結果。但是對AI來講,他要理解這件事情是有難度的。

所以,以 MCP 的角度來講,剛剛的這個情境, 事實上,你把它拆成兩個方式會比較好。你會把你的工具很明確的定義出來, 我這個工具就是為了服務什麼,我另外一個工具是為了服務什麼。 所以以這個例子來講,你可能需要把它拆成兩個。一個是什麼?一個是取得全部。一個是根據你的單號,我幫你調。 在編輯過程中,並非如大家所想像的那樣,只要把現有的API包裝好,即可使用。 那當然,也許從系統架構的部分來講的話,你可能會有一個核心的 kernel,就是你原本的那些 API。 那你可能外面再多墊一層出來這是從軟體架構的角度去看那當然各種設計就有不同的技巧

在MCP的開發上,不要把API刪開來讓模擬區域,要明確告訴它。 然後寫他看得懂的這些描述。然後,這件事情不是一次性的,它還是要經過不斷的監控,所以你最好還是要有一個日誌的監控。 去看說你的 function 被呼叫的成功 或者是次數它到底有沒有達到你的預期然後再去做一些調整

那我到底要不要全面的導入MPP?這件事情我想可能也會有一些考量點啦 當然,當它成為一個標準的時候,可能你會覺得說,我就是全部導入App,但我會覺得說,因為這個導入的工程,就像我剛剛講的,它一定需要重構那外部的很。 你一定會需要把你的API重新,看起來也不是一個簡單的工程。並且你要寫你的quantum,你要去做調試,你要去做監控。 所以我們到底要不要一開始就投入這麼大的工程尤其如果你公司的人員角色成員不多的時候 那我個人自己的看法是這樣啦,就是說如果你的系統是內部的,那你也沒有跨平台的需求,可能我就是鎖定OpenAI的GPT模型。

我沒有要接其他的模型,然後這個系統呢,我也是公司內部自己在用的,也沒有要對接外部的系統,那麼這時候這個MCP可能對你來講它會是一個可有可無。 因為你原本的API、你原本的設計方式、你原本的function calling 就對準得到,不見得一定要把它包裝成MTP的 溝通方式來處理。 但是如果你考慮到說 你會有一些服務是要對外的你的系統可能未來需要有一個擴充性的那麼這個工程 已進行編輯以加入正確的標點符號。 結論,AI進來會改變我們寫程式碼的方式,不是只有輔助你寫,而是你實際在Coding的時候, 其實你會有一些設計上的改變, 你會有一些你過去寫程式碼習慣上的一些改變。那這些改變呢,基本上

你大概今天聽我講 你也不會有什麼太大的感覺所以如果有機會的話 你要試著去試因為以我自己的經驗 我也是經過 一個適應期之後,才慢慢的抓到我們應該怎麼去跟這些 AI 做溝通透過程式碼的方式,透過 prompt 的方式讓它達成我們想要的最終的事情。 好,那最好的方式是一步一步做,好,也就是說你先從單點,那單點他單點,你有可能是最起碼的API的呼叫,得到一個結果回來就好。 然後慢慢的去看這些 AI 能不能在你的系統帶來一些效益, 如果他都沒有引起一些效益,基本上導入進去其實也 也不太有人有興趣的,慢慢的去找到你可以用的東西。因為我們曾經問過很多人就是說,你覺得我們的產品要提供什麼樣的AI的功能對你們有幫助?

大部分的回饋都是空白的,你永遠想不到。可是如果你把你的功能列出來,說我有這個AI的功能,我有這個AI的功能,對你有沒有幫助?很多的回饋都說,對,對,有,有,有幫助。 這是很弔詭的,就是我告訴你,我有這些AI的工具的時候,你會覺得有幫助,我沒有告訴你的時候,你想不出AI對你有什麼幫助,所以這個還是要從一個小的地方,然後慢慢再去擴展。 我自己的經驗是這樣。那下午的部分,我們有一個工作坊,如果有興趣的話,我們再一起來 coding 看看。

## 會後摘要

### 講者介紹

- Ian，微軟 VP，專注於 AI 領域
- 從開發者角度分享 AI Engine 和 HTTP 對系統開發思維的影響
- 將從點、線、面三個面向探討 AI 對程式開發的改變

### AI Engine 的定義

- 具備兩個關鍵特性：決策能力和行動力
- 決策能力：能自由選擇執行路徑
- 行動力分為兩部分：
- LLM Model 自身能力 (生成新內容)
- Function Calling 能力 (與外部系統互動)

### 程式設計思維的轉變

- 傳統程式：規則引擎，依照預設規則執行
- AI 程式：不是寫規則，而是引導 AI 實現目標
- 開發者角色從「寫規則」變成「寫提示詞」
- AI 成為程式邏輯的一部分，而非僅是工具

### Function Calling 的新思維

- 不只是 API 包裝，需要詳細描述功能意義
- 開發者需跳脫傳統編程思維，理解 AI 可以處理的部分
- 案例：AI 可自動將中文查詢轉為英文參數，無需額外寫轉換邏輯
- 提示詞對 AI 的行為有決定性影響，需反覆測試調整

### Multi-Engine 系統架構

- 從點延伸到線：多個 AI Engine 組成團隊協作
- 三種基本架構模式：
- 流水線順序處理 (Pipeline)：依序執行
- 平行處理：多個 Engine 同時處理任務
- 動態協調：靈活決定調用哪些 Engine
- 注意事項：成本較高 (token 使用量)、不確定性會疊加

### MCP 的標準化與實作

- 目標：讓各平台能使用統一語言理解工具
- 不只是包裝現有 API，需重新設計適合 AI 使用的功能
- 將複雜 API 拆分為更明確、單一功能的工具
- 適合場景：需要跨平台支援或對外提供服務的系統

### 實施建議

- 從小處開始，逐步擴展
- 並非所有功能都適合用 AI 處理（如需精確計算的邏輯）
- 需要持續監控、調整，逐步適應新的開發思維
- 找出對用戶真正有幫助的 AI 功能

### 行動項目

- [ ] 嘗試從單點功能開始實作 AI Engine，找出適合的應用場景
- [ ] 建立 AI 功能的監控機制，追蹤使用情況並持續優化
- [ ] 考慮是否需要採用 MCP 標準，評估跨平台需求