我们都知道，大模型如同强大的“最强大脑”，而AI-Agent则像是赋予这个大脑“真身”的关键所在。在过去的大半年里，我深入研究了众多AI-Agent框架，在这个过程中积累了不少开发技巧、思路以及架构方面的思考。例如，怎样和大型语言模型（LLM）进行更高效的交互？如何优化提示词（prompt）并合理控制令牌（token）数量？又怎样让LLM更快地给出我们期望的结果？下面，就围绕这些问题展开探讨。

一、化繁为简：拆解复杂逻辑是关键

大家还记得刚开始写代码的时候吗？那时，可能会把所有逻辑一股脑地塞进一个长达上百行的main方法里。结果代码不仅难以阅读，调试的时候更是让人头疼，自己都搞不清写的是什么。从那时候起，我们就明白一个道理：复杂的代码逻辑要拆分成一个个小部分，将代码按功能划分成不同的方法、类和模块，这样代码的可读性、可维护性都会大大提高，调试和测试也会变得轻松许多。

在AI-Agent开发中，这个道理同样重要，甚至更为关键。虽然大模型功能强大，但要是我们不能合理利用，反而会事与愿违。有些开发者认为，LLM这么智能，那就把所有可能的指令都写进系统提示词（System Prompt）里，让它自己处理各种情况。但实际效果却不尽人意，模型会变得混乱，该执行的指令不执行，不该执行的却执行了，输出的结果常常让人摸不着头脑。

为什么会出现这种情况呢？当系统提示词里的内容过多时，会引发一系列问题：

  • 信息过载：模型要处理的信息太多，很可能会忽略一些指令。
  • 指令冲突：不同指令之间可能相互矛盾，模型无法判断执行的先后顺序。
  • 上下文混乱：提示词过长，模型容易混淆指令间的关系，理解上出现偏差。
  • 令牌限制：过长的提示词会占用大量令牌，增加使用成本，还会延长响应时间。

打个比方，你拿着一张写满各种商品的购物清单去超市采购，清单上还有各种修改和补充说明，比如“牛奶（脱脂，没有就买全脂）”“鸡蛋（有机的，12个装，有促销就买24个）”“面包（全麦，别买白面包，除非打折）” ，是不是看得眼花缭乱，稍不注意就可能买错东西？模型在面对繁杂的提示词时也是如此，它可能会忽略重要指令，误解指令含义，或者因为不知道该遵循哪个指令而导致输出混乱。

（一）实际案例分析

以开发智能客服机器人为例，一位开发者想让机器人能处理各种用户需求，于是在系统提示词里写了很多指令：“你是一个客服机器人，需要以友好和专业的态度与用户交流。首先，向用户问好。如果用户提出技术问题，提供详细的解决方案。如果用户抱怨，请安抚他们的情绪，并提供折扣券。如果用户询问商品信息，提供最新的商品详情和价格。如果用户要求与人工客服对话，礼貌地询问他们的具体需求，并尝试解决问题。所有回应必须简洁明了，同时体现个性化和温暖。”

这个提示词看似考虑周全，但实际使用时却问题重重。比如，模型可能无法准确判断用户是在抱怨还是询问产品信息，导致回应不准确；由于指令太多，关键的服务流程也可能被忽略。

（二）有效的解决方案

针对上述问题，有以下几个解决办法：

  • 简化系统提示词：只需要清晰描述模型的基本角色和行为，避免过多细节。比如“你是一个客服机器人，负责帮助用户解决问题，以专业和友好的态度与用户交流。”
  • 动态添加指令：以langchain4J框架为例，可以通过封装多个AI Service来实现不同指令，再利用业务编排框架（如liteflow）将这些模块串并联，满足整体业务需求。例如，根据不同用户情况添加相应指令：检测到用户抱怨或情绪激动时，添加安抚情绪的指令；用户提出技术问题，添加提供解决方案的指令；用户询问商品信息，添加提供商品详情的指令。
  • 引入中间层：在这种业务场景下，引入意图识别模块作为中间层很有必要。先对用户输入进行分析，再根据分析结果决定模型执行的操作。下面这段代码就是封装了一个用户意图识别的AI Service，让大模型先判断客户意图，再决定执行哪个指令。
public enum UserIntentEnum { @Description("问候语, 例如:你好|您好|嗨|早上好|晚上好") GREETING, @Description("技术问题, 例如:技术问题|无法使用|出错|故障") TECHNICAL_ISSUE, @Description("客户抱怨评价, 例如:差评|不好用|生气|投诉|抱怨") COMPLAINT, @Description("客户商品咨询, 例如:价格|多少钱|商品信息|详情") PRODUCT_INQUIRY, @Description("客户想转人工, 例如:人工客服|真人") REQUEST_HUMAN } interface UserIntent { @UserMessage("Analyze the priority of the following issue? Text: {{it}}") UserIntentEnum analyzeUserIntent(String text); }

