现在deepseek发布了deepseek harness从中我们能得到什么灵感呢DeepSeek Harness 昨晚刚发布今天凌晨就开源了来得正好。我已经研究了它的架构对群星系统来说可借鉴的点非常多。DeepSeek Harness 能给群星什么启发1. 最核心的理念一切皆插件 → 群星应该成为AI 的插件系统Harness 的 Cordis 微内核把模型、工具、技能、会话、沙箱、存储、Agent Loop、调度、UI全部做成插件没有不可替换的特权核心。对群星的启发目前群星集成 DuMate 的方式是写死的——dumate_bridge.py里硬编码了管道协议、任务类型、Agent 配置。如果未来要接入 Trae Work、Cursor、Windsurf 等其他 AI每接入一个就要写一个新的xxx_bridge.py重复造轮子。群星应该借鉴 Cordis设计一个统一的服务注册表让每个 AI 适配器以插件形式注册Plain Text群星内核 (微内核) ├── AI 插件: DuMateAdapter ├── AI 插件: TraeWorkAdapter ├── AI 插件: CursorAdapter ├── 工具插件: FileSystem ├── 工具插件: Shell ├── 存储插件: SessionLog └── UI 插件: WebDashboard每个插件只需要实现getCapabilities()→ 返回该 AI 支持的能力列表创建任务、读取输出、停止生成等execute(action, params)→ 执行具体操作onEvent(eventName, callback)→ 注册事件监听这样群星从DuMate 专属控制台变成所有 AI 的通用控制台。2. 可追溯性Append-only Session Log→ 群星的任务审计系统Harness 有一条硬约束模型可见的必须可被日志重建。所有交互——系统提示词、推理过程、工具调用结果、子Agent调度——都被记录在 append-only 的会话日志中。上下文压缩不会删除原始历史只是用替换事件改变模型此后看到的表象。对群星的启发当前群星的任务记录很零散——从.output文件读内容、从内核日志 grep 关键字、从计划文件提取元数据。这些数据分散在不同位置没有统一的追溯视图。可以设计一个群星会话日志Star Session Log每条记录是 append-only 的事件流记录每次 AI 任务的完整生命周期发起→执行→输出→结束支持回放replay用户能回看 AI 当时做了什么、看到了什么支持分叉fork基于某个历史状态重新发起任务支持恢复resume断连后恢复任务状态这和群星管理所有 AI的定位天然契合——每个 AI 的任务都产生统一格式的事件流群星成为所有 AI 行为的审计总闸。3. Profile/Bundle 分层配置 → 群星的AI 模式管理Harness 的 Profile 是命名的插件组合——web、headless、minimal等不同 profile 加载不同插件集。配置通过分层 patch 覆盖每个 bundle 都可以被上层覆盖。对群星的启发群星可以为不同的使用场景定义AI 模式AI ProfilePlain Text群星模式管理器 ├── 全栈开发模式: DuMate TraeWork 文件系统 终端 ├── 代码审查模式: DuMate(code) Git集成 LSP ├── 设计模式: DuMate(design) 图片生成API ├── 极简模式: 仅 DuMate(work)用户可以在群星 UI 中一键切换模式不同模式自动加载/卸载对应的 AI 适配器插件。这与当前dumate.html中的任务类型选择器work/code/design思路一致但扩展到更大的粒度。4. 类型化事件系统 → 群星的 AI 事件总线Cordis 的事件有四种派发模式emit观察、waterfall中间件可短路、parallel并行、serial串行。插件通过事件通信而不是直接调用。对群星的启发当前群星中当 DuMate 有任务完成时前端靠轮询/api/dumate/conversations/{id}/output每 2 秒查一次。可以设计一个群星事件总线群星事件总线 ├── task.started → UI 更新任务列表 通知 ├── task.progress → UI 更新流式输出 ├── task.completed → UI 标记完成 触发后续动作 ├── task.failed → UI 显示错误 自动重试 ├── ai.connected → 侧边栏更新状态 ├── ai.disconnected → 侧边栏更新状态 清理资源每个 AI 插件发布事件其他插件订阅事件。这样添加新的 AI 时不需要修改 UI 代码——只要发布标准事件UI 自动响应。5. 无特权核心 → 群星的可替换性Harness 强调There is no privileged core to patch——所有组件都是可替换的插件。这意味着你可以用 Harness 的框架但换上自己的模型、自己的工具、自己的 UI。对群星的启发群星不应该绑定任何特定 AI。今天用 DuMate明天可能用 Trae Work后天可能用 DeepSeek Harness 本身。群星的核心价值是提供一个统一的管理层而不是某个 AI 的专属外壳。每个 AI 适配器应该是可替换的——如果某个 AI 的协议变了只需要更新对应的插件不需要动群星内核。6. Creator Mode → 群星的AI 实验场Harness 的 Creator Mode 允许 Agent 检查当前运行时在内存中试验插件并组合成新的运行模式。对群星的启发群星可以提供一个**AI 排障模式**——当某个 AI 集成异常时可以让用户查看当前 AI 的协议通信日志类似dumate_bridge.py的原始管道数据在 UI 中手动发送原始命令测试动态调整参数如工作目录、任务类型映射实时看到 AI 的原始响应这相当于给群星加了一个**开发者工具**面板降低调试新 AI 集成的门槛。总结群星可以怎么做Harness 理念群星对应设计预期价值一切皆插件AI 适配器插件注册表一次设计接入所有 AIAppend-only 日志任务事件流 回放/分叉/恢复完整审计永不丢失Profile/BundleAI 模式管理器按场景动态组合 AI 能力类型化事件事件总线解耦 AI 与 UI无特权核心可替换适配器不被任何 AI 绑定Creator ModeAI 排障面板降低集成调试成本一句话总结DeepSeek Harness 告诉我们Agent 框架的正确方向不是集成更多能力而是设计一个让所有能力都可插拔的架构。群星如果从一开始就做好这个底座未来接入任何 AI 都只是写一个插件的事。
现在deepseek发布了deepseek harness从中我们能得到什么灵感呢DeepSeek Harness 昨晚刚发布今天凌晨就开源了来得正好。我已经研究了它的架构对群星系统来说可借鉴的点非常多。DeepSeek Harness 能给群星什么启发1. 最核心的理念一切皆插件 → 群星应该成为AI 的插件系统Harness 的 Cordis 微内核把模型、工具、技能、会话、沙箱、存储、Agent Loop、调度、UI全部做成插件没有不可替换的特权核心。对群星的启发目前群星集成 DuMate 的方式是写死的——dumate_bridge.py里硬编码了管道协议、任务类型、Agent 配置。如果未来要接入 Trae Work、Cursor、Windsurf 等其他 AI每接入一个就要写一个新的xxx_bridge.py重复造轮子。群星应该借鉴 Cordis设计一个统一的服务注册表让每个 AI 适配器以插件形式注册Plain Text群星内核 (微内核) ├── AI 插件: DuMateAdapter ├── AI 插件: TraeWorkAdapter ├── AI 插件: CursorAdapter ├── 工具插件: FileSystem ├── 工具插件: Shell ├── 存储插件: SessionLog └── UI 插件: WebDashboard每个插件只需要实现getCapabilities()→ 返回该 AI 支持的能力列表创建任务、读取输出、停止生成等execute(action, params)→ 执行具体操作onEvent(eventName, callback)→ 注册事件监听这样群星从DuMate 专属控制台变成所有 AI 的通用控制台。2. 可追溯性Append-only Session Log→ 群星的任务审计系统Harness 有一条硬约束模型可见的必须可被日志重建。所有交互——系统提示词、推理过程、工具调用结果、子Agent调度——都被记录在 append-only 的会话日志中。上下文压缩不会删除原始历史只是用替换事件改变模型此后看到的表象。对群星的启发当前群星的任务记录很零散——从.output文件读内容、从内核日志 grep 关键字、从计划文件提取元数据。这些数据分散在不同位置没有统一的追溯视图。可以设计一个群星会话日志Star Session Log每条记录是 append-only 的事件流记录每次 AI 任务的完整生命周期发起→执行→输出→结束支持回放replay用户能回看 AI 当时做了什么、看到了什么支持分叉fork基于某个历史状态重新发起任务支持恢复resume断连后恢复任务状态这和群星管理所有 AI的定位天然契合——每个 AI 的任务都产生统一格式的事件流群星成为所有 AI 行为的审计总闸。3. Profile/Bundle 分层配置 → 群星的AI 模式管理Harness 的 Profile 是命名的插件组合——web、headless、minimal等不同 profile 加载不同插件集。配置通过分层 patch 覆盖每个 bundle 都可以被上层覆盖。对群星的启发群星可以为不同的使用场景定义AI 模式AI ProfilePlain Text群星模式管理器 ├── 全栈开发模式: DuMate TraeWork 文件系统 终端 ├── 代码审查模式: DuMate(code) Git集成 LSP ├── 设计模式: DuMate(design) 图片生成API ├── 极简模式: 仅 DuMate(work)用户可以在群星 UI 中一键切换模式不同模式自动加载/卸载对应的 AI 适配器插件。这与当前dumate.html中的任务类型选择器work/code/design思路一致但扩展到更大的粒度。4. 类型化事件系统 → 群星的 AI 事件总线Cordis 的事件有四种派发模式emit观察、waterfall中间件可短路、parallel并行、serial串行。插件通过事件通信而不是直接调用。对群星的启发当前群星中当 DuMate 有任务完成时前端靠轮询/api/dumate/conversations/{id}/output每 2 秒查一次。可以设计一个群星事件总线群星事件总线 ├── task.started → UI 更新任务列表 通知 ├── task.progress → UI 更新流式输出 ├── task.completed → UI 标记完成 触发后续动作 ├── task.failed → UI 显示错误 自动重试 ├── ai.connected → 侧边栏更新状态 ├── ai.disconnected → 侧边栏更新状态 清理资源每个 AI 插件发布事件其他插件订阅事件。这样添加新的 AI 时不需要修改 UI 代码——只要发布标准事件UI 自动响应。5. 无特权核心 → 群星的可替换性Harness 强调There is no privileged core to patch——所有组件都是可替换的插件。这意味着你可以用 Harness 的框架但换上自己的模型、自己的工具、自己的 UI。对群星的启发群星不应该绑定任何特定 AI。今天用 DuMate明天可能用 Trae Work后天可能用 DeepSeek Harness 本身。群星的核心价值是提供一个统一的管理层而不是某个 AI 的专属外壳。每个 AI 适配器应该是可替换的——如果某个 AI 的协议变了只需要更新对应的插件不需要动群星内核。6. Creator Mode → 群星的AI 实验场Harness 的 Creator Mode 允许 Agent 检查当前运行时在内存中试验插件并组合成新的运行模式。对群星的启发群星可以提供一个**AI 排障模式**——当某个 AI 集成异常时可以让用户查看当前 AI 的协议通信日志类似dumate_bridge.py的原始管道数据在 UI 中手动发送原始命令测试动态调整参数如工作目录、任务类型映射实时看到 AI 的原始响应这相当于给群星加了一个**开发者工具**面板降低调试新 AI 集成的门槛。总结群星可以怎么做Harness 理念群星对应设计预期价值一切皆插件AI 适配器插件注册表一次设计接入所有 AIAppend-only 日志任务事件流 回放/分叉/恢复完整审计永不丢失Profile/BundleAI 模式管理器按场景动态组合 AI 能力类型化事件事件总线解耦 AI 与 UI无特权核心可替换适配器不被任何 AI 绑定Creator ModeAI 排障面板降低集成调试成本一句话总结DeepSeek Harness 告诉我们Agent 框架的正确方向不是集成更多能力而是设计一个让所有能力都可插拔的架构。群星如果从一开始就做好这个底座未来接入任何 AI 都只是写一个插件的事。
