本文分享企业团队开发基于大语言模型的智能客服系统时遇到的五大常见错误：过度设计多Agent架构、不必要地将工具交给Agent、使用JSON而非Tool获取参数、让大模型输出前端组件，以及对开发细节考虑不足。问题根源在于对Agent和LLM理解不足，作者强调非必要不用多Agent，确定性功能应在代码中直接调用，需要决策的功能才用Tool，并提供了学习资源和开发原则。

---

随着大语言模型（LLM）技术的快速发展，越来越多的应用开发工程师开始尝试转型进入AI Agent开发领域。然而，这个转型过程充满挑战：从指令式编程到上下文工程的思维转变、从确定性逻辑到概率性输出的适应、从传统架构设计到Agent系统设计的重新认知。我们团队也是一样，最近在开发“智能客服Agent”这个项目，也遇到了一些问题。可以说这些问题都是Agent开发新手的常见误区。

作为一个典型的企业应用开发团队，我们采用Java后端和React前端的技术栈，最近在着手开发一个基于大语言模型的智能客服系统。这个系统的核心是一个智能客服Agent，它能够理解用户的自然语言输入，智能地调用后端服务获取所需信息，并以自然、友好的方式与用户进行对话交互。为了确保系统的可靠性和安全性，我们在关键操作环节引入了人工确认机制，让用户能够审核和干预AI的决策。考虑到与现有Java生态的无缝集成以及生产环境的高并发需求，我们选择了langgraph4j作为智能体编排和模型管理的核心框架。这个选择让我们能够在保持系统稳定性和可扩展性的同时，充分发挥大语言模型的智能化能力，同时通过人机协作确保服务质量。

由于我们开发团队是第一次尝试开发智能体，所以在开发中犯了一些“显而易见”的错误，非常具有代表性，总结一下，以帮助团队成员避免类似错误。

常见错误

1. 1. 在Agent架构上欠缺考虑，引进太多Agent，应该要考虑好把多个Agent合并成一个。（其实是单Agent还是多Agent问题的低级版本）

我们团队在一开始设计的时候，考虑了未来的扩展性，引进了多Agent架构。这个多Agent架构，包括意图识别Agent、订单查询Agent、回复话术生成Agent、任务生成Agent等，并通过意图识别Agent进行路由分发。

这个设计给团队带了很多的问题：

• 意图识别不准，就会导致后面的执行出错。由于意图识别和其他Agent是独立的，就无法利用Agent的自纠错机制，也就说在错误调用某个工具失败后，Agent在读到错误信息后，可以根据错误反馈来做出正确的决策。而这里的多Agent设计就无法利用这一点。另外，我们的几个Agent本来就是一个业务流程的多个步骤，需要靠流程进度来确定下一步做什么，而不是定义清晰的多个Agent，这就导致我们一直在调整意图识别模块的提示词，一直无法达到很好的效果。

• 多个Agent还要管理多个system prompt。一方面，每个Agent都有单独的一个系统提示词，这样维护起来就很麻烦；另一方面，还有一个symstem message放置位置的为题。在切换到另一个Agent时，当前Agent的system message是放在最开始的地方，还是当前Agent的其实位置呢？这个很微妙，不同的大模型可能处理顺序不一样，我们使用Kimi-K2的时候，发现放在不同的位置，效果完全不一样，这个后面还要讲到。

• 在多Agent中，不同Agent产生的历史记录，可能会相互影响，需要正确低保留和舍弃，或者总结。比如，Agent A具有tool1，当你切换到不具有tool1 的Agent B的时候，它看到有调用tool1的历史记录，它会有什么反应呢？

• 最后，还有一个资源浪费和时间延迟的问题，因为用户的每一次输入都要调用一次意图识别，这会额外占用时间。这在像Deep Research这样的一次任务需要运行几分钟的任务来说，这个时间可能不是问题，但是在我们的场景中，需要经过多次交互来明确任务内容的，影响就比较大了。

2. 有些工具在代码中直接调用即可，却配置给Agent，并告诉Agent按提示词规定的流程调用。（其实是用workflow还是Agent问题的低级版本。）

我们团队在刚开始开发的时候，把一些验证参数的函数也提供给Agent，告诉Agent按提示词规定的流程调用，这是完全没有必要的，比如以下一段提示词（这里做了简化）

### 核心处理流程 
####（1）调用`checkOrderStatus`工具校验订单状态。 
####（2）当订单状态异常时，你需要引导用户提供更多信息。 
####（3）调用`getProcessingRule`工具获取处理规则。 
####（4）调用`generateResponse`工具生成回复内容...

像checkOrderStatus这样的函数，我们在拿到订单号后，直接调用即可，不需要让Agent去调用。如果调用失败，返回失败信息给Agent，让Agent自己去处理就可以了。提供给Agent的工具应该是需要大模型去做决策的。

上面的提示词还有问题，就是提示词写得比较偏向工作流而不是Agent。可以把Agent想象成一个“大厨”，你只要告诉它目标，并为他准备必要的“食材”和“器具”，其他的让他自己去完成。

3. 倾向于使用json等结构化输出或者调用大模型来获取入参，而不是使用Tool工具

这个对于老手来说，可能觉得有点好笑，但是对于新手来说，确实比较符合他们的思维习惯。你要获取订单号，那我就让大模型输出来，我再去解析；或者，我直接调用大模型，让大模型从上下文对话中获取。

这种方法当然不是不行，而是不够优雅。大模型的输出，一方面要在前端展示给用户看，一方面工程师希望利用它来获取信息。给用户看得信息，应该自然，简洁；而给工程师看的信息，应该是结构化的，方便解析。这两者本质上就是矛盾的，导致我们看Agent的输出就很奇怪，像是一个工具，而不是一个聪明的助手。

