TechSummary 2025-10-2

如何利用 GitHub Copilot 在五小時內自動化實現無障礙合規性 🧑‍💻

Source: https://github.blog/ai-and-ml/github-copilot/how-we-automated-accessibility-compliance-in-five-hours-with-github-copilot/

• GitHub 過去的無障礙合規修復流程是手動且效率低下，導致反應時間慢、追蹤不一，且無法規模化。
• 透過 GitHub Copilot，團隊在約五到六小時內，將此流程轉變為自動化、可審計的循環，包括自動建立 GitHub Issues、更新現有問題、交叉引用 CRM 追蹤、自動關閉已解決的問題、同步指派者及提及相關利害關係人。
• Copilot 透過快速原型設計和測試，讓領域專家直接構建自動化解決方案，大幅減少傳統開發所需的數週時間，將工程師從基礎骨架工作解放，專注於安全、規模化與生產強化。
• 建構流程輕量化，包括：用簡潔語言定義規則、請 Copilot 調整程式碼而非從零開始、使用小型合成數據測試邏輯、審查輸出並優化提示、添加防護措施（如冪等性、減震機制）、記錄決策並重新運行測試以確保無回歸。
• 自動化成果包括：修復問題迅速出現、所有權和狀態集中化、減少重複或過時的溝通、治理工作轉向高價值分析。Copilot 的賦能讓領域專家能夠直接構建原型，降低了未來合規工具的開發門檻。

從 Shell 腳本到科學代理：AI 代理如何轉變研究工作流程 🔬

Source: https://www.docker.com/blog/ai-science-agents-research-workflows/

• 問題點： 傳統科學研究工作流程由多種工具、腳本和格式拼湊而成，缺乏可重複性，且基礎設施通常是事後考量，導致效率低下。
• 科學代理的承諾： AI 驅動的系統能自主規劃、執行並迭代整個科學工作流程，無需人工不斷提示。例如，給定化合物和蛋白質的 CSV 文件，代理可自動搜尋文獻、預測 ADMET 性質並生成報告。
• 科學代理的定義： 區別於 ChatGPT 等聊天機器人，科學代理是自主系統，能理解目標、分解步驟、選擇工具、執行計算並反思結果，更像數位研究助理或協作者。
• 與 LLM（如 ChatGPT）的關鍵差異：
  • 互動： LLM 是多輪對話，代理是長週期、自主工作流程。
  • 角色： LLM 是助手，代理是明確執行特定任務的研究協作者。
  • 自主性： LLM 需外部提示，代理是完全自主的規劃、工具選擇和迭代。
  • 工具使用： LLM 透過插件，代理是明確的工具整合（API、模擬、Dockerized 工具）。
  • 記憶： LLM 是短期上下文，代理是持久的長期記憶（向量資料庫、檔案日誌）。
  • 可重複性： LLM 非常有限，代理是完全容器化、版本化的可重複工作流程。
• CrewAI 範例： 透過多代理系統（如 Curator、Researcher、Web Scraper、Analyst、Reporter）協同工作，自動化原本需數小時甚至數天的人工任務。
• Docker 實現： 提供一個雙容器範例，展示代理如何自動規劃和執行工作流程，包括攝取 CSV 文件、查詢 PubMed、生成文獻摘要、計算 ADMET 屬性、編譯 Markdown 報告。

  docker compose up

  此範例展示了代理無需手動干預即可進行決策、使用工具和協調任務的能力。
• 基礎設施的重要性： AI 科學代理的瓶頸在於基礎設施。Docker 透過標準化環境、可重複工作流程、可組合代理和流暢的編排解決了重負載、可重複性混亂、工具鏈複雜性和版本控制等挑戰。

使用 Docker Offload 和 Unsloth 微調本地模型 🧠

Source: https://www.docker.com/blog/fine-tuning-models-with-offload-and-unsloth/

• 背景與挑戰： 小型本地模型在複雜任務中表現不足，而大型模型訓練成本高。微調環境設置複雜、易出錯，且對硬體有要求（如 GPU），尤其對於 MacBook 用戶而言更是挑戰。
• 解決方案： 結合 Unsloth（快速模型微調框架）和 Docker Offload（在雲端提供 GPU 資源）來實現本地模型的快速、高效微調。
• 範例目標： 微調一個小於 1GB 的 Gemma 3 270M 模型，使其能可靠地遮蔽個人身份資訊 (PII)。
  • 原始模型表現： 對於 PII 遮蔽任務，原始 Gemma 3 270M 模型輸出不符預期，例如只輸出 [PERSON] 而非詳細遮蔽。
