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

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

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

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

DeepSeek Harness 系列

1. 首周观察：热度、版本与生产风险
2. Cordis 与插件运行时
3. 数字分身 Runtime 与长期记忆分层
4. 30 天学习路线
5. AI Agent 五层工程课
6. DeepSeek Harness vs LangGraph

数字分身架构：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
    }

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

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 风险。

站内延伸阅读

• DeepSeek Harness 的 AgentOS 定位
• Everything is a Plugin 架构观察
• DeepSeek Harness 插件生态首轮增长
• DeepSeek Harness 的 Node.js 与 TypeScript 集成
• DeepSeek Harness 本地部署指南
• 主流 AI Agent 框架选型
• Agent 工具调用评测框架
• LangGraph 控制流、持久化与部署
• 从零复刻 Agent Harness
• AI Agent 企业级开发与 MCP
• 多智能体框架的工程边界
• AI Agent 工程师技能升级路线

一手资料

• DeepSeek Harness 官方项目
• 官方 Architecture
• 官方 Releases
• Cordis 论文仓库

结语

判断一个 Agent Runtime，关键不是演示能跑多少工具，而是状态、权限、恢复和升级是否可控。把这些问题逐项验证，才能决定 DeepSeek Harness 应该进入实验、试点还是生产。