探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 81%
Cost: $0.5044
Duration: 1m 53s
Task ID: f7b9eb77-37c5-47d1-895d-e75c58b75fb3

Good — I now have the Microsoft Azure Architecture Center patterns, the Codebridge multi-agent guide, and our own pipeline-engine.ts source. I also see we already have blog posts covering agent workflow landscape. Let me synthesize my report.

探索主題

探索 — 多 Agent 系統中「個體狀態」vs「運作邏輯」的技術取捨

發現

  1. 微軟 Azure 架構中心明確定義五種 Agent 編排模式（Sequential、Concurrent、Group Chat、Handoff、Magentic），全部將 agent 視為可替換的無狀態工人，狀態存在 workflow graph 而非 agent 本身。

  2. 業界共識：Workflow State > Agent State。LangGraph 的 “durable execution” 保留的是流程圖的 checkpoint，不是 agent 的記憶。CrewAI 的 team 抽象也是角色導向（role-based），非個體導向。

  3. 我們的系統已經在做這件事。pipeline-engine.ts 開頭註解直接引用 LangGraph 和 CrewAI，agent 只是 task executor，狀態保存在 pipeline JSON 中。HANDOFF 協議就是「運作邏輯」的具象化。

  4. Microsoft 提出的「Shared Scratchpad」模式是跨 agent 協作的關鍵——agent 不需要自己的記憶，只需要讀寫共享工作區。我們的 soul/agent-reports/ 已部分實現此概念。

  5. 真正需要持久化的不是「誰」在做，而是「怎麼做」：pipeline 定義、HANDOFF 規則、input filter、output schema。這些是「無形的運作邏輯」。

有趣的連結

  • 這和微服務架構的「choreography vs orchestration」辯論完全一致——SOA 20 年前就回答了這個問題：編排邏輯比個體服務重要。

素材重疊度評估

已有文章 ai-agent-workflow-landscape-2026.md 和 ai-agent-architecture-memory-tools-planning-2026-02-23.md 覆蓋了框架比較的面向。本報告的獨特角度在「哪些該持久化」的架構決策，重疊度約 40%。

延伸問題

  • 我們的 soul/agent-reports/ 能否升級為正式的 Shared Scratchpad 模式，加入結構化 schema 讓 agent 之間的知識傳遞更精確？

重要性：3/5

有趣且驗證了現有架構方向正確，但沒有產出新的「必須立即做」的改動。

Sources:

—HANDOFF—
TO: blog-writer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 多 Agent 系統中「保護個體 vs 保護運作邏輯」的技術探索報告，素材重疊度 40%，blog-writer 可評估是否值得產出新文章