• 微調步驟：
  1. 克隆專案：

     git clone https://github.com/ilopezluna/fine-tuning-examples.git
     cd fine-tuning-examples/pii-masking

     專案包含用於微調 Gemma 3 的 finetune.py 腳本，使用 ai4privacy 的 pii-masking-400k 資料集。
  2. 啟動 Docker Offload (含 GPU)：

     docker offload start

     選擇帳戶，並確認啟用 GPU 支援以獲得 NVIDIA L4 實例。
  3. 運行 Unsloth 容器：

     docker run -d -e JUPYTER_PORT=8000 \
       -e JUPYTER_PASSWORD="mypassword" \
       -e USER_PASSWORD="unsloth2024" \
       -p 8000:8000 \
       -v $(pwd):/workspace/work \
       --gpus all \
       unsloth/unsloth

     此命令會啟動包含 Jupyter 和 Unsloth 的容器，並將本地工作目錄掛載到 /workspace/work。
  4. 執行微調： 在容器內執行 finetune.py 腳本。

     docker exec -it $(docker ps -q) bash
     cd work
     python finetune.py

     腳本使用 LoRA 技術（輕量級微調方法，只訓練小型適配器層）在不到 20 分鐘內完成訓練，將結果 LoRA 權重保存到掛載目錄。
  5. 轉換為 GGUF 格式： 為便於 Docker Hub 分發，將微調後的模型轉換為 GGUF 格式。

     cd ..
     git clone https://github.com/ggml-org/llama.cpp
     python ./llama.cpp/convert_hf_to_gguf.py work/result/ --outfile work/result.gguf

  6. 打包並分享到 Docker Hub：

     docker model package --gguf /Users/ilopezluna/Projects/fine-tuning-examples/pii-masking/result.gguf ignaciolopezluna020/my-awesome-model:version1 --push

  7. 測試結果： 使用 Docker Model Runner 運行微調後的模型。

     docker model run ignaciolopezluna020/my-awesome-model:version1 "Mask all PII in the following text. Replace each entity with the exact UPPERCASE label in square brackets (e.g., [PERSON], [EMAIL], [PHONE], [USERNAME], [ADDRESS], [CREDIT_CARD], [TIME], etc.). Preserve all non-PII text, whitespace, ' ' and punctuation exactly. Return ONLY the redacted text. Text: This is an example of text that contains some data. The author of this text is Ignacio López Luna, but everybody calls him Ignasi. His ID number is 123456789. He has a son named Arnau López, who was born on 21-07-2021"

     微調後的模型能精確地將 PII 遮蔽為 [GIVENNAME_1] [SURNAME_1] 等格式，證明其有效性。
• Docker 微調模型的優勢： 速度快（20 分鐘內）、無需本地 GPU、模型可移植、具備實用性。這使得小型通用模型能轉變為專注、可靠的工具，即使非 ML 專家也能輕鬆實現。

IntelliJ IDEA 2025.2.3 已發布！ ✨

Source: https://blog.jetbrains.com/idea/2025/10/intellij-idea-2025-2-3/

• IntelliJ IDEA 2025.2 的最新次要更新 v2025.2.3 已發布。
• 用戶可透過 IDE 內部、Toolbox App 或 Ubuntu 的 snaps 進行更新，也可從官網下載。
• 此版本包含多項改進：
  • Jira 任務伺服器整合在獲取任務時恢復正常。
  • 在 Services 視圖中，啟用 ClassicUI 插件時，斷點功能如預期工作。
  • 從 Find Usages 對話框中同時開啟多個文件的功能再次可用。
• 詳細問題解決清單可參考發布說明。

Koog × A2A：在 Kotlin 中構建互聯的 AI 代理 🤖

Source: https://blog.jetbrains.com/ai/2025/10/koog-a2a-building-connected-ai-agents-in-kotlin/

