AI 協作與擴充

從與 AI 協作出發：掌握工程觀念，把固定流程整理為 Skills，以 MCP 連接外部工具，再設計多 Agent 協作。

初次接觸？先看聊天、代理人與工作模式的差異 →

內容核對：2026/10/19。以官方文件釐清概念；案例為文件研究，未逐一安裝實測。

先把任務、背景資訊與驗收條件交代清楚，建立可用的 AI 協作流程；當方法逐漸固定，就整理成 Skill。需要連接外部資料與操作時，再處理 MCP 整合；出現可分工的任務後，才評估多 Agent 的控制與協調方式。

依使用需求安排閱讀順序，各層可獨立採用或組合。下方保留技術比較、工程取捨與原始文獻。

四種工程觀念，分別在處理什麼？

與 AI 合作，先看四個基本問題：指令如何表達、上下文如何組織、工作由什麼環境執行，以及如何反覆驗證並停止。Prompt、Context、Harness 與 Loop 分別關注這些問題，實作範圍會重疊。

用「請 AI 修好一個網站錯誤」來比較
觀念關注的問題簡單例子
提示詞工程
Prompt Engineering		指令、目標與輸出要求怎麼說清楚？說明錯誤、預期行為與驗收條件。
上下文工程
Context Engineering		每一步需要哪些資訊，哪些應保留、取回或移除？提供相關程式、錯誤紀錄與專案規則，避免無關資料擠滿上下文。
執行環境工程
Harness Engineering		代理透過什麼工具、權限與狀態管理把工作做完？讓代理讀檔、修改與跑測試，並管理執行結果及操作確認。
迴圈工程
Loop Engineering		何時啟動、如何驗證並繼續，以及何時停止或交回人？修改後跑測試，失敗就帶回結果再修；通過即結束，超過次數或預算就停下回報。

Loop Engineering 是新興用語，尚未形成一致的分類標準。這裡著重任務的觸發、驗證、狀態與停止規則；研究也區分這種任務層迴圈，與 Harness 內部原有的模型／工具往返。它可以搭配單一或多個代理人。

上面的網站例子是本站的說明示例；單靠 AI 自評「完成」不足以驗收，仍應使用測試或明確檢查條件。

Skills：把固定流程封裝成技能

與 AI 協作一段時間後，反覆使用的任務規則可以封裝為 Skills：把操作流程、範例與參考資源整理成可按需載入的能力單位，減少每次重新交代的成本。

封裝時要定義觸發條件、必要輸入、工作步驟、輸出格式與驗收標準。Skill 提供工作方法；工具可用性與操作權限仍由執行環境決定，跨產品使用也需檢查相容性。

Skills 技能庫與推薦 →

前往獨立頁面，查看官方技能庫、社群技能與搜尋目錄。

整理自己的工作方法 →

將反覆工作整理成技能，定義步驟、範例與驗收方式。

本站延伸閱讀

MCP：把工作流程接到外部工具

當流程需要查詢文件庫、存取工作系統或執行外部操作，可透過 MCP 建立標準化連接，讓支援的 AI 應用取得伺服器提供的資料與功能。

例如：文章查證 Skill 定義流程，代理人透過 MCP 查詢資料來源、取得證據並回傳引用。整合時要確認資料範圍、讀寫權限、回傳格式與失敗處理；已有內建工具或直接 API 連接時，也能沿用。

Hook：在指定時機自動檢查與接續

當固定流程需要在特定事件發生時自動執行，就可以使用 Hook，例如危險指令執行前阻擋、個資與密鑰送出前檢查，也可用於改檔後格式化或等待輸入時通知。

各家產品開放的觸發時機、可執行動作與阻擋能力不同；也要區分聊天網站、CLI、桌面與雲端環境。先選一個明確需求，再查目前產品支援的事件。

    多 Agent 協作架構

    當單一代理的流程與工具已能運作，而任務開始需要平行探索、領域上下文隔離或獨立審查，就需要評估多代理分工。設計重點是控制權、通訊拓樸、任務依賴與共享狀態；子代理只是其中一種實作機制。

    先區分「誰控制誰」「工作如何排程」「如何交換與裁決結果」。這些面向可以組合，例如中央主控搭配平行研究、共享證據表與獨立審查。

    依設計面向比較；以下模式可以組合，並非互斥分類
    面向與模式控制與資訊流適用性與工程取捨
    控制拓樸一主多工Supervisor / Orchestrator–Worker主控負責拆解、委派及整合；專家完成子任務後回傳。適合可分割任務；瓶頸在主控規劃、整合能力與上下文容量。
    控制拓樸階層式Hierarchical總協調者、團隊主管與執行代理分層管理；中間層也有派工權。適合多團隊與局部專業分工；增加交接、延遲與摘要失真。
    控制拓樸對等／去中心Peer-to-Peer / Decentralized協作決策分散，各代理依局部資訊與通訊協定協調；不必全互連。適合分散探索；需處理任務認領、衝突解決及全局停止。
    控制權轉移交接式Handoff目前代理將控制權與必要狀態移交另一位專家，由後者接續。適合跨領域連續互動；交接不同於呼叫子代理後取回結果，也不必然去中心。
    工作流流水線／工作圖Pipeline / DAG / State Graph以階段、依賴、分支及匯合編排代理和程式節點；有循環時不再是 DAG。適合明確流程與驗收門檻；須定義狀態合併、退回及重試規則。
    發言調度群聊與動態選角Group Chat / Speaker Selection代理在共享對話內發言，由規則或選角器決定下一位。適合互動討論；群聊不代表無主控，且對話歷史與回合成本會增長。
    互動策略產生／審查與辯論Generator–Critic / Debate提出候選、交叉質疑或依準則修訂，再由明確規則裁決。適合挑錯與比較分歧；共識不是正確性證據，須有外部驗證或基準。
    結果聚合投票／候選整合Ensemble / Mixture-of-Agents先產生多份候選，再投票、評分或逐層整合；MoA 與模型內 MoE 不同。適合增加候選多樣性；相關錯誤與聚合偏差仍存在，且需要更多推論。
    共享狀態共享黑板Blackboard代理共同讀寫問題狀態與中間產物，調度器依狀態選擇後續工作。適合累積共同證據；需處理版本、寫入衝突與資料可見範圍，可搭配多種拓樸。

    子代理、Skills 與協作架構的關係

    子代理是可委派工作的執行單位，常用於主控式或階層式架構；它是否獨立保留狀態、能否再派工及彼此傳訊，取決於實作。Skills 是可載入的工作規則與知識，載入多個 Skills 不等於產生多個代理。

    比較方案時，需固定或明列模型、工具及推論預算，再量測成功率、延遲、成本與錯誤傳播。下方技術導讀逐項列出原始文獻、選型條件與限制；不以單一 benchmark 排名架構。