DeepSeek Harness 能不能直接用在银行资产保全上——官方安全通告划的红线，与三处结构性错配

DeepSeek Harness 能不能直接用在银行资产保全上——官方安全通告划的红线，与三处结构性错配

DeepSeek Harness 确实是官方产品——2026-08-13 开源、MIT 许可、239,580 star、基于 Cordis 的"everything-is-a-plugin"架构。但它自己的 SAFETY.md 写明：未经过安全审计，不得视为安全或生产就绪。所以"能不能直接用"这句话，官方已经替我们答了一半。

真正的错配不在模型能力，而在抽象层。55 个官方插件包里，fs／shell／terminal／subprocess／ssh／lsp／ptc-runtime 面向的是代码工程；能直接复用到案件、押品、诉讼节点的，接近于零。

三处硬约束与资产保全正面冲突：Files API 只收图片不收 PDF/DOCX，而资产保全的原材料恰恰是法律文书与卷宗；JSON Output 官方承认"可能返回空内容"；thinking 模式默认开启且温度类参数被钳制。

结论是一句话：能借它的插件机制，不能借它的安全边界。 把 dsh 当插件框架用，安全边界由银行自建层承担——这既是技术判断，也是金发〔2026〕8号下唯一站得住的姿势。

一、先把这个名字说清楚

很多讨论里"DeepSeek harness"是个含糊说法。它确实存在，而且是官方开源项目，这些都能在仓库元数据里直接核到（PRIMARY，GitHub API 于本文核验日取得）：

启动方式是 npx @deepseek-ai/dsh web，默认在 http://127.0.0.1:3080 起 Web UI（PRIMARY，README 原文）。

但有两个必须同时读的事实。README 在标题下方第一段就写着：DeepSeek Harness 处于 developer preview，并且用加粗强调"THERE WILL BE COMPATIBILITY-BREAKING CHANGES"（PRIMARY，README 原文）。

而仓库根目录有一个 SAFETY.md，README 要求"运行本项目前请阅读安全通告"。它的第一段是（PRIMARY，SAFETY.md 原文）：

DeepSeek Harness is experimental developer-preview software. It has not undergone a security audit and must not be treated as secure or production-ready.

一个 239,580 star 的项目，同时在 README 里说"会有破坏性变更"、在安全通告里说"没做过安全审计"。这两句话必须一起拿给合规看。 只讲前者是选择性披露。

二、官方自己划的三条红线

The project can execute model-generated code and commands, load third-party plugins, and access the network, processes, credentials, and files made available to it.

Sandboxing, approval prompts, and permission controls can reduce risk, but they do not guarantee isolation or prevent damage. Even correctly enforced restrictions cannot protect resources that the project is allowed to access. Do not rely on DeepSeek Harness as the sole security control for untrusted workloads.

把它翻成银行的语言：这个 harness 的设计前提就是"它能执行模型生成的代码和命令、能加载第三方插件、能碰到你给它的凭据和文件"。而沙箱、审批弹窗、权限控制只降低风险、不保证隔离；即便限制全部正确执行，也保护不了项目已被允许访问的资源。

对资产保全的直接后果：押品估值影像、征信报告、诉讼卷宗、当事人身份证号与银行卡号——这些正是"项目被允许访问的资源"。官方在此明确说不要把它当作不可信工作负载的唯一安全控制。

顺带把监管侧的对应条款摆出来（PRIMARY，金发〔2026〕8号《关于银行业保险业人工智能安全开发应用的指导意见》，2026-06-18 发布）：

• （十六）高风险应用准入：涉及"资金交易、资产评估、信贷审批、承保理赔、风险管理等，以及"与客户利益直接相关、直接影响金融合约达成"的生成式 AI 场景应用，应被视为高风险应用
• （二十五）智能体系统安全：持续监控模型行为，防范"提示词注入、思维链注入、多模态攻击、上下文污染"等威胁
• （二十二）可解释性：可解释性不足的 AI 技术应用于高风险场景时，仅能作为辅助工具
• （二十四）数据红线："姓名、身份证号、手机号、银行卡号等个人信息和隐私数据不得用于生成式人工智能模型训练和优化"
• （五）模型准入：对生成式 AI 模型实施准入管理；"外部引入的生成式人工智能模型需经过网信部门备案"

