当 Agent 开始拥有工具和权限，软件该怎么组织
当 Agent 开始拥有工具和权限，软件该怎么组织
知识混子前阵子刷到一本新书，《DeepSeek Harness 技术入门与架构原理》，讲的是 DSH 这套 Agent 框架。
先说清楚：下面这些是看介绍整理的，书我还没读完。 这篇文章更像是一份阅读清单，把我觉得值得关注的点先记下来。
DSH 是今年 8 月开源的项目，涨星速度很夸张，据说 42 小时破了 10 万。这种热度通常会带来一个问题：用的人多，理解的人少。
README 能告诉你「有什么功能」「怎么启动」，但不会告诉你「为什么设计成这样」。而这恰恰是打算在生产环境里跑 Agent 的人最需要知道的。
一、真正的问题不是「怎么用」
这本书的定位有点特别。作者在序言里说得很直接：怎么用、有哪些参数，这些内容 AI 自己就能生成，读者上网查文档就够了。
它想回答的是另一个问题：
当大模型开始拥有工具、状态、权限、执行环境、子代理和工作流以后，一个 Agent 软件究竟应该怎样被组织？
这个问题的保质期比「DSH 怎么配置」长得多。命令行参数两三年后可能面目全非，API 也可能重写，但「组件如何组合」「生命周期如何管理」「能力如何按需装配」这些思考框架，不会随着某个框架的版本号过期。
二、为什么选 DSH 当样本
书里拿 DSH 当解剖对象，理由不是「它是行业标准」，而是它把架构公开得足够彻底。
DSH 的架构文档里有几个关键决定：
model adapter、tool registry、session log、agent loop全部放进插件体系- 产品层没有一个必须改源码才能扩展的特权核心
- 能力尽量从「不可替换的中心」降级成「可组合的插件」
也就是说，真正稳定的内核不是某个模块，而是**「组件怎么组合」这套规则**。
这个设计选择提供了一个少见的观察窗口——能看清楚一个「可组合的 Agent Runtime」到底长什么样。
三、书的结构
全书八章，分成三段，是一条「先跑起来、再拆开看、最后自己动手」的路径。
第一部分（1-2 章）建立坐标
先把「产品」和「Runtime」分开，然后从零把 DSH 跑起来。这里有个有意思的设计：用四套 Preset（Standard、PTC、Minimal、Creative）做对照实验。
不需要理解原理，用眼睛看就行——同一个模型、同一个进程，不同会话可以有完全不同的能力组合。
第二部分（3-5 章）进入内部
- 第 3 章拆「一切皆插件」的真实含义：没有特权核心，但仍然有 Kernel
- 第 4 章从 Skill、Tool、Hook 三个层次动手改 Harness，并分清 Guard、Approval、Sandbox 这三件经常被混为一谈的事
- 第 5 章深入 Cordis，看插件为什么能动态组合
第三部分（6-8 章）走向设计
第 6 章还原一轮对话在 Runtime 里究竟发生了什么，第 7 章把 Tool Call 和 Runtime 连成一条链，第 8 章切换到设计者视角，从 Capability、Provider、Policy、Preset 四个维度设计自己的 Harness。
四、两个我觉得用得上的细节
每章都是同一个四层结构：
- 它解决什么工程问题
- 官方实现放在哪里
- 运行时为什么这样工作
- 你怎样用实验验证，而不是只相信概念图
最后一条是我最看重的。讲架构的书很容易变成画概念图，但架构对不对，得能验证才算数。
实验不依赖云端模型。 书里的实验用本地模型就能跑完，几分钟能看到结果。比如删掉一个 Skill 看能力是否真的消失、让依赖出现再消失再回来、追踪一次带 Tool Call 的流程。
五、它想说的那句话
书里有一句我觉得概括得挺好：
模型只会生成 Token，Agent 要完成任务。
这两者之间的差距，就是 Harness 存在的空间——既连接，又约束。
书里也提了一个我觉得很真实的担忧：一大批团队会从「加一个工具」开始，一路走到维护十几套改不动的分支版本，然后在某个深夜被安全审计报告炸醒，发现自己根本说不清这个 Agent 到底能做什么、不能做什么。
这不是 DSH 的问题，是所有 Agent 系统共同的架构挑战。
六、一句话总结
按介绍的说法，读完能带走三样东西：一套观察框架（看到 Agent 系统会先问它的能力边界在哪）、一套设计方法（从四个维度思考而不是从零堆工具函数）、一套调试思路（知道该从 Session Event Log 开始追溯）。
我打算找时间认真读一遍。如果你也在折腾 Agent，值得一起看。
