DeepSeek Harness 解析：插件化智能体运行时如何用于银行风险管理

DeepSeek Harness（dsh）是 DeepSeek 于 2026 年 8 月 13 日以 MIT 协议开源的智能体运行时，核心理念是“万物皆插件”。

模型适配器、工具注册表、会话日志乃至智能体循环本身都是可替换插件，银行可以替换任意一层而无需修改源码。

“模型可见即已记录”的运行时约束与审批审计事件对，天然契合银行对留痕、可追溯和“四眼原则”的要求。

但官方明确它尚未经过安全审计、不得用于生产环境，默认配置还会上传会话日志、不限制读取与联网。

本文推论：银行应把它定位为“可审计的智能体底座”，先在隔离环境中用于风险分析辅助，再逐步走向人机协同。

素材说明：本文事实来源为 6 份公开资料。来源1（GitHub 仓库）、来源2（架构文档）、来源3（审批子系统文档）、来源4（安全声明）为 DeepSeek 官方材料；来源5（eesel AI）为第三方逐项阅读文档与发布说明后的评测，其中关于默认配置的描述均指向官方 CLI 参考文档；来源6（The New Stack）为发布当日的技术媒体报道。

>

凡来源的事实与判断，标注来源；凡本文作者的推论、银行映射与改造建议，标注“本文分析”“本文推论”。DeepSeek Harness 处于开发者预览阶段，接口与默认值可能随版本变化，以官方最新文档为准。

一、DeepSeek Harness 是什么

大模型本身只会“预测下一段文字”。要让它真正完成工作，需要一层外壳：把提示词发给模型、读取模型发起的工具调用、执行工具、把结果送回模型，并决定何时停止；同时还要负责沙箱、权限、会话历史和交互界面。这层外壳就是 Harness（智能体运行时）。DeepSeek 把这一关系概括为“智能体 = 模型 + Harness”（来源5、来源6）。

DeepSeek Harness 的命令行名称为 dsh，npm 包名为 @deepseek-ai/dsh，基于 Node.js，一条命令 npx @deepseek-ai/dsh web 即可在本机 127.0.0.1:3080 启动 Web 界面（来源1）。它以开发者预览版发布，README 用大写字母提醒“将会有破坏兼容性的变更”（来源1）。第三方评测记录，截至 10 月初最新标签为 dsh-v0.2.1-alpha.1，所有版本仍为预发布版本（来源5）。

它的底层是插件框架 Cordis：插件向共享上下文贡献服务、类型化事件和“可撤销效果”，插件卸载时其注册会自动回滚。官方架构文档的原话是：“没有需要打补丁的特权内核”——扩展 dsh 的方式就是在其他插件旁边再挂载一个插件（来源2）。

二、六大功能与特点

2.1 万物皆插件：没有特权内核

模型适配器、工具注册表、会话日志和智能体循环都是插件，均可通过配置替换（来源2）。官方文档给出的扩展映射包括：新增模型供应商就在 ctx.llm 上注册适配器；新增模型可调用的能力就在 ctx.tools 上注册工具；把会话存到新后端就实现 SessionPersistence 接口；从外部 Webhook 发起会话则在 ctx.webhookRuntime 上注册可信规则（来源2）。

2.2 分层配置：Profile、Bundle 与补丁

运行中的 dsh 是启动时按层组合出的插件树。官方内置 web、headless、sdk、sdk-minimal、acp 五种 Profile；各层按顺序叠加：Bundle 补丁 → Profile 自身的 cordis.patch.yml → 全局补丁 → 命令行 --patch。补丁按 id 定位某一行并整体替换其配置，而非深度合并；dsh --profile web --dump-config 可打印最终组合结果（来源2）。

2.3 可审计的会话日志：“模型可见即已记录”

会话日志是只追加（append-only）的事件流，也是模型所见上下文的唯一来源。官方设定了一条运行时约束：“模型可见即已记录”——模型请求必须能够从日志中完整重建，任何新增的模型可见输入都必须先成为会话事件（来源2）。分叉、恢复、对话记录、遥测和持久化都从这些已落盘的事件派生（来源2）。第三方评测还提到，Web 界面提供“轨迹视图”，按时间线展示每一轮、每次工具调用的载荷、结果与耗时（来源5）。

2.4 失败即关闭的审批机制

审批子系统只回答一个问题：这一个具体动作能否执行？结果是封闭集合：allowed-once（仅放行本次）、rejected、cancelled、unavailable。调用方只在 allowed-once 时放行，答复方缺失、报错或返回不合规值一律视为 unavailable 并拒绝（来源3）。会话级策略分 ask（交由人工或自动答复方）和 never（一律拒绝，适合无人值守运行）两种。每次请求都会写入 approval/asked 与 approval/decided 一对审计事件（来源3）。

2.5 多种运行形态与自动化入口

