前面研究過 Tavily Extract Keyless 跟 Jina Reader，都可以讓自己的 Web Agent 直接讀取網頁，再轉成 Markdown 給 LLM 使用
後來發現 Cloudflare 其實也有類似的服務，叫做 Browser Rendering ...
前面研究過 Tavily Search API，可以讓自己的 Web Agent 直接搜尋網路
後來翻了一下官方文件，發現 Tavily 還有 Extract API，可以直接讀取網頁內容，再轉成 Markdown 給 LLM 使用
最近在開發 Web Agent，一直在找免費的 Web Search API
前面研究過 Exa、Jina，這次換來試試 Tavily
Tavily 是專門給 AI Agent 使用的搜尋 API，可以直接回傳網頁標題、網址與內容摘要，不需要自己解析 Google 搜尋頁面
重點是有免費額度，而且不用綁信用卡。
上一篇介紹了 Exa Search API，讓 AI Agent 可以直接搜尋網路，不需要再透過 Playwright 開啟瀏覽器，也不用自己解析 Google 的搜尋結果
不過搜尋只解決了一半的問題..
最近在開發 Web Agent，一直想弄個免費的 Web Search 備援
原本第一個想到 Google Search API，結果查了一下官方文件，Google 的 Custom Search JSON API 已經停止接受新用戶，既有用戶也得在 2027 年 1 月 1 日前完成遷移
以前好歹還有每天 100 次免費搜尋，現在連申請的機會都沒了 :'(
如果你有在寫 AI Agent，你就知道搜尋(Web Search)是一件麻煩的事情
如果要用 Google，你別傻了，它們是最麻煩的，光是 API 申請、設定跟計費就夠煩了，當然你可以用 Playwright 直接開瀏覽器搜尋
但是就很消耗資源，你知道的...
我之前也試過用 C# HttpClient 直接抓 DuckDuckGo，原本以為只要解析搜尋結果的 HTML 就搞定了
結果連續三次 HTTP 403，連搜尋都還沒開始就被擋下來了 XD
上一篇測了 Cloudflare Workers AI 的 FLUX.1 Schnell
這次換另外一顆：
@cf/black-forest-labs/flux-2-klein-4b這顆我覺得比 Schnell 更適合真的拿來做 Blog 圖片
原因很簡單，它可以直接設定圖片的寬高，也支援 seed , width , height ，所以如果我要 16:9，不用自己再裁圖
直接指定 1280 x 720 就可以
最近我一直在找可以直接用 API 產圖，而且成本不要太誇張的服務
最後又回頭看了一下 Cloudflare Workers AI
Cloudflare 其實不只有文字模型，它也有提供圖片生成模型，其中一個就是
@cf/black-forest-labs/flux-1-schnell
上一篇已經讓 .NET 10 ASP.NET Core 支援 MCP，OpenCode 也可以直接呼叫 UpdateHoroscope 去修改網站上的雙子座運勢
不過上一篇是直接連 http://localhost:5100/mcp
本機測試當然沒差，但如果真的放到 Server 上，這樣我自己是不太敢用 ...
最近在測 MCP，一開始看很多範例都是 Echo、GetWeather，Code 可以跑，但是我自己還是覺得有點難看出實際可以拿來幹嘛
所以這次換一個簡單一點的案例，讓你直接體驗 MCP 對於製作網站可以幹嘛
最近在看 API Client 驗證這一塊
一般除了 Token 之外，可能還會再加 DeviceId、Fingerprint 之類的資訊，用來判斷是不是原本那台 Client
但這些東西本質上還是 Client 傳一個值給 Server
如果真的想確認 Client 還是不是原本那個，就可以再多一層 Key Proof
寫 C# 久了之後，會發現效能改善不一定都要做到很複雜
很多時候不是要換架構，也不是一定要上什麼很進階的技巧， 反而只是一些平常寫 Code 時的小習慣
例如少查一次 Dictionary、少產生一個 String、少配置一個 Array，單看一次幾乎沒有差
但如果這段程式每天跑幾十萬、幾百萬次，這些小地方累積起來其實就有差了..
前一篇測試了 Scriban，主要目的就是希望在 .NET 10 裡面
可以讓前端頁面在執行期直接修改，不用每次都重新 Build、Publish、Deploy..
前一篇測試了 RazorEngineCore，主要目的就是希望在 .NET 10 裡面
可以做到像以前 ASPX 一樣，前端頁面可以直接修改，不用每次都重新 Build、Publish、Deploy..
最近朋友問我可不可以不透過 Visual Studio or Visual Code 呼叫 Github Copilot
感覺起來他就是要幹大事，其實問一下 AI 就知道可以不過我還是測試一下
畢竟可以讓程式自己寫程式，一直都是工程師的浪漫?
很多人一開始看 async/await，都會先把它當成語法糖。
我自己一開始也是這樣想
就覺得不就是把同步改成 await，讓 thread 不要卡住，看起來也比較現代一點，而且你現在用 copilot 應該也是 tab tab 就出來了
但真的在 API、網站服務，或是有點流量的系統裡用久之後，才會慢慢發現
async 不是只有能不能跑而已，它其實還會影響 效能、記憶體使用量，還有整體穩定度
有些 async code 表面上完全沒問題
但如果剛好寫在系統很常被呼叫的地方，它就可能一直默默建立 Task
平常流量小的時候不太有感，等到 request 一多，GC 開始變忙，延遲就會慢慢浮出來
一開始看到 record，其實完全抓不到重點
看起來跟 class 很像，而 class 又早就被拿來跟 struct 比過無數次
現在再多一個 record，第一反應只覺得，是不是又一個學了也不一定會用到的語法糖..
最近在整理一段舊系統的商業邏輯時，發現錯誤處理幾乎清一色都是 try/catch + throw
現在其實已經是 21 世紀了，很多時候有更好的方法可以處理 try catch 跟以前學習的方式有點不同
這篇單純記錄我實際套用 Result Pattern 後的想法與最小可行寫法筆記一下..
聊一下關於好用的 LINQ 很多時候我們從資料庫撈出資料來，並且透過 API 往外吐，這是後我們都會把肥大的資料
拿掉一些或是組合一些欄位，之後再往外面吐，當然這沒什麼問題但...