把两侧拼起来，结论没有回旋余地：资产保全落在（十六）的高风险应用里，而 DeepSeek Harness 官方自述未过安全审计、且其安全机制不被官方承认为可靠隔离。一个高风险应用不能建在一个自己声明"不要当作唯一安全控制"的基础上。

这不是"先小范围试点"能解决的——（二十二）已经把"可解释性不足者仅能作辅助工具"写死了，一个没有通过安全审计的运行时不可能提供可解释性保障。

三、错配之一：抽象层——55 个插件说明了什么

这是本文最实的一段观察。packages/ 目录下共有 55 个插件包（PRIMARY，GitHub API 目录列举于本文核验日）。按用途粗分：

面向代码工程的（占比最大）：fs、shell、terminal、subprocess、ssh、lsp、pty-runtime、computer-use、browser-use、document、attachment、compaction、context、plan、subagent、todo

治理与基础设施的：sandbox、guard、hooks、credentials、identity、storage、session、telemetry、runtime-diagnostics、schedule、jobs、workflow、mcp、skill、llm、api、web、sdk、core、boot、preset、bundle

结论很直白：这个 harness 的世界模型是"工作区文件 + 命令执行 + 计划与委派"。官方文档的示例任务是"Summarize this repository and identify its main packages"（PRIMARY，官方 quickstart 原文）。

而资产保全的世界模型是案件、债权、押品、诉讼节点、催收工单、时效台账。fs 与 shell 在这里没有对应物——押品台账不是工作区文件，案件流转不是 shell 命令。

这意味着"直接用"在字面意义上不成立：不是配置项没调对，而是它没有"查询押品系统""生成调解方案草稿""推进诉讼节点"这类工具。这些工具必须由银行自己写。

好消息是扩展点是干净的（PRIMARY，官方开发文档）：插件是一个导出 apply 函数的 TypeScript 模块，通过 ctx.tools.register(defineTool({...})) 注册能力，parameters 负责参数推断与校验，output.schema 声明规范值、output.render 转成模型可见内容，参考文档里还列了 policy hooks、后台任务与 UI 卡片。

换句话说：能力可扩展，边界不可继承。 你能把银行工具接进去，但你接进去的东西是否安全、是否留痕、是否可回退，全部由你自己写——而这恰好是官方明说不负责的那部分。

四、错配之二：输入形态——只收图片的 Files API

资产保全的原始材料是什么？法律文书、借款合同、担保合同、法院判决书、卷宗、催收记录、押品评估报告。 这些绝大多数是 PDF 或 DOCX。

而官方 Files API 的支持范围是（PRIMARY，官方文档）：JPEG、PNG、GIF、WebP。

这是一条硬墙。资产保全的输入必须先经过 OCR 或格式转换才能进入系统，而转换本身就是一个新的错误来源——扫描件 OCR 的数字与日期错误、表格跨页断裂、印章与手写批注丢失。这些错误会一路流到下游的判定环节。

更麻烦的是它与（一）里那条"格式与口径"判据的冲突：站内已有的资产保全任务分型把"材料完整性判断"列为最值得评估微调的窄分类型，因为它四项判据可同时成立。但如果材料要先过一道有损的 OCR，那这个任务的错误就不再可归因到"模型输出"这一层——你无法区分是模型判错、还是 OCR 就没读出来。

适配含义：材料摄取必须自建，并且必须保留原件与 OCR 结果的逐项对应关系，让判定结论能回指到原文位置。

五、错配之三：确定性——三处官方承认的松动

资产保全与零售智能体支付共享一个硬约束：同一个输入必须映射到同一个结果。而 DeepSeek 的官方文档在三个地方承认了不确定性（全部 PRIMARY，出处见文末 references）：

