跳转至

Agent Plan x DeepSeek Harness 实践指南

📊 Level ⭐⭐⭐ | 13.1KB

最新的DeepSeek 智能体应用框架（DeepSeek Harness，简称DSH），Model、Tool、Memory、Sandbox 和 Agent 都是可组合、可替换、可扩展的插件 。Harness 本身退到最薄——它只做三件事：调度模型与工具、在高危操作前请你审批、维护一份任务计划。

→ 原文存档

摘要

本文由火山方舟团队发布，介绍新一代 DeepSeek 智能体应用框架 DeepSeek Harness（DSH） 如何与 方舟 Agent Plan 配合，拼出一套"量大管饱"的智能体。核心思想很鲜明：DSH 把自己压缩成一套薄而开放的插槽（Model/Tool/Memory/Sandbox/Agent），Agent Plan 则往插槽里填满经过验证的插件——从全模态模型、豆包搜索、专业数据集，到基于 OpenViking Context 的记忆、Agent 进化、AI Native 开发底座。

文章用一个独立开发者"小曾"为三只车企持仓搭建每日投资研究助理的完整案例收尾：从一句自然语言任务出发，由 agent 自主查专业数据、检索实时新闻、生成研究简报、把结果沉淀为可持续更新的页面，最后跨会话记住研究偏好并学会他的分析方法。整篇既是 DSH 架构的官方宣介，也是一条"给 agent 装插件"的最小可行路径。

核心要点

  • Harness 最薄化原则：DSH 的 Model、Tool、Memory、Sandbox、Agent 都只是可组合、可替换、可扩展的插件，框架自身只做三件事——调度模型与工具、高危操作前请用户审批、维护任务计划。
  • 启动极轻：一条命令 npx @deepseek-ai/dsh web 即跑起本地 Web 界面（默认 http://127.0.0.1:3080/），把 agent 的底座入场成本压到几近为零。
  • Agent Plan = 模型 + harness 组件打包：按 Agent = Model + harness 的思路，把"能干活、能记事、能成长、能出产品"所需的能力一次订阅，AFP 额度统一抵扣，预算管理更省心。
  • "DSH 提供插槽，Agent Plan 提供插件"：组件并非随意堆砌，而是方舟沉淀的产品能力加上广大开发者反复验证过的 Harness 优选组合——搜索用哪个、数据信哪个、记忆怎么接、进化怎么做，都已挑过一遍。
  • 五大 Harness 组件各司其职：豆包搜索让 agent 能上网、专业数据集给 agent 硬核结构化数据、Agent 记忆跨会话记住用户、Agent 进化让 agent 越用越聪明、AI Native 开发底座让 agent 直接把手头任务做成真实产品。
  • 实战闭环完整可复现：从自然语言任务到"查数据→搜新闻→出简报→沉淀页面→记忆习惯→学会方法"，一整套投资研究助手的生长过程全被记录。

深度分析

DeepSeek Harness 插件化架构：Model / Tool / Memory / Sandbox / Agent

DSH 最值得注意的设计是把智能体的五类能力全部插件化。模型负责推理生成、工具负责检索执行、记忆负责跨会话沉淀、沙箱负责隔离安全执行、Agent 本体负责编排决策——每一类都定义成"可替换的插槽"，而不是写死在框架里的点。这让 DSH 与把一切逻辑揉进单一循环的早期 agent 框架形成鲜明对照：换模型、换检索源、换记忆后端，都不需要改框架本身。

用户插入模型的方式印证了这种开放：在 DSH 的"设置 → 模型"里添加自定义提供方，用专属 API Key 接入。框架把"能力边界"让渡给插件，把自己收敛为纯粹的执行调度层——这与 Agent Harness 架构 讨论的"harness 作薄工作台、能力靠外部注入"同源。

harness 退到最薄：只做调度、审批与计划

DSH 反复强调"退到最薄"——留给自己的职责只有三条：调度模型与工具、在高危操作前请你审批、维护一份任务计划。这恰好对应一个长期运行的 agent 最容易失控的三个环节：该用哪个模型/工具、会不会做危险动作、任务到底做完没做完。把这三件事收进 harness，等于把"护栏"而不是"能力"交给框架，能力全部外置为插件。

这种设计有直接的工程收益：瘦 harness 意味着低耦合、高可替换——更新模型不动框架，换记忆后端也不影响调度逻辑，插件生态独立演进。它呼应了 Thin Harness, Fat Skills 的哲学，即框架轻、技能/插件重，是近一年 agent 工程圈逐渐收敛的共识。

方舟 Agent Plan：把优选插件递到开发者手里

模型与框架本身只是"插槽与大脑"，真正让开发者少走弯路的是 Agent Plan 的插件工具箱。它把搜索、数据、记忆、进化、开发底座五个高频需求分别标准化成可直接接入 DSH 的组件：豆包搜索带权威来源过滤、时间范围筛选与 Query 自动改写；专业数据集按 query 自动路由到财报、工商、司法、论文、车型、宏观等垂类库；Agent 记忆把记忆/资源/技能统一抽象成"虚拟文件系统 + 语义检索"，分层装载、按需召回、会话后自动沉淀；Agent 进化从近期会话识别可优化的指令文件并生成带 diff、证据与置信度的建议；AI Native 开发底座则基于火山引擎 Supabase 提供 Serverless PostgreSQL、认证、对象存储与"推送即发布"的前端部署。

