1. 前言：助理只活在我的終端機裡

Day 21 教會助理查資料，Day 22 讓它記得前面聊過什麼，Day 23 替它加上護欄，Day 24 拿標準答案考過它，可是到昨天為止這個助理只有我用得到，因為它是一支在我的 Cloud Shell 裡執行的 Python 程式，同事想問一句上週哪支廣告花最多錢，得先有我的專案權限、裝好套件、再學會下指令。

要讓同事用最直接的做法是把它變成一個網址，但網址一旦誰都連得上，就多了三個原本不存在的問題，任何知道網址的人都能花我的 Token，助理查得到顧客名單所以連得上的人也問得到，而且呼叫模型的人變多之後，一個晚上能花掉多少錢不再是我自己控制得住的。

所以今天的重點不在部署本身，部署只要一個指令，重點是部署之前先回答三個問題，誰能連、連進來的服務能碰什麼、最多能花多少，另外還有一個要誠實面對的落差，篇名寫的是全團隊都能直接用，今天做完之後離這句話還差一步，文章後面會交代差在哪裡。

今日核心目標：

1. 把 Day 22 的多輪對話和 Day 23 的護欄合成一個服務，部署到 Cloud Run，只開給指定的 Google 帳號
2. 服務用專屬的服務帳號查資料與呼叫 Gemini，映像檔和環境變數裡不放任何金鑰
3. 替服務加上自己的每日花費上限，並且讓每一次呼叫都出現在昨天的儀表板上

2. 系統架構全景與設計理念

三個問題各由不同的一層回答，而且每一層都不靠助理自己的判斷。

這個設計有三個刻意的安排。

第一，身分驗證交給平台，程式裡沒有任何登入的邏輯，Cloud Run 的服務可以設定成不允許未驗證的請求，這時候每一個請求都要帶 Google 簽發的身分權杖，而且那個身分要有這個服務的 roles/run.invoker，我實測沒帶權杖是 HTTP 403、權杖過期是 HTTP 401，兩種都在進到程式之前就被擋掉，官方定價頁也寫明被 IAM 擋下的請求不計費，所以陌生人就算拿到網址一直敲，也花不到我的錢。

第二，服務上沒有金鑰，助理要查 BigQuery、要呼叫 Gemini，在很多教學裡這兩件事各需要一把金鑰，放在環境變數或設定檔裡，這裡的做法是部署時指定服務帳號，Cloud Run 會在執行時把這個身分交給程式，Google 的用戶端程式庫會自己取得短期的憑證，整個映像檔裡找不到任何一把可以被偷走的鑰匙，手冊原本替今天排的主題是用 Secret Manager 管理金鑰，實際做下來這個服務沒有金鑰可以管，Secret Manager 真正派上用場是 Day 28 的 Slack 網址，3.3 會說明有密鑰的時候該怎麼接。

第三，花費的上限放在服務自己身上，昨天的預算警報只會寄信，而且可能晚幾個小時，擋不住一個晚上燒完預算的意外，所以服務在每次呼叫模型之前自己先算，今天已經花了多少、這一次最貴會花多少，加起來會超過上限就不呼叫，直接回答今天的額度用完了。

3. 核心技術深度拆解

3.1 從終端機程式到服務：兩支程式合成一支

盤點現有的程式時發現一件事，Day 22 的多輪對話 chat.py 沒有護欄，Day 23 的護欄只接在一題一問的測試程式上，多輪對話和護欄從來沒有同時存在過，今天主要的程式工作就是把兩者合成 agent/serve.py，用 Flask 包成三個端點，另外加上對話頁用到的兩個靜態檔。

合在一起之後，有四個地方的做法和終端機版本不一樣。