• 挑戰： 構建多 AI 代理系統時，各代理間因 API 介面、訊息格式和身份驗證差異，難以協同工作，導致需大量客製化整合程式碼。
• A2A (Agent2Agent) 協議： 提供標準化的跨代理通訊層，作為 AI 生態系統的通用翻譯器，實現即插即用連線、標準化訊息格式、內建編排及可擴展性。
• Koog 框架： 一個基於 Kotlin 的 AI 代理內部編排引擎，適用於 JVM、Android、iOS、WebAssembly 及瀏覽器應用。其優勢包括：複雜工作流程管理（圖形化策略、循環、分支、並行）、即用組件、工具編排、原生 MCP 整合、記憶與儲存支援、容錯性及可觀測性。
• Koog 與 A2A 結合： Koog 處理企業級 AI 編排的核心問題，A2A 則補足了代理間通訊的空白。Koog 的高級工作流程可作為 A2A 任務被其他代理請求，同時 Koog 代理也能利用 A2A 生態系統的完整能力。
• A2A 協議關鍵組成：
  • 代理發現： 透過標準化的「代理卡片」（JSON 文件描述功能，如名稱、描述、技能、端點、安全方案）實現。

    val agentCard = AgentCard(
        name = "Blog Writer",
        description = "AI agent that creates high-quality blog posts and articles",
        url = "https://api.blog-writer.com/a2a/v1",
        version = "1.0.0",
        capabilities = AgentCapabilities(streaming = true),
        defaultInputModes = listOf("text/plain"),
        defaultOutputModes = listOf("text/markdown"),
        skills = listOf(
            AgentSkill(
                id = "write-post",
                name = "Blog Post Writing",
                description = "Generate engaging blog posts on any topic",
                tags = listOf("writing", "content", "blog"),
                examples = listOf("Write a post about AI trends")
            )
        )
    )

  • 通用訊息格式： 所有代理間通訊使用單一標準化訊息格式，統一了請求、回應及更新模式，支援文本 (TextPart)、文件 (FilePart) 和結構化數據 (DataPart) 等豐富內容。

    val message = Message(
        role = Role.User,
        parts = listOf(
            TextPart("Write a blog post about the future of AI agents")
        ),
        contextId = "blog-project-456"
    )
    val request = Request(
        data = MessageSendParams(
            message = message,
            configuration = MessageConfiguration(
                blocking = false, // Get first response
                historyLength = 5 // Include context
            )
        )
    )
    val response = client.sendMessage(request)

  • 任務生命週期： 根據複雜度和時長管理不同類型的工作，包括即時訊息、長時間運行任務和即時更新 (SSE)。
  • 內建安全性： 依賴 OAuth2、API 密鑰和 HTTPS 等行業標準，無需學習新的身份驗證機制。
• Koog 代理與 A2A 整合：
  • 將 Koog 代理封裝為 A2A 伺服器： 定義代理策略，使用 Koog 的轉換器和節點處理 A2A 訊息格式和交換。安裝 A2AAgentServer 特性，使代理可被發現和訪問。

    fun blogpostWritingStrategy() = strategy<MessageSendParams, A2AMessage>("blogpost-writer-strategy") {
        val blogpostRequest by node<MessageSendParams, A2AMessage> { input ->
            val userMessage = input.toKoogMessage().content
            llm.writeSession {
                user {
                    +"Write a blogpost based on the user request"
                    +xml {
                        tag("user_request") {
                            +userMessage
                        }
                    }
                }
                requestLLM().toA2AMessage()
            }
        }
        val sendMessage by nodeA2ARespondMessage()
        nodeStart then blogpostRequest then sendMessage the nodeFinish
    }
    // ... (agent definition and server setup)

  • 從 Koog 代理呼叫其他 A2A 代理： 配置 A2A 客戶端以獲取代理卡片，並在策略中使用 nodeA2ASendMessage 或 nodeA2ASendMessageStreaming 來呼叫這些客戶端。

    val a2aClient = A2AClient(transport = transport, agentCardResolver = cardResolver)
    a2aClient.connect()
    // ... (agent strategy using nodeA2AClientSendMessage)

ReSharper 和 Visual Studio 2026：發布當天即可兼容，遷移步驟和性能提升 🚀

Source: https://blog.jetbrains.com/dotnet/2025/10/02/resharper-and-visual-studio-2026/

• 兼容性： JetBrains 和 Microsoft 合作，確保 ReSharper 2025.2.1 從 Visual Studio 2026 Insiders 發布之日起即可兼容。VS 2026 Insiders 支援與 VS 2022 並行安裝。
• Microsoft 新遷移策略： VS 2026 首次實現向後兼容 VS 2022 擴展，大多數工具將自動遷移。然而，ReSharper 使用 .exe 安裝程式，而非常見的 .vsix，因此最初不支援自動遷移。
• ReSharper 遷移助手： 為解決 .exe 安裝程式的限制，JetBrains 引入了「Migration Assistant」——一個輕量級的 .vsix 擴展。
  • 遷移步驟：
    1. 在 Visual Studio 2022 中安裝 ReSharper 2025.2.2 或更高版本。
    2. 確保已安裝 ReSharper Migration Assistant（可在 Visual Studio Marketplace 找到，或與 ReSharper 捆綁安裝）。
    3. 升級到 Visual Studio 2026 時，在安裝對話框中選擇「Include installed extensions from the Visual Studio Marketplace」。
    4. 啟動 Visual Studio 2026，進入 Extensions | ReSharper Installer | Install ReSharper。
    5. dotUltimate 安裝程式將彈出，允許配置所需工具。重啟 VS 後，ReSharper 即可使用。
