Day 25 我們看 Claude Code。

它最適合研究：

一個 Production Coding Agent 如何安全地在真實 Repository 中行動。

今天換另一個方向。

如果 Agent 的目標不只是完成一個 Session，而是：

• 跨 Session 記住使用者
• 搜尋過去 Conversation
• 累積可重用 Skills
• 從 Messaging Channel 接收工作
• 在未來時間自己被喚醒
• 把結果主動送回不同平台
• 在不同 Terminal Backend 中執行
• 長期運作，但 Idle 時不需要一直燒 Token

那 Harness 的核心問題會從：

怎麼控制一次 Coding Session？

變成：

怎麼讓 Agent 在時間上持續存在？

這就是 Hermes Agent 最值得看的地方。

Awesome Agent Architecture 研究的版本固定在 v2026.7.1，特別把它當成 Memory、Skills、Always-on Channels、Scheduling 與 Loop Engineering 的參考系統。

第一個錯誤：Long-term Agent = 一個永遠不停止的 Loop

很多人第一次想像 Personal Agent 會畫：

while True:
    think()

但這不是一個好的 Always-on Architecture。

如果 Model 永遠醒著：

• Token 持續花
• Context 持續成長
• Idle 也有成本
• Restart 很難
• 事件來源混在一起

更合理的設計是：

Idle
↓
Message / Cron / Event
↓
建立新的 Session / Task
↓
Run
↓
Persist
↓
Deliver
↓
Idle

所以 Hermes 最值得學的第一個觀念是：

Always-on 不代表 Model Always-running。

長期存在的是 Harness。

Model 只在有工作時被喚醒。

1. Memory：跨 Session 的不是 Conversation，而是選過的資訊

如果 Agent 每次重新開啟都把所有歷史 Conversation 全部塞回 Prompt：

Session 1
+
Session 2
+
Session 3
+
...

最後只會得到 Context Explosion。

Hermes 更值得看的方向是把：

Persistent Memory

當成獨立 Capability。

也就是 Day 10 的分工：

Conversation Archive
≠
Memory

Memory 應該回答：

哪些過去資訊，未來仍然值得影響 Agent？

2. Session Search 和 Memory 是兩種不同能力

Hermes 這種長期 Agent 很適合看一個常被混在一起的邊界。

Memory

保存提煉過、值得長期存在的資訊。

Session Search

在需要時搜尋過去完整 Conversation。

兩者解決不同問題。

例如：

Memory:
使用者偏好每次 Deployment 前先看 Diff

Session Search:
上週我們到底怎麼討論 payment timeout？

如果所有歷史細節都寫進 Memory，Memory Store 會變垃圾場。

如果什麼都不 Extraction，只靠 Search，又會讓 Agent 每次重新理解完整對話。

所以：

Memory 保存長期 State，Session Search 保存可追溯 History。

3. Skills：Hermes 最值得看的其實是 Procedural Memory

Memory 回答：

過去有什麼值得記？

Skill 回答：

這類 Task 下次應該怎麼做？

例如 Agent 過去多次完成：

抓 Feed
去重
整理摘要
送 Telegram

如果這種 Workflow 會重複，最有價值的不是保存所有 Transcript。

而是抽成 Skill。

概念上：

Repeated Experience
↓
Extract Procedure
↓
Skill
↓
Future Task loads Skill

這就是一種 Procedural Memory。

4. Skill Discovery 和 Skill Loading 必須分開

如果有 100 個 Skills，每次都把 100 個完整 Skill 塞進 Context，效果和巨大 System Prompt 一樣。

比較好的方式：

skills_list
↓
看到 name + description
↓
選擇
↓
skill_view
↓
載入完整內容

這正是 Day 8 的 Progressive Disclosure。

Hermes 的價值不是「有 Skills」。

而是：

Skill 可以被發現、需要時才載入，而且還可以被管理與演化。

5. Skill 能長出來，也代表 Skill 需要治理

Agent 可以學習 Workflow 很吸引人。

但「會自己學」同時帶來：

• Duplicate Skills
• Outdated Skills
• Bad Procedure
• Over-specific Skills
• Conflicting Skills

所以 Skill Evolution 一定要搭配：

