harness engineering for your team

原始來源與檔名：2026-08-18T095611+0800-harness engineering for your team.md

SOURCE | 資訊源評估

準確性: 高 - 作者精準地抓住了 AI Agent 在從「單兵作戰」走向「團隊協作」時所面臨的架構與管理痛點。
易理解性: 高 - 透過客服、開發者和 HR 的具體案例，生動解釋了共享 Agent Harness 的風險與價值。
閱讀策略建議: 重點理解文章中指出的三個核心衝突點（上下文污染、權限管理、規則衝突），並反思自身團隊在使用 AI 工具時是否遇到類似問題。

NAPKIN | 餐巾紙

餐巾紙公式

Team Harness = Solo Harness - Personal Blind Spots + Governance (Code Review for Rules) + Role-based Access Control 最適合單人的 AI 設定，往往是最糟糕的團隊設定。單人設定是「日記」，團隊設定則是「憲法」。

一句話

將 AI Agent 擴展給團隊使用時（Harness Engineering），必須解決上下文污染、權限越界與規則衝突的問題，並建立將個人 AI 技巧提煉為團隊共識的管理機制。

餐巾紙草圖

From Solo to Team Harness
+-------------------------+         +-------------------------------+
| Solo Harness (Diary)    |         | Team Harness (Constitution)   |
| - 1 User, 1 Intent      |         | - N Users, Conflicting Intents|
| - Private Shorthand     |  ====>  | - Explicit Official Rules     |
| - Implicit Permissions  |         | - Role-based Permissions      |
| - User's Rule is Law    |         | - Governance / Rule PRs       |
+-------------------------+         +-------------------------------+
                                         |
                                         v
                                  +-------------------------------+
                                  | Harness Engineering Work      |
                                  | - Resolve contradictions      |
                                  | - Promote best practices      |
                                  | - Gatekeep the baseline       |
                                  +-------------------------------+

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

核心問題: 為什麼在單人工作上表現完美的 AI Agent 環境（Harness），一旦開放給整個團隊使用就會崩潰？
核心答案: 因為單人環境隱含了個人的偏好、縮寫與無形的權限；當多人共享時，會出現上下文污染、權限失控與指令衝突。因此，團隊的 Harness 需要像軟體程式碼一樣，建立審查與治理機制。
論證結構: 提出論點（最好的單人設定是最差的團隊設定） -> 解釋什麼是 Harness -> 深入探討三個核心痛點（上下文、權限、規則衝突） -> 探討知識共享的雙刃劍 -> 重新定義工程師/管理者的工作。

章節骨架

What changes when the harness is shared: 從單一負責人（Principal）變成多位具備不同意圖、權限的負責人。
Your context file stops being your memory: 個人的筆記充滿縮寫和未明說的規則，作為團隊的共享知識庫會導致混亂。
Permissions shift from tool to person: Agent 本身的權限管理必須轉變為基於提問者角色的存取控制（例如 HR 與 Manager 詢問薪資資料的結果應不同）。
A correction becomes a ruling: 多人修改指令會產生衝突（如：保留還是刪除贅字），AI 會出現搖擺不定，需要治理機制來決定誰的規則說了算。
Improvement stops compounding in private: 團隊共享的好處是最佳實踐可以迅速普及，但壞處是錯誤的規則也會瞬間污染所有人。
What your job becomes: Harness Engineering 從「寫 Prompt」變成了「治理規則」，像管理生產環境程式碼一樣管理 AI 環境。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

單人的 AI Harness 是圍繞單一使用者的盲點與習慣打造的 --> 開放給團隊使用時，AI 面臨多個主體（Principals）的矛盾指令與隱含權限 --> 導致 AI 無法判斷該聽誰的，甚至洩漏敏感資訊 --> 因此需要 Harness Engineering，建立類似 Pull Request 的審查機制來管理 AI 的規則基線 (Baseline)。

關鍵證據

權限問題 (Permissions): 舉例 Microsoft 365 Copilot 在企業推廣時，高達 40% 延遲上線。因為 Copilot 讓過去多年來未被嚴格管理的共享資料夾（如薪資檔案）變得瞬間可被任何員工輕易搜尋到。
規則衝突 (Correction becomes ruling): 開發者 Olivia Craft 的案例，全域指令要求嚴格的 TypeScript，而專案指令要求寬鬆原型，導致 Claude 毫無規律地在兩者間跳轉。
知識共享乘數效應: 一個業務員解決「價格太貴」的優質應對話術，只要放入團隊 Harness，隔天所有業務（包含新人）的 Agent 都能直接使用。

隱形假設與邊界

隱形假設:
- 團隊使用的 AI 是一個中心化的共享 Agent (或共享同一份底層系統 Prompt/Context 檔案)，而不是每個人完全獨立的實體。
- 團隊具備建立規則審查（如 GitHub PR 機制）的工程文化。
邊界條件: 若團隊極小，或是每位成員的工作完全不相交（如設計師與後端工程師使用不同的獨立 Agent），則這種共享 Harness 的衝突會較少發生。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

作者盲點: 文章主要討論了規則的治理，但沒有深入探討技術上如何實作這種「角色級聯上下文（Role-based Context Cascading）」，即如何讓 AI 動態組合全域規則與個人特有規則。
知識連接:
- 「單人日記到團隊憲法」的轉換，與程式設計中從「寫一次性 Script」到「編寫團隊維護的軟體專案」是完全一致的進化過程。
- Harness Engineering 本質上就是 Policy as Code (規則即代碼) 的延伸。
行動觸發: 在公司導入企業級 AI（如 Copilot）前，必須先做一波全面的權限盤點與資料清洗；團隊共用的 System Prompt 必須放入版本控制系統 (Git)，任何人修改都要過 Code Review。

