企业官网建设流程全解析

1. 项目概述：当表格问答遇上多智能体协作

最近在做一个挺有意思的项目，叫DataFactory。这名字听起来像个数据工厂，实际上也确实如此，只不过它生产的是“答案”。简单来说，DataFactory是一个专门用来解决高级表格问答问题的多智能体协作框架。你可能要问了，表格问答不就是对着Excel或者数据库表问问题吗，比如“上个月销售额最高的产品是什么？”，这有什么高级的？确实，传统的表格问答系统能处理这类简单的查询，但一旦问题变得复杂、模糊，或者需要结合表格之外的知识进行推理，它们就有点力不从心了。

举个例子，给你一张员工信息表，里面有姓名、部门、入职年份、薪资等级。你问：“找出所有在研发部门工作超过5年，并且薪资等级在P7以上的员工，按入职年份排序。” 这还算清晰。但如果问题是：“请推荐几位适合领导新成立的‘AI创新实验室’的资深技术专家。” 这个问题就复杂多了。它隐含了多个条件：候选人需要在技术部门、有足够资历（可能对应高薪资等级或长司龄）、具备AI相关背景或潜力。表格里可能没有直接的“AI背景”字段，这就需要系统结合外部知识（比如，哪些部门与AI技术更相关）进行推理。DataFactory要解决的，正是这类需要深度理解、多步推理和知识融合的“高级”表格问答任务。

它的核心思路是“分而治之，协同作战”。与其让一个庞大的、试图包揽一切的模型去硬啃复杂问题，不如把它拆解成多个子任务，交给一群各有所长的“智能体”去协作完成。这就像组建一个项目团队：有专门分析问题需求的“产品经理”，有负责从表格里精准提取数据的“数据分析师”，有擅长从外部知识库中查找补充信息的“研究员”，还有负责整合所有信息、生成最终答案的“报告撰写员”。DataFactory就是这样一个团队的“协作平台”和“工作流引擎”。它底层借鉴了ReAct（Reasoning + Acting）的思想，让智能体不仅能“思考”（推理下一步该做什么），还能“行动”（调用工具去执行，比如查询数据库、调用API）。同时，为了处理那些表格里没有的隐性知识，它引入了知识图谱作为外部记忆和推理引擎。这个框架的目标，是让机器像经验丰富的业务分析师一样，能够游刃有余地处理那些开放、复杂、需要综合判断的表格查询。

2. 核心架构与多智能体协作机制拆解

2.1 多智能体角色定义与职责划分

DataFactory的成功，关键在于设计了一套职责清晰、又能紧密协作的智能体角色。这不是简单地把一个任务丢给多个模型并行处理，而是构建了一个有组织、有流程的虚拟团队。在我的实现中，主要定义了四类核心智能体：

1. 问题解析与规划智能体这是团队的“指挥官”。它的输入是用户的原始自然语言问题。它的核心职责是进行意图识别和任务分解。首先，它会分析问题的类型：是简单的数据检索（如“求和”、“计数”），是复杂的条件筛选与排序，还是需要进行数值计算、趋势分析或因果推断？接着，它会将复杂问题分解成一个有序的、可执行的子任务序列。例如，对于“推荐AI实验室负责人”这个问题，它可能规划出以下步骤：

• 子任务A：从员工表中筛选出技术部门（如研发部、算法部）的员工。
• 子任务B：从结果中筛选出司龄大于5年的员工。
• 子任务C：从结果中筛选出薪资等级在P7及以上的员工。
• 子任务D：结合知识图谱，查询这些员工的过往项目经历，识别出有AI或机器学习项目背景的候选人。
• 子任务E：对最终候选人列表按资历（可综合司龄和薪资）进行排序。

这个智能体通常由一个经过微调的语言模型担任，其提示词工程至关重要，需要教会它识别各种问题模式和对应的分解模式。

