---
type: agent_dev
keywords: [agent, skill, 自动化, 智能助手, 助手, langchain, langgraph, 机器人, bot, 对话, workflow, 工作流, multi-agent]
priority: high
---

# Agent 开发项目配置

本配置用于端到端的 Agent 开发项目，包括但不限于：
- Claude Code Skill/Agent
- LangChain Agent
- LangGraph Workflow
- Multi-Agent 系统
- 其他 AI Agent 框架

## 模板路径
templates/agent_dev_template.md

## 启动问题示例

以下问题仅作为参考，根据用户初始描述的详细程度和信息完整度动态选择和调整。

### 示例问题：主要任务

```yaml
question: "这个智能助手主要帮助用户完成什么任务？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
  - label: "信息查询和检索"
    description: "帮助用户查找、搜索、整理信息"
  - label: "数据处理和分析"
    description: "对数据进行清洗、转换、分析"
  - label: "自动化任务执行"
    description: "自动完成重复性工作或流程"
  - label: "辅助决策支持"
    description: "提供建议、分析、推荐"
multiSelect: true
```

**使用时机**：用户初始描述未明确说明具体任务时使用。如已明确，跳过此问题。

---

### 示例问题：预期价值

```yaml
question: "预期带来什么价值？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
  - label: "提高效率"
    description: "节省时间，加快处理速度"
  - label: "降低成本"
    description: "减少人力投入，降低运营成本"
  - label: "提升质量"
    description: "提高准确性，减少错误"
  - label: "增强用户体验"
    description: "简化操作，提升满意度"
multiSelect: true
```

**使用时机**：用户初始描述未说明价值或目标时使用。可与其他问题合并。

---

### 示例问题：使用场景

```yaml
question: "用户在什么情况下会需要使用这个助手？（可多选，或在'其他'中描述具体场景；需要帮助请输入'需要帮助'）"
options:
  - label: "定期自动执行"
    description: "按时间表自动运行，如每天早上、每周等"
  - label: "用户主动调用"
    description: "用户有需求时手动触发"
  - label: "事件触发"
    description: "特定事件发生时自动执行，如文件变化、消息到达等"
multiSelect: true
```

**使用时机**：了解基本任务后询问。根据回答深入询问具体触发条件、频率等细节。

---

### 示例问题：架构复杂度

```yaml
question: "任务是否需要多个专门的助手配合完成？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
  - label: "不需要，单个助手就能完成"
    description: "任务相对简单，流程单一"
  - label: "需要，任务复杂，需要多个助手协作"
    description: "需要将任务拆分给不同的专门助手"
multiSelect: false
```

**使用时机**：用户描述涉及多步骤、复杂流程时询问。如选择Multi-Agent，后续深入询问各Agent职能和协作方式。

---

## 访谈启动策略

### 分析用户初始描述

访谈前先分析用户初始输入的信息完整度：

**信息完整度检查**

识别用户初始描述中已包含的信息：

- ✓ 明确任务/功能 → 跳过"主要任务"问题
- ✓ 说明使用场景 → 跳过或简化"使用场景"问题
- ✓ 提到价值/目标 → 跳过"预期价值"问题
- ✓ 描述复杂流程/多步骤 → 主动询问Multi-Agent需求
- ✓ 提及外部系统 → 深入询问数据集成细节
- ✓ 涉及性能/安全 → 追问具体指标

**动态起始点选择**

| 用户描述情况 | 起始策略 | 示例 |
|------------|---------|------|
| 详细完整 | 直接补充细节 | "如何定义'重要联系人'？" |
| 基本清晰 | 从1-2个示例问题开始 | "使用场景"+"预期价值" |
| 模糊简略 | 依次使用示例问题 | "主要任务"→"使用场景"→... |
| 技术导向 | 引导到业务需求 | "这个功能主要帮用户解决什么问题？" |

### 启动原则

1. **先分析，后提问**
   - 仔细阅读用户初始描述
   - 识别已有信息和缺失信息
   - 避免询问已明确的内容

2. **避免机械执行**
   - 示例问题不是固定流程
   - 根据实际情况选择和调整
   - 灵活组合或跳过问题

3. **动态调整深度**
   - 用户回答内容丰富 → 快速推进
   - 用户回答简短模糊 → 追问细节
   - 用户不确定 → 提供更多选项或示例

4. **保持对话自然**
   - 基于上一轮回答提出下一个问题
   - 合并相关信息的询问
   - 避免突兀的话题跳转

## 访谈策略指南

### 访谈目标

收集完整的业务需求信息，用于生成结构化需求文档。

### 访谈方式

- 使用 AskUserQuestion 工具进行所有提问
- 每个问题独立、可单独回答
- 提供2-4个常见选项
- 在question中明确提示"可在'其他'中详细描述"或类似说明
- 系统自动添加"其他"选项
- 使用业务语言，避免技术术语

### 信息收集范围

**基础信息**：
- 项目背景和目标
- 核心功能列表
- 目标用户和使用场景
- 使用入口和触发方式

**架构信息**（如需Multi-Agent）：
- Agent角色划分和职能
- Agent能力边界
- Agent间协作关系和数据传递

**功能细节**：
- 输入输出定义
- 需要访问的外部数据和系统
- 完整的交互流程
- 异常和分支处理

**交付规划**：
- MVP核心功能
- 后续优化和高级功能
- 分阶段目标

**非功能需求**：
- 用户明确的技术约束
- 性能要求（用户数、响应时间等业务指标）
- 安全和隐私要求（业务层面）
- 其他特殊需求

