Claude Tag 正式推出：讓 AI 成為 Slack 團隊的共用成員
Anthropic · 2026-06-23
Anthropic 於 2026 年 6 月 23 日發布 Claude Tag，這是一項讓企業團隊在 Slack 頻道中共用同一個 Claude 實例的新功能，目前以 Beta 形式提供給 Claude Enterprise 與 Team 方案客戶。不同於過去各自與 Claude 單獨對話的模式，Claude Tag 讓頻道內所有成員都能看到 AI 的工作進度，並接力交付任務。Anthropic 表示，內部產品團隊已有 65% 的程式碼由其內部版本的 Claude Tag 協助生成。
背景
傳統 AI 助理的最大侷限在於單人、單對話、無持續記憶——每次啟動都要重新交代背景。工程與產品團隊往往花大量時間反覆解釋專案脈絡，而成果也無法讓其他同事直接接手。Claude Tag 的設計目標正是解決這種「AI 孤島」問題，將 AI 嵌入團隊日常溝通流程，而非讓使用者特別切換到另一個工具。
現有的 Claude in Slack 整合將在 30 天遷移期後由 Claude Tag 取代。Anthropic 提供符合資格的組織啟動點數以降低遷移門檻。
核心功能
在 Slack 頻道中輸入 @Claude 即可指派任務，Claude Tag 會在該執行緒中逐步列出工作清單，讓所有頻道成員同步掌握進度。任何人都可以在同一個執行緒中接手、補充或修改任務，形成真正的多人協作。Claude 在執行過程中會保留頻道記憶，無需每次重新說明背景。
開啟「ambient」模式後，Claude 無需被 @mention 也會主動追蹤相關頻道的資訊，並在發現值得關注的內容時主動通知團隊。典型的使用場景包括：
- 從討論串自動產生決策文件或 PR 草稿
- 跨頻道彙整專案進度摘要
- 重現 Bug 並開立 Issue
- 長達數小時或數天的排程任務（非同步執行）
權限與管理架構
Claude Tag 採用頻道為單位的存取控制，而非個人帳號層級。管理員在 claude.ai/admin-settings/claude-tag 集中設定「Access bundle」，一次性綁定特定工作區與頻道所需的憑證（如 Git 倉庫、Datadog 等外部服務）。設定完成後，該頻道的所有成員即可立即使用，無需逐人設定。
管理員可查看活動日誌、設定 Token 消耗上限，並可全組織停用 DM 模式（DM 模式下 Claude 會使用個人 claude.ai 帳號而非組織配置）。底層模型為 Opus 4.8，各頻道可維持獨立的「Claude 身分」，做到資訊隔離。
影響範圍
Claude Tag 代表 AI 助理從「個人工具」演進為「團隊基礎設施」的重要一步。透過統一的頻道記憶與可見的執行軌跡，AI 的工作成果不再是黑盒子，也讓組織能以更系統化的方式衡量與審計 AI 的使用。對工程團隊而言，最直接的影響是非同步任務自動化——無需等待人工執行，Claude 可在下班後繼續處理被交付的工作，早上推送結果。
原始來源：Anthropic News — Introducing Claude Tag、Claude Tag 產品頁面
IBM 開源 CUGA：24 個單檔範例展示企業級 AI Agent 架構
Hugging Face Blog (IBM Research) · 2026-06-23
IBM Research 於 2026 年 6 月 23 日在 Hugging Face 發布技術文章，介紹 CUGA（Configurable Generalist Agent）框架及其配套的 24 個可運行示範應用。CUGA 是一套輕量化的 Agent 執行框架，負責包辦規劃、執行迴圈、工具呼叫與狀態管理等基礎設施，讓開發者專注於定義工具與提示詞。所有範例均以單一 Python 檔案呈現，涵蓋研究、生產力、文件處理、多 Agent 協作等場景。
背景
打造真實可用的 Agentic 應用時，工程師往往花費大量精力在與業務邏輯無關的基礎設施問題上：如何管理超過 20 步驟的長任務狀態、如何讓 Agent 在出錯時自我修正，以及如何整合不同模型後端。CUGA 的設計哲學是將這些共用問題封裝進框架本身，對外只暴露工具定義與提示詞兩個介面。
框架以 pip install cuga 安裝，預設模型為 gpt-oss-120b，但透過單一環境變數即可切換至 Anthropic、watsonx 或 Ollama。
核心架構
CUGA 的執行引擎支援三種推理模式（Fast、Balanced、Accurate），並內建反思步驟（Reflection）——在工具呼叫失敗時，Agent 會暫停、診斷錯誤原因，再重新規劃後續步驟，而非繼續執行錯誤路徑。沙箱執行環境可選擇本機、Docker/Podman 或 E2B 雲端，CodeAct 模式則允許工具呼叫與生成程式碼混合執行。
框架提供六種策略（Policy）用於治理 Agent 行為：
- Intent Guards：根據關鍵字或語意拒絕特定請求
- Tool Approval：在執行高風險操作前暫停等待人工確認
- Tool Guides：引導 Agent 優先使用特定工具
- Playbooks：將已知的最佳執行流程固定下來
- Output Formatters：強制規範回應格式
- Custom Policies：自訂邏輯的逸出口
工具整合與多 Agent 擴展
CUGA 支援四種工具綁定方式：OpenAPI 規格、MCP（Model Context Protocol）伺服器、LangChain 函式，以及帶有 decorator 的 inline Python 函式。多 Agent 架構透過 CugaSupervisor 實現，Supervisor 可將子任務委派給多個專門的 CugaAgent 實例。
示範倉庫 cuga-apps 中的 Ouroboros 是一個由 7 個 Agent 組成的潛在客戶開發系統，展示了多 Agent 協作的完整鏈路。A2A（agent-to-agent）委派功能與 ALTK-Evolve 在職學習機制，讓 Agent 能在執行過程中累積技能。
影響範圍
CUGA 的 24 個範例應用跨越研究自動化（Paper Scout、Wiki Dive）、PDF/音訊/影片 RAG、即時指標監控，以及 IBM 雲端顧問等企業應用場景。對希望快速驗證 Agentic 架構的工程師而言，單檔範例設計大幅降低了學習曲線——每個應用都是完整可執行的參考實作，而非需要組裝的框架骨架。IBM 另有面向生產環境的治理框架 IBM Sovereign Core，與 CUGA 共用相同的 Policy 設計語言。
每週自動發版：Hugging Face 如何用 AI 加人工審核縮短釋出週期
Hugging Face Blog · 2026-06-23
Hugging Face 於 2026 年 6 月 23 日發布技術文章，說明 huggingface_hub 函式庫如何從每 4–6 週手動發版，轉型為全自動每週發版流程。整套系統以 GitHub Actions 為骨幹，結合開放權重模型 GLM-5.2（753B 參數，由 Z.ai 提供）生成 Release Notes，並在人工確認後發布至 PyPI，每次發版成本約 0.25 美元。
背景
手動發版的主要問題有兩個：發版間隔過長導致貢獻者等待數週才能看到自己的 PR 出現在正式版本；以及 Release Notes 品質不穩定——人工撰寫容易遺漏 PR、分類不一致。Hugging Face 的目標是讓流程完全可重複，同時保留人工最終審核以防止 AI 幻覺內容流入正式發布。
流程架構
GitHub Actions 工作流程處理三種發版類型：Minor Prerelease（從 main 建立 RC 分支）、Minor Release（將 RC 升格為正式版）、Patch Release（在現有分支上修復 Bug）。整個流程由八個 Job 串接，涵蓋版本管理、套件發布、AI 生成文件、下游測試與後處理：
- prepare：版本偵測、分支建立、版本號更新、commit 與 tag
- publish-pypi / publish-hf-cli：使用 OIDC Trusted Publishing（PEP 740 attestation），不需長效 secrets
- release-notes：呼叫 OpenCode CLI，以 GLM-5.2 草擬 Release Notes
- test-downstream：在 transformers、datasets、diffusers、sentence-transformers 建立測試分支
- slack-message：發送預發布通知至 Slack 並建立討論串追蹤進度
- post-release：將 main 版本號推進至下一個開發版本
AI 生成 Release Notes 的驗證機制
這套流程最關鍵的設計是「模型起草、確定性程式碼驗證、人工決定」三層機制。Python 腳本從 squash-merge commit 中提取 PR 編號作為事實基準，模型以 PR metadata 起草 Release Notes 後，自動化驗證程式碼比對 PR 清單，若發現遺漏或多餘的 PR，Agent 會重新提示模型修正。
為避免模型虛構不存在的功能，流程將每個 PR 的實際文件 diff 作為 grounding 資料傳給模型。人工審核者在 Prerelease 與 Minor Release 之間有完整時間窗口編輯草稿，PyPI 發布設有 Required Reviewers 審批門檻，確保不會在無人確認的情況下自動推送。
影響範圍
這套流程將貢獻者從提交 PR 到看到版本號的等待時間從數週縮短至一週以內，並透過自動 PR 留言（「shipped in vX.Y.Z」）提供即時回饋。所有工具（GitHub Actions、OpenCode、PyPI Trusted Publishing）均為開放或可自行部署，整體方案可移植至任何 Python 開源專案。每週固定節奏也讓下游使用者（如 transformers）能以更可預期的頻率整合更新。完整工作流程已開放於 huggingface_hub GitHub 倉庫。
原始來源：Hugging Face Blog — Shipping huggingface_hub every week、GitHub Actions 工作流程