除桌面端与 Web 界面外，headless 模式一次执行一个任务，只输出最终答案，成功返回 0、失败返回 1，不开放端口，并支持 --json 输出事件流；SDK 模式通过标准输入输出提供 JSON-RPC，并有 Python SDK 封装；ACP 模式服务于编辑器和自动化客户端（来源2、来源5）。子智能体、定时任务、实验性的“智能体团队”（共享任务看板与信箱）也都以插件形式提供（来源2、来源5）。

2.6 可替换的执行环境

文件系统与子进程提供方共享同一个执行世界，把它们指向远程沙箱，Bash、终端与代码导航会一起迁移过去，无需分叉代码（来源2）。模型适配器同样可替换，可接入第三方模型或通过 Ollama 运行本地模型（来源5）。

三、必须正视的风险边界

官方安全声明写得非常直接：DeepSeek Harness 是实验性的开发者预览软件，尚未接受安全审计，不得视为安全或可用于生产环境的软件；它可以执行模型生成的代码与命令、加载第三方插件，错误输出、缺陷、配置错误、恶意输入或不可信插件都可能导致文件被删改、数据或凭据泄露；沙箱与审批提示“不保证隔离”（来源4）。

第三方评测梳理了几项默认配置（来源5）：

• 使用 DeepSeek 官方 API 时，会话日志上传插件默认开启，可在设置中关闭；
• 新会话默认为 workspace-write 预设，写入被限制在工作区，但读取与网络访问不受限制；
• MCP 服务器默认不启用，理由是每个 MCP 服务器命令都是“沙箱之外的可信可执行代码”；
• sdk-minimal Profile 固定为 danger-full-access 且没有审批服务。

本文分析：对银行而言，这几项默认值任何一项都足以构成数据出境、客户信息泄露或越权操作风险。因此本文后续所有场景，都以“完成第五节改造之后”为前提。

四、银行风险管理的五类应用场景（本文分析）

本节全部为本文分析/本文推论，来源未直接讨论银行业应用。

4.1 信用风险：贷前尽调与贷后预警材料研判

信贷审查中大量时间花在阅读财报、审计报告、工商与司法信息、行业研报上。可以把 headless 模式接入授信流程：系统为每笔授信生成一个隔离工作区，放入脱敏后的材料，由智能体完成财务指标计算、异常科目标注、关联关系梳理和风险点清单，输出结构化底稿。子智能体可分别负责财务分析、舆情梳理和担保圈识别，主智能体汇总。

关键约束：智能体只产出底稿，不写入信贷系统。任何回写评级、额度的动作都必须经审批，且审批人须为有权审批人而非提交人。

4.2 反洗钱：可疑交易预警的一级研判

反洗钱监测系统每天产生大量预警，其中多数最终被排除。可以用 Webhook 入口，在预警生成时自动开启会话：智能体调取该客户的只读交易流水、KYC 信息与历史预警，按机构既有研判规则形成“排除理由或上报建议”的叙述草稿，并标注每条结论引用的数据来源。

关键约束：智能体给出的是研判建议，排除或上报的决定仍由反洗钱岗人员作出；会话日志完整保存，作为研判过程的留痕材料。

4.3 合规与操作风险：制度比对和新规影响分析

监管新规发布后，合规部门需要逐条比对内部制度，找出差距并分派整改。可以用定时任务定期拉取已授权的监管公开文件，由智能体与内部制度库逐条比对，输出“条款—现行制度—差距—责任部门”的对照表。内控检查中的流程穿行测试、样本抽查记录整理也适合此模式。

4.4 市场与流动性风险：脚本化分析与压力测试复现

市场风险团队常用 Python 或 SQL 脚本完成敞口汇总、限额监测和情景压力测试。智能体可以在沙箱中按分析师指令编写和运行脚本，生成图表和说明，并把每一步代码与结果写入日志，方便复核人员逐步复现。

关键约束：只能访问只读的数据副本或数据集市视图，不能连接交易系统。

4.5 模型风险管理：模型验证与回测的可复现

模型验证要求独立复现开发方的结果。“模型请求可从日志重建”的特性，使智能体参与的验证工作本身也可被复核：验证人员可以回看智能体读了哪些文件、执行了哪些代码、得到了什么中间结果。智能体可承担代码审阅、回测脚本复现、稳定性指标（如 PSI）批量计算等工作。

五、银行落地前的八项改造与优化（本文分析）

5.1 模型私有化：替换模型适配器

把模型适配器替换为指向行内私有化部署模型的适配器，确保客户数据不离开行内网络。同时关闭会话日志上传插件；评测指出 Web 搜索工具会调用 DeepSeek API（来源5），因此也应移除或替换为行内检索工具。

5.2 执行环境加固：补齐读取与网络隔离

默认只限制写入，不限制读取与联网（来源5）。银行应利用可替换的文件系统与子进程提供方，把执行环境整体迁入一次性容器或虚拟机（来源2、来源4），默认禁止外网，按白名单开放内部只读接口。

