企业官网建设流程全解析

最近被问得最多的一类问题，不是“智能体有什么用”，而是“智能体到底是由什么组成的”。很多人把智能体和聊天机器人划等号，觉得接一个大模型API、套一个对话框就算完事，结果一上线就发现它既记不住前几轮说过的话，也调用不了任何真实接口，稍微复杂一点的需求就卡死。其实智能体是一个由多个模块组成的小型系统：大模型负责当大脑，规划模块决定先干什么后干什么，记忆模块保证它不“失忆”，工具层让它有手有脚，反馈和容错机制让它不至于在错路上狂奔。这篇文章就把“智能体的组成”这件事从头到尾拆一遍，把每一块的职责、原理、踩坑点和使用时机都讲清楚。适合三类人看：正在做AI产品原型的学生或开发者，准备智能体相关岗位面试的人，以及用过Coze、Dify但想搞清楚底层逻辑、考虑自己写代码搭建的工程师。

1. 先拆结构：为什么说智能体不是“一个模型”而是五层系统

1.1 为什么不能直接拿大模型当智能体

在拆组成之前，必须先理解一个底层事实：大模型本身不是智能体，它是智能体的“大脑皮层”。模型做的是根据前面所有token预测下一个token，输入一段文本，它返回一段文本，这个过程里没有目标、没有状态、没有外部世界。你问它“帮我查一下上海明天天气”，它只能编一个答案出来，因为模型训练数据和实时天气之间没有必然联系。

我习惯打一个比方：大模型像一个记忆超群但没有手脚、也记不住几分钟前聊过什么的顾问。他能给建议，但没法执行；他会顺着你的话往下说，但不会主动盯住一个目标想办法绕开障碍。智能体的价值，就是在这个顾问身边配上一个秘书团队：有人负责拆任务，有人负责记笔记，有人负责打电话查资料，还有人负责检查他有没有把事办错。这个“秘书团队”，就是智能体的组成模块。

1.2 智能体为什么会“火”起来：一次关键能力跃迁

很多人以为智能体是这两三年才有的概念，其实Agent这个词在强化学习、多智能体系统里已经存在几十年。真正让LLM时代的智能体爆发，是模型具备了Function Calling能力，加上ReAct范式开始普及。ReAct就是把Reason（推理）和Act（行动）交替执行：模型先根据当前情况想一步，然后决定调用哪个工具，拿到工具返回的结果后再继续推理。

整个过程像一个人拿到任务后：

1. 先想清楚目标是什么；
2. 选择一个工具去获取信息或执行动作；
3. 看到结果，再想下一步；
4. 循环，直到完成目标或触发终止条件。

现在你看到的所有智能体开发框架，包括LangChain、LangGraph、Dify、Coze、AgentScope、Spring AI等，底层基本都是这个循环的不同包装。这不是巧合，而是因为这套模式最贴合“目标导向”的推理方式。你理解了这套范式，再看智能体的组成，就会顺理成章。

1.3 为什么要拆成模块：工程上不只是“为了好看”

模块化设计在智能体项目里不是理论洁癖，而是实实在在的工程需要。我见过很多项目把智能体堆成一个巨大的Prompt，所有逻辑都靠自然语言描述塞进上下文，结果改一个细节要动全局，出问题也无从查起。把智能体拆成模块之后，至少有四个好处：

• 可替换：觉得模型脑子不够用，换一个底座，其它模块不用动；觉得某个工具不好用，单独替换工具实现。
• 可调试：日志可以按模块打点，哪一步出了问题一目了然。
• 可复用：记忆模块、工具层可以从一个智能体搬到另一个智能体。
• 可测试：每个模块都可以单独写测试用例，不用等整个系统跑通。

在后面的章节里，我会把智能体拆成五大核心模块来讲，这些模块的组合方式，几乎就是所有智能体应用案例集的底层模板。

2. 五大核心模块：每一块负责什么、为什么必须存在

2.1 大脑层：大模型（LLM）不是越大越好

作为大脑的大模型是第一块组成，它解决“理解与生成”的问题，同时负责把其他模块串起来。现代智能体框架中，模型除了输出回答，还要输出“结构化决策指令”：到底该调用哪个工具、调用参数是什么、任务是否已经完成。所以模型的能力上限，基本决定了智能体的智能上限。

