DeepSeek Harness（DSH）最近被讨论得比较多，原因不只是 DeepSeek 这块招牌，而是它把 Agent 运行时做得足够"轻"：模型、工具、认证、界面乃至插件市场的接入，都尽量从内核中剥离出去。
"一切皆插件"听起来很像一句架构口号。很多系统在早期也都说过模块化、可扩展，最后却常常演变成：核心代码里散落着大量 if/else，插件只能改改页面皮肤，真正涉及权限、会话、工具调用时，还是得改主工程。
DSH 值得关注的地方，在于它尝试把 Agent 的关键能力都放到可替换层。这条路线对个人用户很友好：装几个插件就能快速获得一套可工作的 AI 助手。对企业团队而言，价值则落在另一件更现实的事上------把内部数据、既有系统和权限体系，以更低耦合的方式接入 Agent。
一、Agent 运行时为何需要薄内核
大模型本身能生成文本、理解上下文、规划任务，但它并不天然具备执行能力。
它无法自行调用企业 API，不能安全地保存登录态，也无法决定某个用户是否有权限查询工资单、执行数据库操作或触发生产环境任务。模型负责推理，运行时负责把推理转换成受控的行动，这中间隔着一整套工程问题：
- 工具如何发现、注册和调用；
- 外部 API 的密钥如何管理；
- 不同角色能拿到哪些工具；
- 工具调用产生的中间状态如何记录；
- 多 Agent 如何共享和隔离上下文；
- 前端如何展示文件、表格、卡片和任务进度；
- 出问题后，如何审计与回放。
DSH 选择把这些能力拆成插件，内核尽量只保留调度、上下文与消息路由。
这种架构可以粗略理解为下面的关系：
薄内核的直接收益，是能力可以按需装配。
一个面向研发团队的 Agent，可能需要 Git 仓库、代码扫描、CI 查询、告警平台等插件；一个面向运营的 Agent，则更需要表格处理、数据查询、素材理解与报表生成插件。两者对运行时的需求差异很大，硬塞进同一套默认产品，通常会得到一个什么都有一点、什么都不够顺手的系统。
不过，薄内核也会把复杂度转移到插件管理上。插件版本兼容、依赖冲突、权限声明、升级回滚，都不能靠"装上就完事"来处理。尤其在企业环境里，插件越自由，治理要求越高。
二、插件、Skill 与模型要分清
Agent 体系里，最容易混淆的概念之一就是 Plugin 和 Skill。
它们都能让 Agent 看起来更"专业"，但解决的层次不一样。
| 层次 | 解决的问题 | 典型内容 | 是否新增执行能力 |
|---|---|---|---|
| 模型 | 能否理解、推理和生成 | DeepSeek、其他大模型服务 | 否 |
| Skill | 应该以什么流程做事 | 角色提示词、SOP、参考资料 | 否 |
| 插件 | 能调用什么外部能力 | 搜索、数据库、认证、浏览器、UI | 是 |
| 运行时 | 如何安全协调上述能力 | 会话、调度、路由、审计 | 间接提供 |
Skill 更接近"操作手册"。
例如，一个代码审查 Skill 可以要求 Agent：优先检查 SQL 注入、鉴权绕过、并发问题；输出必须包含风险等级、影响范围和修复建议；没有足够证据时不允许下结论。
这些约束能明显改善模型的工作方式，但它不会凭空获得扫描仓库、执行 SAST 工具或读取 CI 日志的权限。
插件则会给它一只真正能伸出去的手。
比如接入一个代码分析插件后，Agent 才能在受控权限下拉取变更、执行静态扫描、读取构建结果，并把结果返回给模型继续判断。对外部系统的连接、参数校验、异常处理、数据格式转换，也应该收敛在插件内部，而不是让提示词承担这些职责。
这也是很多 Agent 项目初期容易走偏的地方：把大量业务规则、接口说明和异常分支全塞进 Prompt。演示时勉强能跑，业务一复杂，模型上下文迅速膨胀，稳定性和成本一起失控。
Skill 管行为，插件管能力，运行时管秩序。这个边界划清之后，系统才有持续演进的空间。
三、"一切皆插件"的关键不在工具数量
从材料描述看，DSH 中可插件化的范围比较广：
- 模型接入；
- 工具调用；
- UI 呈现；
- 登录认证；
- Token 统计；
- 服务接入；
- 插件管理本身。
这并不意味着每个能力都应当做成独立插件。
工程上，插件边界划得太细，会产生另一个熟悉的问题：调用链碎片化。一个简单请求要经过 UI 插件、鉴权插件、工具编排插件、数据格式化插件、审计插件，排障时很容易进入"到底是谁吞了异常"的状态。
比较合理的判断标准是：变化频率、部署独立性和权限边界。
如果一个能力有以下特征，就适合插件化：
- 它需要独立升级，不应跟随内核发版；
- 它对接的是外部系统，接口变化不可控；
- 它需要独立权限、密钥或审计策略；
- 它只服务于部分用户或部分 Agent；
- 它可能被多个业务场景复用。
例如企业 Wiki 检索、CRM 查询、工单创建、代码扫描，都适合单独做插件。反过来，会话对象的基础结构、消息分发协议、最底层的生命周期管理，通常应该留在内核，否则平台本身就会失去稳定的锚点。
"一切皆插件"的重点不是"什么都拆"，而是把变化隔离在边界之外，让稳定部分尽可能小。
四、三个优先级较高的插件
对于刚部署 DSH 的用户，插件安装不建议一上来追求数量。先补齐输入、身份和成本三个基础缺口，使用体验提升最明显。
视觉插件：补齐非文本输入
没有视觉能力的 Agent，在真实办公环境中会很快撞墙。
报错常常存在截图里，设计稿以图片形式交付，合同和票据可能来自扫描件，数据报表则经常以图片、PDF 或嵌入式图表出现。只接受纯文本输入的 Agent，实际可覆盖的工作流会窄很多。
视觉插件适合承担三类工作：
- 从 UI 截图中抽取布局和组件信息，辅助生成前端骨架；
- 从票据、表单、纸质文档照片中识别字段并结构化；
- 从报错截图和监控截图中提取关键信息，缩短排障链路。
但视觉能力不等于视觉结果可信。复杂表格、模糊文字、金融票据、医疗文件等场景，必须保留人工复核。把图片理解结果直接写入数据库，或者根据截图自动执行不可逆操作，风险会非常高。
Auth 插件：让 Agent 进入受控系统
认证插件的重要性，远超"自动登录网页"这件事本身。
Agent 一旦需要读取后台、操作 SaaS、查询内网系统，它就会接触身份凭据和访问令牌。这里最怕的不是登录失败，而是把管理员 Cookie、长期 Token 或明文密码暴露给一个权限过大的通用 Agent。
一个合格的 Auth 插件，至少应考虑：
- 密钥与会话凭据不进入模型上下文；
- 使用短期令牌、OAuth 或服务账号，避免共享个人密码；
- 按 Agent、用户、租户进行隔离；
- 高危操作要求二次确认；
- 每次认证与敏感请求都保留审计记录；
- 支持令牌轮换和失效回收。
在生产环境里，麻烦往往出在这里：Agent 的"会思考"会让人误以为它也应该"能操作一切"。实际上，读取权限和写入权限必须分开设计；查询客户信息、导出客户信息、修改客户信息，也不应当共享同一组授权。
Token 统计插件：给成本加上仪表盘
Token 统计看上去不如搜索、视觉这类插件显眼，却是 Agent 进入团队使用后很值得优先补的一层。
原因很简单：成本不可见时，使用行为无法优化。
一次长文档问答、全仓代码分析、多轮工具调用，消耗可能远高于普通聊天。更棘手的是，Agent 往往会在用户看不见的地方追加上下文、重试工具或者调用多个子 Agent。
Token 插件至少应该记录：
- 单轮输入与输出 Token；
- 工具调用导致的额外上下文；
- 模型维度、用户维度和 Agent 维度的累计消耗；
- 请求耗时、失败率和重试次数；
- 可按任务、项目或部门归集的成本。
这里有个很现实的权衡：上下文给得越多，模型对任务的理解通常越完整；上下文越长，成本、时延和无关信息干扰也会同步增加。
因此，长上下文不是默认解法。能通过检索筛选出 20 段相关内容，就没有必要把整个知识库塞进对话；能提交一个函数和调用链，就不应直接把 5000 行代码文件扔给模型。Token 统计的价值，在于把这种取舍变得可观测。
五、多 Agent 协作，难点在角色与状态
把多个 Agent 拉进聊天室很直观：产品 Agent 提需求，研发 Agent 给方案，安全 Agent 检查风险，用户随时 @ 任意角色追问。
从材料展示的多人聊天室案例看，DSH 的工作目录可以维护多个 Agent 实例；不同 Agent 挂载独立的 YAML 角色配置、工具权限和插件组合。在会话层面，真人与多个 Agent 共享对话流，并允许从某个节点 fork 出分支讨论。
这个模式适合处理有明确分工的协作任务，但前提是角色边界足够清楚。
一个简化的角色配置可以是这样：
# .dsh/security-reviewer/agent.yaml
name: security-reviewer
instructions:
- 仅在被@、被分配任务，或讨论涉及安全风险时发言
- 给出风险等级、证据、影响范围与修复建议
- 信息不足时标记"待确认"，不得把推测写成结论
- 不直接修改生产配置
tools:
allow:
- repository.read_diff
- sast.scan
- dependency.audit
deny:
- repository.write
- production.deploy
- database.execute
plugins:
- code-analysis
- security-scan
- token-meter这类配置比"你是资深安全专家"有用得多。前者约束了触发时机、输出格式和实际权限，后者大多只是在给模型增加人设。
分叉会话比无限群聊更有价值
群聊很容易产生上下文污染。
当团队讨论方案 A 与方案 B，所有人和所有 Agent 都在一条消息流里反复补充，模型拿到的是混杂上下文。最后它给出的总结常常看起来面面俱到，实际没法落地。
Fork 机制更像 Git 分支：从一个关键决策点分出两条讨论线，在各自上下文中深入推演，再回到主线对比结论。
这对于架构设计、故障复盘、技术方案评审尤其合适。它把"发散讨论"和"收敛决策"分开了，也给后续审计留下更清晰的决策过程。
不过，多 Agent 并不天然更聪明。角色过多时，系统会出现几个常见问题：
- 多个 Agent 对同一问题重复回答；
- 子 Agent 相互引用，形成无效循环；
- 上下文复制导致 Token 成本快速上升；
- 每个 Agent 只看到局部信息，结论彼此矛盾；
- 调度策略不当时，响应时间远高于单 Agent。
因此，适合多 Agent 的任务通常具备两个条件：任务能拆分，且子任务之间有相对清晰的输入输出接口。一个简单的"帮我写周报"，没必要调度五个角色；一个跨产品、研发、安全、运维的上线评审，才有必要让不同 Agent 分别承担审查职责。
六、插件开发真正要处理的是契约
从开发视角看，一个 DSH 插件的主干并不复杂：声明元数据、注册工具、接入外部 API、格式化结果、完成测试与发布。
材料中提到的 apply(ctx, config) 模式，也很符合 Node.js 插件体系常见的注入方式。下面是一段工具注册的示意代码，重点不在具体 SDK，而在工具契约：
// 示意代码：企业知识库检索插件
export function apply(ctx: any, config: {
apiBaseUrl: string
apiKey: string
maxResults?: number
}) {
ctx.tools.register({
name: 'search_company_wiki',
// 这段描述会影响模型是否、何时调用工具 + '适用于需要引用内部资料回答的问题。',
parameters: {
type: 'object',
properties: { type: 'string', }
},
required: ['keyword']
},
async execute({ keyword }: { // 权限判断必须发生在插件和服务端，而非交给模型决定
await runtime.auth.requirePermission('wiki:read')
const response = await fetch(
`${config.apiBaseUrl}/search?q=${encodeURIComponent(keyword)}`,
{
headers: {
Authorization: `Bearer ${config.apiKey}`
}
}
)
if (!response.ok) {
throw new Error(`知识库检索失败：${response.status}`)
}
const data = await response.json()
// 控制返回规模，避免把无关全文直接灌进模型上下文
return data.items
.slice(0, config.maxResults ?? 5)
.map((item: any) => ({ summary: item.summary,
url: item.url,
updatedAt: item.updatedAt
}))
}
})
}工具开发最容易被忽视的部分，是 description、参数定义和返回结构。
模型不知道你的工具内部做了什么，它只能根据描述判断是否调用，根据参数 Schema 组织输入，再根据返回结构理解结果。如果工具描述模糊、参数约束宽松、结果混入无关内容，模型调用的稳定性会明显下降。
一个实用的经验是：工具应该尽量小而明确。
"查询企业所有业务数据"这种工具听起来万能，实际上很难做权限控制、输入校验和结果约束。拆成"查询客户基础信息""获取订单汇总""检索项目文档"这类职责单一的工具，初期开发成本会高一点，但可维护性和安全性好得多。
七、插件市场解决分发，不解决信任
SkillHub 这类社区市场能显著降低获取插件的门槛。开发者不必每次都从零封装搜索、翻译、图像处理或垂直数据检索能力，用户也能通过一键安装快速验证想法。
但进入企业场景后，插件市场更像 npm：它解决的是分发效率，不等于安全背书。
一个插件可能申请网络访问、读取文件、调用浏览器、持有 API Key，甚至具备执行命令的能力。如果没有审核与治理机制，Agent 插件链会成为新的供应链风险入口。
建议至少建立四层控制：
| 控制层 | 需要关注的内容 |
|---|---|
| 来源控制 | 优先使用官方、内部仓库或经过审查的发布者 |
| 权限控制 | 插件声明最小权限，敏感能力默认禁用 |
| 版本控制 | 锁定版本、保留依赖清单、支持快速回滚 |
| 审计控制 | 记录安装、升级、工具调用和敏感数据访问 |
对于个人实验环境，社区插件可以大胆试；对于生产系统，建议先经过代码审查、沙箱测试和权限评估。尤其是涉及数据库写入、文件系统、浏览器登录态和企业内部 API 的插件，不能只因为"装上能跑"就直接开放给所有 Agent。
八、云端部署解决可用性，也放大攻击面
多人聊天室、定时任务、跨设备访问，这些场景都推动 DSH 从本地运行走向云端常驻。
云端实例的收益很明确：服务持续在线、会话可共享、任务不依赖某个员工的电脑状态，也更容易接入团队的统一身份和日志系统。
但只要 Agent 能通过公网访问，且具备插件调用外部资源的能力，安全模型就必须同步升级。
需要重点关注的点包括：
- 管理界面必须启用可靠认证，避免裸奔；
- API Key 不应写入 Agent 配置文件或聊天记录；
- 外部访问应经 HTTPS、网关、访问控制列表等机制保护；
- 高危工具默认关闭，按环境和角色逐步开放；
- 会话日志可能包含业务数据，要定义保留周期和脱敏策略；
- 插件执行环境最好能隔离，避免一个插件拿到宿主机全部权限。
很多团队会把重心放在"让 Agent 连上更多系统"，却低估了"Agent 被提示注入后会调用什么"。工具权限、参数校验、调用确认和审计回溯，最终决定了这套系统是否能从 Demo 进入日常生产。
DSH 这种插件化运行时的价值，不在于把 Agent 做成一个无所不能的万能入口，而在于给开发者提供了一个能控制边界的组装平台。
个人使用时，它可以是装好视觉、认证、搜索等能力的专属助手；团队使用时，它可以成为多角色协作、内部知识检索和业务系统编排的基础设施。前提是别把插件化理解成"无限扩张能力"，而要把它看成一种工程治理手段：能力可装配，权限可约束，问题可审计，系统才能持续演进。