从聊天机器人到 AI 开发助手：基于 DeepSeek Harness 与飞书构建远程开发入口

AI-CODING 实践系列（一）

关键词：DeepSeek Harness、DSH、飞书机器人、AI Agent、会话隔离、多项目管理、Windows

前言

最近一直在思考一个问题：能不能让 AI 编码工具摆脱传统 IDE 和终端的限制，变成一个可以随时远程交互的开发助手？

平时使用 Claude Code、Codex 或其他 AI 编码工具，大多需要打开电脑、进入项目目录、启动工具，然后输入需求。

这些工具的编码能力已经相当不错，但交互方式仍然比较依赖开发者坐在电脑前。

我希望实现的是另一种工作模式：

在手机上提出需求，与 AI 讨论实现方案。
不同开发项目拥有独立的上下文。
确认需求后，让 AI 在开发机上自动完成编码和编译。
开发过程可以异步执行，不必保持聊天窗口或终端打开。
最后通过聊天工具收到执行结果。

经过一段时间的尝试，最终形成了一套基于 DeepSeek Harness + 飞书机器人 + Python 的 AI-CODING 原型。

本文主要记录技术选型、远程交互以及多项目管理的实现过程。

一、为什么需要独立的 Agent Harness？

最开始考虑过几种不同的 AI 编码工具，包括 Claude Code、CodeBuddy、WorkBuddy，以及独立的 Agent Harness。

这些工具都能够完成一定程度的自动化开发，但要实现无人值守运行，还需要解决另外几个问题：

如何从手机远程提交任务？
如何让 Agent 长期保持在线？
如何管理多个开发项目？
如何避免不同项目的对话互相污染？
如何在聊天结束后继续执行长时间任务？

传统的交互式编码工具并不天然解决这些问题。

因此，我逐渐确定了一条原则：

Agent 负责理解和执行开发需求，任务调度与状态管理应当由确定性的程序负责。

最终选择 DeepSeek Harness（以下简称 DSH）作为主要的 Agent 基座。

选择它的主要原因，是它同时提供了交互式 Host 和适合自动化调用的 Headless 执行方式，能够在一套基础设施上承担不同角色。

二、从企业微信转向飞书

最初设想通过企业微信下发任务。

除了聊天本身，我也希望利用企业微信微盘，实现构建包、日志和测试报告的上传下载。

但实际调研后发现，消息机器人和微盘 API 并不是同一种权限体系。对于缺少企业管理员权限的个人开发环境，深度集成微盘存在额外门槛。

因此，我决定不再把文件交付能力和消息入口绑定在同一个平台上。

最后选择了飞书。

飞书的优势不仅在于能够收发消息，更重要的是它支持群聊、话题以及应用机器人，可以形成比较自然的多项目讨论空间。

我希望实现这样一种结构：

AI-CODING 飞书机器人
│
├── 私聊
│   ├── 管理项目
│   ├── 查询任务
│   └── 系统操作
│
└── AI-CODING 讨论群
    ├── 项目 A / 功能讨论
    ├── 项目 A / 构建问题
    ├── 项目 B / 功能开发
    └── 项目 C / 技术研究

日常不需要打开网页管理后台，可以直接在手机上完成大部分交互。

三、如何让 DSH 常驻后台？

在 Windows 开发机上，DSH 可以通过 Web Host 运行，并不要求一直打开浏览器。

最初曾考虑安装 Desktop 版本，因为桌面应用在启动和管理方面通常更直观。

但在现有环境中，Web Host 已经满足消息插件的运行需求，因此暂时没有必要增加另一个客户端。

这里有一个实际踩过的坑。

DSH 最初通过 npx 运行，后来为了固定版本，使用类似这样的命令：

npx.cmd --yes @deepseek-ai/dsh@<version> web --no-open

显式指定版本后，npm 可能需要重新下载对应版本及其依赖。首次执行时，终端短时间没有出现 Web 服务输出，并不一定代表程序出错，也可能尚未完成依赖安装。

另外，npm 的安装脚本安全策略可能阻止部分原生模块执行安装脚本。这类问题可能影响 DSH 的终端和本地进程能力，不能简单忽略。

最终的处理方式是：

固定已经验证可用的 DSH 版本。
确认原生依赖安装完整。
通过 Windows 任务计划程序在登录后启动 DSH Web Host。
关闭浏览器或断开远程桌面连接后，Host 仍继续运行。

这里需要说明：登录自启不等于 Windows 服务。

如果系统重启后始终没有用户登录，采用登录触发的任务计划程序不会自动启动 Host。这一点需要根据实际无人值守要求进一步完善。

四、飞书插件的选择比想象中复杂

DSH 有社区插件生态，但插件数量多并不意味着可以随意安装。

我曾尝试过不同的飞书插件，遇到的最大问题是版本兼容。