對話紀錄不能只放在記憶體裡，終端機版本的對話紀錄是一個變數，程式結束就沒了，服務版本要同時記住好幾場對話，我一開始的做法是放在記憶體裡的一張對照表，用隨機產生的編號當鑰匙，30 分鐘沒動就丟掉，並且把執行個體上限設成 1，免得同一場對話的下一句被送到另一個執行個體，結果在瀏覽器裡實測就出事了，第一句答完之後我隔了不到半分鐘才問第二句，助理已經不記得前一句，查服務的紀錄才發現 Cloud Run 在第一句答完 4 秒後就把閒置的執行個體收掉，第二句是新的執行個體接的，所以現在的做法是把記憶體當成暫存，找不到這場對話的時候，從問答紀錄表把它接回來，接回來的有通過檢查的那幾輪問了什麼、答了什麼，整場成功執行過哪些工具，以及已經問了幾輪，當時的工具結果不在紀錄表裡，模型需要的話會重查，紀錄表裡找不到、查詢失敗、接回來的內容通不過檢查、超過 30 分鐘沒動或不是同一個帳號，就當成一場新的對話。

顧客資料獨佔的範圍從一題變成一整場，Day 23 有一條寫在程式裡的保證，同一題只要用過其他工具就不再提供顧客資料，反過來也一樣，目的是不讓外人寫得進去的內容和顧客個資出現在同一次問答裡，接到多輪對話之後，上一輪讀到的內容還留在紀錄裡，所以範圍要跟著擴大成一整場對話，查過廣告花費的那一場就問不到顧客資料，要另外開一場新的對話單獨問。

沒有完整通過的那一輪不留在紀錄裡，回答被輸出檢查擋下、被安全設定擋下、寫到上限沒寫完，這幾種情況使用者拿到的是一句固定的說明，那一輪的問題、工具結果和模型原本的回答全部從記憶體裡的對話紀錄拿掉，下一輪不會再看到，但那一輪仍然算一輪，查過的工具也仍然算數，另外輸出檢查也比 Day 23 嚴，回答裡只要出現長得像完整 email 或手機號碼的字串就整段不送，Day 23 的做法是遮蔽之後放行。

出狀況時往不花錢的方向倒，第一句發問進來時服務才去查單價、宣稱用語和今天已經花多少，查不到就不提供對話，過 30 秒才會再試，用量或問答紀錄寫不進資料表，之後就不再呼叫模型，呼叫模型失敗而不確定有沒有被收費的那一次，當成最貴的情況記帳，這幾條沒有一條會讓使用者比較方便，但每一條都確保出狀況的時候錢不會默默流出去。

完整的程式與 97 項不花錢的自我檢查在 agent/serve.py 與 agent/serve_selftest.py，其他細節寫在 agent/README.md。

3.2 誰能連：不允許未驗證，再一個一個加人

部署指令裡和誰能連有關的只有一個旗標 --no-allow-unauthenticated，服務建好之後，再替每一個要用的帳號加上 roles/run.invoker。

gcloud run services add-iam-policy-binding martech-assistant \
  --region us-central1 \
  --member="user:同事的帳號" \
  --role="roles/run.invoker"

這裡的權限是綁在這一個服務上的，同事不會因此看得到專案裡的其他東西，他也不需要 BigQuery 的權限，因為查資料的是服務帳號不是他。

要留意 roles/run.invoker 只有呼叫這一項權限，3.6 會用到的 gcloud run services proxy 啟動時要先讀服務的設定才知道網址，那需要另一項權限，所以要讓同事用這個指令，得再綁一個同樣只到這個服務的 roles/run.viewer，做法是把上面那一行的角色換掉再執行一次，部署腳本會替名單上的帳號把兩個角色一起綁好。

部署完之後我做了五項不花錢的檢查，結果如下。

第四項值得多說一句，同事在瀏覽器裡使用的時候，是透過自己電腦上的一個代理程式連到服務的，這個代理會替每一個請求補上他的身分，如果服務對請求的來源完全不設防，他同時開著的任何一個惡意網頁都可以叫瀏覽器對這個代理送出發問，等於借他的身分問問題、花他的額度，所以 /chat 只收帶著對話頁專用標頭的請求，並且檢查瀏覽器送來的來源網址在不在名單上，這一項是部署前請沒有參與撰寫的另一方來找問題時被找到的，我自己寫的時候沒有想到。

