Agent Build Note

本文基于：https://www.anthropic.com/engineering/building-effective-agents

构建高效智能体：从确定性工作流到自主系统的架构演进

1. 引言：生成式人工智能的工程化转折与范式重构

在当今的人工智能技术浪潮中，大语言模型（LLM）的飞速发展已经从单纯的模型能力竞赛，逐渐转向了更为务实且复杂的系统工程竞赛。如果说 GPT-3 的出现标志着“提示词工程”（Prompt Engineering）的诞生，那么随着模型推理能力、上下文窗口以及工具调用能力的显著增强，我们正处于一个新的历史转折点——“智能体工程”（Agent Engineering）的崛起。

Anthropic 的研究团队在24年12月发布的深度分析文章《构建高效智能体》（Building Effective Agents）为这一转折点提供了极为关键的理论支撑和实践指南 1。这不仅仅是一份技术文档，更是一份关于如何在不可预测的概率模型与确定性的软件系统之间架起桥梁的工程宣言。本报告将基于该核心文献，为技术领导者、系统架构师及高级人工智能开发者提供一份详尽的、百科全书式的知识图谱。我们将深入剖析智能体系统的本体论定义，解构五大核心架构模式的内在逻辑与适用边界，并探讨确保这些自主系统在生产环境中安全、可靠运行的工程哲学。

本报告旨在超越表层的技术复述，深入挖掘每一个架构模式背后的第二层级和第三层级洞察。我们将探讨为什么简单的可组合模式往往优于庞大的黑盒框架？为什么“延迟”可以作为换取“准确性”的货币？以及如何通过“反向设计”工具接口来适应模型的认知特性。通过这份报告，读者将获得从构建实验性原型到部署大规模生产级智能体系统的全方位战略视野。

2. 本体论界定：工作流（Workflows）与智能体（Agents）的二元光谱

在深入具体的架构模式之前，我们必须首先清理当前 AI 领域中混淆不清的术语体系。Anthropic 的研究极具洞见地提出了一个二分法（或更准确地说是光谱的两端），即“工作流”与“智能体” 1。理解这一区别，是所有架构决策的基石。

2.1 工作流：确定性的代码编排

在光谱的一端是工作流（Workflows）。这是一种以代码为中心的系统架构。在工作流中，大语言模型（LLM）扮演的角色更像是一个极其智能的“函数调用”或“数据转换器”，而不是系统的“大脑”。

系统的控制流——即任务执行的步骤、条件分支、错误捕获机制以及数据流向——完全是由开发者在预定义的代码路径（Predefined Code Paths）中硬编码确定的 1。开发者确切地知道系统在第 1 步会做什么，在第 2 步会调用什么工具，以及在遇到特定错误时会跳转到哪一行代码。

这种架构的核心价值在于**可预测性（Predictability）*与*一致性（Consistency） 1。由于路径是固定的，系统的行为边界被严格限制。无论输入如何变化，处理流程的骨架保持不变。这使得工作流非常适合那些定义明确、边界清晰、对结果的标准化要求极高的任务。例如，一个用于生成每日财报摘要的系统，其流程固定为“数据抓取 -> 数据清洗 -> 摘要生成 -> 格式化输出”，每一个环节的连接都是刚性的。

2.2 智能体：模型驱动的动态决策

在光谱的另一端是智能体（Agents）。这是一种以模型为中心的系统架构。在这里，LLM 获得了“驾驶权”。它不再仅仅是被调用的子程序，而是成为了系统的编排者和决策者。

智能体系统的工作方式是：开发者设定一个高层次的目标（例如“帮我策划一次去日本的旅行”），然后由 LLM 动态地决定需要执行哪些步骤、按照什么顺序执行、调用哪些工具（如搜索引擎、航班预订API、酒店数据库），以及如何处理中间出现的意外情况

这种架构的核心价值在于**灵活性（Flexibility）**和**自主性（Autonomy）**。LLM 可以根据任务的实时反馈调整策略，处理那些在代码编写阶段无法预见的非结构化、开放式问题。然而，这种能力的代价是丧失了部分可预测性。由于 LLM 的输出本质上是概率性的，同一个任务在不同时间的执行路径可能完全不同，这给测试、调试和质量控制带来了巨大的挑战。

2.3 架构选择的辩证法：奥卡姆剃刀原则

Anthropic 的工程实践揭示了一个深刻的真理：在 AI 系统设计中，存在一种过度追求“全自主智能体”的危险倾向。许多开发者试图构建一个万能的通用智能体来解决所有问题，结果往往陷入调试的泥潭。