其一，结构化输出可能为空。 JSON Output 指南原文：

When using the JSON Output feature, the API may occasionally return empty content.

这一条对银行特别致命。押品台账核对、材料齐备性检查、时效监控，全部建立在"结构化抽取出一个字段"之上。返回空内容不是报错，是一次静默失败——而静默失败在流程／工具型任务里是最难发现的一类缺陷。

其二，strict 模式是 Beta，且 schema 子集受限。 要启用需把 base_url 切到 /beta，且所有 function 都要 strict: true；同时每个 object 的全部 properties 必须都列入 required、additionalProperties 必须为 false，而 minLength／maxLength／minItems／maxItems 不被支持（PRIMARY，Tool Calls 指南）。

后果：银行真实的风控校验——金额区间、日期先后、比例阈值、枚举取值——大部分无法表达在这个 schema 子集里，只能退回到 harness 侧自己校验。这直接削弱了"用模型自身的约束来保证正确性"这条捷径。

其三，思考模式会削弱可复现性，而它是默认开的。 官方定价页写明两个模型都"Supports both non-thinking and thinking (default) modes"（PRIMARY）。而思考模式下不支持 temperature／presence_penalty／frequency_penalty，且 top_p 被钳制在 0.95–1.0 区间，超出部分按边界处理；非思考模式下 top_p 固定为 1.0、用户传值被忽略（PRIMARY，Thinking Mode 指南）。

也就是说：想要批处理可复现，就必须显式关掉思考；而关掉思考这件事，在走 OpenAI 兼容网关时不会自动生效。 官方配置文档为此专门给了一个开关——针对"除非被告知否则就会思考"的模型（例如 OpenSeek 兼容网关后面的 DeepSeek V4），需要设 compat.thinkingFormat: deepseek，off 才会真正发出 thinking: {type: disabled}（PRIMARY，harness providers 文档）。

这一条是本文最实用的单点发现：它不是理论问题，是一个真实的、会导致"我明明关了思考、账单却还是按思考模式走"的生产事故来源。

还有一个连带约束：带 tools 时，reasoning_content 必须在后续所有请求中完整回传，否则 API 返回 400（PRIMARY，Thinking Mode 指南）。任何做会话裁剪或改写的中间层都会踩到它。

六、启示：harness 是运行时，不是产品——以及这一轮的新变化

第一层启示，是本文最想传达的判断：harness 是一个运行时，不是一个产品。 官方给的是运行时底座与插件机制，不给业务语义、不给安全边界、不给合规结论。银行采购的标的其实是"插件 + 边界 + 留痕"，而不是那个 239,580 star 的仓库。

第二层启示，来自一个反直觉的对比。 站内已有文章引用过"上下文管理在 harness 里的价值随窗口增大而衰减"这组数据（arXiv:2609.20804：上下文管理带来的增益在 32k 窗口下是 35.7pp，到 128k 只剩 2.7pp；T0 溢出率从 78.7% 降到 8.7%）。而 DeepSeek 当前两个模型都是 1M 上下文（PRIMARY，官方定价页）。

按那组数据的趋势，1M 窗口会让 compaction／context 这类插件的边际价值大幅下降。 这听起来是利好，但不能直接这么推——原因有两层，都有一手依据：

• 推论本身超出了那组数据的测试范围。 那组实验覆盖的是 32k–128k，没有 1M 的实测点。窗口继续放大后检索质量怎么变，是未测区间。（本文推论，非论文结论）
• 而 DeepSeek 自己的数据指向相反方向：V3.2 技术论文写明，因为只支持 128K，"约 20% 以上的测试用例超出该限制"，不做上下文管理时得分为 51.4（PRIMARY，arXiv:2512.02556）；V4 技术论文给出 1M 上下文下的 MRCR 83.5、CorpusQA 62.0，而对照的 Opus-4.6 是 92.9 与 71.7（PRIMARY，arXiv:2606.19348）。

