尧图网页设计 
一、复杂工作流的任务组织方式增强型、链式和路由式架构已经能够覆盖大量 Agent 场景。当任务继续增长以后会出现三类更复杂的需求多个独立任务需要同时执行任务数量需要根据输入动态确定以及生成结果需要经过反复检查和修改。这些需求分别对应并行工作流、协调器工作流和评估优化工作流。三种架构的共同点是开始显式管理任务执行过程。系统需要决定任务如何拆分、如何并发、如何评估。二、并行工作流的并发执行并行工作流适用于多个子任务之间不存在直接依赖的情况。┌→ Task A ─┐ Input ─────┼→ Task B ─┼→ Aggregate → Output └→ Task C ─┘例如一份企业分析报告可以分别处理财务、产品和风险信息。三个任务之间没有严格先后顺序就可以并行执行最后由聚合节点统一整理。另一种并行方式让多个模型对同一个问题分别生成结果再进行汇总。其目的主要是利用多个独立结果进行交叉参考使结果更全面准确。并行工作流最直接的收益是降低总执行时间。三个独立任务串行需要依次等待并行执行时总耗时更接近其中最慢的任务。并行也会增加 Token 和计算成本因此任务之间必须真正具有独立性。为了“使用多 Agent”而让多个模型重复做同一件事很容易得到高成本、低增益的系统。三、协调器工作流的动态任务拆分固定并行结构要求开发者提前知道需要执行哪些任务。现实中的复杂请求往往不具备这种确定性。同一个系统可能同时收到简单查询和大型研究任务两者需要的步骤数量完全不同。【非常适用于用户Query Rewrite负责解决拆分后的多个子任务】协调器工作流在前面增加一个任务规划节点Input ↓ Coordinator ↓ 动态任务列表 ↓ Workers ↓ Aggregate协调器会根据用户输入动态生成后续子任务并决定需要调用几个执行节点。【相对于前述架构协调器的设计往往难度更大】例如用户要求“分析一个自然碳项目的开发条件”Coordinator 可以生成方法学、空间数据、碳量和风险等多个子任务一个简单的“项目在哪里”只需要执行地理信息查询。这种设计的价值在于让计算资源与任务复杂度匹配。同时协调器必须设置明确的控制条件。最大任务数量、最大模型调用次数、超时和成本预算都需要限制否则动态拆分容易演化成不可控的任务膨胀。四、评估优化工作流的反馈迭代评估优化架构用于对输出质量要求较高的任务。它通常包含生成器和评估器两个角色Generator ↓ Evaluator ↓ 通过 → Output ↓ 未通过 ↓ Feedback ↓ Generator以论文内容生成作为示例。生成模型首先产出内容评估模型检查完整性和质量。如果发现数据没有来源或者内容缺失就把反馈返回生成器继续修改直到满足条件。这种结构比在一个 Prompt 中加入大量“必须准确、必须完整”的要求更加清晰。Evaluator 可以拥有独立评价标准生成器根据明确反馈进行修订。需要注意模型评估仍然具有不确定性。能够通过代码完成的检查应优先使用确定性规则。例如 JSON 字段是否完整、数字是否超出范围、引用格式是否存在都可以直接程序校验。语义完整性、文章结构和表达质量等问题再交给模型判断。五、复杂架构的成本与可靠性权衡从控制方式、延迟、可靠性、适用场景和开发复杂度对不同工作流进行比较。Agent 架构实际上是在三个维度之间做选择。第一是延迟。链式和评估循环通常增加执行时间并行可以降低独立任务的总时长。第二是成本。每增加一次模型调用都会增加 Token 消耗。第三是可靠性。增加检查和反馈机制可以提高结果可控程度但系统本身会更加复杂。因此一个任务不应该因为“重要”就自动使用最多 Agent。需要判断错误成本是否值得额外模型调用。六、不同工作流的组合方式真实 Agent 系统通常同时使用多种模式。一个复杂请求可以先由 Router 判断业务类型再由 Coordinator 拆分任务多个 Worker 并行完成子任务最后通过 Evaluator 检查最终输出。例如用户请求 ↓ Router ↓ Research Agent ↓ Coordinator ↓ 并行 Workers ↓ Aggregator ↓ Evaluator ↓ 最终答案这种结构很强但开发和调试成本同样明显。因此架构组合应该逐步演化。首先确认单一模型和少量 Tool 是否能够解决问题再根据真实 Bad Case 增加新的控制机制。七、总结并行工作流解决独立子任务的并发执行协调器工作流解决动态任务拆分评估优化工作流解决生成结果的持续检查与修正。三种结构分别对应效率、任务规划和质量控制三个问题。复杂 Agent 设计最终可以归纳为一个原则根据任务结构增加必要的控制机制并为每一层复杂度找到明确业务理由。当系统中的每一个 Router、Coordinator、Worker 和 Evaluator 都能够回答“它解决了什么具体问题”时Agent 架构才真正具有工程价值。 复杂 Agent 工作流设计：并行、协调与评估优化机制
一、复杂工作流的任务组织方式增强型、链式和路由式架构已经能够覆盖大量 Agent 场景。当任务继续增长以后会出现三类更复杂的需求多个独立任务需要同时执行任务数量需要根据输入动态确定以及生成结果需要经过反复检查和修改。这些需求分别对应并行工作流、协调器工作流和评估优化工作流。三种架构的共同点是开始显式管理任务执行过程。系统需要决定任务如何拆分、如何并发、如何评估。二、并行工作流的并发执行并行工作流适用于多个子任务之间不存在直接依赖的情况。┌→ Task A ─┐ Input ─────┼→ Task B ─┼→ Aggregate → Output └→ Task C ─┘例如一份企业分析报告可以分别处理财务、产品和风险信息。三个任务之间没有严格先后顺序就可以并行执行最后由聚合节点统一整理。另一种并行方式让多个模型对同一个问题分别生成结果再进行汇总。其目的主要是利用多个独立结果进行交叉参考使结果更全面准确。并行工作流最直接的收益是降低总执行时间。三个独立任务串行需要依次等待并行执行时总耗时更接近其中最慢的任务。并行也会增加 Token 和计算成本因此任务之间必须真正具有独立性。为了“使用多 Agent”而让多个模型重复做同一件事很容易得到高成本、低增益的系统。三、协调器工作流的动态任务拆分固定并行结构要求开发者提前知道需要执行哪些任务。现实中的复杂请求往往不具备这种确定性。同一个系统可能同时收到简单查询和大型研究任务两者需要的步骤数量完全不同。【非常适用于用户Query Rewrite负责解决拆分后的多个子任务】协调器工作流在前面增加一个任务规划节点Input ↓ Coordinator ↓ 动态任务列表 ↓ Workers ↓ Aggregate协调器会根据用户输入动态生成后续子任务并决定需要调用几个执行节点。【相对于前述架构协调器的设计往往难度更大】例如用户要求“分析一个自然碳项目的开发条件”Coordinator 可以生成方法学、空间数据、碳量和风险等多个子任务一个简单的“项目在哪里”只需要执行地理信息查询。这种设计的价值在于让计算资源与任务复杂度匹配。同时协调器必须设置明确的控制条件。最大任务数量、最大模型调用次数、超时和成本预算都需要限制否则动态拆分容易演化成不可控的任务膨胀。四、评估优化工作流的反馈迭代评估优化架构用于对输出质量要求较高的任务。它通常包含生成器和评估器两个角色Generator ↓ Evaluator ↓ 通过 → Output ↓ 未通过 ↓ Feedback ↓ Generator以论文内容生成作为示例。生成模型首先产出内容评估模型检查完整性和质量。如果发现数据没有来源或者内容缺失就把反馈返回生成器继续修改直到满足条件。这种结构比在一个 Prompt 中加入大量“必须准确、必须完整”的要求更加清晰。Evaluator 可以拥有独立评价标准生成器根据明确反馈进行修订。需要注意模型评估仍然具有不确定性。能够通过代码完成的检查应优先使用确定性规则。例如 JSON 字段是否完整、数字是否超出范围、引用格式是否存在都可以直接程序校验。语义完整性、文章结构和表达质量等问题再交给模型判断。五、复杂架构的成本与可靠性权衡从控制方式、延迟、可靠性、适用场景和开发复杂度对不同工作流进行比较。Agent 架构实际上是在三个维度之间做选择。第一是延迟。链式和评估循环通常增加执行时间并行可以降低独立任务的总时长。第二是成本。每增加一次模型调用都会增加 Token 消耗。第三是可靠性。增加检查和反馈机制可以提高结果可控程度但系统本身会更加复杂。因此一个任务不应该因为“重要”就自动使用最多 Agent。需要判断错误成本是否值得额外模型调用。六、不同工作流的组合方式真实 Agent 系统通常同时使用多种模式。一个复杂请求可以先由 Router 判断业务类型再由 Coordinator 拆分任务多个 Worker 并行完成子任务最后通过 Evaluator 检查最终输出。例如用户请求 ↓ Router ↓ Research Agent ↓ Coordinator ↓ 并行 Workers ↓ Aggregator ↓ Evaluator ↓ 最终答案这种结构很强但开发和调试成本同样明显。因此架构组合应该逐步演化。首先确认单一模型和少量 Tool 是否能够解决问题再根据真实 Bad Case 增加新的控制机制。七、总结并行工作流解决独立子任务的并发执行协调器工作流解决动态任务拆分评估优化工作流解决生成结果的持续检查与修正。三种结构分别对应效率、任务规划和质量控制三个问题。复杂 Agent 设计最终可以归纳为一个原则根据任务结构增加必要的控制机制并为每一层复杂度找到明确业务理由。当系统中的每一个 Router、Coordinator、Worker 和 Evaluator 都能够回答“它解决了什么具体问题”时Agent 架构才真正具有工程价值。