感知节点：Agent的"感官系统"如何接收和处理输入

感知节点是Agent决策链路的起点。AI Agent（人工智能智能体）的感知能力决定了它能处理什么类型的输入——文本、图像、音频还是结构化数据。现代Agent通常基于LLM（Large Language Model，大语言模型）构建，感知层的核心任务是将各种格式的输入转化为LLM可处理的统一表示。

文本输入是最基础的形式。用户输入"帮我查一下北京明天的天气"，Agent的感知层首先进行文本清洗——去除多余空格、标准化标点、检测语言类型。如果用户输入包含文件附件（如PDF文档），感知层还需要调用文档解析模块提取文本内容。

多模态感知是更复杂的情况。当用户上传一张截图并说"帮我分析这个数据图表"时，Agent需要同时处理文本输入和图像输入。文本部分走语言理解通道，图像部分走视觉理解通道（如GPT-4o的视觉能力），两个通道的输出在后续节点合并。这个过程中的关键挑战是模态对齐——确保文本和图像理解结果在语义层面一致。

感知层的另一个重要功能是上下文注入。Agent不是无状态地处理单次输入，而是将对话历史、用户偏好、系统设定等上下文信息一并传入感知层。例如，用户先说"我想看北京的天气"，接着说"那上海呢"，Agent的感知层需要从对话历史中提取"天气查询"这个上下文，将"那上海呢"补全为"查询上海明天的天气"。

意图识别与任务规划：Agent如何判断"要不要用工具"和"用几个工具"

感知层输出的是用户输入的结构化表示，接下来进入意图识别节点。这是Agent决策的核心环节——判断用户到底想要什么，以及是否需要调用外部工具。

意图识别的基本逻辑是：LLM基于用户输入和上下文，判断请求属于"纯对话"还是"工具调用"类型。纯对话类请求（如"什么是AI Agent"）可以直接由LLM生成回答，不需要调用外部工具。工具调用类请求（如"查北京明天天气"）需要LLM识别出具体的工具调用意图——查询天气、调用API、搜索资料等。

意图识别的挑战在于模糊意图的处理。用户说"帮我看看最近的AI新闻"，这个请求需要调用搜索引擎工具，但"最近"是多久？"AI新闻"是学术新闻还是产业新闻？Agent需要在意图识别阶段做出合理假设，并在任务规划中设计灵活的执行策略。

任务规划节点紧接意图识别。对于简单请求（如查天气），任务规划可能只有一步——调用天气API。但对于复杂请求（如"帮我分析最近AI行业的融资趋势"），任务规划需要将请求拆解为多个子任务：

子任务1：搜索"AI融资"相关新闻（调用搜索引擎工具）

子任务2：从搜索结果中提取融资事件信息（调用文本抽取工具）

子任务3：对融资事件按时间和金额分类统计（调用数据分析工具）

子任务4：生成趋势分析报告（LLM直接生成）

任务规划的输出是一个有向无环图（DAG），定义了子任务的执行顺序和依赖关系。子任务1和2是串行依赖（2依赖1的输出），子任务3依赖2的输出，子任务4依赖3的输出。优秀的任务规划能显著减少工具调用次数——例如将多个独立的搜索请求并行化处理，可以将总执行时间降低40%-60%。

工具选择与执行调度：从"知道用什么"到"知道怎么用"

工具选择节点解决的是"从可用工具池中选出最匹配的一个或多个"。Agent通常拥有一个工具库，包含搜索、数据库查询、API调用、文件操作等多种工具。工具选择不是简单的关键词匹配，而是LLM基于任务需求、工具描述和历史使用效果的综合判断。

工具选择的技术实现通常基于Function Calling（函数调用）机制。开发者预先定义每个工具的名称、描述、参数格式，LLM在推理时根据这些定义决定是否调用工具、调用哪个工具、传入什么参数。例如，当Agent的工具库中有天气查询和股票查询两个工具时，用户问"今天适合穿什么"，LLM需要判断这需要天气信息，选择天气查询工具。

