記錄
當時用agno主要目的就是實現agent功能： 實際上一開始我們的技術方案裡面沒有這個，最早設想的是單純prompt工程加基於ragflow的知識庫 但客戶突然需求變更，提出了更復雜的查詢和儲存需求，我們討論之後就發現只能用agent做，因為涉及到多輪查詢以及總結，單純的知識庫根本不夠用 一開始我們嘗試了langchan，但否定，因為太重型，後來選擇了比較輕量部署的agno，然後就開始寫 agno最顯著的優勢就是簡單，引入即可快速部署，所以我們後來的架構就是agno+tool call去呼叫ragflow的知識庫，後者的sdk支援很好
從技術上來講，後端具體的實現是這樣的： 首先使用者傳送請求，然後構建模板prompt，裡面包含前端發來的使用者訊息：有他的name，id，以及role，還有它所包含的許可權範圍，如果使用者有上傳檔案，還有檔案的名稱和格式 處理好後，將此prompt轉到agent端，再由那邊根據agent和mcp的工具處置 auth驗證在Agent場景下最主要的特殊考量就是要將其明確在prompt，只需要前端做好包裝，確認傳來的role是正確的，那麼這部分就不用考慮太多，按role分流即可
協作主要藉助github project確定任務表單，以及騰訊會議（類似zoom）和qq（因為是中國的工程師在和我協作）。我們對進度的同步主要依賴待辦事項和定期的開會。每次開會都會討論當前進度，客戶方面的動態以及技術上是否遇到問題，如果有如何解決。
我覺得整兒個過程最困難的就是與我協作的資深工程師選擇了自己不熟悉的工具鏈，尤其是nest.js這個我之前完全沒接觸過的套件。而我的做法就是學習，先讀官方文件，然後讓ai和我一起協作——因為涉及到陌生技術，所以我非常謹慎的要求他事無鉅細的解釋（為什麼要這麼做，理由必須充分），而在我大概熟悉之後，就開始自己思考並構建。 模板程式碼有官方工具提供，而且每一個都是定義清楚地，我只需要把相關功能填入即可。 nest的後端模組很分明，
微服務架構 dify
autogen，可以多代理對話，還能群聊，以及在中途加入人類反饋一，agno就沒這功能
HippoRAG，類腦的rag框架
hono/client微服務架構，但是return要求嚴格
我協作感受到的最大感觸就是，和我搭配的那位資深工程師也是vibe為主，但是他的思維和設計也是牢牢人類主導
vibe coding 的時候，prompt 是具體到要到什麼檔案改什麼函式的 nocobase 非常牛逼，前端都能包辦，我身邊有創業公司拿這個做供應鏈管理，用了兩年多 如果需要 wordpress 體驗的後端可以用 strapi 開源夠用 國內的 ant design pro，國外的 mui toolpad core reactflow，業界標準拖動組建 logseq 風格非常強，做的已經不像 markdown
agno後來遇到問題，查不到資料庫，完全接不到vector db上，只要帶了session就出問題，後來換成了mastra，agno最大的問題就是文件支援很不全。
我覺得面試以過程導向就足夠了，和高管聊了一個半小時，就算沒有錄取也能瞭解到一些業界內容
- 政府標案裡面有不少都是舊的語言，這時候快速的學習能力和AI技巧就能用上
- 文書處理的需求是有的，但是會傾向於分佈實施，過於激進的技術嘗試不適合政府客戶
- 重點說自己過去的經驗，學歷方面只要大概解釋就好，對面既然發了面試就說明這方面不是重點
- 舊語言的架構很多都是維護，而且命名標準很差，但核心邏輯因為是程序導向，所以相對沒那麼難，但主要是搞懂在幹什麼
- 可以適當往上合理調整薪資，然後說初期可以接受基本，重點是相信公司會按能力評估調整，給對方臺階
- 講AI的時候可以多結合可以用AI提效的地方，可以去強調資深工程師的高顆粒度vibe，然後拉回人類主導
- 可以強調自己不熟但快速上手的能力，重視本質的第一性原理，從軟體工程的共通部分來推斷，剩下的其實就是熟悉跨語言的寫法和具體工具
- 強調自己的多語言導向，不過這個要看面的是什麼崗位，如果是專精的話就不能是這個策略，要朝適合的方向發力