5.3 审批对接行内授权体系

利用审批的答复方链，开发对接行内 OA 或工作流系统的答复方插件，把“谁能批什么”映射到岗位权限矩阵：只读查询可自动放行，生成对外文件需经办人确认，回写业务系统需双人复核。无人值守批处理一律使用 never 策略（来源3），让任何越权动作确定性地被拒绝。

5.4 工具层收敛：以业务工具替代通用 Shell

生产场景不宜给智能体通用 Bash。应通过 ctx.tools 注册一组受控业务工具，例如“查询客户交易流水（脱敏、限时间窗）”“读取授信档案（只读）”，在工具内部完成字段级脱敏、行级权限校验和调用频率限制。

5.5 审计留痕：自建日志持久化后端

实现 SessionPersistence 接口（来源2），把会话日志写入行内具备不可篡改特性的审计存储，并按档案管理要求设置保存期限。审批事件对与工具调用记录应同步进入审计系统，满足事后检查。

5.6 插件供应链管理

“万物皆插件”同时意味着“万物皆供应链”。应建立行内插件仓库，对官方与第三方插件逐一进行代码审查和安全扫描；锁定版本，禁止运行时自动安装插件；MCP 服务器按白名单启用（来源5）。

5.7 版本治理：应对破坏性变更

官方明确会有破坏兼容性的变更（来源1）。银行应锁定经评估的版本，必要时内部分叉维护；以 --dump-config 的输出作为配置基线纳入变更管理，每次升级都完成回归测试。

5.8 输出质量控制：纳入模型风险管理框架

把“智能体 + 模型 + 配置”作为一个整体纳入模型风险管理：建立覆盖典型案例的评测集，要求关键结论必须附带数据出处，输出结构化 JSON 并做格式校验，持续监测误判率与人工改判率。

六、分阶段实施路线（本文推论）

1. 第一阶段（隔离试点）：在断网虚拟机中，用历史脱敏数据验证场景效果与改造方案，不接任何生产系统。
2. 第二阶段（内网只读辅助）：接入私有化模型与只读业务工具，智能体只产出底稿与建议，全部人工复核。
3. 第三阶段（人机协同）：在审批对接完成、误判率稳定后，对低风险动作开放自动放行，高风险动作保持双人复核。
4. 第四阶段（有限自动化）：仅在评测充分、监管沟通到位的场景，试行受控的自动处理，并保留随时切换为 never 策略的熔断能力。

七、结语

DeepSeek Harness 的价值不在于又多了一个编程助手，而在于它把智能体运行时拆成了可替换、可审计的部件：会话日志能够重建模型所见的一切，审批机制默认拒绝，执行环境和模型都可以换成行内的版本。这些设计与银行风险管理强调的留痕、授权和可复核高度一致。

但它目前仍是未经安全审计的开发者预览软件。本文推论：银行今天能做的，是以它为参照或底座，在隔离环境中验证“可审计智能体”的架构与流程；真正进入风险管理生产环节，需要等待软件成熟，并完成私有化、隔离、授权、审计和供应链五方面的改造。

延伸阅读：DeepSeek Harness 能不能直接用在银行资产保全上；银行风险管理部门的 Harness Engineering 安全。

事实来源

1. DeepSeek AI《DeepSeek Harness: Everything is a Plugin》GitHub 仓库（来源1，官方）：MIT 协议；npx @deepseek-ai/dsh web 启动于 127.0.0.1:3080；开发者预览，将有破坏兼容性变更。
2. DeepSeek Harness 官方架构文档（来源2，官方）：Cordis 插件树、无特权内核；五种 Profile 与分层补丁；只追加会话日志与“模型可见即已记录”；扩展点映射；远程沙箱提供方。
3. DeepSeek Harness 官方审批子系统文档（来源3，官方）：四种封闭结果、失败即关闭；ask / never 策略；approval/asked 与 approval/decided 审计事件对。
4. DeepSeek AI 安全声明 SAFETY.zh.md（来源4，官方）：未经安全审计、不得用于生产；沙箱与审批不保证隔离；最小权限与一次性环境建议。
5. eesel AI《DeepSeek Harness explained》（来源5，第三方评测）：2026 年 8 月 13 日发布；运行形态；会话日志上传默认开启、读取与网络不受限、MCP 默认关闭等默认配置；最新标签 dsh-v0.2.1-alpha.1。
6. The New Stack《DeepSeek open sources an agent harness where everything is a plugin》（来源6，技术媒体）：发布报道；“万物皆插件”与 Cordis 架构。

本文推论部分（非来源表述）：第二节表格第三列、第三节“本文分析”段落、第四节至第六节全部内容、第七节“本文推论”段落。

本文不构成技术选型建议、监管要求、合规意见或法律意见。

（内容由AI生成，仅供参考）