App Plugin for DeepSeek Harness：一种同时面向人和 Agent 的插件形态

[jo32]

聊天擅长表达意图，Tool 擅长让 Agent 调用能力。但很多真实任务还有另一半：人得持续地看、听、比较、选择、纠正和直接动手。

音乐编排就是个很直接的例子。你可以说“把它改成 35 秒左右的游戏配乐，加钢琴，最后一段再推一点”，但要判断结果到底成不成立，人还是需要：

• 看到整首歌的结构和每一段的长度；
• 点开 16 步 pattern 调节奏；
• 在时间线上定位 Intro、Verse、Break 和 Finale；
• 播放、暂停、跳转，直接听差别；
• Agent 改完之后，继续自己微调或者撤销。

把这些全塞进聊天，领域界面的信息密度就没了；让 Agent 直接操作 DOM，业务语义又会退化成一堆脆弱的按钮和坐标。

所以我更愿意把一个 App 插件理解成三件套：

1. Human surface：给人用的领域界面，比如音序器、阅读器、证据时间线；
2. Agent contract：固定的 action、结构化的 Tool、明确的输入输出 Schema；
3. State / effect boundary：经过验证的领域对象、revision、artifact，以及可关联、可拒绝、可撤销的 effect。

人和 Agent 不需要抢同一套 UI，也不需要各自维护一个互不相干的产品。两者围绕同一个被验证过的工作对象协作。

先声明：App Plugin 不是 Harness 现有功能

它不是 DeepSeek Harness 现有的官方功能，也不是官方术语。它是我在做 DeepDeck 的过程中，用 Harness 已有的 Cordis Host / Client 插件机制搭出来的一套新约定，带点运行时实验的味道。

Harness 本身已经备齐了模型连接、Workspace、Session、Tool、Cordis loader，以及 service / slot 这些扩展能力。但它还没定义过“App”这一层抽象——一个插件该怎么拥有稳定的应用身份、启动入口和独立窗口，怎么拿到自己的 Workspace 和一组固定的 Agent actions，以及 Agent 跑出来的结果怎么安全地回到一个正在运行的 App 里。

我说的 App Plugin，说到底仍然是一个普通的 Cordis 插件包。没有新的包格式，也没动 Harness 上游任何一行源码，只是在普通插件之上多约定了一层能力：

• 稳定的 App identity、名称和源码来源；
• Apps launcher、独立窗口和独立设置入口；
• App-scoped Workspace 与标准 Harness Session；
• 由 App 校验和派发的固定 Agent actions；
• 从 Session 返回 App 的受控 effect、artifact 和任务状态；
• 可选的 Creator Workspace、本地构建与 Cordis 热更新生命周期。

放到整个栈上看，三层的分工大致是这样：

层	主要职责
DeepSeek Harness / Cordis	模型、Workspace、Session、Tool、插件装配，以及 service / slot 等扩展点
DeepDeck App runtime	App 注册与启动、独立窗口、App-scoped Session/action bridge、effect 关联和桌面生命周期
App Plugin	领域 UI、状态 Schema、固定 actions、validator、artifact 与具体工作流

所以这篇帖子不是在介绍 Harness 已有的某个功能，而是想拿一个已经跑起来的第三方原型，聊聊其中哪些抽象也许值得变成 Harness / Cordis 的通用扩展点。

为什么要做这种插件形态

最近我一直在 DeepDeck 上做 App Plugin。最新的一个实验是 Strudel Studio：基于 Strudel 的歌曲级可视化音序器，可以用时间线、分段和 16 步音序编辑一首短曲，也能把当前项目交给 Harness 里的主 Agent 做结构化编曲。

之前我在 #3328 介绍过 DeepDeck，也更新过第一版 Apps runtime。这次不想再写一篇产品展示，而是想单独把这几次实现背后的动机拿出来讨论。

做到 Strudel Studio 之后，我对自己为什么要设计这套插件形态，终于有了更清楚的答案：

插件不该只负责给 Agent 增加几个后台工具；它也可以把领域 UI、结构化状态、受控动作和标准 Agent Session 组合成一个同时面向人和 Agent 的 App。

