OpenAB 企業控管實作 — 從 config 到部門落地
過去三週講了 W1 破口、W2 trust、W3 四原則。這一週是 abstraction layer 怎麼具體落地：config-driven。
同樣從病房那 2 小時挑最後一個時刻（完整故事見 W1 cornerstone）：
14:00 — Hub deploy 觸發
整篇 W1 cornerstone 被 polish 完之後，Erwin 沒去通知工程師「請手動 deploy」。他開了 git worktree、clone main、commit、push 到 origin/main、GitHub Actions FTP 部署自動觸發。整個過程沒有任何人類介入。
會 work 是因為什麼？config-driven 早就把流程寫死：什麼 push 觸發 deploy、什麼 secret 給 GitHub Actions、什麼 user 有 push 權限。Erwin 只是依著 config 跑。
前端工程師對這個模式不陌生：webpack.config.js、tailwind.config.ts、eslint config 早就是這個模式：用 config 把行為當資料宣告，而不是寫在 code 裡。企業 AI gateway 用的是同一個 idea，只是 scope 從一個前端 codebase 變成全公司。下面講 OpenAB 的 config 模式怎麼落地到部門級。
為什麼 config 是「人類在迴圈裡」的最小保證
Humberto Cervantes（墨西哥 UAM）、Rick Kazman（ATAM 共同發明人、夏威夷大學 / CMU 軟體工程研究所）與 Yuanfang Cai（Drexel 大學）在美國 NSF 贊助下，今年 1 月在 IEEE Software 發表了一篇研究："LLMs as Assistants in Software Architecture Design"（同研究團隊的完整方法論文 30 頁版已被 IEEE TSE 接收）。7 月 1 日 Kazman 在北科大的 SEAT 大師演講中展示了一組非常直接的實驗數據：
Testability 場景的架構設計問題：
所有 LLM 模型 → 100% 選同一個答案（Hexagonal Architecture）
23 位人類架構師 → 8 種不同選擇，其中 21.7% 說「我資訊不夠，不能決定」
LLM 不會質疑自己的選擇。只有人類會說「等等，我不確定」。更關鍵的是：人類架構師不只是「選不同答案」，還經常主動 disagree with 或 distrust LLM 的建議，原因是模型缺乏 context 且回答 inconsistent。這不是能力問題，是信任問題。
Kazman 的結論是：LLMs are not yet ready for autonomous design, but are powerful collaborators. 人類擅長 convergent thinking（在 context + constraints 下做取捨），AI 擅長 divergent thinking（快速產生大量可能性）。正確的契約是：
人類負責目標、結構、取捨、意義。AI 負責速度、一致性、在定義邊界內的執行。
這跟 W1 講的「senior judgement 往上推」是同一件事。
但這裡有一個關鍵問題：「defined boundaries」誰來 enforce？
如果只是口頭契約，agent 被 prompt injection 的那一刻契約就崩了。如果是寫在文件裡的 policy，沒人看。如果是分散在 5 個不同系統的設定，出事的時候兜不起來。
我目前看到最乾淨的答案是：一份 config.toml。
Config 定義 agent 能做什麼 = divergent thinking 的邊界
人類決定 config 長什麼樣 = convergent thinking 的判斷
改 config 不改 code = 治理成本降到最低
Config 可以被 git track、被 review、被 audit = accountability
一份 config.toml = Kazman 說的「defined boundaries」的工程實現。也是 W3 四原則中 Control by Configuration 的具體落地。
OpenAB 不是只有聊天。它的 config-driven 設計天然適合企業 AI 治理。我這幾個月跟幾個團隊 PoC + 自己場景跑下來，注意到的是：真正讓主管放心的不是 agent 多聰明，而是「我能不能在一個檔案裡看到它能做什麼、不能做什麼」。以下整理的是我目前的設法。
OpenAB 可用的控管機制
1. Channel Restriction（頻道隔離）
[discord]
allowed_channels = ["1234567890"]
作用：bot 只在指定頻道回覆，其他頻道完全靜默。
企業用法：
#frontend-ai → 前端 agent 群
#backend-ai → 後端 agent
#marketing-ai → 行銷用 agent
#general → 沒有 agent，純人類討論
一個頻道 = 一個邊界。跨頻道的 agent 互不干擾。 我自己的 baseline 是這個一定要設，因為它是後面所有控管的前提。
2. Bot Message Control（bot 間互動控制）
[discord]
allow_bot_messages = "mentions" # off / mentions / all
值 | 行為 | 用途 |
|---|---|---|
off | 忽略所有 bot 訊息 | 獨立工作的 agent |
mentions | 被 @mention 才回 | multi-agent 協作 |
all | 回所有 bot 訊息 | 全自動 pipeline（有風險） |
企業用法：
前端 code review：5 agent 用 mentions 互相 review
行銷助手：off，只回人類問題，不跟其他 bot 互動
3. Trusted Bot Whitelist（信任名單）
[discord]
trusted_bot_ids = ["erwin_bot_id", "hange_bot_id"]
作用：即使 allow_bot_messages = mentions，也只接受名單內的 bot。
企業用法：
防止外部 bot 注入指令
前端頻道只信任前端的 5 個 agent
後端頻道只信任後端的 agent
4. User Message Control（用戶訊息控制）
[discord]
allow_user_messages = "multibot-mentions"
值 | 行為 |
|---|---|
involved | 自己的 thread 不用 @，channel 要 @ |
mentions | 永遠要 @ |
multibot-mentions | 多 bot 場景，有其他 bot 時要 @ |
企業用法：multibot-mentions 最適合。避免多 agent 場景下搶著回覆。
5. Turn Limit（迴圈防護）
# 內建，不需設定
max_bot_turns = 20 # soft limit
hard_limit = 100 # 絕對上限
作用：bot 之間對話超過 20 輪自動停。人類說話重置計數。
企業用法：防止 agent 無限迴圈燒 token。
前面 5 條都是「誰能跟誰說話」的問題。接下來要處理的是另一個現實：就算溝通管道管好了，agent 佔用的資源也需要一個上限。不然一個失控的 agent 就能把整個團隊的 quota 燒光。
6. Session Pool（資源控管）
[pool]
max_sessions = 5
session_ttl_hours = 24
這解決的問題是：最多 5 個同時進行的對話，24 小時後自動清除。不用人去手動關。
企業用法：
前端團隊 3 人 → max_sessions = 5（留 buffer）
行銷 10 人 → max_sessions = 10
控制每個部門的 AI 使用量
7. Working Directory（檔案存取範圍）
[agent]
working_dir = "/app/frontend-code"
為什麼要這個？agent 只能存取指定目錄，看不到其他程式碼。
企業用法：
前端 agent → working_dir = "/app/frontend"
後端 agent → working_dir = "/app/backend"
agent 碰不到不該碰的 code
8. Environment Variable Control（環境變數控制）
[agent]
env = { COMFYUI_API_URL = "http://localhost:8188" }
# 不傳 DB_PASSWORD、AWS_SECRET 等
為什麼要這個？只傳指定的環境變數給 agent，不是全部。
企業用法：agent 拿不到 DB 密碼、API secret。就算 agent 被 prompt injection，也拿不到機密。
9. CLAUDE.md / Persona（行為定義）
# 你是前端 code reviewer
## 你可以做的
- review React/Next.js code
- 建議效能優化
## 你不能做的
- 不碰後端 code
- 不碰資料庫
- 不回答跟 code 無關的問題
作用：用 prompt 限制 agent 的行為範圍。
企業用法：每個部門的 agent 有不同的 CLAUDE.md，定義能做和不能做的事。
到目前為止都是「agent 被動回應」的控管。但企業場景裡，agent 也需要主動做事：排程跑報告、定時 review PR。這時候問題變成：它什麼時候主動、發到哪裡、誰能關掉它？
10. Cronjob 排程控管
[[jobs]]
enabled = true / false
schedule = "0 8 * * *"
channel = "specific-channel-id"
platform = "discord"
這解決的問題是：排程只發到指定頻道，可以隨時開關。
企業用法：
每天早上 9 點自動 review 昨天的 PR → 前端頻道
每週一產週報 → 管理層頻道
hot-reload，改 toml 不用重啟
11. Lifecycle Hooks（agent 啟動 / 關閉自訂命令，0.8.4-beta.6 起）
[hooks]
pre_boot = "log-agent-start.sh"
pre_shutdown = "log-agent-stop.sh"
作用：agent 啟動前、關閉前可以執行自訂命令，整個 lifecycle 都進 audit trail。
企業用法：
合規行業需要紀錄「agent 何時上線、誰啟動的」 —
pre_boot寫進 SIEMagent 關閉前同步狀態給 monitoring →
pre_shutdown自動執行配合 Helm
serviceAccountNameper-agent（0.8.4-beta.4 起），agent 身份、啟動時間、操作軌跡全部從 config 可控
12. ghpool 整合（agent 打 GitHub API 統一走代理）
如果 agent 需要打 GitHub API（CI bot、code review agent），統一走 ghpool — PAT token 池化、依剩餘 rate limit 自動分配、Mutation 透傳保持身份清晰。agent 不直接拿 GitHub token，從 K8s Secret 動態載入。
前面 12 條解決的是「agent 在執行期間的邊界」。但還有一個更根本的問題沒回答：如果 agent 死了怎麼辦？如果它跑在 spot instance 上被回收了、如果 container OOM 了、如果 region 掛了 — 你的 agent 的記憶跟狀態去哪了？
13. pre_seed / pre_shutdown — Stateless Agent（v0.9.0-beta.6 起）
這個功能看起來很小（從 S3 拉 zip 解壓），但它解決的是企業大規模部署 AI Agent 的根本問題：Agent 應該是 stateless 的。（白話說：agent 死掉不用哭，3 秒重生，什麼都沒丟。）
12-Factor App 早就告訴我們答案：Factor III（Config 存在環境中）、Factor VI（Process 是 stateless 的）、Factor IX（快速啟動、優雅關閉、可隨時銷毀）。如果你用過 Heroku 或 Cloud Run，你已經活在 12-Factor 裡了。AI Agent 也是 process，不應該依賴本地 state 來運作。
完整 lifecycle 現在長這樣：
hooks.pre_seed → hooks.pre_boot → (agent running) → hooks.pre_shutdown
pre_seed 做的事：
Agent 啟動時，從 S3 拉 zip 解壓到 $HOME
支援多層覆蓋（像 Docker layers）
S3 native checksum 自動驗證完整性
Layer 1: s3://corp/base-policies.zip ← 全公司合規政策
Layer 2: s3://corp/team-backend.zip ← 後端團隊共享 memory
Layer 3: s3://corp/agent-alice.zip ← 這個 agent 的個性化設定
pre_shutdown 做的事：
Agent 關閉前，tar $HOME（排除 .cache / node_modules / .rustup / .cargo 等）→ sync 回 S3
Agent 變成真正的 cattle not pets — 隨時可以殺掉重建，零資料遺失
對企業意味著：
一個 image 跑所有 agent — 差異化靠 seed layers，不靠 image rebuild
秒級 scale — ECS Fargate spot 被回收？重啟 pre_seed 3 秒恢復
合規審計 — S3 versioning + CloudTrail = 完整的 config 變更歷史
災難恢復 — S3 cross-region replication，agent 換 region 也能跑
Multi-cloud — 底層是標準 S3 API，Cloudflare R2（免 egress 費）/ MinIO（air-gapped）都支援
Production-ready AI Agent = Stateless + Fast Recovery + Observable。跟 12-Factor App 一樣的道理，只是這次跑的不是 HTTP server，而是一個會思考的 process。
最後一條比較特別。前面 13 條都是「限制 agent 做什麼」，但企業有些場景是反過來的：你希望 agent 默默在旁邊聽，不搶話，但關鍵時刻能插一句有用的。跑了三個月下來，我自己覺得這個模式對「知識流失」的問題特別有效：團隊討論的東西不會再消失在聊天記錄裡。
14. Ambient Mode — 環境模式（v0.9.0-beta.6 起）
[ambient]
enabled = true
[ambient.discord]
channels = ["你的頻道ID"]
Ambient mode 讓 bot 被動監聽指定頻道中的所有訊息，不需要被 @mention。Bot 觀察對話流，只在它認為有價值的時候才回應；沒什麼好補充的就回傳 [NO_REPLY]，完全靜默。
關鍵行為：
Bot 緩衝訊息，每 60 秒（或累積 10 則）才送給 LLM 判斷一次
LLM 選擇回應或
[NO_REPLY]（不回就不會出現在頻道中）有人 @mention bot，立即切回正常即時回應模式
可在
~/.openab/config/ambient.md自訂判斷標準
企業用法：
Team channel 的「技術顧問」— 平時只聽，發現技術錯誤或有人問問題才回
Compliance observer — 監聽是否有人貼敏感資料
知識庫同步 — 聽到重要討論自動摘要寫入 knowledge base
14 條控管講完了。但 config 寫好之後，agent 要跑在哪裡？這不只是 infra 問題，部署模式決定了你的安全邊界長什麼樣。選錯部署模式，前面 14 條 config 的保障會被打折扣。
部署模式選擇 — POD 模式（v0.9.0 起）
⚠️ Update：NVIDIA OpenShell 自 v0.9.0 起停止支援。原有 OpenShell sandbox 的安全保障（process / filesystem / network isolation）由 K8s native security context + network policy + secret injection 取代。POD 模式現在是唯一的部署路徑。
POD 模式下的安全機制：
K8s SecurityContext — runAsNonRoot、readOnlyRootFilesystem、drop ALL capabilities
Network Policy — namespace-level egress allowlist，只放行需要的 endpoint
Secret Injection — 透過 K8s Secrets / External Secrets Operator 注入，agent code 看不到 raw value
pre_seed / pre_shutdown — stateless + S3 備份，隨時可銷毀重建
Audit — sender_context + lifecycle hooks + K8s audit log
講了 14 條聽起來很多。但實際上每個部門的 config 大概就 10-15 行。下面直接看真的長什麼樣。
部門配置範例
以下以一家寵物科技公司為例（情境示範），示範如何按部門切 config。這套切法不限於特定產業——金融、製造、SaaS 都適用，差別只在 working_dir 跟 env 的內容。
前端團隊
# 5 agent multi-review 模式
[discord]
allowed_channels = ["frontend-code-review"]
allow_bot_messages = "mentions"
allow_user_messages = "multibot-mentions"
trusted_bot_ids = ["erwin", "hange", "armin", "mikasa", "eren"]
[agent]
working_dir = "/app/frontend"
env = { NODE_ENV = "development" }
# 不傳任何 secret
[pool]
max_sessions = 5
後端團隊
# Claude + 地端 Qwen3（可能碰到機密資料）
[discord]
allowed_channels = ["backend-ai"]
allow_bot_messages = "off"
trusted_bot_ids = []
[agent]
working_dir = "/app/backend"
env = { DB_HOST = "readonly-replica" }
# 只給 read-only DB，不給 write
[pool]
max_sessions = 3
AI Team
# Claude + Gemini Pro（需要大 context）
[discord]
allowed_channels = ["ai-research"]
allow_bot_messages = "mentions"
[agent]
working_dir = "/app/ai-models"
[pool]
max_sessions = 3
session_ttl_hours = 48 # 研究對話可能很長
行銷團隊
# 只回答問題，不寫 code
[discord]
allowed_channels = ["marketing-ai"]
allow_bot_messages = "off"
allow_user_messages = "involved"
[agent]
working_dir = "/app/marketing-docs" # 只有文件，沒有 code
env = {} # 不傳任何環境變數
[pool]
max_sessions = 10 # 行銷人多
SDET 團隊
# Claude + Codex（快速產 test）
[discord]
allowed_channels = ["sdet-testing"]
allow_bot_messages = "mentions"
[agent]
working_dir = "/app/tests"
[pool]
max_sessions = 5
上面這幾組 config 我跑了大概三個月，橫跨 5 個部門場景，目前還沒遇到事故——但這只是我這個取樣下的觀察，不代表絕對安全，每個團隊還是要視自己的 threat model 微調。我自己的感受是，config 最大的價值不是防住 100% 的問題，而是出事的時候你 30 秒就能定位是哪一行設定沒蓋到。
控管總覽
┌─────────────────────────────┐
│ OpenAB Instance │
│ │
│ config.toml 定義： │
│ ├── 哪個頻道 │ → Channel Restriction
│ ├── 信任哪些 bot │ → Trusted Whitelist
│ ├── bot 間怎麼互動 │ → Message Control
│ ├── 能看哪些檔案 │ → Working Directory
│ ├── 拿到哪些變數 │ → Env Control
│ ├── 最多幾個對話 │ → Session Pool
│ ├── 行為邊界 │ → CLAUDE.md
│ ├── 啟動/關閉 hooks │ → Lifecycle Audit
│ └── 排程與 GitHub 代理 │ → Cronjob + ghpool
│ │
│ 全部 config-driven │
│ 全部可審計 │
│ 改 config 不改 code │
└─────────────────────────────┘
跟 OpenClaw 的差異
控管機制 | OpenAB | OpenClaw |
|---|---|---|
頻道隔離 | config 一行 | 沒有 |
Bot 信任名單 | trusted_bot_ids | 沒有 |
檔案存取範圍 | working_dir | full disk access |
環境變數控制 | 指定傳哪些 | 全部暴露 |
Session 限制 | max_sessions | 沒有 |
迴圈防護 | turn limit 20/100 | 沒有 |
行為定義 | CLAUDE.md | 可以但沒有強制 |
Audit trail | Discord/Slack thread | 個人帳號裡 |
OpenClaw 給 agent 一切。OpenAB 只給 agent 該有的。
寫到這裡你可能注意到一件事：上面每一條 config 都不是什麼新概念。如果你是前端工程師，這些 pattern 你每天都在用，只是換了一個名字。這讓我開始想：誰最適合擁有 AI agent 的治理？答案可能比你想的近。
前端的下一個角色：Frontend Deployment Engineer
W1 講到「每一波技術轉變都讓分開的職責被整合成新角色」，Data Engineer、DevOps、SRE、Platform Engineer 都是這樣冒出來的。這一波 AI，我看到的下一個整合角色是 Frontend Deployment Engineer。
為什麼是前端？因為這篇講的 14 條 config + deployment mode 選擇，每一條都是前端工程師已經熟悉的 pattern：
config.toml=webpack.config.js/next.config.ts— 用宣告式設定控制行為Channel Restriction = route-based code splitting — 不同路徑載不同東西
Working Directory = monorepo workspace boundaries — 每個 package 只看到自己的 scope
Environment Variable Control =
.env.localvs.env.production— 分環境給不同變數Session Pool = connection pooling / rate limiting — 控制併發
Lifecycle Hooks =
postinstall/prebuild— npm script lifecyclePOD vs OpenShell = Vercel Edge vs self-hosted Docker — deployment target 的選擇
前端工程師本來就在做 deployment 的事：CI/CD pipeline、preview environments、feature flags、A/B testing infrastructure、CDN cache invalidation。這些加上 AI agent 的 config-driven governance，就是 Frontend Deployment Engineer 的 scope。
這個角色的職責：
Agent 編排 — 哪個部門用哪些 agent、config 怎麼切、怎麼 review
部署拓撲 — POD / OpenShell / hybrid 怎麼選、egress policy 怎麼配
Developer Experience — 讓工程師安全地用 AI，不需要每次問 DevOps
Observability — token usage、session metrics、audit log 的 dashboard
治理自動化 — config change → PR → review → deploy，跟前端現有 CI/CD 同一條 pipeline
W1 說「每一波都是抽象層往上加一層」。前端從「寫 DOM」推到「寫 Component」推到「寫 Config」推到「管 Agent + Deployment」。Frontend Deployment Engineer 與其說是新職稱，不如說是前端工程師在 AI 時代自然的上移方向。
如果你現在已經在管 CI/CD、寫 Helm chart、配 Vercel / Cloudflare Workers — 你離這個角色只差「把 AI agent 的 config 也納入你的 deployment pipeline」這一步。
四篇串起來
週 | 核心問題 | 答案 |
|---|---|---|
W1 | AI 把工程價值歸零了嗎？ | 沒有。成本從 code 層推到判斷層（歷史節奏） |
W2 | 判斷層的瓶頸是什麼？ | 信任 — 誰下令、誰負責、資料外洩怎麼辦 |
W3 | 信任的架構解是什麼？ | 四原則 — Control / Security / Accountability / Portability |
W4 | 四原則怎麼落地？ | Config-driven — 一個檔案解決一個部門的 AI 治理 |
從 Cervantes、Kazman 與 Cai 的學術研究到工程實踐，結論相同：人類掌控目標與邊界，AI 在邊界內執行。Config 就是那個邊界的物理形式：可被 review、audit、version control，也可以被一行改掉。
Config 本身不 fancy，但它是我目前看到最乾淨、最容易跟法遵解釋的一條路。
→ wchung.tw/blog/openab-series
資料來源
學術研究
H. Cervantes, R. Kazman, Y. Cai, "LLMs as Assistants in Software Architecture Design", IEEE Software, Jan. 2026. (DOI: 10.1109/MS.2026.3663353)
H. Cervantes, R. Kazman, Y. Cai, "An LLM-assisted approach to designing software architectures using ADD", IEEE TSE, 2026. 30 pages. (DOI: 10.1109/TSE.2026.3706446; NSF Award #2232720, #2213764)
Rick Kazman, "Better Together: How Humans and AI Can Co-Create Software Designs", SEAT 大師演講, 北科大, 2026-07-01.
Humberto Cervantes, Rick Kazman, "Designing Software Architectures: A Practical Approach", 2nd Edition, Pearson (SEI Series in Software Engineering).
前三篇引用的延續
W1：a16z、Darktrace 2024、IBM 2024、CSA 2026、Google DeepMind Big Sleep
W2：EchoLeak CVE-2025-32711、Salesforce ForcedLeak CVSS 9.4、NVIDIA OpenShell / Computex 2026
W3：Rubrik 2026 NHI Report、Cloudflare AI Gateway、Portkey、LiteLLM、Helicone、OpenRouter 市場對照
