10 个关键问题 Q&A

1. Q：DSH-SuperAgent 是 DeepSeek 官方商用产品吗？A：不是，仅为研究原型，不适合直接上生产环境。
2. Q：DSH 是什么？A：DeepSeek Harness，是这个 SuperAgent 依赖的 Agent 运行时。
3. Q：它可以监听哪些消息渠道？A：默认 GitHub，额外可选接入飞书。
4. Q：智能体会不会自己随便主动干活？A：不会，只能由授权用户指令或团队预设规则触发。
5. Q：它的核心设计哲学是什么？A：尽可能少占用团队注意力，仅在需要人工决策或产出结果时通知人。
6. Q：一个任务启动后如何运行？A：创建独立工单，分配隔离 Worker 会话与目录执行，完成后返回 PR 等结果。
7. Q：Router 和 Worker 分别负责什么？A：Router 接收事件、调度工单；Worker 负责单个工单的代码执行工作。
8. Q：部署方式有什么特点？A：步骤繁多，支持编码 Agent 交互式引导，一步步自动配置。
9. Q：开源版本和论文描述完全一致吗？A：不一致，论文里部分规划属于未来方向，原型没有实现。
10. Q：开发阶段用什么命令做校验构建？A：pnpm check，一次性执行类型检查、测试、打包构建。

✅ 核心声明（最重要）

• 仅研究原型，非 DeepSeek 官方产品；代码本身就是团队日常开发产物，大量工程由编码 Agent 完成；代码有 bug、风格不一致，
• 不可直接上生产，使用前必须自行评审改造。
• 
  
1. 开源版本 ≠ 内部版本，也不等于论文《Exploring Super-agent Design: Towards a More Autonomous Agent System》的完整实现；论文里一部分设计属于未来方向，原型里并没有实现。
2. 底层载体：作为 DSH（DeepSeek Harness）Bundle插件包运行。DSH 是插件化的 Agent 运行时，负责工具、沙箱、会话、模型接入；Super-agent 是在它之上叠加多任务调度、事件监听、团队协作逻辑。

✅ 它是干什么的？能力边界

• 监听渠道：GitHub（必填）+ 可选飞书；
• 触发模式：只有授权用户指令 / 团队预定义规则允许时才干活，不会随意乱行动；
• 工作模型：收到请求 → 创建独立工单（Work Item）→ 分配独立 Agent 会话 + 独立工作目录执行 → 在原对话里返回结果（典型产出：PR）；
• 配套 Web 面板：展示待人工确认事项，把人的注意力消耗降到最低；
• 核心理念（000-philosophy.md）：

  尽可能少占用团队注意力，尽可能多交付价值。能不打扰人就不说话；只有需要人决策验收、或者产出结果可用时才通知人。

和普通 Coding Agent 的区别：普通 Agent 是单次对话、一次性任务；Super-agent 是常驻、事件驱动、多工单隔离并行、跨 IM/GitHub 信道联动的团队协作者。

✅ 部署方式

安装步骤较多，官方设计了Agent 自助引导流程：直接对你的编码 Agent 说：

Read SETUP.md in this repository and set up dsh-superagent with me.

Agent 会一次只问一个简短问题、先输出完整方案、再自动安装配置，全程参照仓库里 SETUP.md。

✅ 文档阅读顺序（按编号依次阅读，依赖前置文档）

1. 000-philosophy.md
   设计哲学、对运维 / 使用者的约束
2. 001-domain.md
   业务域模型（工单、事件、源定义）
3. 002-authorization.md
   权限、授权模型
4. 003-execution.md
   任务执行沙箱、会话隔离
5. 004-prompts.md
   内置提示词体系
6. 005-panel.md
   Web 管理面板
7. 006-deployment.md
   手动部署、配置、升级、排障
8. 007-architecture.md
   架构（Router + Worker 双层）
9. 008-cookbook.md
   扩展开发，新增消息源（Source）

✅ 开发 & 工程命令

bash

pnpm check


一次性执行：类型检查 + 单元测试 + 构建打包

✅ License

MIT License

🧠 配套架构补充（论文里的核心，原型部分落地）

• Router（调度器）
  常驻，接收所有外部事件、判断是否受理、创建工单、分派 Worker；
• Worker（执行智能体）
  每个工单独立隔离，独立目录、独立会话，负责读代码、改代码、跑测试、提交 PR，Worker 还可以继续调用子 Agent；
• 核心痛点：传统 Agent 瓶颈不再是模型能力，而是人的注意力预算，人只能同时跟进少量会话；Super-agent 把会话调度、上下文同步交给系统，人只做验收和决策IT之家。

📌 局限清单

1. 当前原型聚焦单个 GitHub 仓库，不是多仓库管理；
2. 论文部分设想（部分自主主动触发、更复杂的自愈、跨多外部系统）还没实现；
3. 工程质量是研究代码水平，稳定性、异常恢复、安全隔离都需要二次加固；
4. 不是托管 SaaS，是要自己部署运维的 Bundle。