從治理到執行：POG Task 設計與 MVP

如果治理無法觸及執行，它就只是理論。

為什麼 POG Task 必須是「可執行格式」

在前一篇文章中，我們確立了一個前提：Prompt Orchestration Governance (POG) 若無法約束實際執行，就無法成立。

但治理不能停留在原則或抽象模型。它必須能回答實際的問題：

• AI 現在正在執行哪一個任務？
• 這個任務的狀態與脈絡是否可被人類理解？

POG Task v1.1.0 的存在正是為了回答這個問題。

POG Task v1.1.0 並不是一個完整的任務系統。它刻意只滿足三個條件：

1. AI 可以直接讀寫
2. 人類可以直接審查
3. 狀態可被工具呈現，但不被工具控制

這導出了 v1.1.0 的整個設計邏輯。

實體結構：檔案即真理

在討論工具之前，我們必須先看資料存在哪裡。POG Task v0 實施嚴格的檔案結構，以確保可移植性與可審查性。

目錄結構

系統完全存在於您的 codebase 中，通常在 pog-task 根目錄下：

pog-task/
├─ README.md                                # 根文件
├─ task.schema.json                         # YAML 格式校驗定義
├─ pog-task-agent-instructions.md           # AI Agent 的「協定」
├─ pog-task-design.md                       # 系統設計
└─ list/                                    # 任務列表 (按專案/模組分層)
    └── {project}/
        └── {module}/
            ├── {task-title}.yaml           # 結構化狀態流 (State)
            └── record/{uuid}/record.md     # 執行紀錄與推理日誌 (History)

• list/{project}/{module}/*.yaml: 這是「需要做什麼」的結構化意圖。
• record/{uuid}/record.md: 這是「發生了什麼」的推理與執行日誌。

為什麼 POG Task 使用 YAML 作為任務載體

在 v1.1.0 中，我們選擇了 YAML 這是基於可讀性與嚴謹性的考量。

它同時滿足：

• 結構化意圖：支援巢狀結構與複雜的檢查清單。
• 人類與 AI 友善：YAML 格式極易閱讀與編輯，減少解析幻覺。
• 嚴格校驗：透過 JSON Schema 確保每一個任務都符合規範。
• Git 連動：與 Git、diff 和 review 流程完美契合。

任務的最小結構

一個 POG Task 只關心「可治理的事實」，例如：

type: task
id: "h7a8b9c0-d1e2..."
title: "Improve task governance clarity"
status: "in_progress"
created_at: "2026-02-01T10:32:00Z"
checklist: 
  - task: "Update documentation"
    done: false

這不是單純的工作流，而是 結構化意圖 (Structured Intent)。

為什麼 Task 與 Record 必須分離

POG Task 明確區分兩種資料：

• Task List (YAML)：現在有哪些意圖存在？
• Record (Markdown)：這個任務是「如何被執行的」？

因此，每一個 Task 都會對應一個獨立的執行紀錄檔案（例如 record/{uuid}/record.md）。

• 執行步驟
• 決策理由
• 中途修正
• 完成條件判定

這讓治理不再依賴「聊天記憶」，而是依賴可重讀的事實紀錄。

POG Task v1.1.0 沒有專屬的 Web UI。第一個人類介面選擇了 VS Code，原因非常務實：

1. 開發者與 Agent 頻繁在此協作。
2. 原生支援檔案系統與目錄語意。
3. Plugin 可以「觀察輔助」，而不「接管邏輯」。

Plugin 概覽

POG Task Manager 擴充套件設計為一個被動的觀察者，將您的任務狀態視覺化，而不擁用資料。

取得 POG Task Manager Plugin

1. Explorer View（檔案總管視圖）

Plugin 不強迫您閱讀原始 YAML，而是在側邊欄提供結構化的樹狀視圖（Tree View）：

• 分組：任務會自動依 project 和 module 分組。
• 狀態指示：圖示清楚顯示任務是 todo、in_progress 還是 done。
• 情境：intent 顯示為主要標籤。

2. Task ↔ Record 導航

這是核心的「治理動作」。

• 點擊任務：立即分割編輯器。
  • 左側：YAML 檔案。
  • 右側：對應的 record.md 檔案。
• 如果 record 不存在，plugin 會提示從標準範本建立，確保每次執行都具備完整的推理脈絡。

3. 執行對齊（Execution Alignment）

• 複製 Prompt：一鍵動作，為您的 AI agent 生成「交接 Prompt（Handoff Prompt）」。這個 prompt 包含任務情境與更新 record 的指令，橋接了任務定義與 AI context window 之間的落差。

Plugin 「不做」什麼

為了維持「治理優先」的哲學，plugin 有嚴格的界線：

• 沒有拖放狀態變更：您不能將任務拖到「完成」。您必須更新底層檔案或 record。
• 沒有隱藏資料庫：所有資料都只是文字檔。如果您移除 plugin，您的任務仍是 100% 可讀的。

LLM Agent 在 POG 中的角色

在當前架構中，LLM Agent 負責：

1. 讀取任務意圖
2. 領取與執行指定任務
3. 將推理過程與產出物寫入 record
4. 更新任務狀態與檢查清單

Agent 不擁有任務狀態的最終詮釋權。它只負責留下足夠的線索，讓人類可以理解。

Agent 的操作協定：pog-task-agent-instructions.md

為了確保 Agent 行為可靠，POG 建立了一套嚴格的「協定（Protocol）」，記錄在 pog-task-agent-instructions.md 中。這不只是文件，而是每個 Agent 在行動前必須閱讀的 操作說明書。

該協定的重點包括：

1. 分層路徑規則：
   • pog-task/list/{project}/{module}/{task-title}.yaml
2. 狀態轉移協定：
   • 認領（Claiming）：Agent 必須將狀態更新為 in_progress，並填寫 claimed_by。
   • 歷史（History）：每個關鍵動作必須追加到 history 中。
3. 「意圖優先」與「Record 永久化」：
   • 建立任務後，必須立即初始化 record.md。
   • 原始意圖：必須將使用者的原始需求記錄在 record.md 中，防止執行偏離。

這套協定將 AI 執行的「黑盒子」轉變為可預測、可觀察的過程。

結語：v1.1.0 是一道治理防線

POG Task v1.1.0 並不試圖讓 AI 更快。它的存在，是為了確保：

在 AI 開始「自主代理」之前，我們仍然擁有完整的治理視線。

YAML 與 VS Code Plugin 不是美學選擇；它們是治理立場的具體化。

10. 路線圖與未來工作

最完整的內容 : https://enjtorian.github.io/pog-task/zh-tw/