所以真正的结论是：1M 窗口降低了"装不下"的风险，但没有降低"读不准"的风险。 窗口变大改变的是失败方式，不是失败有无——这恰恰是 harness 不能省的原因：上下文管理从"截断"变成了"定位"。

第三层启示来自一个容易被忽略的细节。 DeepSeek 官方公布的 agent 基准分数，其框架是 DeepSeek Harness 的 minimal 模式，并注明 effort 为 max、top_p=0.95、temperature=1.0（PRIMARY，官方 Change Log 脚注）。

这意味着官方自己承认：那些成绩是"模型 + harness 配置"的联合结果。 这一点对银行极其有用——它意味着厂商的分数不能直接当基线，因为基线里已经含了一个厂商自己调的 harness。你自己的 harness 才是基线的一部分。

七、合规与自部署的现实

许可层面是好消息。 DeepSeek-V4.1-Flash 的模型权重与仓库均为 MIT License（PRIMARY，HuggingFace 模型卡原文："This repository and the model weights are licensed under the MIT License"）。552B 参数 MoE 架构，prefill 激活 8B、decode 激活 16B，另有 196B Engram 参数；上下文 1M，最大输出 384K（PRIMARY，官方新闻与模型卡）。

但 V4-Pro 的许可状态本文不下结论：不同来源存在冲突（HF 仓库存在且有第三方称 MIT，另有来源称 V4-Pro"仅提供 API 商业服务"）。这一项标注为未解决，落地前必须直接查证仓库 license 字段。

自部署不是"有 MIT 就能装"。 官方在 V4.1-Flash 发布公告里写明，若需大规模部署且具备相应资源（2,000 张 GPU 加存储集群）欢迎联系（PRIMARY，官方新闻原文）。这说明 552B 规模的自建是一笔实质的基建投入，不是"下载权重跑起来"。

更关键的是模型标识会漂移。 官方定价页至今仍并列列出 deepseek-flash 与 deepseek-v4-pro 两个模型（PRIMARY），但发布公告写明：自 2026-09-14 04:00 UTC 起，所有 deepseek-v4-pro 请求将被转发到 V4.1-Flash 并按其费率计费，"直至 V4.1-Pro 发布"（PRIMARY，官方新闻原文）。此前 deepseek-v4-flash、deepseek-v4-flash-vision-exp 也已被下线并路由到 V4.1-Flash；更早的 deepseek-chat／deepseek-reasoner 于 2026-07-24 停用。

一个把 deepseek-v4-pro 写进配置文件的银行，会在某天早上醒来发现跑的是另一个模型，而自己什么都没改。 这是本文认为最容易被忽略、也最容易造成评估失效的运维风险——它不在模型卡上，在公告里。

关于 API 数据与训练：开放平台服务协议（2026-04-22 发布、2026-04-29 生效）第 4 条不含训练许可条款，即 API 侧的输入输出不用于模型训练；这与面向网页／App 的用户协议（其中含训练条款与退出机制）不是同一份文件（PRIMARY，协议文本）。银行若用 API，这是有利事实；但必须确认所用的是开放平台服务协议而非用户协议，并把这一条写入供应商尽调报告。

关于备案：DeepSeek 已有生成式 AI 服务备案号 Beijing-DeepseekChat-202404280016 与算法备案号 网信算备110108970550101240011号（PRIMARY，公开备案信息）。但该备案是否覆盖 V4／V4.1 系列模型，本文未能核实——标注为未验证。 金发〔2026〕8号第（五）条要求"外部引入的生成式人工智能模型需经过网信部门备案"，这一条是否因为模型升级而需要重新备案，应向 DeepSeek 或属地网信办直接核实。这是本文认为落地前必须先解决、且不能靠技术手段绕过的问题。

最后一条现实：公开报道中，国有大行已有基于 DeepSeek 的私有化部署落地（PRIMARY 为监管文件，SECONDARY 为媒体报道）。但本文未能找到任何公开的、针对资产保全／不良资产／催收清收／诉讼这一具体场景的 DeepSeek 落地案例——标注为未验证。

