技術 Day 22：委派範圍限制的具體寫法——一次教訓换來的 prompt 設計

前言：「只做這件事」為什麼還是攔不住 昨天講完「違規但結果正確」該怎麼處理，今天要往前退一步：與其事後判斷該不該接受違規，不如先想辦法讓違規發生的機率降到最低。...

技術 Day 21：案例——一個 agent 違反只讀不寫指示，但改的內容剛好是對的

前言：結果是對的，這件事就該算了嗎？ 昨天講完「只讀不寫」這條規則該怎麼寫進委派指令，今天要面對一個更棘手的情況：規則寫得再明確，還是有 agent 會違反它—...

技術 Day 21：多 Agent 協作——什麼情況該讓子任務跑在獨立 agent

前言：改動不大，是不是就不用委派？ 「這個任務範圍很小，直接自己做不是比開一個獨立 agent 還快嗎？」 這是個很常見的直覺，而且這個直覺的判斷依據其實錯了。...

技術 Day 20：為什麼要限制 agent「只讀不寫」——查核跟修正分開的理由

前言：反正 agent 看得懂問題，順手改掉不是更有效率嗎？ 「派一個 agent 去查文章裡有沒有技術錯誤，它看到問題，順手改掉不就好了，何必還要多一趟『回報...

技術 Day 19：案例——兩個 agent 同時寫同一個檔案，事後怎麼比對取捨

前言：明明分工清楚，怎麼還是撞在一起？ 「我已經把任務拆好、每個 agent 各自負責不同的範圍了，應該不會重複吧？」 如果你也這樣想過，先別急著放心。昨天講的...

技術 Day 18：案例——一個 agent 逾越指派範圍，自己動手做了別人的工作

前言：委派出去的任務，範圍是誰畫的？ 「我只是叫它做 A，怎麼連 B、C、D 都一起做了？」 這句話聽起來像是在稱讚一個很主動的下屬，但套在委派給獨立 agen...

技術 Day 17：為什麼要委派給獨立 agent——不是「分工」這麼簡單

前言：委派不就是把工作拆給別人做嗎？ 「多 agent 協作聽起來很潮，但說穿了不就是把一件事拆成好幾份、分別叫不同的 agent 去做嗎？跟找幾個工讀生分工有...

技術 Day 29: 如何使用 AWS bedrock multi-agent 協助維運人員對 AWS 服務做 operation (上)

在前幾天的文章中，使用 Bedrock Agent 對不同的 AWS 服務進行操作，例如： 檢查 SQS 的狀態和重新執行 message 查詢 Dynamo...