用 Claude + MCP 重寫整個公司的 Ops：BotsUP 真實 stack 拆解

BotsUP 把整個公司的 Ops（策略、專案、商業、內容）全部重寫成 4 個 MCP server，Claude 是第一公民。這篇透明拆解我們的 stack、tool 設計、AI agent 使用模式與踩過的坑。

用 Claude + MCP 重寫整個公司的 Ops：BotsUP 真實 stack 拆解

我是 Vincent，BotsUP 的 founder。過去 10 個月我把整間公司的內部系統重寫一次，核心決策只有一個：AI Agent 是 first-class user，不是事後加上的 chat bubble。

這篇文章是我們自家 stack 的誠實拆解，不是 demo、不是 marketing，是每天實際在跑的東西。如果你是 CTO、或正在考慮把內部流程 AI 化，這篇應該能省你幾個禮拜的摸索。

TL;DR

BotsUP 的 admin backend 掛著 4 個 MCP server（PM / Dev / CMS / Biz），總共約 120 個 tool。
MCP 走 OAuth 2.1，Claude.ai、Cursor、我們自研的 agent runner 都接得上。
主網站跑在 App Hosting（Next.js 15 App Router），MCP proxy + OAuth 拆到 Cloud Run，資料層是 Firestore + Firebase Auth。
每個 Agent（Morning briefing、Bookkeeping、PM、Dev）都只是 Claude + 特定幾個 MCP tool 的排列組合，沒有 LangChain、沒有 agent framework。
財務記帳、報價發票、每日 briefing、PR ship 流程，目前 80% 以上由 Claude 操刀，我只做 P0/P1 review 和 scope 決策。

先講結論：Stack at a glance

層級	選擇	為什麼
前端 + API	Next.js 15 App Router	SSR + API Routes 同 repo、RSC、部署彈性
資料庫	Firestore	multi-tenant scoped query 原生好用、跟 Firebase Auth 無縫
認證	Firebase Auth + 自建 role（admin / developer / editor / viewer）	成熟、free tier 夠、role 自己長
主站部署	Firebase App Hosting（`botsup.cc`）	和 Firebase stack 最順、build cache 穩定
MCP proxy	Cloud Run（`mcp.botsup.cc`）	pay-per-request、cold start 可接受、OAuth handler 獨立部署
MCP 協定	Model Context Protocol（Anthropic spec）	LLM 能 discover / choose / call tool，跨 agent 平台共用
Agent runner	Claude.ai（native MCP）、Cursor、Claude Code CLI	沒有自己寫 agent loop，把 orchestration 交給上游
觀測	Firestore `audit_logs` collection + Cloud Logging	每個 tool call 都留 trace