3.3 連進來的服務能碰什麼：專屬的服務帳號，沒有金鑰

服務帳號 martech-assistant 是昨天 Terraform 先建好的，它的權限只有三項。

這裡有一個要講清楚的取捨，dataEditor 代表服務帳號改得動資料集裡的每一張表，不只是它需要寫入的那兩張，我接受這個範圍的理由是助理的六個工具都是寫死的 SELECT，模型只能填參數不能自己寫 SQL，但正式環境比較好的做法是資料集只給讀取權限，只對紀錄用的那幾張表另外給寫入權限。

至於密鑰，這個服務剛好一把都沒有，但 Day 28 要讓流程把警報送到 Slack，Slack 的 Webhook 網址就是一把密鑰，拿到的人可以冒充機器人發訊息，那種情況的接法是把值放進 Secret Manager，部署時用 --update-secrets 掛進服務，再給服務帳號 roles/secretmanager.secretAccessor。

gcloud run services update 服務名稱 --region us-central1 \
  --update-secrets=SLACK_WEBHOOK_URL=slack-webhook-url:1

冒號後面的 1 是密鑰的版本，官方文件建議掛成環境變數時把版本釘住不要寫 latest，因為環境變數是執行個體啟動的時候解析的，釘住版本才知道每一個執行個體用的是哪一個值，今天的服務用不到這一段，先放在這裡，Day 28 會用到同一把密鑰。

3.4 最多花多少：先保留再呼叫

每日上限的做法是先保留再呼叫，每次呼叫模型之前，先假設這一次會用到輸入上限 6,000 與輸出上限 1,024 個 Token，照單價表算出最貴的金額大約是新台幣 0.27 元，今天已經花的加上這筆保留的金額會超過上限就不呼叫，呼叫完再把保留的金額換成實際的金額。

def reserve(self):
    with self._lock:
        self._roll()   # 換日（台北時間）就從 0 開始
        if self.spent + self.reserved + self.worst > self.cap + 1e-9:
            return False
        self.reserved += self.worst
        return True

先保留的原因是服務會同時處理好幾個請求，如果每個請求都是先看一眼還有額度就去呼叫，四個請求同時看到還有額度、同時呼叫，就一起衝過上限了，單價不寫在程式裡，從昨天的單價表 ref_llm_price 讀，表裡已經有 2027 年調價後的那一列，執行個體重新啟動之後就會用新的單價。

這個上限保證到哪裡要講清楚，它是照單價表估的不是帳單，額度記在執行個體的記憶體裡，一開始從用量表讀回今天已經花的，之後有人發問時，距離上次對帳超過一分鐘就再和用量表對一次，取比較大的數字，另外執行個體上限設成 1 並不是絕對的保證，官方文件寫明流量突然變大這類情況下，執行個體數量可能短暫超過上限，重新部署換版時新舊版本短暫並存則是我的推論、沒有實測，那段時間兩個執行個體要靠用量表對帳，而用量是一輪問完才寫進表裡，所以最壞的情況是兩邊各花掉一份額度，以預設的 3 元來說就是 6 元，真正帳單層級的保證只有預算，而預算只會寄信，這三層各有各擋得住與擋不住的範圍，沒有哪一層可以單獨依靠。

3.5 實際問七句話

我用三場對話、七句話測了部署好的服務，第一場是一般的連續提問，最後一句故意要顧客資料，第二場先問顧客資料再要別的，第三場要求寫不能寫的宣稱。

七句話共呼叫模型 11 次，輸入 30,589 個 Token、輸出 3,002 個，合計新台幣 1.09 元，表裡各列四捨五入後相加會是 1.10，上線後的 16 項檢查全部通過，包括使用者看到的回答裡沒有任何完整的 email 或手機、沒有一場對話同時拿到顧客資料和其他工具的結果、每一次呼叫都對得到單價。

