核心命題： 當 AI Agent 為你生成一份深度調研報告，你如何知道它真的走了完整的分析流程？如何知道結論是基於年報數據而非幻覺？Skill Reporting 用一行文字給出答案——而它的安裝方式，只是一條寫在 RULES.md 裡的規則。
方法論： 黑箱問題診斷 → 一行摘要設計 → 制度性技能哲學 → 前後對比實測 → 間接效應分析 → 一行安裝
前言：你信任一個你看不見的東西嗎？
想像這個場景：
你讓 AI Agent 分析一間港股公司，它花了 30 秒，給了你一份 2,000 字的調研報告。
報告看起來很專業——財務數據、業務分析、風險評估，樣樣俱全。
但你內心有一個揮之不去的疑問：
它是真的搜索了最新年報，還是直接憑訓練數據編的？
這不是一個「性能問題」。LLM 的幻覺率已經降到個位數，推理速度也足夠快。這是信任問題。
而信任，是最難用 benchmark 量化的東西。
一、黑箱問題：AI Agent 最大的信任危機
1.1 你的 Agent 在做什麼？
現代 AI Agent 的核心能力是「工具調用」——它可以搜索網絡、讀取文件、查詢數據庫、調用 API。一個典型的港股調研流程涉及 8-15 次工具調用，橫跨多個技能。
但問題來了：
用戶只看得到最終輸出，看不到中間過程。
| 你知道的 | 你不知道的 |
|---|---|
| 最終報告的內容 | Agent 用了哪些工具 |
| 報告看起來專業 | 數據來源是否可靠 |
| 結論似乎合理 | 是否跳過了關鍵步驟 |
這就是「黑箱問題」：輸入和輸出之間的過程完全不可見。
1.2 市場數據：透明度是第三大障礙
這不是我們的臆測。市場數據證實了這一點：
| 數據來源 | 發現 |
|---|---|
| Deloitte 2026 | 透明度是企業採用 AI Agent 的第三大障礙（僅次於安全性和成本） |
| VentureBeat | 可審計性被列為 Agent 生產部署的首要需求 |
| 行業調查 | 僅 20% 企業有成熟的 Agent 治理機制 |
| 用戶行為 | 「不知道 Agent 做了什麼」是用戶流失的主因之一 |
換句話說：不是 AI 不夠聰明，是它不夠透明。
1.3 現有方案的局限
市面上有一些嘗試解決透明度的方案：
| 方案 | 問題 |
|---|---|
| Session 日誌（JSONL） | 只有開發者能讀，普通用戶無法理解 |
| 可觀察性平台（LangSmith 等） | 需要額外付費、額外安裝、額外學習 |
| 詳細過程輸出 | 淹沒最終答案，用戶不想看 50 行調試信息 |
| 手動文檔 | 靠人維護，一定會過時 |
所有這些方案都有一個共同問題：太重了。它們需要安裝額外的軟件、學習新的界面、支付額外的費用。
有沒有一個方案，輕到不需要安裝任何東西？
二、Skill Reporting：一行文字的設計哲學
2.1 核心思路
Skill Reporting 的方案簡單到令人驚訝：
在每次 Agent 回覆的末尾，自動附加一行技能使用摘要。
格式統一到只有一行：
> 🛠️ 使用技能：skill-A（用途）+ skill-B（用途）+ tool-C（用途）
就一行。不多，不少。
2.2 格式規範
這一行由三個要素組成：
| 要素 | 說明 | 示例 |
|---|---|---|
| 前綴 | > 🛠️ 使用技能： |
固定格式，可識別 |
| 技能名稱 | 使用的技能或工具名稱 | ak-sdd-list, ak-financial-analyst, firecrawl-search |
| 用途說明 | 括號內的簡短說明 | （港股調研）, （搜索年報）, （財務分析） |
| 分隔符 | + |
連接多個技能 |
為什麼選擇這個格式？
- 一行：不會淹沒主要內容，用戶一眼掃過即可
>前綴：在 Markdown 中渲染為引用塊，視覺上與正文分離- 🛠️ 表情符號：快速視覺識別，無需閱讀文字就能知道這是技能摘要
- 括號用途：讓用戶理解每個技能的具體貢獻，而非只看到技能名
+分隔符：清晰區分不同技能，避免混淆
2.3 制度性技能：不需要程式碼的技能
這是 Skill Reporting 最顛覆性的設計選擇：
它不是一個軟件包。它是一條規則。
傳統的「技能」需要安裝程式碼、配置依賴、處理版本衝突。Skill Reporting 只需要在 RULES.md 中加入一條永久規則：
## R18：每次回覆附帶技能使用信息
每次回覆末尾附帶「> 🛠️ 使用技能：」清單。永久，不可跳過。
就是這樣。 沒有 npm install，沒有 pip install，沒有 docker compose。
這引出了一個重要的設計概念：制度性技能（Institutional Skill）。
制度性技能的核心洞察是：在 AI Agent 的世界裡，規則和程式碼具有同等的執行力。Agent 會讀取 RULES.md 並嚴格遵守其中的每一條規則。因此，一個設計良好的規則可以產生與一段程式碼完全相同的效果——但成本為零。
| 傳統技能（程式碼） | 制度性技能（規則） |
|---|---|
| 需要編寫/測試/部署 | 只需要寫一行 Markdown |
| 有版本衝突風險 | 零依賴 |
| 需要持續維護 | 寫一次，永久生效 |
| 僅限特定平台 | 跨所有 AI Agent 平台 |
三、實戰對比：同一場景，有天壤之別
3.1 場景：港股公司調研
以一次典型的港股調研為例——分析 00928 帝王國際投資。
❌ 無 Skill Reporting
Agent 回覆：
帝王國際投資（00928.HK）主要從事白酒銷售、保健產品及放債業務。2025 財年收入約 HK$2.1 億，同比增長 15%...
用戶收到這份報告時，完全不知道：
- 這個收入數據是從年報來的，還是 LLM 編的？
- Agent 有沒有搜索最新的市場新聞？
- 財務分析是基於什麼模型？
用戶只能選擇相信——或者不相信。
✅ 有 Skill Reporting
Agent 回覆：
帝王國際投資（00928.HK）主要從事白酒銷售、保健產品及放債業務。2025 財年收入約 HK$2.1 億，同比增長 15%...
🛠️ 使用技能：ak-sdd-list（港股信息搜索）+ ak-financial-analyst（財務分析）+ firecrawl-search（搜索最新新聞）+ dd-checklist（盡職調查清單驗證）
區別一目了然：
| 維度 | 無 Reporting | 有 Reporting |
|---|---|---|
| 數據來源透明度 | 0%（完全黑箱） | 100%（每個技能可見） |
| 用戶信任建立 | 靠信仰 | 靠驗證 |
| 流程可審計性 | 需要翻 Session 日誌 | 看最後一行 |
| 新用戶第一印象 | 「這東西可靠嗎？」 | 「哦，它做了這麼多步驟」 |
3.2 更多場景對比
| 場景 | 無 Reporting | 有 Reporting |
|---|---|---|
| 收到市場分析報告 | 「數據哪來的？」 | 「看到了，用了 DI + 年報搜索 + 新聞」 |
| Debug 出錯 | 翻 50K tokens 的 Session JSONL | 看最後一行，定位出錯的技能 |
| 新用戶評估 Agent | 需要閱讀文檔才知道能力範圍 | 每條回覆都在展示能力 |
| 團隊協作 | 同事不知道 Agent 怎麼得出結論的 | 技能摘要可被審查和討論 |
| 合規審計 | 無法證明盡職調查流程 | 技能清單 = 審計軌跡 |
四、間接效應：超出預期的設計紅利
Skill Reporting 的設計初衷是「讓用戶看到 Agent 做了什麼」。但在實際使用中，它產生了三個意想不到的間接效應。
4.1 Agent 自我約束效應
這是最令人驚訝的發現。
當 Agent 知道每次回覆都要在末尾列出使用的技能時，它會產生一種「自我約束」行為：
Agent 不會跳過技能，因為它知道跳過的技能會在摘要中缺席。
這是一種「通過透明性實現的問責制」。Agent 不是因為程式碼限制才走完整流程，而是因為「會被看到」才走完整流程。
具體表現：
- Agent 在使用工具前會更謹慎地考慮「這個技能是否必要」
- 減少了「跳步」行為（跳過某些看似可選但實際重要的步驟）
- 增加了技能使用的一致性（同類任務使用相同的技能組合）
4.2 Debug 時間 10 倍縮短
在沒有 Skill Reporting 的環境中，Debug 一個 Agent 錯誤的流程是：
- 打開 Session JSONL（可能 50K+ tokens）
- 搜索工具調用記錄
- 逐條檢查每個 tool call 的參數和結果
- 定位問題步驟
- 修復
平均耗時：10-30 分鐘。
有 Skill Reporting 後：
- 看最後一行技能摘要
- 發現某個技能缺失或參數異常
- 直接定位到對應的 Session 段落
- 修復
平均耗時：1-2 分鐘。
| Debug 步驟 | 無 Reporting | 有 Reporting |
|---|---|---|
| 定位問題技能 | 遍歷所有 tool call | 看最後一行 |
| 確認流程完整性 | 手動比對預期流程 | 一眼看出缺失 |
| 時間成本 | 10-30 分鐘 | 1-2 分鐘 |
4.3 信任的複利效應
信任不是一次建立的，是累積的。
| 互動次數 | 無 Reporting 的信任狀態 | 有 Reporting 的信任狀態 |
|---|---|---|
| 第 1 次 | 觀望：「這東西行不行？」 | 好奇：「哦，它用了這些技能」 |
| 第 5 次 | 猶疑：「每次都是黑箱」 | 驗證：「每次都有清楚的來源」 |
| 第 20 次 | 麻木：「就這樣吧」 | 信任：「它從不偷懶」 |
| 第 100 次 | 習慣性依賴但內心不確定 | 深度信任，願意交給更重要的任務 |
每一次回覆末尾的那一行，都是一次「信任存款」。
五、設計原則：制度性技能的四大法則
從 Skill Reporting 的設計中，我們提煉出制度性技能的四條通用法則：
法則一：規則即程式碼
在 AI Agent 的世界裡，規則和程式碼等價。Agent 會讀取並嚴格遵守規則。與其寫一個複雜的 middleware 來攔截輸出，不如寫一條規則讓 Agent 自己執行。
法則二：最小化負擔
制度性技能的價值在於「零安裝成本」。如果一條規則需要 50 行配置和複雜的條件邏輯，它應該變成程式碼。好的制度性技能應該是「一行規則」。
法則三：可見即問責
當行為可見時，執行者會自我約束。這不僅適用於人類，也適用於 AI Agent。透明的輸出格式本身就是一種質量保證機制。
法則四：格式決定效用
同一條信息，格式不同，效用天差地別。Skill Reporting 的 > 🛠️ 格式之所以有效，是因為它：
- 在視覺上與正文分離（Markdown blockquote）
- 可被正則表達式快速解析（用於自動化審計）
- 人類可讀（不需要工具輔助）
六、跨平台支援：一行安裝
Skill Reporting 不依賴任何特定平台。它是一個純規則的設計，可以安裝在任何 AI Agent 系統中。
安裝步驟
Step 1： 創建技能目錄並下載 SKILL.md
mkdir -p skills/skill-reporting && curl -sSL https://raw.githubusercontent.com/Bryan-cmf/agentic-infrastructure/main/skill-reporting/SKILL.md -o skills/skill-reporting/SKILL.md
Step 2： 在 RULES.md 中加入永久規則
## R18：每次回覆附帶技能使用信息
每次回覆末尾附帶「> 🛠️ 使用技能：」清單。永久，不可跳過。
完成。 沒有第三步。
支援的 Agent 平台
| 平台 | 支援狀態 | 備註 |
|---|---|---|
| OpenClaw | ✅ 原生支援 | 規則系統原生支援 RULES.md |
| Claude Code | ✅ 支援 | 通過 CLAUDE.md 規則系統 |
| Cursor Agent | ✅ 支援 | 通過 .cursorrules |
| GitHub Copilot | ✅ 支援 | 通過 .github/copilot-instructions.md |
| 任何遵循 rules-based 的 Agent | ✅ 理論支援 | 只要 Agent 會讀取規則文件 |
七、與其他透明度方案的協同
Skill Reporting 不是要取代其他透明度方案，而是與它們互補：
| 方案 | 作用 | 與 Skill Reporting 的關係 |
|---|---|---|
| Skill Reporting（本方案） | 用戶端透明度：每次回覆可見 | 基礎層 |
| Session JSONL | 開發者端可審計性：完整過程記錄 | 深度層 |
| LangSmith / LangFuse | 平台級可觀察性：性能監控 | 監控層 |
| Agent Audit 技能 | 定期自動審計：合規檢查 | 治理層 |
四層互補，形成完整的 Agent 透明度矩陣。但 Skill Reporting 是唯一的「零成本入門層」——任何人都可以在一分鐘內安裝。
八、結論：最簡單的方案，最深刻的影響
Skill Reporting 用一行文字解決了一個價值數十億的問題：AI Agent 的信任赤字。
它的設計哲學可以濃縮為一句話：
不需要讓 Agent 更聰明，只需要讓 Agent 更透明。
當用戶能看到 Agent 的每一步，信任就不再是信仰問題，而是驗證問題。
而最令人驚嘆的是：這一切的實現成本，只是一條寫在 RULES.md 裡的規則。
延伸閱讀
- 子代理隔離架構：AI 金融應用的可靠性教訓 — 上下文污染問題的系統性解決方案
- AI 記憶調用的工程學：四路存取路徑 × 十大場景全矩陣實測報告 — 記憶系統的工程設計
- Skill Reporting GitHub Repository — 技能源碼與安裝指南
🛠️ 使用技能：read（讀取 SKILL.md 源文件）+ write（撰寫 MDX 文章）+ exec（查詢目錄結構）