留白提問 (Guided Reflection)

提問：當團隊意見分歧時，如何決定 AI Agent 的最終規則（例如 Coding Style）？
- 架構師視角 (引導思路)：這不再是 Prompt Engineering 的問題，而是組織治理（Governance）的問題。需要有一個 Owner（如 Tech Lead）擁有最終裁決權，確立不可逾越的 Invariants（不變式）。
提問：如何在享受團隊共享知識的同時，保留個人使用 AI 的靈活性？
- 架構師視角 (引導思路)：架構上需要分層。底層是 Team Baseline（憲法，如資料安全、品牌語氣），上層允許掛載 Personal Layer（個人習慣，如排版偏好）。當兩者衝突時，Baseline 優先。

跨域映射

在 DevOps / 軟體工程，這叫 配置管理 (Configuration Management) 與存取控制 (RBAC)。

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

Permissions shift from tool to person
- 「A team manager asks the same thing, and the agent has to refuse… This is the wall Microsoft 365 Copilot rollouts hit at industry scale. The access problem was already there. The shared agent made it searchable.」
- 推薦理由: 極其銳利的洞察。揭示了企業導入 AI 時最大的阻力通常不是 AI 不夠聰明，而是 AI 讓過去隱藏在混亂資料夾中的權限漏洞瞬間被放大。
Improvement stops compounding in private
- 「Treat the shared baseline like production, because that’s what it is now. A solo harness you can break and fix in private. A team harness you break for everyone at once.」
- 推薦理由: 重新定義了 AI Prompt 的地位。在團隊環境中，修改 Prompt 就是在修改「生產環境 (Production)」，必須受到嚴格把關。

STRUCTURE MAP | 全書結構圖

Harness Engineering for Teams
+-- 1. Concept Definition
|   +-- Harness: Environment wrapped around AI (tools, memory, rules)
|   +-- Solo Harness = Personal, Diary
|   +-- Team Harness = Shared, Constitution
+-- 2. Three Major Failure Modes
|   +-- Context as Memory:
|       - Private shorthand becomes confusing official truth
|   +-- Permissions (Tool -> Person):
|       - RBAC needed (HR vs. Manager)
|       - Unmasks existing messy file access permissions
|   +-- Conflicting Rulings:
|       - Opposing instructions cause unpredictable AI behavior
|       - Need for invariants & ownership
+-- 3. Compounding Improvements
|   +-- Upside: One person's good idea becomes team baseline
|   +-- Risk: Bad rules infect the whole team instantly
+-- 4. Paradigm Shift (The New Job)
    +-- From "Writing Prompts" to "Governing the Baseline"
    +-- Treat shared rules like production code (PR reviews)

harness engineering for your team (Architectural Deep Dive)

前言/背景

隨著 AI Agent 逐漸進入企業，許多人發現自己精心調教的「超強 AI 助理」一旦分享給團隊，就會頻繁出錯。本文提出了 Harness Engineering (環境/外圍工程) 的概念，探討將 AI 從單人工具轉換為團隊協作系統時，所面臨的結構性衝突與管理挑戰。

章節詳細總結

1. 什麼是 Harness 與共享的改變

Harness 指的是包覆在 AI 模型外圍的一切：它讀取的指令檔案、可以呼叫的工具、保持的記憶體，以及對輸出的檢查機制。
在單人模式下，Harness 是為你量身打造的，容忍了你的盲點與習慣。
一旦變成團隊共享，AI 就必須同時面對多個擁有不同權限與意圖的「主體 (Principals)」，此時原本為單人服務的模型就會陷入混亂。

2. 共享 Harness 的三大痛點

上下文不再是私人記憶: 優秀客服的私人筆記充滿了縮寫和「不用明說的潛規則」。當這些筆記變成團隊共享的知識庫時，其他不具備相同背景知識的同事（或他們的 AI）就會產生誤解。
權限從「工具級別」轉向「角色級別」: 同樣問一句「資深工程師的薪資帶是多少？」，AI 必須回答 HR，並拒絕 Team Manager。微軟 365 Copilot 在企業推廣時遭遇重大阻力，正是因為 AI 讓公司內部多年來混亂、設定錯誤的共享資料夾瞬間變得「可輕易搜尋」。AI 沒有製造權限問題，它只是暴露了問題。
修正變成了「法令衝突」: 如果兩個編輯對同一個 Agent 下達相反的指令（一個要刪除贅字，一個要求保留以維持節奏），AI 無法同時滿足兩者，會出現隨機搖擺。這時必須有「人類的治理決策」來決定誰的規則是「團隊憲法」。

3. 知識共享的雙刃劍與管理

優勢: 當業務員發現一個處理客訴的絕佳話術，只要加入團隊 Harness，隔天全團隊的 Agent 都能具備這個能力，產生巨大的乘數效應。
陷阱: 一條錯誤的折扣規則只要被寫入，也會瞬間污染所有人的系統。
解法: 必須將共享的 AI 規則（Baseline）視為「生產環境 (Production)」。任何新增的規則必須經過類似軟體工程的 Pull Request (PR) 審查流程，由負責人批准後才能上線。

總結與結論

個人的 AI 調教是一門「手藝」，你只要讓 AI 懂你即可；但團隊的 Harness Engineering 則是一門「制度管理」，你需要決定誰有權限存取什麼、當規則衝突時誰說了算。
人類在 AI 協作中依然不可或缺，只是判斷的層級提高了：你不再需要花時間去微調單個輸出，而是花時間去「治理」整個團隊 AI 運行的環境基線與邊界。