把工程 workflow 寫進 Hermes Agent 的核心思想

問題不是記憶，而是注入來源

很多人會直覺想把 workflow 存到 memory。這樣做有幫助，但不夠穩。因為 memory 更適合儲存使用者偏好、環境細節、穩定慣例；如果你要的是「代理的核心工作憲法」，那就必須放到每回合都會重新建構的 system prompt 來源。

兩條必須永久存在的工程鐵律

Implementation:
Write Code -> Run Tests -> Fail -> Fix -> Review Logs -> Fix -> Write Code (repeat)

Bug Fix:
Reproduce the issue -> Find the root cause -> Fix -> Review logs and code -> Fix (repeat) -> Add additional unit tests to improve coverage

這兩條規則不是一般提醒，而是流程憲法。它們的目的不是讓代理「更認真」，而是防止它進入典型的錯誤模式：

• 只改 code 不跑測試
• 測試過了就宣稱修完，卻沒看 runtime logs
• 沒有先重現問題就開始 patch
• 修完沒有補 regression coverage，導致 bug 回來

正確的實作方式：三層鎖定

第一層：寫進核心 prompt builder

這是最重要的一層。把 workflow guidance 寫成 prompt builder 裡的常數，例如 WORKFLOW_DISCIPLINE_GUIDANCE，並在 system prompt 組裝時固定注入。這樣代理每次開新回合時都會重新收到這套規則，不依賴聊天歷史。

第二層：寫進 SOUL.md 做備援

SOUL.md 是另一種每回合重新載入的長期人格來源。即使未來 prompt builder 邏輯被重構，SOUL.md 仍能保留這套 doctrine。

第三層：寫測試保護這個 contract

如果沒有測試，未來很容易在 refactor 時把規則意外刪掉。最好加一個測試，直接驗證 build 出來的 system prompt 確實包含 workflow 關鍵句。

為什麼測試不可少

真正會讓這套核心思想消失的，通常不是 AI 忘記，而是人類重構時把 prompt 組裝改壞。所以測試不是附加品，而是這個 doctrine 能否長期存在的保險絲。

def test_includes_workflow_discipline_guidance(self, agent):
    prompt = agent._build_system_prompt()
    assert "Write Code -> Run Tests -> Fail -> Fix -> Review Logs -> Fix -> Write Code (repeat)" in prompt
    assert "Reproduce the issue -> Find the root cause -> Fix -> Review logs and code -> Fix (repeat) -> Add additional unit tests to improve coverage" in prompt

這個測試的價值很直接：如果某次修改讓 workflow guidance 不再出現在 system prompt，CI 會先炸，而不是等你實際用到時才發現代理開始偷懶。

一個常見誤解：只存 memory 就夠了

不夠。Memory 很適合存「使用者希望之後都用繁體中文」、「偏好的稱呼方式」、「某台機器的環境細節」；但如果你要的是工程流程鐵律，這種東西應該屬於 system-level guidance，而不是 user memory。

最穩的組合通常是：

• 核心 prompt 常數：主來源
• SOUL.md：人格備援
• memory：記錄這位使用者真的很重視這套 workflow
• tests：防止未來被不小心移除