• Review
• Update
• Delete / Archive
• Version
• Evaluation

真正的 Self-improvement 不是：

每次成功就多寫一個 Skill。

而是：

把反覆有效的 Experience 壓縮成可重用 Procedure，再持續整理。

6. Messaging Gateway：Channel 不應該成為 Agent Core

Hermes 可以從多種 Messaging Platform 接工作。

這裡最值得看的不是「支援很多平台」。

而是 Adapter Boundary。

理想架構：

Telegram / Slack / Discord / ...
↓
Channel Adapter
↓
Normalize Message
↓
Resolve Identity / Permission
↓
Create or Resume Session
↓
Agent Core
↓
Delivery Adapter
↓
Channel

Agent Core 不應該到處充滿：

if telegram
if slack
if discord

Channel-specific Complexity 留在 Gateway。

7. Channel 帶來的真正問題是 Identity 與 Authorization

同一個 Agent 接上 Messaging Platform 後，不能只問：

Message 內容是什麼？

還要問：

• 誰傳的？
• 這個人可以使用 Agent 嗎？
• Group Message 和 DM 權限一樣嗎？
• 這個人可以觸發哪些 Tool？
• 結果可以送到哪個 Target？

所以 Always-on Agent 的 Safety Surface 和 Coding Agent 不同。

Claude Code 很關心：

Workspace Permission

Hermes 類系統更需要：

User Identity
Channel Authorization
Delivery Scope

8. Cron：不是「讓 Agent 每分鐘自己看一下」

Hermes 的 Scheduling 很適合對照 Day 15。

好的排程不是：

Agent 永遠醒著
每分鐘想：
現在有沒有工作？

而是：

Scheduler
↓
Due Job?
↓
建立 Fresh Agent Session
↓
必要時 Load Skills
↓
Run to Completion
↓
Deliver
↓
Update next_run

這樣 Idle 時 Model 不需要存在。

9. Scheduled Task 最有趣的地方是可以帶 Skill

假設每早 9 點：

讀幾個 Feed，整理新文章，再送到 Telegram。

如果每個 Cron Prompt 都重新寫完整 Workflow：

第一步...
第二步...
第三步...

Schedule 會和 Procedure 綁在一起。

Skill-backed Scheduling 則可以拆成：

Schedule
定義：
何時做

Skill
定義：
怎麼做

Prompt
定義：
這次做什麼

這是一個很乾淨的 Responsibility Split。

10. Cron Session 不應該可以無限建立 Cron

Always-on Agent 最危險的 Loop 之一是：

Cron Task
↓
Agent
↓
建立更多 Cron
↓
新的 Cron 再建立更多 Cron

這會變成 Scheduling Explosion。

Hermes 類設計很值得學的一點就是：

Recurring Automation 本身也需要 Tool Scope。

排程執行中的 Agent 可以被限制，不讓它再自由創造更多 Schedule。

這就是 Day 19 Autonomy 的具體例子。

11. Terminal Backend：Environment 是可替換 Capability

Long-term Agent 不一定只在本機 Shell 工作。

它可能跑在：

• Local
• Docker
• SSH
• Remote Sandbox
• Cloud Environment

這時一個重要架構原則是：

Agent 不應該直接依賴某個具體執行環境。

更好的方式：

Agent
↓
Terminal Capability
↓
Backend
├── Local
├── Docker
├── SSH
└── Remote Sandbox

只要 Capability Contract 一樣，Environment 可以替換。

12. Persistent Shell 和 Persistent Memory 是兩回事

這也是很容易混淆的地方。

• Persistent Memory：跨 Session 保存知識。
• Persistent Filesystem：跨 Run 保存檔案。
• Persistent Shell：跨 Tool Call 保留 Process / Shell State。
• Session Persistence：保存 Conversation / Agent State。

四個 Persistence 的生命週期完全不同。

一個成熟 Long-term Agent 要把它們分開。

不然很容易出現：

我以為「Agent 記得」是 Memory，實際上只是上一個 Container 還沒被刪。

13. Background Process：不要用 Polling 把 Agent 變成監工

如果 Agent 啟動一個很久的 Process：

npm run server
long benchmark
training job

最差的做法是讓模型每輪問：

跑完了嗎？