模型选型上有几个判断维度：

• 上下文长度：决定了短期记忆这个“杯子”能装多少水；
• 推理能力：决定了复杂任务的拆解深度；
• 工具调用稳定性：决定了工程上是否省心；
• 成本与延迟：决定了智能体能否规模化落地。

最好的选择不是最强的模型，而是在任务复杂度、单位成本和响应速度之间取平衡。我的经验是，先用强模型跑通场景，再用弱模型做降本验证。很多简单的工具调用任务，小模型加一个写得很具体的Prompt完全够用。另外，多模态大模型的进展让智能体的输入通道从纯文本扩展到了图片、语音，但组成原理不变，只是大脑层的能力更丰富了。

2.2 规划决策层：把大目标拆成可执行的小步骤

规划层是智能体和普通聊天机器人最大的分水岭。用户说“帮我整理本周市场数据并写一份周报”，聊天机器人会直接开始编报告，智能体则会先拆分出：查询数据源、清洗数据、生成图表、起草报告、检查格式等子任务，再决定执行顺序。

常见的规划策略有三类，各有适用场景：

• ReAct式规划：走一步看一步，适合目标模糊、环境动态变化的任务，缺点是容易绕弯子。
• Plan-and-Execute式：先让模型生成一个整体计划，再逐步执行，适合流程明确的场景，能大幅减少中间推理次数，但遇到意外变化时需要维护计划更新。
• Reflexion式：在执行失败后，把失败原因作为“经验”反馈给模型，让它重新尝试，适合需要反复试验的任务。

实际项目中很少有人只用单一策略，更多是混用。比如做客服智能体，开场走ReAct判断用户意图，确认是查询件后切换成固定流程，异常时再走Reflexion重试。规划层的本质是决策，它把“下一步做什么”变成模型可以推理的问题。这里有个实操要点：一定要在系统提示词里给规划层加上边界，告诉它什么情况下必须停下来问用户，什么情况下不许自作主张。否则模型很容易为了“完成目标”在错的方向上反复横跳。

2.3 记忆系统：没有记忆的智能体就是“金鱼”

LLM本身不保留任何跨请求的状态，每一次调用都是“一次性”的。因此记忆系统是智能体组成的必备模块。记忆通常分三层：

第一层是短期记忆，就是把最近几轮对话塞进上下文窗口，实现连续对话。窗口管理需要技巧，常见做法是把旧对话逐轮压缩成摘要，只保留与当前任务相关的细节。

第二层是长期记忆，也就是“把知识沉淀下来”。最常见的是向量数据库，把文本切块、用Embedding模型编码成向量，查询时把用户问题也转成向量做相似度检索。参数上我建议，切块大小控制在500到800个字符左右，重叠50到100个字符，保证跨块语义不断裂。Embedding模型尽量和主模型配套，如果混用不同体系，检索出来的内容模型可能“看不懂”。

第三层是结构化记忆，用数据库或KV存储保存用户偏好、订单状态、历史结论等确定性的信息。这一层比向量检索更准，也不容易被检索结果干扰，适合对准确性要求高的场景。销售智能体就是典型例子：客户上次提到的预算、家人关系、跟进节点，这些信息放结构化存储里，每一次会话直接读取，比等向量检索靠谱得多。

2.4 工具调用层：让智能体真正“有手有脚”

工具层解决的是模型无法直接操作真实世界的问题。它的组成包括：工具定义、执行器、返回处理三部分。

工具定义的本质是给模型写“说明书”。现在主流模型都支持Function Calling，做法是提供一个JSON Schema，描述工具名称、用途、参数类型。模型读了说明书后，在需要时生成一个“调用指令”，而不是直接执行。这一段定义质量影响巨大，我踩过不少坑：description写得太模糊，模型就不知道该什么时候用；参数名写得太抽象，模型就填错值。写description有一个技巧：想象你在让一个聪明的实习生干活，你要把前提条件、返回值含义、边界情况全部写清楚。

