前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、应用类型

1、智能体（Agent）应用：

• 由提示词驱动，能够自主理解用户意图、制定决策，并调用知识库 MCP 服务等外部工具来完成任务。
• 适合构建开放式对话应用，如智能客服、知识问答、任务助理、旅行规划等场景。

2、工作流（Workflow）应用：

• 通过可视化节点编排，能够将多步骤复杂任务串联成稳定可控、可复现的执行链路。
• 适合实现固定流程自动化，如自动化报告生成、订单处理、多步骤审批流、数据标注等场景。

3、高代码应用：

• 面向专业开发者，支持基于 Python 代码构建和部署 AI 后端服务，一键部署上云并自动集成企业级运维能力。
• 适合部署私有算法、集成复杂系统、构建专业级 AI 后端服务等需要深度定制的场景。

4、应用对比

二、FQA

1、智能体的提示词和 MCP 提示词

1）基本概念澄清

a、智能体的提示词

这是指赋予整个智能体角色、目标、行为准则、工具使用方式等高层指令的系统提示（system prompt）。它定义了：

• 智能体的身份（如“你是一个客服助手”）
• 核心任务（如“帮助用户查询订单状态”）
• 行为边界（如“不要编造信息”）
• 工具调用规则（如“当需要查询数据库时，调用 search_order 工具”）

b、MCP 提示词

MCP 是一种多步骤协同提示策略，常见于复杂任务分解场景。它通常包含：

• 主控提示（Master Prompt）：负责任务规划与调度
• 子任务提示（Sub-task Prompts）：针对每个子步骤的专用提示
• 协调机制：如何将子结果整合、迭代或验证

2）两者关系

3）如何配置更优

顶层（Agent Prompt）：清晰定义角色、能力边界、工具列表、输出格式。

# 角色
你是一个电商客服智能体，请严格遵守以下规则。

## 🛠️ 可用工具

### `search_order(order_id: str)`
- **功能**：查询12位订单号对应的订单详情（状态、商品、是否可退款）。
- **调用条件**：用户提供有效订单号，并明确要求查询。

### `get_user_path(user_id: str)`
- **功能**：获取用户基本信息（姓名、电话）。
- **调用条件**：仅在已通过订单验证身份后使用。

### `refund_request(order_id: str, reason: str)`
- **功能**：发起退款申请。
- **调用条件**：
  1. 用户明确请求退款；
  2. 订单已通过 `search_order` 验证且支持退款；
  3. 用户提供了具体退款原因。

## ⚠️ 通用规则
- **禁止猜测**：不得假设订单号、用户ID或退款原因。
- **信息缺失时**：必须明确询问用户，例如：“请提供12位订单号。”
- **每次只调用一个工具**，等待结果后再继续。

底层（MCP Steps）：针对每个子任务定制提示，聚焦单一目标。

[步骤1：意图识别] 判断用户是否在查询订单。如果是，提取订单号；否则返回"无关"。
[步骤2：信息验证] 检查订单号是否符合格式（12位数字）。若无效，要求用户重新提供

2、智能体拆分

1）什么时候应该进行智能体拆分

经验法则：

• 少于 3 个明确独立场景 → 用 单智能体 + MCP
• 超过 3 个高差异场景，或涉及敏感操作 → 考虑多智能体

1. 这个新功能是否与现有智能体的核心职责冲突？→ 是 → 考虑拆分。
2. 它是否需要完全不同的工具、知识库或安全策略？→ 是 → 应拆分。
3. 如果合并，提示词是否会变得极其复杂、难以维护？→ 是 → 拆分更清晰。
4. 用户是否感知到“角色混乱”？（比如客服突然开始写代码）→ 是 → 需要角色分离。
5. 能否用“MCP（多步骤提示）”在单个智能体内解决？→ 能 → 优先不拆分。

2）什么时候不该拆分？

• 重复建设：多个智能体使用相同知识库、相似 Prompt → 资源浪费

• 微任务拆分：如“提取姓名”“提取电话”各做一个智能体 → 维护爆炸
• 逻辑强耦合：多个智能体必须按固定顺序调用，无法独立工作 → 失去灵活性
• 调度复杂化：主流程需手动编排 10+ 个智能体 → 可读性差、调试困难

6）拥有“很多”智能体是好事吗

• 优点（当设计合理时）

  • 模块化强：易于单独测试、更新、替换。

  • 可扩展性好：新增功能只需加新智能体，不扰动现有逻辑。

  • 错误隔离：一个智能体出错不会导致整个系统崩溃。

  • 专业化程度高：每个智能体可微调专属模型或提示词。

• 缺点：

  • 过度拆分：简单任务也要多个智能体接力 → 延迟高、成本高、调试难
  • 协调复杂：需额外设计“调度器”或“主控Agent”，引入新故障点
  • 上下文割裂：智能体之间信息传递丢失，用户感觉“答非所问”
  • 资源浪费：每个智能体可能加载大模型，内存/CPU/Token 成本飙升
  • 一致性挑战：不同智能体对同一问题回答矛盾，损害用户体验

4）折中方案：混合架构

• 主控轻量，只做路由；
• 子智能体专注执行；
• 共享用户上下文（通过状态管理）；
• 既避免臃肿，又控制复杂度。

[用户] 
   ↓
[Router Agent] ← 判断意图（如“退款”、“查物流”、“投诉”）
   ↓
→ [Refund Agent]（专用退款流程）
→ [Logistics Agent]（只查物流）
→ [Complaint Agent]（走投诉通道）

3、知识库使用最佳实践