基于LLM开发Agent应用开发问题总结
基本概念介绍
本文所讲Agent指，这类能自主规划、调用工具实现目标的智能体应用。分单Agent及多Agent架构。
- 单 Agent：一个智能体集成感知、规划、执行与记忆，闭环完成任务。
- 多 Agent：多个分工智能体通过通信协作，共同完成复杂任务。
常见问题与应对策略
1.未结合实际问题选择合适的架构
问题描述：前期未按复杂度、性能、工具依赖选好单/多 Agent 架构，导致后期维护贵、扩展难。
多 Agent 场景下，把意图理解当成单轮分类，忽略多轮、多层语义，结果意图分发失准，补救成本高。
策略1：根据场景选择合适的Agent架构
| 维度 | 单Agent | 多Agent |
|---|---|---|
| 任务目标 | 单一明确 | 多目标、跨领域 |
| 工具数量 | 少（<5–10个） | 多，需解耦管理 |
| 流程特征 | 固定、线性 | 动态、分支多 |
| 典型场景 | 问答 | 多场景下的问题分析 |
- 架构设计原则：分治 + 高内聚低耦合
- 核心思想：分而治之，避免“超级Agent”
- 设计目标：每个Agent职责单一、边界清晰，模块间低耦合，便于独立迭代与扩展
策略2：权衡协同机制：中心化 vs. 去中心化
| 模式 | 优点 | 风险 |
|---|---|---|
| 中心化 | 全局可控、易协调、趋优解 | 单点瓶颈、扩展性差 |
| 去中心化 | 灵活、鲁棒、可并行 | 通信开销大、局部决策质量决定整体效果 |
策略3: 选择意图理解模式
- 关键任务：
- 明确意图全集（主意图 + 子意图）
- 定义公共参数（如用户ID、地理位置、订单号）
- 划定主子Agent意图边界，避免理解冲突或重复识别
- 设计建议：
- 意图识别 ≠ 单轮分类，需支持多轮语境与层级语义
- 提前建立意图-Agent映射表，作为分发依据
总结
“先评估复杂度，再选架构；多Agent务必分治清晰、意图前置、协同有策，否则后期补救成本极高。”
2. 过度依赖对话交互UI增加用户交互复杂度
问题描述：纯LUI（语音/自然语言）效率低，不适合高频、高精度操作。纯GUI缺乏灵活性，难以应对长尾需求。
策略: 让用户用最自然的方式完成任务，而非证明技术多先进
-
混合界面：GUI承载确定性操作，LUI处理模糊需求，两者可无缝切换
例：订单查询先点选时间范围（GUI），再补充"只看已发货的"（LUI） -
模块化架构：把流程拆成可独立替换的组件，业务变更时只需调整局部
-
灰度预埋：设计时预留"隐藏入口"，支持新功能渐进式曝光
-
核心操作固定，边缘功能用LUI兜底
例：机票预订的"选座"用可视化界面，"申请靠过道"可用自然语言
3.将AI与业务系统强行结合
问题描述： 把 AI 当“插件”直接塞进老系统，流程、交互、数据接口原封不动，只想让 AI 替人跑一遍原有步骤。
策略: 基于AI重构流程
- 避免依赖固有路径，为了强行与原有模式结合，会导致整个过程的复杂度增高，降低投产比。此时可以考虑基于新的模式重构流程。
4.盲目使用高级模式
问题描述：盲目使用ReAct模式、多Agent架构。没有充分考虑业务场景。使得明确、具体的简单任务调用次数过多、耗时过长，严重影响用户体验。
策略1: 选择实现方案时，考虑性能体验问题。明确交互产品应满足的性能需求。最终选择合适的实现方案。Workflow、Plan-and-Execute、thinking模式、ReAct模式。
5.入口意图理解上下文信息不足导致结果错误
问题描述：在Agent入口一次性完成图分类。当初始环境下信息不足，导致最初的意图识别时，会早上整个流程错误。
策略 当缺乏足够的信息，在初始条件决策模糊存在多种可能性时，避免在入口做意图分类。可以在所有上下文信息充分收集后，完成计算后，告诉模型可能的选项，让模型在后置的流程中基于用户根据最全面的上下文信息自主选择最合适决策。当然这种方式也存在问题，回溯流程导致资源消耗增大，结合实际情况综合考虑使用。
6.工具描述模糊模型识别工具准确率低
问题描述：提供给大模型的工具定义（包括名称、描述、参数说明）模糊、不准确或有歧义，导致模型在需要调用工具时，无法精准理解每个工具的用途，出现选错工具、传错参数、重复调用工具，导致最终错误。
策略1:
- 编写清晰的说明：描述必须清晰、准确、无歧义，用准确的语言告诉模型“这个工具是做什么的”、“什么时候应该用它”、“需要哪些参数，每个参数是什么意思”。其实提供准确的示例。
- 明确工具职责：确保每个工具的功能是单一且明确的，避免出现功能重叠和语义模糊。工具之功能互不交叉。