于是问题就变成了：Harness / Cordis 生态里，值不值得沉淀出一套最小的 App contract？

Strudel Studio：共享状态的可逆编辑

Strudel Studio：人在时间线和 16 步音序器中听、看、直接编辑；Agent 通过受约束的 action 修改同一个歌曲项目。

Strudel Studio 的权威状态既不是聊天文本，也不是任意一段 Strudel / JavaScript，而是一个有严格 Schema 的歌曲项目：BPM、调式、分段、轨道，以及每个“轨道 × 分段”对应的 16 步 pattern。

App 可以把当前项目和用户意图派发到自己的标准 Harness Workspace / Session。Agent 要改歌，必须返回一个完整、可验证的 schemaVersion: 2 项目，而且只能调用一次封闭的 strudel_apply_project action tool。

这个 effect 只有在 App client、request、sequence 和 base revision 都对得上当前草稿时才会被接受。如果用户已经继续编辑过，迟到的 Agent 结果会因为 revision 过期被拒掉，而不是覆盖掉新内容。

内置播放器同理，它不会执行任意 Strudel 或 JavaScript。CODE 视图只生成和解析带 @song、@section、@track、@pattern、@swing 标记的安全子集；未知、重复或者不完整的结构会被拒掉，并且要走和本地编辑、Agent effect 同一套 validator 才能回到项目模型。

这里的关键不是“给音序器加了个聊天框”，而是让自然语言意图进入一次受控的领域状态转换，再把结果交还给人能看懂、能验证的界面。

另外两个实验：信息探索与长任务证据

Hacker News Reader 让人用普通阅读器浏览信息流、搜索和展开讨论树；App 同时向 Agent 暴露 feeds、stories、search、users 和当前 UI context 的只读工具。选中文字后触发 Summarize / Explain，任务会进入 Reader 自己的标准 Harness Workspace / Session，而不是另一套聊天系统。

Hacker News Reader：人浏览信息流和讨论树，Agent 通过只读工具读取当前上下文并执行 Summarize / Explain。

Video Sherlock 把视频分析做成长任务：Agent 负责获取视频、转录、抽帧、视觉核验和生成审计报告；App 把任务状态、播放位置、证据高亮、关键帧和 limitations 作为持续对象呈现。任务需要人介入时，用户可以直接在 App 里回答，也可以进入同一个 Session 观察工具活动和继续处理。

Video Sherlock：长任务的结果回到证据控制台，视频、时间线、关键帧和报告保持同步。

这三个例子对应的是三种不同问题：信息探索、长任务与证据、共享状态的可逆编辑。它们需要的 UI 完全不同，但模型连接、Workspace、Session、工具装配、任务状态和信任边界全都可以复用 Harness。

这也是我选择插件系统、而不是给每个 App 单独做一套 AI 后端的原因：领域 App 应该专注自己的对象和交互，Agent 基础设施交给 Harness 统一来。

我不希望它变成什么

• 不是要求每个 Plugin 都带 UI；大量能力保持 headless、Tool-only 才是对的。
• 不是用 App 取代 Skill / Markdown；Agent-readable contract 依然重要。
• 不是让实时 Agent 输出直接成为权威状态；预览可以流式回显，最终状态仍应来自验证过的 effect 或 artifact。
• 不是再造一个藏在 App 里的 workflow engine；任务还是应该进入标准 Harness Session，用户可以从 App 里，也可以从 Session 里回答、观察和接着处理。
• 不是让 Agent 靠 DOM 自动化随便改界面；Agent 应该操作有业务语义、有权限边界的 action。

一个最小 App contract 可能包含什么

我现在能想到的最小集合是这些：

• 稳定的 App identity，以及 launcher / settings / standalone window 这类可选入口；
• App-scoped Workspace 和标准 Session，而不是每个插件都重新实现一遍聊天和模型账号；
• 由 App 准备、校验并派发的固定 actions；
• 从 Session 回到 App 的相关性信息：client、request、sequence、revision；
• 受控 effect 与 artifact 协议，以及 preparing / running / attention / completed / failed 这些任务状态；
• Host / Client 权限、构建来源和生命周期边界。

