---
title: "资产保全超级智能体怎么搭"
date: 2026-11-01
description: "DeepSeek 的 dsh-superagent-prototype 是事件驱动、低打扰的智能体：Source 产事件，Router 签发带范围和制度版本的 Mandate，每工单独立执行。本文映射资产保全：法院查控、查封到期、质押物跌价、债务人工商变更作事件源，续封、补保全、线索核查、法拍跟进作工单，明确哪些智能体可做、哪些必须人决，给出 observe 到 auto 的三阶段路径与审计要点。"
tags: ["资产保全","智能体架构","DeepSeek","事件驱动","银行风控","多智能体","合规边界"]
schema_type: Article
references:
  - title: "deepseek-ai/dsh-superagent-prototype（GitHub，MIT）"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype"
    source: "DeepSeek Harness 团队"
  - title: "dsh-superagent 文档 000 Philosophy"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/000-philosophy.md"
    source: "GitHub"
  - title: "dsh-superagent 文档 001 Domain model"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md"
    source: "GitHub"
  - title: "dsh-superagent 文档 002 Authorization"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md"
    source: "GitHub"
  - title: "dsh-superagent 文档 003 Execution"
    url: "https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/003-execution.md"
    source: "GitHub"
---

# 资产保全超级智能体怎么搭

**DeepSeek 开源的 dsh-superagent-prototype 不是又一个聊天 Agent，而是一套"事件驱动、最少占用注意力"的智能体运行架构。**

**它的核心主张是：一个能替整个团队干活的 Agent，也能浪费整个团队的注意力，所以它只在被要求或规则允许时行动，只在人必须决策或能用结果时才说话。**

**把这套架构逐项映射到银行资产保全，会得到一张清晰的构建蓝图：法院查控、查封到期、质押物跌价、债务人工商变更都是事件，续封、补保全、线索核查、法拍跟进都是带授权范围的工单。**

**关键不是让 Agent 自己去扣款或签收法律文书，而是把"人必须决策"的动作和"机器该抢先做"的动作用 Mandate 边界切干净。**

**落地节奏应当是 observe（只记录它本会怎么做）→ 人工核对草稿 → 高置信场景 auto，而不是一上来就让 Agent 自动跑全流程。**

## 一、为什么资产保全需要"超级智能体"而不是单会话 Agent

1. **多案件并行是常态**：一家省级分行法金/保全条线手上可能同时挂着几百到上千个在诉、在执、在保案件。单会话 Agent 一次只跟一个任务，做完一个再做下一个，无法支撑这种并发规模。
2. **事件来自多个系统**：保全不是客户来一句话才动，而是法院查控专线反馈、行内催收工单、质押物行情、债务人工商变更、12368 送达通知在持续产生信号，Agent 必须"听环境"而不是"等指令"。
3. **长程任务跨周跨月**：续封要提前 30 天预警、法拍从评估到成交可能跨季度，要求工单有自己的状态和上下文，而不是每次对话从零开始。
4. **人的注意力是瓶颈**：保全经理真正稀缺的是判断力——要不要启动诉讼、同不同意减免、接不接受以物抵债、提不提执行异议。大量机械性的监控、材料整理、期限提醒、文书初稿不该占用他们。
5. **dsh-superagent 的架构正好对症**：它把"连续听事件"的 Router 和"并发跑任务"的 Worker 分开，把"该不该开工"的研判和"能干到哪一步"的授权分开，把"健康状态不打扰人"作为第一原则。

## 二、架构逐项映射：从 Source 到 Channel