报告建议遵循“奥卡姆剃刀”原则：始终从最简单的解决方案开始。如果在工作流（Workflow）能够解决问题的时候，绝对不要引入智能体（Agent）1。只有当任务的复杂性使得预定义路径变得不可能（例如，步骤的数量和类型完全取决于输入内容）时，才应考虑赋予模型自主决策权。

通过组合简单的模式来构建系统，而不是一开始就依赖复杂的框架，可以让开发者更清晰地掌控系统的行为，并在性能、成本和可靠性之间找到最佳平衡点。

3. 核心架构模式深度解析：构建智能系统的五块基石

Anthropic 识别并提炼了五种构建 AI 系统的核心模式 1。这些模式并非互斥的，而是可以像乐高积木一样灵活组合。它们涵盖了从简单的线性处理到复杂的递归优化的全景图。

3.1 模式一：提示词链 (Prompt Chaining) —— 以时间换取质量的线性逻辑

3.1.1 机制解构

提示词链（Prompt Chaining）是最基础也是最强大的工作流模式。其核心思想是将一个庞大、复杂的任务分解为一系列线性的、顺序执行的子任务。在实现上，**前一个 LLM 调用的输出（Output）直接作为下一个 LLM 调用的输入（Input）的一部分 **

这种模式背后的逻辑基础是认知负载理论。就像人类在同时处理多项任务时容易出错一样，LLM 在面对一个包含多个隐含步骤的复杂指令时，其推理能力也会下降。通过拆解任务，我们实际上是在降低每个独立环节的“熵”，让模型能够在一个更窄、更明确的上下文中集中算力。

3.1.2 深度洞察：延迟与准确性的交易市场

提示词链本质上是在进行一场交易：我们愿意牺牲一定的系统响应速度（增加延迟），来换取最终结果的准确性和可靠性。

在单次 Prompt 中处理复杂任务时，模型往往会忽略指令的某些细节，或者在长上下文中产生幻觉。通过链式结构，每一环都是一个天然的“检查点”（Checkpoint）。例如，在生成文案和发布文案之间插入一个“合规性审查”环节，可以有效拦截潜在的风险。

此外，提示词链还解决了上下文窗口的限制问题。在处理长文档时，我们可以先提取关键信息，再将精简后的信息传递给下一步，而不是在每一步都拖着沉重的原始文档。这种**“信息蒸馏”**机制显著提升了系统的效率。

3.1.3 应用场景与案例分析

多阶段内容创作：

1 提到的一个典型案例是“生成并翻译营销文案”。如果我们要求模型“用西班牙语写一段关于新款跑车的营销文案”，模型可能会因为同时兼顾“创意构思”和“语言翻译”而顾此失彼，导致文案既不地道也不吸引人。

采用链式模式：
1. Step 1 (Ideation): 使用英文（或模型最擅长的语言）根据产品特性生成核心营销文案。此时模型只需专注于创意。
2. Step 2 (Translation): 将生成的文案翻译成西班牙语。此时模型只需专注于语言转换。
3. Step 3 (Localization): 根据西班牙当地的文化习俗调整措辞。
  
  这种分步处理不仅提高了每一以步的质量，还使得调试变得简单——如果翻译有问题，我们只需调整 Step 2 的 Prompt，而不必担心破坏 Step 1 的创意逻辑。
基于大纲的文档生成：
这也是我最推崇的开发模式，先使用深度搜索来寻找可能的技术路径，然后生成大纲，进行最小可行性测试，之后再尽可能细化开发文档（只有在自己明确知道该怎么做时再交给ai去做，才不会出错，经过ai几次迭代之后进行项目备份和文档更新（文档应尽可能详细的写明整个项目的架构和关键fuction的实现逻辑），如此往复迭代推进开发

先生成文档大纲，经人工或自动验证确认无误后，再将大纲作为输入，逐章生成具体内容。这避免了模型在写作过程中“跑题”或结构混乱。

3.2 模式二：路由 (Routing) —— 关注点分离与成本优化的艺术

3.2.1 机制解构

路由（Routing）模式引入了“分类”与“分流”的概念。系统首先接收用户的输入，通过一个“路由器”（通常是一个轻量级的 LLM 或专门训练的分类器）对输入进行分析和归类，然后将其导向特定的下游处理路径