这里面有些可能适合上升成 Harness / Cordis 的通用扩展点，有些也许就该永远留在 DeepDeck 这类桌面产品层。这一点我现在没有结论。

想讨论的几个问题

1. “App”值不值得成为 Harness 插件生态里的一个约定，还是说它更适合作为第三方客户端自己的组合方式？
2. Core 最该提供的最小能力是哪个：App identity、Session/action bridge、effect correlation，还是 artifact / task lifecycle？
3. 对共享可编辑状态来说，revision + validated effect 够不够？还需要事务、权限声明或者更强的审计模型吗？
4. 什么情况下一个插件应该保持 headless？什么情况下领域 UI 真的能提高人的理解、控制和验证能力？

我目前的判断是：插件系统的终点不应该只是一张越来越长的 Tool 列表。更有意思的方向也许是——普通软件继续保留适合人的形态，但它的状态和动作天然能被 Agent 理解；Agent 也不需要接管整个界面，而是在一套清晰的协议里参与工作。

相关项目

• DeepDeck
• Strudel Studio
• Hacker News Reader
• Video Sherlock

利益相关：以上项目都是我自己在做。DeepDeck 基于 DeepSeek Harness，但不是 DeepSeek 官方产品。

English summary

Chat is great for expressing intent, and tools are great for letting an Agent call capabilities. But many real tasks have a second half: humans need to keep watching, listening, comparing, choosing, correcting and directly manipulating. Music arrangement is a direct example—you can describe the change you want, but judging whether it works still requires seeing the song structure, clicking a 16-step pattern, locating sections on a timeline, and listening to the difference. Push all of that into chat and you lose the information density of a domain UI; let the Agent drive the DOM and business semantics collapse into fragile buttons and coordinates.

So I think of an App plugin as three things: a human surface (the domain UI), an agent contract (fixed actions, structured tools, explicit schemas), and a state/effect boundary (validated domain objects, revisions, artifacts, and effects that can be correlated, rejected or undone). Humans and Agents don't fight over the same UI—they collaborate around one validated working object.

“App Plugin” isn't an existing DeepSeek Harness feature or term. It's a third-party runtime experiment I built in DeepDeck on top of ordinary Cordis Host / Client plugins—no changes to Harness itself, and no new package format. Harness already provides models, Workspaces, Sessions, tools and extension points like service / slot; what it doesn't define is an “App” layer with a stable identity, launcher, own Workspace, fixed actions, and a safe path for Agent results to return to a running App.

Strudel Studio is the latest example. Humans edit and audition a song through a timeline and a 16-step sequencer, while the Agent receives a validated song project and can only apply one complete revision through a bounded action tool. Stale results get rejected by revision checks, and the built-in preview never evaluates arbitrary Strudel or JavaScript. The point isn't “adding a chat box to a sequencer”—it's letting natural-language intent enter a controlled domain state transition, then returning the result to an interface a human can read and verify.

Hacker News Reader tests information exploration with read-only tools and UI context. Video Sherlock tests long-running, multimodal work where task progress, evidence, inspected frames and human attention need a persistent surface. Together, the three experiments ask the same question: should Harness / Cordis define a minimal App contract—identity, App-scoped Sessions, fixed actions, correlated effects, artifacts and task lifecycle—or should this composition stay entirely inside third-party desktop clients?

[ljc6413]

这个思路认同——插件确实是 DSH 生态里最值得深耕的形态。我做的 YiHe 编程认知内核也是这么定位的：43 个领域包（11 门语言 + 量子/形式化验证/编译器/WebAssembly/Web3 等 13 个前沿方向）打包成 Agent 预设 + 内核插件，装进 DSH 后 AI 在具体领域给结构化决策。

其中"问题自动路由到领域包"的机制或许对你有参考：用户问协程自动进 Kotlin 包、问重入攻击自动进 Web3 包，避免一个命名空间装不下的问题。

在线体验（真实内核，无需安装）：https://www.zhiyiwei.cn/?utm_source=github_discussion
仓库：https://github.com/ljc6413/pkg-dev （Apache-2.0）