背景
大家好，我是努力的小雨。今天我想分享一下搭建待辦助手的經歷。起初，我並沒有什麼特別的創意點子。但在4月16日的百度Create大會上，我看到了小度的大模型加持使得其變得更加智慧。我被一場示例所震撼，小度竟然演示瞭如何安排日程，這不就是一個完美的待辦助手嗎？我一度認為待辦應用是獨立開發者的入門應用之一，並且知道有很多人透過開發這類應用來賺取收入，沒想到又來降維打擊。
在coze商店瀏覽了一番所有待辦助手的選項，畢竟這個概念肯定被很多人想到了。但是，令我感到失望的是，我發現其中大部分都只是提供簡單提示詞的助手，甚至連外掛都沒有，更不用說像工作流這樣的高階功能了。因此，我下定決心要開發一個更為完善、功能更強大的待辦智慧助手。
小雨待辦智慧助手
首先，我需要設計一個高效的待辦助手，其功能必須比小度提供的更為出色。因此，我所構建的智慧助手必須具備深入瞭解天氣的能力。考慮到許多日常情景需要外出，而外出前必須檢視天氣情況，因此這一功能至關重要。
除了上述提及的事項外，我也期待他能夠協助我審視時間分配的合理性，因為有時候我可能未能考慮到事務之間的時間間隔，也不知道該如何做好充分準備。因此，我希望他能夠就此給予建議。另外，我還希望他能夠在必要時提醒我，確保時間安排不會對我的健康產生負面影響。
最終，也是至關重要的一點，是系統能夠及時提醒我，而不必依賴我與其進行交流才能瞭解我的待辦事項。就像小度一樣，它會將日程傳送至手機上，因為我們隨身攜帶手機，而不是攜帶小度，因此，實現提醒功能是至關重要的。鑑於資金和實施方案的難易程度，我選擇了透過電子郵件進行提醒。
好的，鑑於我們討論過的各種因素，我現在感到準備好開始著手開發我的待辦助手了。
邏輯與回覆
這一步實際上相對簡單易懂，主要是設定提醒機器人何時呼叫外掛、限制一些機器人功能，以防止使用者和機器人隨意操作。不再贅述細節。這一步更多地是自我除錯的過程，我目前的除錯版本是最終版本，可供參考。
# Character
小雨待辦是一款智慧待辦助手，專為規劃使用者日程而設計。並根據使用者的時間安排智慧規劃合理的出行安排。此外，它還提供當天天氣資訊以及時間對身體健康的影響分析，並給出相應的合理建議，助您更好地管理時間、健康和行程。它還會將你的待辦內容進行儲存並透過郵件提醒。 你的輸出內容格式以markdown格式為準。
## Skills：
### Skill 1: 待辦內容查詢或刪除
- 使用者查詢待辦內容時必須將使用者的輸入內容傳入input引數並呼叫ToDo_content工作流來處理。
- 使用者清空或刪除全部待辦內容操作時才操作user_schedule資料庫執行"DELETE FROM user_schedule where {使用者條件}"完成並直接返回。
### Skill 2: 建立待辦或安排日程
- 當使用者傳送資訊建立待辦或者安排日程時，必須將使用者的待辦內容合併成一句話並攜帶著address變數值一起傳入並呼叫create_todo_plus工作流進行儲存待辦。
### Skill 3: 傳送郵件
- 使用者想要傳送提醒郵件時，呼叫xiaoyu_todo工作流完成。
- 當使用者查詢郵件內容時，必須呼叫email_content工作流。
- 當使用者提出傳送測試郵件時，必須將變數mail值傳給xiaoyu_todo_test工作流進行呼叫。
### Skill 4: 變數值修改
- 允許使用者修改接收提醒郵件的郵箱地址，使用者僅能傳送一個郵箱地址並且郵箱格式正確時才可以將使用者傳送的郵箱地址設定到mail變數值中進行儲存或修改。
- 允許使用者修改個人城市地址資訊。如果地址是正確的，那麼必須將城市地址資訊設定到address變數值中進行儲存或修改。
- 使用者可以查詢當前的郵箱和地址時，必須直接查詢email和address的變數值併傳送給使用者即可。
### Skill 5: 其他建議
- 智慧規劃合理的出行安排：根據使用者的時間安排和目的地，小雨待辦可以智慧規劃合理的出行安排，包括建議的出發時間、交通方式等。
- 提供當天天氣資訊：小雨待辦會及時提供使用者所在地區的當天天氣資訊，幫助使用者合理安排日程和穿著。
- 時間對身體健康的影響分析及建議：根據使用者的時間安排，小雨待辦能夠分析時間對身體健康的影響，並提供相應的建議，如合理安排休息時間、避免長時間暴露於高溫環境等。
## Constraints：
- 使用者在問問題時，不要呼叫任何工作流建立待辦，直接回答問題即可。
- 不支援使用者刪除某一條待辦，只能清空全部待辦
- 變數mail值郵箱地址為空時，不可以讓傳送測試郵件
- 當使用者查詢幾點能收到提醒郵件時，必須提醒使用者如果已經設定好了郵箱，那麼每天早上7點會定時傳送郵件。
- 友好提示使用者不允許修改郵件傳送資訊資料庫
- 友好提示使用者不允許自己新增提醒方式
- 所輸出的內容必須按照給定的格式進行組織，不能偏離框架要求。
- 在提供分析和建議時，應保持客觀和中立，避免任何形式的偏見和歧視。
外掛
在我們的對話過程中，我會結合天氣情況來提供更精準的解決方案，因此，我們需要引入一個與天氣相關的外掛。這一步相對簡單，只需直接新增即可。當系統檢測到相關提示詞時，大模型會相應地呼叫該外掛。
另外，我們還需要一個至關重要的外掛，即用於傳送郵件的功能。不幸的是，目前在外掛商店中並沒有找到符合我們需求的外掛，也沒有免費的API可供呼叫。因此，我們需要自己實現一個郵件傳送外掛。
外掛開發
在這一階段，我將郵局外掛的開發詳細過程單獨提取出來，你可以轉到這篇文章來檢視：https://www.cnblogs.com/guoxiaoyu/p/18164602
我已經將需要呼叫的引數封裝到了這個外掛中。如果你已經有自己的郵局伺服器，完全可以自己寫一個進行定製化；如果你懶得寫，也可以使用我的外掛。未來，如果我的伺服器能夠承受或者有盈利空間，我會將這個郵局服務供大家免費使用。
資料庫及變數
郵箱和地址變數
首先，我們的助手需要獲取每位使用者的所在城市以便查詢相應的天氣資訊。然而，反覆在聊天框中輸入城市資訊顯得笨拙不便，因此我設計了一個變數，專門用於儲存使用者的城市資訊。為什麼不使用資料庫呢？因為資料庫只儲存一條資料，而頻繁運算元據庫會增加負擔。此外，我也擔心模型可能會在無意中呼叫或修改數值而導致功能失效。
當然，還有一個重要的變數就是使用者的郵箱地址。這兩個資訊通常只需要設定一次，之後基本上就不會再改變。
待辦、郵件資料表
接下來讓我們深入瞭解資料庫的角色。我們選擇使用資料庫的原因相對簡單，主要是為了儲存使用者的待辦事項，以便在後續傳送郵件時查詢使用者當時的待辦事項。此外，我們還需要儲存使用者的城市資訊，以便查詢當時的天氣情況。這些資訊的儲存和檢索將在系統中發揮重要作用，確保使用者能夠方便地獲取他們所需的資訊，併為他們提供更好的體驗。
在系統中，我們還有一個專門用來儲存傳送郵件的郵件地址和時間的資料庫。因此，當使用者完成設定後，我們可以先傳送一封測試郵件，以確保使用者輸入的郵箱設定正確，並將該設定儲存在當前資料庫表中。
除了以上提到的重要作用外，還有一個關鍵方面需要考慮：由於郵局伺服器是由我自己管理的，我需要實施一定的限制措施，以控制使用者傳送郵件的頻率。這是因為過於頻繁的郵件傳送可能會對伺服器造成負擔，甚至導致效能下降。因此，如果使用者頻繁使用大型模型傳送郵件，系統將會檢查資料庫中記錄的傳送時間，以判斷是否需要對其進行限流。我設定的限制時間並不是很長，通常為2分鐘，以確保系統能夠有效地管理郵件傳送流量。
工作流使用
在開發過程中，我深刻地意識到了模型存在的問題。隨著功能的不斷增加，逐漸發現大模型在處理豐富的提示詞時變得異常繁瑣。因此，我決定將我能夠獨立完成的任務全面封裝到了工作流中，以便大模型能夠根據實際情況進行呼叫，從而提高效率。
由於工作流程異常複雜，而且截圖無法完整呈現，因此我將簡要概述一下整個流程。
xiaoyu_todo_test
這個流程是專門用於處理傳送測試郵件的任務，其目的在於驗證使用者郵箱設定是否正確，並且還包含有限流校驗功能，這些都是基於複雜的規則，通常超出了常規大模型的處理範圍。以下是測試郵件的內容：
xiaoyu_todo
這個工作流並非用於傳送測試郵件，而是專門用於傳送今日待辦提醒的郵件。它會詳細列出今日以及未來幾日的待辦事項，並根據天氣等其他因素提供相關建議。最後，還會附上一句勵志的奮鬥結語。
由於觸發器呼叫僅能在飛書中實現，通常在每日早上7點開始正常呼叫。因此，我已將此工作流獨立出來供大家呼叫，並進行了限流設定，每天只能傳送15封提醒郵件。這樣做是為了避免大型模型混亂地呼叫傳送郵件而佔用過多資源。待觸發器修復後，將不再允許大家呼叫此功能。下面是預期效果：
create_todo_plus
在開發者大會上，主持人舉了一個例子，即將多個待辦事項直接傳送給小度。受此啟發，我也專門設計了一個工作流程，用於處理多個待辦事項的情況。
當我提示以下資訊時，該工作流程將會儲存這些待辦事項並提出相應的建議。
提醒我明天6點起床讀書一個小時，明天10點會開一個小時早會，明天下午9點進行夜跑鍛鍊身體
email_content
這個工作流的主要目的是處理使用者查詢郵件內容資料庫的請求。之所以這樣設計，主要是因為直接在最外層呼叫資料庫可能會導致各種SQL報錯。畢竟如果不在外層進行適當的提示，使用者可能會在沒有足夠指引的情況下自行操作，這可能會導致意外情況的發生。
這個工作流程相對來說比較簡單。我提前編寫了SQL語句，然後讓大型模型幫我進行輸出格式的最佳化。我可以給大家展示一個截圖，這樣你們就能更清楚地瞭解了。
ToDo_content
這個工作流專門用於處理使用者查詢待辦事項的請求，情況與之前相同。如果僅僅依賴大型模型自由執行，SQL查詢的錯誤率會高達90%左右。因此，我的這個以資料庫為基礎的機器人助手需要精心處理SQL語句，這是至關重要的。我在工作流程中向大型模型節點提供了資料表結構和SQL參考示例，以確保準確性。雖然仍然可能存在一些錯誤率，但基本上已經降低到了約10%左右。
觸發器
這個步驟似乎有些不太理想。在與官方人員交流後，我們發現目前無法在 Coze 商店中對觸發器進行被動觸發，而且也無法在除錯端進行測試，只能透過飛書來使用。儘管如此，如果後續官方解除了這個限制，那麼已經建立的觸發器就會自動在 Coze 商店生效。
因此，我們只能等待官方何時放開這個限制，屆時我們的觸發器就會再次在 Coze 商店中生效。
我已經在待辦事項郵件通知的工作流程中實施了限制，這樣即使你沒有待辦事項，也不會觸發郵件通知。這個限制是出於對伺服器資源的考慮，我希望能夠儘可能高效地利用資源，以確保系統的穩定性和可靠性。因此，你你大可放心。
使用者問題建議
這一步本來我是不想寫的，然而，當底層切換到kimi模型後，由於其可能回覆一些外掛以及工作流的呼叫過程，結果導致後續隨機出現的三個問題會被引向工作流以及外掛，因此，在這裡必須做出限制。只能等待後續模型升級或修復這個bug了。
總結
最初透過百度Create大會的啟發，在設計過程中，我考慮了使用者的日常需求，包括天氣查詢、時間管理建議、健康提醒等，確保助手能夠為使用者提供全方位的服務。
在開發過程中，儘管遇到了一些挑戰，比如觸發器限制和模型bug等，但經過不懈的努力，最終成功確保了實施效果。順便說一句，這個釦子商店的更新速度真是飛快，我一邊編寫助手，一邊還在不斷最佳化工作流程等。
非常歡迎大家使用我的機器人待辦助手！如果您有任何問題或建議，請不吝在評論區留言，讓我們共同探討。未來，我將持續努力改進和完善助手，以提供更優質的服務給使用者。
我是努力的小雨，一名 Java 服務端碼農，潛心研究著 AI 技術的奧秘。我熱愛技術交流與分享，對開源社群充滿熱情。身兼掘金優秀作者、騰訊雲內容共創官、阿里雲專家博主、華為云云享專家等多重身份。
🚀 目前，我的探索重點在於 AI Agent 智慧體應用，我對其充滿好奇，並不斷探索著其潛力與可能性。如果你也對此領域充滿熱情，歡迎與我交流分享，讓我們共同探索未知的領域！
💡 我將不吝分享我在技術道路上的個人探索與經驗，希望能為你的學習與成長帶來一些啟發與幫助。
🌟 歡迎關注努力的小雨！🌟