1. **Source（事件源）→ 保全事件总线**：法院执行查控专线反馈、查封冻结到期日历、质押物行情价格源、债务人新增被执行/股权出质/终本案件、12368 司法送达、行内催收系统工单、企业微信/邮件来函、抵押物被另案查封的网络舆情。每个 Source 有自己的 bot 身份和读位点，重启不重复消费。
2. **Trigger（不可变事件）→ 一条带时间戳的信号**："某笔贷款抵押物查封将在 30 日后到期""某质押股票收盘跌破警戒线 8%""某债务人新增一条终本案件""法院反馈查控到其在他行存款 47 万元"。Trigger 是审计和幂等的最小单位，重复到达不重复开工单。
3. **Thread（线程）→ 一个案件/一个债务人的时间序事件流**：同一债务人的工商变更、查控反馈、保全动作、来函都归到同一个 Thread，给研判提供连续上下文。
4. **Eval（双层研判）→ Router 决定要不要开工单**：第一层 Gate 看是谁、哪个系统、按什么强度发起；第二层 Assessment 模型研判匹配哪条规则（续封、补保全、财产线索核查、处置启动、信用风险触发）。输出 accept / stop / ignore / unavailable。
5. **Mandate（授权）→ 工单的"范围+强度+制度版本"**：明确这个工单能干到哪一步——比如"只能起草续封申请书并准备材料，不能向法院提交""只能查控线索并出报告，不能联系债务人""只能发补仓预警，不能冻结或处置"。Mandate 同时记录依据的本行保全制度版本，制度改了，在途工单会收到通知。
6. **Ticket（工单）→ 一个保全动作**：续封申请、质押物补仓通知、财产线索核查、法拍进展跟进、破产债权申报材料准备。每个 Ticket 有自己的目录，相当于一案一档。
7. **Executor（Worker）→ 每个工单一个独立工作会话**：在自己的目录里调查控接口、估值接口、法条检索库、文书模板，并发跑多个案件；后台任务超时上限、中断恢复、结构化报告就绪/受阻/失败/无需处理。
8. **Subscription（订阅扇出）→ 一个在办案件自动订阅该债务人的所有后续事件**：后续新增被执行、股权冻结、抵押物另案查封，无需人再提，自动作为上下文扇到这个工单。
9. **Channel（回信）→ 回写动作**：企业微信推给客户经理、法金系统立案、邮件给外部律所、行内工单系统派单。Agent 不直接对外发法律文书，必须人审。
10. **Panel（待办面板）→ 只列"等人决策"的事**：健康的、正在自动跑的工单不占空间；面板第一屏就是" Awaiting answer / Awaiting review / Blocked"。

## 三、保全场景的五类事件与对应规则

1. **期限类事件**：查封/冻结/续封到期前 30 天、诉讼时效届满前 90 天、执行申请期限临近、法拍公告期截止。规则：自动起草续封/执行申请材料并推给保全经理，人审后提交。
2. **价值类事件**：质押股票/债券/大宗商品跌破警戒线或平仓线、抵押物估值下调、保证人净资产恶化。规则：自动生成补仓通知草稿并测算缺口，交客户经理联系保证人；触及平仓线升级为人工决策。
3. **线索类事件**：债务人新增被执行、新增股权出质、不动产登记变更、新增对外投资、银行账户查控反馈。规则：自动归集财产线索清单并关联到对应贷款，生成核查工单；发现可供执行财产时建议启动处置。
4. **司法类事件**：12368 送达、开庭通知、执行异议裁定、另案查封、破产申请被受理。规则：自动提取关键期限和应对事项，提示是否在法定期限内提异议/申报债权；法律判断必须人。
5. **行为类事件**：债务人失联修复、还款承诺未兑现、保证人代偿意愿变化、舆情负面。规则：记录并升级到催收工单，不自动对外承诺。

## 四、最关键的设计：Mandate 边界切在哪里

1. **Agent 可以自动做（observe 成熟后 auto）**：事件归集、期限提醒、材料初稿、法条检索、财产线索清单、估值测算、对账单据整理、内部工单派单、案件台账更新。
2. **Agent 必须停在人面前**：向法院/仲裁机构提交任何法律文书、签收司法文书、对外联系债务人或保证人做出任何承诺、扣款或处置担保物、同意减免/展期/以物抵债/债转股、提起或撤回执行异议、申报破产债权的最终口径。
3. **为什么这样切**：dsh-superagent 文档明确要求"按影响停止，而不是按努力停止"——一个本地改动做到可审阅结果就停，需要设计决策就停在一个明确问题上。在银行语境，"影响"就是法律效果和资金处分：一旦对外产生法律效力或动用客户资金，必须人。
4. **强度分级**：explicit（保全经理明确指令）直接开工单；inferred（系统规则触发）默认先 observe，记录"我本会怎么做"，人核对一批后再转 auto；bot/系统消息不能发起 explicit 工单，只能发起候选。
5. **制度版本绑定**：Mandate 记录依据的是哪一版保全制度。制度修订后，在途工单收到 policy-changed 通知，而不是旧授权继续跑到底。