最关键的是它们免去了在海量插件里试错的成本：搜索该用哪个、数据该信哪个、记忆怎么接、进化怎么做，都已被方舟和广大开发者在真实项目里挑过一遍——装上就是一套"能打的组合"。这种"平台出组件 + 框架出插槽"的分工，正是 Agent Harness 工程综述 强调的"harness 平台化、能力组件化"生产形态。

Agent Plan 的落地实践：从自然语言到投资研究助手

案例的含金量在于它是一个可长期使用的成长型 agent：先接入 Seed-Evolving 模型（官方称在搜索幻觉、工具调用幻觉、状态幻觉上显著降低、抗误导能力提升）；再分五步走——专业数据集查结构化财务、豆包搜索补实时事件背景、AI Native 开发底座把研究沉淀为可持续更新的页面、OpenViking Context 记忆让新会话记住研究偏好、Agent 进化在多次修正后把工作习惯转成长期规则。每一步都对应一个真实痛点。

最大启示是"让偏好与产出成为 agent 的长期资产"：不是每天重新问一遍，而是把研究结果、用户偏好、分析习惯都变成可复用、可追加、可进化的结构化状态。结合 Agent 记忆模块化框架 看，OpenViking Context 正是用"统一抽象成文件 + 分层召回"把记忆从聊天历史升华成 context 数据库。

实践启示

  1. 先用薄 harness 起步，别急着自研框架：「插槽薄 + 插件量大管饱」意味着一条 npx 命令就能起步，把工程投入花在插件选型与编排，而非框架本身。
  2. 按"能干、能记事、能成长、能出产品"四件事逐个补齐能力：接模型保证能干，接搜索和数据保证准确，接记忆保证记事，接进化保证成长，接开发底座保证最终出产品——缺哪块补哪块。
  3. 让记忆成为上下文数据库而不只是聊天记录：OpenViking Context 把记忆/资源/技能统一抽象成文件并分层召回，新会话自动召回、结束后增量捕获——这正是跨会话"它还认得你"的关键。
  4. 把长期任务导向"可沉淀的资产"，而非一次性答案：多次强调"先把研究结果真正留下来"、"做成可持续更新的页面"——agent 的长期价值来自把每次产出落成可追加的结构化状态。
  5. 利用"进化"机制把人工修正固化为规则：跑几次真实任务后让 agent 执行 "Learn from my recent sessions"，它会把你反复纠正的内容生成带 diff、证据、风险值与置信度的优化建议，确认后才写入长期指令。
  6. 信任但审批：务实的高危操作审批让 agent 与用户保持"越权前请示"的安全边界，适合从实验走向日常生产。

会话实现：事件是事实，消息是派生物（术哥源码级拆解，SUPP 2026-09-09）

DSH 的 session 不把会话实现成 messages[] 数组，而是一份只追加的、类型化的 SessionEvent 日志：deriveMessages() 负责把日志投影成模型历史——日志是唯一真源，LLM 消息历史是派生物。

  • append 顺序与两层结构：Session.append() 先分配连续序号（seq = log.length），JSON 快照 + surface 元数据校验后 log.push，再发布 session/event。原始日志层（turn/step/流分片/工具调用）不直接投影为 transcript message，但 tool/result 是例外（SurfaceEventType，直接投影为 tool message）；surface 层通过 surfaceOp/sourceEventSeqs 标记位置与派生关系。
  • 同步提交 + 异步持久化：内存日志提交同步（post-commit 观察通知，失败不撤销），JSONL 持久化插件订阅 session/event 进 writer buffer，session/flush 才 drain；轮次边界 checkpoint 负责观察耐久性失败——"内存事实先提交；持久化是可替换插件；检查点负责耐久性"。
  • fork/恢复/压缩都是追加而非改写：fork 取连续事件 seed（不含未闭合 turn），inheritedEventCount 划边界；恢复从 JSONL 重放事件、补齐中断轮次；压缩追加 compaction 事件（开始/摘要/剪枝/结束），旧节点变 shadowed 而非删除，SessionEventTrace 用 replacedBy/replacedEventSeqs/sourceEventSeqs/derivedEventSeqs 记录变换关系，replaceGeneration 作压缩成功进展证明。
  • 查询与血缘：session-query-sqlite 用 FTS5 且默认关闭，索引文本有筛选（reasoning block/被阻止提示词不入索引）；traceEvent 区分四类关系（被谁替换/替换了谁/引用谁/被谁当来源）；projection/stats/telemetry/title 都订阅同一 session/event 流做旁路折叠，不另造状态机。

这个维度回答了一个核心架构问题：当模型看到的状态、磁盘保存的状态、UI 展示的状态发生分歧时，谁拥有最终解释权——DSH 的答案是事件日志，其他一切都从它重新算。

相关实体

关联