AI Engineer onepage/ runtime meta-tooling
Sandhya Subramani, AWS · 20:40
這支影片在講：Agent 可以自己寫工具，但不能自己跳過治理
Sandhya Subramani 用 Strands Agents SDK 示範：一個起初沒有任何 domain tool 的 agent，遇到能力缺口時能寫出工具、動態載入並立即使用；但同一套機制也把評估、沙盒、權限與可觀測性推到系統的核心。
發布：2026-10-04講者：Sandhya Subramani（AWS GenAI）
01 / 問題
工具清單永遠不完整
預先列舉工具會卡在 long tail：使用者一旦提出新需求，agent 只能拒絕、交給人，或被迫重啟與重新部署。
02 / 反轉
把能力缺口變成任務
給 agent 編輯器、shell、載入器與「好工具長什麼樣」的指令；它可在 runtime 產生小工具，寫完即掛回自己的工具面。
03 / 解法
自由度必須配護欄
能寫工具也代表能擴大 blast radius。production 要同時評估任務、工具選擇、參數與 agent flow，並收緊執行與權限。
Signals
影片最值得抓的四個設計訊號
Starting point
0 tools
demo 從沒有 domain tool 的 agent 開始，讓需求決定要補什麼能力。
Meta-tooling
3 tools
editor、shell、load_tool 是最小能力面；其餘功能由 agent 在需要時寫入。
Agent patterns
4 種
swarm、graph、handoff、workflow 可作為 agent 拆分與協作的結構選項。
Guardrails
3 層
sandbox execution、constrained permissions、observability 共同限制自我修改的風險。
Core story
從「會寫工具」到「可被信任」的三段路
01
先定義工具的品質契約，再讓 agent 寫
agent 不是憑空產生任意程式。系統 prompt 要具體描述工具的輸入、輸出、錯誤處理與使用時機；editor 與 shell 讓它實作、試跑、修正，load_tool 才把符合契約的結果接到 runtime。
02
把「產生工具」視為另一種可測的決策
評估不能只問最後答案對不對。還要看 agent 是否選對工具、傳對參數、在多 agent 交接時維持正確 flow；否則成功只是偶然，失敗也無從定位。
03
把可執行性與權限分開收束
自寫工具需要執行環境，卻不該因此取得任意系統或資料權限。沙盒限制程式能做什麼，最小權限限制它能碰什麼，而 observability 留下誰在何時新增、呼叫與失敗的證據。
Decision map
這個架構如何運作
能力缺口：先辨認「缺什麼」使用者提出的任務超出現有工具面時，agent 不必假裝能做；它可把缺口明確化為一個受規格約束的工具需求。
生成與試跑：把 code 留在隔離區由 editor 寫檔、shell 測試，但不要把 production secrets 或寬鬆 host access 交給這個環節；每次執行都應有可追溯紀錄。
載入：把新能力當成版本化資產load_tool 不是隱形魔法。工具名稱、schema、來源、測試結果與適用範圍要可檢視，才能避免 runtime 工具面悄悄漂移。
擴張：用子 agent 處理可分解工作旅行規劃 demo 說明 agent 可自組 sub-agents；實際採用 swarm、graph、handoff 或 workflow，取決於是否需要並行、狀態機、交接或固定程序。
Use this
導入 self-modifying agent 前，先跑這份清單
把「工具品質」寫成可驗收的規格明定 schema、輸入驗證、錯誤訊息、side effect 與測試案例；不要只要求模型「幫我寫一個 tool」。
把 tool choice 與 parameter choice 放進 eval最終任務成功不足以定位問題。要獨立衡量選工具、填參數與跨 agent 流程，才能知道該改 prompt、tool 或 orchestrator。
讓生成程式先在 sandbox 執行將網路、檔案系統、process 與資源使用限制在必要範圍；預設不帶入 production credentials 或可逆性差的操作。
採最小權限，並讓升權可見工具能寫成不代表可讀、可寫、可付款或可部署。高風險權限應需要明確 policy 或人工確認。
保留工具生命週期的可觀測性追蹤生成原因、原始碼版本、測試、載入、呼叫與失敗；這是 debug、稽核與安全回應的共同基礎。
Source video