## 五、三阶段落地路径

1. **第一阶段 observe（只记录不执行）**：Router 监听所有事件，对每个候选工单生成"我本会做什么、依据哪条规则、准备什么材料"的记录，但不派单、不回写。人每周抽看记录准确率，重点看误报率和漏报率。这一阶段 dsh-superagent 的默认模式就是 observe，不要急着开 auto。
2. **第二阶段 auto-draft（自动起草+人工审批）**：高置信期限类事件（如续封到期）自动生成材料包推到人面前，人一键审核提交；线索类和价值类自动出报告，人决定下一步。这一阶段 Panel 只推"等人审"的工单，正在跑的不打扰。
3. **第三阶段 auto（高置信场景自动闭环）**：仅限纯内部、无对外法律效果、无资金处分的动作——台账更新、内部派单、期限提醒、材料归档。任何对外动作和资金处分永远不进入 auto。
4. **演进判据**：误报率、人返工率、平均响应时长、在办案件积压量。当 observe 记录被人采纳率稳定在高位、且连续没有出现一次越界动作，再放开下一档；出现一次越界就回退。

## 六、与行内系统的集成和审计要点

1. **一案一档天然对应**：每个 Ticket 一个独立目录，案件材料、往来文书、查控记录、决策历史全部落在该目录，审计可逐案追溯——这正好满足监管对智能体操作"可解释、可回放、可审计"的要求。
2. **不碰核心账务**：Executor 通过受管控的接口读查控、估值、工商数据，写回只到法金/催收工单系统，不直接连核心系统做资金动作。文档里那句"wrapper 和目录建立默认值，不是安全边界"要牢记——绝对路径仍能绕过，网络和权限边界必须在系统侧而不是提示词侧。
3. **数据主权**：债务人、抵押物、查控数据都是行内敏感数据，事件总线和 Worker 必须部署在行内环境，不能把案卷内容发到外部模型 API；这与站点此前讨论的本地部署和数据主权一脉相承。
4. **人留痕**：每一次人审、人停、人改都记录在 Ticket 上；Agent 的报告分 progress / waiting / ready / blocked / failed / dropped，不允许它用自由文本说"我在等人"，必须用结构化字段，面板才能准确分类。
5. **Watchdog 盯进展不盯存活**：续封草稿三天没动、法拍一个月无进展、线索核查超时，Watchdog 主动升级，而不是等系统挂了才报警。

## 七、三个冷静判断

1. **这套架构不替银行写法律判断**：它解决的是"并发听事件、并发跑材料、把人的注意力只留给决策"，诉讼时效怎么抗辩、执行异议成不成立、破产债权怎么申报，仍要靠法金专业判断。
2. **不要从第一天就接所有 Source**：先接一个最痛的事件（建议从查封/冻结到期预警开始，误报少、价值直观、无对外动作风险），跑稳再加质押物行情和工商变更，最后接司法专线。
3. **dsh-superagent 是研究原型不是产品**：仓库自己声明"仅供参考、可能有 bug、不是 DeepSeek 官方产品、与内部版本不完全一致"。银行要借的是它的领域模型和授权哲学，不是直接上生产；真正的安全边界要在接口、权限、网络层重做。

## 结语

资产保全的痛，从来不是缺一个会写文书的大模型，而是几百个案件同时在跑、事件散在七八个系统、保全经理被期限和材料追着跑。dsh-superagent 给出的答案——用 Source 听事件、用 Mandate 切授权、用 Ticket 一案一档、用 Panel 只等人——恰好是把保全从"人盯屏幕"变成"系统盯屏幕、人做判断"的那套运行时。照这张蓝图搭，第一步不是买最贵的模型，而是先把自己的保全事件列清楚，再决定哪些能 observe、哪些必须永远停在人面前。

（口径说明：本文架构概念、哲学、授权模式、执行规则来自 DeepSeek dsh-superagent-prototype 仓库及其 000/001/002/003 文档，仓库声明其为研究原型、非官方产品。文中银行资产保全场景映射、规则设计、三阶段路径与 Mandate 边界为作者结合业务的分析，不构成具体技术方案或合规意见；实际落地需结合本行系统、司法管辖和监管要求设计。）