1、为什么要分等级？

很多 AI 项目一开始就喊 Agent。

但实际做出来，只是一个大模型聊天框。用户问一句，模型答一句。它不会查企业数据，不会调用业务系统，也不会把任务拆开执行。

所以，做 AI 应用前，先别急着选框架。先问一个问题：这个需求到底属于哪一级？

• 只需要解释、总结、写作：Level 0。

• 需要查资料、查知识库、查数据库：Level 1。

• 需要拆任务、调工具、处理中间失败：Level 2。

• 需要多个角色分工协作：Level 3。

图 1：AI 应用从 LLM 问答逐步升级到多智能体系统

2、Level 0：LLM 问答，只有“大脑”

Level 0 最简单。用户输入问题，大模型直接生成答案。

它适合做解释、翻译、摘要、改写、普通内容创作。优点是快，成本低，上手简单。

但它有明显边界：它不知道最新信息，不知道你的企业数据，也不能真正操作外部系统。

核心观点：Level 0 不是没用，而是只适合“纯文本、低风险、无实时数据”的任务。

典型场景

• 技术文章润色。

• 产品文案生成。

• 代码片段解释。

• 会议纪要摘要。

3、Level 1：RAG / 工具连接，让模型会“查资料”

Level 1 开始接触真实世界。

模型不再只靠训练时的知识，而是可以先检索知识库、搜索网页、查询数据库，再基于资料回答。

这就是 RAG 和工具调用的价值：给大模型补外部信息。

典型场景

• 企业知识库问答：先查内部文档，再回答。

• 智能客服：先查订单、物流、退款状态，再回复用户。

• 投研助手：先查公告、新闻、研报摘要，再生成观点。

• 代码问答：先检索代码仓库，再解释具体模块。

核心观点：Level 1 的关键不是“模型更聪明”，而是“资料更准”。

图 2：四种 AI 应用架构的核心差异

4、Level 2：单体 Agent，从“回答”升级到“执行”

Level 2 才真正接近我们常说的 Agent。

它不只是回答问题，而是围绕目标不断循环：理解目标、制定计划、调用工具、观察结果、修正动作。

一个代码 Agent 收到 Bug，不应该只给建议。它应该能读代码、定位文件、修改逻辑、运行测试、根据报错继续修复。

它比 Level 1 多了什么？

• 规划能力：知道先做什么，再做什么。

• 状态管理：知道任务进行到哪一步。

• 工具选择：知道什么时候查库，什么时候调用 API。

• 异常处理：工具失败后能重试、降级或换路径。

• 反思修正：对结果做检查，而不是一次输出就结束。

核心观点：Level 2 的本质：让 AI 从“生成文本”变成“完成任务”。

5、Level 3：多智能体系统，像一个 AI 团队

Level 3 不再追求一个万能 Agent。

它更像一个团队：经理 Agent 负责拆任务和统筹，专家 Agent 分别负责检索、分析、写作、审核、执行。

复杂任务往往不是一个人干完，而是多个角色配合完成。AI 系统也一样。

典型场景

• 自动生成深度研究报告：检索 Agent、分析 Agent、写作 Agent、审核 Agent 协作。

• 复杂客服系统：前台 Agent、订单 Agent、退款 Agent、投诉 Agent 分工。

• AI 编程团队：需求 Agent、代码 Agent、测试 Agent、Review Agent 配合。

• 企业流程自动化：财务、法务、销售、运营多个 Agent 按权限协作。

核心观点：多智能体不是越多越好。角色越多，通信成本、冲突处理、日志追踪也越复杂。

图 3：根据任务复杂度选择 AI 应用等级

6、案例：一个智能客服，四种做法

同样是“智能客服”，不同等级的实现差别很大。

图 4：智能客服从问答机器人升级到多智能体客服团队

Level 0：能聊天，但查不了业务

用户问退款进度，模型只能根据通用话术回答。看起来像客服，实际没接系统。

Level 1：能查知识库和订单

用户问订单状态，系统先调订单接口，再让模型组织语言。回答更准，但流程仍比较固定。

Level 2：能处理完整售后流程

用户说“我东西没收到还扣款了”，Agent 会识别意图，查订单、查物流、查支付，必要时追问或转人工。

Level 3：复杂问题交给专家协作

投诉、退款、物流、风控分别由不同 Agent 处理，经理 Agent 汇总结果。适合大规模客服中心。

7、工程上怎么落地？

真正的 Agent 系统不是一个 Prompt。它是一条执行链。

请求进入系统后，先识别意图和权限，再进入编排层。编排层决定是走 RAG、工具、计划器，还是交给其他 Agent。每一步都要有状态、日志、异常处理和成本记录。

图 5：生产级 Agent 系统的工程分层

8、不要过度设计

很多人做 AI 应用，第一反应就是 LangGraph、多 Agent、MCP、复杂状态机。

但工程上有一个朴素原则：能用简单方案解决，就不要上复杂方案。

图 6：一张图判断该选哪种架构

9、总结

• LLM 是大脑，但不是完整 Agent。

• RAG 解决“知道什么”的问题。

• 工具调用解决“能做什么”的问题。

• 规划和状态解决“怎么持续执行”的问题。

• 多智能体解决“复杂任务如何分工”的问题。

• 架构选择要从业务复杂度出发，不要一开始就堆复杂度。

核心观点：判断一个 AI 应用是否需要 Agent，只看一句话：它是不是要围绕目标，持续调用工具，把任务做完。

下一章预告

下一章讲提示链 Prompt Chaining。它是最基础的 Agent 设计模式。复杂任务不要一口吃，要拆成流水线。