Golang

MCP 2026-07-28 is not a minor release that merely renames fields. It moves the protocol core from “establish a bidirectional session, then exchange messages inside it” toward a model that better fits Web infrastructure: each request is self-describing, independently routable, and explicitly cacheable; interactions and long-running work have clear protocol contracts. This directly addresses common production problems: sticky routing, rolling deployments, gateways that cannot inspect bodies, retrying after disconnects, and OAuth trust boundaries.

This article draws on the official release announcement, changelog, specification, Go SDK v1.7.0, and nine executable examples in go-training/mcp-2026-07-28. Their roles differ: the specification defines wire semantics, the SDK defines the public Go API, and the examples and tests only demonstrate the behavior they cover. Tasks in particular are standardized in the specification, while v1.7.0 does not yet provide a complete typed API.

By the end, you should be able to answer four questions: how MCP becomes easier to scale horizontally, how to complete an interaction without a session, what a gateway can safely observe, and which layer server, client, and platform owners should migrate first.

For hands-on verification, refer to the training examples for 01 Stateless, 02 Subscriptions, 03 MRTR, 04 Cache, 05 HTTP headers, 06 Deprecations, 07 MCPGODEBUG, 08 Authorization, and 09 Extensions / Tasks.

MCP 2026-07-28 不是一次把欄位改名的小改版。它把協定核心從「先建立雙向 session，再在裡面交換訊息」改為更接近 Web 基礎設施擅長處理的模式：每個 request 自我描述、可獨立路由、可明確快取，互動與長工作則有明確的 protocol contract。這正好處理 production 最常見的麻煩：sticky routing、滾動部署、gateway 看不懂 body、斷線重試與 OAuth 信任邊界。

本文以官方 release announcement、changelog 與 specification、Go SDK v1.7.0，以及可執行的 go-training/mcp-2026-07-28 九組範例為依據。三者的角色不同：規格定義 wire semantics，SDK 定義公開 Go API，範例與測試只證明它實際覆蓋的行為；尤其 Tasks，規格已正式化，但 v1.7.0 尚未有完整 typed API。

讀完你應該能回答四件事：怎麼讓 MCP 更容易水平擴展、怎麼在無 session 下完成互動、gateway 能安全觀察什麼，以及 server、client、platform 各自該先遷移哪一層。

想邊讀邊驗證，可直接對照教材的 01 Stateless、02 Subscriptions、03 MRTR、04 Cache、05 HTTP headers、06 Deprecations、07 MCPGODEBUG、08 Authorization 與 09 Extensions / Tasks。

Gitea Act Runner is the execution component of Gitea Actions, responsible for fetching CI/CD tasks from the Gitea Server and reporting execution results. As more teams self-host Gitea, the HTTP request volume between Runners and the Server has become a bottleneck on the Server side. This article documents how we analyzed and resolved this problem, reducing the request volume from approximately 1,300 req/s to approximately 170 req/s for 200 Runners — an 87% reduction.

Update (2026-04-20): This article originally described the design after PR #819 merged. A follow-up, PR #822, revealed during code review that #819 had introduced a concurrency regression for Runners with capacity > 1, and addressed it with a “single poller + semaphore” architecture. See the new section at the end: Follow-up: Single Poller with Semaphore (PR #822).

Gitea Act Runner 是 Gitea Actions 的執行元件，負責從 Gitea Server 領取 CI/CD 任務並回報執行結果。隨著越來越多團隊自架 Gitea，Runner 與 Server 之間的 HTTP 請求量成為了 Server 端的瓶頸。本文記錄我們如何分析並解決這個問題，將 200 個 Runner 的請求量從約 1,300 req/s 降到約 170 req/s，降幅 87%。

更新（2026-04-20）：本文原本描述 PR #819 合併後的設計。後續 PR #822 在 code review 中揭露 #819 對 capacity > 1 的 Runner 引入了一個 concurrency regression，並用「單一 poller + semaphore」架構再次修正。請見文末〈後續修正：Single Poller with Semaphore（PR #822）〉章節。

In previous posts, I introduced the concept of Agent Skills and showed how to build an AI-driven development workflow with Claude Code + GitHub Copilot Review. As more products and teams embrace AI Agents, a clear architectural pattern is emerging: API + CLI + Skills. This isn’t a framework or protocol — it’s a pragmatic three-layer architecture that enables any product to become “agent-friendly” quickly.

在之前的文章中，我分別介紹了 Agent Skill 的概念以及如何用 Claude Code + GitHub Copilot Review 打造 AI 驅動的開發流程。隨著越來越多產品和團隊開始擁抱 AI Agent，一個清晰的架構模式正在浮現：API + CLI + Skills。這不是某個框架或協議，而是一種務實的三層架構，讓任何產品都能快速變得「對 Agent 友善」。

In today’s enterprise environment, Generative AI technology has become key to enhancing business efficiency and innovation. However, with the diversification and decentralization of AI services, how to uniformly manage and call these services has become a challenge. This article will introduce how to use Golang to develop a unified API Gateway for cross-cloud AI services, achieving a secure and scalable enterprise-level solution.

This was my second public talk at the 2025 iThome CloudSummit Taiwan. Below is the outline of the talk.

1. Authentication and Authorization
2. Multi-Cloud AI Backend Integration (Azure OpenAI, AWS Bedrock, Google Gemini AI, etc.)
3. Traffic Control and Resource Management
4. Monitoring and Metrics Aggregation

在當今的企業環境中，Generative AI 技術已經成為提升業務效率和創新能力的關鍵。然而，隨著 AI 服務的多樣化和分散化，如何統一管理和調用這些服務成為了一個挑戰。本文將介紹如何使用 Golang 開發一個跨雲端 AI 服務的統一 API Gateway，實現安全、可擴展的企業級解決方案。

這是我在 2025 年 iThome 臺灣雲端大會 (CloudSummit) 的第二場公開演講，底下是演講的內容大綱。

1. 身份驗證與授權
2. 多雲人工智慧後端整合 ( Azure OpenAI、AWS Bedrock、Google Gemini AI …. )
3. 流量控制與資源管理
4. 監控與指標聚合

In 2025, I delivered a workshop at the iThome Taiwan Cloud Summit in Taipei, titled “Step-by-Step Guide to Building MCP Server and Client with Golang (Model Context Protocol)”. The goal of this workshop was to help developers understand how to implement the MCP protocol using Golang, providing practical code examples and hands-on guidance. I have organized all workshop materials into a GitHub repository, which you can find at go-training/mcp-workshop. For detailed workshop content, please refer to this link.

2025 年在台北 iThome 臺灣雲端大會 (CloudSummit) 給一場 Workshop，主題是「一步步學會用 Golang 開發 MCP 伺服器與客戶端 (Model Context Protocol)」。這次的工作坊旨在幫助開發者了解如何使用 Golang 實現 MCP 協議，並提供實際的程式碼範例和操作指南。我已經先將 Workshop 的內容整理成一個 GitHub Repo，您可以在 go-training/mcp-workshop 找到相關資源。詳細 Workshop 內容，請參考此連結。