import anyio
from claude_agent_sdk import query, AssistantMessage, TextBlock
# ① Agentic SDK 後端:呼叫會思考的 agent 生成文字(慢、秒級)
def route_draft_notice(body):
prompt = f"用繁體中文寫一段 50 字內催領通知,目前有 {body.get('stuck', 0)} 件待領包裹。"
async def _ask():
out = []
async for msg in query(prompt=prompt): # Claude Agent SDK 一次性查詢
if isinstance(msg, AssistantMessage):
out += [b.text for b in msg.content if isinstance(b, TextBlock)]
return "".join(out)
return {"route": "agentic_sdk", "generated": anyio.run(_ask)}
# ② 快取後端:第一次 miss 才查 DB,之後走記憶體(毫秒)
def route_community_stats(body):
hit = cache_get("community_stats")
if hit is not None:
return {"route": "cache_hit", "data": hit}
data = {"households": db_query("SELECT COUNT(*) FROM households")[0][0]}
cache_set("community_stats", data)
return {"route": "cache_miss_then_db", "data": data}
# ③ DB 後端:即時查真實事實,完全不靠模型
def route_parcel_status(body):
rows = db_query("SELECT status, COUNT(*) FROM parcels "
"WHERE direction='outbound' GROUP BY status")
return {"route": "db_realtime",
"facts": [{"status": s, "count": c} for s, c in rows]}
# ④ 快速計算後端:純算、無 IO(最快)
def route_late_fee(body):
days = int(body.get("overdue_days", 0))
return {"route": "compute", "overdue_days": days, "late_fee": min(days, 30) * 5}
這在 2026 已經是業界標準:A2A 由 Google 發起、現在交給 Linux Foundation 治理,有 Python、JavaScript、Java、Go、.NET 五種語言的開發套件,並已內建進 Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock 等平台。意思是,不同廠商、不同框架做出來的 agent,現在能用同一套規矩互相對話——這正是「讓大家的 agent 互通」的基礎。
關鍵:知識層為什麼要接「真實資料」,而不是寫死答案
AI 會幻覺、會忘記。所以把知識接給 agent 時,真正可靠的不是「標準答案」——答案是判斷,會隨著架構改變而過期。可靠的是兩種事實:一是「過去踩過的坑」(真的發生過,不會變),二是「資料庫此刻的真實數字」(當場查得到)。讓事實去約束 AI 的嘴,而不是讓 AI 的判斷當真理。這就是為什麼進階的知識系統(KM)會直接接上正式資料庫,而不是把答案寫死在文件裡——真相在帳本裡,不在 AI 的記憶裡。
進階:怎麼讓整個團隊在一個平台上共用 agent?
現在多數人是「一個人對一個 AI 工具」,各做各的——知識不共享、agent 不互通、同樣的事每個人重做一次。如果要讓整個團隊(包含不會寫程式的同事)在一個平台上共用 agent,要補三個能力,由淺到深:
今日的科技趨勢展現了開發者社群對「工具深度」與「系統透明度」的持續追求。無論是針對 AI 模型真實性的質疑，還是對經典分散式運算謬誤的重新審視，都顯示出技術成熟期對於基礎理論與誠實開發的重視。閱讀今日整理的文章，將幫助你從底層原理到前沿應用，建立更完整的技術視野。
🤖 AI/機器學習
🇧🇷 里約熱內盧的「本土」LLM 疑似為現有模型的混合體
這篇文章探討了巴西里約熱內盧聲稱開發了全新本土大型語言模型（LLM）的爭議。根據社群的研究與回饋，該模型似乎只是將現有的模型進行了合併或微調，而非真正的原創開發。這引發了關於 AI 研發透明度以及「本土化模型」定義的熱烈討論。對於關注區域 AI 技術發展的讀者來說，這是一個關於模型真實性與聲譽的警示案例。
壓測經驗：RLS 的「OR 擋索引」要 5.4M 才看得見，連 AI 都沒辦法 Day One 告訴你對的選擇
成本一：AI 打掉「建造成本」，沒打掉「複雜度稅」。月分區讓程式更難推理。這兩天我們親自繳了這個稅：監測資料量時，pg_total_relation_size 對分區母表只算母表本身（回 0）；還有 FK 要複合鍵、分區不繼承 RLS、清測試資料時被自己剛上的 append-only trigger 擋住……這個複雜度，是每一次未來改動、每一次 debug 都要付的稅，連 AI 也付。「AI 讓規模準備好建」是真的，「規模準備免費」是假的——稅照繳，只是從建造繳給了維護。
成本二：有些規模決策是「經驗的」，Day One 就是準備不了——RLS 自己就是鐵證。RLS 本來就是 Day One 的規模準備（多租戶隔離），結果它是錯的 Day One 選擇。為什麼當初設計看不出來？因為「OR 擋索引」這個病要 5.4M 壓測才看得見。有些決策，正確答案取決於規模行為，而那行為你預測不了——那是壓出來的，不是設計出來的。而且如前面那一節的教訓：光有規模還不夠，要對的「資料形狀」——對照社區是 0 筆的那次壓測，把第二波洩漏整個蓋住了。經驗決策不只需要壓力，需要對的壓力。
AI 時代，「規模化 Day One」從奢侈變預設。但「準備什麼」的判斷力反而更值錢：有把握的結構提前上（便宜了）；取決於規模實測的決策，老實留給壓測。
有把握的（會有很多社區 → 按社區/時間分區；離線不可妥協 → 佇列），提前做。沒把握的（隔離機制、索引策略），別假裝設計階段就能拍板。這跟我之前寫過的 企業 AI 落地為什麼失敗 是同一個底層觀念：方法論不能照抄，要看你的前提條件還成不成立。
如果只能留一句：老的 RD 有老的包袱，所以才有「MVP、先別管規模」的智慧。但那個智慧是成本算出來的。當 AI 把建造成本打掉、當你做的是領域已驗證的 V2——規模化就是 Day One 的事。只是別忘了，AI 打不掉複雜度稅，也替不了你壓測；有把握的提前上，沒把握的，老實壓出來——而且要用對的資料形狀去壓，單租戶測不出跨租戶的洩漏。
RLS 是我們「Day One 準備了錯的東西、規模化才發現」的活標本。它沒有讓這個決定變壞——它讓這個決定有了教材。