身為一個科技業工程師,我的各種群組最近突然很不尋常。
你知道的,就是那種平常只會出現「prod 又炸了 🔥」「誰又把 API key 推上去了」「有人要訂雞排嗎」的群組。
突然間,大家都在問:「欸欸欸,Clawdbot 你有看嗎?」
我第一個反應是:又一個 AI 工具對吧,名字取得跟海鮮一樣。
第二個反應是:等等,為什麼大家這麼興奮?
後來才發現,這玩意兒其實是在講一個很「工程師」的東西:
把聊天軟體當控制台(ChatOps 2.0),用 gateway 把訊息導給 agent,agent 再去呼叫工具把事情做完——而且是真的做完,不是只會嘴砲。
(你可能也會看到它被叫 Moltbot。名字梗就是龍蝦會脫殼 molt;總之就是同一掛東西在社群上的不同叫法,就像有人叫它「小龍蝦助手」一樣。)
當 產品 炸掉時,至少還有龍蝦陪你
先用一個例子講:從「一句廢話」到「一個完整的 md 檔」
我用一個工程師真的會遇到的任務當例子:把冗長無聊的會議逐字稿整理成 markdown,順便把 action items 拉出來。
你在群組隨手丟一句:
你:「幫我把
meeting-2026-01-28.txt整理成 md,分成『重點』『決議』『待辦』,待辦要有負責人跟 deadline。」
如果是比較聰明的 agent,它通常會先反問你缺的參數(這點反而很工程):
Agent:「deadline 沒講的我要怎麼處理?要不要統一標『TBD』?另外負責人要用人名還是 @帳號?」
你回:
你:「deadline 沒寫就 TBD;負責人用 @帳號。」
接著它就會去真的做事(重點在這裡),最後回你兩種東西:
- 一段摘要(讓你快速確認沒寫歪)
- 一個產物(例如
meeting-2026-01-28.md)
產物長得大概像這樣(示意):
# 2026-01-28 會議整理
## 重點
- API gateway 的 rate limit 要調整
- 下週要 demo 新功能
## 決議
- 先用 hardcode 方式處理 demo
- tool allowlist 要補文件
## 待辦
- [ ] @alice:把 gateway 的 rate limit 改成每分鐘 60(TBD)
- [ ] @bob:補上 tool allowlist 文件(2026-02-02)
如果你想像它在背後到底做了哪些動作,大概會長這樣(示意 log):
1) tools.read_file(path="meeting-2026-01-28.txt")
2) tools.extract_sections(schema=["重點","決議","待辦"], assignee_format="@handle")
3) tools.normalize_deadlines(missing="TBD")
4) tools.write_file(path="out/meeting-2026-01-28.md", content=...)
5) gateway.send_attachment(chat="#team", file="out/meeting-2026-01-28.md")
你看起來像是在「聊天」,但它其實是在跑一個小工作流。
這一段如果你只看文字會覺得「嗯不就摘要」,但工程上真正的差別是:
- 它不是只會回你一段話
- 它能用工具把檔案真的產出來、放到指定位置、或丟回群組
所以我常用一句很俗但很準的話:差別不在它會不會回,而在它會不會真的動手。
「deploy」「read file」「write report」——龍蝦比你還會用工具
背後其實就四塊:聊天窗 → gateway → agent → tools
把名詞拆開就不神秘了(而且你會發現它其實很像你以前做過的 ChatOps,只是多了個會「規劃」的腦):
- 聊天平台:你每天滑的那個 App(當 UI 就好,別加戲)
- Gateway:接線生(收訊息、認人、處理群組/附件、把格式統一)
- Agent Runtime:腦(LLM + 規劃 + 狀態 + 工具選擇)
- Tools:手(讀寫檔、跑腳本、打 API、查資料、產檔…)
我覺得下面這張圖比任何介紹文都誠實:
gateway 當接線生,agent 負責決策,tools 負責動手。
進化!從 ChatOps 脫殼變成 AI Agent 了!
為什麼工程師會覺得它「香」?(不是因為它會講笑話)
我覺得它紅的地方,通常不是「模型多聰明」,而是它讓一些很瑣碎、很日常的自動化突然變得容易交付:
1. 你不用再做醜後台了 🎉
以前:「欸我寫了個腳本可以整理會議記錄,但你要先登入這個醜後台,然後點這裡、貼那裡、選格式、按送出…」
現在:「你在群組丟一句話就好。」
2. 參數不齊?Agent 會反問你
很多流程本來就卡在「參數沒給齊」:
- 要 markdown 還是 doc?
- 檔名規則是什麼?
- 輸出路徑放哪?
Agent 可以在對話裡把參數補齊,而不是讓你對著一個表單發呆。
3. 內部小工具變得比較像產品
大家用訊息就能觸發,不用:
- 裝一堆東西
- 記一堆指令
- 開 VPN
- 找到那個「不知道放在哪」的內部網站
如果要更具體一點,工程師最愛拿它做的,通常都是這種:
- 「把會議逐字稿整理成 md」
- 「把群組裡的一串需求整理成 ticket 草稿」
- 「把昨晚錯誤摘要整理後丟回群組」
- 「幫我把這段 code review 意見整理成 TODO list」
講白一點:都是那種你本來就會寫腳本做,但你懶得做 UI 的事。
真實案例:把亂七八糟的對話變工單
我自己最常腦補的第二個例子是「把一串很亂的對話變工單」:
PM:「這功能下週要 demo,能不能先 hardcode?」
你:「你先別急…(然後丟了一串需求跟限制)」
你:「@agent 幫我把上面這段整理成 ticket,欄位要有 scope / out-of-scope / acceptance criteria / risks。」
它如果回得像樣,你就知道它不是在陪聊,它是在幫你把雜訊變成可交付的格式。
但也最容易翻車的地方:權限與爆炸半徑 💥
給龍蝦工具之前,請三思
你一旦讓 agent 真的能「做事」,它一定會碰到權限問題。
常見的爆炸場景:
- Tools 能讀檔? → 那它能不能讀到不該讀的?(例如
.env或客戶資料) - Tools 能寫檔? → 那它能不能覆蓋/污染資料?(例如不小心
rm -rf /) - Tools 能執行指令? → 那它其實就有能力把機器搞爛
- Tools 能連外? → 那就要開始擔心資料外流跟成本(想像它不小心呼叫了 10000 次 API)
如果我要在公司「真的用」,我會先做這些很無聊但很保命的限制:
1. Tools 全部 allowlist
先別想著「它什麼都能做」,先想「它只能做哪幾件事」。
# 允許的工具清單
allowed_tools:
- read_file # 但只能讀特定資料夾
- write_file # 但只能寫到 out/
- summarize_text
- create_ticket
# 禁止的工具
forbidden_tools:
- execute_shell # 絕對不行
- delete_file # 除非有 human-in-the-loop
- send_email # 要先確認
2. 權限分層(讀 / 寫 / 外連 分開管)
- 讀檔只給白名單資料夾
- 寫檔只准輸出到
out/之類的路徑 - 連外要控網域/控速率/控金額
3. 高風險動作 human-in-the-loop
刪檔、改設定、deploy、寄信…這種先問你一句再做。
Agent: 我準備要執行以下指令:
rm -rf /tmp/old-logs/*
確認要執行嗎? [Y/n]
4. 可追溯
至少留得下:
- 誰下指令
- 它叫了哪些工具
- 工具輸入輸出是什麼(敏感內容要遮罩)
{
"timestamp": "2026-01-28T03:02:15Z",
"user": "@alice",
"command": "整理會議記錄",
"tools_called": [
{ "tool": "read_file", "args": { "path": "meeting.txt" } },
{ "tool": "write_file", "args": { "path": "out/meeting.md" } }
],
"status": "success"
}
很多人聽到這裡會覺得:哇好麻煩。
但我的經驗是:你只要把它當成「一個很會動手的自動化」,你就會突然覺得這些規矩一點都不多。
畢竟,你不會讓一個實習生有 sudo 權限,對吧?
結論:龍蝦很香,但別被夾到
Clawdbot / Moltbot 這波紅,我覺得合理:它把 agent 這件事做得很「日常」——用聊天訊息當入口,背後串 gateway/agent/tools,最後交付產物。
但也因為它真的能動手,所以最重要的不是「prompt 漂不漂亮」,而是:
- 權限怎麼切
- 爆炸半徑多大
- 出了事能不能追
不然你某天凌晨會被叫醒,而且還不是被 pager 叫醒。
是被自己養的龍蝦叫醒。 🦞
延伸思考:你可以拿它做什麼?
如果你也想試試看,這裡有一些「低風險、高價值」的起手式:
適合新手的安全場景:
- 會議記錄整理 → 只讀不寫,風險低
- 文件摘要生成 → 輸入輸出都可控
- Ticket 草稿生成 → 只是草稿,人工再確認
- 錯誤 log 分析 → 讀 log 檔,產出摘要
進階一點的場景:
- 自動化 code review 意見整理
- 把 Slack 討論串轉成 RFC 草稿
- 定期產生團隊週報
- 監控告警自動分類 + 建議處理步驟
高風險場景(請三思):
- ❌ 自動 deploy
- ❌ 自動刪除資料
- ❌ 自動發送對外郵件
- ❌ 自動修改 production config
記住:先從「只讀」開始,再慢慢加「寫」的權限。
P.S. 如果你看完這篇還是不確定要不要用,我的建議是:先從「幫你整理會議記錄」開始試試看。如果它連這個都做不好,那就別給它更大的權限了。如果它做得不錯,那恭喜你,你多了一個不會抱怨加班的同事。🦞
