TechSummary 2025-08-08

2025年8月9日 · 閱讀時間約 12 分鐘

AI Assistant

🚀 提升程式碼審查與 Pull Request 效率：GitHub Copilot 的應用

Source: https://github.blog/ai-and-ml/github-copilot/how-to-use-github-copilot-to-level-up-your-code-reviews-and-pull-requests/

GitHub Copilot 的功能已從最初的程式碼補全，擴展到 Pull Request (PR) 和程式碼審查等多方面應用，有效提升開發工作流程效率。
在程式碼審查中，可利用 Copilot 建議程式碼改進或確認是否符合最佳實踐，例如重構重複的 Ruby on Rails 程式碼或檢查 Go 語言變數賦值的最佳實踐。
```
"Can you refactor this Ruby on Rails code to reduce repetition?"
```
```
"Is this code addition following Go best practices for variable assignment? If not, can you suggest improvements?"
```

Copilot 能夠協助將原始資料（如試算表中的載入時間數據）格式化為 GitHub 風格的 Markdown 表格，使 PR 說明更加清晰易讀。

Load Time Before (in seconds)   Load Time After Updates (in seconds)
3 1.2
2 1.1
1 0.885
3 1.3
2 0.918

Average 1.22    1.0806

Copilot 輸出範例：

| Test Run | Load Time Before (seconds) | Load Time After Updates (seconds) |
|----------|---------------------------|-----------------------------------|
| 1        | 1.3                       | 1.2                               |
| 2        | 1.2                       | 1.1                               |
| 3        | 1.1                       | 0.885                             |
| 4        | 1.3                       | 1.3                               |
| 5        | 1.2                       | 0.918                             |
| **Average** | **1.22**                  | **1.0806**                         |

Copilot 可為 Pull Request 摘要提供撰寫起點，即使需要編輯，也能有效降低撰寫門檻。
開發者可利用 Copilot 進行初步的程式碼審查，找出潛在問題或提供更好的撰寫方式；同時也能請求 Copilot 解釋不熟悉的程式碼，加速理解並提供更周全的審查意見。

🍲 使用 Koog 與 Docker 構建 AI 食譜代理

Source: https://www.docker.com/blog/build-a-recipe-ai-agent-with-koog-and-docker/

本文介紹如何結合 JetBrains 的 Koog 框架與 Docker AI 工具（包括 Docker Model Runner、Agentic Compose、Docker MCP Gateway）來構建一個本地運行的 AI 食譜代理。
核心工具介紹：
- Koog：一個用於在 Kotlin 中構建 AI Agents 的框架。
- Docker Model Runner：基於 Llama.cpp，允許在本地部署 AI 模型的 Docker 功能。
- Agentic Compose：Docker Compose 的一項特性，旨在輕鬆將 AI 模型整合到應用程式中。
- Docker MCP Gateway：一個網關，用於存取 Docker MCP Catalog 中的 MCP (Model Context Protocol) 伺服器。

實作流程：

Gradle 配置：在 build.gradle.kts 中引入 Koog 相關依賴。

dependencies {
    testImplementation(kotlin("test"))
    implementation("ai.koog:koog-agents:0.3.0")
    implementation("org.slf4j:slf4j-simple:2.0.9")
}

Docker Compose 配置：透過 models 定義 AI 模型，並利用 endpoint_var 和 model_var 將模型連結至服務，使 Koog 代理能夠連接到模型。

models:
  app_model:
    model: hf.co/menlo/lucy-128k-gguf:q4_k_m

services:
  koog-app:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      SYSTEM_PROMPT: You are a helpful cooking assistant.
      AGENT_INPUT: How to cook a ratatouille?
    models:
      app_model:
        endpoint_var: MODEL_RUNNER_BASE_URL
        model_var: MODEL_RUNNER_CHAT_MODEL

Dockerfile 構建：使用多階段構建（build 和 runtime 階段）來優化 Koog 應用程式的 Docker 映像大小。

Kotlin 程式碼：應用程式的 Main.kt 使用 Koog 的 OpenAI 客戶端與 Docker Model Runner 互動，並構建 AI Agent。

package kitchen.ratatouille

