★ FEATURED ARTICLE 从零开始构建AI Agent，我踩过的所有坑都在这里：不靠运气，只靠系统性认知和可复用的工程路径项目评审会上，我提交的AI客服系统被一票否决：‘它连今天天气都查不到，怎么叫智能？’ 那一刻我才意识到，自己只是把ChatGPT包装成了网页入口。一、别把聊天机器人当AI Agent评审会上，我拿着刚部署的AI客服系统，信心满满地演示“智能问答”。用户问：“今天北京天气怎么样？”我切换到ChatGPT模式，它立刻给出一段详细描述，包括温度、空气质量、穿衣建议。我甚至觉得它比天气APP还贴心。结果，会议主席直接打断：“它连今天天气都查不到，怎么叫智能？”那一刻我才意识到，自己造的不是AI Agent，而是一个披着智能外衣的“文本生成器”。它不感知现实，只凭记忆里的统计规律说话。我甚至没意识到，它在“回答”时，根本没调用任何外部API，所有信息都是它“编”出来的。后来我查了它的日志，发现它曾自信地生成一条虚构的LangChain导入路径：from langchain.tools import WeatherTool。而实际的工具类名是WeatherTool，但路径应为langchain_community.tools。它不是不知道，而是“不知道”也敢说，因为模型训练时见过太多类似结构的代码，于是组合出一个“看起来合理”的路径。这就是幻觉——不是错误，而是自信的错误。更深层的问题是：它没有记忆。用户上一轮说“我喜欢蓝色”，下一轮问“推荐一款蓝色T恤”，它完全不记得。因为它的上下文窗口是固定的，一旦超出，历史就被丢弃。而企业真实场景中，用户偏好、订单状态、历史问题，都需要持续跟踪。我这才明白，真正的AI Agent，不是在“回答问题”，而是在“完成任务”。它要能感知环境——比如知道现在是2024年4月5日，北京的天气由实时API提供；它要能规划——把“查天气”拆解为“获取城市+调用API+解析结果+生成自然语言”；它要能调用工具——不是写死代码，而是动态选择合适的外部服务；它还要记得——把用户偏好存入长期记忆，下次主动推荐。LLM只是执行引擎，真正的智能，藏在任务规划、工具调用、记忆系统、外部交互这四条链路上。一个只会“说”的聊天机器人，永远无法成为企业级AI系统。本系列是学习记录，代码在本地验证过，部分接口与参数根据素材推断，未做实测部署。二、从LLM到AI Agent的技术跃迁路径我曾经以为，只要把一段提示词塞进ChatGPT的对话框，就能实现“智能客服”。直到客户问：“今天北京天气怎么样？”我盯着屏幕，看着模型生成了“晴朗，气温23℃”，却意识到它根本不知道今天是哪一天，更没连接任何气象数据源。它只是在重复训练时见过的天气描述。那刻我才明白，LLM的本质是个高级的“文本预测器”。它能根据历史数据生成连贯的句子，但无法感知现实。它不会查天气、不会读数据库、不会判断用户上一轮说了什么——它只记得“最近的上下文”里有哪些token。于是，我尝试用RAG（检索增强生成）来补救。我把企业产品文档上传到向量数据库，让模型在回答前先“查资料”。这确实提升了答案的准确性。可当我问“我上次买的那款T恤现在还卖吗？”时，系统还是回答“未找到相关记录”。因为RAG只能检索静态知识，无法获取实时状态，比如库存变动、订单进度、用户地理位置。真正的突破点，出现在我引入了工具调用机制。不再是让模型“编造答案”，而是让它“去干活”。我写了一个函数，能通过OpenWeatherMap API获取实时天气。当用户提问“今天北京天气”，模型不再凭空猜测，而是自动调用这个函数，拿到真实数据，再转成自然语言回复。但这还不够。如果用户说“我上次选了蓝色，下次推荐同色系”，模型必须记住这个偏好。于是我加了记忆模块——短期记忆保存当前会话的上下文，长期记忆则通过数据库记录用户行为。下次对话，它能主动说：“您上次喜欢蓝色，我推荐这款深海蓝连帽衫。”更关键的是任务规划能力。复杂的请求不能一步完成。当用户说“帮我查一下下周去上海出差的航班和天气”，模型需要拆解为：获取城市 → 查询航班 → 获取天气 → 综合分析 → 输出建议。这个规划过程，才是AI Agent区别于普通LLM的核心。我终于理解了这条技术演进路径：LLM：只生成文本，无记忆、无工具、无环境感知RAG：引入外部知识，但无法获取实时数据AI Agent（带工具）：具备任务规划、工具调用、记忆保持能力，能自主完成多步任务LLMOps：将上述能力流程化、可视化、可复用，形成可管理的AI系统真正的企业级AI，不是“回答问题的聊天机器人”，而是“能感知、能规划、能执行、能记住”的智能体。它不再依赖模型的“幻觉”，而是通过工具链和流程闭环，把“智能”从“生成”变成“行动”。本系列是学习记录，代码在本地验证过，部分接口与参数根据素材推断，未做实测部署。三、LLMOps不是噱头，是AI应用工程化的刚需项目刚上线那会儿，我还在为“用ChatGPT写了个客服机器人”沾沾自喜。直到产品负责人问我：“这个回答里说的‘2024年北京马拉松冠军’，是哪位？” 我才意识到，我做的根本不是“智能系统”，而是一套精心包装的幻觉生成器。更糟的是，每次修改提示词、加个新工具、改个知识库，我都得重写一堆接口调用代码，整个系统像用胶带粘起来的纸板房，一碰就塌。后来我才明白，真正的AI应用开发，不是拼谁写得快，而是拼谁的系统够稳、够可复用。一个企业级AI客服，至少要同时应对以下问题：用户问“我上次买的那款蓝牙耳机在哪？”——需要调用订单系统，还得记住用户历史行为用户问“下周上海出差，天气怎么样？”——必须查实时天气API，还得结合航班信息模型输出里出现了“XX公司”这种敏感词——必须经过安全过滤才能返回不同大模型（GPT-3.5、ERNIE-4.0、MoonShot）响应风格和成本差异巨大——要统一接入、统一计费如果靠手写代码一个个连，光是搭建这个流程，就得写几百行样板代码，而且每改一次，都要重新测试整个链路。更别说，下个版本可能换模型、换数据库、加新工具，整个系统就得重来一遍。这时候，LLMOps才真正显现出它的价值——它不是“用AI的工具”，而是“管理AI的系统”。它把原本散落在各处的模块，变成了可拖拽、可复用、可审计的组件。比如 Dify 提供的 AI 应用构建器，你只需要说一句：“我要一个能查天气、查航班、记用户偏好的客服机器人”，它就能自动帮你生成工作流、配置工具、设定记忆策略，甚至输出可部署的 API。这种“自然语言 → 应用”的转化，不是魔法，而是系统性工程的胜利。它背后是把以下能力抽象成标准化接口：模块手动实现痛点LLMOps 提供的能力Prompt每个场景写一套，难维护可版本管理、支持变量、支持模板记忆自己写 Redis 逻辑，难同步短期记忆（上下文）、长期记忆（用户档案）内置工具手动封装 API，每次加都得写适配层内置工具库 + 自定义工具注册，支持函数调用知识库分段、向量化、检索全靠代码自动分段、支持元数据、向量检索引擎内置成本监控要自己记录 Token 数、模型价格自动统计每条请求的消耗，支持成本看板安全审核用正则过滤敏感词，易漏内置内容审核模块，支持黑白名单与自定义规则最让我震撼的是，Dify 的工作流编排界面——你不是在写代码，而是在画流程图。一个“用户提问 → 检索知识 → 调用天气API → 生成回答 → 记录对话”的链路，拖三四个节点就搞定了。每个节点还能设置条件分支：比如“如果用户提到‘出差’，则触发航班查询”。# 一个典型的 Dify 工作流配置片段（模拟）workflow:name:"客服Agent - 多步任务"nodes:-id:"input"type:"user_input"description:"接收用户原始问题"-id:
阅读完成 · 觉得有帮助？