2. 数据查询与提取智能体这是团队的“执行者”。它接收来自规划智能体的具体数据查询指令（例如，“从employee表中查询department为‘研发部’的所有记录”）。它的核心能力是将自然语言或结构化的查询描述，转换成能够被底层数据库或数据处理引擎执行的确切查询语句，比如SQL。对于非结构化的表格（如CSV、Excel），它需要理解表格的语义（表头含义、数据类型），并进行精准的筛选、投影和连接操作。这个智能体的准确性直接决定了后续所有步骤的数据基础是否可靠。在实践中，我通常会结合使用两种方案：对于已知固定模式的表格，可以训练一个专门的文本到SQL模型；对于更通用的场景，则利用大语言模型强大的代码生成和理解能力，配合详细的表格schema描述，来生成查询代码（如Pandas操作代码）。

3. 知识融合与推理智能体这是团队的“外脑”和“分析师”。很多高级问题的答案并不直接存在于表格数据中。例如，表格里有“产品名称”和“销售额”，但问题问的是“哪些产品属于我们的战略新兴品类？” 战略新兴品类的定义，可能存储在公司内部的知识图谱或文档中。这个智能体的职责就是：当规划中指出需要外部知识时，它被激活。它接收当前的数据上下文（例如，一批产品名称）和待解决的子问题（例如，“判断这些产品是否属于战略新兴品类”）。然后，它会去查询连接的知识图谱，寻找实体、属性和关系，将表格中的数据和外部知识进行链接和融合，并基于图谱进行简单的推理（如：“产品A属于‘智能硬件’类，‘智能硬件’是‘战略新兴品类’的子类，因此产品A属于战略新兴品类”）。

4. 答案合成与校验智能体这是团队的“收官者”。它接收所有前置智能体的输出：原始问题、分解后的子任务计划、从表格中提取的原始数据、从知识图谱获得的相关信息和推理结果。它的任务是将这些零散的信息整合成一个连贯、准确、符合人类表达习惯的最终答案。这不仅仅是简单的拼接，而是需要：验证数据的一致性（例如，不同子任务查询的结果在ID上是否能正确关联）、处理可能的空结果或冲突、决定答案的呈现形式（是列表、摘要、还是带有解释的段落），并最终生成自然语言文本。此外，它还应具备初步的校验能力，例如检查数值的合理性（销售额不会是负数），或者当结果集为空时，给出可能的原因提示（“未找到符合‘AI背景’条件的员工，建议放宽‘技术部门’的范围或考虑外部招聘”）。

注意：智能体的划分不是一成不变的。根据具体业务场景的复杂度，你可以增加更细分的角色，如“计算智能体”专门处理数值运算和统计，“质量控制智能体”专门校验中间结果的合理性。关键在于确保每个智能体的职责单一且明确，避免出现“全能但全不能”的智能体，这是降低系统复杂度、提升可维护性的关键。

2.2 基于ReAct的协作工作流引擎

定义了角色，接下来就需要一套机制让它们有序地跑起来。DataFactory采用了ReAct范式作为智能体协作的“总控逻辑”。ReAct的核心在于将“推理”和“行动”交织在一个循环中，这对于需要多步决策的任务非常有效。

在DataFactory的上下文中，这个循环通常由一个“协调器”来驱动（这个协调器本身也可以看作一个高级智能体，或者由框架的工作流引擎实现）。整个协作流程可以概括为以下几个阶段：

阶段一：初始化与问题接收协调器接收用户问题，并初始化上下文环境，包括加载目标表格的元数据（表头、类型）和可用的知识图谱端点信息。

阶段二：规划生成与任务分发协调器调用“问题解析与规划智能体”，生成初始的任务分解计划。这个计划不是一个简单的列表，而是一个有向无环图，定义了任务之间的依赖关系。例如，“筛选技术部门”和“筛选高薪资”这两个任务可以并行执行，但它们的结果都必须准备好，才能进行“查找AI背景”这个任务。

