394 lines
11 KiB
Markdown
394 lines
11 KiB
Markdown
|
---
|
|||
|
|
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：模糊简略的描述**
|
|||
|
|
|
|||
|
|
用户输入：
|
|||
|
|
```
|
|||
|
|
想做一个自动化工具。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
应对策略：
|
|||
|
|
- 信息极少
|
|||
|
|
- 从示例问题"主要任务"开始，依次引导
|