这是《DeepSeek Harness 架构拆解》第四章。本章不再重复 Agent 的 Turn、Step 与 Session 运行流程，而是继续追问：当一套 Agent 系统进入真实工程以后，需要用哪些架构设计承接模型变化、工具副作用、能力替换和复杂任务编排？
本章从 DeepSeek Harness 源码中提炼六项可复用的工程设计：
1. **LLM Adapter 与 Provider 路由**
Agent Loop 只提交 Provider 无关的 GenerateOptions；Adapter 负责具体模型协议、流式响应和 Provider 自有行为。新增模型实现不需要侵入 Agent Loop。
2. **可组合、可重建的模型请求**
模型配置、System Prompt、Session History、Runtime Context 和当前 Scope 内的 Tool Schema 在每个 Step 统一组装。任何进入模型请求的运行事实，都必须拥有明确的记录与重建来源。
3. **ToolDefinition 与 Tool Registry**
Tool 不是“名称加回调函数”。完整定义需要覆盖输入 Schema、输出 Schema、执行、取消、超时、并发分类、模型结果投影以及 UI Presentation。一份 Registry 同时服务模型可见性、执行查找和客户端展示。
4. **Tool 执行策略流水线**
Tool Call 依次经过参数物化、pre-execute、Approval、Monotonic Guard、执行包装、Tool Body、post-execute、Normalize 和结果事件。策略异常采用 Fail Closed；最终 Guard 只能保持或收紧权限。
5. **Capability Seam 与 Agent Scope**
Consumer、Service Definition、Service Provider 三种角色共同组成完整能力。Tool 面向模型，Service 面向系统复用，Provider 决定能力在本地、沙箱还是远程实现。Scope 负责不同 Agent 的能力组合，具体安全规则则靠近真实副作用执行。
6. **Subagent 与 Workflow**
Subagent 被设计成可替换的任务委托能力；Workflow 在其上组织顺序、并行和汇总。两者继续复用 Agent、Tool、Session、取消和生命周期机制，不要求修改核心 Agent Loop。
章节最后会用一张接入决策图回答：一个新需求应该落在 LLM Adapter、ToolDefinition、Capability Service、Service Provider、Policy / Guard、Agent Scope，还是 Subagent / Workflow。
适合关注 Agent Runtime、TypeScript Agent 框架、模型适配、工具安全、沙箱、权限审批、多 Agent 和工作流架构的开发者。