阶段三：循环执行与状态管理协调器开始按依赖关系调度子任务。对于每个子任务：

1. 思考：负责该任务的智能体（如数据查询智能体）根据当前上下文（问题、已有结果）进行“思考”，决定需要执行什么“动作”。例如，“我需要查询员工表，条件为department列包含‘研发’或‘算法’”。
2. 行动：智能体执行该动作，通常是调用一个工具。对于数据查询智能体，这个工具就是数据库查询执行器。它会生成SQL或Pandas代码并执行。
3. 观察：智能体获取动作执行的结果（查询到的数据行，或一个错误信息）。
4. 再思考/传递：智能体根据观察结果，判断该子任务是否完成。如果完成，则将结果写入共享上下文，并通知协调器；如果未完成（例如，查询结果为空，可能需要调整查询条件），则重新进行“思考-行动”循环，或者将异常状态上报给协调器。

协调器监控所有子任务的状态。当一个任务完成后，它会更新上下文，并触发其依赖的下游任务开始执行。同时，它需要处理异常，比如某个智能体多次尝试后仍失败，协调器可能需要决定是重试、跳过该任务，还是向用户请求澄清。

阶段四：结果汇总与答案生成当所有必要的子任务（或根据某种策略判定足够生成答案的任务）都完成后，协调器调用“答案合成与校验智能体”。该智能体获取完整的上下文，执行最终的整合、校验与生成工作，输出最终答案给用户。

阶段五：可选的反馈与学习在一些更高级的实现中，系统可以收集用户对答案的反馈（显式评分或隐式行为），用于优化智能体的决策（如调整规划策略）或更新知识图谱。

这个基于ReAct的工作流，使得DataFactory能够灵活地处理复杂、动态的查询过程。智能体不再是被动地执行预设脚本，而是能够根据中间结果动态调整策略，具备了初步的“应变”能力。

2.3 知识图谱的集成与作用

知识图谱在DataFactory中扮演着“外部常识库”和“关系推理机”的双重角色，它是解决“表格信息不足”问题的关键。

1. 实体链接这是第一步，也是最基础的一步。当表格中的数据项（如产品名“AlphaPhone”、员工名“张三”）需要与外部知识关联时，系统需要将这些字符串准确映射到知识图谱中的对应实体节点上。这通常需要一个实体链接服务，它可能基于字符串模糊匹配、别名词典或嵌入向量相似度来实现。例如，将表格中的“AlphaPhone”链接到知识图谱中的实体产品:AlphaPhone。

2. 属性补全与关系查询链接成功后，知识图谱就能提供表格中缺失的属性。例如，员工表里只有“部门”和“职位”，但知识图谱中存储了每位员工参与的“项目”经历。通过查询与员工:张三相连的参与关系，就能找到他做过的所有项目，进而判断他是否有AI项目经验。

3. 层次推理与语义扩展知识图谱的类别层次结构（本体）非常有用。例如，图谱中定义了品类:智能手机是品类:消费电子的子类，而品类:消费电子又是品类:硬件的子类。当问题问及“硬件产品销量”时，智能体可以通过图谱推理，将“智能手机”、“平板电脑”等都纳入统计范围，实现语义层面的查询扩展。

4. 作为规划的依据知识图谱甚至可以在规划阶段就发挥作用。问题解析智能体在分解任务时，如果识别出问题中提到了某些概念（如“战略品类”），而表格中没有对应字段，它就可以在规划中主动插入一个“调用知识融合智能体”的子任务，去图谱中查询这个概念的定义和包含的实体。

在实际集成时，通常不会要求智能体直接去写复杂的图查询语言（如Cypher, SPARQL）。更常见的做法是，将知识图谱封装成一组API工具，例如：