其实这种实现方式，就是prompt开发中常提到的思维链/思维树架构模式。

二、合理使用工具和上下文：并非越多越好

在构建智能对话系统时，很多开发者觉得给模型提供的工具和上下文越多，模型表现就会越好。但事实并非如此，过多的工具和上下文不仅不能提升模型性能，还会带来一系列问题，比如成本大幅增加、响应速度变慢，甚至会让模型产生幻觉（hallucination） 。所以，我们要理性对待工具和上下文的使用，避免陷入“越多越好”的误区。

（一）Function Call工具：避免模型“消化不良”

现代LLM的函数调用（Function Call）功能非常强大，借助它，我们可以在聊天机器人中集成各种工具，像调用外部API、进行数据库查询、使用计算器等，从而实现复杂任务的处理。这一功能让很多开发者兴奋不已，有人就想“工具这么多，都给模型用上吧”。但这种做法会让模型“消化不良” ，引发不少问题：

  • 成本飙升：每增加一个工具，对话的复杂程度就会上升。模型生成回复时要考虑更多可能性，这会消耗更多计算资源和令牌，直接导致使用成本增加。
  • 模型产生幻觉：工具过多时，模型可能无法准确判断何时调用哪个工具，就会在不恰当的时候调用错误的工具。
  • 用户体验受损：模型的不当行为会让用户感到困惑和不满，影响产品的整体口碑。

举个例子，用户只是简单对聊天机器人说“你好” ，正常情况下机器人回一句问候就行。但如果模型被赋予过多工具，它可能会过度解读用户意图，去调用数据库查询、访问外部API，甚至帮用户订外卖。这样的响应既浪费系统资源，还可能泄露用户数据，引发安全问题。

针对这些问题，有以下解决方案：

  • 精选工具：根据当前场景的实际需求，挑选真正必要的工具提供给模型。
  • 意图识别：在模型调用工具前，先进行用户意图识别，只有在确实需要时才调用相关工具。
  • 设置调用条件：为工具的调用设定严格的条件和限制，防止模型随意使用工具。

（二）RAG技术：合理管理上下文

RAG技术能让模型依据提供的上下文给出更准确的回答，在需要提供具体信息和背景知识的场景中非常实用。不过，过度提供上下文也有负面影响：

  • 令牌消耗巨大：大量上下文意味着更多的令牌消耗，而模型使用成本通常和令牌数量直接相关，所以成本会显著提高。
  • 响应时间延长：模型需要处理的信息变多，响应速度就会变慢，用户等待回复的时间变长。
  • 注意力分散：过多的上下文会让模型难以聚焦最相关的信息，回答的准确性反而降低。
  • 增加错误风险：上下文信息过多，模型容易在无关信息中迷失，生成与用户需求不相符的回答。

比如用户问“你能告诉我今天的天气吗？” ，模型只需提供当前天气信息即可。但要是给模型提供大量气象数据、历史天气记录等上下文，不仅会增加成本，模型给出的回答可能又长又不实用，影响用户体验。

对此，有以下优化策略：

  • 动态上下文管理：根据用户的具体需求，灵活提供最相关的上下文信息，而不是一股脑全给模型。
  • 上下文精简：对提供的上下文进行筛选，只保留和当前对话高度相关的部分。
  • 上下文缓存：在多轮对话中，合理缓存上下文，但要避免其无限增长。
  • 用户引导：设计合理的对话流程，引导用户提供更精确的信息，减少对大段上下文的依赖。

在使用工具和上下文时，关键在于把握好“度”，确保其与实际需求相关。过多的工具和上下文并不能提升模型表现，反而可能起到反作用。我们要以用户需求为出发点，合理配置模型的能力，在满足功能需求的同时控制成本。

三、总结

在大型模型AI-Agent的开发过程中，我们要遵循传统软件开发中模块化、可测试、易维护的原则。不能只依赖模型的强大能力，而忽视架构设计的重要性。将复杂逻辑拆解成小的组件有诸多好处：可以降低成本，减少不必要的模型调用，节省令牌消耗；能够提高性能，缩短响应时间，提升用户体验；还能增强可靠性，模块化设计便于测试和维护，减少错误出现的概率。

希望大家在AI-Agent开发中，既能充分发挥模型的优势，又能掌控好架构。就像俗话说的“不要试图一口吃成个胖子”，AI-Agent也需要我们耐心“调教”。祝愿大家在AI发展的浪潮中能够顺利前行，取得理想的成果。