今天是鐵人賽的最後一天，我想用一篇軟性文章來總結這次的旅程，並分享我對 AI 如何影響程式設計的看法。
這三年來，LLM 的應用經歷了劇烈的演變：從早期單次內容生成的階段，迅速進化到具備自主決策能力的 AI Agent（AI 代理），甚至進一步邁入多代理協作（Multi-Agent）的時代。這是一場本質性的轉變。
正如前面文章範例所展示的，過去開發者主要依賴規則設計邏輯，現在則走向一個融入 AI 決策與生成能力的新模式。前陣子，Andrej Karpathy 在一場演講中提到：「現在，我們幾乎可以用英文對電腦進行程式設計。」這句話精準地點出了核心轉變——程式碼的焦點從關注一步步「如何做」(How)轉向用自然語言表達「想要什麼結果」(What)，讓模型來決定如何實現。
從前面的示範範例中可以看到，許多 Agent 的設計除了工具之外，更重要的是用自然語言來描述目標或具體任務內容。這是因為 AI 模型能夠處理許多模糊不清或複雜多變的情境，這是過去傳統基於規則設計的程式碼無法輕易達成的。
因此，處於 LLM 時代的開發者，除了需要理解程式語言和邏輯之外，更需要具備如何有效與 AI 溝通的能力。這包括:
而這二件事，根據我自已的經驗，沒有真的動手做光靠網路收集許多prompt還真沒那麼效果。
多代理協作(Multi-Agent Systems)允許多個 AI Agent 分工合作完成任務，就像組建真人團隊一樣。如同系統設計，Multi-Agent Systems 有多種不同的架構設計，可以根據任務需求和目標來選擇適合的架構模式，例如:
即便是 Multi-Agent Systems 的設計，也需要開發者具備系統設計的能力，因為多代理系統的協作流程和互動方式會影響整體系統的效能和可靠性。這類架構讓 AI 系統彷彿一個團隊，各個 Agent 如同團隊成員，各司其職又互相配合以完成複雜任務。
接著 Anthropic 在 2024 年推出的**模型上下文協議(Model Context Protocol, MCP)**讓 Agent 的設計更進一步。如果說 Web API 是讓各種不同的系統能夠互相溝通的標準，那麼 MCP 就是 AI Agent 界的 API。
MCP 定義了一套標準化的訊息格式和交互協議，讓不同的 AI Agent 能夠輕鬆整合各種工具和服務到 AI 系統中，有了這個明確的標準，Agent 與工具、環境之間的互動方式變得更加清晰和可靠。
老實說，一開始我對 MCP 並沒有太大感覺，因為我覺得目前的 Agent 框架已經足夠好用且靈活。但隨著我對多代理系統的理解加深，我開始意識到 MCP 想帶來的重要性。連結 Agent 生態系，它促進不同 AI 系統之間的互操作性，還為未來更複雜的 AI 生態系統奠定了基礎。
但也千萬不要以為 MCP 是萬靈丹，MCP 只是定義了 Agent 與外部系統互動的標準，並沒有解決所有的設計挑戰。開發者仍然需要根據具體需求來設計和實現 AI Agent 的行為和邏輯，這需要結合對 AI 技術的理解和系統設計的經驗。並且 MCP 也不是拿現成的 API 就能直接套皮完成，還是需要一些轉換及優化的工作。
隨著 AI 技術的進步，軟體設計正在經歷變革。當我們面臨一個應用需求時，是該堅持傳統的規則式，還是交給 AI 決策?
我並不認為這兩者是非此即彼的選擇，而是應該根據具體情境來決定:
傳統規則式程式適用於:
AI Agent 適用於:
在實務上，通常需要採用混合式實作:簡單、需要精確規則處理的部分仍使用傳統規則式的程式碼(確保效率和可控性);而模糊、難以規則覆蓋的部分則交給 LLM AI(提高智能和使用者體驗)。
面對 AI Agent 與新架構的潛力，開發團隊會面臨一個策略性選擇:
全面導入
漸進整合
漸進整合通常是更務實的選擇，讓團隊能夠在學習中成長，在驗證中調整策略，需要先有體會到 AI 帶來的價值，才會有動力去做更大規模的變革。
總結來說，AI 正在重新定義程式設計的本質，從規則式邏輯轉向自然語言驅動的智能系統。開發者需要:
未來的程式設計將不僅僅是撰寫程式碼，更是設計智能系統和協作流程的藝術。希望這次的鐵人賽能夠激發大家對 AI 與程式設計未來的思考，期待在未來的日子裡，我們能夠共同見證並參與這場技術革命。
「未來的程式設計，不再只是寫程式碼，而是設計一支支智慧團隊，讓 AI 與我們並肩創造新的可能。」
iThome鐵人賽
看影片追技術