Anthropic 最近發佈了一篇關於 Harness 的工程實踐文章。表面上是在講產品實作，本質上回答的是一個更長期的問題：
當模型能力持續變化時，Agent 系統哪些層要穩定，哪些層應該允許快速替換？
我對這篇文章的核心理解是：Agent 基礎設施會越來越像一個輕量的 Agent OS。
重點不在「把今天的**流程寫死」，而在「定義長期穩定的系統抽象」。
很多 Agent 框架常見的問題是：
- 把模型的臨時短板固化為永久架構
- 把 prompt 工程誤當成系統邊界
- 把一次有效的補丁寫成長期依賴
模型會變強，今天合理的補丁，明天可能就是技術債。
這套思路不是承諾某一種固定編排方式，而是抽象出三層穩定介面：
session：可恢復的事件與狀態歷史harness：推理與調度循環（brain）sandbox：執行環境與工具能力（hands）
它們分離後，系統更容易替換、恢復和擴展。
一個關鍵觀點是：Session 不等於模型上下文。
Session 應該是可查詢、可回放、可恢復的事件日誌，而不是直接塞給模型的歷史拼接。
這樣做的價值：
- trimming 不等於歷史消失
- compaction 不等於事實丟失
- 崩潰恢復可以回到事件層，而不是依賴摘要記憶
Harness 應專注於調度，而不是持有業務狀態。
理想介面更接近：
execute(name, input) -> string
這代表模型只需要關心「我能調用哪些能力」，而不必強綁具體設備、容器或作業系統。
當 brain 和 hands 解耦後：
- 工具環境可以獨立演進
- 不同基礎設施可以並行接入
- 不必每個會話都預熱完整執行環境
這會直接帶來更好的啟動與擴展表現。
這種拆分通常會同時改善效能和安全。
效能上：
- 可以先啟動 brain，再按需拉起 hands
- 降低首 token 延遲（TTFT）
安全上：
- 不把高敏憑證直接暴露給模型
- 用受控 proxy / vault 做間接憑證訪問
- 安全邊界建立在系統約束上，而不是「模型應該做不到」
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/254757.html