DeepSeek SuperAgent实战：多项目并行开发全流程

DeepSeek SuperAgent 正在把 AI 编程从「单次对话」推向「持续协作」。B站 UP 主分享的这套实战教程，完整跑通了从安装部署、IM 接入到多项目并行推进的链路，值得想提升交付效率的开发者细看。

SuperAgent 是什么：一个常驻的研发搭档

据 UP 主引用的官方文档，SuperAgent 是一个自主 Agent 系统，运行在 DeepSeek^广告 Harness（DSH）之上，以独立进程和独立 Profile 的方式存在。这一点很关键：它的执行过程在 DSH 桌面端看不到，模型配置也自成一套。

它的工作方式和真实研发协作高度相似——需求直接丢在飞书群里，SuperAgent 接收后自主开发，完成后向 GitHub 仓库提交 PR，评审意见也在 PR 里继续迭代。UP 主用一句话概括了它的定位：相当于团队里的一个研发成员。

官方总结的四个特征构成了这套系统的能力边界：

• 连续：用户在 IM 提出方案 A，随后在 PR 中改成方案 B，Agent 能理解并调整执行方向
• 高效交互：响应速度快，可并行处理多个复杂任务
• 主动：无需等待指令，持续观察环境事件并主动推送
• 持久：始终在线，接入真实工作环境长期运行，遇到异常自动修复

理解这四点，就理解了它与普通代码补全工具的本质差异。

DeepSeek Harness（DSH） 是 SuperAgent 运行所依托的宿主环境，可理解为承载 Agent 进程、管理模型配置与插件生态的基础平台。文中提到的桌面端看不到执行过程、模型配置自成一套，正源于 DSH 将 Agent 作为独立 Profile 隔离运行的架构设计：每个 Profile 拥有自己的模型名、API key 与插件表，因而修改配置时不能沿用桌面端的设置，而要直接改对应配置文件。这种隔离既避免了多个实例互相干扰，也让同一台机器上并行运行多个 SuperAgent 成为可能——后文多项目并行正是建立在这一机制之上。

安装：把依赖交给 Agent 自己解决

安装环节的设计思路很有意思——不写死步骤，而是让 Agent 自己读官方说明书。UP 主发送的提示词只有三部分：仓库地址、按官方说明书安装、缺依赖时自动补装。由于 SuperAgent 依赖 Node、Git、Python 等较多组件，这种「自己搞定」的方式反而最省事，整个安装过程用了四分钟。

装完后会获得一个管理面板地址，从这里可以看到 SuperAgent 的执行过程，设置里也能看到已安装的插件，包括 GitWatch、飞书等。需要注意的是模型配置：默认沿用 DSH 中的模型，若要修改，得让它改对应的配置文件，模型名和 API key 存放在独立的表中。

打通飞书与 GitHub：权限是最容易卡住的地方

要让 SuperAgent 进入真实工作流，需要配置两样东西：IM 群聊和 GitHub 仓库，教程里选的是飞书。

流程本身不复杂——让 Agent 配置飞书 CLI，按提示在开放平台创建应用、填入 App ID 和密钥、把机器人拉进群。但 UP 主在演示中遇到了一个典型坑：机器人进群后发消息没反应。原因是创建应用后没有做授权，Agent 主动申请了一键授权链接，补上群相关权限后还需在开放平台「版本管理与发布」中创建新版本并发布，权限才真正生效。

第二处卡点是模型调用报错。排查后发现是旧版 API key 已失效导致 401，Agent 自己检测到本地 DSH 有一份有效配置，完成了修复。这类自愈能力在后续所有环节中反复出现，也是这套系统最实用的部分。修复后，在群里发指令，仓库的 README 里就多了一行来自 SuperAgent 的修改。

飞书开放平台的应用权限体系采用「申请—授权—发布」三段式流程：创建应用后默认不携带任何业务权限，需要先在权限管理中勾选所需范围（如群消息接收、机器人发言），再由管理员完成授权，最后在「版本管理与发布」中创建并发布新版本，权限才会对线上生效。文中机器人进群后发消息无反应，正是因为应用缺少群相关权限且未发布新版本，授权链接与重新发布缺一不可。理解这一流程可以避免把「消息不通」误判为网络或配置问题。

案例一：从群聊需求到 PR 合并

UP 主用一个 Todo 应用演示完整开发链路。产品文档按 P0 划定功能范围，核心是任务的增删改查。在群里 @SuperAgent 并附上需求，它回复「收到」即进入开发阶段，左侧会话可以查看进度，整个任务执行了 26 分钟。

产出形式是一个 PR，里面附带了测试截图以及手机端、电脑端的适配截图。本地拉起来验证后，功能正常，但 UP 主对按钮颜色不满意——直接回群里说改成绿色，SuperAgent 提交了新的 PR 完成调整。

另一种修改路径更贴近日常协作：直接在 PR 下 add agent 让它执行，比如把按钮改成红色，任务面板会显示新任务，完成后原 PR 自动更新。合并后本地验证，颜色确实生效。这种「需求-开发-评审-修改」的闭环无需在多个 session 间切换，注意力只需落在需求本身和最终验收上。

PR（Pull Request）下的 add agent 指在代码托管平台的 PR 评论或操作入口中直接唤起 AI Agent，使其以当前 PR 的分支与讨论为上下文执行修改。相比回到 IM 群重新描述需求，这种方式让评审意见、代码差异和修改动作处在同一处，Agent 能直接读到评审上下文并推送新提交，原 PR 自动更新。它把「提意见」和「改代码」压缩成一个动作，是多实例协作中维持上下文连续的关键入口。

案例二：多实例并行，一人推进多个项目

官方文档明确说明，一个机器人绑定一个实例，因此多项目并行需要准备独立的机器人和仓库。UP 主新建了第二个仓库和名为「项目二组」的机器人，把实例名、端口号、绑定的飞书机器人和仓库地址一并交给 Agent 配置，整个过程用了 12 分钟。

第二个实例上线后也遇到了群消息能触达、但与 Git 仓库衔接异常的问题，让 Agent 自行排查后它创建了 PR 完成修复。随后两个群、两个仓库、两个实例同时开工：项目二开发个人博客，项目一给现有项目添加四种主题模式。两个任务都完成后各自提交了 PR，并附上测试与效果图。

几点判断：价值在持续协作，边界在人工验收

这套方案最核心的价值不在「快」，而在「不断线」。传统用法里每开一个新对话都要重新交代项目背景，而 SuperAgent 让后续需求和 bug 反馈可以继续在群里或 PR 下追加，上下文自然延续。

但它并未消除人的责任。UP 主在结尾特别强调：提交了代码不代表任务完成，功能有没有做好、问题有没有修好，最终仍要自己测试验收。对个人开发者而言，比较稳妥的路径是先拿一个小项目跑通「需求-提交-测试-反馈」这一轮，再逐步接入更多项目。

从工具形态看，SuperAgent 把 IM 群聊、代码仓库和 PR 评审串成一条连续的协作流，这比单纯提升生成速度更接近真实研发的运作方式。至于它能否在更复杂的项目中稳定承担角色，取决于每个团队如何划定 Agent 的职责边界和验收标准。