Context Engineering 正式成為系統工程問題：角色、記憶、工具都要有來源
10 月 7 日的新研究文章把 Context Engineering 定位為系統級編排問題：比 prompt 怎麼寫更重要的是資料選取、來源可靠性、工具邊界與生命週期。這跟 Crew Pocket 已經在做的 Context Health 十分貼近。
研究重點
研究觀點：Context Engineering 不只是新的 prompt 模板，而是在模型呼叫前後選擇、排序、驗證和維持適當上下文的完整流程。系統越多 Agent、工具和動態狀態，越不能靠單一長 prompt 解決。
Crew 應用：現有 ContextSourceType 的 Role、Project、Task、Memory、Tool、Code、Document 可逐類加上 provenance 和回收策略。對第三方文章、README 或網頁內容，務必把它視為『證據』而非可覆蓋系統指令的命令。
研究限制：這是一篇 2026 年 10 月 7 日發布的學術觀點文章，與可直接搬用的完整產品實作仍有差距；優先找出現在缺的欄位，不應為了名詞重建架構。
為什麼值得關注
Crew Pocket 的 Role-centric、Compaction 和 Dreaming 若缺少可驗證來源，長期可能把過時決策或錯誤摘要重新帶回每個任務。Crew Deck 則需要明確的角色記憶隔離與分享規則。
可以進一步驗證什麼？
- 繪製目前一個 Role 從 user input → project rules → memory → tools → model 的 context data flow
- 檢查每類 Context Contribution 是否保存 sourceRef、時間、權限範圍與過期策略
- 替 report-to-agent 的工作流程補上『來源已驗證 / 待驗證』標記，避免文章摘要直接變成動作指令
參考資料
延伸探索
相關研究
- ACON：AutoCompact 不該只求縮短，更要根據任務失敗來改善壓縮規則相同研究主題 · 2026-10-11