这就像是一个繁忙的呼叫中心总机，根据用户按下的按键（或语音识别结果），将电话转接给专门负责“技术支持”、“账单查询”或“新业务办理”的专员。

3.2.2 深度洞察：专业化分工与经济学模型

路由模式的深层价值在于它实现了关注点分离（Separation of Concerns）。在没有路由的系统中，我们往往被迫编写一个庞大的、面面俱到的 Prompt 来处理所有可能的用户请求。这种 Prompt 维护极其困难，且容易因为指令冲突导致性能下降。通过路由，下游的每个处理单元只需专注于一类特定的任务，可以使用高度定制化、高度优化的 Prompt。

更重要的是，路由模式是实现成本效益最大化的关键手段。在 AI 工程中，并非所有任务都需要最顶级的模型Anthropic指出，通过路由，我们可以将简单的、低风险的任务（如一般的问候、简单的事实查询）分流给更小、更便宜、更快的模型（如 Claude Haiku）；而将复杂的推理、创意写作或代码生成任务分流给更强大但昂贵的模型（如 Claude Sonnet 或 Opus）。这种分层策略可以在不牺牲用户体验的前提下，将系统的运营成本降低数倍甚至更多。

3.2.3 应用场景与案例分析

智能客户服务系统：
- 用户输入：“你好，我想重置密码。” -> 路由判定：简单指令 -> 转发给小模型，直接返回预设的重置链接和指南。
- 用户输入：“我的云服务器昨天半夜突然宕机了，日志显示有内存溢出，但我检查了监控并没有异常，这是怎么回事？” -> 路由判定：复杂技术故障 -> 转发给大模型，并挂载技术文档库和日志分析工具。
- 用户输入：“我要投诉你们的服务！” -> 路由判定：情绪安抚/高优先级 -> 转发给专门的情感处理模块或人工客服通道。
多模态意图识别：

根据用户输入是纯文本、包含代码片段还是包含图片，路由到相应的处理管道。例如，如果包含图片，则路由到具备视觉能力的模型路径。

3.3 模式三：并行化 (Parallelization) —— 速度与视角的双重奏

3.3.1 机制解构

并行化（Parallelization）模式打破了线性处理的桎梏。它允许 LLM 同时在多个独立的线程或进程上处理任务的不同方面，最后通过编程方式将这些并行的输出聚合成最终结果

1	这点再深度搜索时很有必要，我们往往需要多个来源的信息综合给到顶级模型来处理输出

3.3.2 深度洞察：从串行等待到并发协同

并行化主要解决两个核心痛点：处理速度和结果的可信度。

速度（通过分段 Sectioning）：对于超长文档的分析或大规模数据的处理，单次串行处理不仅耗时，而且容易受到上下文窗口的限制。通过将任务切片（例如将一本书按章节切分），并行地交给多个 LLM 实例处理，可以成倍地缩短总的处理时间（Wall-clock time）。
可信度（通过投票 Voting）：这是并行化模式更高级的应用。由于 LLM 的输出具有随机性，单一的输出可能包含错误或偏见。通过让模型对同一个问题运行多次（可能使用不同的 Prompt 变体、不同的温度设置，甚至完全不同的模型），然后对结果进行“投票”或“加权平均”，可以有效消除偶然性误差，获得更稳健的结论。这类似于机器学习中的“集成学习”（Ensemble Learning）思想。其中的数学原理可理解为概率分布的稳定

3.3.3 应用场景与案例分析

实时内容风控（Guardrails）：

在传统的串行模式下，必须先运行“审核模型”检查用户输入是否违规，通过后再运行“生成模型”回复。这会带来双倍的延迟。

采用并行化模式：系统同时启动“回复生成”和“内容审核”两个任务。
- 线程 A：生成对用户的回复。
- 线程 B：检查输入是否存在恶意攻击、敏感词或越狱尝试。
  
  如果线程 B 发现违规，系统可以瞬间拦截线程 A 即将发送的回复，并替换为拒绝提示。这种机制在不牺牲用户体验（低延迟）的同时保证了安全性
全方位代码审查：

针对一段代码，并行启动三个专注于不同领域的审查 Agent：
- Agent 1：专注于安全性（Security），寻找 SQL 注入、XSS 等漏洞。
- Agent 2：专注于性能（Performance），寻找内存泄漏、低效算法。
- Agent 3：专注于可读性（Style），检查代码规范和注释。
  
  最后将三者的审查报告汇总，给出一个全面的 Code Review 结果。