• 性能提升：
  • Visual Studio 2026： 針對更快的解決方案載入和更響應的 UI 進行了優化，例如將解決方案載入時間從 14 秒降至約 9 秒 (VS 2022 vs VS 2026)。
  • ReSharper 2025.2： 引入了「Out-of-Process (OOP) 模式」，讓 ReSharper 的分析引擎在獨立進程中運行，減少 IDE 凍結。測量顯示，此模式減少了 Visual Studio 2022 啟動時 UI 凍結達 61%。
• 這些共同的改進使 Visual Studio 2026 和 ReSharper 的整體體驗更加流暢，尤其對於大型解決方案。

推動 PHP 開源向前發展 🐘

Source: https://blog.jetbrains.com/phpstorm/2025/10/moving-php-open-source-forward/

• JetBrains 不僅透過 PhpStorm 支援 PHP 社群，還支持 PHP Foundation、舉辦 PHPverse 活動，並將 Laravel Idea 插件免費開放給所有人。
• JetBrains 宣佈新一輪開源專案贊助計畫，每年將贊助約五個專案和維護者，以使支援多樣化。
• 2025-2026 年度贊助者：
  • Saif Eddin Gmati：開發基於 Rust 的新 PHP Linter 和靜態分析器 Mago。
  • Markus Staab：參與 PHPStan、Rector 和 PHPUnit 等多個現有開源專案。
  • Kyrian Obikwelu：積極探索 PHP 中的 AI 和 MCP 可能性。
  • Sjon Hortensius：負責廣受歡迎的 PHP 線上 Shell 工具 3v4l.org。
• 尋找第五位贊助者： JetBrains 鼓勵社群提出合適人選或專案建議。
• 持續承諾： JetBrains 將持續贊助 PHP Foundation，並鼓勵更多組織加入。
• 舊有贊助專案的調整： 為了支持更多新專案，JetBrains 不再贊助 Derick Rethans (Xdebug) 和 Juliette Reinders Folmer (CodeSniffer) 等長期合作的專案，並鼓勵其他組織接力贊助。
• 強調開源的力量，鼓勵社群共同努力讓 PHP 變得更好。

保護模型上下文協議 (MCP)：代理工作流程中的新 AI 安全風險 🛡️

Source: https://dzone.com/articles/mcp-ai-security-risks-agentic-workflows

• 模型上下文協議 (MCP) 於 2024 年末推出，旨在為 AI 代理連接企業工具、API 和資料庫提供標準化機制，推動代理 AI 革命。
• MCP 類似於 ODBC（Open Database Connectivity），為 AI 代理與企業數據和應用程式的互動提供標準方式。
• 然而，MCP 的強大功能，如雙向通訊、代理功能和工具描述，也引入了全新的安全風險類型，對網路安全專業人員構成挑戰。

插入式分類帳表格的測試更新和可更新分類帳表格的更新理解 📊

Source: https://dzone.com/articles/sql-server-ledger-table-updates-guide

• SQL Server 中的分類帳表格 (ledger tables) 提供防篡改功能，對需要高信任度和可審計性的系統至關重要。
• 插入式分類帳表格 (Insert-only ledger tables)： 嚴格執行不可變性，僅允許添加數據，不可修改或刪除，適用於交易日誌或事件溯源。
• 可更新分類帳表格 (Updatable ledger tables)： 允許修改和刪除數據，但會細緻地維護所有變更的加密可驗證歷史記錄，類似於區塊鏈。
• 文章透過實作示範：
  • 測試插入式表格的更新操作，以確認其限制。
  • 探討可更新表格如何無縫透明地管理更新，並提供實用範例。

AI 基礎設施指南：工具、框架和架構流程 🏗️

Source: https://dzone.com/articles/ai-infrastructure-guide-tools-frameworks-and-archi

• 構建強健的 AI 基礎設施需要理解多層技術的理論基礎和實際實施細節。
• 本指南為規劃、部署和管理各規模 AI 系統提供了全面資源，從實驗原型到服務數百萬用戶的企業級生產部署。
• 現代 AI 應用需要複雜的基礎設施來處理大型語言模型的計算強度、多代理系統的複雜性以及互動式應用的即時要求。
• 挑戰不僅在於選擇正確的工具，更在於理解它們如何跨整個技術堆疊整合，以提供可靠、可擴展和具成本效益的解決方案。