这意味着：银行资产保全的同行经验，在公开范围内是空白的。 好处是没有现成的坑要踩，坏处是第一个踩的人没有参照系。

八、适配清单：五步

假设结论是"用它的机制、不用它的边界"，那么要做的是下面五件事。顺序不能换。

第一步：把安全边界从 dsh 里拿出来，另建一层。 不要在 dsh 的沙箱与权限控制上建立控制——官方明说它们不保证隔离。银行需要的是自己控制的执行面：独立的工具网关负责鉴权与调用留痕，dsh 只拿到"调用网关"的权限，不直接接触业务系统与数据。这一层的验收标准是：dsh 整体被攻破时，波及范围止于网关。

第二步：把 55 个官方插件当参考清单，而不是依赖清单。 需要自己写的是业务工具层：押品台账核对、案件节点流转、时效监控、法律文书与调解方案草稿、追索线索归集。每一个都要用 ctx.tools.register(defineTool({...})) 注册，并在 parameters 里做足校验——因为 strict 模式用不上（Beta + schema 子集受限），校验责任完全落在 harness 侧。

第三步：材料摄取自建，并保留原件到结论的可回指链路。 绕开 Files API 只收图片的限制（OCR 或格式转换），并且必须让每一条判定都能回指到原件的页码与位置。否则一旦上游转档出错，你无法把错误归因回"模型判错"还是"材料没读出来"。

第四步：把确定性开关显式化，并写进配置基线。 至少四件事：批处理类任务显式关闭思考模式；走 OpenAI 兼容网关时设 compat.thinkingFormat: deepseek（否则 off 不生效）；给模型 ID 加上"漂移检测"——因为 deepseek-v4-pro 已被公告转发到 V4.1-Flash；以及对 reasoning_content 回传做中间层保护，否则会撞 400。

第五步：在隔离环境里做评测，不要在生产数据上做第一次运行。 官方推荐用一次性的虚拟机或容器、以最小权限运行（PRIMARY，SAFETY.md 的 responsible use 段）。对银行的具体含义是：评测集用脱敏后的历史案件，评测环境与生产网络物理隔离，评测结论留档并接受（十七）项的人工监督与紧急停用要求。

一句提醒：这五步里，第一步和第四步最容易被跳过，因为它们不产生演示效果。而恰恰是这两步，决定了（二十二）项下你能不能主张这个系统是"高风险场景的辅助工具"而不是"自动化决策者"。

九、结论

"银行资产保全能不能直接用 DeepSeek Harness"的答案，分两层。

第一层是采购层的：不能。 不是因为模型能力不够，而是因为官方安全通告自己划了红线——未过安全审计、不得视为生产就绪、沙箱不保证隔离、不要当作唯一安全控制。资产保全落在金发〔2026〕8号第（十六）条的高风险应用里，押品、诉讼材料与当事人身份信息正是第（二十四）条划定的不可用于训练优化的那类数据。一个高风险应用不能建在这样的运行时之上，这不是保守，是合规底线。

第二层是工程层的：可以借。 它的插件机制干净（apply(ctx) + ctx.tools.register）、协议适配务实（三种协议可选、自建网关可接、compat 开关覆盖了企业网关最常见的不兼容）、MIT 许可与 Anthropic 格式端点让私有化与多模型切换都留了门。它值得借鉴的是"everything-is-a-plugin"这个架构判断——把可替换的与不可替换的分开，这是对的。

但真正决定成败的不是架构判断。 资产保全的护城河从来不是 agent 有多聪明，而是：它做的每一个动作，能不能被回溯到一个人、一个依据、一个时间点。 DeepSeek Harness 提供的是让 agent 动起来的能力，不提供让动过之后还能说清的能力。

落到一句可执行的话：把 DeepSeek Harness 当作一个可以被替换的插件框架引入，把安全边界、留痕与回退这三件事全部自建——并且在合同与备案上确认它能进这道门。技术可行性从来不是这件事的瓶颈。

作者毕超，金融行业风险管理从业者。本文仅代表作者个人观点，不构成任何机构立场。

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