3.4 模式四：编排者-工作者 (Orchestrator-Workers) —— 动态规划与层级化管理

3.4.1 机制解构

这是典型的**智能体（Agent）**架构，也是从“工作流”迈向“自主系统”的关键一步。在这种模式中，存在一个中心化的 LLM —— 编排者（Orchestrator）。它的职责不是直接执行具体的任务，而是充当“项目经理”的角色。

编排者分析用户的复杂请求，将其动态拆解为若干个子任务，然后根据子任务的性质，指派给特定的工作者（Workers） LLM 去执行。每个工作者可能配备了不同的工具或拥有不同的系统提示词。最后，编排者收集所有工作者的产出，将其综合（Synthesize）成最终的答案 1。

3.4.2 深度洞察：应对“未知的未知”

与“提示词链”不同，编排者-工作者模式中的子任务序列不是预先定义好的。编排者是根据运行时的输入动态决定需要哪些步骤的。这使得系统能够处理那些结构未知、高度复杂的任务。

动态规划能力：编排者必须具备强大的推理能力，能够理解任务之间的依赖关系（例如，必须先完成任务 A 的数据搜集，才能进行任务 B 的数据分析）。
上下文管理：编排者维护着全局的上下文和状态，而工作者只在局部的上下文中运行。这有效地解决了长上下文带来的“迷失”问题，因为每个工作者只需处理与其任务相关的信息。
复杂性封装：对于用户而言，系统是一个统一的接口，但在内部，可能调用了数十次不同的模型和工具。

3.4.3 应用场景与案例分析

复杂软件工程任务：

用户请求：“将网站所有页面的主题色从蓝色改为红色，并更新所有相关的图标文件。”

这是一个极其模糊且涉及广泛的任务，无法用简单的线性链条解决。

Orchestrator 的思考过程：
1. 我需要先找到所有定义颜色的文件 -> 指派 Worker A (File Searcher) 搜索 CSS/SCSS 文件。
2. 我需要找到所有蓝色的图标 -> 指派 Worker B (Image Analyzer) 扫描图片目录。
3. 收到 Worker A 的列表 -> 指派 Worker C (Code Editor) 逐个替换颜色变量。
4. 收到 Worker B 的列表 -> 指派 Worker D (Design Tool) 生成新的红色图标。
5. 最后，指派 Worker E (Tester) 运行测试脚本验证更改。
  
  1 强调，这种涉及多个文件、多种操作类型且具体的修改点无法预知的任务，是编排者模式的最佳舞台。
深度市场调研报告：

编排者决定分别搜索“最近的新闻报道”、“股市历史数据”、“竞争对手财报”和“社交媒体舆论”，分别指派给擅长搜索、擅长数据分析、擅长文本总结的 Workers，最后由编排者汇总写出报告。

3.5 模式五：评估者-优化者 (Evaluator-Optimizer) —— 模拟人类专家的自我迭代闭环

3.5.1 机制解构

这是一个循环迭代的模式，代表了当前智能体工程的高级形态。在这种模式中，包含两个核心角色（可以由两个不同的 LLM 扮演，也可以是同一个 LLM 的不同人格）：

生成者（Generator）：负责产生初步的解决方案或草稿。
评估者（Evaluator）：负责对生成者的产出进行严格的批评、打分和反馈。

系统进入一个“生成 -> 评估 -> 优化 -> 再评估”的闭环，直到满足预设的评估标准（如评分达到 9/10，或不再发现逻辑错误）1。

3.5.2 深度洞察：利用判别力优于生成力的不对称性

这一模式建立在一个深刻的 AI 理论基础之上：LLM（以及人类）识别错误的门槛通常远低于生成完美答案的门槛。

就像我们要写出一篇诺贝尔文学奖级别的文章很难，但要指出一篇文章写得枯燥乏味却很容易一样。LLM 在充当“批评家”时往往比充当“作家”表现得更敏锐。通过让 LLM 自己批评自己（Self-Correction），或者让一个更强的模型批评一个小模型，我们可以迫使系统不断逼近完美的极限。

收敛性挑战：设计该模式的关键难点在于设定清晰的停止条件（Stop Conditions）。如果评估标准过高，系统可能陷入无限循环；如果过低，则失去了优化的意义。通常需要结合最大迭代次数作为兜底。
质量质变：对于翻译、代码编写、数学推理等对准确性要求极高的任务，这一模式往往能带来性能的质的飞跃。

3.5.3 应用场景与案例分析

文学级翻译：