工具选择的进阶场景是动态工具发现。在MCP（Model Context Protocol，模型上下文协议）等标准化协议下，Agent不需要预先知道所有工具，而是在运行时从工具注册中心动态发现可用工具。这使得Agent的工具能力可以随时扩展，不受初始配置限制。

执行调度节点负责按任务规划定义的顺序和依赖关系执行工具调用。这个节点的核心挑战是：

第一，依赖管理。子任务B的输入依赖子任务A的输出时，调度器需要确保A完成后才执行B。如果A失败，调度器需要决定是重试A、跳过B、还是用备用方案替代A。

第二，并发控制。多个无依赖关系的子任务可以并行执行，但并发数量需要控制——同时发起过多API调用会触发速率限制或导致超时。合理的并发度通常设置为3-5个并行任务。

第三，超时处理。每个工具调用设置超时阈值（通常10-30秒），超时后触发重试或降级策略。例如搜索引擎工具超时，可以降级为使用缓存的搜索结果。

结果整合：Agent如何把碎片信息变成连贯回答

结果整合是决策链路的最后一个节点，也是最容易被忽视的环节。工具执行返回的是结构化数据——JSON格式的天气信息、搜索结果列表、数据库查询结果。将这些碎片化信息组织成用户能理解的自然语言回答，是结果整合节点的任务。

结果整合不是简单的"把数据拼成句子"。LLM需要对多个工具的返回结果进行信息融合、冲突解决、重点提炼。

信息融合：当多个工具返回相关但格式不同的信息时，LLM需要将它们合并为统一的表述。例如天气API返回温度和湿度，搜索工具返回穿衣建议，LLM需要将这些信息融合为"明天25度、湿度60%，建议穿薄外套"这样的连贯表述。

冲突解决：当不同工具返回的信息矛盾时，LLM需要判断哪个来源更可信。例如搜索引擎返回"某公司融资5亿"，但数据库查询返回"融资3亿"，LLM需要根据信息时效性和来源可靠性做出选择，或在回答中标注差异。

重点提炼：用户问"北京天气怎么样"，工具返回的温度、湿度、风速、空气质量、紫外线指数等十几项数据。LLM需要根据用户的隐含需求（穿衣建议vs出行计划vs健康提醒）提炼最相关的信息，而不是把所有数据罗列一遍。

结果整合的质量直接影响用户体验。一个优秀的Agent回答应该像专业助理的回复——简洁、准确、有针对性，而不是像API文档一样罗列字段。这也是为什么结果整合节点需要强大的LLM支持——弱模型能完成工具调用，但难以做好结果整合。

常见问题

Agent的决策链路是否每次都完整走6个节点？

不是。对于简单对话类请求（如"什么是AI Agent"），Agent在意图识别阶段判断为"纯对话"，跳过工具选择和执行调度，直接由LLM生成回答。6个节点的完整链路主要在需要工具调用的场景中出现。链路的灵活性也是Agent高效运行的关键——不必要的工具调用会增加延迟和成本。

感知节点如何处理用户输入中的拼写错误或语法问题？

现代LLM具有较强的容错能力，能理解包含拼写错误或语法不规范的输入。感知层的文本预处理主要处理格式标准化（如统一编码、去除多余空白），而非语法纠正。对于严重到影响语义理解的错误，Agent通常会在意图识别后向用户确认——"您是想查询XX吗？"

任务规划节点和工具选择节点的区别是什么？

任务规划解决"做什么"——将复杂需求拆解为子任务序列。工具选择解决"用什么做"——为每个子任务匹配具体工具。例如用户要求"分析AI融资趋势"，任务规划拆解为搜索→抽取→统计→生成报告4个子任务，工具选择为每个子任务分别匹配搜索引擎、文本抽取工具、数据分析工具和LLM。

结果整合节点为什么需要强大的LLM？弱模型不行吗？

结果整合需要信息融合、冲突解决和重点提炼三种能力，这些都需要较强的推理和语言组织能力。弱模型能完成简单的数据格式化，但在多工具结果融合、冲突判断和针对性提炼方面表现不足。结果整合质量直接决定用户体验，是Agent能力差异的关键分水岭。