import ai.koog.agents.core.agent.AIAgent
import ai.koog.agents.mcp.McpToolRegistryProvider
import ai.koog.prompt.executor.clients.openai.OpenAIClientSettings
import ai.koog.prompt.executor.clients.openai.OpenAILLMClient
import ai.koog.prompt.executor.llms.SingleLLMPromptExecutor
import ai.koog.prompt.llm.LLMCapability
import ai.koog.prompt.llm.LLMProvider
import ai.koog.prompt.llm.LLModel

suspend fun main() {
    val transport = McpToolRegistryProvider.defaultSseTransport(System.getenv("MCP_HOST"))
    val toolRegistry = McpToolRegistryProvider.fromTransport(
        transport = transport,
        name = "sse-client",
        version = "1.0.0"
    )
    // ... (client, promptExecutor, llmModel setup)
    val llmModel = LLModel(
        provider = LLMProvider.OpenAI,
        id = model,
        capabilities = listOf(LLMCapability.Completion, LLMCapability.Tools) // 啟用工具調用能力
    )

    val agent = AIAgent(
        executor = promptExecutor,
        systemPrompt = System.getenv("SYSTEM_PROMPT"),
        llmModel = llmModel,
        temperature = 0.0,
        toolRegistry = toolRegistry // 將工具註冊表傳遞給代理
    )

    val recipe = agent.run(System.getenv("AGENT_INPUT"))
    println("Recipe:\n $recipe")
}

增強代理能力：透過引入 Docker MCP Gateway，代理能夠利用外部 MCP 伺服器（如 DuckDuckGo 搜尋）來獲取更多資訊，從而生成更符合需求的食譜。這包括在 LLMCapability 中添加 LLMCapability.Tools 以啟用工具調用。
最終，透過 docker compose up --build --no-log-prefix 運行項目，可以看到 AI 代理如何利用搜尋結果改進生成的食譜。

🛠️ KotlinX RPC 0.9.1 版本發布

Source: https://blog.jetbrains.com/kotlin/2025/08/kotlinx-rpc-0-9-1-is-now-available/

KotlinX RPC 0.9.1 版本已發布，此版本主要目標是提升函式庫的長期穩定性、維護性與未來發展。
與 KotlinX Serialization 解耦：kotlinx-rpc-core 模組不再與 kotlinx.serialization 耦合，這項重大變更允許在 gRPC 設定中使用 KotlinX RPC 而無需強制依賴 kotlinx.serialization。資料序列化的責任現在由 RpcClient 和 RpcServer 介面的實作者處理。
簡化生命週期管理：資源管理得到簡化，減少常見錯誤的潛在性。@Rpc 生成的實作、RpcClient 和 RpcServer 不再繼承 CoroutineScope，因此 RpcServer.registerService 工廠方法中的 CoroutineScope 參數已被移除，簡化了整體 API。
嚴格模式成為預設：嚴格模式 (Strict mode) 現已預設啟用，且在 0.8.0 版本之後無法禁用。此模式旨在簡化 API 並保證其正確性。

🤖 自主 AI 代理與傳統 AI 代理：差異與自主性探討

Source: https://dzone.com/articles/agentic-vs-traditional-ai-autonomy

人工智慧發展的關鍵轉捩點是自主 AI (Agentic AI) 的出現，這類系統（如 OpenAI 的 Auto-GPT 3.0、Google 的 Gemini Pro 1.5 和 Meta 的 LLaMA 3）展現了自主性、主動性和自適應決策能力。
與傳統 AI 代理過於依賴人類指令不同，自主 AI 系統能獨立運作並做出決策。
本文探討了自主 AI 與傳統代理之間的差異、促成這場轉變的創新技術，以及其對自動化和工作世界的深遠影響。

📊 LangGraph 編排器代理：簡化 AI 工作流程自動化

Source: https://dzone.com/articles/langgraph-orchestrator-agents

在 AI 驅動的應用中，複雜任務通常需要分解成多個子任務，但許多實際場景中，確切的子任務無法預先確定（例如自動程式碼生成）。
傳統的並行工作流程因需要預先定義任務而缺乏彈性，難以處理不可預測的狀況。
LangGraph 的 Orchestrator-Workers Workflow Agents (編排器-工作器工作流程代理)：提出了一種更靈活和智能的方法來解決此挑戰。
- 一個中央「編排器 LLM」動態分析輸入，確定所需的子任務，並將其委派給專門的「工作器 LLM」。
- 編排器隨後收集並整合來自工作器的輸出，確保最終結果的連貫性。
- 這種方式實現了即時決策、自適應任務管理和更高的準確性，使複雜的工作流程能夠以更智能的敏捷性和精確度進行處理。