構建實時完整性的 ML 平台 🛡️

Source: https://dzone.com/articles/ml-platforms-for-real-time-integrity

• 大型社交網路面臨著一個普遍挑戰：隨著用戶流量呈指數級增長，如何維護安全可靠的環境。
• 手動流程在高負載下容易崩潰，而臨時的機器學習模型也難以通用化。
• 本文探討了大型平台如何透過開發全面的機器學習基礎設施來應對這一挑戰。
• 強調單一過濾器或獨立模型在規模化時通常難以長期存活。

在 GCP 上構建可擴展且可靠的行銷數據堆棧 📈

Source: https://dzone.com/articles/scalable-reliable-marketing-data-stack-gcp

• 現代行銷的關鍵是乾淨、上下文相關且及時的數據，以推動個性化體驗並實現可量化的成果。
• 對於跨 Google Ads、Meta 和 DSPs 等平台運行數十甚至數百個廣告活動的企業來說，實現此類數據協調的基礎設施至關重要。
• 在 GCP 上擴展行銷數據堆棧不再僅僅是選擇 BI 工具或將少量數據集遷移到雲端。
• 它關乎於架構一個在 GCP 上具備彈性的基礎，該基礎能夠從多個來源攝取廣告活動數據、支持跨時區的分散式團隊，並為即時儀表板提供動力，同時維護治理和運營可靠性。

多雲環境中的基礎設施即程式碼 (IaC)：一致性和安全問題 ☁️

Source: https://dzone.com/articles/iac-multi-cloud-consistency-security

• 研究相關性： 現代組織越來越多地採用雲技術來提高 IT 基礎設施的靈活性、可擴展性和效率。IaC (Infrastructure as Code) 在此過程中扮演重要角色，它允許組織透過程式碼描述基礎設施，自動化部署流程，減少人為錯誤風險，並確保應用程式生命週期各階段的一致性。
• 多雲架構趨勢： 公司趨向於使用多個雲提供商，以分散負載、提高容錯能力，並遵守安全和數據本地化法規。這種方法使組織能夠利用不同雲提供商的優勢，同時最大限度地降低單一提供商帶來的風險。
• 本文將探討在多雲環境中實施 IaC 時所面臨的一致性和安全問題。

解構 IPTables：其內部工作原理與命令和演示 🧱

Source: https://dzone.com/articles/unpack-iptables-inner-workings-commands-demos

• 網際網路早期，數據封包自由傳輸，系統服務預設暴露，導致安全問題（蠕蟲、病毒、未經授權訪問、DoS 攻擊、IP 欺騙等）。
• IPTables： 旨在解決這些安全問題的工具，作為 Linux 核心中的一個防火牆，用於過濾、轉換和操作 IP 封包。
• 文章將深入探討 IPTables 的內部工作原理，包括其鏈 (chains)、規則 (rules) 和目標 (targets)，並透過命令和實際演示展示其配置和應用。

Salesforce Data Cloud：設置和使用攝取 API 🔗

Source: https://dzone.com/articles/datacloud-streaming-ingestion-api

• Salesforce Data Cloud 提供整合解決方案，用於攝取和整合客戶資訊，幫助企業規模化地提供個性化體驗。
• 攝取 API (Ingestion API)： 該平台的核心，簡化了將資訊導入 Data Cloud 的過程。
• 本文深入探討了 Ingestion API 的技術細節，包括其底層模式、實作方式以及將數據攝取到 Salesforce Data Cloud 的建議。
• Ingestion API 是用於攝取到 Salesforce Data Cloud 的 RESTful 端點，提供兩種主要互動模式。

使用 Red Hat Service Mesh 為 CP4I App Connect 中不可用的 API 服務實現斷路器 🚦

Source: https://dzone.com/articles/circuit-breaker-app-connect-red-hat

• 問題： 某些應用程式在高負載下可能因記憶體不足和 CPU 利用率過高而停止響應，因為後端不可用導致請求堆積。
• 解決方案： 使用 Red Hat OpenShift Service Mesh 實現斷路器模式，當應用程式或 API 不健康時，阻止向其發送請求。
• 本文將展示如何在使用 Red Hat OpenShift Service Mesh 和 IBM Cloud Pak for Integration — App Connect API 服務時，實現斷路器模式以應對應用程式無響應的情況。