执行器是实际跑工具的地方，可以是一个Python函数、一个REST API封装、一段SQL、甚至一个代码解释器。这里必须做的工程加固包括超时控制、异常捕获、结果大小限制。很多失败不是模型的问题，而是工具本身报错后，模型拿到一段红色堆栈就懵了。

返回处理同样重要。工具返回的原始数据要精简再喂给模型，数据库查询返回100行原始记录，模型容易被干扰；你提前做一次汇总，只把关键指标给它，决策质量会大幅提升。RAG本质上就是工具层的一种特殊形态，它的输出是检索到的知识片段。所以不要老想着“RAG和Agent谁替代谁”，在组成视角下，RAG只是Agent工具箱里的一个工具。

2.5 反馈与容错层：决定智能体靠不靠谱

最后一块组成是反馈与容错，这是很多教程不提、但项目上线后最关键的模块。

模型不是每次都对，工具不是每次都不报错，网络不是每次都通畅。反馈与容错层要做的事情分成三层：输入校验、执行容错、结果校验。

输入校验指在用户输入进入规划层之前，先做敏感信息检测、意图边界判断、参数格式校验，从源头减少后续错误。执行容错指给每个工具调用加超时、重试和指数退避，失败后把错误信息结构化地反馈给模型，让它尝试替代方案，而不是把原始异常直接暴露给用户。结果校验指在智能体给出最终答复前，做规则检查，比如金额是否匹配、日期是否正确、工具是否真的调用成功。

我见过一个客服智能体，订单查询工具返回值解析失败时，它会自信满满地说“您的订单已发货”，用户一看物流信息完全对不上。问题就出在缺少结果校验层：模型把不完整的工具返回当作有效结果拿去用了。加一道校验，发现工具返回字段不完整，就强制进入“重新查询或转人工”分支，这类“一本正经胡说八道”的问题立刻少了一半。这套机制在工程领域有个说法，叫LLM智能体的自主容错控制，本质就是让系统在无人干预的情况下，识别异常、修正或隔离故障、继续完成任务。

3. 平台搭智能体和Python搭智能体，差别到底在哪

3.1 平台路线：Coze、Dify这类工具解决“快”的问题

Coze和Dify为代表的低代码平台，几乎把智能体的组成封装成了可视化模块：你拖一个大模型节点，连一个知识库节点，挂一个插件节点，再加一个对话入口，一个能跑的智能体就出来了。这类平台特别适合三种情况：一是快速验证产品想法，不需要写代码；二是团队里有产品经理、运营人员，希望他们也能直接维护智能体；三是发布渠道多，平台能直接一键接入微信群、网站客服、钉钉等。

平台方案的代价是抽象层级太高。底层怎么规划、上下文怎么管理、模型如何选择，都被封装成开关和模板。做一些标准任务没问题，一旦你要实现一个复杂的条件循环、要在多个智能体之间传递任务、要私有化部署、要接入自己训练的专用小模型，平台提供的自由度往往不够，这时你会在平台的各种“高级设置”里折腾半天，最后发现还是得自己写。

3.2 代码路线：从LangGraph、AgentScope到Spring AI

用代码搭智能体，等于你自己来设计和实现上面所有模块。当前用得比较多的框架：Python生态有LangGraph、AutoGen、AgentScope；Java生态有Spring AI结合AgentScope的实践。框架只是脚手架，真正的组成部分还是要靠代码定义。

代码路线的优势是控制力。你可以精确控制状态流、可以给特定用户走特定分支、可以自定义日志和监控、可以任意接入内部系统、可以做A/B测试。缺点是门槛高，并且要自己处理工程细节：会话并发、上下文压缩策略、工具鉴权、失败重试、资源回收等。用平台三分钟能跑通的Demo，用代码可能要写一个周末，但上了生产环境，维护和扩展的底气完全不一样。

3.3 一个对照表：到底怎么选

我整理了一张表，按个人经验打分：

我自己做项目的习惯是“先平台后代码”：先用平台把业务逻辑跑通，拿到真实对话样本，分析用户到底需要哪些工具、哪些环节容易失败，再用代码框架重写，把平台验证过的逻辑固化下来。这比一上来就找框架教程看三天更高效。

