DeepSeek Harness 技術入門與架構原理
亦凱
相關主題
商品描述
本書圍繞DeepSeek Harness（DSH），講解 Agent（智能體）軟件的系統化組織方式。全書從“模型只會生成 Token，Agent 要完成任務”這一根本矛盾切入，根據“一切皆插件”（Everything Is a Plugin）原則，剖析 DSH 如何把模型適配、工具註冊、會話記錄、Agent 循環等能力組織進統一的插件組合體系，並借助 Cordis 運行時實現插件的動態掛載、生命周期管理與依賴重新解析。全書按“先跑起來，再拆開看， 自己動手”的路徑展開，包括導讀、8章正文和2個附錄：先運行 DSH，用4套Preset（預置組合）觀察同一模型在不同能力組合下的行為；再拆解 Skill、Tool、Hook 3個擴展層次，分清 Guard、Approval、Sandbox 的執行邊界；隨後進入 Cordis，解釋插件的動態組合、生命周期與熱 新； 從設計者視角討論如何構建和驗證自己的 Harness。書中提供多組動手實驗與觀察方法。主要實驗可以使用兼容的本地模型完成；涉及特定 Provider、圖像輸入或版本接口的實驗，仍需按相應環境覆核。本書適合有一定大模型應用經驗的開發者、AI 應用工程師與架構師閱讀，也適合所有想理解“Agent 軟件應當如何組織”這一問題的技術讀者參考。
作者簡介
亦凱 ，AI 技術專家、 自媒體人，長期深耕 AI Agent 與大語言模型工程化應用領域。行業影響力：入選「知乎商業答主影響力榜」AI 方向前 10 名。憑借對前沿技術的敏銳洞察與實戰經驗，持續輸出深度技術分析，在知乎及各大技術社區具有極高的專業口碑。各主流自媒體平臺均擁有 5 萬+垂直粉絲， 博文累計閱讀量突破百萬。擅長將覆雜的底層算法原理轉化為易於理解的工程實踐指南。核心專長：專註於 AI Agent 架構設計、RAG 知識增強及多智能體協同系統。致力於打破大模型應用中的“黑盒”，幫助開發者實現從理論到生產環境的閉環落地。
目錄大綱
導讀 為什麼現在需要Harness
0.1 Model只會生成Token，但Agent要完成任務
0.2 為什麼DSH值得單獨寫一本書
0.3 本書的學習路徑
第1章 Harness不只是另一個Coding Agent
1.1 先把“產品”和“Runtime”區分開
1.2 “一切皆插件”
1.3 為什麼這不只是“多加幾個Tool”
1.4 這是否意味著DSH會成為行業標準？
1.5 Developer Preview
第2章 從零開始運行 DSH
2.1 環境準備
2.2 Workspace是Agent的“現實世界”
2.3 配置模型
2.4 預置4套Agent Preset
2.4.1 對照4套Preset
2.4.2 觀察Composition的“差分”
2.4.3 比較同一任務的執行軌跡
2.5 為什麼官方Benchmark會選Minimal
2.6 本章小結
第3章 “一切皆插件”意味著什麼？
3.1 DSH的Preset4套不是4個獨立Agent
3.2 Host Plane與Agent Plane
3.2.1 Scope Context：會話級能力從哪裏來
3.2.2 作用域的意義：動態組合必須有邊界
3.3 Standard：能力基線
3.4 PTC：同一批能力，不同的呈現方式
3.5 Minimal：把Harness壓到非常薄
3.6 Creative：讓Runtime本身也成為可操作對象
3.7 4套Preset如何體現“一切皆插件”
3.8 “一切皆插件”不等於沒有內核
3.9 本章小結
第4章 從Skill、Tool到Hook——親手改變Harness
4.1 Skill：最輕量的擴展
4.1.1 Skill路徑與默認啟用方式
4.1.2 動手實驗：刪除Skill，觀察能力是否還在
4.2 第二層：寫一個真正的工具
4.2.1 註冊也有生命周期
4.2.2 不要把Tool看成一個函數
4.3 第三層：用Hook改變執行規則
4.4 Tool Execution Pipeline：一次工具調用究竟要經歷哪些階段
4.5 Guard、Approval與Sandbox：規則判斷、單次授權與執行隔離
4.5.1 為什麼Guard要“單調”
4.5.2 Approval與Sandbox為什麼必須放在不同層
4.6 Code Mode與Pipeline：為什麼不能繞開這條管線
4.7 動手實驗：同一Tool，不同執行規則
4.8 本章小結
第5章 Cordis讓插件能夠動態組合
5.1 Temporal Composability：生命周期結束時，變化也必須被撤下
5.2 Effect的邊界
5.3 Spatial Composability：當能力環境變化時，插件還能不能運行
5.4 插件被發現，不等於已經具備運行條件
5.5 Fiber：記錄插件實例的一段生命周期
5.5.1 Fiber還記錄“誰和誰一起結束”
5.5.2 逆序清理不等於逆序完成
5.6 Cordis的HMR建立在生命周期之上
5.7 Effect與Coeffect：組件增加什麼，又需要什麼
5.8 動手實驗：讓依賴出現，消失，再回來
5.9 為什麼Cordis特別適合Agent Runtime
5.10 本章小結
第6章 Agent一輪到工作的全過程
6.1 Agent Loop不是黑盒
6.2 Turn與Step：一輪工作可以包含多次模型推進
6.3 Tool Call要經過統一執行管線
6.4 Session不是簡單的消息數組
6.5 模型看見的內容應當可追溯
6.6 為什麼“可重建”對調試特別重要
6.6.1 持久會話事件與實時Agent/能力事件：記錄事實和支持幹預
6.6.2 為什麼還要保留assistant/chunk
6.6.3 Projection：同一組事實可以生成不同視圖
6.6.4 上下文壓縮也必須保持可解釋
6.7 穩定的請求前綴與與KV Cache
6.8 從“保存事件”到“重建模型請求”
6.8.1 重建一次模型請求，至少需要哪些材料
6.8.2 能回放，不等於結果一定能覆現
6.8.3 用Session調試Agent：先找證據，再判斷是不是模型問題
6.9 本章小結
第7章 從Tool Call到Agent Runtime
7.1 Code Mode：讓模型用程序編排已有工具
7.2 Code Mode不能繞過安全治理
7.3 Code Mode的分層設計與適用邊界
7.3.1 代碼執行能力與具體實現分離
7.3.2 PTC壓縮的是確定性控制流，不是依賴語義理解的決策
7.3.3 Code Mode中的工具調用為什麼還要經過統一執行管線
7.3.4 動手實驗：用同一任務比較Native Tool Calling與Code Mode的執行效果
7.3.5 Code Mode什麼時候反而不劃算
7.4 Subagent：“子任務的委派也可以是可替換的能力
7.4.1 同一種Subagent能力，可以有不同實現
7.4.2 委派子任務的3個問題
7.4.3 委派還要明確任務和返回結果
7.5 Sandbox：決定能力在哪個受控環境中執行
7.6 持續任務機制：讓工作跨越多個Turn
7.7 Extensions：讓Agent可以觀察和修改當前Runtime
7.8 Creative為什麼屬於高信任能力
7.9 Runtime到底多做了什麼
7.10 本章小結
第8章 設計自己的Harness
8.1 從需求出發，而不是從插件列表出發
8.2 能力定義、Provider與使用方（Definition/Provider/Consumer）
8.2.1 設計一種新能力時，需要先確定什麼
8.2.2 把可替換點放在正確的層
8.3 動手實驗：寫出自己的第五套Preset
8.3.1 最