• get_entity_info(entity_name: str): 获取实体的基本属性和直接关系。
• find_entities_by_category(category: str): 查找属于某个类别的所有实体。
• check_relation(entity1: str, relation: str, entity2: str): 检查两个实体间是否存在特定关系。 然后，让智能体通过ReAct中的“行动”步骤来调用这些工具。这样，智能体只需要知道“需要去查某个信息”，而不必关心底层图谱的具体结构。

3. 关键技术实现与工具选型

3.1 智能体核心：大语言模型的选择与提示工程

智能体的“大脑”通常由大语言模型充当。模型的选择需要在能力、成本和速度之间权衡。

模型选型考量：

• 闭源 vs. 开源：GPT-4、Claude等闭源模型在复杂推理、指令遵循和代码生成上通常表现最强，但API调用有成本和延迟，且数据隐私需要考虑。Llama 3、Qwen、DeepSeek等开源模型可以私有化部署，数据安全可控，经过特定微调后也能达到不错的效果，是许多企业级项目的首选。
• 尺寸与能力：对于“问题解析与规划”、“答案合成”这类需要较强逻辑和语言能力的任务，通常选择70B参数或更大的模型。对于“数据查询”这类任务，如果查询模式相对固定，可以用小一些的模型（7B-13B）甚至微调过的编码模型，以追求更快的响应速度。
• 上下文长度：表格的schema描述、中间结果、知识图谱查询结果都可能很长。必须选择支持足够长上下文（如128K tokens）的模型，或者设计巧妙的分块与摘要机制，确保所有必要信息都能被模型看到。

在我的项目中，我采用了混合策略：使用一个强大的开源模型（如Qwen-72B）作为“规划”和“合成”智能体的核心；对于“数据查询”智能体，则使用一个在文本到SQL任务上微调过的较小模型（如CodeLlama-13B），以优化吞吐量和成本。

提示工程是灵魂：模型本身是原材料，提示词才是塑造智能体行为的模具。一个糟糕的提示词会让最强的模型也表现失常。

• 角色定义清晰：在提示词开头，必须明确、强硬地定义智能体的角色。例如，给数据查询智能体的提示词开头可以是：“你是一个专业的数据分析师，精通SQL和Pandas。你的任务是根据用户的问题和提供的表格结构，生成准确的数据查询代码。你只能输出代码，不要有任何解释。”
• 提供结构化上下文：将表格的schema以清晰的方式提供。不要只是粘贴表头，最好用类似JSON的格式描述每个列的名称、数据类型和示例值。对于知识图谱，提供可用的API工具列表及其功能描述。
• 设定输出格式：严格要求输出格式。对于生成代码的智能体，要求其将代码包裹在特定的标记中（如sql ...）。对于生成规划或答案的智能体，可以要求其以JSON或Markdown列表的形式输出，便于后续程序化解析。
• 示例驱动：在提示词中包含几个精心设计的示例（Few-shot Learning）。展示一个复杂问题、模型应该进行的思考过程（如果是ReAct模式）、以及最终的正确输出。这是校准模型行为最有效的方式之一。
• 迭代优化：提示词不是一蹴而就的。需要准备一个测试集，包含各种边缘案例，然后观察模型的失败情况，有针对性地调整提示词。例如，如果模型总是忽略某些筛选条件，就在提示词中强调“必须严格考虑所有提及的条件”。

3.2 框架搭建：从零到一的工程实践

搭建DataFactory这样的系统，远不止是调几个API那么简单，它涉及到一整套工程架构。

1. 智能体抽象层首先，需要定义一个统一的智能体接口。无论底层用的是OpenAI API、本地部署的Llama，还是一个简单的规则引擎，对外都应提供统一的think_and_act(observation, context)方法。这为未来替换或升级模型提供了便利。

