Golang

2026 年 10 月 14 日，我在 Hello World Dev Conference 2026 帶了一場 90 分鐘的實作工作坊：「讓 AI Agent、MCP Server、CLI 安全登入」。這篇文章把工作坊的觀念與練習路線整理下來，讓沒到場的朋友也能從自己的筆電開始，走過一次 MCP 的授權流程。

當 Agent 能讀文件、查工單、寫入資料，接上工具只是開始。真正要回答的是：這次操作代表誰？可以做哪些事？這顆 Token 能用在哪個服務？出事後，要怎麼停止它的權限？

上一篇企業身分認證治理實戰談的是整體架構，這篇則把焦點拉近到一個 HTTP 請求：從沒有 Token 時的 401，一路追到登入、取得授權，以及 Server 決定接受或拒絕的那一刻。

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.