1 提到了文学翻译的例子。翻译不仅仅是词义对应，更涉及语气、潜台词和文化隐喻。
1. Generator：生成初稿。
2. Evaluator：指出“这句话语气太生硬，不符合原文的讽刺意味”或“这个成语用错了”。
3. Generator：根据反馈重写。
  
  经过三轮迭代，译文的信达雅程度将远超单次生成。
复杂搜索与问答：

当用户询问一个需要综合多处信息的问题时：
1. Agent 搜索并生成回答。
2. Evaluator 判断：“这个回答没有覆盖用户关于‘2023年之后’的时间限制要求。”
3. Agent 收到反馈，针对性地补充搜索 2023 年后的信息并更新回答。

4. 工程实践指南：驯服概率系统的野马

架构模式只是蓝图，要将蓝图变为现实并在生产环境中稳定运行，需要严谨的工程实践。Anthropic 的研究特别强调了可靠性（Reliability）、测试（Testing）和工具设计的重要性。由于智能体本质上是概率性的，它们比传统的确定性软件更容易发生“级联故障”。

4.1 简单性原则与迭代式开发

在工程界，“过早优化是万恶之源”，而在 AI 界，“过早引入代理（Agentic）复杂性”则是灾难之源。

直接调用优先：1 强烈建议开发者在使用 LangChain、AutoGPT 等高级框架之前，先尝试直接使用 LLM 的原生 API 进行开发。只有直接与模型对话，才能真正理解模型的边界、延迟特性和原始能力。框架往往封装了太多魔法，导致调试时无法定位是模型笨还是框架逻辑错。
循序渐进：从最简单的 Prompt 开始 -> 进阶为 Prompt Chaining -> 需要逻辑分支时引入 Routing -> 只有在任务确实需要动态规划时才升级为 Orchestrator-Workers。每增加一层复杂性，都必须有明确的测试数据证明其带来了性能提升。

4.2 透明度（Transparency）与可观测性

智能体系统是一个“黑盒”在指挥另一个“黑盒”。如果不把过程透明化，调试将无从下手。

显式思维链（Explicit Chain of Thought）：系统设计应强制要求智能体在采取行动前输出其规划步骤。例如，不要让模型直接调用工具，而是先输出：“我需要先查询天气，因为用户的请求依赖于实时天气状况。”这不仅有助于开发者 Debug，还能让最终用户看到系统在“思考”，从而增加信任感 1。
详细的追踪日志：记录每一次 LLM 调用的输入、输出、Token 消耗、延迟以及工具调用的参数。

4.3 智能体-计算机接口 (ACI) 的设计哲学

我们习惯了为人设计 GUI（图形用户界面），为程序设计 API，现在我们需要为智能体设计 ACI（Agent-Computer Interface）。

工具定义即提示词：工具的名称、描述、参数说明不再仅仅是给人看的文档，它们直接就是 Prompt 的一部分，是模型理解世界的窗口。必须像打磨 System Prompt 一样精心打磨工具定义。描述不清会导致模型产生幻觉，误用工具 1。
模型友好型格式：1 提出了一个非常具体的建议：避免让模型在 JSON 结构中编写转义代码。
- Bad Practice: 要求模型输出 {"code": "print('hello world')\nif x > 1:..."}。这种大量转义字符的格式极易导致模型出错。
- Good Practice: 允许模型直接在 Markdown 代码块中输出代码，然后由解析器提取。或者设计容错性更强的参数格式。

4.4 防错设计 (Poka-yoke)

借鉴丰田生产方式中的“防错”（Poka-yoke）理念，我们应该通过系统设计让模型“想犯错都难”。

强制约束：例如，在设计文件操作工具时，不要允许模型使用相对路径（如 ./config.json），因为模型往往搞不清当前的运行目录在哪里。强制要求使用绝对路径，或者在工具内部自动补全路径，可以从根本上杜绝“File Not Found”错误 1。
枚举与类型检查：对于有限选项的参数，在工具定义中使用枚举（Enum）限制模型的输出范围。

4.5 沙盒环境与安全护栏

智能体具有自主行动能力（如写入文件、发送邮件、执行代码），这意味着它们也具有破坏能力。