class Agent: def __init__(self, name, role_description, llm_client, tools=[]): self.name = name self.role = role_description self.llm = llm_client self.tools = tools # 智能体可以调用的工具列表 def run(self, task_input, shared_context): # 1. 构建包含角色、任务、上下文、工具描述的提示词 prompt = self._construct_prompt(task_input, shared_context) # 2. 调用LLM，获取响应（可能是思考文本，也可能是工具调用指令） llm_response = self.llm.generate(prompt) # 3. 解析响应，如果是工具调用，则执行工具并获取结果 if self._is_tool_call(llm_response): tool_name, params = self._parse_tool_call(llm_response) result = self._execute_tool(tool_name, params, shared_context) return {"action": "tool_call", "result": result, "next_thought": None} else: # 4. 如果是最终答案或中间结论，则返回 return {"action": "final_answer", "result": llm_response}

2. 工具系统工具是智能体“行动”的载体。需要设计一个工具注册和执行框架。每个工具（如query_database,search_knowledge_graph,calculate_statistics）都有明确的名称、描述、参数格式和对应的执行函数。

class Tool: def __init__(self, name, description, func): self.name = name self.description = description # 用于放入提示词，告诉LLM这个工具是干嘛的 self.func = func class ToolRegistry: def __init__(self): self.tools = {} def register(self, tool): self.tools[tool.name] = tool def execute(self, tool_name, **kwargs): if tool_name in self.tools: return self.tools[tool_name].func(**kwargs) else: raise ValueError(f"Tool {tool_name} not found.")

3. 工作流协调器这是系统的大脑。它需要维护一个任务队列或图，管理共享上下文（一个全局的字典，存储各个智能体产生的中间结果），并根据ReAct循环或预定义的流程来调度智能体。它还需要处理错误和超时。可以使用像LangChain、LlamaIndex这类框架提供的现成工作流组件，也可以基于异步编程（如Python的asyncio）自己实现一个轻量级的调度器。

4. 上下文管理共享上下文的设计至关重要。它必须能存储结构化和非结构化的数据。我通常使用一个分层的字典结构：

shared_context = { "original_question": "推荐AI实验室负责人", "plan": [{"task_id":1, "task":"filter_tech_dept", "status":"completed", "result": [...]}], "extracted_data": { "tech_employees": [...], "senior_employees": [...] }, "kg_insights": { "employee_123_ai_projects": [...] }, "current_focus": "task_4_find_ai_background" }

同时，要设计上下文压缩策略。当上下文变得太大，超出LLM的窗口限制时，需要对旧的历史信息进行摘要，只保留关键结论，丢弃细节。

3.3 知识图谱的构建与查询接口封装

对于很多项目来说，从头构建一个完整的知识图谱是不现实的。更务实的做法是，利用现有结构化数据快速构建一个“轻量级”图谱，或者直接对接已有的业务知识库。

轻量级图谱构建：如果你的数据源主要是关系型数据库，可以利用一些工具进行自动化或半自动化的映射。例如，将数据库中的表映射为图谱中的“类别”，将行映射为“实体”，将列映射为“属性”，将外键关系映射为“关系”。像D2RQ、Ontop这样的工具可以帮助完成这种映射。对于非结构化文档，可以利用实体识别和关系抽取模型来提取三元组。

查询接口封装：如前所述，避免让LLM直接生成图谱查询语句。我们应该封装一层简单的API。例如，针对员工背景查询，可以提供一个工具函数：

def find_employee_experience(employee_ids: List[str], keyword: str): """ 在知识图谱中查找指定员工是否有包含特定关键词的项目经验。 参数： employee_ids: 员工ID列表 keyword: 关键词，如“AI”、“机器学习” 返回： dict: {employee_id: [project_name1, project_name2, ...]} """ # 内部将employee_id链接到图谱实体 # 执行图查询，例如：MATCH (e:Employee)-[:WORKED_ON]->(p:Project) WHERE e.id IN $ids AND p.description CONTAINS $keyword RETURN e.id, p.name # 将查询结果组织成字典返回 pass