4. 一个最小可落地的智能体：从需求到代码骨架

4.1 动手前先画一张“能力地图”

搭智能体之前，我强烈建议先用一张纸把边界画清楚：用户是谁，输入是什么，输出是什么，需要访问哪些外部系统，哪些操作必须经人工确认，哪些失败必须转人工。这个能力地图决定了后面所有模块的设计。

比如做一个“订单助手”：输入是用户的文本或订单号，输出是查询结果或售后解决方案；需要的工具是订单查询API、物流查询API、退款申请API；必须人工确认的是金额超过300元的退款；必须转人工的是投诉、骂人、无法定位异常等。提前规划好边界，比直接在代码里瞎写判断强太多。我在实际工作中发现，超过一半的智能体开发项目失败，不是因为模型不够聪明，而是能力边界从一开始就没定义清楚。

4.2 极简代码骨架：一个不依赖框架的ReAct循环

下面用最少的代码演示一个智能体的核心骨架。它不绑定任何具体框架，逻辑就是“模型决策、工具执行、结果回填、循环决策”。这是理解智能体组成最直观的代码形态。

import json from openai import OpenAI TOOL_IMPL = {} # 工具名 -> 可调用函数 class MiniAgent: def __init__(self, model, system_prompt, tools): self.client = OpenAI() self.model = model self.system_prompt = system_prompt self.tools = tools def run(self, user_input, max_steps=5): messages = [{"role": "system", "content": self.system_prompt}, {"role": "user", "content": user_input}] for step in range(max_steps): resp = self.client.chat.completions.create( model=self.model, messages=messages, tools=self.tools, tool_choice="auto") msg = resp.choices[0].message messages.append(msg) if not msg.tool_calls: # 模型不再调用工具，直接输出 return msg.content for tc in msg.tool_calls: # 依次执行模型要求的工具 name, args = tc.function.name, tc.function.arguments try: result = TOOL_IMPL[name](**json.loads(args)) result = json.dumps(result, ensure_ascii=False)[:2000] except Exception as e: result = f"TOOL_ERROR: {e}" messages.append({"role": "tool", "tool_call_id": tc.id, "content": result}) return "已达到最大步骤数，请重新描述问题"

这段代码已经把智能体组成的四个关键环节体现出来了：System Prompt限定角色和能力边界，tools声明模型可以使用的工具，循环结构实现规划与执行交替，异常捕获把错误反馈给模型而不是直接崩溃。把TOOL_IMPL里加入真实函数，再配上对应的tools定义，就构成一个能跑的智能体。

4.3 三个决定“好用还是难用”的细节

第一个细节是System Prompt。不要只写“你是助手”，至少要包含四段信息：角色与风格、能力边界与禁止事项、可用工具和什么时候用、输出格式偏好。模型读到的说明越具体，行为越可控。

第二个细节是工具返回结果的长度。上面代码里我已经设置了截断2000字符。工具返回几万字时，模型的注意力会被无关字段淹没，决策质量断崖式下降。建议在工具内部先做一层摘要，只返回模型真正需要的字段。

第三个细节是完整日志。每个循环步骤，要把模型思考内容、调用的工具名、参数JSON、返回值摘要、执行耗时都记录下来。这些日志在出问题debug时价值极高。很多初学者不记录日志，出了问题就只能盲猜。

4.4 千万别用“两三个问题”来验收智能体

一个常见错误是拿两三个精心设计的问题测一下，觉得效果好就上线。智能体类系统的验收一定要场景化测试：准备20个正常情况用例，再准备20个刁钻用例，包括信息缺失、敏感请求、多轮追问、工具故障、超长输入、语气攻击。把这些用例录成自动化脚本，批量跑，记录通过率和失败原因。

我自己的做法是把测试集存在一个表格里，跑完一轮导出结果，逐个看失败的case，把失败原因归到“模型问题”“工具问题”“Prompt问题”“记忆问题”四类，分类修补。经过三四轮迭代，通过率一般能从70%提到95%以上。这个过程没有捷径，但能保证不上线后翻车。

5. 常见问题与排查技巧实录

5.1 智能体“答非所问”，到底是哪一层出问题了

