Registration 都應該配合 agentic flow
上一篇講到我哋點睇 AI Manager CRM backend：
前台可以繼續 vibe code，保持快、custom、貼近產品感覺。但 user、database、CRM records、booking、billing、message、reporting、permissions 呢啲核心後台能力，最好唔好靠 AI agent 即興由零亂砌。
比較穩陣嘅分工係：
- app 負責 interface 同 product experience
- backend 負責 data、policy、workflow 同 trust
- agent 負責 call 有 schema、有規則、有安全邊界嘅 tools
今次由一個好細，但其實好關鍵嘅位開始：registration。
如果一個 backend 本身係設計俾 AI agent 操作，第一步 setup 都應該可以由 agent 幫手完成。
傳統 API signup 點解有啲卡
好多 developer quickstart 都係同一個流程：
- 開 signup page
- 建 account
- 入 dashboard 搵 API key
- copy API key
- paste 入 agent 或 CLI
- 終於開始第一個 call
呢個流程對 dashboard-first SaaS 係合理嘅。
但對 agentic backend，就有少少斷開。
如果個 backend 本身係俾 AI agent 操作，user 應該可以直接講：
幫我開一個 FavCRM workspace，業務係香港一間 yoga studio，叫 Stretch + Breathe。
然後 agent request signup code，等 user 貼返 email code，verify code，再收到 API key。
人負責證明 email ownership。Agent 負責完成 workflow。
呢個 flow 會建立啲咩
完成 registration 之後，你會有：
- 一個 FavCRM workspace
- 已驗證嘅 owner email
- 一條
fav_mcp_*API key - 已設定嘅 CLI 或 MCP client
- 第一次 MCP endpoint diagnostic check
同一個 flow，可以喺 MCP client 入面跑，亦可以用 favcrm CLI 跑。
Path A：喺 MCP client 註冊
喺 MCP-compatible client 入面，agent 會用兩個 no-auth tools：
register_organisation_requestregister_organisation_verify
第一步會寄出一個短期有效嘅 email code。
{
"name": "register_organisation_request",
"arguments": {
"email": "[email protected]",
"organisationName": "Stretch + Breathe",
"industry": "fitness",
"country": "HK",
"timezone": "Asia/Hong_Kong"
}
}
回應會包括 request ID、masked email 同 expiry time。
{
"requestId": "signup_req_...",
"maskedEmail": "yo*@example.com",
"expiresAt": "2026-05-11T12:00:00.000Z",
"instructions": "Tell the user to check yo*@example.com for a 6-digit code..."
}
User 收到 email，再將 6 位數 code 貼返俾 agent，agent 就可以 verify：
{
"name": "register_organisation_verify",
"arguments": {
"requestId": "signup_req_...",
"code": "123456"
}
}
Verify 成功後，系統會建立 workspace，並且只回傳一次 API key。
{
"organisationId": "org_...",
"companyId": "co_...",
"userId": "usr_...",
"apiKey": "fav_mcp_...",
"loginUrl": "https://app.favcrm.io",
"nextSteps": "Set Authorization: Bearer <apiKey> on subsequent MCP calls..."
}
呢條 key 唔應該貼入 source code。比較好嘅做法係放入 MCP client config、local environment variable，或者 secret manager。
Path B：用 CLI 註冊
如果你喺 terminal 做 setup，CLI 會包住同一個 flow。
先由 source 安裝：
git clone https://github.com/favcrm/cli ~/Project/favcrm/cli
cd ~/Project/favcrm/cli
cargo install --path .
Request email code：
favcrm signup request \
--email [email protected] \
--organisation-name "Stretch + Breathe" \
--industry fitness \
--country HK \
--timezone Asia/Hong_Kong
再 verify：
favcrm signup verify \
--request-id <request-id> \
--code <six-digit-code>
Default 情況下，signup verify 會將 API key 儲存到 CLI config。Human output 會 mask key，除非你特別用 --show-key。
呢個 default 好重要。Agentic system 應該避免 API key 出現在 logs、chat transcript、screenshots 或 repo files 入面。
做第一次 diagnostic
Verify 完之後，可以跑：
favcrm doctor
Doctor command 會檢查：
- MCP endpoint URL
- auth 有冇設定好
- reachable tool count
- current organisation context
- plan status
- 如果有 WhatsApp connection，都會一併檢查
如果想要 machine-readable output：
favcrm --json doctor
Fresh workspace 回傳 empty services list 係正常。呢個唔代表壞咗，反而代表 auth 已經通，backend 已經 ready，可以開始 setup。
Agent 要識處理嘅幾個情況
Registration flow 本身好細，但 agent 仍然要識處理 edge cases。
Code 過期。 再 call register_organisation_request 拎新 code。
Code 錯。 用更正後嘅 6 位數 code retry verification。
Account 已存在。 請 user 入 portal login，再由 Settings 建 MCP key，或者繼續現有 merchant flow。
收唔到 email。 先檢查 masked email，等一分鐘，再視乎情況 request 多次。
Token 洩漏。 入 portal revoke 舊 key，再 issue 新 key。
點解呢件事重要
Agentic registration 唔只係慳幾個 click。
重點係由第一步開始，backend 已經係為 agent operation 而設計。Agent 可以 discover signup tools、request email ownership proof、完成 verification，然後直接進入真正有用嘅工作。
User 唔需要一開始就理解 API-key screen，先至感受到價值。
之後 agent 可以 list tools、inspect schemas、call CRM operations：
favcrm tool list
favcrm tool describe list_services
favcrm tool call list_services '{}'
想睇 agent 註冊之後可以 call 嘅全部 194 個 typed tools 同 playbooks，可以去 FavCRM 嘅 MCP catalog。
真正重要嘅原則唔係「叫 AI 做晒所有嘢」。
而係：俾 agent 一個有規則、有權限、有 typed tools、有安全邊界嘅 backend，然後俾佢喺呢個邊界入面操作。
啱啱接觸呢個類別？由 咩係 agentic CRM 開始。
