★ FEATURED ARTICLE 从去年开始我几乎每周都会被问到同一类问题智能体到底是什么为什么同样的模型别人做出来的“智能体”能稳定干活我的却只能在演示时跑通接触到的“智能体开发”项目越多我越觉得问题根本不在于模型选得多强而在于很多人把智能体理解成了“套了提示词的聊天框”忽略了它真正的核心——一套由多个模块组成的系统。这个系统至少包含核心大脑、规划能力、记忆、工具调用、容错机制这几大块缺一块智能体就会从“能用”变成“碰运气”。这篇文章我就完整拆一遍智能体的组成。不绕弯子直接从实际开发视角讲清楚每个模块为什么存在、怎么选、怎么做再结合我踩过的一些坑说说那些文档里一般不写的细节。无论你是打算做AI智能体开发还是在Dify、Coze这类平台上搭过几个流程但搞不清底层原理这篇文章都应该能帮你把整张图补全。1. 先看全景智能体到底由什么组成1.1 从一个实际需求说起假设你要做一个智能体用户问它“帮我查一下明天上午的天气如果适合户外活动就把闹钟调到7点半并提醒我带伞。”如果你只是给大模型发这句话它大概率会怎么答它不会真的去查天气也不会碰你的闹钟而是“编”一个天气数据然后礼貌地告诉你“建议带伞”。这是模型的本质它只在做文本续写没有查天气的动作没有改闹钟的权限也记不住你之前说过“我一般7点起床”。要让这段对话变成一个真正干活的智能体你需要给它装上一个大脑之外的“身体”一个能根据指令调用天气API的执行器一个能记住用户偏好和当前状态的记忆区还要有一套在API调用失败时知道怎么办的容错逻辑。这些模块组合起来才叫智能体。这也是这篇博文一直强调的智能体不是一个模型而是一套组装系统模型只是其中最核心的一个零件。1.2 六大核心模块一览我把常见智能体方案里反复出现的模块整理成一个清单几乎每个成熟项目都能在这个清单里对号入座模块职责概览常见实现方式核心大脑语义理解、生成回复、决策输出各类LLM如GPT、Claude、Qwen及开源模型规划模块把目标拆成步骤决定下一步做什么ReAct循环、Plan-and-Execute、反思机制记忆系统保存用户偏好、历史对话、任务状态上下文窗口、向量数据库、KV存储工具与外部连接调用API、搜索、计算、操作数据Function Calling、REST接口、代码沙箱反馈与容错检测错误、重试、降级确保输出可靠自检、重试器、降级规则、评测集安全与治理控制权限、过滤有害输出、审计权限校验、输出过滤器、日志系统从这张表能看到真正耗时间的往往不在模型调用而在规划、记忆、工具、容错这几个工程模块上。很多AI智能体应用案例之所以成功不是因为用了某个逆天模型而是这几层做得扎实。1.3 为什么“模型”不等于“智能体”我常用一个类比大模型是发动机智能体是整车。发动机决定了动力上限但一辆车能不能安全上路还要看底盘、转向、刹车和油路。只堆发动机功率车上路一定出事故。智能体开发里最常见的翻车现场就是“模型很强但没有刹车”比如一个客服智能体在用户连续追问三次后开始凭空编造退换货政策这种幻觉靠换更强模型很难根除需要靠容错机制、工具检索和权限边界去约束。理解了这个理念再往下看“智能体由什么组成”就不会觉得枯燥了。接下来我按模块拆开讲先说最核心的大脑。2. 核心大脑LLM并不是插上就能用2.1 主模型与辅助模型的分工很多人觉得LLM智能体就是选一个最强的模型所有任务都扔给它。我早期也这么干后来发现两个问题一是贵二是慢。一次简单意图识别如果每次都走最强模型不光延迟高成本几乎不可控。更合理的做法是把模型分成两层。主模型负责核心推理和生成比如理解一个复杂指令、生成一份方案辅助模型负责轻量任务比如意图分类、关键词抽取、情感判断、判断“这句话要不要调用工具”。在主模型之前加一个小模型的“路由判断”能省下大量不必要的重推理。这个思路在成熟的多模态大模型应用里也很常见图片要不要放大看细节、表格要不要调OCR都是先用轻量判断再决定。选主模型时要考虑场景写代码、分析长文档、做复杂规划需要推理能力强的模型做闲聊、情感陪伴、教育问答需要对话自然和安全对齐好的模型。这里我不绑定具体厂商建议是直接在你的真实任务集上做对比不要只看跑分。2.2 提示词与指令模板把“系统约束”写进生成逻辑主模型装上之后第一件事是设计系统提示词System Prompt。系统提示词就是给智能体写的“操作系统”它约束回答的语气、权限边界、工具使用方法。很多人的提示词只有一句“你是一个AI助手”这等于给了发动机没有方向盘。我一般会给一个三层结构。第一层是角色与目标说清楚“你是一个客服智能体只负责退换货问题”。第二层是规则与边界明确“不知道的信息必须说不知道严禁编造政策”“如果用户问促销价格调用价格查询工具后再回答”。第三层是格式要求比如“输出为JSON包含answer字段和tool_calls字段”。这三层写清楚模型的稳定性立刻上一个台阶。调用参数也要同步控制。temperature在工具调用场景通常调到0或者0.2越高越容易让模型“自由发挥”出错误动作。如果你用的是支持JSON输出模式的接口尽量开启避免模型把JSON格式写得乱七八糟后续解析时崩溃。2.3 上下文窗口与Token预算管理LLM的上下文窗口看似越来越大但要注意塞进去的内容越多模型越容易抓不住重点幻觉率也随之上升。这就是为什么“把全部历史对话都丢给模型”是新手最容易犯的错。我的做法是给上下文划分预算。系统提示词占一个固定比例最近几轮对话占一部分检索到的相关资料占一部分工具返回结果占一部分还要留出生成回复的余量。如果发现超出预算优先压缩的是“历史对话”可以把旧对话折叠成摘要而不是一字不差塞进去。比如用户三天前说过“我住上海”后续只要保留“用户所在城市:上海”这个结论就行不需要保留整段聊天气氛。短期记忆其实并不复杂难的是长期记忆的设计这部分放到下一节讲。3. 规划与记忆让智能体会想也会记3.1 规划模块的常见模式智能体和普通聊天机器人最大的区别就是它会“行动”而行动需要规划。我梳理了三种最常被用到的规划模式ReAct模式模型按“思考-行动-观察”循环执行。第一步根据用户问话思考需要调用什么工具第二步调用工具第三步根据工具结果继续思考是否还要再调。这个过程可以用循环代码控制每一轮把模型输出和工具结果拼接回上下文。Plan-and-Execute模式模型在开始时一次性生成一个完整计划比如“先查库存再算价格再生成推荐”然后后台依次执行。这个模式好处是速度稳定坏处是一旦执行结果和计划假设不符很难中途调整。反思模式模型在给出最终答案前先自己生成一个初稿然后评价这个初稿哪里不好再生成第二版。教育智能体里很常用因为回答错了比回答慢更严重。实际项目里这三个模式经常组合。比如先让主模型用ReAct处理未知问题同时用Plan-and-Execute处理固定流程比如“退换货申请”这种步骤明确的场景。规划模块在代码层面通常只是几个判断和循环难的是如何设计“让模型在什么情况下做出什么规划”的规则。3.2 短期记忆与长期记忆的实现差别记忆模块容易被人忽视但它决定智能体是不是真的“懂你”。短期记忆指当前对话上下文通常由消息列表组成比较容易理解。长期记忆指跨会话保存的信息比如用户偏好、历史订单记录、之前任务的结果等这些一般要写到外部存储里。举个教育情感智能体的例子学生用户每次都会表达“数学题好难不想做”如果智能体没有长期记忆它每次只会机械地鼓励如果它记得“这个学生昨天因为分数运算崩溃过一次今天情绪状态可能不好”它就会调整语气先共情再拆题。这就是长期记忆的实战价值。实现长期记忆时我的建议是分开存两类信息。一类是事实记忆比如“用户所在城市上海”“用户偏好不用辣椒”直接用结构化存储即可。另一类是语义记忆比如“用户喜欢用比喻来理解概念”这类需要向量化。用Embedding模型转成向量存进向量数据库等需要时做相似度检索。3.3 记忆写入与检索不是所有历史都该进上下文记忆模块有的人做完发现反而拖慢系统原因往往是“什么都记检索时什么都拿出来”。我定了几条原则。写入时只有出现明确的实体信息、用户偏好或任务结果才把内容写入长期记忆。比如“我下周出差深圳”就必须记但“我今天心情不错”可以不记。检索时先做相关性过滤只取最相关的top-k条而不是把所有向量都拼进去。阈值也很重要相似度太低的结果宁可不给模型否则反而会引入噪声。还有一个易错点记忆读取的时机。通常是在模型生成回复之前做一次检索把结果作为上下文的一部分传入。但如果在工具调用后检索第二次往往效果更好因为工具已经确认了用户需求这时检索到的记忆更精准。这种多轮读取的设计需要你在上层的业务流程里显式加入“查询记忆”这一步而不是指望模型自己想起来。4. 工具使用与外部能力从聊天到干活的转折点4.1 函数调用是怎么被模型驱动的智能体能“干活”的关键在工具调用市面上最通用的机制叫Function Calling。简单说你先把工具的描述写成一份JSON Schema比如“get_weather接收city和date两个参数返回天气信息”然后把这份Schema随对话一起发给模型。模型在生成时如果判断当前需要查天气它的输出就不是普通文字而是一段结构化的“调用请求”比如请求调用get_weather且参数是city上海date2026-05-20。你的代码解析这段请求执行真实API调用把结果再返还给模型模型再基于结果生成用户能看的回答。这里有个常见误解不是模型直接执行了函数模型只是“建议”调用哪个函数真正的执行发生在你的代码里。这个分离很重要因为它给了你控制权。比如模型建议调用“删除数据库”工具时你可以在代码层加一个二次确认机制不让模型直接操作危险动作。4.2 典型工具组合搜索、计算器、代码解释器、RAG实际智能体项目里会用哪些工具我按使用频率列几类信息检索API比如天气、新闻、地图、电商价格属于最常见的“感知”工具。代码解释器模型生成一段代码在沙箱环境执行并拿结果适合做复杂计算、图表生成、数据处理。数据库查询通过自然语言生成SQL再查询业务数据这是企业级应用的核心场景。RAG检索增强生成把私有文档先切片向量化用户提问时检索相关内容给模型做参考。RAG本质上也是一种工具只是它调用的是你自己的知识库。通信与业务API发邮件、创建工单、改日历、发消息这类能让智能体完成闭环任务的工具价值最高。现在多模态大模型发展很快工具层面也在扩展比如图像输入、语音识别、截图理解。但我的经验是别为了让智能体“显得高级”就一次接太多工具工具越多模型做选择的难度越大出错率越高。先保证五个以内的核心工具跑顺再逐步扩展。4.3 平台搭建与Python原生搭建的差异很多读者会问我用Dify、Coze这些平台搭出来的智能体和用Python自己搭建的有什么不同答案挺明确。低代码平台最大的优势是快可视化编排、内置工具节点、调试界面、发布通道都现成适合快速做原型、验证业务逻辑也适合非专业开发人员维护。我见过不少运营团队用Coze搭建客服流程改话术不用等开发排期这是实打实的效率。但平台也有代价。一是可定制性受限内部特有的工具协议、鉴权逻辑、复杂的动态规划很难在平台上表达。二是可观测性和数据主权平台上的Log、用户数据默认存在平台侧有些企业场景无法接受。三是复杂工程能力比如高并发、多租户隔离、精细化监控平台能给的方案往往比较有限。技术面试时也常被问到这类问题我的回答基本都是原型验证用平台生产落地用代码两者不是替代关系而是不同阶段的工具。如果你选择走代码路线Python生态最成熟LangChain、LlamaIndex、AgentScope等框架都能用。Java生态里也有Spring AI 2、AgentScope的Java版本适合已有Spring Boot技术栈的团队。框架能省掉一部分样板代码但核心的组装逻辑还得自己理解否则出了问题很难定位。5. 反馈与自主容错构建可靠AI系统的工程实践5.1 为什么容错是智能体落地的分水岭对智能体开发来说最典型的翻车现场你肯定见过智能体在调用工具时连续报错然后它不承认失败反而自己编了一个结果告诉用户“已经帮你完成”。这种情况在demo里能被忍受在生产环境里就是事故。可靠并不是“模型不出错”而是“出错以后系统能自我发现、自我恢复、至少不撒谎”。这个能力现在被单独提出来叫自主容错控制已经成为智能体工程实践里最重要的研究方向和落地能力之一。一个不用容错模块的智能体就像一个从不看仪表盘的司机轮胎爆了还在踩油门。5.2 错误检测与重试策略容错的第一步是发现错误。错误分几类格式错误比如模型输出的JSON解析失败工具异常比如第三方API返回500逻辑错误比如模型调用了工具但参数明显不合常理还有自评错误即模型自己意识到“我掌握的信息不足以回答”。发现错误之后要有重试策略。我的经验是不是所有错误都值得重试。工具超时或网络抖动这类瞬时错误可以自动重试每次间隔指数退避比如1秒、2秒、4秒最多三次。模型输出格式错误可以让模型根据报错重新生成一次往往第二次就能修正。但如果是工具业务逻辑上的错误比如权限不足、余额不足重试没有意义应当直接走降级或转人工。关键在于要把错误信息送回模型的上下文并明确告诉它“刚才的调用失败了原因是XX请重新决策”。很多新手只做了重试却没有把失败原因给到模型模型只能瞎猜越猜越错。5.3 降级与兜底一条可执行的错误处理链路容错的高阶是降级设计。降级的意思是在某个子系统不可用时智能体依然能给出一个对用户有帮助的回应而不是直接崩掉或者编造。我给一个可参考的决策链路。当工具调用失败时系统先判断网络上是否有兜底的数据源有就用兜底源没有就检查智能体是否已积累足够知识能直接回答能就明确标注“该信息可能不够实时”如果连知识也不足就诚实地回答“我需要连接XX服务后才能回答请稍后重试”或者把会话转给人工客服。这条链路里每一层都有一个动作不会出现“模型在空地上自由发挥”的情况。还要设计一个额外的保护明确禁止模型在工具失败后假装成功。做法是在系统提示词里写死规则同时在代码层检测如果模型没有调用工具却声称“已调用”立刻拦截并生成修正语句。这条规则能减少大量用户投诉。5.4 评估闭环没有评测的迭代都是自嗨容错做得怎么样不能靠感觉要有评测。真实部署前我建议至少准备三样东西。一组典型场景测试用例覆盖主流程、边界条件、异常输入一组历史badcase把之前智能体答错的案例汇总起来每次改动后回归一遍还有一个上线后的监控面板记录调用成功率、工具失败率、用户反馈标签等。有了评测闭环容错模块的迭代才算真正闭环。否则你会发现今天修了一个bug下周改提示词又把它带回来了而且完全没有察觉。6. 多智能体协作与扩展方向6.1 从单智能体到多智能体单智能体是“一个模型管所有事”这个方案在复杂业务里很快就会遇到瓶颈。首先是上下文互相干扰比如一个智能体既要跟用户聊情感问题又要查库存算物流两件事的上下文混在一起回复质量双双下降。其次是权限难控制一个能查库存的智能体往往也能看到成本不安全。多智能体架构就是把这个大而全的智能体拆成多个角色每个角色各管一段。拿销售智能体举例线索挖掘智能体负责从公开渠道筛选潜在客户话术生成智能体负责根据客户行业生成个性化开场白客户情绪分析智能体负责识别用户语气是热情还是抵触CRM更新智能体负责把有效信息回填系统。每个智能体只有单一职责上下文干净模型压力小出错了也不会连带整个流程崩掉。6.2 常见多智能体架构编排式、辩论式、流水线式多智能体怎么组合一般看任务性质。编排式也叫主管/工人模式一个主控智能体负责拆解目标把子任务分发给不同的专业智能体然后汇总结果。这种模式适合目标不固定、需要灵活应对的用户请求。流水线式适合固定流程比如“线索清洗-内容生成-外呼-结果回收”这种环节明确的任务上一个智能体的输出就是下一个的输入。辩论式多个智能体对同一个问题互相评审、给出不同意见最后投票或由裁判汇总适合高价值决策场景比如生成重要方案、审查敏感内容。多智能体不是越多越好。每增加一个智能体就增加一层通信成本和协调复杂度。很多时候两个专职智能体加一个协调者的效果优于十个互相抢上下文的通用智能体。这也是我在看过几百个智能体案例之后的一个很深的体会好项目都是“克制”出来的。6.3 那些案例里反复出现的模块规律市面上流传的“500个智能体案例集”这类资料我基本都翻过一遍发现一个共性案例里有用的智能体其组成几乎都逃不掉前面说的那几个模块。有的案例强调记忆设计有的强调工具链有的干脆只靠一个写得很细的系统提示词加两个工具就撑起整个产品。它们之间的差异只在于某个模块被放大了而不是某个模块可以被取消。所以与其搜集更多案例不如先把组成结构吃透然后往自己的场景里套。这个道理适用于任何智能体开发方向不管是写代码智能体、销售智能体还是教育智能体。7. 从零搭一个最小可用智能体7.1 先定需求再定模块别一上来就堆功能我的习惯是先列清楚“必须能力”和“暂缓能力”。比如你只想做一个“能查公司内部知识库并回答员工政策问题的智能体”那必须能力就两样文档检索工具、对话记忆。不需要接代码解释器不需要接外部搜索更不需要多智能体。把范围缩到最小后续每一步都能快速验证这才是靠谱的起步方式。7.2 一个实际的组装过程以Python为例我写一个极简但完整的实现逻辑不绑定具体SDK用伪代码风格展示六个模块如何串起来def run_agent(user_input, history, memory_store, tools): # 1. 从长期记忆中检索相关信息 memories memory_store.search(user_input, top_k3) # 2. 组装上下文系统提示词 历史 检索记忆 本次输入 messages build_messages( systemSYSTEM_PROMPT, historyhistory, memoriesmemories, user_inputuser_input ) # 3. 调用主模型传入tools的JSON Schema response llm.chat(messages, toolstools, temperature0.1) # 4. 如果模型决定调用工具解析并执行 if response.tool_calls: for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append(format_tool_result(call, result)) # 执行完工具后让模型基于结果生成最终回复 response llm.chat(messages, temperature0.1) # 5. 简单容错如果最终回复声称调用过工具但实际没有调用日志拦截 if claims_tool_call(response.text) and not has_tool_log(messages): response.text fallback_message(response.text) # 6. 把本轮关键信息写入长期记忆 memory_store.save_important_facts(user_input, response.text) return response.text这里我故意去掉了一堆复杂分支只保留了最核心的循环。你可以看到整个流程其实分为检索记忆、组装消息、调用模型、判断工具、执行工具、二次生成、写入记忆。每一步之间都有清晰的边界出了问题只需要看其中一小段。7.3 上线前的最低检查清单上线之前拿这份清单逐条过一遍能省掉很多线上事故工具调用失败时是否有兜底回复而不是编造数据。非白名单域名或危险操作是否有代码层拦截。长期记忆写入是否是异步的会不会阻塞主流程。是否有基础日志能查到每一步的模型输入输出。是否设置了单次会话的最大工具调用次数上限防止死循环。是否对提示词做了版本管理方便回滚。这六项是最底线。如果你做的智能体要面向企业客户还需要再加上人机协同的转人工机制和审计日志。8. 常见问题与排查技巧实录8.1 问题速查表我把自己和身边团队实际遇到的高频问题整理成一张表供你排查时对照现象可能原因排查方向智能体反复调用同一个工具停不下来上下文里保留了上一次工具结果模型误以为还需要再调检查循环内是否清空了上一轮的工具调用记录设置最大轮次模型拒绝调用工具直接凭记忆回答工具Schema写得太复杂或描述不清简化工具描述把“何时使用该工具”写进描述工具返回结果和最终回复明显矛盾二次生成时上下文没有包含工具结果或包含后被截断检查Token预算和消息顺序确保工具结果在截断保护区内用户说“昨天刚告诉过你”智能体毫无印象长期记忆写入条件太苛刻或检索不到检查写入逻辑是否提前退出检索相似度阈值是否过高一次简单提问却调用了很多工具响应极慢规划模块缺少提前终止规则增加“已获得足够信息”的判定减少不必要的耗时代码智能体在工具全部失败后开始编造结果缺少降级链路和诚实规则按5.3的链路补上兜底回复和防撒谎拦截8.2 现场排查的方法排查智能体问题别只是盯着最终回复看那个只是结果。要看过程日志模型每一步的完整输入、它自己生成的思考内容、调用了哪个工具、工具返回了什么。我一般会把日志格式设计成“步骤编号-动作类型-关键内容”便于按时间线回放。如果你用平台搭建Dify和Coze的调试日志也能看到这些信息只是维度不如自建系统细。还有一个很实用的技巧在系统提示词里加入“让你debug用的内部输出”比如要求模型在调用工具前输出一行DEBUG_INTENT: 我准备调用xxx因为用户需要xxx。这行内容可以在开发环境打开、生产环境关闭能极大降低定位问题的成本。8.3 两条更省心的调试经验最后分享两条实操经验。第一先跑通最小闭环再加模块。很多团队一上来就接三四个框架和十几个工具出了问题根本不知道是模型的问题还是框架的问题还是工具的问题。我建议第一版只保留模型、一个工具、一个记忆库跑通后逐步加。第二容错机制本身也会引入bug重试循环、降级判断、记忆写入都可能出岔子所以给每个容错动作也加上日志。如果你的智能体最后表现得像一个“会承认失败、会重新尝试、实在不行会求助”的助理那你的容错层就算真正立住了。我做过的项目里凡是后来稳定运行的都长一个样核心模型规规矩矩规划路径清楚记忆写得克制工具调用有边界容错机制兜底最后再通过评测不断收口。理解和掌握这些组成部分之后你就会发现智能体开发不再是凭感觉调提示词而是一门可以稳定复盘的工程。这大概也是这项技术最值得深耕的地方。
阅读完成 · 觉得有帮助？