然后，在给智能体的工具描述中，就写：“find_employee_experience：根据员工ID列表和关键词，查找他们相关的项目经验。” 这样，智能体只需要知道调用这个工具并传递参数，完全不用关心背后的图数据库是Neo4j还是NebulaGraph，查询语言是Cypher还是Gremlin。

缓存策略：知识图谱查询可能比数据库查询更慢。对于频繁查询的实体或关系，引入缓存层（如Redis）可以极大提升系统响应速度。缓存键可以设计为查询参数的哈希值。

4. 实战演练：从问题到答案的完整流程

让我们通过一个具体的例子，走一遍DataFactory处理一个高级表格问答的全过程。假设我们有一张销售订单表，包含字段：order_id,product_name,category,sales_amount,region,order_date。同时，我们有一个产品知识图谱，存储了产品之间的替代关系、所属的战略品类等信息。

用户问题：“请分析一下，在华东地区，如果我们下个季度主推的‘智能手表’产品因为供应链问题供货不足，哪些产品可以作为备选推广重点？请综合考虑这些产品的历史销售表现和战略重要性。”

这是一个典型的复杂问题，涉及条件筛选（华东地区）、假设推理（智能手表供货不足）、外部知识（产品替代关系、战略品类）、以及多因素决策（销售表现+战略重要性）。

步骤1：问题解析与规划问题解析智能体开始工作。它分析出问题的核心要素：

• 核心任务：寻找备选推广产品。
• 约束条件：区域=华东地区；假设场景=智能手表缺货。
• 决策依据：1. 与智能手表可替代（知识图谱）。2. 历史销售表现好（表格数据：销售额高、稳定？）。3. 战略重要性高（知识图谱：属于战略品类）。
• 输出形式：一个产品列表，可能附带简要分析。

基于此，它生成一个任务计划（简化版）：

1. T1:从销售订单表中，筛选出region='华东'的所有历史记录，计算各产品的总销售额和订单数（作为销售表现指标）。
2. T2:调用知识图谱工具，查询与“智能手表”存在“可替代”关系的所有产品列表。
3. T3:将T1和T2的结果进行连接，得到在华东地区有销售记录的、且可替代智能手表的产品集合。
4. T4:对于T3中的每个产品，调用知识图谱工具，查询其是否属于“战略品类”。
5. T5:综合每个产品的销售表现指标（如销售额排名）和战略重要性（是/否战略品类），设计一个简单的评分规则（例如，战略品类加1分，销售额排名前10%加1分），对产品进行排序。
6. T6:根据排序结果，生成最终答案报告，列出Top N的备选产品，并说明理由。

步骤2-5：多智能体协作执行

• 协调器启动，创建共享上下文，放入原始问题。
• 协调器将T1分发给数据查询智能体。该智能体“思考”后，生成SQL：SELECT product_name, SUM(sales_amount) as total_sales, COUNT(*) as order_count FROM sales_orders WHERE region = ‘华东’ GROUP BY product_name ORDER BY total_sales DESC。执行后，将结果（产品销售列表）写入上下文。
• 协调器将T2分发给知识融合智能体。该智能体“思考”后，调用工具find_substitute_products(main_product=’智能手表’)。工具查询图谱，返回列表[‘运动手环’， ‘健康监测戒指’， ‘蓝牙耳机（运动款）’]。结果写入上下文。
• 协调器发现T1和T2都完成了，触发T3。这个任务可能由一个专门的数据融合智能体处理，或者由协调器直接进行程序化处理：取两个列表的交集。假设‘蓝牙耳机（运动款）’在华东没有销售记录，则交集为[‘运动手环’， ‘健康监测戒指’]。
• 协调器将T4分发给知识融合智能体，对[‘运动手环’， ‘健康监测戒指’]逐个调用工具is_strategic_product(product_name)。假设返回：运动手环是，健康监测戒指不是。
• 协调器将T5分发给一个计算与排序智能体。该智能体从上下文中读取数据：运动手环（销售额高，是战略品类），健康监测戒指（销售额中等，非战略品类）。它按照预设规则（可以写在提示词里，也可以作为一个配置化的工具）计算得分并排序。结果写入上下文。

