Jan 31 2026
菩提樹下的楊過 -
Agent設計模式學習(基於langchain4j實現)(9) - 人機協同
經過前面的一系列流程，招聘來到了最重要的1個環節，AI雖然強大，但是不能完全代替人做決定，最終還是要Boss決策這個候選人的去留。從系統設計角度來説，整個AI智能體環節中，要預留人工干預的能力，也稱為"人機協同"（human_in_the_loop)
示例代碼：
1 @SpringBootApplication
2 public class _9a_HumanInTheLoop
AI
Jan 18 2026
菩提樹下的楊過 -
Agent設計模式學習(基於langchain4j實現)(7) - 監督者模式
書接上回，這次學習一種更高級的模式：監督者模式。職場上的牛馬們，大家回想一下，每次部門的OKR，是怎樣層層拆解最終落地的？是不是得有一個大佬(即：監督者)，根據OKR先做拆解計劃（plan)，然後把活兒派給各組去落地(action)，中間還會時不時的review？ 這個就叫做監督者模式。
仍然還是這個招聘的示例，我們定義1個監督者Agent
1 public interface HiringS
AI
Jan 17 2026
菩提樹下的楊過 -
Agent設計模式學習(基於langchain4j實現)(5) - 條件工作流
書接上回，簡歷評估完後，根據評估結果，如果合格，公司就該通知面試，否則回郵件拒絕。也就是今天要演示的“條件工作流”。下面定義這2個分支對應的Agent:
一、定義不同分支的Agent
1.1EmailAssistant (發郵件拒絕候選人Agent)
1 public interface EmailAssistant {
2
3 @Agent("向未通過篩選的候選人發送拒絕郵件
AI
Jan 17 2026
菩提樹下的楊過 -
Agent設計模式學習(基於langchain4j實現)(4) - 並行工作流
書接上回，現在簡歷已經潤色得足夠好了，投遞到了HR手上，假設跟候選人也做了初步的電話溝通。接下來，公司需要對候選人做如下審查：
經理：針對簡歷，結合招聘崗位要求，審查簡歷是否符合要求（包括優點和不足）
HR：針對簡歷，結合電話溝通記錄以及HR招聘相關要求，審查簡歷是否適合（包括優點和不足）
團隊成員：針對簡歷，評估候選人融入團隊的程度（包括優點和不足）
可以發現，這3個角色對候選人的評估
AI
