第 1.1.1 节：先说清 AI Agent 解决什么问题

本节围绕“先说清 AI Agent 解决什么问题”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够用一句话说明 AI Agent 的目标、适用场景和不做范围。

本章要解决什么问题

很多人第一次听到 AI Agent（人工智能体）时，会把它理解成“更聪明的聊天机器人”。这个理解不算完全错，但会误导工程设计。

聊天机器人主要负责回答问题。AI Agent 的关键差异在于：它围绕一个目标，在上下文、工具、约束和反馈之间循环决策，直到完成任务或触发失败处理。

本章先建立一个清晰的判断标准：什么时候只是 Chatbot（聊天机器人），什么时候是 Workflow（工作流），什么时候才需要设计成 Agent。

读完本章后，你应该能够：

很多读者已经听过 Agent、RAG（检索增强生成）、Workflow 和 Tool Calling（工具调用），但还没有形成工程判断。真实项目最容易失败的地方不是“模型不会回答”，而是一开始把系统类型判断错了。

如果把普通 FAQ（常见问题）问答做成复杂 Agent，项目会变贵、变慢、难验收。如果把需要查订单、建工单、转人工的业务只做成 Chatbot，用户会得到看似流畅但无法落地的回答。如果把退款、投诉、隐私这类高风险问题完全自动化，系统就可能越权。

所以这一章的价值是建立第一条分界线：什么时候该聊天，什么时候该检索，什么时候该走固定流程，什么时候才值得引入 Agent。 这条分界线会直接影响后面的模型选择、Prompt（提示词）、工具调用、状态设计、日志审计和面试表达。

假设客户说：

读图重点：不要先选框架：资料依据决定是否需要 RAG，动作确定性决定 Workflow 或 Agent，高风险路径始终保留人工责任。

我想做一个 AI（人工智能）客服，用户问什么它都能回答，最好还能自动处理售后。

这句话里面至少混着三类需求：

如果只是回答 FAQ（常见问题），它更像 RAG 问答系统。如果要按规则走固定流程，它更像 Workflow。如果需要根据用户目标、上下文和工具结果动态决定下一步，它才更接近 AI Agent。

岗位面试和客户沟通不会只问“Agent 是什么”。更常见的是用一个模糊需求考你会不会拆边界。

真实问法	背后考点	回答方向
我们要做智能客服，你觉得是 Chatbot、RAG 还是 Agent？	需求判型	先看是否需要企业资料、业务工具、多轮状态和人工兜底，不直接套框架。
用户问退货政策和查订单状态，处理方式一样吗？	知识问答与业务动作边界	退货政策走知识库和引用，订单状态必须走受控工具和权限校验。
为什么不能让 Agent 直接退款？	风险控制	Agent 可以整理材料或发起审批，资金动作需要规则、权限、人工确认和审计。
Workflow 是不是比 Agent 落后？	选型理性	规则稳定时 Workflow 更可控；任务开放、多步骤、需要动态判断时才用 Agent。
你怎么证明自己不是只会调模型？	工程证据	用输入输出、工具边界、状态、日志、失败兜底和验收样例说明系统可交付。

从本章开始，我们把“AI 客服”收束成一个贯穿项目：企业客服知识库与工单 Agent 工作台。

这个项目不是一句“做个客服机器人”就能完成。它至少包含四种能力：

能力	人话解释	在客服工作台中的表现	本书后续章节
Chatbot	能和用户对话	回答普通寒暄、说明服务范围	本章
RAG	从企业资料里找依据再回答	回答退换货规则、产品说明、售后政策	第 2 卷 RAG
Tool Calling	让系统查数据或执行业务动作	查订单、查物流、创建工单	第 1.6 章
Agent 编排	根据目标、状态和结果决定下一步	判断先问订单号、先查政策、还是转人工	第 1.7 章与 LangGraph（智能体状态图框架）

本章不要求读者立刻做完整工作台，而是先学会判断：一个需求到底只是聊天、只是检索、只是流程，还是需要 Agent 系统。

常见误解	卡住的原因	正确理解
只要接了大模型就是 Agent	把生成文本和完成任务混在一起	Agent 必须围绕目标推进任务，并处理工具、状态和边界。
客服项目一开始就做全自动	忽略资金、投诉和隐私风险	高风险动作要审批，低风险问答可以自动化。
RAG 和 Agent 是二选一	把能力层和系统形态混在一起	RAG 可以成为 Agent 的知识来源。
Workflow 不够智能，所以都要换成 Agent	为了追新词牺牲可控性	固定规则清楚时，Workflow 更稳、更便宜、更容易验收。
会聊天就能面试 Agent 岗位	缺少工程证据	面试要讲清输入输出、工具、状态、日志、失败兜底和验收标准。