DeepSeek Harness 做数字分身: Runtime 与长期记忆分层

把 DeepSeek Harness 用于数字分身，真正困难的不是把人格提示词塞进系统消息，而是决定哪些状态属于人、哪些状态只属于一次 Agent 执行。这个边界一旦画错，后续每次框架升级都会牵动身份、记忆和授权数据。本文给出一套可替换 Runtime 的分层方案。

本篇属于 DeepSeek Harness 系列。系列不重复追逐插件快讯，而是从成熟度、运行时、记忆、安全和评测五个层面判断它能否成为长期基础设施。

撰写说明：本文使用 DeepSeek Harness 辅助撰写，并由人工编辑校对。

DeepSeek Harness 系列

数字分身架构：DSH 应该放在哪里

我推荐你不要采用：

DeepSeek Harness
     ├── 人格
     ├── 全部记忆
     ├── 所有账号
     ├── 所有个人数据
     ├── Agent
     └── 产品

因为这样把数字分身真正不可替换的资产绑定到了一个刚进入 Developer Preview 的 runtime。

推荐的是：

Twin Core 独立，Harness 可替换。

推荐架构图

flowchart LR
    U["用户 / Web / App / Voice / IM"] --> G["Identity Gateway<br/>Auth · Consent · Session"]

    G --> R["Twin Runtime Adapter"]

    subgraph DSH["DeepSeek Harness · Execution Plane"]
        P["Persona / Context Plugin"]
        A["Agent Loop"]
        W["Workflow / Scheduler"]
        SA["Subagents"]
        T["Tool / MCP Registry"]
        AP["Approval / Policy"]
        SB["Sandbox"]
        TR["Append-only Trajectory"]
    end

    R --> P
    P --> A
    A --> W
    W --> SA
    A --> T
    T --> AP
    AP --> SB
    A --> TR

    subgraph MEM["Digital Twin Data Plane · Canonical"]
        ID["Identity / Profile<br/>Postgres"]
        EM["Episodic Memory"]
        SM["Semantic / Preference Memory"]
        V["Vector Index"]
        O["Objects / Attachments"]
        POL["Consent / Permission / Provenance"]
    end

    ID --> P
    EM --> P
    SM --> P
    V --> P
    POL --> P

    subgraph CON["Connector Plane"]
        MAIL["Email"]
        CAL["Calendar"]
        DOC["Docs / Notes"]
        MSG["Messages"]
        WEB["Browser / Web"]
        DEV["Devices / Other Sources"]
    end

    T <--> CON
    CON --> MEM

    A --> M["Model Gateway"]
    M --> DS["DeepSeek"]
    M --> OM["Other Models"]

    TR --> OBS["Evaluation / Observability"]

这里最重要的是那个 Twin Runtime Adapter。

你的业务代码调用：

TwinRuntime.run()
TwinRuntime.resume()
TwinRuntime.cancel()
TwinRuntime.getTrajectory()
TwinRuntime.callTool()

而不是到处直接调用：

DeepSeekHarness.*

这样将来可以：

DeepSeek Harness
      ↓
LangGraph
      ↓
Microsoft Agent Framework
      ↓
another runtime

而人的记忆、人格、数据、permissions 不需要迁移。

这是我认为你现在最值得做的架构决定。

数字分身的数据流

flowchart TD
    S["Email / Calendar / Notes / Chat / Browser / Files"] --> I["Ingestion"]

    I --> V["Validate Source + Provenance"]
    V --> D["PII / Consent / Access Policy"]
    D --> N["Normalize into Personal Events"]

    N --> X["Memory Extraction"]
    X --> E["Episodic Events"]
    X --> F["Semantic Facts"]
    X --> P["Preferences / Relationships"]
    X --> VI["Vector / Search Index"]

    Q["User Request"] --> RET["Context Retrieval"]
    E --> RET
    F --> RET
    P --> RET
    VI --> RET

    RET --> H["DeepSeek Harness"]
    H --> LLM["LLM"]
    LLM --> PLAN["Plan / Tool Proposal"]

    PLAN --> AUTH{"Permission + Risk Gate"}

    AUTH -->|"deny"| DENY["Reject / Ask User"]
    AUTH -->|"approve"| TOOL["MCP / Tool / Connector"]

    TOOL --> REAL["External World"]
    REAL --> RESULT["Result"]

    RESULT --> H
    H --> LOG["Append-only Agent Trajectory"]

    RESULT --> REF["Reflection / Memory Candidate"]
    REF --> CHECK["Validate + Deduplicate + Confidence"]
    CHECK --> E
    CHECK --> F
    CHECK --> P

注意这里我特意放了两个完全不同的 log：

DSH Trajectory
= Agent 做过什么

Twin Memory
= 关于“我”的什么信息应该长期保留

不要把二者混在一起。

推荐的数字分身核心数据模型

erDiagram
    PERSON ||--|| IDENTITY_PROFILE : owns
    PERSON ||--o{ CONNECTOR_ACCOUNT : authorizes
    PERSON ||--o{ MEMORY_EVENT : experiences
    PERSON ||--o{ MEMORY_FACT : has
    PERSON ||--o{ CONSENT_POLICY : defines
    PERSON ||--o{ AGENT_SESSION : starts

    CONNECTOR_ACCOUNT ||--o{ SOURCE_ITEM : provides
    SOURCE_ITEM ||--o{ MEMORY_EVENT : produces
    MEMORY_EVENT ||--o{ MEMORY_FACT : derives

    AGENT_SESSION ||--o{ TOOL_ACTION : contains
    CONSENT_POLICY ||--o{ TOOL_ACTION : governs
    CONNECTOR_ACCOUNT ||--o{ TOOL_ACTION : executes

    PERSON {
        uuid person_id
    }

    IDENTITY_PROFILE {
        uuid profile_id
        int version
        json persona
        datetime effective_from
    }

    MEMORY_EVENT {
        uuid event_id
        datetime event_time
        string source
        float confidence
        string provenance
    }

    MEMORY_FACT {
        uuid fact_id
        string predicate
        string value
        float confidence
        datetime valid_from
        datetime valid_to
    }

    CONSENT_POLICY {
        uuid policy_id
        string scope
        string action
        string decision
    }

    TOOL_ACTION {
        uuid action_id
        string tool
        string risk_level
        string approval
        datetime executed_at
    }

三种迁移模式，我推荐按这个顺序考虑：

模式	做法	推荐度
Adapter / Strangler	保留你现有数字分身 memory/backend，只把 agent execution 换成 DSH	★★★★★
DSH Worker	产品 backend 把任务投给隔离的 headless DSH worker；worker 无 canonical state 所有权	★★★★★ 生产路线
Plugin-native Twin	persona、memory、connector 全做 DSH plugin	★★★★ 原型 / 研究
All-in DSH	identity、memory、storage、runtime 全绑 DSH	★☆☆☆☆

DSH headless profile 官方本来就是无 server 的 one-shot runner，这使第二种“任务 worker”模式尤其自然；你可以在它外面加自己的 API、queue、tenant isolation 和 process/container boundary。

我的建议是：

现在：
Existing Twin Backend
        ↓
TwinRuntimeAdapter
        ↓
DSH Headless / Web

未来成熟后：
TwinRuntimeAdapter
        ↓
DSH Cluster / LangGraph / MAF / ...

这样你可以享受 DSH 的创新速度，却不用承受它全部的 breaking-change 风险。