智能体带来了一组架构层面的挑战，而传统软件设计从来就不是为解决这些挑战而生的。传统应用运行在高度限定的上下文里：接收输入，按预先设定的工作流运行，然后给出输出。当问题可预测、规则清晰时，这套模型运转得很好。但智能体面对的是另一种现实：它们必须在开放式环境中行动——信息可能不完整，情境可能突变，而下一步几乎不可能在事前就一目了然。
要在这种条件下有效运作，智能体需要普通应用所不具备的能力。它们必须能在缺少持续人工指导的情况下自主决策；当出现新的数据或约束时，能够动态调整计划；并且以既协同又高效的方式与其他智能体合作。同样重要的是，它们必须在长时间交互中维持连贯一致的行为，使得某一时刻的决策仍与先前确立的目标与上下文保持一致。这些要求使得自主性、适应性与持久性成为核心设计考量。
满足这些需求，不能只靠对现有软件实践做增量改良。我们需要一种结构化的智能体架构方法——把自主、协同与连续性视为基本设计原则，而不是事后补丁。本章提出的正是这样一种方法：给出一个框架，用来构建不仅能孤立地完成任务，而且能在复杂环境中扩展运行的 AI 智能体。
本章将从塑造智能体行为的核心原则开始，介绍一种结构化的智能体架构方法。这些原则——可信性、可靠性、可解释性等——既是实践中的路标，也是“护栏”，帮助确保智能体的行为能反映我们的价值观（包括企业价值观）、满足监管要求，并与运营层面的期望保持一致。
在此基础上，我们将审视构成智能体架构的关键组件：驱动决策的大语言模型（LLM）、扩展功能能力的工具，以及支持智能体管理长时任务的记忆系统。我们还将概述消息模型与协作模式，使智能体能够在分布式环境中工作——既可以独立运行，也可以作为更大系统的一部分协同运行。上述要素共同构成技术基础，使智能体能在真实世界的条件下有效运作。
为了把这些概念放进具体语境，我们引入四类智能体：任务导向型、目标导向型、仿真型、观察者型，它们各自适配不同的问题域。随后我们讨论在规模化开发、部署与运营智能体时需要考虑的事项，包括工具集成、策略（policy）执行与状态管理。本章最后会把这些概念应用到我们的案例研究中，通过一个假想实现把架构与概念“演起来”。
智能体原则
“原则”常常被误以为是模糊而抽象的东西。但一个好的原则，是一种基础性的指导准则：它界定价值，塑造决策与行为，在复杂系统的设计与评估中提供路标与护栏。原则帮助组织把抽象目标翻译成可操作的成功标准，从而在不同团队与技术之间保持一致性与连贯性。
技术会变化，监管会收紧或放松，业务优先级也必然会调整；但原则是稳定的参照点，帮助组织在不确定性中做选择。把决策锚定在持久的价值上，而不是短暂的趋势上，原则就能确保智能体的设计与运行在长期内保持一致。正是这种“耐久性”，让团队可以更自信地创新：工具与语境会变，但指引方向的“罗盘”不变。
总之，原则建立了一套共享词汇，使各方围绕共同期待达成对齐，减少歧义，并推动协同行动。
对智能体而言，原则尤其重要：智能体可能以最小的人类监督自主行动，并且常常会影响关键业务结果。清晰的智能体原则能把智能体引导到符合组织价值、监管要求与伦理规范的结果上。把这些原则内嵌到智能体设计中，我们——社会、组织、开发者——就能理解并管理风险，建立利益相关方信任，并确保 AI 驱动的流程与战略目标保持一致。
我们的智能体架构很大程度上围绕四项关键原则展开，如图 5-1 所示。它们指导智能体“能做/该做什么”，设定智能体“如何做它应该做的事”的期望，并为解释“为什么它这么做”提供依据。
图 5-1. 智能体原则
在我们看来，智能体的重要原则包括：
- 可信且可问责
智能体必须透明地遵循其使命（purpose），并遵守企业、伦理或监管政策。智能体必须能够被问责，以证明其可信。 - 可靠且耐久
智能体必须给出准确结果——可类比“五个九”级别的准确率，并将幻觉降到最低。（在运营语境中，五个九指标——例如 99.999%——表示某个平均准确率或其他成功指标的比率。）智能体必须能够延续持续很久的对话（分钟、小时、天或更长），并在发生错误时恢复。 - 可解释且可追溯
智能体必须提供可重复的结果。智能体的活动必须完全透明：每一步、每个工具、或每个协作智能体，都应可供审阅（因此也应可解释）。每个提示词（prompt）都应可获取；所有工具与智能体活动的结果都必须可追溯。 - 可协作且智能
智能体必须能够自主且智能地与其他智能体（以及工具）协作以完成任务。
可信且可问责
智能体必须遵循其定义好的使命，并与既定的企业、伦理与监管政策保持一致。对“规定使命”的刻意聚焦，为可信系统奠定基础：行动与决策的一致性，会在用户与利益相关方之间建立信心。
这一原则只有一个简单目的：通过确保每个智能体都能在既定边界内、以可预测方式运行，来培养利益相关方的信心。事实就是：当组织、监管者与终端用户确信智能体会按预期行事时，他们更愿意使用智能体。反之亦然：他们很可能不会使用一个自己无法理解或无法信任的智能体。
在这个信任框架中，“运行边界”的清晰性是关键要素。通过遵循规定使命与由清晰政策施加的约束，智能体能把偏离预期、引发非预期后果的风险降到最低。对运行边界的严格遵守，使智能体行为更可预测，减少歧义，并让信任得以生长——因为所有参与方都理解智能体行动的范围与限制。
清晰带来透明。能够记录并公开其决策过程、输入与输出的智能体，会形成一种运行环境：审查不仅可行，而且被默认应该发生。透明使持续的复核与评估成为可能，既强化内部治理框架，也让外部利益相关方放心——智能体确实在按预期行事。
透明之所以是可信系统的基石，是因为它为智能体活动提供了可公开审阅的记录。当智能体清楚地发布决策形成的过程，我们就能在每个层级对这些过程进行充分审查。这种开放不仅加固了健壮的内部治理，也为外部利益相关方提供证据，用来验证系统是否可靠、是否合乎伦理，最终增强对输出的信心。
为了进一步提升信任，认证框架变得至关重要。我们建议采用一种方法（见图 5-2），其建模方式类似当今全球正式标准组织所使用的流程。例如，在美国由 Underwriters Laboratories（UL） 承担这一功能，在加拿大由 Canadian Standards Association（CSA） 承担这一功能。当然，我们也要说明：采纳本节定义的端到端步骤可能会引入复杂性，因此并非所有智能体都需要，尤其是在低风险环境下的智能体。然而可以预期的是，随着智能体接管更重要的任务与角色，我们将要讨论的这些步骤中，相当一部分——甚至全部——都会被采用。
图 5-2. 智能体认证流程
自主智能体的认证流程从一份申请开始。申请包含详细的技术文档，概述智能体的使命、政策、架构、算法、决策过程与预期运行参数。这份初始提交让评估方（例如组织的治理团队或第三方）能够详细理解智能体的设计，以及它与既定企业、伦理与监管政策的对齐程度。
评估方随后对提交材料进行严格审查，重点关注设计规格、风险评估与对已发布政策的合规性。在这一阶段，可能会制定一套测试协议，用于模拟智能体的运行环境，确保其行为在贴近真实使用情境与潜在边界案例的条件下被评估。
经认可的测试环境在这一流程中扮演重要角色。类似于产品测试中的实验室认可，这些环境被验证满足对可靠性与可重复性的标准预期，从而支持对智能体性能进行客观测试，尤其是在透明性、错误率与对既定运行边界的遵守方面。
完成初步评估后，将启动迭代式复核流程。开发者与评估方紧密合作，修复测试中发现的偏差或问题。这可能包括改进算法、增强决策过程的透明性，并通过追加测试验证智能体持续满足所需标准。
流程还可能包含对智能体部署环境的审查。这一步验证运行设置——例如数据源、与外部系统的集成、以及监控机制——是否与技术文档、以及组织的政策与标准完全一致。
当智能体成功通过测试与环境检查后，将获得正式认证。该认证对外证明：智能体在性能、透明性、可靠性以及伦理与监管政策合规方面，达到或超过预先定义的标准。认证对利益相关方而言是一个基准，也是一种公开的质量信号。
认证还会通过发布详细指标与合规报告进一步加固。这些文档描述测试结果、检查发现与持续合规状态。通过公开这些记录，流程促进透明性，并让利益相关方能够持续验证智能体的性能与对标准的遵守情况。
认证流程通过持续的监督计划来维持，包括定期审计与周期性复评。持续监控确保智能体即使在运行语境变化时，仍能保持对既定标准的合规。
我们相信，信任——对智能体本身以及对其所运行生态的信任——将是落地采用的关键。因此，要在智能体驱动系统中建立可信性，需要一种多维度的方法：清晰的运行使命、透明性，以及对既定政策的纪律化遵循。再叠加一个健壮的认证框架——包含认可机制、公开标准、可量化指标与第三方审计——就能用可验证的合规证据进一步强化信任。这种综合方法不仅能在今天赢得利益相关方信心，也为长期的持续改进与可靠性奠定基础。
可靠且耐久
在关键业务环境中，智能体必须交付精确、一致的输出，并满足严格的性能标准。这些高标准对于确保智能体在面对复杂或动态任务需求时仍保持可依赖性至关重要。在那些错误可能带来显著运营或财务后果的应用场景中，这种可靠性尤其关键。
实现高可靠性——比如五个九（99.999%）——意味着智能体必须能在多种条件下正确执行任务。这包括处理输入数据的变化、适应意外的运行情景，并在性能不显著退化的情况下持续维持表现。
耐久性同样重要，尤其对需要进行长时交互的智能体而言。智能体必须在较长持续时间内维持运行性能——无论任务持续分钟、小时还是数天——而不出现性能退化或上下文丢失。这样，即使任务跨越很长时间，智能体仍能保持连贯性并持续提供准确输出。本章后续将讨论如何在长周期内管理对话与任务。
要达到这些高标准，智能体的设计与测试流程必须严苛且全面。这包括在模拟运行条件下进行压力测试，以及采用持续集成与持续部署（CI/CD）实践，以支持持续的性能评估。
监控系统在维持高可靠性与耐久性方面也发挥关键作用。持续监控让我们能够实时跟踪性能指标，并快速发现偏离预期行为的情况。通过高级分析与自动告警，智能体生态的监控可以确保任何性能问题都被及时处理，从而长期维持高水平的可靠性。
可解释且可追溯（Explainable and Traceable）
自主智能体中的可解释性概念（见图 5-3），根植于这样一种需求：我们必须理解智能体是如何得出其决策的。鉴于 LLM 支撑着智能体的许多功能，而 LLM 天生具有非确定性（nondeterminism），因此就需要一个系统能清晰地勾勒每一个运行步骤。简单来说，就本文语境而言，非确定性指的是像 LLM 这类系统输出的可变性：即使输入完全相同，每次执行也可能产生不同输出。这种可变性源于模型内部的概率性决策过程——对于同一个提示词，可能存在多种看似合理的候选回应。
由于智能体依赖 LLM 来解读提示并生成回应，它们也继承了这些模型的非确定性特征。这意味着，即便输入相同，智能体也可能给出不同输出。正因如此，就必须具备健壮的机制，确保智能体的行动仍然可被理解。
图 5-3. 可解释且可追溯的智能体
当智能体保留其完整决策过程的信息时，就实现了可解释性。这包括：记录任务计划的创建过程、记录协作智能体或工具的选择过程、以及记录将提示词中导出的参数注入到工具或协作智能体（用于任务步骤执行）的过程。在任务规划的每一步中持续捕获数据至关重要，具体包括：
- 任务计划展示了智能体如何把一个请求分解为更小的子任务，并在后续执行这些子任务。
- 为任务计划的每一步识别智能体与工具，展示了智能体如何从一整套可用的智能体与工具“宇宙”中挑选出合适的工具或协作智能体。
- 将参数插入到每个子任务，展示了在交接与后续执行协作智能体与工具时所使用的精确参数。
我们稍作解释。
智能体运行的第一步，是基于给定请求或提示创建一份任务计划。任务计划创建完成后，智能体会识别：对于任务计划中的每一步，应当使用哪一个协作智能体或工具来完成。这意味着把任务步骤映射到相应的智能体或工具，并确保为其分配正确的参数。
从初始提示中导出的参数，会用于将每个任务步骤“定制”到当前上下文中。这些参数影响智能体及其协作者如何执行动作，以确保输出与最初意图对齐。记录参数替换（parameter substitution）对于理解任何偏差或非预期结果都是必不可少的。
因此，当以上所有信息——任务计划、工具选择、参数整合——都可供审阅时，我们就认为该智能体是可解释的。这种透明性对于验证智能体行为是否符合其设计目标至关重要，同时也使任何异常都能被细致调查。
可追溯性是与之互补的属性：即使一次任务跨越多个协作智能体与工具，我们仍能把智能体的任务计划与其实际执行过程对应起来。系统会为“源头任务”创建一个唯一标识符——也就是接收首次请求的智能体所创建的第一份任务计划对应的任务——并将该标识符附加到每一个步骤与子步骤上，把智能体发生的每个动作、决策与交互连接起来。这个标识符使任何受众——开发者、审计人员或运营人员——都能重建完整的决策过程，从而定位任何错误来源或偏离预期行为的环节。
可追溯性还延伸到多智能体协作同一任务时的智能体间通信。通过为每次智能体交互维持唯一标识符与详细日志，组织就能创建一张端到端的任务执行地图。这种全链路映射对于有效治理至关重要。
可解释性与可追溯性的组合，不仅有助于内部流程优化，也支持对外部监管要求的合规。利益相关方可以通过审阅详细日志与记录，评估智能体是否在既定伦理与运营框架内运行。这些记录——它们记录了智能体行动的方方面面——构成治理框架的基础。在金融、医疗等受监管行业中，这种细节粒度对于确保自主系统既安全又可问责是必不可少的。
这些可解释性信息同样有助于诊断智能体行为中的问题或不一致。当出现非预期结果时，详细日志能让开发者或运营人员更容易隔离并理解导致问题的一连串事件，从而进行有针对性的干预。除了问题诊断之外，这些记录信息对持续改进也极其宝贵。通过分析智能体历史行动数据，开发者可以识别模式、优化决策过程，并进一步降低非确定性对整体性能的影响。
有趣的是，可解释性与可追溯性还是任何自主智能体认证框架中的关键组成部分。正如产品认证通过严苛测试与文档证明产品安全一样，面向智能体的类似认证流程也会使用每一步运行细节记录。这样的方法能确保智能体不仅满足性能标准，也必须对其决策承担责任。
可协作且智能（Collaborative and Intelligent）
当今的 AI 工作流往往依赖单个 LLM 来管理从输入到输出的整条处理链。然而，随着请求复杂度和规模的提升，这种方式可能带来显著错误。由于 LLM 具有内在的非确定性——同一输入可能产生不同输出——当任务需要更精细或更长时间的处理时，结果质量恶化的风险会不断上升。
智能体采取了不同的方法：它们会创建一份逐步的任务计划，把大型任务或请求分解成更小的子任务。智能体不会把整个流程的所有方面都揽在自己身上，而是评估任务的哪些部分需要专门能力，并选择合适的协作者来辅助完成。这种分布式方法利用了多个智能体的优势，提高了完成复杂任务时的准确性与效率。
智能体会从一个注册表（registry） 中选择协作者（此处只需知道：注册表是一个元数据仓库；其细节会在后续章节解释），而注册表是智能体生态的一部分。该注册表列出了所有可用智能体与工具及其能力，确保每个子任务都被分配给最合格的实体。当智能体能够在任务计划的治理或映射之下，自主与其他智能体交互并进行协同，就实现了协作。正是这种协作机制减轻了任何单个智能体的负担，并通过借助集体专长提升系统韧性。
但在智能体生态中，协作远不止于此。协作过程首先从某个智能体接收请求并创建一份完整任务计划开始。随后，该智能体把部分工作交接给协作智能体。协作智能体在收到子任务请求后，会通过创建自身的详细计划来进一步细化任务。这种递归式委派，使系统能够把最复杂的请求拆解为更容易管理与执行的“简单任务层级结构”。
当每个协作智能体收到分配给它的子任务时，它也可能进一步识别额外的专门智能体或工具，来处理请求中的某些特定方面。这种级联式的任务规划方式，确保大型复杂任务的每个要素都能由最适合的智能体或工具来处理。
但为什么要费劲把请求拆成更小部分？为什么不干脆让一个 LLM 承担越来越多的功能？简而言之，可分解性（decomposability） 是软件工程的基石，它使开发者能够把复杂系统拆解成可管理、彼此独立的组件。在传统软件设计中，这一原则体现为模块化编程：系统由离散、可复用的模块集合构建而成。模块通常对应函数调用，封装特定逻辑或行为。通过把大问题拆解为更小、更明确的单元，开发者可以隔离错误、便于维护，并促进可扩展性。
在分布式软件架构中，可分解性的单元常常扩展为 API 调用，它们作为独立服务之间的通信通道。一次 API 调用充当系统不同部分之间的契约，确保每个模块通过清晰定义的接口进行交互。这种做法提升了系统可靠性与灵活性，因为每个服务都可以独立开发、测试与部署。
对于智能体而言，可分解性原则被应用到更高的抽象层次：基本单元变成了智能体或工具。正如函数调用在传统编程中抽象了一个离散操作，智能体在更大的智能体生态中封装了一组特定职责。协作智能体通过委派子任务并协调努力来共同工作，这与软件工程中的模块化设计原则相呼应。这种协作模型不仅简化了复杂任务的管理，也增强了系统韧性与适应性，从而再次证明了可分解性在传统与现代分布式系统中的恒久价值。
可分解性的另一个额外收益，是它促进智能体的专业化。由于可分解性允许更小、更细粒度的智能体（和工具），我们就能设计出面向非常具体能力的定制组件。我们不必只依赖“通用智能体”，而可以得到高度专门化的智能体。这种专业化可以通过多种方式实现：智能体可以与在特定领域训练过的微调 LLM 配对；或者智能体及其 LLM 可以通过（例如检索增强生成 RAG）访问专门文档或数据——比如公司政策或公司数据——使智能体与 LLM 具备特定领域知识的“感知能力”。
智能体组件（Agent Components）
第 4 章介绍了智能体，并指出它们具有若干关键属性——为方便起见，我们在图 5-4 中再次展示这张图。
图 5-4. 简化的智能体架构（Simple agent architecture）
我们先简要回顾一下智能体的本质与行为。智能体能够规划并执行任务。它们还拥有由 LLM 驱动的智能，使智能体可以以更复杂、更成熟的方式进行交互与推理。LLM 赋予智能体若干“超能力”：
- 问题求解（Problem-solving）
智能体可以用自然语言与人交互，能够理解复杂甚至含糊的请求，并能给出回答问题与满足请求的路径。 - 工具（Tools）
智能体可以与其环境交互，以访问互联网或企业数据，或与产品进行交互。 - 记忆（Memory）
智能体可以追踪交互历史（近端记忆），为交互提供更丰富的上下文，从而更有效地满足请求。智能体也可以通过访问持久化数据来获取企业或互联网“记忆”（长时记忆），以辅助完成请求。 - 学习/适应（Learning/adapting）
利用智能体的交互历史以及用户（或其他智能体）的反馈反应，智能体可以从过去的交互中学习。
在本节中，我们将展开说明这些“超能力”，但这一次会加入更进一步的细节，用以解释智能体架构的组件以及它们如何工作。
智能体“大脑”（Agent “Brain”）
LLM 使智能体能够使用自然语言与人以及其他智能体交互。LLM 的设计目标，是解释并将人类输入转换为可用于规划与执行复杂操作的数据。通过把人类输入的文字或语音翻译成可用信息，LLM 让智能体具备与人交互、进行推理、并规划与执行各种任务的能力。
不过，现代 LLM 远不只是“翻译器”。LLM 会分析模式，并利用这些模式对世界进行推理。正因如此，当面对其训练数据中涵盖的主题时，智能体会显得格外聪明、反应迅速。
LLM 的一个关键特性——也是我们提到过的挑战——是它们可能具有非确定性（nondeterministic） 。同一个问题或指令，有时会产生不同答案，这取决于随机性、提示词措辞方式、或提示词所附带的具体上下文等因素。尽管非确定性会让智能体看起来更具创造力——能够生成新颖、令人意外的想法——但它也会带来一定程度的不可预测性。
许多现代 LLM 是多模态（multimodal） 的。这意味着它们不仅能处理文本（如文档与代码），还能够处理视频、音频与图像。多模态为智能体打开了无数可能性：它们可以看图片来识别物体，读取代码来调试问题，甚至将多种信息整合成一次回应。
LLM 通常默认是无状态（stateless） 的，这意味着它们不会自动记住对话或上下文，除非这些信息被明确存储在其他地方。某种意义上，与 LLM 对话就像在和一个知识渊博但“每说完一句就会忘掉上一句”的人交谈，除非你把内容写下来。然而，为了进行长对话，智能体需要追踪先前交互发生了什么。它们需要保存对话历史，并在需要时把这些历史再喂回给 LLM。
LLM 的训练输入来源极其广泛（文本、图像、音频与视频），因此它们可以讨论历史事件、解决数学问题、并总结科学论文。然而，它们也存在局限：LLM 只能在其训练时可获得的数据上进行训练，因此对更近的数据并没有足够信息来回应。确实，LLM 可能通过推理在某些情况下给出正确回答，但在另一些情况下，它们的回应会是编造的或干脆错误的，这被称为幻觉（hallucination） 。LLM 通常在公开数据上训练，可能无法访问企业数据或防火墙/付费墙之后的信息，这意味着它们未必像我们期望的那样“足够专门”，更像是聪明的通才——样样通、样样松（jacks-of-all-trades, masters of none）。对于需要深度专业知识的任务，智能体可能需要使用外部数据与各种工具来增强其记忆。
上下文敏感性（context sensitivity） 也是另一个重要方面。你提问的措辞方式——以及你提供的细节——会对 LLM 如何回应产生很大影响。提示越清晰，你越可能得到清晰答案；若你表达含糊，模型可能会自行补齐空白，而结果也会随之波动。同样地，智能体会非常谨慎地管理任务，以可靠、可复现、可解释的方式运行。
智能体记忆（Agent Memory）
智能体的记忆来自多个来源：编码在其 LLM 权重中的原生知识、其即时上下文中提供的短暂信息，以及通过检索技术（例如检索增强生成，retrieval-augmented generation，RAG）访问的外部存储库。它们共同构成了一种动态的层级结构，涵盖回忆、推理与适应，并定义了智能体如何感知、解读并在世界中采取行动。
在最底层的是原生记忆（native memory） ——训练过程中隐式捕获的知识。这是智能体对语言、事实与世界规律的基础理解。然而，这种记忆是静态的：它反映了训练时可获得的数据与当时的“世界观”。为了保持最新或具备领域特化能力，智能体必须用上下文与外部输入来增强它。
第二层是短期或情境记忆（short-term or contextual memory） ，它包括活动提示词以及任务执行期间可用的周边上下文。它的作用类似工作记忆（working memory）——易失、容量有限，却对即时推理至关重要。一旦任务结束，这层记忆会消散，除非被明确总结或存储到其他地方。
再往上是长期或外部记忆（long-term or external memory） ，通常由 RAG 或类似方法驱动。通过 RAG，智能体会查询结构化存储——向量数据库、文档仓库或 API——按需检索相关信息。简单的 RAG 实现会对 embedding 做最近邻搜索；而更复杂的版本会结合排序、过滤与反馈回路，以确保精确性与相关性。这使得智能体无需重新训练模型，就能访问最新的企业知识或网络知识。
但智能体还能进一步受益：在长期记忆中区分出多种不同类型的记忆。
- 情景记忆（episodic memory） 让智能体回忆特定交互或经历，为跨会话的连续性提供支撑。
- 程序记忆（procedural memory） 编码技能与可重复行为——如何完成某些工作流或执行政策。
- **语义或概念记忆（semantic or conceptual memory）**捕 获思想与实体之间的抽象关系，形成领域的“认知地图”。
- 事实记忆（factual memory） 保留离散的真值——数值、规则与已验证的数据。
这些记忆类型协同工作，使智能体能够同时基于上下文与历史进行推理。
记忆的结构与其内容同等重要。简单的向量检索可能会在上下文碎片化或查询含糊时表现不佳。为了解决这一点，更先进的架构会依赖本体（ontologies）与分类体系（taxonomies） ——对实体、其类别与其关系进行形式化定义。它们为语义检索提供支架，确保“员工”“经理”“合同工”不只是词语，而是带有定义属性的关联概念。知识图谱（knowledge graphs） 在此基础上更进一步：用节点与边编码实体与关系，从而支持推理与推断。当与 LLM 驱动的检索结合时，图谱既充当事实骨架，也充当语义罗盘，使智能体能够推理因果、依赖与层级。
在实践中，这种结构化记忆架构会提升检索准确性、上下文对齐与可解释性。智能体不再只是拉取“看起来相关”的文档，而是能够回忆与查询最贴近问题的概念、流程或过往经验。基于图谱的推理还能帮助智能体弥合缺口——把事实与赋予事实意义的概念或事件连接起来。它也带来透明性：智能体不仅能解释检索到了什么，还能解释为什么选择这些信息。
智能体记忆也必须随时间进行管理。记忆会根据重要性与使用频率被提升、被总结或被遗忘。情景痕迹可以被提炼为简洁叙事；事实数据可以被验证与刷新；过时信息可以被修剪，以避免漂移或膨胀。这一记忆生命周期确保智能体的回忆既高效又相关——一种动态的“保留与更新”平衡，比静态知识库更贴近人类认知。
智能体上下文工程（Agent Context Engineering）
上下文工程（context engineering）是一种实践：在恰当的时间，把恰当的信息选择出来、组织成结构化形式，并交付给智能体的 LLM。由于 LLM 除了你提供的文本以及它能访问到的 token 之外，并“不知道”你当前的处境，性能在很大程度上取决于你把哪些上下文放进提示词里：指令、约束、事实、先前步骤与目标。良好的上下文工程通过塑造模型“看到什么”以及“应该如何推理”，把一个通用模型变成具备任务胜任力的助手。
它之所以重要，是因为 LLM 运行在严格的上下文窗口与注意力预算之内。即便窗口在增长，注意力计算的成本通常也会随着输入长度增加而上升，而无关文本会稀释或带偏推理。在多智能体系统中，这个问题会叠加放大：许多智能体会产出消息，工具会生成输出，而下一次决策真正有用的只是其中一部分。如果没有严格的上下文选择纪律，智能体会重复劳动、忽略约束，或在步骤之间表现不一致。
从高层看，上下文工程回答三个问题：要包含什么、要如何格式化、以及何时刷新或遗忘。其中，“包含什么”混合了新近性（recency，最新状态） 、相关性（relevance，与当前查询最接近） 、可靠性（reliability，可信来源）与角色（role，谁产出的） ；“如何”覆盖指令脚手架（instruction scaffolding）——系统消息、角色提示、few-shot 示例、schema、以及函数或工具定义；“何时”管理生命周期：任务的初始播种（initial seeding）、每一步之后的增量更新（incremental updates）、以及为了保持工作集小而有用的收敛（consolidation，如摘要与检查点）。
实践技术可分为若干层次。RAG 技术可以用来自向量库或数据库的外部事实填充上下文；重排（reranking）把最相关的少量段落提升上来；压缩（compression）把长历史提炼成结构化摘要；插槽化（slotting）为“必须包含”的项目（如安全规则、API、或约束）在提示词中预留固定区块。对于智能体而言，规划器（planners）会附带目标与子目标，工具代理（tool brokers）会包含函数签名（function signatures），状态管理器（state managers）会注入最新的环境变量或工作流元数据。最好的系统会把这些组合起来，让模型始终看到一个紧凑、经过策展的世界视图。
正如我们之前所说，智能体的记忆通常按层级（tiers）组织，每一层服务于不同目的。最快的一层是提示词本身——模型直接可见，构成其短期工作记忆。中间层保存滚动摘要、近期决策与未完成任务；这些信息紧凑、易更新，也能在需要时快速回填到提示词中。长期层持久化完整工件——文档、日志、先前对话——并通过检索机制进行选择性访问，只把与当前查询相关的内容提取出来。合在一起，这些层级映射了人类与计算机管理有限活跃记忆的方式：上层快但小，下层慢但大。提升与淘汰策略（promotion and eviction policies）决定信息在层级间如何移动，由相关性、新近性与重要性驱动。
这种分层记忆自然引出缓存（caching）——一种把恰当数据放在下次使用位置附近的运行技术。在 LLM 与智能体中，上下文缓存（context cache——上下文工程的核心关注点）工作在应用层。它跨步骤存储事实、摘要与检索段落，使系统无需重新抓取或重新生成即可复用既有上下文。工程师将这些缓存视为更广义记忆层级的一部分：提示词是热缓存（hot cache），摘要是温缓存（warm cache），持久化存储是冷缓存（cold cache）。键（keys）——例如 embeddings、实体 ID、或目标标识符（goal identifiers）——与 TTL（time-to-live）设置确保高频所需信息保持在手边，而陈旧或无关数据会被逐步清除。本质上，上下文缓存把“记忆分层”的思想落地为操作机制：在速度、容量与相关性之间维持一种流动的、动态的平衡，使智能体能够在规模化场景下高效思考。
在上下文工程中，上下文质量取决于其结构。无结构的倾倒式内容会浪费 token；结构化提示能把预期说清。典型脚手架包括：简短目标、约束、带签名的可用工具、当前状态，以及清晰的“下一步动作”请求。当工具可用时，函数调用（function calling）还能进一步把输出约束到 JSON schema，从而提升确定性（determinism）与下游自动化能力。护栏（guardrails）——策略检查、类型校验、来源标记（source tagging）——也会随上下文一起携带，使智能体能为其行动给出理由，并让审计链路保持完整。
一个有趣且值得借鉴的观察是：上下文工程背后的思想并不新。计算长期以来一直用层级与策略来管理稀缺的工作内存。CPU 把热数据放入小而快的缓存（L1/L2/L3），依赖局部性（locality）去预取可能的下一批字节，并在缓存未命中时回退到主存。操作系统用虚拟内存扩展这一点：进程看到的是一个大而统一的地址空间，而 OS 把页面映射到 RAM 或磁盘、用页表追踪，并用 TLB（translation lookaside buffer）加速。RAM 紧张时页面会被换出到磁盘；需要时再通过缺页（page fault）换回。
这些原则同样可以干净地映射到 LLM 与智能体。提示词类似 L1 缓存：小、快、且珍贵。滚动摘要类似 L2/L3：更大但仍易加载。外部存储——向量数据库、文档库、数据湖——相当于 RAM 与磁盘。检索是一次“换入”（page-in）操作；摘要与淘汰是“换出”（page-out）策略。检索过多会导致注意力预算“抖动”（thrash）；检索过少则会让模型缺乏信号。有效系统会围绕局部性调参：把语义上最相关、最近使用、且最可信的片段放在离模型最近的位置。
时间局部性（temporal locality）在上下文工程中扮演显而易见且关键的角色。就像处理器会缓存最近访问的数据，因为它很可能很快再次被使用，LLM 与智能体也受益于在工作上下文中优先放入最新且与时间相关的信息。近期事件、状态变化与用户指令，几乎总是对下一步具有最高的预测与推理价值。包含及时数据能保证连续性、防止过时假设，并让推理链条与系统的真实世界状态保持一致。反之，当陈旧或滞后的信息主导提示词时，模型会浪费注意力，并有在过时事实上行动的风险。因此，有效的上下文工程会镜像缓存优化：把“最热”的、最相关的信息放在推理核心附近，以在时间维度上维持连贯性与响应性。
虽然上下文工程是相对新的关注点，但它建立在反复被使用过的技术与模式之上（例如前文的计算机内存示例）。基于这些概念，我们可以假设一种很可能的未来上下文工程架构由五个主要组件组成：上下文管理器（context manager） 、检索器（retriever） 、摘要器（summarizer） 、路由器（router）与记忆存储（memory store） 。上下文管理器充当编排者（orchestrator），维护将输入到下一次模型调用的工作集信息。检索器对接持久化存储或向量数据库，用于定位相关历史数据或外部知识。摘要器把长历史或冗长工件压缩成简洁、结构化的表达，保留关键含义并尽量降低 token 成本。路由器决定每个智能体或任务需要多高的保真度——完整工件、摘要还是元数据——并把决策回传给上下文管理器。最后，记忆存储持久化所有长期数据，提供持久性与可回放能力（replay capability）。这些组件共同维持速度、成本与完整性之间持续更新的平衡。
这些组件以紧密的反馈回路交互协作。当新的事件发生——例如用户输入、一次观测（observation），或智能体的状态更新——上下文管理器接收事件并向检索器查询相关材料。摘要器对相关背景做压缩，路由器决定所需保真度，记忆存储同时记录原始事件及其加工形态。在调用模型之前，上下文管理器组装一个提示词，将即时更新（时间局部性）与检索到的背景（语义相关性）融合起来。执行之后，结果与新工件回流到记忆存储，更新索引与摘要，为下一轮迭代做准备。这个持续循环——检索、摘要、路由、提示、更新——构成了可扩展上下文工程架构的核心，确保每一次模型或智能体步骤都在恰当时间、以恰当粒度，使用恰当信息运行。
智能体工具（Agent Tools）
正如我们所见，LLM 扮演着智能体的“大脑”。而借助任务管理能力，智能体可以与协作智能体一起工作——有点像在需要专业知识时，能够分享洞见或委派任务的“同事”。
另一方面，工具（tools）则更像是智能体的“四肢”。就像人的胳膊与腿让人能够与物理世界互动，工具让智能体能够与其环境交互。工具是智能体执行那些需要外部动作的任务的手段。
工具有多种形态，广义上可分为传感器（sensors）与执行器（actuators） 。传感器从环境或用户处采集数据——为智能体提供可用于决策的信息。执行器则执行动作：根据智能体的指令去做事，无论是发送消息、调整设置，还是触发某个流程。
不过，需要知道的是：尽管智能体与工具有时看起来能做同样的事，但它们仍有些不同。智能体以异步（asynchronous） 方式运行：它们接收请求，在较长时间跨度内处理，最终返回结果。这种异步模型支持长时任务——可能需要多轮迭代或多方协作——而要处理这些任务，往往需要在更长交互期间进行状态管理。相较之下，工具通常以**同步（synchronous）**方式运行：被调用后执行一次性、即时动作。
还需要补充一点：这并不意味着工具内部的步骤一定同步执行——它们内部也可以是异步的（例如以发布-订阅方式调用企业 API），但从调用工具的智能体视角来看，它们表现得像一个内联函数：被调用、等待完成、拿到结果，然后继续向前。
这些概念在现代框架中已有体现，例如 Anthropic 的 Model Context Protocol（MCP） 与 LangChain，它们为工具定义了标准化的调用模式。这种标准化简化了多样化工具的集成，确保无论工具作为传感器还是执行器使用，都能无缝并入智能体的工作流。
智能体任务管理（Agent Task Management）
任务分解、规划与执行是一项复杂的工作。想象一下，在请求（提示词）可以呈现为各种形式、可能含糊不清、并且还能通过不同媒介（文本、音频、视频等）表达时，要如何去理解一个任务。再想想，为了完成一个请求，任务可能需要深入的领域知识。然后，当一个逐步的任务计划被创建出来后，还要考虑智能体如何判断该用哪些工具，或该与哪些其他智能体协作。最后，在这一切都完成之后，还要考虑一个任务可能会持续运行数分钟、数小时，甚至数天；并且当任务中断、或需要并获得额外的人类输入时，它必须能够被重启。
那这一切究竟如何运作？首先，创建任务计划；其次，识别协作者与工具，并把它们接入任务计划；第三，基于给定输入（提示词），把参数填入每个协作者/工具对应的每一步。图 5-5 展示了本节将展开说明的方法。
图 5-5. 智能体任务管理
创建任务计划（Creating the Task Plan）
一旦给定一个请求（提示词），智能体必须创建一个任务计划，如图 5-6 所示，用以完成该请求。
图 5-6. 创建智能体任务计划
任务计划由两个主要部分构成：
- UUID
在智能体生态系统内标识该任务的唯一 ID - 步骤（Steps）
用于完成任务的一系列步骤；更简单的任务可能只有顺序步骤，而更复杂的任务则可能把步骤组织为有向无环图（DAG）
每个步骤又由若干子组件构成，这些子组件会在后续阶段被填充：
- 步骤 ID（Step ID）
在该任务内唯一标识该步骤的标识符 - 协作者/工具（Collaborator/tool）
完成该特定步骤的协作智能体或工具的完全限定名（fully qualified name） - 参数（Parameters）
协作者或工具为完成该步骤所需的一组参数 - 状态（Status）
该步骤的状态；初始为默认值（例如 READY），用于反映该步骤的执行状态 - 结果/细节（Results/details）
该步骤完成后的结果
创建任务计划有若干种技术。如果智能体的 LLM 在与该请求相关的领域受过训练，那么它可能立刻具备创建一个扎实任务计划所需的知识。另一方面，如果智能体的 LLM 训练并没有让它成为任务规划方面的专家，那么我们就需要提供显式的指导——一种策略——来告诉智能体的 LLM 如何创建任务计划。
一个典型策略可以用多种方式表述，但既然我们是在要求 LLM 来生成任务计划，那么大概有几件事值得考虑使用：
- 自然语言（Natural language）
该策略应使用自然语言来定义。 - JSON Schema
应给 LLM 提供指导，使其生成符合特定结构的任务计划。假设任务计划被组织为一个 JSON 对象，那么我们可以提供一个 JSON Schema，以非常明确的细节定义任务计划中每个字段。 - JSON 示例（JSON samples）
应给 LLM 提供若干个优秀任务计划的示例（通常每个示例都应符合所提供的 JSON Schema）。
识别协作者与工具（Identifying Collaborators and Tools）
一旦任务计划创建完成，下一步就是把任务计划中的每一步，连接到将执行该步骤的协作者与工具（图 5-7）。但它们如何被识别？从哪里来？又如何被接入任务计划？
图 5-7. 识别智能体的协作者与工具
智能体会在可用的协作智能体与工具清单中进行搜索，然后把协作者/工具名称填入任务计划（例如，第 1 步由 Agent 1 完成，第 2 步由 Tool 2 完成）。这份清单由一个注册表（registry）维护，第 8 章会更详细解释；但此处你可以先把它理解为：一个存放智能体生态系统中所有智能体与工具信息的仓库。
参数替换（Parameters Substitution）
最后，用户提供的提示词包含了完成请求所需的具体信息。智能体会使用其 LLM，如图 5-8 所示，从提示词中识别这些信息，并将其映射到每个智能体或工具所需的参数上。
图 5-8. 参数替换
执行任务计划（Executing the Task Plan）
到这一步，我们已经有了一个可落地的任务计划：包含多个清晰铺排的步骤；每个步骤都已确定对应的工具或协作者；并且所需参数也已填入。但它如何被执行？图 5-9 展示了其运作方式。不过，对此存在两种思路：要么利用 LLM 的能力去调用任务计划中的步骤，要么使用一种程序化的方法来执行任务计划。两者都可行，但各自有利有弊。
图 5-9. 任务执行
LLM 执行任务的主要缺点在于：LLM 是非确定性的（nondeterministic），也就是说，执行步骤由概率驱动，可能会随时间变化（或导致错误或幻觉）。对于较小的请求，出错概率可能很低，因此这可能是可接受的。但对于更大或更复杂的请求，错误可能会增多到超过请求方阈值或容忍度的程度。而当错误阈值被突破时，LLM 的黑盒特性会让 LLM 更难调试、理解或解释。这种做法常见于 AI workflow：由 LLM 来掌控任务执行的各个方面。
而智能体则有第二种选择：将任务规划与执行解耦，使用替代性的、也许更确定性的执行引擎，从而获得更可复现、可解释、也更可靠的执行方式。
智能体交互与对话（Agent Interactions and Conversations）
智能体通过协作来完成任务。这些协作被归类为交互（interactions） ——既包括智能体之间简单的请求/响应，也包括由许多交互构成、可长时间运行的对话（conversations） ；对话允许采用一种或多种智能体消息模型。
智能体消息模型（Agent Messaging Model）
在大规模系统中，通信策略远远超出为低延迟与即时回复而设计的传统请求-响应式 API 交互，涵盖了支持更复杂、持续更久对话的一系列消息模型。如图 5-10 所示，这些模型包括：
- 消息队列（Message queues） ：通过解耦发送方与接收方来管理异步交互
- 事件驱动或流式消息（Event-driven or streaming messaging） ：智能体订阅持续的事件流，使其能对动态数据进行实时响应
- 基于 Actor 的架构（Actor-based architectures） ：独立智能体处理消息并维护自身状态，从而增强模块化与韧性
- 共享工作空间（Shared workspaces） ：创建协作环境，使智能体能够汇聚数据与洞见，共同朝着目标推进
图 5-10. 智能体消息模型
先给出几个定义（Let’s start with a few definitions）
请求-响应（Request-response）
这是一种同步消息模式：一个系统通过发送请求来发起调用，然后等待回复，从而实现即时反馈与错误处理。比如，当用户登录在线银行应用时，应用会向服务器发送登录请求，服务器验证凭据后返回响应，确认访问或说明错误。同样在 Web API 场景中，客户端可能通过调用某个 RESTful 端点请求产品详情，而服务器会实时返回对应的产品信息。
消息传递（Messaging）
该模型通过多种异步模式促进分布式系统中的数据交换，解耦发送者与接收者以提升可扩展性与韧性。例如，在基于队列的异步消息系统中（如 RabbitMQ 或 IBM MQ），生产者把消息写入队列，消息会一直保留到消费者取出并处理，即使负载波动也能保证可靠性。另一种模式是发布-订阅（pub/sub）：发布者把消息发送到某个主题，多个订阅者可以各自独立地接收并处理这些消息；Apache Kafka 与 Google Pub/Sub 是这种方式的典型代表。这些模型满足企业的多样需求——从电商系统中的订单处理与库存更新，到在微服务架构中分发实时通知。
事件驱动模型（Event-driven models）
该模型（有时也被视为一种架构模式）允许系统组件通过发出并响应事件——某件事发生了的离散信号——来通信，从而实现解耦、响应式与可扩展的流程。例如，在电商系统里，购买完成可能触发一个“订单已下达（order placed）”事件，库存管理、支付处理与物流配送等多个服务会订阅该事件，并在事件发生时各自独立行动。类似地，在物联网（IoT）场景中，传感器检测到阈值被突破时可以发布事件，触发即时告警、数据记录或自动化安全响应。
这些模型都可以用于智能体。但每一种都有利有弊，最终有些模型可能比另一些更适合智能体通信。首先，智能体通信与传统的请求-响应交互（API 常用方式）存在显著分歧。API 采用为即时、低延迟交互而设计的请求-响应模型；而智能体则以**基于对话（conversation-based）**的方式运行，对话可能跨越更长时间并涉及更复杂的交互。这种区别是根本性的，因为它会塑造底层通信协议与系统整体架构。
传统 API 依赖如 REST/HTTP 或 gRPC 这类标准请求-响应模型。这些协议针对速度与效率做了优化，在请求发出后几乎立即返回响应。这种设计适合简单任务——一次同步的信息交换即可完成。相反，智能体被构建来处理更复杂的对话：它可能需要更多上下文、多个回合的交互，有时甚至还需要与其他智能体协作。
由于智能体交互可能跨越更长的持续时间，它们需要不同的通信模型。智能体往往不是“一次请求+立即回复”，而是进入延展的对话。这种对话模型必须容纳延迟、间歇式处理、以及潜在的异步响应——而这些通常不属于传统 API 那种严格、低延迟环境的特征。
一种支持此类异步交互的常见方法是消息队列模型。在这种方式下，一个智能体（发送方）把消息放入队列，另一个智能体（接收方）再处理请求。这种设置解耦了发送与接收，使发送方在消息被处理期间不会被阻塞，可以继续运行。消息队列确保每条消息最终都会被处理，即使存在延迟也如此，因此非常适合管理延展对话与复杂工作流。
另一种方法是事件驱动或流式消息。在该模型中，智能体订阅事件流，并在新数据到达时作出反应。持续的信息流让智能体能够边到边处理更新，并与环境保持“持续对话”。当对话涉及动态、快速变化的信息，并且需要作为对话流程的一部分被即时处理时，事件驱动方式尤其有用。
第三种用于智能体通信的模型是 Actor 模型。这里，每个智能体被视为一个独立的 actor：它可以处理消息、改变自身状态，并与其他 actor 通信。每个 actor 处理自己的任务与交互，使系统更模块化、更具韧性——某个 actor 的失败不一定会影响整个系统。
最后，共享工作空间为多个智能体提供了更宽泛的协作环境。在这些工作空间里，智能体把内容写入一个可被许多智能体访问的区域（例如：内存、数据库），因此它们不只是进行一对一对话，而是处于一个更大的生态中，便于汇聚资源、数据与洞见。
共享工作空间在仿真场景或多个智能体朝同一目标协作时尤为有用。在这种情况下，工作空间就像一个数字化实验室或控制室：智能体可以在其中尝试不同方法、检验假设，并实时迭代解决方案。这种面向目标的协作有助于梳理那些对单个智能体或简单对话交换来说过于笨重的复杂流程。
这些多样化模型——消息队列、事件驱动/流式消息、以及基于 Actor 的架构——为应对智能体对话的延展性与异步性提供了必要基础设施，确保即使交互跨越更长时间、并涉及多个步骤或多个智能体，系统依然保持鲁棒。
智能体对话管理（Agent Conversation Management）
虽然智能体可以使用多种消息模型进行通信，但它们的交互会组织成我们称之为 “对话（conversations）” 的结构，其原型显然来自人类对话。和现实世界的对应物一样，对话由多个交互组成，每一次交互都会为对话的信息流与历史增添内容。并且同样像现实对话那样，如图 5-11 所示，对话可能跨越毫秒、分钟、天，甚至更久的时间尺度。
图 5-11. 智能体对话管理
理解对话的一种方式，是把它们与编程联系起来。智能体对话的结构很像编程中的函数调用树（function call tree） 。在智能体对话中，一个智能体可能发起与第二个智能体的对话，而第二个智能体又与第三个通信，如此类推。这可以是串行的——每个响应依赖前一个响应；也可以是并行的——多个智能体同时在对话的不同分支上工作。这样的结构允许复杂问题求解：每个智能体贡献整体任务中的一个特定部分。关键在于：一次对话会跨越多个智能体、由多次交互构成。实际上，正是对话把端到端的智能体交互绑定在一起。
在这些对话中，不同类型的交互提供不同能力。例如，问候与讨论类交互旨在为对话定框，而不是直接请求具体动作。这些起始交换设定语气、建立上下文，并让智能体把握对话的整体意图与环境——就像人类在进入实质讨论前先寒暄一样。
信息类交互为任务提供关键上下文。这类交换不是下达命令，而是共享相关数据、澄清细节，并确保所有参与智能体对任务有共同理解。通过建立坚实的信息基础，智能体可以更有效地协作，降低对话推进过程中误解或错误的风险。
任务请求类交互是智能体对话中最核心的功能性交换。在这里，一个智能体传达具体请求或指令（并伴随必要的信息流），由此触发一连串响应来完成该请求。
任务状态类交互用于在对话中更新某个请求的进展。这些消息让所有参与者了解当前执行情况、遇到的问题，以及相对原计划可能出现的偏离。
智能体状态管理（Agent State Management）
在计算机科学中，状态管理指的是跟踪与控制系统或应用状态的实践。状态表示某一时刻程序正在处理的相关数据与变量的当前条件或快照。这包括从用户输入与会话细节，到程序执行的各种操作结果在内的一切。
更直观地说，状态管理就像是在应用内部记录“正在发生什么”。正如一个人会记住对话细节，一个程序也必须记住某些信息，才能在多次交互或多次会话中保持连续性与一致性。没有适当的状态管理，应用可能会丢失这些细节，导致错误或不可预期的行为。
状态管理的一个重要考量，是区分有状态（stateful） 与无状态（stateless） 设计。在有状态系统中，应用会保留过去交互的信息，这对用户认证、购物车维护等任务至关重要。相对地，无状态系统把每个请求都当作彼此独立、无需保留上下文的事件来处理，这能简化设计，但并不适用于所有应用类型。
例如在 Web 开发中，状态管理对构建响应式、交互式应用至关重要。Cookie、Session 与本地存储等技术让 Web 应用能够随时间记住用户动作与偏好。在更长期的层面上，数据库可用于存储更持久、可长期保存的状态。这确保即使用户在页面间导航或重载浏览器，其体验仍然连贯、顺滑且个性化。
但有状态处理确实会引入复杂性。比如并发会给状态管理带来额外挑战，尤其在多个进程或线程试图同时访问或修改同一状态的环境中。锁（locking）、事务内存（transactional memory）或不可变数据结构（immutable data structures）等技术被用来防止冲突并确保数据完整性。
为什么要解释无状态与有状态的考量？主要是因为智能体——就其本质而言——是有状态的：它们必须管理长时对话，并维护持久状态，以支持重启恢复（restart-recovery）或对话中途来自人类（或其他智能体）的反馈。
那么，为了管理智能体的状态，必须维护什么？至少需要维护以下关于智能体状态的信息：
- 运行时状态（Runtime state）
用于判断智能体是否忙碌、是否在等待输入、或是否处于错误状态 - 对话历史（Conversation history）
用于提供上下文或短期记忆，使智能体能将其提供给 LLM 来响应任务请求 - 任务状态（Task status）
用于判断智能体任务是进行中、等待反馈，还是处于错误状态 - 任务状态数据（Task state）
维护任务的所有相关信息（是否在运行、历史是什么），以支持重启恢复与问题诊断
这些状态信息可以通过多种技术来维护。最简单、也最“琐碎”的方案——可能只适用于演示——是在智能体自身内存中维护状态。显然，这种方案只能在短暂的意义上工作，无法支持任何长期的智能体状态。更常见的做法，是把智能体状态维护在数据库中，并依赖现代数据库成熟可靠的数据管理能力来进行长期状态管理。尤其是数据库非常适合智能体状态管理：设计良好的分布式能力可以轻松支持规模化的智能体（成千上万，甚至可能是数百万个）。当需要更复杂的分布式状态管理时（也许只在最苛刻的高可用数据需求下才需要），诸如分布式缓存或 Paxos、Raft 这类一致性算法，可以帮助确保系统各部分对状态具有一致、连贯的视图。
智能体工作空间（Agent Workspaces）
智能体可以使用前面提到的消息模型来协作，但它们的协作也可以遵循若干已被充分验证的模式——基于共享内存（shared-memory）的协作。我们把这种模式称为智能体工作空间（agent workspaces） ，如图 5-12 所示。
图 5-12. 智能体工作空间
在任务导向（task-oriented） 的协作中——与使用智能体工作空间的协作相对——智能体几乎不共享信息，主要依赖交换具体的请求。每个智能体专注于其被指定的功能，通过传递清晰指令来完成交接，而不会深入暴露其内部状态的细节。这种精简方式保证效率并维持清晰边界，很像公司中不同部门通过交接定义明确的任务来协同，而不是陷入宽泛、开放式的讨论。
然而，仿真（simulation） 或目标导向（goal-oriented） 的协作则需要更强的信息共享。在这种情况下，智能体共同工作以实现复杂结果，实时汇聚它们的数据、洞见与进度更新。这种协作方式类似于跨学科团队为解决复杂问题而进行头脑风暴：每个成员的输入对制定通向共同目标的成功路线都至关重要。
为了让智能体有效共享信息，需要一个共同工作空间——一个集中式的数字环境，在其中数据、上下文与通信可以被汇聚，并可被所有协作智能体访问。这个工作空间充当共享画布：智能体不仅能在其上交换信息，也能对齐行动并协调策略。它提供了一个框架，使各个智能体贡献的细微差异都可见，从而支持一种一致且集成的问题求解方式。
但为智能体协作建立工作空间也会带来一系列挑战，尤其是在安全与访问权限方面（工作空间安全将在后文完整讨论）。就像安全的实体会议室会限制只有授权人员才能进入一样，数字化工作空间也必须执行严格控制，确保只有通过验证的智能体才能访问。这需要实现强健的认证机制，并定义细粒度的访问权限，以在保护敏感数据的同时仍能支持有效协作。
智能体身份与角色（Agent Identities and Roles）
在多智能体生态中，协作需要智能体的身份与角色作为支撑。这一基础结构支撑智能体的顺畅运行与安全交互，正如任何组织中个体身份的重要性一样。身份体系的核心是完全限定名（fully qualified name, FQN） 这一概念。FQN 充当区分不同智能体的唯一标识。它由两部分组成：命名空间（namespace）与本地名（local name） ，两者之间用分隔符（例如冒号）连接。比如，一个智能体可能具有如下 FQN：
brodagroupsoftware:bank-agent
在这个例子中，brodagroupsoftware 表示命名空间，而 bank-agent 是本地名。这种命名约定能立刻指示智能体的功能，以及它隶属的组织或群体。
命名空间在整个智能体生态中是唯一的。命名空间可以按适合该生态的任何逻辑结构分配。例如，在公共智能体生态中，命名空间可能反映创建或拥有该智能体的组织；在组织内部，命名空间则可能反映组织中创建或拥有该智能体的某个团队或部门。
在每个命名空间内，智能体的本地名也需要保持唯一。这意味着，即便两个智能体在不同组织（也就是不同命名空间）里承担相似功能，由于命名空间前缀不同，它们的 FQN 仍然是不同的。同样，在某个特定命名空间（如某个团队）内，这也保证了某一特定目的只会指定一个智能体。
不过，由于智能体需要在大型组织中进行规模化部署（并具备容错能力），每个由 FQN 指定的智能体可能会有多个实例（instances） 。因为同一个智能体 FQN 可能以多个实例被部署，所以每个实例都会被分配一个通用唯一标识符（universally unique identifier, UUID） （通常称为 UUID，它是唯一标识某个对象的字符串——在这里就是智能体实例）。
每个智能体还会被分配一个角色（role） ，用于定义其在生态中的具体职责。这些角色会记录在 Identity Book of Record（IBOR） 中——一个集中式注册表，用于维护每个智能体的功能与权限等详细信息。每个角色会通过 RBAC（基于角色的访问控制） 方案被授予特定的访问权。通过给智能体分配明确角色，系统就能执行策略，决定哪些智能体被允许彼此通信或协作。RBAC 同样用于治理工具的访问与使用：智能体必须具备合适角色才能访问特定工具，从而确保敏感操作只会由具备相应授权级别的主体来执行。
智能体类型（Agent Types）
智能体可以根据其运行特性被划分为若干类型：
- 任务导向型智能体（Task-oriented agents）
- 目标导向型智能体（Goal-oriented agents）
- 仿真智能体（Simulation agents）
- 观察者智能体（Observer agents）
任务导向型智能体（Task-Oriented Agents）
任务导向型智能体执行具有明确目标与指令的任务，这些目标与指令由用户或其他智能体提供。如图 5-13 所示，它们的工作方式是：接收一个目标（由提示词定义，可能带有参数），制定一个结构化计划来达成目标，然后自主执行该计划。
图 5-13. 任务导向型智能体
任务导向型智能体交换的数据量很少，通常仅限于完成任务以及与其他智能体（或执行工具）协调所必需的信息。每个任务都可能包含多个离散子任务，而这些子任务的持续时间差异很大，从几秒钟到数小时（甚至更久）不等。为了管理这种差异，任务导向型智能体会在交互过程中维护状态信息，确保进度被跟踪、依赖关系被管理，并且任何中断都能在不丢失整体目标上下文的情况下被处理。
以我们的“开立银行账户”用例作为任务导向型操作的例子。当客户发起开户请求时，一个专门的“开户智能体（account open agent）”负责整体流程。该智能体接收客户请求，然后制定一个详细计划，通过将专业化子任务交接给生态中的其他智能体来完成开户过程。
在这个例子里，第一个子任务可能是身份验证。开户智能体把它委派给“身份验证智能体（identity verification agent）”，后者通过访问工具来校验客户提供的信息与文件，从而确认客户身份。身份验证完成后，开户智能体进入 KYC（know your customer，了解你的客户）流程。该任务由专门的 KYC 智能体处理，它评估客户背景与风险画像，以满足监管要求。KYC 智体完成后，开户智能体继续进行账户设置，其中包括与“首笔入金智能体（initial deposit agent）”协调，由其负责处理客户的初始资金。
最后，当所有核心任务完成后，开户智能体将最终步骤委派给“通知智能体（notification agent）”。该智能体向客户传达结果——例如账户已成功开立以及后续步骤。贯穿整个过程，任务导向型架构确保每个专业化智能体专注于其指定子任务，同时整体的开户工作流保持连贯、高效，并能适应任何意外的延迟或问题。
目标导向型智能体（Goal-Oriented Agents）
目标导向型智能体（如图 5-14 所示）被设计为以协作方式工作，通过延展、动态的对话来解决缺乏预设任务序列的复杂问题。不同于模仿请求-响应方式的任务导向型智能体，目标导向型智能体会持续评估共享目标，并实时调整策略。它们的灵活性使其在需要持续协商与调整的环境中尤其有用。
图 5-14. 目标导向型智能体
这种方法的一个重要特征是使用共享工作空间（shared workspace） ，智能体可以在其中发布、访问与更新信息。该工作空间充当一个公共草稿板（common scratchpad），让多个智能体能够看到不断演进的对话、跟踪进度，并基于最新共享数据调整各自的贡献。在共享工作空间中，智能体交换的不仅是离散数据点，还包括完整的对话线程，这些线程封装了决策背后的上下文与理由。
这种持续的数据交换使每个智能体都能对集体目标形成更深、更长期的理解，确保每个智能体的输入都基于项目的最新状态。其结果是一系列交互：工作空间中的端到端对话充当协作式问题求解过程的完整历史。
尤其值得注意的是，目标导向型智能体的动态特性使其能够持续细化计划。它们可以基于从共享工作空间中的其他智能体或外部事件收到的反馈来调整方法。这种迭代式规划与自适应过程，使智能体能够处理随时间演化的复杂问题，而不仅仅是执行预设任务。
设想一个金融服务场景：一组智能体被要求为大型机构客户优化投资组合。在这个例子中，一个智能体可能负责聚合市场数据与新闻，另一个分析风险与合规因素，而第三个则整合客户特定偏好与绩效指标。它们共同朝着共享目标工作：构建一个在最大化回报的同时最小化风险的均衡组合。
在这个金融服务示例中，每个智能体在集体目标里都有明确角色。市场数据智能体持续监测经济指标与金融新闻，将最新信息输入共享工作空间。与此同时，风险分析智能体评估各类资产的波动性与潜在下行风险，确保任何建议的调整都符合监管标准与风险承受度。最后，客户顾问智能体综合这些洞见，使投资建议贴合客户的战略目标。
在这种协作生态中，共享工作空间对于实时数据集成至关重要。智能体会借助外部来源——如实时行情与历史绩效数据——来进行决策。当这些外部数据与内部对话状态合并后，智能体就能在市场突变或新趋势出现时动态调整建议，确保组合持续与客户目标保持最优对齐。
持续反馈是目标导向型智能体模型的重要特征。随着每个智能体贡献其知识，工作空间演化为一段全面叙事，反映集体推理过程。智能体会审阅这段叙事以发现不一致或改进机会，从而进行一种持续的自我纠错，提升整体决策过程。
这种协作模型也很可能需要更高级的安全与访问控制措施。在数据敏感性至关重要的场景下，可能需要强健的认证协议与 RBAC（基于角色的访问控制）来保护共享工作空间。
仿真智能体（Simulation Agents）
仿真智能体（如图 5-15 所示）被设计用于通过创建并在虚拟模型中交互来探索复杂系统。这些智能体在较长时间跨度内协同工作，通过持续的数据交换来模拟真实世界环境的复杂性。其主要目标是观察涌现行为（emergent behavior） ——即由许多简单组件相互作用而产生的模式与现象。涌现行为能提供对系统动力学的宝贵洞见，而这些洞见往往难以通过孤立或静态分析捕获。
图 5-15. 仿真智能体
与目标导向型智能体相似，仿真智能体也利用共享工作空间——一个协作环境，多个智能体可在其中实时发布与检索数据。这个共享工作空间（对仿真智能体而言，与目标导向型智能体一样）充当所有智能体对话的历史记录，可用于理解涌现行为。通过持续更新该工作空间，智能体维护一个关于仿真环境的全面且不断演进的图景，确保每个决策都基于系统的集体状态。
来看一个例子。在保险资管的损失分析（insurance asset management loss analysis）背景下，仿真智能体可以被部署来建模保险组合在不同风险情景下的行为。例如，一组智能体可能模拟历史损失数据与资产表现，另一组则建模市场波动与灾难性事件等外部因素。通过在共享工作空间中交互，这些智能体持续交换关于理赔趋势、资产贬值与风险暴露的洞见。其结果是一种动态仿真，帮助保险机构理解潜在损失模式，并制定更具韧性的策略。
有意思的是，仿真智能体之间的长期交互能让系统检测到非线性与意外结果。随着每个智能体贡献其专门分析，共享工作空间成为不断演进洞见的存储库。这种协作式仿真能够揭示涌现现象——例如在上述保险资管示例中出现的损失聚簇，或市场变量与理赔频率之间未预见的相关性——这些现象在其他情况下可能会被隐藏。
观察者智能体（Observer Agents）
智能体可以像复杂生态中的智能传感器（smart sensors）或观察者一样工作，持续扫描环境以检测关键变化，如图 5-16 所示。例如，在金融市场中，这些智能体被编程用来监控海量数据流——从市场价格波动到突发新闻——并识别可能表明重大变化的事件。它们的运行类似于高灵敏传感器：检测异常并记录事件，以便进一步分析。
图 5-16. 观察者智能体
但观察者智能体不仅作为传感器工作，也可以作为智能执行器（smart actuators）。一旦检测到相关变化，它们会处理输入数据，将其与预定义阈值或标准进行评估，然后发出智能输出，例如触发交易信号或提醒人工操作员。
这种“感知 + 行动”的一体化功能在金融交易等快节奏环境中尤为重要。比如，设想一个部署在股市中的观察者智能体，它同时跟踪量化市场数据与定性新闻事件。当某家科技公司宣布重大产品发布时，该智能体会立刻记录这条新闻以及交易量的激增。随后，它会交叉引用历史数据并应用其决策逻辑，以判断该事件是否通常与买入信号相关。这种行为类似于人类分析师将多源输入综合为可执行的交易建议。
在许多情况下，这些智能体运行在事件驱动或阈值触发机制上。它们持续消费市场输入，一旦满足特定条件——例如股价快速下跌或交易量异常飙升——就记录该事件并提醒系统的其他部分采取行动。这种响应机制确保系统保持敏捷，几乎能瞬时应对波动的市场状况。
当部署多个观察者智能体时，它们可以通过共享草稿板（shared scratchpad）来协作——一个共同工作空间，用于记录并交换观察结果。在金融市场背景下，这种协作可能意味着共享关于新兴趋势的实时洞见，或在发出集体建议之前对信号进行相互印证。这种将传感器与执行器角色整合在一起的协作模型，显著提升决策准确性与系统响应能力——这一概念正变得越来越重要，不仅在今天的自动化交易市场中如此，在众多行业的快节奏环境中同样如此。
智能体模式（Agent Patterns）
模式（pattern，有时也称为架构模式 architecture pattern）代表一种在系统设计中经常出现的问题的可复用解决方案。它提供一个高层级的框架或模板，用来指导系统——在我们的语境中即智能体（agents）——的结构化与组织方式。与具体实现不同，模式是抽象的，因而可以根据不同需求进行裁剪与定制，从而促进更具适应性的设计方法。
当这些模式被有效应用时，会带来诸多收益。它们通过为反复出现的设计挑战提供标准化、可重复的解决方案来提升复用性。这种一致性不仅节省时间与资源，也有助于在开发者之间建立共同语言，使想法与策略更易沟通，尤其是在精确性与协作至关重要的复杂环境中。
而且，通过拥抱更高层级的抽象，模式让开发者能够把注意力集中在总体设计与架构上，而不是被繁琐的实现细节拖住。对宏观设计原则的聚焦，会推动采用经过验证的实践，而这些实践往往能带来更可扩展、互操作性更强的系统。归根结底，模式像是一张蓝图，用于构建健壮且可维护的智能体生态系统，为业务与技术领域的创新与增长提供坚实基础。
那么，我们来看看一些智能体模式。
智能体通信模式（Agent Communication Patterns）
通信模式（如图 5-17 所示）定义了智能体生态系统内部的交互与信息交换方式。与关注智能体如何完成目标的功能模式不同，通信模式强调的是智能体之间或与用户之间交换的结构。
图 5-17. 智能体通信模式
该图包含若干常见的智能体通信模式。
交互模式（Interaction pattern）
交互模式是一种直接的通信模型：发送方——无论是人还是智能体——发出请求，接收智能体立即处理该输入并给出响应。该模型是同步且一对一的，因此非常适合不需要在交互之间维护长期状态或记忆的简单交换。它常见于聊天机器人与虚拟助手中，能够满足用户对快速且可预测响应的期待。其简单性不仅能简化用户体验，也使其易于实现与扩展，并且在管理对话历史方面开销很小。
委派模式（Delegation pattern）
委派模式展示了一个智能体如何把任务交接给另一个智能体，同时转移责任与所需数据。在这种设置中，原始智能体可能会偶尔检查进度，但总体上会让接收方独立管理任务。这种“放手式”做法在任务过于复杂或需要专业化专长的场景中特别有价值。通过利用委派，系统可以更高效地分摊工作负载，并利用更广泛的技能池。这不仅简化流程，也使组织能够把精力放在战略层面的监督上，因此它对业务与技术管理者而言都是一种有效模型。
对话模式（Conversation pattern）
对话模式支持有状态、多步的通信：智能体在一系列交换中保留上下文。不同于简单的请求-响应交互，这种方式允许延展对话，持续时间从几秒到几天都可能。通过保留对话上下文，智能体可以在先前交互基础上继续推进，根据早先输入调整响应，并在整个过程中保持连贯的流动。
该模式对于长周期协作尤为有效。它让智能体能够在多轮对话中协商、细化并对齐目标，往往涉及多个智能体协同处理复杂任务、仿真或目标。共享上下文有助于确保协同一致的行动，降低误沟通或重复劳动的概率。
此外，对话模式并不限于智能体之间——它同样促进与人的沟通。当智能体需要额外信息或澄清以完成任务时，它们可以与人进行对话，并将该输入无缝融入正在进行的对话之中。这种动态交换不仅丰富了交互，也创造了更具响应性与适应性的环境。
注意力模式（Attention pattern）
注意力模式为带外（out-of-band）交互建立一个专用通道，使智能体能够在不打断常规通信流的情况下，向另一位智能体或人发出“需要介入”的信号。它被设计用来让智能体在出现异常条件或需要额外信息时，从通常的任务导向或对话式交换中“暂时让开”。
通过为紧急交互建立这条独立路径，注意力模式提供了一种可靠方法来标记异常或请求额外的人类输入。这确保关键问题能被及时处理，同时保持正常通信流的平稳运行。
广播模式（Broadcast pattern）
广播模式允许单个智能体一次性把信息发送给多个接收方（其他智能体或人）。这种单向方式意味着发送方只推送数据而不期待反馈，从而简化通信过程并减少开销。
监听者模式（Listener pattern）
监听者模式有时也被称为发布/订阅（pub/sub）模式：智能体订阅并发布通知，使其能够被其他智能体的交互“唤醒”并作出响应。这种设计将发送方与接收方解耦，使每个智能体可以保持空闲，直到相关事件发生。通过避免持续轮询，智能体能更高效地运行，只在特定通知触发其参与时才介入。这个异步通信框架非常适合需要及时响应的动态环境。
特别值得关注的是，监听者模式通过以精简方式管理零散事件来支持健壮且可扩展的交互。它提供一种机制，让智能体在不扰乱常规通信流的情况下交换信息，确保关键更新被迅速处理。对于业务与技术管理者而言，该模式为构建响应式系统提供了一种优雅方案，使系统能够在多个智能体之间高效协调复杂任务。
智能体角色模式（Agent Role Patterns）
角色模式（如图 5-18 所示）定义了智能体在智能体生态系统中承担的具体职责与行为（也就是它所扮演的角色）。
图 5-18. 智能体角色模式
规划者模式（Planner pattern）
规划者模式赋予智能体将总体目标拆解为更小、可执行步骤的能力。这类智能体通过把复杂任务分割成可管理的单元来制定策略，确保更大目标的每个组成部分都能被有条不紊地处理。通过聚焦任务分解，规划者智能体会生成一份清晰路线图，把高层目标转化为系统化的计划。
规划者智能体会利用来自环境的数据，或来自可用智能体与工具注册表的数据，不仅用于形成任务计划，也用于识别最适合处理每个子任务的候选者。它们会把原始请求中提取出的必要参数补齐，确保执行精确。一旦计划确定，规划者智能体通常会与编排者智能体协作来协调落地，从而在业务与技术导向的运作中实现更顺畅的集成式协同。
编排者模式（Orchestrator pattern）
编排者模式让智能体能够在多个智能体之间协调任务：它接收规划者智能体制定的战略计划，并以更细致的方式组织其执行。它负责分配任务、安排动作的时间与顺序，并确保每一步都分配到合适资源。尽管它本身并不执行具体任务——那是执行者智能体的职责——但它在理顺流程与维持秩序方面扮演关键角色。
除了任务协调之外，编排者智能体还会密切关注任务进展，识别任何可能阻碍成功执行的问题。这种前置、主动的监控有助于保持推进节奏，并在挑战出现时快速处理，确保复杂项目平稳推进。对业务与技术管理者而言，编排者模式为管理复杂工作流提供了可靠框架，能在协作环境中提升效率与精确性。
执行者模式（Executor pattern）
执行者模式聚焦于把规划者智能体制定、并由编排者组织的详细计划落到动作上。这类智能体专注于执行更大任务中的单个步骤，确保计划的每一部分都被高效完成。通过直接对接工具、外部系统，甚至其他智能体，执行者在战略规划与可落地结果之间架起桥梁。
本质上，当其他智能体负责设计与协调整体流程时，执行者站在一线处理任务执行的“细枝末节”。这个角色对于让计划真正兑现至关重要：它确保每一步按预期完成，从而支撑复杂项目的顺利推进与成功交付。
观察者模式（Observer pattern）
观察者模式让智能体能够监控特定系统、其他智能体或环境，而不主动介入其运行。它通过各种传感器（例如通过互联网或工厂设备）收集数据，并处理这些输入以识别趋势、模式或异常。观察者智能体会分析收集到的信息，并判断何时需要将重大变化或潜在问题通知其他智能体或人类操作员。此外，观察者智能体也可能基于分析结果作出决策，并触发告警或进一步分析。
裁判模式（Judge pattern）
裁判模式让智能体能够基于一组既定规则、标准或伦理指南作出决策。它会监听观察者智能体的通知与输入，仔细评估信息以发现问题、异常行为或潜在的政策违规。随后，该智能体会决定该情形是否需要进一步处理或介入，以确保一切都符合预先定义的判定准则。
此外，裁判角色为决策过程增加了一层可解释性与透明度。通过清晰地评估并论证其选择，它不仅有助于维持秩序与一致性，也能在利益相关方之间建立信任。在那些强调问责以及伦理标准或监管合规的环境里，这种清晰度尤为关键。
执法者模式（Enforcer pattern）
执法者模式会对其他智能体（例如裁判角色）作出的决策采取行动：当检测到规则违规或政策破坏时，它会介入。它通过执行自动化响应来纠正偏差，并在必要时联系人工操作员处理那些需要额外监督的问题，从而在整个生态系统中确保合规。该方法不仅有助于维持秩序，也通过确保既定标准被持续贯彻来建立信任。
智能体组织模式（Agent Organizational Patterns）
组织模式（如图 5-19 所示）定义了智能体在一个智能体生态系统中如何被结构化与组织起来。
图 5-19. 智能体组织模式
单例模式（Singleton pattern）
单例表示一种“人—智能体”（聊天机器人）或“智能体—智能体”的关系（这种关系，显然，体现了协作），也是最简单的协作形式。单例智能体独立行动，通常处理非常简单的请求：这类请求不涉及长期决策，也不需要与其他智能体进行内部协调。这些交互大多彼此独立，能够提供即时响应（主要通过请求—响应模型），并根据用户输入执行命令。
团队模式（Team pattern）
团队模式表示多个智能体围绕共同目标协同工作。团队既可以以层级方式运作——由“领导”智能体分配任务；也可以以去中心化方式运作——所有智能体作为平等同伴，通过自组织来实现其目标。
组织模式（Organization pattern）
组织模式定义了多个智能体团队在更大生态系统中的结构组织方式。在这种模式下，一个中心治理智能体或领导者会引导下属智能体的行为，同时确保各个具体任务与总体目标保持一致。该结构支持智能体之间的高效协调，建立起有助于精简沟通与一致性策略执行的层级体系。
这种模式通常使用策略与治理机制来规范智能体交互，从而提供更好的监督与控制，并让智能体生态系统在智能体数量增长时仍可扩展。然而，这种模式的关键挑战在于如何平衡“本地自治”与“中心治理/控制”。清晰结构能确保智能体在规则内高效工作，但在某些情况下，中心化决策未必能抵消本地自治带来的收益（例如敏捷性）。
群体模式（Swarm pattern）
在群体模式中，没有任何单一智能体充当中央权威。智能体基于局部交互进行自组织：它们自主决策，同时以集体方式朝共享目标推进。这种方式消除了层级命令结构，使每个智能体都能快速响应本地条件，并有效地为系统整体目标作出贡献。
这种去中心化结构可以增强智能体生态系统的可扩展性。该模式也可能使用分布式算法、点对点通信与共识构建技术来维持大量智能体之间的协调。然而，群体模式带来的更高速度与敏捷性，也伴随着在治理与中心控制方面的权衡：智能体获得了快速响应与灵活性，但缺乏中央权威可能会使统一策略的执行与全局战略方向的一致性更难保障。
生态系统模式（Ecosystem pattern）
生态系统模式让来自多个组织或机构的智能体协同工作，以实现更广泛的一组目标（例如在一家公司中，这些目标可能是业务流程目标），且往往不存在中心化控制。在这种模式下，来自不同组织的智能体各自保持自治：它们独立做决策，同时仍与共同的利益与目标保持对齐。
该模式强调智能体及其所属组织之间的灵活关系。通过促进跨组织边界的协作，生态系统模式使多个独立智能体能够在没有中心化控制的情况下协调活动、共享信息，并对齐行动。
法律实体模式（Legal entity pattern）
法律实体模式为一个智能体组织设立正式的法律边界，确保这些数字智能体在被认可的法律框架内运行。它提供一种结构，使智能体采取的行动具有法律约束力，从而让该组织能够作为一个独立的法律实体运作。
在这种模式下，智能体可能执行完整的组织结构——从战略决策到日常运营。采用法律实体模式的组织中，人类参与可能非常少，并被限制在监督或伦理监管角色。该模式的设计目标是：数字智能体自主完成常规管理与运营任务，而人类操作员只在必要时提供指导与介入。这种角色分离可能提升效率与速度，同时确保组织遵循法律要求。
联邦模式（Federation pattern）
联邦模式描述一种协作框架：来自独立组织的智能体在保留适当个体自治的同时一起工作。该模式试图在中心化控制与治理、以及本地自治之间取得平衡，其方式类似政府结构。在最高层级，一个“联邦权威”负责处理全局问题，并建立适用于所有参与智能体的总体规则与标准；在本地层级，智能体则通过将这些规则适配到本地语境来行使更高自治，并基于即时条件快速做决策。这种分层方式在顶层提供统一监督与治理，同时赋予最贴近执行的一侧足够灵活性，以有效应对本地挑战。
通过把中心治理与去中心化决策结合起来，联邦模式提供了一种平衡模型，可提升整体系统效率与协调能力。中心框架确保所有智能体遵循共同标准与协议，而本地自治允许快速、情境化的响应。该结构支持可扩展性，并让复杂的多方利益相关系统能够协同运作，确保全局与本地需求都能被有效满足。
供应链模式（Supply chain pattern）
该模式是联邦模式的扩展：存在许多法律实体，控制相对去中心化，但由正式的合同条款来治理协作。
智能体配置（Agent Configuration）
如图 5-20 所示，智能体配置定义了一个智能体的特征与属性。虽然不同智能体的配置可能各不相同，但至少会定义若干核心属性：
- 身份、描述与目的
- 任务执行策略
- 安全配置
- 策略与认证
- 智能体与工具可见性
注
这里先说明一下——我们非常努力地避免展示代码级片段，以免给人一种在描述某个特定实现或产品配置的印象。不过，在某些地方我们会讨论智能体、用户、交互以及许多其他组件的元数据。我们认为，把这些信息可视化、甚至真正理解它们，最好的方式是使用一种“编码隐喻”。
当出现这种情况时，我们会用一种 类似 YAML 的形式 来表示 agentic mesh 的元数据（不是严格的 YAML，但借用了 YAML 的表达力与结构）。这么做是因为 YAML 在技术社区中广为人知，而且它能够提供其他格式不容易做到的描述性（例如 JSON 更难阅读，而纯文本又不易表达关系或层级结构）。为强调这一点，我们会在图中使用 “Illustrative”（示意）标签来尽可能明确地传达：这只是用于说明的表达方式。
图 5-20. 智能体配置
身份、描述与目的（Identity, Description, and Purpose）
在智能体生态系统中，每个智能体都会被分配一个唯一标识符，称为 全限定名（FQN, fully qualified name） 。FQN 由两个关键要素组成：命名空间（namespace） 与 本地名（local name） 。二者结合，为在复杂网络中区分不同智能体提供了一套健壮机制。
命名空间在该识别框架中扮演重要角色，它把相关智能体归为一组。通过这种分组，管理大量智能体会更容易，因为每个命名空间为智能体运行提供了一个语境边界。本地名则是 FQN 中用于在命名空间内部 唯一标识 某个智能体的部分。
智能体的描述（description） 是面向人的可读概览，内容可以包含创建者认为有用的任何信息。从很多角度看，它相当于对智能体的总体摘要。
智能体的目的（purpose） 则是对“智能体应该做什么”的明确且细致的定义。其首要作用是为智能体的结果与输出设定清晰预期。此外，目的也是治理的基线：它为智能体如何被管理、如何被追责奠定基础。在目的定义清晰的前提下，就更容易制定策略、监控绩效，并处理任何偏离预期行为的情况。
我们建议，智能体的“做法”（事实上，尽可能多的配置内容）都应使用自然语言来定义，使整个过程既直观又易用。这种方式让创建者可以用日常语言描述智能体的目的与功能，降低门槛；同时也提升了系统与 LLM 的兼容性，因为 LLM 可以更容易地理解并与这些描述交互。
在我们的智能体生态系统中，智能体配置通过一个集中式的 注册表（registry） 与 市场（marketplace） 来维护。注册表充当一个详细、可搜索的数据库，用于存储并更新关于智能体（甚至工具）的信息。要找到一个智能体，关键在于拥有有用且细致的信息——这正是“目的”和“描述”的价值所在：它们是主要的检索条件，使智能体能够彼此定位。与此同时，市场的设计目标是让人们也能发现满足特定需求的智能体（同样以目的和描述作为关键搜索字段），提供一个易用界面，便于潜在用户浏览并找到他们可能想要交互的智能体。
任务执行策略（Task Execution Strategy）
当一个智能体通过其目的与描述信息被识别出来后，它就可以在前文所述的任务管理流程中被选中来完成某个具体任务。此时，“策略”开始发挥作用：它定义一套清晰的任务执行方案。
任务履约策略（task-fulfillment strategy） 是一组详细的、逐步的指令，描述智能体将如何完成被分配的任务。这些指令把总体目标拆解为更小、可管理的行动，从而为端到端的任务完成提供所需引导。
和配置的其他部分一样，这种做法也用自然语言书写。通过日常语言来描述策略与步骤，创建者无需专门的编码知识就能清晰表达想法。当然，自然语言有时会含糊，但正是这种特性在与 LLM 交互时带来独特优势：自然语言的内在弹性允许智能体的 LLM 在更广的语境中解释指令，使其即便没有一套完全细化的端到端流程，也仍能推进任务执行。
归根结底，“明确的策略”与“自然语言指令”的结合，使智能体能够以更动态、并且具备一定自治程度的方式执行任务。这不仅简化了执行过程，也使智能体能够按需调整与细化行动，确保它对任务环境中的意外挑战与变化保持响应性。
安全配置（Security Configuration）
智能体的安全配置包含若干组件，包括其角色以及特定的安全特性。
智能体的角色（role） 定义了该智能体被期望承担的职责与可执行的动作，类似于组织中人类岗位的角色定义。正如人类角色划定职责边界与权限范围一样，智能体角色为系统提供结构，并帮助确保交互与操作与整体目标对齐。
显然，安全是任何智能体生态系统中的首要关切，因此可以使用多种选项来保护智能体与其处理的数据。智能体配置允许你决定其安全特性。例如，双向传输层安全（mTLS） 属性可用于通过加密来保护通信，确保客户端与服务器之间的通信安全。此外，引入 OAuth2 可以实现受控访问，确保只有被授权的参与方——无论是智能体还是人类用户——才能与特定智能体交互。
进一步地，前文讨论过的智能体 FQN 还可用于与企业级的身份主记录系统（identity book of record） 集成，以验证凭据并确认智能体被指定的角色。该集成保证智能体身份能在更广泛的企业安全框架中被认证，类似于企业目录中对员工凭据的管理方式。
策略与认证（Policy and Certification）
与策略相关的配置属性充当护栏，用于引导智能体的行动与决策，使其行为与组织的战略目标保持一致。通常，附着在智能体上的策略会规定具体义务，这些义务可能来自监管要求、公司准则或伦理标准。它们为智能体必须运行的边界提供框架，确保所有行动遵循既定规则与规范。
认证属性则对这些策略形成补充：它们记录了智能体合规性的验证过程。认证会标注由哪个个人或权威主体确认该智能体符合其既定目的并遵守治理策略，以及该认证发生的时间戳。这一层验证在生态系统内部建立信任，因为它提供透明度与保证：智能体不仅被正确配置，而且持续与组织标准与伦理标准保持一致。
智能体与工具可见性（Agent and Tool Visibility）
智能体与工具的定义会集中维护在注册表中，注册表充当智能体生态系统配置数据的中心数据库。它相当于一个综合目录，确保所有智能体与工具都有清晰文档，从而让自动化系统与人类操作员更容易发现、引用并管理这些组件。
智能体可见性（agent visibility） 专门定义：某个智能体被允许与哪些其他智能体协作。更具体地说，当智能体在制定任务计划时，其中一步是识别它可以协作的其他智能体，以共同完成请求。通过控制可见性，组织可以把交互限制在对任务必要且合适的范围内，从而提升生态系统中的安全性与效率。类似地，工具可见性（tool visibility） 规定智能体被允许交互或调用哪些工具。
理想情况下，一个智能体生态系统应实现 零信任（zero-trust） 的安全姿态：默认情况下，除非被明确允许，否则任何智能体都看不到任何其他智能体或工具。零信任是一种安全原则，它假设不会对任何实体——无论在网络内外——赋予隐式信任，并要求对每一次访问尝试进行持续验证。该模型通过让智能体从“无默认权限”开始来降低风险，从而减少未授权行为的可能性，并限制被攻陷智能体可能造成的损害范围。
为了支持这种零信任模型，一个智能体会被配置为对其 可见的智能体数量为 0、可见的工具数量也为 0——本质上使其在未被授予特定权限前处于“不可用/不活跃”状态。这种刻意的限制确保智能体在没有明确授权的情况下无法造成意外后果或引发安全漏洞。
智能体与工具的可见性可以通过多种方式定义，包括使用 FQN 或 正则表达式（regex） 。FQN 提供精确且无歧义的指定方式；而 regex 则提供一种灵活的模式匹配方式，用于匹配智能体名称（例如，很容易通过 regex 让某个命名空间下的智能体或工具对其可见）。
总结（Summary）
本章清晰展示了智能体架构应如何被设计。我们强调，这类系统必须扎根于一套坚实的原则之上——例如可信性、可靠性与透明性——从而确保从任务规划到任务执行的每一个组件，都同时满足技术与伦理层面的基准要求。并且，通过将复杂操作拆解为可管理、可模块化的任务单元，再结合专业化工具的能力，智能体不仅能提升系统的鲁棒性，也为顺畅的规模化扩展与持续改进铺平道路。
在确立了智能体架构的基础之后，第 6 章将转向企业语境：探讨如何把“理论上设计良好的智能体”落到“企业级可用的智能体”——也就是安全、可扩展、可信，并能无缝融入现代组织运行体系的智能体。