10/9 我改用瀏覽器、照人打字的速度再問一次，3.1 提到助理不記得前一句就是這時候發現的，把對話紀錄改成可以從問答紀錄表接回來、重新部署之後，我又開了一場對話，前三句是上表第一場的第一、二、四句，兩分鐘內問完，都由同一個執行個體處理，接著放著不動，服務的紀錄顯示執行個體在第三句答完的 15 分鐘後被收掉，再過 4 分鐘我回到同一個頁面問第四句，請它把剛剛聊到的整理成兩點，頁面先出現一行說明，寫著服務剛換了一台、這場對話是從紀錄接回來的，接著的回答裡花費、曝光、點擊和幾支素材的點擊率都和前面一致，圖二就是這一場，這一句只呼叫模型 1 次，輸入 1,886 個 Token，10/8 同樣問法的那一句是 3,932 個，原因是接回來的只有問答的文字、不含當時的工具結果，瀏覽器裡這七句共呼叫模型 12 次，合計新台幣 1.03 元。

有一個數字值得注意，上表第一場的第四句輸入了 9,003 個 Token，兩次呼叫平均各 4,500，是每次 6,000 上限的四分之三，原因是對話紀錄每一輪都整份再送一次，前面三輪的問題、工具結果和回答都算在裡面，所以雖然設定是一場最多 8 輪，照這個速度推估，查過兩三次資料的對話大概五六輪就會碰到輸入上限，被要求開新對話，今天最長的對話只有四輪，沒有實際測到這個情況，這是刻意留下的限制，對話越長每一句越貴，上限就是用來擋這件事的。

兩天共 23 次呼叫都已經出現在昨天的儀表板資料來源裡，不用改任何設定，表裡的日期是我實際測試的那兩天。

3.6 離「全團隊都能直接用」還差一步

回到篇名，今天做完之後，被加進名單的同事要怎麼用，有兩條路。

第一條是 gcloud run services proxy，它會在自己的電腦上開一個代理，把瀏覽器的請求補上身分再轉給服務，接著打開 http://localhost:8080 就是對話頁，官方文件說這是在瀏覽器裡測試私有服務的建議做法，沒有裝 gcloud 的人可以開 Cloud Shell 執行同一行指令，再用右上角的網頁預覽打開，我用自己的帳號在 Cloud Shell 實測過這條路是通的，我的帳號是專案擁有者，只有 run.invoker 加 run.viewer 的同事帳號我沒有第二個帳號可以實測。

第二條是自己拿身分權杖用 curl 呼叫，這條路適合程式，不適合人。

兩條路都要求同事會下指令，而且有一件事和直覺相反，同事就算已經在瀏覽器登入了那個有權限的 Google 帳號，直接把服務的網址貼到網址列，看到的還是這一頁。

Error: Forbidden
Your client does not have permission to get URL / from this server.

原因是瀏覽器登入 Google 這件事，並不會讓它對別的網址自動帶上身分權杖，所以對會下指令的同事來說今天已經可以用，對行銷企劃同事來說還差一層登入頁，按一下用 Google 帳號登入就能進去的那一種。

補上這一層的現成做法是 Identity-Aware Proxy，它現在可以直接掛在 Cloud Run 服務上，不需要另外架負載平衡器，官方定價頁把保護 Google Cloud 上的應用程式這項功能列為不收費，同事打開網址會被帶去 Google 登入，登入的帳號在名單上才進得來，我沒有把它放進今天的主線，原因有兩個，官方文件寫到組織以外的使用者要先做一次性的設定、把 OAuth 同意畫面的對象設成 External，沒有組織的專案可能要先在 Console 做第一次設定，這一段沒辦法做成一行指令，另外文件沒有點名個人 Gmail 帳號，也沒有寫同意畫面需不需要送審，我也沒有實測，照寫可能會讓照做的人卡在半路，所以今天只把這條路指出來，公司有 Google Workspace 的團隊可以往這個方向接。

