[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-agt-governed-agent-calls-zh":3,"article-related-agt-governed-agent-calls-zh":30,"series-tools-1c9e6787-9ad4-4d49-9800-b54f71149e4e":73},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"1c9e6787-9ad4-4d49-9800-b54f71149e4e","agt-governed-agent-calls-zh","AGT 把代理呼叫變受管動作","\u003Cp>我最近一直在看代理工作流，越看越火大。\u003Ca href=\"\u002Fnews\u002Fkimi-k3-model-hype-into-harness-work-zh\">模型\u003C\u002Fa>本身其實沒那麼可怕，真正出事的是中間那層黏合劑：它一下子要讀文件、一下子要寄信、一下子要碰資料庫、一下子還想跑 shell 指令，結果整個系統只靠一句「請乖乖照規則」撐著。這種東西不能叫控制，只能叫祈禱。\u003C\u002Fp>\u003Cp data-speakable=\"summary\">我拆 \u003Ca href=\"\u002Ftag\u002Fmicrosoft\">Microsoft\u003C\u002Fa> 的 Agent Governance Toolkit，整理成一份可直接複製的代理治理模板，讓工具呼叫先過政策再執行。\u003C\u002Fp>\u003Cp>這次把我拉進來的是 Microsoft 的 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-governance-toolkit\">Agent Governance Toolkit\u003C\u002Fa>。我不是把它當發表稿看，我是把它當一個我真的想放在代理前面的模式看。因為只要代理會花錢、改資料、發訊息、委派工作，治理就不能只寫在提示詞裡，得真的卡在動作前面。\u003C\u002Fp>\u003Cp>觸發我整理這篇的來源就是 \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa> repo 本身，還有 README 跟文件連結。Microsoft 明講這套工具目前是 public preview，也提供快速開始、CLI 檢查、語言套件和政策範例，還把 OWASP Agentic Top 10 納進考量。這種「好，直接給我線路圖」的材料，才是我會認真拆的東西。\u003C\u002Fp>\u003Ch2>別再把提示詞當成權限系統\u003C\u002Fh2>\u003Cblockquote>「提示詞層級的安全性，只是在跟一個隨機系統客氣地說請不要亂來。」\u003C\u002Fblockquote>\u003Cp>這句話我講得很直，因為太多代理系統真的就是這樣。你以為多塞幾句 system prompt，就等於有了控制；實際上只要工具層鬆掉，模型前一秒還很有禮貌，下一秒就可能把不該碰的東西碰了。README 寫得很明白：代理會呼叫工具、瀏覽網站、查資料庫、甚至委派給其他代理。只要做到這一步，危險點就不再是文字生成，而是執行本身。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784405026107-79g5.png\" alt=\"AGT 把代理呼叫變受管動作\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我\u003Ca href=\"\u002Fnews\u002Fopen-source-ai-agent-frameworks-compared-langfuse-zh\">比較\u003C\u002Fa>在意的是它的處理方式：每一次工具呼叫、訊息送出、委派動作，都要先在可預測的應用程式碼裡被攔下來，等政策判斷過了才會真的送出去。重點不是模型有沒有被提醒，而是動作有沒有被攔截。這才叫控制。\u003C\u002Fp>\u003Cp>我之前在內部代理原型也踩過這個坑。測試時看起來都很乖，結果一個提示注入進來，它就開始嘗試呼叫我們根本不想開放的工具。模型沒有「駭進去」，是我們前面根本沒放閘門。這就是我看到這套工具時最有感的地方。\u003C\u002Fp>\u003Cp>實操寫法很簡單：不要再問「怎麼讓提示詞更安全」，直接改問「這個動作的閘門放在哪裡」。只要會改狀態、花錢、外洩資料、跨信任邊界，就應該先過政策引擎。你如果在程式碼裡講不清楚門在哪裡，那你其實沒有門。\u003C\u002Fp>\u003Ch2>身分要能回答是誰做的，不只是誰連上來\u003C\u002Fh2>\u003Cp>README 裡有個問題我覺得很重要：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-governance-toolkit\">「Which agent did this?」\u003C\u002Fa> 這句看起來很廢話，真的做多代理系統才知道一點都不廢話。很多團隊一開始圖方便，幾個代理共用一個 API key、一個 service account、一個後端 connector。結果平台看得到是這個 app 連線，卻看不到到底是哪個代理做了決定。\u003C\u002Fp>\u003Cp>這會直接搞爛事件處理。出事之後你如果只得到「某個代理做的」，那根本沒辦法查。我要知道是哪個代理、用了哪個政策版本、走了哪條工具路徑、當時是代替誰做事。沒有這些，後面全都在考古。\u003C\u002Fp>\u003Cp>Microsoft 的文件有提到零信任身分，架構圖裡也出現 \u003Ca href=\"https:\u002F\u002Fspiffe.io\u002F\">SPIFFE\u003C\u002Fa>。如果你沒碰過，SPIFFE 是給 workload 一個可追蹤身分的標準，不是拿一包共享秘密大家輪流冒充同一個 app。這方向我很買單。代理系統最怕的就是「反正都同一把 key」，那樣你根本分不出誰做了什麼。\u003C\u002Fp>\u003Cp>我看過很多團隊在 demo 階段共用一把 key，覺得省事。真的上線後就開始痛苦：危險動作發生了，卻不知道是哪個代理觸發的，也沒辦法針對不同角色、不同環境套不同規則。治理工具如果沒有把身分放進路徑裡，後面全部都會鬆。\u003C\u002Fp>\u003Cul>\u003Cli>每個代理都給自己的身分，就算後端共用也一樣。\u003C\u002Fli>\u003Cli>日誌要同時記下 agent ID、政策版本、動作結果。\u003C\u002Fli>\u003Cli>能用 SPIFFE 這種 workload identity 標準就別再靠長效共享秘密。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>實操寫法：先定義身分模型，再寫代理邏輯。先決定誰代表代理、誰是被代理的使用者、誰是執行環境。然後把這些身分一路帶進政策評估和稽核紀錄。只要日誌回答不了「誰做了什麼」，這系統就還太鬆。\u003C\u002Fp>\u003Ch2>政策要能擋動作，不是只寫得像有在管\u003C\u002Fh2>\u003Cp>README 裡最實際的東西，就是這種兩行包裝：\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784405016304-sdrz.png\" alt=\"AGT 把代理呼叫變受管動作\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cpre>\u003Ccode>from agentmesh.governance import govern\nsafe_tool = govern(my_tool, policy=\"policy.yaml\")  # 每次呼叫都會檢查、記錄、強制執行\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我喜歡這種寫法，因為它不耍帥。包工具、檢查政策、寫入紀錄、必要時拒絕。沒有什麼神祕的代理執行環境假裝自己是安全邊界，全部都攤在程式碼裡。\u003C\u002Fp>\u003Cp>政策範例也很直白：\u003C\u002Fp>\u003Cpre>\u003Ccode>apiVersion: governance.toolkit\u002Fv1\nname: production-policy\ndefault_action: allow\nrules:\n  - name: block-destructive\n    condition: \"action.type in ['drop', 'delete', 'truncate']\"\n    action: deny\n    description: \"破壞性操作需要人工核准\"\n  - name: require-approval-for-send\n    condition: \"action.type == 'send_email'\"\n    action: require_approval\n    approvers: [\"security-team\"]\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>翻譯一下就是：政策不是註解，政策是可執行的控制流程。動作符合規則就照規則走，根本不用跟模型討論。這就是治理文件和治理系統的差別。\u003C\u002Fp>\u003Cp>我也喜歡這套工具在架構參考裡提到多種政策風格，包括 YAML、OPA、Cedar。這很重要，因為每個團隊都有自己的偏好。有人想要人看得懂的 YAML，有人已經在用 OPA，有人需要更正式的政策語言。重點不是語法長什麼樣子，重點是動作在模型外面被評估。\u003C\u002Fp>\u003Cp>實操寫法：先從最小的 deny list 開始，先擋破壞性操作和高權限副作用。接著把會寄信、改資料、碰正式環境的動作都加上明確核准流程。政策檔要跟程式碼一起版本控管，還要像安全敏感資產一樣審查。你如果不能 diff 政策，就很難相信政策。\u003C\u002Fp>\u003Ch2>沙箱不是加分題，是必要的第二道門\u003C\u002Fh2>\u003Cp>README 一直提 sandboxing，而且提得很對。只要代理能跑程式、碰檔案、叫外部工具，你就需要一個關住它的環境。不是因為模型邪惡，而是因為模型會出錯，而且輸入本來就可能是惡意的。\u003C\u002Fp>\u003Cp>這套工具把 execution sandboxing 列成核心支柱之一，跟實務狀況完全對得上。你不只要知道某個動作能不能做，你還要知道這個被允許的動作能碰到哪裡。允許執行 Python 跟允許它在受限容器裡跑，這兩件事差很多。\u003C\u002Fp>\u003Cp>我以前就看過代理在 dev container 裡亂搞，還沒上正式環境就先把自己玩壞。壞的 shell 指令、壞的檔案寫入、壞的網路呼叫，最後「助理」變成你的事故來源。沙箱就是拿來縮小爆炸半徑的。\u003C\u002Fp>\u003Cul>\u003Cli>會執行程式的工具，放進隔離容器或受限 runtime。\u003C\u002Fli>\u003Cli>讀取型工具和可寫入工具分開。\u003C\u002Fli>\u003Cli>沙箱的網路 egress 也要管，不要只管 app server。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>實操寫法：把沙箱當成政策之後的第二道門。政策決定能不能做，沙箱決定做了之後能碰什麼。如果工具是「跑 Python」，沙箱還是要限制檔案系統、環境變數、網路和程序權限。少這層，就等於把太多表面積交給代理。\u003C\u002Fp>\u003Ch2>稽核紀錄才是出事後真正的產品\u003C\u002Fh2>\u003Cp>README 直接講到稽核人員和監管單位需要可防竄改的紀錄：當時套用哪個政策、代理要求了什麼、為什麼被允許或拒絕。這不是文書作業，這是活命。代理一旦亂來，第一個問題永遠不是「提示詞看起來有沒有寫好」，而是「把決策軌跡拿來看」。\u003C\u002Fp>\u003Cp>Microsoft 也有強調工具會記錄決策。很好，這本來就該做。你只要有允許和拒絕，就一定要有能撐過事後檢討的紀錄，不然事後只能靠猜。\u003C\u002Fp>\u003Cp>很多代理\u003Ca href=\"\u002Fnews\u002Fopen-source-agent-stacks-seven-layers-2026-zh\">堆疊\u003C\u002Fa>會悄悄失敗在這裡。它們有 app log、有 tracing、有模型 telemetry，可是沒有一筆資料能把代理身分、政策版本、請求內容、決策、核准者、時間戳串起來。沒有這個，你只能說你大概知道發生什麼事，不能說你真的知道。\u003C\u002Fp>\u003Cp>我自己偏好一筆稽核事件就回答四件事：\u003C\u002Fp>\u003Cul>\u003Cli>是哪個代理發出的請求？\u003C\u002Fli>\u003Cli>是哪個政策版本在評估？\u003C\u002Fli>\u003Cli>具體要求了什麼？\u003C\u002Fli>\u003Cli>最後為什麼被允許、拒絕，還是升級人工處理？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>實操寫法：把稽核事件當成一等資料模型，不要事後才硬塞 log line。政策版本要存 hash，觸發規則名稱要記，決策用到的欄位要保留。若必須遮罩敏感值，也要確保不會把決策理由一起遮掉，不然那筆紀錄只剩時間戳和噪音。\u003C\u002Fp>\u003Ch2>把它當包裝層，不要當宗教\u003C\u002Fh2>\u003Cp>我喜歡這個 repo 的地方還有一點：它沒有把你鎖死在單一語言或 runtime。文件裡有 Python、\u003Ca href=\"\u002Ftag\u002Ftypescript\">TypeScript\u003C\u002Fa>、.NET、Rust、Go，還有 \u003Ca href=\"\u002Ftag\u002Fclaude-code\">Claude Code\u003C\u002Fa> 外掛整合。這表示維護者很清楚現實限制：治理一定要放在工具真的被呼叫的地方。\u003C\u002Fp>\u003Cp>README 也提到幾個 CLI 指令，像 \u003Ccode>agt doctor\u003C\u002Fcode>、\u003Ccode>agt verify\u003C\u002Fcode>、\u003Ccode>agt red-team scan\u003C\u002Fcode>、\u003Ccode>agt lint-policy\u003C\u002Fcode>。這種東西我會直接拿進 CI。我要的是能檢查安裝、驗證政策、跑合規檢查、掃提示注入風險的東西，而不是只在 demo 時看起來很完整。\u003C\u002Fp>\u003Cp>它標成 public preview，我也覺得合理。這不是拿來裝成熟的成品，而是先把治理骨架放出來。安全工具如果還能老實講自己是 preview，我反而比較放心，至少它沒有假裝自己永遠不會改。\u003C\u002Fp>\u003Cp>實操寫法：不要一口氣導入整套。先挑一個高風險工具包起來，把政策評估接進呼叫路徑，接著補稽核紀錄，再把會執行程式或碰檔案的工具丟進沙箱，最後才加 CI 檢查。順序很重要，因為這樣不會變成一個沒人真的用的治理表演專案。\u003C\u002Fp>\u003Cp>我也會把 wrapper 維持得很薄。治理一定要能在 \u003Ca href=\"\u002Ftag\u002Fcode-review\">code review\u003C\u002Fa> 裡看懂。如果那層封裝太厚，大家第一次被它擋到時就會繞過去。這種系統死掉通常都是這樣死的。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 代理治理起手式\n\n這是我會先放進專案的最小可用版本。\n\n## 1) 政策檔：policy.yaml\n\napiVersion: governance.toolkit\u002Fv1\nname: production-policy\ndefault_action: deny\nrules:\n  - name: allow-read-only-search\n    condition: \"action.type == 'web_search'\"\n    action: allow\n\n  - name: block-destructive-actions\n    condition: \"action.type in ['drop', 'delete', 'truncate', 'shell_exec']\"\n    action: deny\n    description: \"預設不允許破壞性或主機層級動作\"\n\n  - name: require-approval-for-side-effects\n    condition: \"action.type in ['send_email', 'create_ticket', 'write_database']\"\n    action: require_approval\n    approvers:\n      - security-team\n      - service-owner\n\n## 2) Python 包裝器\n\nfrom agentmesh.governance import govern\n\n# 把 `my_tool` 換成你真的工具函式。\n# 預期 action 物件格式：{ type, ... }\nsafe_tool = govern(my_tool, policy=\"policy.yaml\")\n\n# 範例呼叫\nresult = safe_tool(action={\"type\": \"web_search\"}, query=\"最新文件\")\n# 允許\n\nblocked = safe_tool(action={\"type\": \"delete\"}, table=\"users\")\n# 會丟出 GovernanceDenied\n\n## 3) 稽核事件格式\n\n{\n  \"timestamp\": \"2026-07-18T12:00:00Z\",\n  \"agent_id\": \"agent-123\",\n  \"user_id\": \"user-456\",\n  \"policy_name\": \"production-policy\",\n  \"policy_version\": \"1.0.0\",\n  \"action\": {\n    \"type\": \"delete\",\n    \"target\": \"users\"\n  },\n  \"decision\": \"deny\",\n  \"rule\": \"block-destructive-actions\",\n  \"reason\": \"預設不允許破壞性或主機層級動作\"\n}\n\n## 4) CI 檢查\n\n# 驗證政策語法\nagt lint-policy policies\u002F\n\n# 檢查安裝與 runtime 接線\nagt doctor\n\n# 跑治理驗證\nagt verify --strict\n\n# 掃描提示詞或代理指令的注入風險\nagt red-team scan .\u002Fprompts\u002F --min-grade B\n\n## 5) 最小導入順序\n\n1. 先包一個高風險工具。\n2. 在執行前加政策評估。\n3. 每次 allow \u002F deny 都寫稽核紀錄。\n4. 會跑程式的工具進沙箱。\n5. 加 CI 檢查，提早抓政策漂移。\n6. 每個代理分開身分，讓事件能查。\n\n## 6) 我不會省略的東西\n\n- 破壞性動作預設拒絕\n- 每個代理都有穩定身分\n- 每筆稽核紀錄都帶政策版本\n- 會執行程式的工具一定有沙箱\n- 會產生副作用的動作一定有人類核准路徑\n\n## 7) 一句話原則\n\n只要代理能改狀態、花錢、或對外說話，它在離開程序之前就應該先過政策、身分、沙箱和稽核。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板故意寫得很無聊。很好，治理本來就該無聊。真正該有趣的是代理在做的工作，不是權限模型在那邊演戲。\u003C\u002Fp>\u003Cp>如果我明天就要把這套東西塞進真實專案，我會先從政策檔和 wrapper 下手，再把稽核事件接到既有 logging pipeline。接著才補上會執行程式或碰檔案的沙箱。最後才擴到更多代理和更多工具。這個順序能把爆炸半徑壓小，也比較不會把 rollout 弄成災難。\u003C\u002Fp>\u003Cp>來源致謝：原始材料是 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-governance-toolkit\">Microsoft Agent Governance Toolkit repository\u003C\u002Fa> 與 README。我這篇的拆解是原創評論，加上依照 repo 模式整理出的可複製模板，不是 Microsoft 官方範例。\u003C\u002Fp>","我拆 Microsoft Agent Governance Toolkit 的做法，整理成可直接套用的代理治理模板，讓工具呼叫先過政策、身分、沙箱與稽核。","github.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-governance-toolkit",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784405026107-79g5.png","tools","zh","6bc7f633-a474-417a-9dbe-d4fbc46e3e61",[17,18,19,20,21],"代理治理","政策引擎","沙箱","稽核紀錄","SPIFFE",[23,24,25],"提示詞不是權限系統，真正的控制要放在工具呼叫前面。","代理治理要同時處理身分、政策、沙箱與稽核，缺一個都會鬆。","先包一個高風險工具，再逐步擴大，別一次做成治理表演。",0,"2026-07-18T20:03:17.40007+00:00","2026-07-18T20:03:17.391+00:00","9cdb6ccf-56c3-4114-adbe-65258c707a82",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"agt-governed-agent-calls-en","AGT turns agent calls into governed actions","en",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"769444fb-48a3-41d5-8383-f6867ff53232","openclaw-v2026-7-1-control-ui-workspace-zh","OpenClaw v2026.7.1 把控制台變工作區","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784358229254-0dil.png","2026-07-18T07:03:25.506405+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"7bed70e8-39cf-45bb-8f71-6ddd31ad2317","openai-screenless-speaker-turns-chatgpt-companion-zh","OpenAI 無螢幕喇叭把 ChatGPT 變陪伴","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784289800548-z10g.png","2026-07-17T12:02:53.189236+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"2151fdfb-10ca-419c-b4f6-ce36d6ff435f","scale-turns-cuda-code-into-portable-gpu-builds-zh","SCALE 讓 CUDA 變可攜 GPU 編譯","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784210602836-wqlf.png","2026-07-16T14:02:55.366575+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"194cb6f2-9263-4fe4-93f5-20f44ca1bdeb","2027-ai-ml-internship-jobs-daily-zh","2027 AI\u002FML 實習職缺每天更新","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784192579088-va17.png","2026-07-16T09:02:31.951176+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"a4781236-56a1-4b87-b223-df328fd3a0e9","mimo-code-free-trial-not-production-ready-zh","MiMo Code 免費不等於生產力：先試用，再決定是否上車","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784169179259-qkyr.png","2026-07-16T02:32:25.375192+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"44eead66-c13e-48e9-919e-2dede91d44aa","ollama-raises-65m-14-people-8-9m-users-zh","Ollama 拿下 6500 萬美元，14 人撐起 890 萬用戶","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784167385501-huif.png","2026-07-16T02:02:29.250726+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]