严格沙盒（Sandboxing）：所有的执行环境必须是隔离的。例如，使用 Docker 容器或轻量级虚拟机来运行模型生成的代码。绝不能让智能体直接访问宿主机的敏感文件系统 1。
人机协同（Human-in-the-loop）：对于高风险操作（如批量删除数据、发送大额转账、发布公开声明），必须设置“中间人确认”机制。智能体可以起草方案并准备好工具调用，但最终的“执行”信号必须由人类发出。
大规模回归测试：由于单次运行成功不代表系统可靠，必须建立包含数千个测试用例的自动化评估集，反复运行以统计“成功率”。

5. 结论与未来展望

构建高效的 AI 系统不再是单纯的模型选择题，而是一道复杂的架构填空题。Anthropic 的《构建高效智能体》一文为我们指明了方向：从确定性的工作流出发，审慎地引入自主性的智能体模式。

5.1 关键洞察总结

架构决定下限，模型决定上限：一个设计良好的“提示词链”工作流配合中等模型，往往比一个设计混乱的“全自主智能体”配合顶级模型表现更稳定、更实用。
模式的组合效应：真正的威力来自于模式的嵌套。我们可以在“编排者”内部使用“路由”，在“工作者”内部使用“评估者-优化者”。
工程严谨性回归：随着 AI 开发进入深水区，传统的软件工程原则——模块化、测试驱动、关注点分离——不仅没有过时，反而变得比以往任何时候都更加重要。

5.2 决策建议

对于企业技术决策者：不要被“Agent”的炒作迷惑。在审批 AI 项目时，优先通过“工作流”解决 80% 的标准化业务，仅在那些高价值且高度非标准化的场景中探索“智能体”。
对于开发者：掌握这五大模式（提示词链、路由、并行化、编排者-工作者、评估者-优化者）是当前阶段的核心竞争力。学会“降维打击”——如果能用简单的 Prompt Chaining 解决，就不要用复杂的 Orchestrator。

未来，随着模型推理成本的进一步降低（如摩尔定律在 AI 领域的重现），我们预见到“评估者-优化者”模式将成为标配——因为通过消耗更多的计算资源（多轮迭代）来换取更高质量的输出，将变得在经济上极具吸引力。同时，ACI（智能体接口）标准化的争夺战即将打响，谁定义了模型最容易调用的工具标准，谁就掌握了智能体生态的入口。

构建智能体不仅仅是代码的编写，更是对机器认知边界的探索与规训。遵循这些原则，我们将能够构建出不仅聪明，而且真正有用、可靠、安全的智能系统。

附录：五大核心架构模式对比速查表

为了便于读者在实际工程中快速决策，我们将五大模式的核心特性、适用场景及复杂度整理如下：

架构模式	核心逻辑特征	优势分析	典型应用场景	实施复杂度
1. 提示词链 (Prompt Chaining)	线性顺序 (A -> B -> C) 上一步输出即下一步输入	• 分解复杂度：降低每一步的认知负载 • 易于调试：错误定位清晰 • 检查点：中间步骤可人工介入	• 长文案生成与多语言翻译 • 基于大纲的文档写作 • 数据提取与格式化	⭐ (低)
2. 路由 (Routing)	分支选择 (Input -> Classifier -> A/B/C)	• 关注点分离：特定任务用特定 Prompt • 成本优化：按需调用大小模型 • 性能提升：避免通用 Prompt 的平庸	• 智能客服意图分流 • 多模态输入处理 • 简单/复杂任务分层处理	⭐⭐ (中)
3. 并行化 (Parallelization)	并发聚合 (A & B & C -> Aggregation)	• 速度提升：大幅降低长任务延迟 • 视角多样：通过投票机制减少幻觉 • 全面性：多维度同时检查	• 实时内容风控（审核+生成） • 大规模文档切片分析 • 多维度代码/合同审查	⭐⭐ (中)
4. 编排者-工作者 (Orchestrator-Workers)	动态分发 (Manager -> Worker A/B/C)	• 灵活性：处理结构未知的任务 • 上下文管理：各工作者专注局部信息 • 综合能力：整合多源异构数据	• 复杂代码工程（多文件修改） • 深度市场调研与情报综合 • 开放式问题解决	⭐⭐⭐ (高)
5. 评估者-优化者 (Evaluator-Optimizer)	循环迭代 (Gen <-> Eval -> Final)	• 质量飞跃：利用判别力优于生成力的特性 • 自我修正：模拟人类的审稿过程 • 高精度：逼近模型能力极限	• 文学级翻译 • 高难度算法代码生成 • 复杂逻辑推理与数学证明	⭐⭐⭐ (高)

演示网页

查看演示网页

DisplaceStation

How to Biuld Effect Agent