4. FinOps 成本防護實踐：三道防線體系

1. 第一道防線：善用 Google Cloud 每月免費額度：Cloud Run 依請求計費的免費額度是每月 18 萬 vCPU 秒、36 萬 GiB 秒與 200 萬次請求，以帳單帳戶合計，建置映像檔用的 Cloud Build 每月有 2,500 分鐘，一次建置加部署大約 3 到 4 分鐘，映像檔 68 MB，加上 Day 04 那個服務的合計約 119 MB，在 Artifact Registry 每月 0.5 GB 的免費額度內
2. 第二道防線：架構層被動成本防護：最少 0 個執行個體所以沒人用就不計費，最多 1 個，每輪最多呼叫模型 4 次、每場最多 8 輪、輸入上限 6,000、輸出上限 1,024，服務照單價表估算一天花到新台幣 3 元就不再呼叫模型（邊界見 3.4），被 IAM 擋下的請求不計費，命中輸入檢查那幾種說法的問題不會呼叫模型
3. 第三道防線：Cloud Billing 預算警報：沿用 Day 03 的預算警報與昨天加的通知信箱，昨天的儀表板可以看到這個服務每一天花了多少

5. Cloud Shell 實戰演練：把助理部署成私有服務

5.1 事前準備

• 先在 ~/ai-driven-martech-pipeline 執行 git pull，取得 Day 26 新增的 agent/serve.py、agent/static/ 與 scripts/deploy_assistant.sh
• Day 25 的 Terraform 要已經套用，映像檔存放區 martech 與服務帳號 martech-assistant 是那一次建的
• 前面幾天的程式要跑過，助理查的表、宣稱用語表與單價表才存在，缺哪一張部署腳本會直接告訴你是哪一天的
• 準備好要開放的同事帳號，沒有的話先只開給自己

5.2 路線 A｜一行指令

cd ~/ai-driven-martech-pipeline
bash scripts/deploy_assistant.sh

這個指令會先跑不花錢的自我檢查、建立問答紀錄表，接著建置映像檔並部署，把你自己的帳號加進名單，最後自己驗一次，確認服務沒有被開放給所有人、不帶身分的請求真的是 403，全程不呼叫模型，要一起開給同事的話在前面加上 INVOKERS=同事甲的帳號,同事乙的帳號，另外腳本會替 Day 27 排程用的服務帳號 martech-pipeline-runner 先綁好 roles/run.invoker，沒做過 Day 04 的人還會替建置用的預設服務帳號補上 roles/run.builder，結尾會印出目前可以連的所有身分。

5.3 路線 B｜一步一步看

步驟 1：不花錢的自我檢查，建立問答紀錄表

cd ~/ai-driven-martech-pipeline
pip install --user flask google-genai google-cloud-bigquery
python3 agent/guard.py
python3 agent/serve_selftest.py
bq query --nouse_legacy_sql < agent/serve_setup.sql

serve_selftest.py 把模型和 BigQuery 都換成假的，檢查的是服務自己的邏輯，哪些請求會被收下、護欄在多輪對話裡有沒有接對、上限到了會不會停、出狀況時是不是往不花錢的方向倒，最後一行建立問答紀錄表 serve_turns，服務只寫入不建表，少了這張表它會因為紀錄寫不進去而停止呼叫模型。

步驟 2：建置並部署

沒做過 Day 04 的人，要先照 Day 04 的做法替 Compute Engine 預設服務帳號加上 roles/run.builder，等一兩分鐘再部署，建置是用這個帳號進行的。

PROJECT_ID=$(gcloud config get-value project)
gcloud run deploy martech-assistant \
  --source agent \
  --image us-central1-docker.pkg.dev/${PROJECT_ID}/martech/martech-assistant \
  --region us-central1 \
  --no-allow-unauthenticated \
  --service-account martech-assistant@${PROJECT_ID}.iam.gserviceaccount.com \
  --min-instances 0 --max 1 --max-instances 1 \
  --concurrency 4 --cpu 1 --memory 512Mi --timeout 300 \
  --set-env-vars GOOGLE_CLOUD_PROJECT=${PROJECT_ID},DATASET=martech_dw,DAILY_CAP_TWD=3