现象：用户问A，智能体答B；或者答着答着跑偏。排查顺序很重要：先看日志里模型每一步的思考文本，确认它在做什么决策；再看工具返回是否被正确注入到后续上下文；最后看记忆检索出来的内容是不是和当前问题相关。很多时候是长期记忆检索把不相关的历史信息塞了进来，干扰了模型。解决方法是降低相似度阈值，或者在前置检索后加一道相关性重排。

5.2 工具调用反复失败，模型“不会用”工具

现象：模型执意调用一个不存在的工具名称，或者填出明显不合法的参数，或者干脆忽略工具直接编答案。原因通常是工具定义描述不到位。推荐做法：把工具描述写成“在什么条件下应该调用”“参数表示什么”“返回后如何处理”，不要只写一句“查询订单”。这个坑在智能体面试里也是高频题，考察的就是你对工具层组成的理解程度。

5.3 多智能体协作时的“抢话”问题

当智能体的组成从单个Agent扩展到多智能体时，最典型的问题是谁都想回应、互相打断。工程上的解法是把通信机制和调度机制拆出来：定义统一的消息格式，每个智能体只订阅自己负责的事件；调度器决定消息分发给谁；给每个智能体设定优先级和发言频率上限。负责销售的和负责售后的如果都能回答“价格问题”，就要在语义层做分类，避免重叠。这就回到同一个原则：模块职责要正交。

5.4 一张速查表

6. 组成模块不变，场景组合千变万化

6.1 销售智能体：记忆和工具权重最高

销售场景的智能体，组成上突出两块：客户记忆和业务工具。它需要结构化存储客户偏好、历史沟通记录、近期动向，需要调用CRM、报价单、库存查询等工具。话术生成反而不是最关键的地方。很多销售团队做出来的智能体“话很漂亮但没法成交”，原因就是它记不住客户上个月说过的预算范围，工具又只会推送模板内容。把记忆和工具这两块补齐，智能体才真正能帮销售干活。

6.2 教育情感智能体：除了知识还有情绪判断

教育场景，尤其是小学数学辅导这类场景，智能体的组成比通用助手多了两层：情感识别和学习进度记忆。小学数学智能体要做得好，核心不是把答案算出来，而是把题目拆成孩子能理解的步骤，用苏格拉底式提问引导孩子自己得出答案，并且根据孩子之前错过的题型调整讲解方式。这就要求规划层有教学策略，记忆层记录掌握程度，反馈层在孩子反复做错时切换更简单的讲法。这类智能体如果少了情感判断模块，只会冷冰冰地报答案，家长用两次就会放弃。

6.3 客服与代码智能体：结果可验证是第一优先级

客服智能体典型的组成是知识库RAG、工单系统工具、转人工策略；代码智能体则是大模型加代码执行沙箱、文件读写工具、测试反馈循环。这两个场景有一个共同点：结果必须可验证。客服不能乱承诺赔付，代码不能生成一遍过不去的代码。所以工程实践中都会加一道校验器：客服侧校验政策条款和金额，代码侧运行测试用例。校验不通过，绝不直接输出。

6.4 不是所有对话任务都需要“智能体”

最后提醒一句，不是所有对话任务都值得上完整的智能体组成。如果任务只是固定的问答、FAQ、知识检索，一个RAG应用就够了，加太多模块只会增加延迟和不可控性。智能体的优势场景有三个共同点：目标明确、需要外部动作、结果可以验证。反过来，如果这三点不成立，先别急着上Agent，把你的Prompt调好、RAG做好，可能更快更稳。

我个人做了十几个智能体项目之后的体会是：搭一个能跑的Demo真的不难，难的是把“组成”这件事想明白——每一层都独立可测、每一条失败路径都有预案。智能体会一本正经地胡说八道，会在工具失败后自欺欺人，会为了完成目标在错路上绕圈，这些都不是模型单点能解决的，而是靠反馈、日志、权限边界和失败重试这些工程模块去兜底。设计智能体的第一天就把它们放进来，而不是上线前才补，能少踩很多坑。如果你正打算从平台跳到代码，我建议先拿一个月真实对话做测试集，把通过率跑上去，再谈架构，比看多少篇拆解文章都管用。