另外，让大模型通过上下文获取入参，而不是使用Tool工具，这增加了调用量，增加了时间。

而Tool工具，本来就是大模型厂商用来解决这些问题而设计的。他们在训练模型的时候已经把模型调用考虑进去了，因此，直接使用Tool工具更准确，也更有啊。

4. 和前端约定的某些展示组件，由大模型输出，而不是直接返回。由于大模型的输出会存在不确定性，导致前端展示的组件时而可以，时而不行。

由于我们在流程中引入了人工确认环节，因此必须输出工具执行结果和一些按钮，让用户能够确认和干预。团队在一开始的时候，在思维中任务前端的输出应该都由大模型输出。因此有了一下的提示词：

输出调用queryOrder后返回的完整内容

他们期望的是大模型能原封不动地返回工具调用的结果，而结果是这样的：

{   "apiKey": "queryOrder",  
    "apiParams": { "orderId": "ORD123456" },  
    "apiResult": { "status": "processing", "items": [] } 
}

我们知道，LLM输出具有幻觉，随时可能因为多一个逗号、拼错一个字段名，而导致输出错误，导致前端重要的组件没有展示出来。这时候应该利用中断，直接将工具的返回结果输出到前端。

5. 其他的细节

在开发的过程中，还有一些细节值得注意：

• 日志的输出，特别注意要输出最终调用大模型api的请求body，因为不管框架怎么封装，最终传给大模型的body才是我们需要的，这样我们可以查看上下文构造是否正确、工具是否按照我们的预期给到大模型、以及system prompt是否正确。

• system prompt的位置也很重要，当然这个可能因模型而已。我们在切换到Kimi-k2后，发现效果一直很不好，和我们在其他地方测试的感觉完全不一样，后面排查发现是没有把system prompt放在最前面。（而对于claude soonet 4，则完全没有这个问题）

• 对于工具的命名和描述，描述大家比较好理解，对于命名，一开始大家比较随意，以为只有描述影响大模型的输出。由于大模型是基于语义理解的，因此，函数的名字意义也会影响到大模型。这让我想起了一个游戏：一个红笔写的“蓝”字，一个用蓝笔写的”红”字，然后出示文字，让你说是用什么颜色涂的。想必做过游戏的同学们能够理解这个类比。

• 让人工确认的语句应加入LLM上下文。比如我们得到了一个订单查询结果，虽然我们在拿到结果的时候，就通过中断返回到前端，让用户确认。在前端中，用户看到确认按钮，就知道你的意思。但是此时大模型是没有这个语句的，因此我们应该在上下文中加入一句role为assistant的句子：请确认结果是否准确？这样，可以让上下文语义更加连贯。

• 我们在设计的时候，前端没有输出工具调用名称和参数，以及工具调用的原始结果。这个不好，对于工程师，缺少了调试信息。对于某些了解Agent的用户，他想要通过你调用的工具和入参以及原始结果，来看下大模型的调用是否准确。这是增加用户信任的一部分，因此最后在前端以折叠的形式包含工具调用名称、参数和结果。

• 对模型调用工具前的输出限制太多，在最开始设计的时候，我们通过提示词约束模型在调用工具前输出的格式，比如总结查询条件，分析用户意图。后面发现，这样会太死板，第一次调用还可以，如果在一个任务中，多次调用到该工具，而每次调用都输出差不多的内容，就会感觉很机械，因此，后面就直接提示大模型在调用工具前说明理由即可。

问题根源

究其原因，主要还是我们开发团队初次接触Agent，对Agent和LLM的理解不够导致的，比如：

1. 对Tool的理解不够，不知道Tool的入参是可以可以直接用LLM根据上下文获取的

2. 对大模型的不确定性没有足够的考虑，能确定执行的事情不要依赖大模型

3. 对Agent的理解停留在工作流场景，应该要设想大模型能够调灵活调用你给的工具，而不是按照你给的提示词严格执行。

这些问题算是初级错误吧，通过一次实战，基本上都能解决。当然，这只是开始，后面还有规划、记忆、长上下文管理、知识库、多智能体架构等等。

AI时代，未来的就业机会在哪里？

答案就藏在大模型的浪潮里。从ChatGPT、DeepSeek等日常工具，到自然语言处理、计算机视觉、多模态等核心领域，技术普惠化、应用垂直化与生态开源化正催生Prompt工程师、自然语言处理、计算机视觉工程师、大模型算法工程师、AI应用产品经理等AI岗位。

掌握大模型技能，就是把握高薪未来。

那么，普通人如何抓住大模型风口？

AI技术的普及对个人能力提出了新的要求，在AI时代，持续学习和适应新技术变得尤为重要。无论是企业还是个人，都需要不断更新知识体系，提升与AI协作的能力，以适应不断变化的工作环境。

因此，这里给大家整理了一份《2025最新大模型全套学习资源》，包括2025最新大模型学习路线、大模型书籍、视频教程、项目实战、最新行业报告、面试题等，带你从零基础入门到精通，快速掌握大模型技术！

由于篇幅有限，有需要的小伙伴可以扫码获取！

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

5. 大模型行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

为什么大家都在学AI大模型？

随着AI技术的发展，企业对人才的需求从“单一技术”转向 “AI+行业”双背景。企业对人才的需求从“单一技术”转向 “AI+行业”双背景。金融+AI、制造+AI、医疗+AI等跨界岗位薪资涨幅达30%-50%。

同时很多人面临优化裁员，近期科技巨头英特尔裁员2万人，传统岗位不断缩减，因此转行AI势在必行！

这些资料有用吗？

这份资料由我们和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

大模型全套学习资料已整理打包，有需要的小伙伴可以微信扫描下方CSDN官方认证二维码，免费领取【保证100%免费】