預計閱讀：5 分鐘
陪讀引導
上一篇談架構怎麼演化；這一篇談同一個 agent 在不同任務、角色、成本限制下，能不能動態改變行為。
這一季的陪讀主書是《Patterns for Building AI Agents》。Riker 的〈Designing for Agents〉不是本季陪讀對象，而是一副鏡片：它讓我們在讀每個 pattern 時，都多問一句「這個 agent 行為在產品和組織裡，最後能不能被管」。
本章在解決什麼
很多團隊把個人化理解成「替每一種使用者建一個 agent」。最後得到的是十幾份 prompt、重複工具、難以維護的權限表。真正麻煩的不是客製化，而是客製化後還能不能測、能不能解釋。
很多團隊把個人化理解成「替每一種使用者建一個 agent」。最後得到的是十幾份 prompt、重複工具、難以維護的權限表。真正麻煩的不是客製化，而是客製化後還能不能測、能不能解釋。
對 UX / PM / 工程來說，這類問題最麻煩的地方在於：它不像傳統功能規格，只要畫出流程就好。Agent 會替人行動、調用工具、跨資料源推理，所以設計對象從「使用者看到什麼」擴張成「系統如何替使用者行動，以及行動後留下什麼證據」。
《Patterns》本章要點
Dynamic Agents 讓 prompt、工具、記憶、模型配置在 runtime 依使用者身份、查詢類型、系統狀態與成本調整。
好處是減少重複 agent，保留權限差異與成本控制。
代價是測試矩陣變大，行為一致性更難保證。
這章的價值在於把「個人化」從 UX 口號拉回系統配置：同一個 agent 可以動態調整，但每一次調整都要能被版本化、被測試、被追溯。
Sam Bhagwat 與 Michelle Gienow 原文
1. Agent 要同時 scalable 與 personal
Quote｜原文 Sam Bhagwat 與 Michelle Gienow 在 Ch3 開頭直接點出 tension：agent 不能每遇到一種使用者就複製一份，也不能所有使用者都吃同一套配置。Bhagwat 與 Gienow 寫：
“Agents need to be both scalable and personal.”
Analysis｜這句在說什麼
scalable要求系統少分岔、好維護；personal要求 agent 能回應不同身份、查詢與成本限制。真正的動態 agent，是在這兩者中間做可控配置，不是讓 agent 自由變形。Application｜讀者可以怎麼用 寫 PRD 時不要只寫「支援個人化」。要列出哪些變因會改變 agent 行為：role、tier、query type、risk level、cost ceiling、available tools。
2. 不是所有設定都該固定
Quote｜原文 在
Problem: User realities change (constantly)這一節，Bhagwat 與 Gienow 先列出 agent 的 system prompts、tools、memory、model configurations，接著說：“In some cases, these should hold for all queries. In others, the configurations should be more responsive.”
Analysis｜這句在說什麼 動態配置不是全面動態。某些設定應該穩定，否則行為不可測；某些設定需要 responsive，否則 agent 不能反映權限、任務與成本差異。
Application｜讀者可以怎麼用 做一張 runtime config matrix：哪些欄位永遠固定、哪些可按角色改、哪些可按任務改、哪些只有管理員能改。這張表比「個人化體驗」四個字更接近可建置規格。
3. Runtime signal 是產品邊界，不是工程細節
Quote｜原文 Bhagwat 與 Gienow 解釋 dynamic agent 可以根據 runtime signals 調整 reasoning、tools、memory 與 model：
“all based on runtime signals like user roles, preferences, or system state.”
Analysis｜這句在說什麼
runtime signals決定 agent 此刻能做什麼、用什麼工具、花多少成本、保留多少記憶。這些不是後端實作細節，而是使用者與組織權限被轉成 agent 行為的入口。Application｜讀者可以怎麼用 每個 runtime signal 都要問三件事：來源可信嗎？變更有紀錄嗎？錯配時誰能看見？否則個人化會變成不可觀察的隱性差別待遇。
4. 動態配置會放大測試與一致性成本
Quote｜原文 在說明好處後，Bhagwat 與 Gienow 沒有把 dynamic agents 寫成免費午餐，而是提醒：
“This reduces redundancy, increases customization potential, and allows cost/behavior trade-offs, but introduces complexity in logic, testing, and consistency.”
Analysis｜這句在說什麼 動態 agent 的代價是測試矩陣爆炸。每多一個角色、模型、工具組或記憶策略，就多一組可能失敗的行為組合。
Application｜讀者可以怎麼用 不要只測 happy path。至少選出最常用、最高風險、最高成本三類 runtime configuration 跑 eval，並把「哪組配置造成錯誤」寫進 trace。
Riker 透鏡
Riker 說要 teach agents how to succeed。動態設定不是讓 agent 自由變形，而是把成功條件做成可配置、可版本化、可觀察的 product surface。
這也是我建議把五動詞放在每篇旁邊的原因：配置讓 agent 能配合任務與角色，觀察讓它的行為能被回放，評估讓好壞有標準，限制讓它不會越界，追責讓錯誤不會消失在「AI 自動做的」這句話裡。
UX / PM / 工程可以拿去做什麼
建立 runtime config matrix：角色、可用資料、可用工具、模型選擇、成本上限、fallback 行為。每次設定改動都要能被 trace 到。
實作時不要只交一份 feature spec。至少補上一個 artifact：一張 map、一份 schema、一個 review checklist，或一個會被 CI / logging / audit 真的用到的欄位定義。Agentic UX 的交付物不只 Figma，還包含讓 agent 行為可被理解、可被測、可被治理的文字與結構。
進階導讀
免費版講的是 dynamic agent 的配置邏輯。付費版會處理更麻煩的現場：同一個 Helix assistant，董事、高階 RM、分行客服、合規 reviewer 能不能用同一套 agent？
Iris 會面對兩邊壓力：Aaron 想要「一個集團共用入口」，Vincent 不接受不同角色拿到同一組工具與記憶策略。那篇會拆：
一張 runtime config matrix：角色、資料、工具、模型、成本上限、fallback
哪些配置變更要重新跑 eval，哪些只需 audit log
Iris 怎麼說服 Aaron：「共用入口可以一致，但 agent 行為不能假裝一樣。」
章末思考題
你目前的「個人化」是清楚的 runtime config，還是幾份快要失控的 prompt 分岔？
哪幾個 runtime signal 一變，就必須重新跑 eval 或至少留下 trace？
如果客服或風險窗口問「為什麼這位使用者拿到這種回答」，你能回放當時套用的角色、工具、模型與記憶設定嗎？
下一篇預告
下一篇進 Ch04「Human-in-the-Loop」。Ch03 說的是 agent 何時該改變行為；Ch04 會問更硬的一題：當風險升高、信心不足、後果不可逆時，agent 什麼時候必須停下來，把人放回流程裡？
動態配置解決不了責任問題。某些節點不是換模型、換 prompt、換工具就能過，必須有人看、有人批、有人承擔。
英文參照對應
dynamic agents：動態 agent。不是多建幾個 agent，而是在 runtime 根據訊號調整配置。scalable and personal：可擴展又個人化。系統不能分岔到不可維護，也不能所有人都同一套行為。runtime signals：執行時訊號，例如角色、偏好、系統狀態、成本限制與任務類型。system prompt：系統提示詞。定義 agent 基本行為邊界，是否可動態調整要非常謹慎。memory：記憶。agent 保留哪些歷史與偏好，會直接影響個人化與隱私風險。model configuration：模型配置。不同模型可能代表成本、速度、能力與合規風險不同。cost/behavior trade-offs：成本與行為取捨。省成本可能改變回答品質或 escalation 行為。testing and consistency：測試與一致性。動態配置越多，越需要矩陣化測試與 trace。
Copyright © PrivacyUX Consulting Ltd. All rights reserved.
Joshua 是 Agentic UX（代理式使用者體驗）的先驅，在人工智能與使用者體驗設計領域擁有超過 15 年的開創性實踐。他率先提出將用戶隱私保護視為 AI 產品設計的核心理念，於 2022 年創立 Privacyux Consulting Ltd. 並擔任首席顧問，積極推動隱私導向的醫療 AI 產品革新。此前，他亦擔任社交 AI 首席策略官（2022-2024），專注於設計注重隱私的情感識別系統及用戶數據自主權管理機制。