AI 厂商 Anthropic 将 AI 工作流定义为一种结构化、逐步推进的过程，在其中“LLM 与工具通过预定义的代码路径被编排（orchestrated）”。但 AI 工作流不应与智能体混为一谈。智能体可能会在途中动态调整——一旦遇到意料之外的情况就重路由其计划；而 AI 工作流通常沿着固定路径运行，把数据从一个阶段引导到下一个阶段。这种逐步执行可以简化监督与故障排查，使工作流在“简单性比智能体所提供的灵活性更重要”的场景中成为更合乎逻辑的选择。
这种相互作用——AI 工作流的预定义特性与智能体更动态、更自我驱动的能力之间的对比——揭示了更广泛领域可能的走向。在一些情况下，智能体实际上可以在“幕后”嵌入完整的 AI 工作流，把自治性与结构性融合在一起。真正的问题不是谁会胜出，而是两者各自如何以最佳方式为一个更聪明、更敏捷的 AI 生态系统做贡献。
定义 AI 工作流（Defining AI Workflows）
AI 工作流提供一种把语言模型整合进更大流程的结构化方法。它不是让每次模型调用或工具调用各自为政，而是以一种定义清晰、也许更易理解的方式把它们串联起来，从而减少自研 AI 实验中常见的无序感。
AI 工作流让原本复杂、彼此依赖的大语言模型（LLM）调用，可以被拆解为多个更小的阶段。一个单一的业务需求——例如自动化生成一组多语言营销素材——可以被分解为若干子任务：提示生成、语言翻译、情绪/倾向检查，以及最终聚合。这种拆分不仅简化了每一步在 LLM 执行中的角色，也有助于隔离问题：如果某一步的准确性开始漂移，你可以聚焦那一个阶段，而不是把整条工作流都翻一遍。
然而，预定义工作流的刚性意味着“临场适应”会很困难。如果出现了意外的输入类型，或数据偏离了预期范围，工作流可能没有内建机制来处理异常。这个短板在一种情况下尤其棘手：当后续阶段高度依赖前序阶段的正确输出时——某一步出错可能一路级联到最终结果。
从这个意义上说，AI 工作流处在“临时拼凑的探索性实验”与“更高级的自治智能体”之间的关键中间地带。它们依赖一套清晰的架构，在多个阶段协调 LLM 与专用工具。
常见的 AI 工作流类型（Common Types of AI Workflows）
AI 工作流可以遵循多种模式，每种模式适用于不同任务与组织需求。本节将展开几类被广泛使用的模式，包括提示链（prompt chaining）、路由（routing）、并行化（parallelization）、反思（reflection）与编排（orchestration）。
我们使用同一个场景让例子更具象——一个简化版的银行开户流程：客户希望开立一种或多种不同类型的账户。端到端动作包含若干步骤：
- 身份验证（Identity verification）
检查并确认客户确实是其自称的那个人 - 了解你的客户（KYC）
收集文档并确认客户的银行画像与风险画像 - 首次入金（Initial deposit）
实际开立账户并完成资金存入 - 通知（Notification）
通知客户其账户已开立
提示链（Prompt Chaining）
提示链（见图 3-1）把一个高层目标分解成一系列更小的 LLM 任务。一个提示可能生成初稿，第二个提示把文本翻译为目标语言，第三个提示验证文风与语气。每一步把上一阶段的输出作为下一阶段的输入。
图 3-1. 提示链（Prompt chaining）
其核心思路是：通过一串结构化的提示来引导 LLM 的思考过程，每个提示都建立在上一个结果之上。这种方法提供了“导轨”，使最终输出更连贯、更全面，尤其适用于需要多层推理或创意的任务。
在我们的场景中，我们从用户请求开始：
我想开一个新的活期账户……
这会导向一个高层提示：
你是银行的客服 AI。一位名为 John Doe 的客户想开一个新的活期账户。请确认他的身份（已提供并验证身份证明文件），执行 KYC 审查（未发现问题），处理 500 美元的首次入金，然后给出一条简短的最终消息，确认账户已开立且余额为 500 美元。提供任何相关的后续步骤或联系方式。
在一条指令里，LLM 被期望完成：
- 校验身份并确认已验证
- 确认 KYC 无异常
- 处理 500 美元入金
- 为客户撰写最终确认消息
LLM 必须在一个提示内自行处理这些步骤，并判断每一步具体包含什么。
图 3-2 的右侧展示了如何把它拆解成更小的部分：与其让 LLM 自己推导底层细节，不如使用一组更细的、逐步推进的提示；并按需让某一步的输出成为下一步的输入。
身份验证：
我们收到 John Doe 的以下身份证明文件：[描述证件细节]。请验证 John Doe 的身份并确认所有文件齐全无误。
输出： AI 确认证件有效并完成身份核验。
KYC 检查：
John Doe 的身份核验状态为已验证。现在基于以下个人与财务信息执行基础 KYC 审查：[提供相关信息]。完成后总结 KYC 状态。
输出： LLM 执行 KYC，未发现问题，并确认 John Doe 通过 KYC。
首次入金：
KYC 结果为：未发现问题。John Doe 希望存入 500 美元以开立新的活期账户。请处理入金并确认交易。
输出： LLM 处理入金并确认新账户余额为 500 美元。
通知：
基于已验证身份、已通过 KYC、且已确认 500 美元入金，请生成一条给 John Doe 的精简最终消息。在消息中确认账户已开立，提及 500 美元余额，并包含后续步骤或客服联系方式。
输出： AI 生成面向客户的最终确认消息，涵盖所有细节。
通过提示链，LLM 会被引导着走完开户流程的每一步，映射现实世界的手续：核验证件、KYC 审查、处理入金、发出确认。
在每个阶段，AI 的输出都会成为下一条提示的基础。这带来更强的透明度与控制力，降低跳步的概率，并帮助每一阶段保持清晰。
路由（Routing）
路由工作流会对进入的查询或数据点进行分类，并把它导向某个专门模型或流程。图 3-2 的示例展示：如何使用路由模式根据客户需求开立一种银行产品账户（此处是活期账户）。
图 3-2. 路由模式（Routing pattern）
我们的原始用户请求不变：
我想开一个新的活期账户……
但在这种情况下，我们的 AI 工作流能够处理多种账户类型。基于提示链示例，路由示例将能处理多种不同产品类型。提示如下：
如果是活期账户，则运行“活期账户开立链”。如果是储蓄账户，则运行“储蓄账户开立链”。如果是投资账户，则运行“投资账户开立链”。
这种方法建立在一个直觉之上：为某一领域（如退款）微调的 LLM，未必擅长另一个领域（如缺陷报告）。路由确保每个请求进入正确的“车道”，从而提升整体响应质量。
引入路由有几个优势：
- 灵活性
当组织支持更多产品（这里是银行产品）时，不必为所有场景维护一个巨大的提示；而是为每个产品维护专用链路。 - 适配目的（Fit for purpose）
每条工作流都可以针对其特定用例做优化。 - 更好的客户体验
用户获得更相关的提示与更正确的指引，减少困惑与出错概率。
不过，由于路由依赖准确分类，它也会引入新的失败点与复杂度：如果路由器误判输入，就会把请求送进不合适的路径。团队往往通过训练一个独立的轻量分类器，或设置一个兜底路径来处理模糊情况，以降低风险。
并行化（Parallelization）
AI 工作流的并行化（见图 3-3）是一种组织与执行方式：让多个步骤或任务同时进行，而不是按顺序一个接一个执行。提示不再串行喂入，而是被拆开，每一块并行处理。等所有小任务完成后，再把结果汇总并组合成最终输出。
图 3-3. 并行化模式（Parallelization pattern）
这一次，用户请求略有变化：客户希望同时开多个账户：
我想开活期、储蓄和投资账户……
在前面的路由示例基础上，并行化示例会被改造为：并行处理各产品的提示，并在完成后聚合结果：
- 提示 P1：运行“活期账户开立链”。
- 提示 P2：运行“储蓄账户开立链”。
- 提示 P3：运行“投资账户开立链”。
- 以及……
- 聚合： 汇总前面步骤的结果并继续。
当 AI 工作流的不同部分彼此不依赖，或可以轻易拆分时，并行化尤其有用。它能加速计算，更好利用可用算力，并提升吞吐量。
需要注意的是，并行化通常会降低总处理时间，但会抬升协调难度。设计上必须以有序方式聚合或对齐多个 LLM 实例的输出，这可能需要额外逻辑或集成（ensemble）方法。
编排（Orchestration）
在编排模式（见图 3-4）中，一个 LLM（编排者，orchestrator）会动态拆解任务，并把每一部分委派给一组“工人”LLM。与并行化不同——并行化的任务是预定义且并发运行的——编排模式允许编排者动态适应：根据输入的内容或复杂度来决定需要哪些子任务。
图 3-4. 编排模式（Orchestration pattern）
沿用并行化示例，我们展示如何用编排模式实现它。我们仍可使用并行化中的同一用户请求：
我想开活期、储蓄和投资账户……
但此时编排者会用一个类似下面这样的提示（来自任务规划器）来创建任务计划：
John Doe 提出了请求……为该请求创建并执行一个任务计划……
编排动作可能生成类似下面的任务计划：
- 通用步骤：身份核验与 KYC 审查
- 针对每个产品的并行步骤（见并行化提示）
- 聚合结果
- 通知客户账户已开立
通过把子任务委派给专门化或独立的 LLM 实例，编排者能够处理那些不适合固定步骤序列的复杂问题。这种方法在效率与灵活性之间取得平衡：编排者负责规划，而子任务负责执行更窄的任务范围，每个子任务都可以拥有量身定制的提示或指令集合。它也简化调试：如果某个子任务失败，你可以隔离并修正那一块，而不必扰动整个系统。
需要注意的是，每增加一个决策点，就会多一个“运动部件”，从而提升编排者与工人之间误传信息的风险。显然，必须进行谨慎设计，以防出现循环依赖或无限循环，因为编排逻辑必须考虑到工人返回的意外响应与边界情况。
反思（Reflection）
LangChain 将反思定义为一种策略：“通过提示 LLM 反思并批判其过去的行动，有时还会整合额外外部信息，例如工具观测（tool observations）。”
继续我们的场景，如图 3-5 所示，我们用反思模式发起请求，但会验证结果，并在需要时对请求进行返工。
反思模式会提示 AI 系统在继续之前暂停、分析并批判其先前行动。与优先追求效率与即时输出的直接工作流不同，反思插入了一个刻意的自我评估阶段，使 LLM 能够重新审视先前回答，并在必要时加以修正。反思可以是内部的（自我分析），也可以是外部的（引入更多上下文、工具反馈或人类输入）。
图 3-5. 反思模式（Reflection pattern）
这一模式受到心理学中“系统 1 与系统 2 思维”的启发，该概念由 Daniel Kahneman 在《Thinking, Fast and Slow》中提出。系统 1 思维快速、直觉、自动化——类似标准 LLM 通常的生成方式；系统 2 思维则更慢、更审慎、更具分析性——对应反思型工作流引入的行为。
反思帮助 AI 系统跳出系统 1 式的快速响应限制，转向系统 2 式的推理：更谨慎地复核自己的工作。这种反思可改进：
- 准确性
通过促使模型复查推理过程，反思有助于减少常见的 LLM 幻觉或事实性错误。 - 连贯性
当 AI 花时间批判并精炼输出时，回答会更结构化、更合逻辑。 - 对边界案例的韧性
能自我反思的模型更不容易重复犯错，也能在面对模糊或误导性输入时自我纠正。
这种方法尤其适用于知识密集、风险高的应用场景，如法律文档审查、医疗诊断或科学研究——在这些场景中，正确性比响应速度更重要。
反思的主要代价是更高的计算成本与延迟。由于每一轮循环都需要额外处理步骤，低延迟应用（如聊天机器人或实时辅助工具）可能并不适合这种方法。相反，反思更适用于“准确性第一、响应时间其次”的场景。
此外，反思依赖结构良好的评估提示——如果自我批判提示很弱，反思过程可能不会带来有意义的改进。开发者必须谨慎设计反馈回路，确保系统识别并修正真实错误，而不是对琐碎细节过度优化。
AI 工作流的挑战（Challenges with AI Workflows）
所有基于 LLM 的解决方案都建立在概率型（probabilistic），也就是非确定性（nondeterministic）的模型之上。这意味着：对同一个输入，输出可能会出错（即使概率很低）、也可能不可复现；而且在相同输入下得到“名义上不同”的输出是常见现象（不过，通过谨慎调整 LLM 参数并精心设计提示，这种差异是可以被尽量压小的）。
换句话说，非确定性本质上是 LLM 的问题；但由于 AI 工作流与其 LLM 绑定得如此紧密，它也就变成了 AI 工作流的问题。正是这一根本性问题，引发了实践层面的黑盒、扩展与边界案例等挑战。
“黑盒”问题（The “Black Box” Issue）
即便工作流的步骤定义得很清楚，LLM 的内部机制仍可能是不透明的。开发者也许知道每个阶段该调用哪个模型，但往往并不清楚 LLM 是如何得出某个具体结果的。这种缺乏透明度会削弱信任，尤其是在金融或医疗等高风险领域，可解释性（explainability）至关重要。
这带来一个实质性挑战：Anthropic 曾表示，他们“通常把 AI 模型当作黑盒：输入进去、输出出来，但不清楚为什么模型会给出这个响应而不是另一个。这让人很难相信这些模型是安全的：如果我们不知道它们如何工作，怎么知道它们不会给出有害、有偏见、不真实或其他危险的响应？我们如何相信它们会安全且可靠？”
Anthropic 还补充说：“打开黑盒也未必有用：模型的内部状态——也就是模型在写出响应之前‘在想什么’——由一长串数字（‘神经元激活’）构成，但并没有清晰的含义。”
这为什么重要？我们预计企业，尤其是受监管行业的企业，会在监管与合规上遇到障碍：当底层机制不可解释时，它们将难以为模型决策做出合理说明或形成文档。由于所有 AI 工作流实现都基于概率型 LLM，它们也会在问题诊断与故障排查上面临困难。当出现异常输出时，如果 LLM 的决策过程不透明，就很难精确定位并调试错误来源（尽管我们会在本书后续展示一些降低这类错误的方法）。
扩展性挑战（Scaling Challenges）
多步骤 AI 工作流最大的脆弱点之一，是链路前段引入的错误会在后续步骤被放大。例如，在路由工作流中，一个被误分类的请求可能被送入错误的执行分支，进而把不匹配的输出喂给下一步，最终导致整个流水线产生毫无用处甚至误导性的结果。随着工作流复杂度提升，这种“滚雪球效应”会变得更严重。
在提示链中，第一条提示里被忽略的错误——例如对用户目标的误解——会让所有后续步骤都建立在错误解释之上，因而整体变形。同样地，在并行化工作流中，一个有问题的子流程可能污染或与聚合结果相矛盾，迫使下游步骤去调和冲突或无效的数据。当这些工作流被规模化到每天处理成千上万、乃至数百万请求时，这些微小的初始错误就可能产生连锁反应，影响极大范围的输出。
更麻烦的是，我们前面提到的 LLM 黑盒特性会进一步加剧扩展问题。开发者可能无法充分理解或预判 LLM 为什么会生成某个特定响应，因此追踪精确的失效点会变得困难。团队往往不是遇到一个单一、显而易见的 bug，而是发现错误症状分散在工作流的不同部分。如果缺乏透明的推理线索或有效的调试策略，就会显著更难定位到底是哪一环出了问题，更别说修复它。
当组织尝试把这些工作流做大时，就可能撞上一道“实践天花板”：诊断并修正这些分布式错误的运维成本会变得难以承受。若工作流设计者不在每个处理阶段建立健壮的检查、保险丝（fail-safe）与监控，一致性与可靠性就会逐步被侵蚀。这些措施可能包括：人类在环（human-in-the-loop）检查点、自动异常检测工具、或在进入下一步前验证中间输出的门禁（gates）。但这些缓解手段往往会引入额外复杂度与开销，逐步蚕食 AI 工作流所承诺的效率收益。
归根结底，“错误放大”问题叠加“可解释性不足”，会阻碍 AI 工作流的广泛采用，尤其当它们不可避免地变得更复杂时。解决这一问题需要审慎的架构设计、前置的错误处理，以及一套战略性的调试方法：确保链路的每一环都被监控与验证，从而避免错误级联成灾难性的错误输出。
处理边界案例（Handling Edge Cases）
AI 工作流的预设步骤在问题空间定义清晰时效果最好：每一步都假设某类输入，并导向可预测的输出。然而实践中，这种预期未必成立。用户可能用意料之外的格式提供信息，或提出开发者从未想到要预判的问题，从而暴露出一个“难以偏离脚本路径”的系统的边界。
尽管 LLM 擅长解释含糊或不完整的提示，但当它被放在预置工作流中执行时，这种适应性也有上限。模型可以理解自然语言指令、捕捉用户请求的细微差别；但如果工作流设计本身并不容纳新场景，LLM 的响应可能到不了“正确的目的地”。换句话说，无论模型看起来多“智能”，它的输出仍沿着同一条静态路径前进，可能错过相关步骤或跳过关键的防护措施。
这种问题在边界案例上尤为突出——那些不常见、罕见、落在预期使用模式之外的情况。以金融相关工作流为例，开发者可能会规划身份验证或风险评估等任务，但未必会考虑意外的货币格式，或来自某个小众司法辖区的冷门法律限制。当这些异常情况出现时，工作流没有内建分支去处理它，结果要么出错，要么需要临时的人类介入。
除了运维上的不便，为了处理边界案例而引入的复杂度也可能抑制 AI 应用的增长与演进。随着系统在时间推移中遇到新的数据类型，开发者必须手动新增或调整工作流步骤来适配——这既繁琐又容易出错。工作流结构的刚性因此会成为创新的瓶颈：组织不得不不断打补丁或重构流水线，而不是让系统在实时中平滑适应变化。
“优雅、一致且透明地处理边界案例”的需求，凸显了 AI 系统在可预测性与灵活性之间的微妙平衡。预定义工作流非常擅长控制错误率并保证一致性，但它为这种控制付出的代价是适应性受限。当组织扩展其 AI 能力时，可能会发现不断更新静态路径的成本变得不可持续。在这种情况下，引入更动态的组件——或把工作流编排与有限的智能体特性进行融合——可以帮助系统随着需求变化与意外情形一起演进。
对比 AI 工作流与智能体（Comparing AI Workflows and Agents）
如图 3-6 所示，当今的 AI 开发主要围绕两种方法展开：我们前面一直在讨论的 AI 工作流，以及 智能体。AI 工作流通过结构化流水线来编排一系列 AI 操作；其中可以包含条件逻辑与动态元素，但整体仍遵循由开发者设计的架构。相比之下，AI 智能体使用由 LLM 驱动的推理来理解目标、规划路径并自主做出决策，从而能够处理那些未被显式编程的新情况，并能基于上下文与反馈调整策略。
图 3-6. AI 工作流 vs 智能体
从设计上看，AI 工作流在“环境已被充分理解”的场景中表现出色：每条路径与各种应对预案都在事前被写清楚，因此结果更可预测（或者至少其执行路径是可被充分理解的）。但同样的特征也意味着工作流可能缺乏灵活性，因此当面对未预见的边界案例时容易失灵。如果新数据偏离最初假设，系统可能缺乏内建的敏捷性来适应——而这恰恰是基于智能体的模型可能具备优势的地方。尽管存在这些挑战，AI 工作流通过“逐步推进”的方法提供了清晰与简洁，这在一个越来越关注 AI 透明性的时代里正显得尤为有价值。
在智能体这一侧，真正的自治依然是一个持续的挑战。但现代 LLM 现在已经具备更复杂的推理能力，使得智能体比工作流更容易适应新条件，并且为更广泛的自治提供了一条可行路径。需要强调的是，正是这种推理能力让 AI 智能体能够理解上下文、解释含糊指令，并生成新的应对方案。
不过，在今天，一个常被忽视的事实可能是：这些智能体很可能仍运行在某种“隐式的类工作流路径”之中，只是它们拥有更灵活的“决策节点”，允许分支行为。那种“在任何情况下都能做任何事”的完全自由仍在建设中——尽管进展正在非常快速地发生。
显然，两种方法各自都有挑战。工作流在环境以未预期的方式变化时可能崩溃，需要更新与新增决策分支；智能体尽管承诺更强的适应性，但在数据超出其已学习参数的情况下，仍可能产生幻觉或出现缺乏监督的错误。因此，无论是工作流还是智能体，都需要健壮的反馈机制——无论是人类在环复核、错误监控，还是自适应再训练。
还有一点需要考虑：从性能角度看，组织往往用吞吐量、可靠性以及逐步指标（如完成率或错误频率）来衡量工作流。由于工作流结构化的设计，定位改进点通常比较直接。另一方面，智能体在度量上引入了更多复杂性：其结果可能更显著地波动，因此需要新的指标——例如它们在边界案例上的适应能力，或在新数据到来时成功“自我纠正”的频率。
智能体对 AI 工作流的扩展（Agents Extend AI Workflows）
Anthropic 将智能体定义为：“LLM 会动态地引导其自身的流程与工具使用，并保持对其如何完成任务的控制。”Anthropic 还补充说：“一旦任务明确，智能体会独立规划并运行，并可能在需要更多信息或判断时回到人类。”
智能体与 AI 工作流的关键区别在于：智能体会自主且独立地规划并执行工作；而 AI 工作流则按照工作流创建者预先制定的一组指令来执行。话虽如此，当引入更复杂的模式（如编排与反思）时，智能体与 AI 工作流之间的分界线会变得模糊。
AI 工作流与智能体还有其他差异：
- 打包与容器化（Packaging and containerization）
现代架构设计让智能体可以成为 AI 工作流的“容器”。这种容器化提供了一种更灵活、更健壮的方式来打包、实现与部署 AI 工作流。 - 简化交互（Simplified interactions）
这种更健壮的实现方式提供了多种选择，使智能体之间更易交互。 - 企业级能力（Enterprise-grade capabilities）
智能体为 AI 工作流提供了一个更丰富的容器，使其更容易适配企业级期望。 - 扩展（Scaling）
当采用企业级能力后，就更容易运用通用的扩展技术，使智能体生态系统更容易增长。 - 生态系统集成（Ecosystem integration）
借助容器化与更简化的交互模型，智能体可以更容易融入更大的生态系统——agentic mesh。
先从打包与容器化说起。AI 工作流通常被实现为一个 Python 主程序（一个包含多个 import 的 Python 程序），并作为操作系统中的单一进程运行。这当然可以用多种方式扩展，但最常见的方式是把 AI 工作流打包成一个易于部署的容器。不过，如果缺少通用框架，这样做效率并不高（而且很可能带来技术债）。
智能体就是这样的框架。它提供了多种选项，把 AI 工作流打包成容器或部署单元。你不必自己手工去容器化一个 AI 工作流；智能体框架往往开箱即用。例如，智能体可以被打包为微服务、容器或其他模块化部署单元。
接下来，这种通用的打包方式也让智能体之间的交互更容易。例如，可以添加 API，使智能体到智能体、或智能体到生态系统的交互具备一致且定义清晰的通信方式，并通过 OpenAPI/Swagger 规范来描述。再一次，这些事情当然可以手工完成，但既然智能体框架能替你完成，何必自己折腾？
同样基于这种通用打包方式，智能体还允许我们把关键的企业级能力——如安全性、可观测性与可运维性——一起打包进去。这种做法与企业软件的常见实践对齐，使组织更容易把智能体集成进更大的微服务架构中。本质上，每个智能体都可以成为企业 IT 生态系统中的一个节点，通过 API 与标准消息协议交换数据。简单说，智能体提供了交付企业级能力的最短路径。
当规模增长到一定程度，扩展就会成为问题。使用“微服务友好”的方式来打包智能体，意味着企业可以拉起多个智能体实例，每个实例专注于不同任务。一个智能体的多个副本可以并发运行在不同容器中，并根据需求独立地扩容或缩容。
最后一点也非常重要：在未来几年里，我们坚信大量专门化智能体的涌现，将为一个更大规模的互联 AI 生态系统打下基础。正是前述这些要素的组合——更易实现、交互更简化、并能融入更广泛的企业环境——使智能体得以支撑我们称之为 agentic mesh 的不断增长的智能体生态。
总结（Summary）
本章展示了：AI 工作流与智能体是相关但不同的两种“编排智能”的方法。工作流通过预定义步骤引导任务，从而提供可靠性与透明性；智能体带来适应性与自治性，能够适应新条件并从上下文中学习。两者都无法完全取代对方——相反，当可预测性至关重要时，工作流提供结构；而智能体则用推理与灵活性扩展这种结构。二者共同构成正在形成的 AI 生态系统的基础。
在第 4 章中，我们将从“对比工作流与智能体”转向“更深入地、以智能体自身的方式理解智能体”。我们会探索是什么让智能体不同于工作流：它的自治性、规划能力、工具使用、与其他智能体的协作，以及学习能力。通过把智能体建立在人类类比之上——对话、团队、组织与生态系统——我们将看到智能体并非静态工作流，而是更大智能网络中的动态、可适应参与者。
