ECC 不是又一包零散的 AI 編程提示詞，而是一套試圖把 Claude Code、Codex、Cursor、OpenCode、Gemini、Zed 與 GitHub Copilot 類工具拉到同一條工作流軌道上的開源 harness 系統。在 AI coding agent 逐漸從「聊天輔助」走向「可執行、可委派、會修改檔案、會呼叫工具」的階段後，真正麻煩的問題不再只是模型聰不聰明，而是每個工具都有不同的 context 檔案、規則格式、hook 能力、MCP 設定與安全邊界。affaan-m/ECC 的切入點，正是把這些跨工具的操作層整理成可重用的 skills、agents、rules、hooks 與設定慣例。
ECC 是什麼？
ECC 是 GitHub 上由 affaan-m 維護的開源專案，repository 名稱為 affaan-m/ECC。專案自稱為「harness-native operator system for agentic work」與「agent harness performance optimization system」，npm 套件名稱為 ecc-universal，來源資料顯示版本為 2.0.0-rc.1。
用比較實務的說法，ECC 不是單一 IDE 外掛，也不是只給 Claude Code 使用的一份設定檔；它更像是一層跨 AI coding harness 的工作流與操作系統，把常見的開發任務、語言規則、安全檢查、會話管理與工具整合拆成多個可重用元件。來源摘要列出的核心內容包括：
- Skills：可重用的工作流單位，用來承載較耐用、可反覆呼叫的開發流程。
- Agents／subagents：可被主 agent 委派特定任務的子代理，並可搭配工具權限邊界。
- Hooks：在工具呼叫、檔案編輯、提交提示或生命週期事件中插入自動化檢查與處理。
- Rules：跨語言、跨專案的開發規則與指令慣例。
- MCP configs：整理 Model Context Protocol 相關伺服器設定與慣例。
- Cross-harness context files：例如
AGENTS.md、CLAUDE.md、copilot-instructions.md等，協助不同工具讀取一致的專案脈絡。 - 安全與狀態管理：包含 secret detection、sandbox 權限、AgentShield 相關整合、session history、state store 與狀態快照等方向。
為什麼 AI coding harness 需要這種「中介層」？
Claude Code、Codex CLI、Cursor、OpenCode、Gemini、Zed、GitHub Copilot 這類工具表面上都在做 AI 輔助開發，但它們的實作介面差異很大。有些工具支援 hooks，有些只吃 instruction 檔；有些能呼叫 MCP，有些主要依賴 sandbox 權限；有些適合長期會話，有些更像一次性的 CLI 任務。
這會導致三個常見痛點：
- 規則重複：團隊可能在 Claude Code、Cursor、Copilot 與 Codex 各寫一份近似但不同步的 coding guideline。
- 工作流不可攜：在某個工具中整理好的 review、test、refactor、release checklist，很難原封不動搬到另一個 harness。
- 安全邊界不一致：AI agent 可以讀檔、改檔、呼叫 shell、看 PR 內容或處理外部輸出時，每個工具的風險點和防護機制都不同。
ECC 的價值不在於宣稱所有工具功能完全等價，而在於它嘗試把各工具可共用的部分抽象出來：用 AGENTS.md 這類通用 context file 承接共同脈絡，用 skills 承接可重用流程，用 rules 承接語言與團隊規範，用 hooks 在有支援的 harness 裡加入自動化控制，再用 instruction layer 補足 GitHub Copilot 這類較封閉的環境。
它對 Claude Code、Codex、Cursor、OpenCode、Gemini、Zed 與 Copilot 的意義
以 Claude Code 為例，ECC 將 skills、legacy commands、subagents、hooks、rules、MCP 與記憶管理組合成一套偏完整的操作層。來源資料顯示，v2.0.0-rc.1 catalog counts 宣稱包含 60 個 agents、232 個 skills 與 75 個 legacy command shims；在 Claude Code 端還列出 8 種 hook event、20 多個 hook scripts、34 組 common／language rules 與 14 個 MCP servers。
Cursor 的定位則偏向共用 AGENTS.md、共享 commands／skills，並用自己的 hook 事件與 rules 格式銜接。來源表格稱 Cursor IDE 有 15 種 hook types、16 個 DRY adapter hook scripts，以及以 YAML frontmatter 表示的 34 組 rules。這代表 ECC 不是把 Claude Code 設定硬塞到 Cursor，而是透過 adapter pattern 盡量降低重複。
Codex CLI 的狀況更保守。來源的 parity table 明確標示 Codex 目前沒有 hooks；相容性主要依賴 AGENTS.md、可選的 model_instructions_file override、sandbox permissions，以及原生格式的 10 個 skills、7 個可透過 TOML parser 合併的 MCP servers。這點很重要：ECC 不是讓 Codex 突然具備所有 Claude Code hook 能力，而是用 Codex 能接受的介面去承接部分工作流。
OpenCode 則是 ECC 覆蓋較深的另一個面向。來源資料列出 OpenCode 端有 12 個 agents、35 個 commands、37 個 skills、11 種 hook event、13 組 instructions 與 6 個 native custom tools。對已經把 OpenCode 當成 terminal agent harness 的使用者來說，ECC 的吸引力在於能把 Claude Code 端整理出的 workflow 轉成可在 OpenCode 環境使用的版本。
GitHub Copilot 的支援型態較接近 instruction layer，而不是完整 agent／hook／MCP 等價層。來源表格列出 Copilot 主要透過 6 個 prompts、1 個 always-on file、copilot-instructions.md 與 settings.json 來銜接。這也提醒導入者：Copilot 的 ECC 支援應視為「規則與提示層」，不要期待它等同 Claude Code plugin 或 OpenCode plugin。
Gemini 與 Zed 則在來源中被明確列為 ECC 支援或面向的 AI agent harness／開發工具表面；專案檔案中也出現 .gemini/、.zed/ 等路徑，顯示 ECC 的設計目標不是綁定單一產品，而是朝多工具共存的 agentic development workspace 發展。
三份官方指南：從 Claude Code 基礎到 agentic security
ECC 專案同時提供三份值得一起看的指南。本文不放安裝教學，重點放在架構與使用判斷；這三份文件能幫助理解 ECC 為何採用 skills-first、rules、hooks 與安全邊界等設計。
The Shorthand Guide to Everything Claude Code 偏向入門導覽，說明 skills、legacy commands、hooks、subagents、rules、memory、MCP 與 plugin 的角色。它的重點是把 durable workflow 放在 skills，commands 則偏向 slash-entry 相容層。
The Longform Guide to Everything Claude Code 更偏進階實務，聚焦 token economics、memory persistence、verification patterns、parallelization strategies 與可重用工作流。它也談到用 session summary 延續工作、手動 compact、驗證迴圈等做法。
The Shorthand Guide to Everything Agentic Security 則把焦點放在 agentic tool 的攻擊面，例如 prompt injection、惡意文件、GitHub PR review 內容、工具輸出與外部訊息，並提到 sandboxing、sanitization、CVE、AgentShield 與 agent 權限邊界。
Cross-Tool Feature Parity
ECC 的跨工具支援很有企圖心，但不應被解讀為「每個 harness 都有同樣能力」。官方來源提供的 feature parity 更像是一張相容性地圖：哪些工具能跑 agents、哪些工具只能吃 instructions、哪些有 hooks、哪些只能靠 sandbox 或 context file 補足。
| Feature | Claude Code | Cursor IDE | Codex CLI | OpenCode | GitHub Copilot |
|---|---|---|---|---|---|
| Agents | 60 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 | N/A |
| Commands | 75 | Shared | Instruction-based | 35 | 6 prompts |
| Skills | 232 | Shared | 10 (native format) | 37 | Via instructions |
| Hook Events | 8 types | 15 types | None yet | 11 types | None |
| Hook Scripts | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks | N/A |
| Rules | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions | 1 always-on file |
| Custom Tools | Via hooks | Via hooks | N/A | 6 native tools | N/A |
| MCP Servers | 14 | Shared (mcp.json) | 7 (auto-merged via TOML parser) | Full | N/A |
| Config Format | settings.json | hooks.json + rules/ | config.toml | opencode.json | copilot-instructions.md + settings.json |
| Context File | CLAUDE.md + AGENTS.md | AGENTS.md | AGENTS.md | AGENTS.md | copilot-instructions.md |
| Secret Detection | Hook-based | beforeSubmitPrompt hook | Sandbox-based | Hook-based | Instruction-based |
| Auto-Format | PostToolUse hook | afterFileEdit hook | N/A | file.edited hook | N/A |
| Version | Plugin | Plugin | Reference config | 2.0.0-rc.1 | Instruction layer |
Key architectural decisions
- AGENTS.md at root is the universal cross-tool file (read by Claude Code, Cursor, Codex, and OpenCode — GitHub Copilot uses `.github/copilot-instructions.md` instead)
- DRY adapter pattern lets Cursor reuse Claude Code’s hook scripts without duplication
- Skills format (SKILL.md with YAML frontmatter) works across Claude Code, Codex, and OpenCode
- Codex’s lack of hooks is compensated by `AGENTS.md`, optional `model_instructions_file` overrides, and sandbox permissions
這張對照表中最值得注意的架構決策，是 AGENTS.md 被視為 Claude Code、Cursor、Codex 與 OpenCode 可共享的通用跨工具檔案；GitHub Copilot 則改用 .github/copilot-instructions.md。此外，Cursor 透過 DRY adapter pattern 重用 Claude Code 的 hook scripts，skills 則以 SKILL.md 搭配 YAML frontmatter 的方式在多個工具間流動。Codex 由於缺少 hooks，主要靠 AGENTS.md、可選 model instructions override 與 sandbox 權限補足。
v2.0.0-rc.1 與近期版本重點
來源資料顯示，ECC v2.0.0-rc.1 的重點包括表面更新、operator workflows、ECC 2.0 alpha、Dashboard GUI、公開 catalog counts 同步，以及 60 agents／232 skills／75 legacy command shims。它也提到 Tkinter dashboard GUI、Hermes operator story、media／launch tooling，以及位於 ecc2/ 的 Rust control-plane prototype。
較早版本也能看出 ECC 的演進方向：
- v1.9.0：模組化導入架構、6 個新 agents、PyTorch／documentation lookup／Bun／Next.js Turbopack 等 skills、SQLite state store、12 language ecosystems、CI 與 manifest validation 強化。
- v1.8.0：明確定位為 agent harness performance system，重構 hook reliability 與 runtime controls，強化 Claude Code、Cursor、OpenCode、Codex app／CLI 一致性。
- v1.7.0：加入 Codex app＋CLI 支援，並擴大 Cursor、Codex、OpenCode 覆蓋。
- v1.6.0：加入 Codex CLI 支援、AgentShield 整合、ECC Tools GitHub App，以及擴充驗證套件。
- v1.3.0：加入 OpenCode plugin 支援，包含 agents、commands、skills、hook support 與 native custom tools。
不過，rc 與 alpha 字樣也代表導入時不能只看功能數量。特別是 hooks、MCP、secret handling、自動化腳本與 sandbox 權限，任何會讓 AI agent 更接近檔案系統、shell、PR 內容或外部資料的功能，都應該在團隊內先審查再啟用。
安全面：ECC 想解決的不是只有效率
AI coding agent 的風險和傳統 IDE extension 不太一樣。傳統外掛通常由人點擊操作；agentic harness 則可能在讀取文件、審查 PR、解析工具輸出、修改檔案、跑測試、呼叫 shell 時，把外部內容納入模型上下文。這讓 prompt injection、惡意文件、外部輸出污染、secret 洩漏與過度授權變成實際問題。
ECC 在來源中提到 security scanning、secret detection、sandbox 權限、供應鏈掃描腳本與 AgentShield 整合。這些設計方向有其必要性，但也不代表只要使用 ECC 就自動安全。更精準的理解應該是：ECC 提供了一批安全相關元件與慣例，讓團隊能把 agentic security 納入工作流；至於是否適合某個 repository，仍需檢查實際 hooks 行為、會讀寫哪些檔案、會呼叫哪些工具、MCP server 權限與 secrets 處理方式。
誰適合關注 ECC？
ECC 特別適合幾類使用者：
- 重度使用 Claude Code、Codex CLI、Cursor、OpenCode 或其他 AI coding agent 的開發者。
- 想把常用開發流程整理成 skills、agents、rules 與 hooks 的工程團隊。
- 需要在多個 AI 開發工具之間維持一致指令、規則與專案上下文的使用者。
- 關注 prompt injection、secret detection、sandboxing、agent 權限邊界與自動化稽核的團隊。
- 想建立可持續記憶、會話摘要、測試驗證、平行化工作流與多代理協作的進階使用者。
相對地，如果你的使用情境只是偶爾叫 Copilot 補幾行程式，或團隊還沒有準備好審查 hooks、MCP 與 agent 權限，ECC 可能會顯得過重。它比較像是給「已經把 AI agent 當成開發流程一部分」的使用者，而不是單純的程式碼自動完成工具。
授權、商業服務與官方連結
ECC repository 採用 MIT License。依來源摘要，MIT 授權允許使用、複製、修改、合併、發布、散布、再授權與銷售，但需保留著作權與授權聲明；軟體以「AS IS」提供，沒有明示或默示擔保。
開源 repository 與商業／hosted 服務需要分開看。來源指出 README 表示 OSS 會保持免費；ECC Pro 則是面向 private repos 的 hosted GitHub App，標示價格為每席每月 19 美元。另有 ECC Tools GitHub Marketplace 頁面 與 ECC Tools GitHub App，來源描述其提供 PR audits 與 free tier。
可參考的官方／行動連結包括：GitHub repository、README、Releases、Issues、Discussions、npm ecc-universal、npm ecc-agentshield、GitHub Sponsors 與 作者 X 帳號。
編輯觀點：值得看，但不要把它當成零風險捷徑
從 clawhud.com 的角度看，ECC 最值得關注的不是「又多了幾百個 skills」，而是它把 AI coding harness 的問題講清楚了：當開發者同時使用 Claude Code、Cursor、Codex、OpenCode、Gemini、Zed 與 Copilot，真正需要管理的是跨工具的上下文、規則、權限、會話、驗證與安全邊界。
同時，ECC 也需要被謹慎看待。來源中出現的 stars、forks 與 skills 數量很高，但不同頁面與不同時間點可能有落差；第三方目錄頁多半只能證明文件被收錄，不能代表獨立安全稽核或生產環境可靠性。專案自稱 production-ready，但 v2.0.0-rc.1 與 Rust control-plane alpha 仍提醒我們：導入前應把 hooks、MCP、sandbox、secret detection、agent 權限與自動化腳本逐項審查，而不是因為它支援很多工具就直接全開。
一句話總結：ECC 是 AI coding agent 進入多工具、多代理、多規則時代後，很有代表性的「工作流控制層」實驗；它的價值在整合與架構，也因此需要同等嚴肅的安全與維運判斷。