這會浪費 Token。

更好的方式是：

Background Process
↓
Handle
↓
Runtime Notification
↓
Wake Agent when completed

這就是 Event-driven Background Execution。

Agent 不需要一直 Poll。

14. Always-on Agent 的中心其實是 Event Routing

把前面機制合起來：

Incoming Message
Cron
Background Completion
Remote Event
↓
Gateway / Scheduler
↓
Session Router
↓
Agent
↓
Tools
↓
Persist
↓
Deliver

所以 Long-term Agent 的核心不是一個永遠存在的 Model Context。

而是：

一個可以把不同 Event 路由到正確 State、正確 Identity、正確 Session 的 Harness。

15. Hermes 和 Claude Code 的重心其實完全不同

可以直接比較：

這就是為什麼「Agent Harness」不能只研究 Coding Agent。

不同產品場景會讓 Harness 重心完全不同。

16. Improvement Loop：真正有趣的是讓 Experience 回到 Agent

A3 在 Loop Engineering 對 Hermes 的定位很有意思：

Claude Code 比較像：

你 Script 外層 Workflow

Hermes 更接近：

Experience
↓
Memory / Skill
↓
Future Behavior

也就是 Improvement 最終會回到 Agent 的 Context 和 Procedure。

這不是一次 Eval 後人工改 Prompt 而已。

而是讓 Agent 的長期工作痕跡能形成：

• Memory
• Skill
• Better Routing
• Better Procedure

當然這也意味著更需要：

• Rollback
• Review
• Consolidation
• Evaluation

因為錯誤 Experience 也可能被放大。

17. Long-term Agent 最大的 Failure Mode 是 State Pollution

Coding Agent 最怕 Wrong Side Effect。

Long-term Agent 還多一個風險：

錯誤會持續存在。

例如：

• 記錯使用者偏好
• 建了一個壞 Skill
• 排了一個錯誤 Cron
• 把錯誤 Session 當成同一 User
• 把過時 Knowledge 每次都 Recall

一次錯誤可能影響幾個月。

所以 Long-term Agent 很需要：

Scope
Version
Expiry
Consolidation
Identity
Audit

Failure Modes

1. Always-on = Model 永遠 Running：Idle 也花成本，Context 也無限增長。
2. Conversation Archive 當 Memory：所有過去都有機會污染未來。
3. 每次 Cron 都把完整 Workflow 寫進 Prompt：Schedule 與 Procedure 綁死。
4. Scheduled Agent 可以自由再 Schedule：Recursion / Runaway Automation。
5. Channel 沒有 Identity Boundary：Memory、Task、Permission 可能跨 User。
6. Skills 只會增加，不會整理：Procedural Memory 最後變另一個 Context Landfill。
7. Background Work 需要模型一直 Poll：把 Event-driven Runtime 做成 Token-driven Polling。

從 Hermes 學到的七個原則

1. Always-on Harness 不代表 Always-running Model。
2. Memory、Session Search、Skill 是三種不同的持久化能力。
3. Schedule 定義何時做，Skill 定義怎麼做。
4. Channel Adapter 和 Agent Core 要分離。
5. Long-term Agent 的安全核心包含 Identity，不只有 Tool Permission。
6. Background Completion 應該變成 Event，不要讓模型一直 Poll。
7. Experience 能進入未來行為，也代表錯誤 Experience 必須可以被整理與回滾。

今天的結論

Hermes Agent 最值得看的不是：

它支援多少 Messaging Platform？

而是：

當 Agent 從一次 Session 變成長期存在的系統，Harness 的核心從「控制一次 Action」變成「管理跨時間的 State、Identity、Trigger 與 Procedure」。

Claude Code 告訴我們：

Model 怎麼安全碰 Repository。

Hermes 告訴我們：

Agent 怎麼在你離線之後仍然存在，但不需要 Model 永遠醒著。

下一篇我們會走到完全相反的極端。

如果我們把大量 Harness Layer 拿掉，只留一個 Bash Tool、一個小 Loop、Budget 和 Eval，Agent 還能不能解真實 Software Engineering Task？

Day 27：mini-swe-agent。

完整系列與程式碼範例收錄於 https://github.com/hardness1020/awesome-agent-architecture