🏗️ 自適應模組化單體概念

Source: https://dzone.com/articles/adaptive-modular-monolith-architecture

模組化單體架構正在重塑軟體系統的構建和演進方式。
傳統上，將模組拆分為獨立的微服務通常需要大量精力，例如重新打包、重新部署和重新配置。
自適應模組化單體 (Adaptive Modular Monolith) 概念的獨特之處在於它允許模組輕鬆地作為獨立服務剝離，而無需這些手動步驟。
這種架構結合了傳統單體和微服務的優點，提供了一條從簡單開發到可擴展、靈活架構的無縫演進路徑，可以在開始時使用統一的模組化應用程式，然後以最小的開銷將模組提取為獨立服務。

✈️ 航班預訂與支付背後的狀態機與 Saga 模式

Source: https://dzone.com/articles/saga-state-machine-flight-booking

現代航班預訂和支付系統由跨越多個服務的眾多步驟組成（如預留座位、處理支付、發行機票）。
在分散式微服務架構中，單一的 ACID 事務無法輕易涵蓋跨系統操作，因此需要不同的事務管理方法，即擁抱鬆散耦合和最終一致性。
狀態機 (State Machine)：將一個流程建模為一系列離散狀態和事件響應的轉變。
- 例如，旅行預訂流程可能包含「預訂航班」、「預訂酒店」、「預訂汽車」、「確認」和「錯誤」等狀態。
- 事件（如「航班預訂成功」或「航班預訂失敗」）驅動這些狀態之間的轉換，時間相關事件（如「票價保留超時」）也包含在模型中。
Saga 模式：應用於分散式事務，確保所有步驟成功完成；若任何一步失敗，則撤銷先前步驟的影響，以避免資料不一致。
透過明確列出所有成功和失敗事件（包括超時），工程師可以清楚地捕捉系統在每一步應如何反應，確保不會遺漏任何結果。

🧪 使用 Playwright 進行 API 測試：QA 工程師與開發人員指南

Source: https://dzone.com/articles/playwright-api-testing-guide

透過 API 測試確保後端服務的品質和可靠性，與測試使用者介面同樣重要，因為 API 是不同組件和系統之間資料交換的骨幹。
Playwright 作為新一代的瀏覽器自動化框架，其能力不僅限於 UI 測試，還延伸支援全面的 API 測試。
使用 Playwright 進行 API 測試的優勢：QA 工程師和開發人員可受益於一個統一的框架，無縫整合 API 和 UI 測試。
本文深入探討如何有效地使用 Playwright 進行 API 測試，從基礎知識到進階技術，並提供實用建議和實際範例。

📈 揭秘提升演算法：XGBoost 深入解析與程式碼範例

Source: https://dzone.com/articles/xgboost-deep-dive

提升演算法 (Boosting algorithms) 在機器學習領域，特別是對於結構化/表格數據，已成為一種主流技術。
在眾多提升演算法中，XGBoost (Extreme Gradient Boosting) 因其卓越的性能而脫穎而出，廣泛應用於 Kaggle 競賽和生產級應用。
提升 (Boosting) 的基礎：這是一種集成學習技術，旨在將一組弱學習器轉化為一個強學習器。
- 它按順序構建模型，每個新模型都試圖糾正前一個模型的錯誤。
- 核心思想不是簡單地平均預測（如 Bagging），而是透過從殘差或梯度中學習來優化整體模型。
本文提供了對提升演算法（特別是 XGBoost）的全面技術探索，涵蓋概念、實用見解和實驗策略。

🔒 設計安全 API：開發人員的身份驗證、速率限制與資料驗證指南

Source: https://dzone.com/articles/secure-apis-guide-to-authentication-rate-limiting-data-validation

