後端工程師進到企業專案，常常第一次聽到「這要拋 ERP」（把資料送進 ERP）、「要掛進 EIP」，卻沒人說清楚這兩套東西裡面到底有什麼。EIP 就是員工打開電腦、登入公司內網時看到的那個首頁。這篇講它：EIP 到底要有哪些功能，以及一個後端工程師會在哪裡撞到它。
我做電商相關的東西時，有些功能後台真的做了，但不是完整的 ERP，也沒有做在 ERP 裡面。
這不是「怎麼實作一套 EIP」，是**「公司裡有這套東西時，你要接的是什麼」**。
⚠️ EIP 是撞名縮寫：在雲端語境 EIP = AWS Elastic IP（彈性公網 IP），在企業系統語境 EIP = Enterprise Information Portal（企業資訊入口）。本篇講的是後者。
ERP 的模組、一張訂單怎麼在 ERP 裡走、後端接 ERP 會撞牆的地方，在 ERP 在管什麼 寫過了。
EIP：它是聚合層，不是一套系統
員工早上打開公司內網看到的那一頁：公告、待簽的假單、這個月的差勤、找同事的分機、公司文件搜尋。這些資料分別來自 HR 系統、簽核系統、文件系統和 AD。AD（Active Directory）是微軟的帳號目錄，公司每個人的帳號、密碼都記在這裡。EIP 的工作是把它們聚在同一個畫面，並且只登入一次。
聚合層的意思是：自己不太存資料，而是把別的系統的資料拉過來，放在同一個地方給人看。「EIP 是聚合層不是系統」是我理解 EIP 的判斷框架，不是業界的正式定義。但我認為這是多數人搞錯的地方：EIP 本身幾乎不產生資料。
| 功能區 | 內容 | 資料實際來自 |
|---|---|---|
| 單一登入（SSO） | 一次登入打通所有內部系統 | 公司的帳號目錄（AD 或 LDAP） |
| 待辦聚合 | 待簽核、待填、待確認集中一處 | 各系統自己的流程（記錄每張單現在輪到誰處理） |
| 表單與簽核流程 | 請假、加班、請購、申請蓋公司印章，含代理人與加簽（下面解釋） | EIP 自己的流程（少數它真的擁有的東西） |
| 公告與知識庫 | 公司公告、規章、SOP、文件搜尋 | 放網頁內容和公司文件的系統（CMS、DMS） |
| 人事自助 | 差勤查詢、薪資單、個人資料維護 | HR 系統（有些廠商叫 HCM）裡的對應模組 |
| 組織架構與通訊錄 | 誰是誰的主管、分機、部門 | HR 系統，簽核要送給誰，就是照這份走 |
| 入口整合 | 把 ERP、CRM 等系統的畫面放進來，變成一個頁籤或一個連結 | 各系統 |
SSO（Single Sign-On）就是單一登入：在 EIP 登入一次，點進其他內部系統就不用再輸入密碼。負責確認「你是誰」的那一方叫 IdP（Identity Provider，身分提供者），它背後查的就是 AD 或 LDAP 這類帳號目錄（LDAP 是讀寫帳號目錄的通用協定）；各系統和 IdP 之間怎麼傳遞「這個人已經登入了」，多半用 SAML 或 OIDC 這兩套規格。
EIP 的兩個設計難點
- 簽核路徑綁在組織架構上。「送給我的主管」這句話要能執行，組織架構就必須即時且正確。人一調動，那些已經送出、還沒簽完的單子，該走舊主管還是新主管？這是 EIP 最常出事的地方，而它的根因在 EIP 拿資料的源頭：HR 系統裡的組織架構。
- 代理人與加簽讓流程圖爆炸。代理人是你請假時替你簽核的人；加簽是簽到一半，有人要求再多加一位簽核者。再加上「代理人能不能再找代理人」，這幾條組合起來，原本一直線的流程（專員 → 經理 → 人資）就開始長出分岔：經理請假時要改走代理人那條，有人加簽時中間要多插一站。多個流要分開，不要硬塞成一個 status 欄位。硬塞的話，那個欄位會長出「待經理簽」「待代理人簽」「待加簽者簽」「加簽完回經理」這類值，每多一條規則，就多一輪組合，例外情況一多就爆組合。電商系列〈電商訂單狀態機〉那篇把一張訂單拆成五台狀態機，也是同一個道理。
在本機跑起來
以 open source 的 HumHub 為例。它的 Community Edition 是 AGPL-3.0，可以自己架；SAML 登入、公告已讀回條這些功能在付費的 Professional Edition 裡。
我用官方 image 加 docker compose，在本機跑了 HumHub 1.18.6，資料庫用 MariaDB 11.4。建了四個假帳號：IT 管理員、業務部專員、業務部經理、人資專員。
架設時有三件事值得記下來：
- 官方 image 只有 amd64。 amd64 是 Intel、AMD 晶片用的架構；Apple Silicon（M 系列晶片）的 Mac 是 arm64，跑 amd64 的 image 要靠模擬，整體很慢。安裝精靈下載模組那一步曾經逾時回 500，但模組其實已經下載完，重送一次就過了。
- 網址的 port 要跟容器內一致。 HumHub 有即時推播（Mercure，負責把新通知即時推到頁面上），它會拿設定裡的網址，從容器裡面連回 HumHub 自己。設定裡的網址是 18480 port，那是從電腦連進容器用的；但在容器裡面，HumHub 只聽 80 port。拿 18480 從容器裡面連自己，就連不到，Dashboard 每次載入都 500。把容器內外改成同一個 port 才解決。
- 模組裝好不會自動出現。 待辦（Tasks）、Wiki 這些模組在後台裝好之後，每個 Space（HumHub 的團隊空間）還要各自按一次啟用。
走一遍：一個員工的早上
人資在「公司公告」Space 發了一則年終盤點的公告並置頂。業務部經理在「業務部」Space 建了兩個任務，指派給業務部專員。
專員登入後，Dashboard 是這樣：
公告和任務聚在同一頁，右上角的鈴鐺有 2 則通知，就是經理指派的那兩個任務。這就是上面表格裡的「公告」和「待辦聚合」。
但全站的待辦總覽只列 HumHub 自己的任務：
我沒有找到讓外部系統把待辦送進來的機制。也就是說，ERP 裡待簽的請購單，不會自己出現在這裡。
通訊錄（People）可以搜尋，卡片上有姓名和職稱：
HumHub 沒有的兩塊
上面說的兩個設計難點，HumHub 都沒有對應的功能：
- 簽核流程。 在模組市集搜尋 approval，只找到兩個：徵才用的 Job Listings，是第三方付費模組；審核註冊用的 E-Mail Whitelist，在 Professional Edition 裡。最接近表單的是問卷模組 Survey，也是第三方付費，但那是問卷，不是簽核。代理人、加簽更不用說。
- 組織架構。 使用者資料裡沒有「誰是我的主管」這個欄位。最接近的是群組（Group）：它有子群組，也有 Group Manager。但後台的說明寫的是，Group Manager 是用來核准新帳號註冊的，不是簽核主管。
人事自助也一樣：只有個人資料維護，沒有差勤和薪資單。
七個功能區在 HumHub 的狀況：
- SSO：LDAP 是核心內建；SAML 要 Professional Edition；OIDC 沒有設定畫面，要改設定檔。這次只看了設定頁。
- 待辦聚合：官方免費的 Tasks 模組，只聚合 HumHub 內部的任務。有實際操作。
- 表單與簽核：沒有。
- 公告與知識庫：公告是核心功能，有實際操作；Wiki 是官方免費模組，這次只啟用、沒寫內容。
- 人事自助：只有個人資料。
- 組織架構與通訊錄：通訊錄有，有實際操作；組織架構沒有。
- 入口整合：官方免費的 Custom Pages 模組，可以用 iframe（網頁裡開一個框，框裡顯示別的網站）嵌入外部頁面，或放連結。有實際操作。
後端撞到 EIP 的典型場景
你自建的系統要被「掛進」EIP 時，對方通常會要你配合三件事：
- 支援它的 SSO 協定，多半是 SAML 或 OIDC。員工在 EIP 登入過，點進你的系統就不用再登入。
- 提供一個「待辦數量」的 API，讓入口可以顯示紅點。
- 讓你的頁面能被嵌在 iframe 裡。這要調 CSP 和 cookie 的 SameSite 兩個設定，下面實測時會看到為什麼。
HumHub 的 Custom Pages 模組可以把外部頁面嵌進頂部選單，管理員填一個網址就好：
我試著嵌 github.com，畫面是一片空白：
原因在 GitHub 回應裡帶的兩個 header。header 是伺服器回傳網頁時，附在內容前面給瀏覽器看的說明：
X-Frame-Options: deny：告訴瀏覽器「不准任何網站把我放進 iframe」。- CSP（Content Security Policy，內容安全政策）裡的
frame-ancestors：列出「哪些網站可以把我嵌進去」。
瀏覽器看到這兩個，就不讓它被嵌。HumHub 這邊沒有任何錯誤提示。
所以自己的系統要被嵌進 EIP 時，後端要做兩件事：
- 在回應的 CSP 裡允許 EIP 的網域：把 EIP 的網址寫進
frame-ancestors。 - 把登入用的 cookie 設成
SameSite=None; Secure。你的頁面被嵌在 EIP 的網域底下時，對瀏覽器來說，你的 cookie 屬於「另一個網站」，這叫第三方 cookie。SameSite 是 cookie 的一個屬性，決定「在別的網站底下發出的請求，要不要帶上這個 cookie」，設成 None 才會帶；Secure 表示這個 cookie 只在 HTTPS 連線下傳送。這兩個是必要條件，但不一定夠：依 MDN 的說明，Firefox 和 Safari 預設就會限制第三方 cookie，Chrome 預設不擋。所以被嵌進 EIP 的頁面，在 Firefox、Safari 上仍可能拿不到登入狀態，上線前每種瀏覽器都要實際試過。
HumHub 也有官方免費的 REST API 模組（還在 beta）。REST API 就是讓別的程式用 HTTP 網址去讀寫 HumHub 資料的入口；你的系統要反過來跟 HumHub 交換資料時，走的就是它。實測時有一個坑：開了 Basic 認證（每次請求直接附上帳號密碼的驗證方式）之後，還要把帳號加進「Enabled Users」名單，否則一律回 401。401 的意思是「你沒通過驗證」，帳號密碼明明是對的也一樣。
AI 和 MCP 的角色
2026-10 查證時，HumHub 沒有官方的 MCP，GitHub 上也找不到社群做的 HumHub MCP server。要自己接，就是透過官方的 REST API 模組。它的 Bearer token 是綁在一個 HumHub 使用者身上的，一個使用者只能有一把。也就是說，AI 拿的是誰的 token，就是用誰的身分、誰的權限在查。
EIP 跟這個系列的其他系統有一個不同：它有簽核。按下「同意」，代表這個人負責。所以分工是這樣：
- AI 整理，人按同意。 AI 可以把一張單的重點整理好，例如「這張請購單跟過去三張比，金額高了一倍」。但按下「同意」的一定是人，AI 不替人簽。
- 待辦摘要有用，但每一項都要附來源。 早上直接告訴員工「今天有 5 張待簽，2 張急」，比一個紅點數字有用。但每一項都要連回原本的單子，讓人點進去自己看，不是只看 AI 的摘要就簽。
- AI 用發問者自己的權限去查。 這跟知識庫那篇是同一條規則。EIP 聚合了 HR、簽核、文件好幾個系統，如果 AI 用一把管理員的金鑰去查，等於任何能對 AI 發問的人，都拿到了所有系統的管理員視野。
ERP 與 EIP 的分工
ERP 是公司的帳本，EIP 是公司的桌面。 一個管「這件事在帳上怎麼記」，一個管「員工在哪裡看到它、在哪裡按下同意」。
兩者的交會點是組織架構與人：ERP 的 HR 模組多半是組織架構的源頭，而 EIP 的簽核路徑吃的就是那份組織架構。這條線斷掉，兩邊都會壞：例如組織架構沒有同步過去，EIP 的簽核就會送錯人。
想看實作，可以讀這幾套
| 系統 | 授權 | 特色 | AI／MCP 現況（2026-10） |
|---|---|---|---|
| HumHub | AGPL-3.0（另有商業授權） | 企業社群網路，有公告、通訊錄、待辦、嵌入外部頁面；沒有簽核流程 | 沒有官方 MCP，也找不到社群 MCP |
| Frappe | MIT（Frappe HR 是 GPL-3.0） | ERPNext 的底層框架，內建 Workflow，簽核可以套在任何表單上 | 官方 frappe/mcp 170 顆星；社群最多 325 顆星 |
| Nextcloud | AGPL-3.0 | 檔案協作為主，官方 Approval app 可以定義檔案的送審與核可流程 | 官方 Context Agent 提供 MCP server；社群最多 388 顆星 |
| Odoo Community | LGPL-3.0 | 有員工資料、請假、報帳；Approvals（簽核）只在 Enterprise 版 | 沒找到官方 MCP；社群最多 424 顆星 |
星數是 2026-10-20 的數字。