「OpenTelemetry」的搜尋結果
#OpenTelemetry也是一個關鍵字標籤
過去 31 天有 1 篇標成這個標籤 · 目前不在排行榜上
11/9（一）
AI代理人協同作業陷瓶頸 專家呼籲統一記憶格式
圖／示意圖商傳媒｜林昭衡／綜合外電報導AI人工智慧發展迅速，其中「AI代理人（AI Agents）」技術逐漸受到關注。然而，這些能獨立執行任務的軟體代理人卻面臨記憶無法共享的困境，嚴重阻礙了跨工具的協同工作。為此，在 Dash0 負責 OpenTelemetry 開發的 Mads Thines 呼籲業界應為 AI 代理人的記憶制定一套共通格式。 根據《LavX News》報導，Mads Thines 指出，目前的程式開發工具儘管能儲存有用的筆記，卻無法可靠地分享資訊，原因在於每個工具都採用了不同的資料綱要（schema）與儲存系統。這導致 AI 代理人所建立的筆記被困在單一工具中，無法被其他編輯代理人或審查機器人存取。Mads Thines 將當前 AI 代理人記憶的現況，比喻為 OpenTelemetry 問世之前的可觀測性（observability）領域：當年各家廠商使用不同的代理程式與資料格式，導致開發者難以整合資料；而 OpenTelemetry 則提供了一套共享的資料模型與協定，讓開發者能一次埋設程式碼，便將資料發送至整個生態系中的工具。 目前，AI 代理人的記憶實作方式五花八門，例如 GitHub Copilot Memory 會將事實與程式碼引用連結，並在 28 天未使用後移除；LangGraph 的 BaseStore 則採用命名空間與鍵值，並可選用生命週期（time-to-live）設定。Graphiti 與 Zep 則將事實建模為圖形邊緣，追蹤事實套用與系統記錄的時間。Mads Thines 認為，這些不同的設計中蘊含許多有價值的概念，若能整合為一套共通格式，將可結合可追溯的來源、明確的過期機制，以及簡潔的鍵值儲存方式。此格式無需強制各系統採用相同的方法來提取、排序或搜尋記憶，保有各廠商的競爭空間。 Mads Thines 提議，共通的記憶紀錄應包含作用範圍（scope）、鍵值（key）、內容、生命週期以及作者資訊，明確標示該記憶是由人類、AI代理人還是提取服務所寫，以利工具評估記憶的可信度。此外，他也建議制定共享的位址層級與屬性名稱規範，以及寫入、讀取、列表、搜尋、歸檔等操作的共通合約。中立組織而非特定廠商應出面協調這項工作，以避免再次加深碎片化問題。他以 LoreKit 的 MIT 授權資料綱要與磁碟儲存格式作為其中一個輸入範本，其離線儲存可寫入 Markdown 檔案，方便開發者檢查與比對。 然而，記憶共享也帶來「提示注入（prompt-injection）」的潛在風險，亦即一個工具寫入的內容可能會影響或操縱另一個工具。為此，Mads Thines 建議記錄作者資訊、支援簽章，並將記憶連結到相關程式碼，讓讀者能檢查變更，以提升安全性。
鴨鴨新聞
商傳媒10/12（一）
GitHub Copilot Agent 部署新模式：從個人應用走向自動化協作，強化開發可見度
圖／示意圖商傳媒｜責任編輯／綜合外電報導隨著人工智慧輔助開發工具日益普及，微軟旗下程式碼代管平台 GitHub 的現場工程師 Jose Palafox，近日提出一套分階段採納 Copilot Agent 的模型，旨在協助企業有效運用這類 AI 代理程式。他強調，將這些 AI 輔助程式深度整合至持續整合（CI）管線（這是自動化軟體開發流程的一部分，能確保程式碼變更能即時測試與整合），是實現成本控制與提升開發流程可觀察性的關鍵。 GitHub Copilot（一款由 GitHub 和 OpenAI 共同開發的 AI 程式開發輔助工具），其提供的 Agent（AI 代理程式）功能，讓開發者能客製化 AI 代理程式以自動執行特定任務。Jose Palafox 指出，Copilot 所有介面，包括整合開發環境（IDE）、命令列介面（CLI）、軟體開發套件（SDK）以及 GitHub.com 上的雲端 Agent，都匯集到名為 CAPI（Copilot API Service）的統一服務，該服務負責處理輸入、傳送模型、過濾輸出、驗證與日誌記錄等工程工作。開發者可透過 CLI 進行輕量化操作，或利用 SDK 將 Agent 嵌入 Slack 或 Microsoft Teams 等應用程式中。 為推動 Agent 的規模化應用，Jose Palafox 提到企業常因缺乏集中儲存庫而建立專屬的 Agent 市集。這些市集透過特殊 JSON 標記的儲存庫構成，不僅能更新、版本控制 Agent，還能發送漏洞通知，實施輕量級套件管理。此外，組織也可設立內部由管理員控制的 .GitHubPrivate 儲存庫，供組織成員共享 Agent。透過重複使用這些 AI 代理程式，可提升快取命中率，進而降低整體開發成本。 然而，Agent 預設只能在其所屬的儲存庫內執行任務。為解決跨儲存庫協作問題，Copilot 應用程式推出了「orchestrate」指令，能將 GitHub Issue 視為目標，並在相關儲存庫中啟動子 Agent。Jose Palafox 強調，將 Agent 工作負載移至 CI 管線的重要性，這能有效解決因 Agent 程式碼品質不佳導致的重複問題，並提供組織層級的可觀察性，避免本地 Agent 工作流的「隱形化」。 這種 Agentic 工作流程可在 GitHub Actions 等 CI 系統中，利用 Copilot CLI 以無頭模式運行，由儲存庫事件觸發。透過 OpenTelemetry（OTel，一套開源標準，用於收集遙測數據）的檢測，每個 Agent 的日誌資料能被發送到資安資訊與事件管理系統（SIEM）等平台進行分析。這不僅能設定警報，當 Agent 成本超出預期上限（如 P90 預期成本，即成本的第 90 百分位數）時進行調查，也能透過 A/B 測試優化模型的成本效益。GitHub 內部也積極實踐 Agentic 開發，其用於建構 Agent 的 AW project 便完全由 Agent 自身建構，而 GitHub Next 旗下的 Agentics 專案更已提供約 30 個可用的管線 Agent。 對台灣的軟體開發者和企業而言，GitHub Copilot Agent 的這套部署模式，提供了一條優化開發效率、強化成本控制與流程可見度的路徑。透過逐步將 AI 輔助程式從個人應用推向自動化、協作化的持續整合環境，台灣產業有望借鑑此經驗，在 AI 輔助開發的浪潮中提升競爭力。
奧丁丁新聞