例如，某个插件虽然支持飞书话题会话，但其声明依赖的是 DSH 较早版本的内部组件。在新的 DSH Host 中安装时，插件管理器直接给出了不兼容警告。

这件事让我意识到：

插件能够被搜索到，不代表能够安装；能够安装，也不代表长期运行可靠。

筛选插件时，最终重点考察了几个方面：

是否支持当前 DSH 版本。
是否支持飞书 WebSocket 长连接。
是否支持话题独立 Session。
是否能够管理 Session 与工作区。
是否支持远程审批、停止和查询。
是否有持续维护和实际使用记录。

最后选择了社区插件 @xmanrui/dsh-im。

在测试环境中，已经验证了飞书机器人连接、群话题独立会话，以及 DSH 重启后恢复上下文等能力。

使用 WebSocket 长连接的另一个好处是，不需要专门为 Windows 开发机开放公网回调端口。

五、多项目管理：项目不等于会话

在最初的设计中，很容易把“一个飞书话题”理解成“一个开发项目”。

实际使用后发现，这种对应关系过于简单。

同一个项目可能有多个并行讨论，例如功能开发、缺陷修复、构建问题等。它们都应该关联同一个代码仓库，但又不应该共享完全相同的聊天上下文。

因此，我把系统中的对象分成三个层次：

对象	作用
Project	一个实际开发项目，关联 Git 仓库
Discussion	一个飞书讨论话题，关联 Project
Session	一个 DSH 对话上下文

它们之间的关系是：

Project A
│
├── Discussion 1 → DSH Session 1
├── Discussion 2 → DSH Session 2
└── Discussion 3 → DSH Session 3

这样既可以保证不同讨论之间的上下文隔离，又能让多个话题共享同一个项目的基本信息。

项目和讨论映射保存在 SQLite 中，而不是单纯依赖大模型记忆。

这也是本次实践中一个重要的认识：

长期、确定性的业务状态，应该存储在数据库中；模型 Session 更适合保存对话上下文。

六、让飞书成为项目管理入口

为了避免每次创建项目都回到电脑上操作，我增加了一个简单的管理员能力。

它提供项目注册、查询以及飞书话题绑定。

最初的操作流程是：

机器人私聊中登记项目。
在群聊中创建讨论话题。
再返回私聊完成话题绑定。

这个流程虽然能用，但不够自然。

于是进一步增加群聊一站式管理，让用户可以直接在话题中提出：

创建一个项目，名称为示例插件，关联指定 GitLab 仓库。

系统负责登记项目，并尝试自动绑定当前话题。

已有的私聊管理能力仍然保留，只是增加更便捷的群聊入口。

值得注意的是，自然语言管理操作不能仅依靠提示词进行权限控制。

真正涉及创建项目、绑定话题等写操作时，需要使用可信的飞书消息身份和后端权限校验。模型自行生成的用户 ID、群 ID 或话题 ID，不能作为授权依据。

七、最终形成的架构

经过几轮调整，最终收敛为下面的结构：

飞书手机端
    |
    v
dsh-im
    |
    v
DSH 对话 Agent
    |
    +-- ProjectRegistry
    |       项目与话题管理
    |
    +-- Scheduler
            任务队列与状态管理
                |
                v
            DSH Headless
                |
                v
            Git Worktree
                |
                v
            MSBuild / 验证

这里有一个很重要的设计边界：

飞书中的 DSH Agent 不直接承担长时间编码任务，而是负责理解需求、管理讨论和提交任务。

真正的代码修改由独立启动的 DSH Headless 完成。

因此，即使用户退出飞书、关闭手机，编码任务仍然可以由后台执行器继续处理。

八、阶段性总结

这次实践让我对 AI Agent 的理解发生了一些变化。

最开始关注的是应该选择哪个 Agent 框架、哪个聊天插件、如何设计多 Agent 架构。

但真正实现后发现，很多问题并不需要复杂的 Agent 协作框架。

一个可靠的聊天入口、一个能够调用开发工具的编码 Agent，再加上一套轻量的确定性任务管理程序，就足以构建相当实用的自动化开发系统。

同时也得到几个经验：

不要过早追求复杂的多 Agent 架构。
会话隔离和项目隔离是两个不同的问题。
不要把业务状态完全寄托在模型上下文中。
插件兼容性和维护质量比插件数量更重要。
移动端交互应该尽量自然，而不是把命令行搬进聊天窗口。
先验证真正的使用场景，再根据问题完善系统。

目前，飞书已经可以作为 AI-CODING 的远程交互入口，系统也具备了通过飞书驱动开发任务的能力。

下一篇将介绍真正的执行部分：如何在 Windows 中使用 Git Worktree、DSH Headless、MSBuild 和 Python，构建一条能够自动编码、编译和验证的流水线。

本文记录的是一套个人开发环境中的阶段性实践，部分能力仍属于原型验证，不代表已经完成生产级高可用和安全隔离。