注意一個關鍵分工：MCP 工具本體跑在 App Hosting（src/app/api/mcp/*），Cloud Run 只是一層薄 proxy + OAuth handler。這讓我改 tool 邏輯只要 push GitHub，App Hosting 自動部署，不用動到 MCP deployment pipeline。

MCP Server #1：botsup-pm — PM Agent（約 60 tools）

職責：策略（Objective / OKR）→ Milestone → Epic → Backlog Item 的完整管理，加上每日 briefing、Kanban、feedback inbox、scope guard、weekly focus。

Architecture：

Objective (年 / 季 OKR)
  └── (optional) Milestone（成功標準 + due date）
                   └── Epic（有意義的功能模塊，PM 建）
                        └── Backlog Item（可執行 task，Dev Agent 拆）

Project.onePager → strategicLinks: Objective[]

Project 有一份 One-Pager，帶 vision / problem / strategicLinks / non-goals / success metrics。Agent 在做任何 scope 判斷前都會先讀這份，才不會亂答。

主要 tools（節錄）：

策略層：create_objective, update_key_result, list_bets, create_bet
執行層：create_milestone, create_epic, break_down_epic, claim_next_item, update_backlog_item
追蹤層：get_milestone_dashboard, get_weekly_focus, close_weekly_focus, log_scope_event
Inbox：ingest_feedback, triage_feedback, link_feedback_to_item

實際用法：

早上我打「今天 P0 能做什麼」→ Claude 連 get_milestone_dashboard 抓最緊急 milestone，再打 list_backlog 過濾 P0/P1，組一張清單給我，順便幫我 recommend 從哪一個開始。
客戶 email 進來 → 我把內容丟給 Claude → Claude 自動叫 ingest_feedback 寫進 inbox，tag 專案、猜 priority、建議是否要建 backlog item。
每週五晚上 → close_weekly_focus + get_strategy_dashboard 自動生 retro，我只要補一段文字脈絡。
Scope guard：GitHub push 如果 commit 沒有 [BU-xxx] 或 [EPIC-xxx]，webhook 會觸發 log_scope_event，focus score < 60% 我會收到通知。這是 advisory，不阻擋 push，因為有時候就是要打亂一下 scope。

MCP Server #2：botsup-dev — Dev Agent（約 20 tools）

職責：Epic 拆解、自動開發 loop（claim → develop → PR → ship）、GitHub webhook 整合。

Architecture：Dev Agent 跟 PM Agent 共用同一份 Firestore backlog collection，但 tool surface 更小、更動作導向。Agent 不該看到策略層，看到會分心。

主要 tools：

get_milestone_dashboard → list_epics({ milestoneId }) → 找未完成 epic
break_down_epic → 如果 epic 沒有 child → 拆成 3-8 個 backlog item
claim_next_item → 領一個 item，回傳完整 context（description / acceptance criteria / relatedFiles）
log_completed_work, ship_backlog_item, flag_for_review
get_kanban_board 給 dev standup 用

實際 loop（Cursor + Claude Code）：

我在 Cursor 打「claim 下一個 item」→ Cursor 透過 MCP 叫 claim_next_item
Claude 拿到完整 item spec，開始寫 code，一邊寫一邊更新 update_backlog_item
Push commit，訊息帶 [BU-{backlogItemId}] 或 [EPIC-{epicId}]（也支援 closes #{githubIssueNumber}）
GitHub webhook 打回 App Hosting /api/webhooks/github，解析 commit、更新 state、同步 PR 狀態
P0/P1 item：必須等我 review PR 才能 ship_backlog_item；P2/P3：CI 綠了自動 ship
Ship 時自動 close linked issue，並 recompute parent epic 的完成度和 milestone %

這套在 .github/workflows/botsup-sync.yml 是一個 reusable workflow，四個 repo（Agent2PDF / OnReel / BotsUP Website / 日本房產觀察室）通用。Dev Agent 跨 repo 拿 task 不用改 code。

MCP Server #3：botsup-cms — CMS Agent

職責：內容管理（article / channel / review queue）、招聘（job posting / application）、媒體資產。

主要 tools：create_article, update_article, submit_for_review, approve_content, publish_article, create_channel, create_job, list_applications, update_application_status。

實際用法：

AI 寫 research article：我給 brief（就像你現在讀的這篇），Claude 在背景叫 create_article 建 draft → submit_for_review → 我 review → approve_content → publish_article。整條 pipeline 不用登入 admin UI。
履歷處理：應徵者送表單 → list_applications → Claude 讀 resume + 職缺 JD → 給我一個 ranking 和 summary → 我按鈕 call update_application_status。
Content workflow 有 role gating：editor 只能建 draft、developer 以上才能 approve。Role check 在 MCP tool 層做，不是 UI 層，所以 agent 也擋得住。

CMS 的 tool 數量比 PM / Biz 少，因為內容模型本來就沒那麼複雜。不要為了看起來強就硬塞 tool，這是我自己繞過的坑。

MCP Server #4：botsup-biz — Biz Agent（40+ tools，財務最肥）

職責：報價、發票、合約、薪資、費用報銷、銀行對帳、401 營業稅、股東代墊款、journal entry、試算表、財報。

主要 tools：

銷售：create_quotation, create_contract, create_invoice, link_invoice_to_quotation
費用：create_expense_claim, approve_expense_claim, create_cost_record
薪資：calculate_payroll, revert_payroll_to_draft, execute_payroll_run
記帳：create_journal_entry, reconcile_bank_entry, get_trial_balance, get_financial_statement
稅務：query_tax_status, prepare_401_filing

TWD 整數元政策：所有 TWD journal line（debit / credit）必須為整數元。外幣換算（例如 USD → TWD）在 roundTWD() 做一次 Math.round() 寫進 cost_records.amountTWD；建 journal 前還會再 round 一次當防禦。小於 1 元的差額直接吸收進該科目，大於 100 元的差額記到 5502 雜項費用。這條規則是 agent 最容易犯錯的地方，寫在 tool docstring 裡，Claude 會自己守住。

實際用法：

Client 付款入帳 → 把銀行對帳單丟給 Claude → 自動 reconcile_bank_entry + create_journal_entry（借：銀行 / 貸：應收帳款）
月底薪資：calculate_payroll（draft）→ 我 review → 如果要改：revert_payroll_to_draft → 重算 → execute_payroll_run 寫進總帳
季報：get_trial_balance + get_financial_statement 直接產表，我不需要打開 admin UI
發票/報價單必須雙向連結（sourceQuotationId / invoiceId / contractId），tool 層強制，不允許孤兒發票

這是 4 個 MCP server 裡最重、最怕 agent 出錯的，但也是 ROI 最高的。過去每月對帳至少花我兩天，現在通常 2 小時內搞定。

AI Agent 使用模式

所有 Agent 都不是自研 loop，就是 Claude + 指定幾個 MCP tool 的 prompt template。

Morning briefing Agent（每日 08:00 自動跑）

讀 milestones / kanban / 未讀 feedback / 過去 24 小時 git activity / calendar / unread email。產出一份 Markdown briefing，pinned 到 Action! App 當天第一筆。我起床先看這個，決定今天工作順序。

Bookkeeping Agent（event-driven）

收到費用報銷表單、發票 OCR、銀行對帳 CSV → 自動叫 biz MCP 建 journal entry。月底跑一次 full reconciliation，有差異的項目 flag 給我。

PM Agent（daily + on-demand）

每日 standup（what's done / in flight / blocked）、scope guard（追 commit 有沒有對齊 milestone）、focus score。每週五自動寫 retro draft。

Dev Agent（Cursor 手動觸發）

Claim 下一個 backlog item → 在 .claude/worktrees/ 開獨立 worktree → 寫 code → PR → ship。Commit message 自動帶 [BU-xxx]。這是我個人生產力漲最多的環節，實際上 Claude 現在處理我 60%+ 的 routine 開發工作。

Stack decisions：為什麼選這些，不選那些

為什麼 Next.js 15 App Router，不用 Remix / SvelteKit：SSR + API Routes 同 repo 一次搞定、RSC 讓 admin page 直接從 Firestore 抓資料免多寫一層、部署到 Vercel / Cloud Run / App Hosting 都能直接跑。重點是 MCP 的 HTTP endpoint 也是 Next.js API route（src/app/api/mcp/pm/route.ts 等），一份 code 同 deploy。

為什麼 Firestore 不用 Postgres：BotsUP 是 multi-tenant，每個 workspace 有自己的 workspaceId，Firestore 的 scoped query（where('workspaceId', '==', ctx.workspaceId)）搭 security rules 做 row-level 隔離非常直覺。加上我自己在水滴發票時期就熟，zero learning curve。代價是 join 很醜、aggregate query 要自己 fan-out，但對 ops 系統來說可以接受。

為什麼 GCP 不用 AWS / Vercel-only：Firebase 全家桶、Cloud Run pay-per-request 符合我們流量型態、台灣 region（asia-east1）延遲低到可接受。Secret Manager 管 Firebase config 走 runtime 讀取，NEXT_PUBLIC_* 在 server side 一樣 runtime 拿得到，不會 hardcode 進 bundle。

為什麼 MCP 不是 REST API：REST 要在 prompt 裡寫 curl 指令、LLM 要自己組 headers、出錯 retry 是地獄。MCP 讓 LLM 能直接 discover tool schema、選工具、呼叫、拿到 typed response。我們 tool surface 120 個，用 REST 管理根本不可能，prompt context 會爆。更重要：standard spec 讓 Claude.ai、Cursor、自研 runner 共用同一份 tool，不用 per-agent rewrite。

Production 實務

Auth：MCP endpoint 吃 Bearer token（OAuth 2.1 flow by Claude.ai），內部 agent 吃 long-lived JWT。Token issuer 在 Cloud Run 的 mcp-proxy，key 存 Secret Manager。
Multi-tenant：每個 workspace 有 workspaceId，tool 層用 ctx.workspaceId 做 scoped query，security rule 再防禦一次。Agent 拿到的 token 已經綁定 workspace，跨 workspace 不可能。
Rate limiting：Cloud Run 自帶 concurrency limit，加上 custom middleware 對 expensive tag 的 tool（例如 get_financial_statement）做 per-minute cap，避免 LLM runaway call 把 Firestore 打爆。
Audit log：每個 tool call 寫 audit_logs collection，欄位：actorType（human / agent），actorId, toolName, args（redacted），result, ts。debug AI 行為這個 log 是命根子。

給其他團隊的建議

不要從 chat bubble 開始。那是 demo，不是系統。從一個具體、窄、深的流程（例如「每週報銷記帳」）開始，把它做到 agent 能完全接管。
第一個 MCP server 先做 read-only。讓 agent 幫你「查」東西，你驗幾週 tool surface 跟 auth 流程都穩了，再加 write。
Tool 設計 idempotent。LLM 會 retry，你要保證 create_invoice 同樣 input 呼叫兩次不會建兩張發票（做 idempotencyKey）。
每個 tool 都能 dry-run。尤其是會動錢的（journal entry、payroll），一定要有 dryRun: true 模式回 preview。
Docstring 就是 prompt。tool description 寫清楚 constraint（例如「TWD 金額必為整數元」），比你事後在 system prompt 亡羊補牢好十倍。
Scope guard 要 advisory，不 blocking。AI 做錯方向很常見，但硬擋會讓人類抓狂。log + notify 就好，決策權留給 human。

FAQ

Q1：開發這一套花了多久？ 核心 4 個 MCP server 從 scratch 到 production 約 10 個月，我一個人主寫（Claude 幫我寫大約 60%）。前 3 個月在 PM + Dev，第 4-7 個月加 Biz（財務最複雜），第 8-10 個月加 CMS + 調 production hardening。

Q2：我公司很小（3-5 人），也適合做 MCP 架構嗎？ 適合，而且越小越適合，因為你沒有 legacy system 要遷移。但不要一次做 4 個 server，先選一個最痛的流程（通常是記帳或 PM），做一個 MCP server、5-10 個 tool，跑 1-2 個月驗模式。

Q3：會不會太 vendor lock-in Claude？ MCP 是 open spec，Anthropic 主導但 OpenAI / local LLM 都有在 follow。我們 tool layer 跟 Claude 無關，換成 GPT-5 只要換 agent runner 那一層。真正的 lock-in 是 Firebase，不是 Claude。

Q4：成本多少（LLM API + GCP）？ 目前 monthly：Claude API 約 USD 400-600（重度使用），GCP（App Hosting + Cloud Run + Firestore）約 USD 150-250。以取代掉的人力（我自己省 15-20 小時/週）來算，payback < 1 個月。

Q5：可以用開源的 MCP framework 嗎？ 可以，Anthropic 有 TypeScript / Python SDK（modelcontextprotocol.io）。我一開始用 TS SDK，後來為了跟 Next.js API route 整合順一點，把 transport layer 換成自己寫的 HTTP handler。如果你是獨立 server（不嵌 Next.js），直接用 SDK 就好，不用重造輪子。

參考資料

Model Context Protocol 官方規範 — https://modelcontextprotocol.io/
Anthropic：Claude.ai native MCP support 公告
Google Cloud Run 官方文件 — https://cloud.google.com/run/docs
Next.js 15 App Router 文件 — https://nextjs.org/docs/app

BotsUP 自己的 admin 就是最強 demo：4 個 MCP server、AI Agent 從 day 1 是第一公民。我們現在用同一套方法幫客戶把他們的內部 ops 也 AI 化。30 分鐘需求診斷，看怎麼在你公司做一套。