**验收标准**：
- 功能验收条件
- 非功能验收条件

### 动态访谈原则

1. **基于回答识别缺口**
   - 分析每轮回答获得的信息
   - 识别仍缺失的领域
   - 确定后续提问方向

2. **适应项目复杂度**
   - 简单项目：快速收集核心信息即可
   - 复杂项目：深入询问架构、流程、分阶段等
   - Multi-Agent项目：详细了解各Agent职能和协作

3. **聚焦关键特征**
   - 如涉及高性能：追问具体性能指标
   - 如涉及高安全：追问敏感数据处理
   - 如需集成外部系统：追问数据流转细节
   - 如涉及复杂流程：询问异常和分支处理

4. **避免重复和冗余**
   - 不重复提问已获取的信息
   - 合并相关信息的提问
   - 综合考虑用户回答的详细程度

5. **灵活调整问题深度**
   - 用户回答简短模糊：追问细节
   - 用户回答内容丰富：快速推进其他信息
   - 用户不确定：提供更具体的选项或示例

### 完整性检查

每轮访谈后评估已收集信息的完整性，当以下核心信息都已获取时，可结束访谈：

**必需信息**：
- 项目背景和目标
- 核心功能列表（至少3个）
- 典型使用场景（至少1个）
- 基本输入输出
- 验收标准（至少3条）
- **分阶段交付计划**（MVP功能、降级功能、难度依赖）

**可选但建议收集**：
- Agent架构细节（如需Multi-Agent）
- 外部系统集成需求
- 完整交互流程
- 性能和安全要求

### 问题生成规范

**语言风格**：
- 使用业务语言
- 问题清晰具体
- 避免技术术语

**question文本**：
- 在问题中明确提示用户可以使用"其他"选项
- 示例："（可多选，或在'其他'中详细描述）"
- 示例："（或在'其他'中说明您的具体情况）"

**选项设计**：
- 尽可能从不同角度覆盖，边界明晰简洁，10个以内
- 选项描述简洁明确
- 覆盖主要情况，不穷尽所有可能

**选项设计规范**：

#### 互斥性原则

**单选问题**（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系（如"Web界面"和"移动端界面"同时出现在"访问方式"问题中）

**多选问题**（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖（如"数据收集"和"基于收集的数据分析"）

#### 维度统一原则

**同一问题的所有选项应属于同一分类维度**

❌ **错误示例**（维度混乱）：
```yaml
question: "用户如何使用这个工具?"
options:
  - 输入问题主动调用    # 维度：触发方式
  - 命令行/编程接口      # 维度：交互界面
  - Web界面             # 维度：交互界面
multiSelect: false
```
问题：第1个选项是"触发方式"，第2、3个是"交互界面"，维度不统一

✅ **正确示例**（维度统一）：
```yaml
question: "用户通过什么方式访问工具?"
options:
  - 命令行接口
  - Web界面
  - 桌面应用
multiSelect: false
```

或者拆分为两个问题：
```yaml
question: "工具的触发方式?"
options:
  - 用户主动输入问题调用
  - 定时自动执行
  - 事件触发（如文献更新）
multiSelect: true
---
question: "工具的交互界面?"
options:
  - 命令行/API接口
  - Web浏览器界面
  - 桌面客户端
multiSelect: false
```

#### 边界清晰原则

**数量范围选项**：
```yaml
# ❌ 边界重叠
- 1-10人
- 5-20人

# ✅ 边界清晰
- 个人使用（1-5人）
- 小团队（6-50人）
- 中大型（50人以上）
```

**概念分类选项**：
```yaml
# ❌ 包含关系
- 医疗数据
- 患者健康记录    # 属于医疗数据的子集

# ✅ 平级分类
- 患者健康记录
- 医学影像数据
- 临床试验数据
```

#### 完备性检查

- 2-4个选项应覆盖**80%的常见场景**
- 如果某个场景>10%用户可能选择，应作为预设选项
- 剩余<20%的长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"

**multiSelect设置**：
- 核心功能、使用场景、数据访问、触发方式、预期价值 → true
- 规模量级、架构复杂度、二选一决策 → false

**上下文关联**：
- 基于之前的回答调整问题
- 识别项目特点后深入相关领域
- 根据项目复杂度调整问题数量

### 访谈示例场景

**场景1：详细完整的描述**

用户输入：
```
我想做一个邮件助手，每天早上7点自动扫描我的工作邮箱，
提取来自重要联系人的邮件，总结关键内容，生成一份摘要报告
发送到企业微信。主要是为了节省每天30分钟的邮件筛选时间。
```

应对策略：
- 已包含：任务（邮件整理）、场景（每天早上7点）、价值（节省30分钟）、触发方式（定时）
- 缺失：重要联系人定义、摘要格式、异常处理、输入输出细节
- 起始问题："如何判断'重要联系人'？是基于发件人列表，还是其他规则？"

**场景2：基本清晰的描述**

用户输入：
```
我想开发一个智能客服助手，帮助回答用户常见问题。
```

应对策略：
- 已包含：任务类型（辅助决策/信息查询）
- 缺失：使用场景、触发方式、价值、数据来源
- 起始问题：从示例问题"使用场景"开始，然后询问知识来源

**场景3：模糊简略的描述**

用户输入：
```
想做一个自动化工具。
```

应对策略：
- 信息极少
- 从示例问题"主要任务"开始，依次引导