幾個旗標的用意：

• --image 明確指到 Terraform 建的 martech 存放區，那裡有只留最新 2 版的清理規則，不寫的話映像檔會進另一個沒有清理規則的存放區，映像檔的名稱要和服務名稱相同
• --no-allow-unauthenticated 決定誰能連
• --service-account 決定服務能碰什麼
• --max 是整個服務的執行個體上限，--max-instances 是每個版本的上限，兩個都設成 1
• DAILY_CAP_TWD 是服務一天最多花新台幣幾元

步驟 3：加同事

用 3.2 那一行 add-iam-policy-binding，一個帳號執行兩次，角色分別是 roles/run.invoker 與 roles/run.viewer，你自己的帳號如果不是專案擁有者也要加，要跟著做 Day 27 的話，再替 serviceAccount:martech-pipeline-runner@${PROJECT_ID}.iam.gserviceaccount.com 綁一次 roles/run.invoker，要移除就把指令裡的 add 換成 remove。

步驟 4：實際問幾句

python3 agent/serve_try.py --free   # 只做不花錢的五項檢查
python3 agent/serve_try.py          # 再問會呼叫模型的七句話，會先印估價，輸入 yes 才開始

步驟 5：在瀏覽器裡用

gcloud run services proxy martech-assistant --project 專案ID --region us-central1 --port 8080

在自己的電腦上執行就打開 http://localhost:8080，在 Cloud Shell 執行就按右上角的網頁預覽、選通訊埠 8080，通訊埠要用 8080，換成別的對話頁送出的問題會被程式擋下。

5.4 驗證成果

bq query --nouse_legacy_sql --format=pretty < agent/serve_check.sql
bq query --nouse_legacy_sql --format=pretty < agent/serve_report.sql

• serve_check.sql 的 16 項都是 OK
• 報表第 1 段看得到每一輪問了什麼、程式做了什麼、花了多少，第 2 段是這個服務在昨天儀表板資料來源裡的樣子
• 直接把服務網址貼到瀏覽器，看到的是 Error: Forbidden

5.5 用完後怎麼處理

gcloud run services delete martech-assistant --region us-central1

服務沒人用的時候本來就不計費，留著也不會產生費用，Day 27 的排程會呼叫這個服務，要跟著做的話先不要刪，映像檔留在 martech 存放區，由清理規則保留最新 2 版，問答紀錄表 serve_turns 很小，要清掉的話用 bq rm -f -t martech_dw.serve_turns。

6. 工程實務避坑指南

