什么是 dsh-superagent？
dsh-superagent 是一个主动式编码代理，专为配合单个 GitHub 仓库工作而设计。它以 DeepSeek Harness 软件包的形式分发，并监听来自 GitHub 以及可选的飞书请求。
当获授权的用户要求它执行任务时，系统会创建一个工作项、建立专用的代理会话和目录、完成任务，并在原始对话中回复。结果可能包括一个拉取请求。Web 面板会显示需要人工关注的工作项。
dsh-superagent 是供参考的研究原型，并非 DeepSeek 官方产品，也不是可用于生产环境的系统。
公开发布的仓库与团队内部版本不同，也与 探索超级代理设计：迈向更自主的代理系统 一文中讨论的实现不同。该文章中的一些想法描述的是未来方向，尚未在此原型中实现。
核心设计原则
该项目旨在尽可能减少对人工注意力的占用，同时尽可能提供更大价值。由于团队级代理也可能消耗团队的注意力，dsh-superagent 遵循两项重要约束：
- 只有在有人要求它行动，或团队定义的规则允许该行动时，它才会执行操作。
- 只有在有人必须采取行动，或有人可以使用已完成的结果时，它才会发言。
部署代理前，请阅读理念文档。该文档解释了这一运行原则，以及运行系统的人员所承担的责任。
主要功能
- 专注于单个仓库：每次部署只处理一个 GitHub 仓库。
- GitHub 集成：代理监听来自 GitHub 的授权请求。
- 可选的飞书集成：团队也可以使用飞书作为请求来源。
- 工作项跟踪：已接受的请求会成为一个工作项。
- 隔离执行：每项任务都在独立的代理会话和目录中运行。
- 理解对话的回复：结果会返回到请求发起的对话中。
- 人工关注面板：Web 面板会标识需要人员参与的工作。
- 规则控制的行为：代理只会响应请求或明确的团队规则执行操作。
安装前须知
请将此仓库视为研究代码。它可能包含缺陷、不一致的编码风格，或不适合你所在环境的工程决策。在依赖它之前，请审查实现并进行调整。
配置包含许多步骤，因此项目建议与编码代理协作完成，而不是手动猜测所需的配置。
引导式安装与配置
步骤 1：使用编码代理打开仓库
让你的编码代理可以访问已克隆或已检出的仓库。然后向它提供项目推荐的配置指令：
Read SETUP.md in this repository and set up dsh-superagent with me.编码代理应以 SETUP.md 作为事实依据。
步骤 2：回答配置问题
配置流程设计为每次提出一个简短问题。请提供有关仓库、集成和环境的所需信息。即使流程有代理协助，也不要因为这个原因跳过审核步骤。
步骤 3：审查完整计划
收集所需信息后，编码代理会一次性展示完整计划。在允许安装或更改配置前，请仔细审查该计划。尤其要确认计划与您打算让代理管理的仓库，以及您打算启用的请求来源相符。
步骤 4：让代理安装并配置项目
批准计划后，编码代理会根据 SETUP.md 安装并配置系统。由于 README 将详细配置流程交给该文件，请遵循其中的当前说明，不要依赖未记录的命令。
步骤 5：验证项目
进行开发验证时，请运行：
pnpm check此命令会运行类型检查、测试和构建。成功运行后，即可综合检查项目的类型、测试套件和构建流程。
运行代理前先了解文档
编号文档是按顺序累积编写的。请按顺序阅读，因为每份文档只假设你已经了解此前文档介绍的内容：
- 000 理念：了解最大限度减少注意力占用的运行原则以及操作员的职责。
- 001 领域模型：了解项目的核心概念及其相互关系。
- 002 授权：确定哪些人有权要求代理执行工作。
- 003 执行：了解已接受的任务如何执行。
- 004 提示词：查看指导代理行为的提示词。
- 005 面板：了解 Web 面板如何呈现需要人工关注的事项。
- 006 部署：遵循手动设置、配置、升级和故障排除指南。
- 007 架构：研究系统的技术结构。
- 008 指南：了解如何添加 Source。
基本用法
提交已授权的请求
设置完成后，获准用户可以通过 GitHub，或在启用可选集成时通过飞书，要求代理执行仓库工作。典型请求应说明期望的仓库变更以及相关验收标准。
例如，获准用户可以要求代理调查仓库问题、进行适当的代码变更并返回结果。具体的请求方式和获准用户取决于配置的 Source 及授权规则。
让代理创建并执行工作项
请求获接受后，dsh-superagent 会创建一个工作项，并在其独立的代理会话和目录中执行任务。这种执行模型使任务的工作上下文保持隔离。
在原上下文中接收结果
代理会在原始对话中回复，而不是迫使用户去单独的渠道查找结果。根据所执行的工作，回复中可能包含拉取请求。
使用面板进行人工跟进
检查 Web 面板中需要人员处理的工作。面板通过呈现需要人工操作的事项，支持项目的注意力管理目标，而不是为每个内部步骤生成不必要的沟通。
授权与安全运行
授权是设计的核心。能够跨团队仓库执行操作的主动式代理不应接受任意请求。请使用授权文档来定义谁可以发起工作以及需要满足哪些条件。
- 限制请求者：仅允许指定人员或系统创建可执行的请求。
- 审查团队规则：确保自动化操作仅在团队明确制定的规则下执行。
- 保留人工审查：将代理生成的变更视为可能需要检查和调整的工作。
- 扩大使用前进行测试：开发变更后运行
pnpm check，并在你的环境中验证行为。
高级技巧
使用部署指南执行手动操作
如果需要手动设置、更改配置、升级项目或排查问题，请参阅006 部署。README 将该文档列为这些运维流程的详细来源。
调整行为时审查提示词
在更改代理解释或执行工作的方式前，请阅读004 提示词。提示词变更可能影响代理何时沟通、如何处理任务，以及遵循项目注意力最小化理念的程度。
修改任务隔离前研究执行机制
系统为每个工作项提供独立的代理会话和目录。在修改此行为前，请审阅003 执行和007 架构，以确保变更与项目的执行模型和系统模型保持一致。
谨慎添加新的 Source
Source 是系统接收工作的集成方式。如果希望在现有 GitHub 和可选飞书路径之外添加新的 Source，请遵循008 指南。引入新的请求渠道时，不要绕过授权模型。
以有用的静默为目标
调整系统时，同时评估操作的价值及其通知带来的注意力成本。优先在人员必须采取行动或可用结果已经准备就绪时进行沟通。这能使扩展和运维规则与项目的核心理念保持一致。
开发工作流
修改代码后，使用项目的综合验证命令：
pnpm check由于该命令会运行类型检查、测试和构建，因此在分享或部署变更前应将其作为常规检查点。通过此命令并不意味着这个研究原型已经达到生产就绪状态；你仍须审查其行为、安全假设、授权机制以及是否适合你的环境。
结语
dsh-superagent 提供了一种面向研究的模型，用于在尽量减少人工注意力需求的同时，委派单个 GitHub 仓库上的工作。请从引导式的 SETUP.md 工作流开始，按顺序阅读编号文档，谨慎配置授权，使用 pnpm check 验证变更，并通过面板将人工精力集中在真正需要的地方。