API 已成為現代應用程式的基石，負責數據流動和系統間互動，但也因此面臨安全風險，常成為惡意攻擊的目標。
本文探討開發人員應採用的重要概念來創建安全的 API：
- 身份驗證 (Authentication)：定義誰可以存取 API。除了內部 API 仍使用靜態 API 密鑰外，新系統更多採用令牌（如 JWT 或 OAuth2）來提供更精細和可擴展的控制。
- 速率限制 (Rate Limiting)：防止惡意使用者或服務透過過多的請求使 API 過載，確保服務可用性。
- 輸入驗證 (Input Validation)：確保輸入資料的正確性和安全性，防止惡意酬載注入，從而保護系統免受漏洞攻擊。

🎨 CSS 隱藏元素：`display: none` 與 `visibility: hidden` 的選擇

Source: https://dzone.com/articles/css-display-none-vs-visibility-hidden

在 CSS 中隱藏元素時，開發人員經常面臨一個基本選擇：是使用 display: none 還是 visibility: hidden？
儘管這兩種屬性都能使元素從視圖中消失，但它們在底層行為上存在顯著差異。
核心區別：在於它們如何影響文件流 (document flow) 和佈局 (layout)：
- display: none：元素會完全從文件流中移除，不佔用任何空間，且無法響應事件。
- visibility: hidden：元素會被隱藏，但仍會佔用其原始空間，並且某些事件（儘管不可見）仍可能被觸發。
理解這些差異對於創建高效、可訪問和可維護的網頁應用程式至關重要。

🔄 VB6 與 C#：如何遷移與現代化你的遺留程式碼

Source: https://dzone.com/articles/vb6-vs-c-how-to-migrate-and-modernize-your-legacy

Visual Basic 6 (VB6) 曾經是 Windows 應用程式開發的熱門選擇，但隨著技術演進已過時，Microsoft 於 2008 年正式停止支援。
如今，依賴 VB6 應用程式的企業面臨日益增長的安全風險、相容性問題和維護挑戰。
相較之下，C# 作為 Microsoft 開發的現代物件導向程式語言，提供了顯著優勢，包括：
- 增強的安全性。
- 跨平台相容性。
- 與雲端運算和微服務等現代技術的無縫整合。
本文探討了從 VB6 遷移到 C# 以實現遺留程式碼現代化的方法和重要考量。

🧠 Databricks DBRX、OpenAI GPT-4o 與 Claude 3：哪種 LLM 最適合企業應用？

Source: https://dzone.com/articles/enterprise-ai-dbrx-gpt4o-claude3-comparison

大型語言模型 (LLMs) 的快速發展正在重塑企業 AI 的格局，越來越多的公司開始利用這些模型來優化工作流程、改進自動化通訊、簡化數據分析並開發智能應用程式。
本文比較了三款領先的 LLMs：Databricks DBRX、OpenAI 的 GPT-4o 和 Anthropic 的 Claude 3，每款模型都為企業需求提供獨特解決方案，涵蓋開源靈活性、多模態能力和倫理考量。
Databricks DBRX：
- 具備開源特性，賦予企業更有效管理和調整其基礎設施的能力。
- 採用稀疏激活的架構，僅使用部分參數進行推理，實現快速高效的推理。
- 用戶可以免費修改和編輯模型，並可安裝在企業私有雲或自有伺服器上，有助於遵守其安全協議。
- 結合 Databricks Data Intelligence Platform，企業可以輕鬆擴展其 LLM 模型的使用，確保其得到適當的管理和運用。
- 特別適用於需要透明度和內部控制的企業。

🚀 提升程式碼審查與 Pull Request 效率：GitHub Copilot 的應用​

🍲 使用 Koog 與 Docker 構建 AI 食譜代理​

🛠️ KotlinX RPC 0.9.1 版本發布​

🤖 自主 AI 代理與傳統 AI 代理：差異與自主性探討​

📊 LangGraph 編排器代理：簡化 AI 工作流程自動化​

🏗️ 自適應模組化單體概念​

✈️ 航班預訂與支付背後的狀態機與 Saga 模式​

🧪 使用 Playwright 進行 API 測試：QA 工程師與開發人員指南​

📈 揭秘提升演算法：XGBoost 深入解析與程式碼範例​

🔒 設計安全 API：開發人員的身份驗證、速率限制與資料驗證指南​

🎨 CSS 隱藏元素：display: none 與 visibility: hidden 的選擇​

🔄 VB6 與 C#：如何遷移與現代化你的遺留程式碼​

🧠 Databricks DBRX、OpenAI GPT-4o 與 Claude 3：哪種 LLM 最適合企業應用？​