1. 執行個體什麼時候被收掉不由你決定：最少 0 個執行個體的服務，閒置的執行個體隨時可能被收掉，我實測到一次是答完 4 秒後，另一次則是兩分鐘內的三句話都由同一個執行個體處理、閒置 15 分鐘後才被收掉，放在記憶體裡的東西只能當暫存，對話紀錄、花費這類不能掉的狀態都要有一份在記憶體以外的地方，我用程式連續發問的那次測試沒有遇到，改用人打字的速度才遇到
2. 登入了有權限的帳號，瀏覽器直接開網址還是 403：瀏覽器不會自動替別的網址帶上身分權杖，人要用得透過 gcloud run services proxy，或是在前面加一層 Identity-Aware Proxy 這類登入頁，只給 run.invoker 不等於同事打得開，連 proxy 這個指令都還要另外給 run.viewer
3. gcloud 給的身分權杖會過期：我的測試程式一開始就先拿好權杖，接著停在估價那一步等了二十幾分鐘，再往下問的七句話全部是 HTTP 401，我推測拿到的是先前暫存、已經快到期的權杖，更糟的是程式最後還印出問完了，後來改成確認之後才拿權杖、收到 401 就重拿一次、還是不行就停下來明講只問到幾句，官方文件也提醒 gcloud 產生的權杖是開發用的，正式的服務對服務呼叫要用指定對象的服務帳號權杖，Day 27 會用到
4. 執行個體上限 1 不是絕對的：--max-instances 是每個版本的上限，整個服務的上限要另外用 --max 設，而且官方文件說流量突增這類情況下可能短暫超過，把狀態放在記憶體裡的服務要把這一點算進去
5. 不指定存放區，映像檔會進另一個地方：gcloud run deploy --source 預設把映像檔放在 cloud-run-source-deploy，那個存放區不受 Terraform 的清理規則管，每部署一次就多留一份，要用 --image 明確指定
6. 記在記憶體裡的額度，重新啟動後要算得回來：呼叫失敗的那一次如果只記在記憶體，執行個體縮到 0 再起來就不見了，上限等於被悄悄放寬，所以失敗的呼叫也照最貴的情況寫進用量表，這一項同樣是部署前被另一方找到的
7. 本機代理會把同事的身分借給任何請求：對話頁的發問要檢查來源，只靠「反正要有權限才連得到」是不夠的，惡意網頁不需要權限，它借的是正在使用的那位同事的權限
8. 回答要當純文字顯示：Day 23 說過真正的控制在顯示的那一層，今天的對話頁把回答當純文字放進頁面，不解讀 Markdown 也不解讀 HTML，並且用內容安全政策禁止頁面載入圖片與連到外部，所以模型的回答裡會看到沒有被轉換的星號和反引號，這是刻意的
9. 問答紀錄會留下問題的原文、提問的帳號和模型原本的回答：被輸出檢查擋下沒有送出的那一段也在裡面，這是內部工具該有的紀錄，但也代表這張表本身就是敏感資料，要給誰看由 BigQuery 的權限決定，對話頁上也要明講每一句都會留下紀錄
10. 正常的回答也可能被提醒：宣稱用語的檢查是比對字串，講排名的「第一名」、講預防成效下滑的「預防」都在詞庫裡，回答裡出現就會被附上一行不能寫進廣告的提醒，Day 23 實際發生過「預防」那一次，測試程式的七句只有第三場那句拒絕的說明被附上提醒，提醒不會擋下回答，但太常出現就沒有人會看，這個誤傷目前還在

7. 總結與明日預告

今天把 Day 22 的多輪對話和 Day 23 的護欄合成一個服務，部署到 Cloud Run，不帶身分的請求是 403，只有被加進名單的帳號和排程用的服務帳號連得進來，服務用專屬的服務帳號查資料與呼叫 Gemini，映像檔裡沒有任何金鑰，實際問了七句話，呼叫模型 11 次，花了新台幣 1.09 元，顧客資料在第二場對話裡只給得出遮蔽後的樣子，在查過別的資料的第一場對話裡則完全問不到，上線後的 16 項檢查全部通過，10/9 改用瀏覽器問才發現閒置的執行個體會被收掉、對話跟著不見，改成從問答紀錄表接回來之後，隔了 19 分鐘再問的那一句接得上前面的內容，兩天合計呼叫模型 23 次、新台幣 2.13 元，都已經出現在昨天的儀表板資料來源裡。

回到篇名，把助理部署上線這件事今天做到了，讓全團隊都能直接用還沒有完全做到，會下一行指令的同事現在就能在瀏覽器裡和它對話，不會下指令的同事還需要一層登入頁，今天把這一層指了出來但沒有實作，另外三個問題的答案也都有各自的邊界，誰能連是平台保證的，能碰什麼的範圍比理想中大了一點，最多花多少在換版的那一小段時間可能多算一份，把這些都講清楚才是這個服務可以放心讓同事用的前提。

明日預告：Day 27《早上一進辦公室，AI 行銷日報已經自動寫好了》，用 Cloud Workflows 和 Cloud Scheduler 讓流程每天早上自己啟動，查成效、請 AI 分析、寫成日報，不用再有人記得去按。