步骤6：答案合成与交付

• 协调器将T6和全部上下文分发给答案合成智能体。该智能体“思考”后，生成如下答案： “根据分析，在华东地区，若‘智能手表’供货不足，建议优先考虑以下产品作为备选推广重点：

1. 运动手环：该产品在华东地区历史销售额表现优异（排名前5%），且属于公司定义的‘战略新兴品类’，具有较高的市场增长潜力，是首选的替代品。
2. 健康监测戒指：该产品与智能手表存在替代关系，在华东地区有一定的销售基础。虽然目前不属于战略品类，但其独特的形态和健康功能，可以作为差异化补充选项进行推广。 需要注意的是，‘蓝牙耳机（运动款）’虽可替代智能手表，但在华东地区暂无销售记录，若作为新品推广，需进行额外的市场测试和投入。”

至此，一个复杂的、需要数据查询、知识推理和综合决策的问题，通过多智能体的分工协作，得到了一个结构清晰、有据可依的答案。

5. 性能优化、常见问题与避坑指南

构建和运营这样一个多智能体系统，会遇到不少挑战。下面分享一些实战中积累的经验和教训。

5.1 延迟与成本控制策略

多智能体系统最大的开销来自对大语言模型的频繁调用。一个复杂问题可能涉及十几次甚至几十次的LLM调用，如果每次都用GPT-4，成本和延迟都会很高。

• 智能路由与模型分级：并非所有任务都需要最强的模型。可以设计一个路由层，根据任务的难度和重要性，分派给不同能力的模型。例如，简单的数据查询生成，可以用小模型或微调模型；核心的规划与合成，再用大模型。这需要对任务类型有清晰的分类和评估。
• 缓存一切可缓存的：对于相同的用户问题或高度相似的子问题，其解析出的规划、生成的查询语句很可能是相同的。可以在协调器层面引入缓存（如Redis），缓存规划结果、SQL查询语句甚至知识图谱查询结果。缓存键需要精心设计，要能捕捉问题的语义（例如，使用问题文本的嵌入向量进行近似匹配）。
• 异步与并行执行：仔细分析任务依赖图。对于没有依赖关系的子任务（如T1和T2），一定要让它们并行执行，而不是串行。这要求你的协调器和智能体客户端支持异步调用。
• 上下文压缩与摘要：这是控制成本（特别是对于按Token收费的API）和突破模型上下文长度限制的关键。当共享上下文变得庞大时，可以训练一个小的“摘要智能体”，或者使用LLM自身，对历史对话、中间数据进行摘要，只保留核心结论，丢弃冗余细节。例如，将几千行的销售数据摘要成“产品A销售额领先，产品B增长最快”这样的几句话。

5.2 稳定性与错误处理

智能体可能出错，工具调用可能失败，网络可能超时。系统必须具备鲁棒性。

• 智能体超时与重试：为每个智能体的运行设置超时时间。如果超时，协调器可以决定重试（可能换一种提问方式）、降级（换一个更简单的模型或规则）或失败。重试时最好能带上一些错误信息，帮助模型调整。
• 工具调用的防御性编程：所有工具函数都必须有完善的异常处理。数据库查询可能语法错误或连接失败，知识图谱API可能返回异常。工具执行结果应统一封装为{“success”: bool, “data”: …, “error”: “…”}的格式。
• 结果验证与回退：对于关键步骤的结果，可以引入验证机制。例如，数据查询智能体生成的SQL，可以先在一个“沙箱”环境或通过语法检查器进行验证，再正式执行。如果答案合成智能体生成的答案明显不合理（例如，包含“抱歉，我无法回答”这样的模型拒绝词），协调器可以触发一个回退流程，比如让另一个智能体进行复核，或者直接向用户返回一个更友好的错误信息。
• 规划阶段的可行性检查：问题解析智能体生成的规划，有时可能包含无法执行的任务（例如，要求查询一个不存在的列）。可以在规划生成后，增加一个“可行性检查”步骤，由协调器或一个专门的智能体，对照可用的工具列表和表格schema，快速校验规划是否可执行，提前发现并修正问题。

