Human SOP
寫給人看的流程文件。人會用經驗補上例外、優先順序與「大家都知道」的默會知識。
- 主要讀者
- 人
- 常見問題
- 規則藏在腦中，文件更新慢
01 / LAYERS
先分清楚三個層級
Human SOP、Skill 與 Agentic Workflow 不是三種名稱，而是從「人怎麼做」一路走到「系統如何完成整件事」的三個層級。
Skill
一個界線清楚的能力單元，包含何時使用、判斷規則、參考資料，以及必要時可執行的腳本。
- 主要讀者
- Agent
- 合理範圍
- 一次負責一類明確任務
Agentic Workflow
把多個步驟、Skill、工具、資料與人工決策點串成一條完成任務的流程。
- 主要目標
- 從輸入一路產出可驗收結果
- 核心設計
- 節點、Artifact、規則與控制點
02 / BOUNDARY
問題往往不在模型，而在任務太大
一句「幫我優化整個流程」把判斷、搜尋、操作與驗收全塞在一起。即使結果看起來完整，也難以知道哪一段可靠。
Mega Agent
一個 Agent 從頭做到尾，中間決策缺少明確介面。
出錯時難以定位是哪一段推理或工具呼叫出了問題。
修改時常得重寫整段 Prompt，容易影響原本正確的部分。
驗收時只能看最後結果，很難逐步檢查。
VS
可組合 Workflow
每個節點只處理一個明確問題，靠結構化 Artifact 串接。
出錯時可以從 Log 與中間產物找到問題節點。
修改時只調整失準的規則、Skill 或工具。
驗收時每一步都有成功條件與人工檢查點。
03 / METHOD
四步把 Human SOP 轉成 Workflow
每一步都應留下看得見的產物。沒有產物，就很難驗證流程是否真的變得更清楚。
01Standardize
格式標準化
把散文式 SOP 改成 Agent 可判讀的規格：抽出參數、標示規則強度，並把步驟、錯誤處理與輸出格式分區。
MUST
不能省略的硬規則例如：執行前必須驗證申請人身分。
SHOULD
原則上要做若有充分理由可例外，但要留下原因。
MAY
視情況採用不影響核心正確性的選配行為。
Input現有 SOP、使用情境與例外經驗
Action參數化、規則分級、區塊化
Deliverable結構化 Agent SOP v1
02Decompose
拆成節點，用 Artifact 串起來
每個節點都要能獨立執行、獨立驗收、獨立替換。上一個節點的輸出，必須成為下一個節點不用猜的輸入。
Input結構化 SOP 與完整任務目標
Action定義節點邊界、輸入輸出、成功標準
Deliverable流程圖與 Artifact Schema
03Iterate
用真實執行找出默會知識
第一版不會完整。讓流程在低風險資料上跑，觀察 Agent 哪裡誤判，再把原本只存在人腦裡的條件補回規格。
寫 v1先求能跑，不假裝一次完美。
小量執行用真實但低風險案例測試。
看 Artifact找出誤判發生在哪個節點。
補規則把隱藏的判斷寫進 SOP。
再測一次確認問題修好且沒有新回歸。
Input第一版流程與代表性案例
Action執行、觀察、修規則、回歸測試
Deliverable錯誤紀錄、測試集與 SOP v2+
04Integrate
接上工具，也接上控制點
工具讓 Agent 能讀取資料或執行動作；人工確認、權限、記錄與停止條件，則讓流程保持可控。MCP 是連接外部能力的協定，不會替你設計整條工作流。
Input已驗證的節點、權限需求與風險分級
Action接工具、限制權限、加 Log 與人工閘門
Deliverable可觀測、可停止、可回復的流程
04 / CASE
案例：公司內部請求分類
表單、Email 或通訊軟體送來的請求，常需要分類、判斷優先級、找負責人與草擬回覆。這類重複工作適合先做成窄而清楚的流程。
Internal Request Triage
示意資料，不含真實公司資訊1
讀取請求
保留原文、來源、時間與必要識別欄位。
2
分類
輸出 IT、HR、Finance 或 Other，並附信心程度。
3
補充資訊
若內容不足，產生兩至三個具體釐清問題。
4
回覆草稿
根據分類與 SLA 產生回覆，不直接送出。
5
確認與寫回
高權限、財務或低信心案件先由人確認。
Artifact A
request.normalized.jsonArtifact B
triage.result.jsonArtifact C
reply.draft.md05 / PRACTICE
從一件最無聊的重複工作開始
先挑每週都在做、規則大致穩定、失敗風險可控制的工作。第一版只要能省下一部分時間，不必一次追求全自動。
一頁工作表
把答案寫清楚，再決定要用哪個 Agent、模型或工具。
- 先縮小任務邊界。
- 先定義輸出，再寫步驟。
- 先保留人工確認，再逐步放寬。
Task哪一件重複工作最耗時間？開始與結束在哪裡？
Inputs流程一定需要哪些資料？哪些資料可能缺漏？
Artifacts每一步要留下什麼結構化輸出，下一步才不用猜？
Rules哪些是 MUST、SHOULD、MAY？例外怎麼處理？
Acceptance什麼情況算成功？要用哪些案例驗證？
Human Gate哪些動作涉及權限、金錢、外部溝通或不可逆變更？
06 / REVIEW
上線前的六項檢查
流程不是能跑就算完成；還要能理解、能追蹤、能停止，也要知道失敗後怎麼恢復。
1
邊界明確每個節點只處理一類任務，沒有偷偷接管整條流程。
2
輸入輸出固定Artifact 有 Schema、必要欄位與錯誤格式。
3
成功可以驗證每一步都有可測量的接受條件與代表性案例。
4
過程可以觀察保留執行紀錄、中間產物、錯誤原因與版本。
5
權限最小化讀取與寫入權限分開，只開放任務真正需要的能力。
6
人仍能接手高風險、低信心與例外情況會停下來等待確認。
07 / SOURCES
來源與延伸閱讀
本頁以原始內容為主軸，再用官方資料核對技術名詞與設計邊界；不是逐字轉錄。
Protocol
Model Context Protocol ArchitectureMCP 的 Host、Client、Server，以及 Tools、Resources、Prompts
官方文件 →範圍說明：本教材整理的是工作流設計方法。實際導入時仍需依資料敏感度、權限、法規、錯誤成本與使用平台調整；MCP 解決的是標準化連接，不等於自動提供安全、驗收或流程治理。