5.3 效果评估与持续迭代

如何知道你的DataFactory系统好不好？需要建立评估体系。

• 构建测试集：收集一批具有代表性的复杂表格问答对，涵盖不同的业务场景和问题类型。这是评估的黄金标准。
• 定义评估指标：
  • 答案准确性：最终答案与标准答案在事实层面是否一致？这可以通过字符串匹配、关键信息抽取对比或人工评分来衡量。
  • 规划合理性：生成的子任务计划是否逻辑清晰、步骤完整？可以请领域专家评审。
  • 工具调用准确率：生成的查询代码或API调用参数是否正确？
  • 端到端成功率：从问题输入到成功返回一个合理答案的请求占比。
• A/B测试与用户反馈：在内部或小范围用户中上线，对比新系统与旧方案（或人工处理）的效果。收集用户的直接反馈和交互日志，分析用户常问的问题类型、系统常出错的环节。
• 持续迭代点：
  • 提示词优化：根据错误案例，持续调整各智能体的提示词，增加针对性的示例和约束。
  • 工具增强：如果发现某个知识经常被问到但图谱中没有，就考虑扩充图谱或增加新的工具函数。
  • 流程优化：如果发现某些类型的任务总是走一个复杂且低效的规划路径，可以考虑为这类任务设计一个专用的、优化过的“宏”或“模板”，让规划智能体直接调用，跳过不必要的分解步骤。

5.4 几个常见的“坑”与应对

1. 智能体“幻觉”与胡说八道：这是LLM的通病。在DataFactory中，危害尤其大，因为一个智能体的错误输出会成为下一个智能体的输入，导致错误传播和放大。

   • 应对：严格限制智能体的输出格式，强制其以结构化数据（JSON）或代码形式输出，减少自由发挥的空间。在关键节点（如最终答案生成前）引入“事实核查”步骤，让另一个智能体或规则程序去校验核心数据（如销售额数字）是否与原始表格数据一致。

2. 上下文管理混乱：随着对话轮次和任务步骤增多，上下文会变得极其冗长和混乱，导致模型性能下降或遗漏关键信息。

   • 应对：实施严格的上下文修剪和摘要策略。只保留最近几步的详细记录，更早的步骤只保留其最终结论。可以设计一个“上下文管理器”角色，专门负责维护上下文的简洁和有效。

3. 系统响应过慢：用户无法接受一个简单问题等上分钟才出结果。

   • 应对：除了前述的缓存、并行、模型分级策略，还可以实现“流式输出”。对于答案合成，可以让模型先生成一个大纲或核心结论，快速返回给用户，然后再逐步补充细节。给用户一个“系统正在思考”的进度提示，也能改善体验。

4. 对模糊问题的处理能力弱：用户的问题常常不精确，比如“卖得好的产品”。什么是“好”？是销售额最高，还是增长率最快？

   • 应对：在问题解析阶段，可以设计一个“澄清智能体”。当它检测到问题中存在模糊概念时，不是直接猜测，而是生成一个澄清问题列表，通过交互界面反问用户。例如：“请问您指的‘卖得好’，是看总销售额最高，还是同比增长率最快？” 这虽然增加了交互轮次，但能极大提升最终答案的准确性和用户满意度。

构建DataFactory这样的系统是一个持续迭代和优化的过程。它没有一劳永逸的解决方案，更像是在打造一个不断学习和进化的数字员工团队。从最简单的两个智能体协作开始，逐步增加角色、完善工具、优化流程，并根据真实的业务反馈不断调整，是通往成功最可行的路径。