第 10 章探索能够思考、监控和自适应的认知 Agent

本章内容

理解 Agent 认知（cognition）和元认知（metacognition）作为工程概念的含义
将人类思维映射到认知 Agent 架构中
构建认知 Agent 架构
实现元认知过程

到目前为止，我们已经构建了能够进行推理（CoT、ReAct、ToT）、反思自身错误（Reflexion）、围绕目标进行迭代（智能体循环），以及记忆过去交互的智能体。由于这些能力中的每一种单独来看都很强大，你可能会认为，将多种推理模式叠加在一起会让智能体变得更加智能。但事实是，将它们简单堆叠只会让智能体变得更加复杂。可以把我们构建的这些智能体集合想象成一个装满钝器的工具箱。这里缺少的是一个知道该选择哪件工具并正确使用它的工匠。本章的目标，就是构建这个工匠。

在将智能体部署到生产环境时，我们发现智能体能够可靠地处理简单查询。但当用户提出需要整合多个来源的信息、识别检索内容中的矛盾，或者承认智能体没有足够信息来给出有信心回答的问题时，它往往会生成一种听起来很权威但实际上错误的回复。工具没有问题。检索没有问题。模型本身也具备能力。真正缺失的是智能体在行动之前对问题进行思考的能力，以及在行动过程中思考自身思考过程（元认知，metacognition）的能力。

在本章中，我们将从实际智能体工程的角度定义认知（cognition）和元认知（metacognition）。我们将借鉴 Minsky 的“心智社会”（society of mind）、Baars 的“全局工作空间理论”（global workspace theory）以及 Kahneman 的“系统 1 / 系统 2”框架，构建一种认知型智能体架构。在该架构中，专用模块共享一个公共工作空间，注意力机制动态分配控制权，而好奇心、自适应持续性以及自我感知的不确定性等涌现行为，则来自简单组件之间的相互作用。所有代码均使用 OpenAI Agents SDK 和 MCP 服务器实现，并直接建立在前几章介绍的智能体循环和推理模式之上。

10.1 将智能体认知与元认知理解为工程概念

在开始构建之前，我们需要理解为什么目前为止所构建的内容还不够。本节将介绍仅靠推理模式无法解决的失败模式，定义对于智能体而言认知和元认知的含义，并介绍三个将作为我们架构蓝图的理论框架。

10.1.1 具备能力但缺乏认知的智能体的五种失败模式

每一位将智能体投入生产环境的实践者，至少都见过这五种失败模式中的三种：自信但错误的回答、重复循环、僵化的计划、过度坚持的猜测，以及浅层组合。这些并不是边缘情况，而是那些能够推理但无法思考的智能体的默认行为。理解这些问题，是解决它们的第一步。每一种失败模式都对应一种特定的认知或元认知缺陷，我们将通过架构设计来解决这些问题，而不是依靠提示词、技能或推理技巧。

例如，可以让你的智能体运行 10 个不同类型的查询，并观察日志中是否出现这些模式。如果发现其中任何一种，缺失的模块就解释了问题产生的原因。

图 10.1 将每一种失败模式映射到它所缺失的认知能力，以及用于解决该问题的架构组件。在阅读后续描述之前，请先研究这张图。它是本章后续内容的诊断地图。

图 10.1 生产环境中智能体的五种失败模式与认知和元认知缺陷之间的映射关系

图 10.1 中的每一种失败模式都从左向右展开：可观察到的行为、底层的认知缺陷，以及用于修复它的架构组件。注意，这些修复方案并不是提示词技巧，而是我们将在第 10.2 节中构建的结构化组件。下面让我们逐一分析每种失败模式。

自信但错误的回答

智能体检索到一个目录页（table-of-contents page）或元数据记录，将其视为权威内容，并把它作为答案呈现出来。推理链看起来很完整，但输出结果却毫无价值。这种情况发生的原因是，智能体没有评估自身证据质量的机制。它检索到了某些内容，检索结果由于关键词匹配度较高而获得了高评分，于是智能体忠实地基于这些内容进行综合并生成回复。缺失的能力是证据评估（evidence evaluation）。解决方案是引入_评估模块（evaluation module）_，这是一个元认知组件，用于在中间结果到达用户之前评估其质量和相关性。

重复循环

智能体使用完全相同的措辞，连续三次重试失败的搜索查询，在没有任何进展的情况下消耗迭代次数。这是在生产日志中最令人沮丧的失败模式之一。智能体实际上正在完全按照智能体循环的要求执行——持续迭代直到收敛——但它并没有意识到自己陷入了停滞。缺失的能力是停滞感知（stagnation awareness）。解决方案是引入_注意力模块（attention module）_，该模块监控迭代进展，并在检测到智能体原地打转时重新引导认知循环。

僵化的计划

用户描述了一个与标准解决路径相矛盾的场景，但智能体仍然继续沿用标准路径，因为它的计划在任务拆解阶段就已经确定，并且从未被重新审视。这就是计划（plan）与信念（belief）之间的区别。当证据发生变化时，计划应该随之更新。缺失的能力是模型更新（model updating）：即在执行过程中修正智能体对问题理解的能力。解决方案是让_规划模块（planning module）_运行在重新规划模式下，并由评估模块检测到的矛盾信号触发。

过度坚持的猜测

当智能体被询问一个它没有任何数据支持的问题时，它没有表达不确定性，而是生成一个听起来合理的幻觉答案。这可以说是生产环境中最危险的失败模式，因为它会在不被察觉的情况下逐渐削弱用户信任。用户并不知道智能体其实是在猜测。缺失的能力包括知识边界检测（knowledge boundary detection），以及区分“知道”和“生成”的能力。解决方案是引入_置信度门控（confidence gate）_，这是一个元认知检查机制，当内部信号表明确定性较低时，它会阻止智能体向用户呈现结果。

浅层组合

智能体可以分别执行查询 A 和查询 B，但当被要求回答一个需要将二者进行连接（join）或比较的问题时，它会将其视为一个简单的单层查询。它无法自行设计一个多步骤工具工作流。缺失的能力是组合推理（compositional reasoning）。解决方案始于_感知模块（perception module）_，该模块必须识别出查询需要进行组合处理。随后，流程进入规划模块，由规划模块构建一个新的多工具执行计划。

推理与思考之间的差距

CoT 和 ReAct 等推理模式能够为定义明确的问题提供更好的答案。认知能力使智能体能够弄清楚问题本身是什么。元认知能力则使智能体知道自己什么时候已经解决了问题，以及什么时候还没有解决。两者之间的区别，在问题模糊、证据相互矛盾，或者智能体知识不完整的情况下尤为重要，而这些情况正是大多数真实生产环境场景的特点。

10.1.2 从推理原语到认知架构

如果你已经阅读过推理与规划章节，那么你已经了解如何为智能体提供思维链（Chain-of-Thought）、ReAct、思维树（Tree-of-Thoughts）、Reflexion 以及顺序思考（sequential thinking）。每一种方法都是一种强大的推理模式。但这里有一个它们都无法回答的问题：智能体应该在什么时候使用哪一种方法？

一个简单的事实查询不需要使用思维树。一个复杂的、多步骤的故障排查问题不应该只通过一次思维链推理来处理。一个模糊的问题需要先进行探索，然后才需要规划，而这些推理模式本身并不知道什么时候它们正在失效。

我们探索过的推理模式属于认知原语（cognitive primitives）——也就是单独的能力模块。本章讨论的是一种架构，它能够决定应该部署哪一种原语，监控其是否有效，并在无效时进行调整。可以这样理解：推理章节教会了智能体如何使用锤子、螺丝刀和锯子。本章则教会智能体如何阅读蓝图，并决定当前工作需要哪一种工具。

图 10.2 以视觉方式展示了这种区别。左侧展示的是孤立应用的推理模式。开发者在设计阶段选择推理模式，而智能体无论面对什么上下文都会使用该模式。右侧展示的是认知架构，它会根据当前问题动态地选择、组合和监控推理模式。

图 10.2 认知原语与认知架构的区别，其中推理原语成为整个过程中的一种选择机制

图中的关键区别在于认知架构右侧存在反馈循环。当评估组件（Evaluation component）检测到模糊性或矛盾等问题时，控制流会返回注意力机制（attention mechanism），后者可以将智能体重新引导到不同的策略上。而在左侧的静态推理模式中，不存在反馈机制。智能体会选择一种推理模式，并无论其效果如何，都坚持执行直到完成。

这正是我们将要解决的架构缺口。

10.1.3 定义智能体的认知能力

在构建任何东西之前，我们需要准确说明在智能体系统的上下文中，“认知”具体指什么。我们并不是在讨论机器意识等哲学层面的观点，而是在定义那些可以被工程化实现并进行衡量的可观察能力。

智能体认知（agent cognition） 是指智能体对任务所建立的内部模型的质量。一个具备认知能力的智能体，不只是处理查询并生成回复。它会构建对用户需求的表示，推理应该如何处理该问题，并随着新信息的到来不断更新这一表示。认知型智能体由以下四种能力定义：

任务拆解（Task decomposition） 是指在没有被告知具体方法的情况下，将一个新问题拆分为多个子任务的能力。这超越了简单套用模板。认知型智能体遇到一个此前从未见过的问题时，能够自行判断需要执行哪些步骤。
依赖关系推理（Dependency reasoning） 是指识别不同子任务之间依赖关系，并按照正确顺序执行它们的能力。仅仅将问题拆成三个部分是不够的。智能体需要知道部分 B 依赖部分 A 的输出，而部分 C 可以与其他部分并行执行。
组合式工具使用（Compositional tool use） 是指以智能体从未被明确展示过的方式组合工具的能力。智能体拥有搜索工具和比较工具，但没有人告诉它应该将两者连接起来处理交叉验证类查询。认知型智能体能够根据问题结构自行推断出这种工具组合方式。
模型更新（Model updating） 是指随着新信息到来而修正自身理解的能力。智能体开始执行任务时，可能基于用户需求建立了一个假设。在执行过程中，新的证据可能与该假设产生冲突。认知型智能体会更新自己的计划；缺乏认知能力的智能体则会继续沿着原路径执行。

表 10.1 将认知能力映射到智能体行为，展示每种能力存在和缺失时分别会产生什么结果。每种能力都对应支持它的原语（primitive），如表中所示。原语定义了智能体在其指令中所采用的推理策略。

表 10.1 智能体认知能力

能力	存在时的表现	缺失时的表现	支持原语
任务拆解（Task decomposition）	智能体能够创造新的子任务执行序列	智能体将复杂查询视为简单的信息查找	CoT、规划（planning）
依赖关系推理（Dependency reasoning）	智能体能够在遵循依赖关系的同时安排执行步骤	智能体以任意顺序执行步骤	ToT、顺序思考（sequential thinking）
组合式工具使用（Compositional tool use）	智能体能够以新的方式组合工具	智能体将查询映射为单一工具调用	ReAct
模型更新（Model updating）	当证据与当前理解产生冲突时，智能体会修正计划	智能体无论发生什么都会遵循最初计划	Reflexion、重新规划（replanning）

10.1.4 定义智能体的元认知能力

如果说认知（cognition）是智能体思考的质量，那么元认知（metacognition）就是智能体思考自身思考过程的能力。这并不是一个哲学层面的细节，而是生产级智能体系统中最具实际价值的能力。对于智能体而言，元认知包含三个方面：

置信度校准（Confidence calibration） 是指智能体表达出的置信程度与实际正确性之间的相关程度。它并不是指智能体是否会说“我不确定”，因为通过提示词可以让语言模型对任何事情都这样表达。真正的置信度校准意味着，智能体的内部信号（token 概率、检索评分以及证据一致性）能够预测输出是否正确。Wang 等人（2025）在 DMC 框架中的研究表明，从 token 似然度中提取出的隐式置信度指标，比语言表达出的显式置信度更能预测答案正确性。这正是我们将在架构设计中利用的差距。
停滞检测（Stagnation detection） 是指智能体识别自身是否正在取得进展的能力。缺乏元认知能力的智能体会不断重复相同的失败方法，直到达到迭代次数限制。而具备元认知能力的智能体会在两轮迭代后发现自己的研究结果没有变化，并转向另一种策略。
知识边界感知（Knowledge boundary awareness） 是指当智能体处于自身知识范围之外时，其行为能够发生变化的程度。MetaMedQA 基准测试（Nature Communications，2025）对此进行了直接测试，结果发现，当正确选项并不存在于候选答案中时，模型仍然持续给出自信的回答。模型无法判断自己什么时候不知道答案。将知识边界感知能力构建到架构中，正是解决这一问题的方法。

隐式置信度与显式置信度之间的差距

研究表明，LLM 的内部不确定性信号（token 熵、logprob 分布）比其语言表达出的置信度更能预测答案正确性。一个智能体说“我很有信心”几乎无法提供有效信息，但如果一个智能体在生成答案 token 时具有较高的概率分布，那么它确实更有可能给出正确答案。我们将在第 10.3 节构建元认知监控机制时利用这一差距。

10.1.5 三个理论基础

我们即将构建的认知型智能体架构并不是凭空创造出来的。它借鉴了认知科学和心理学领域三个成熟的理论框架。每一个理论框架都直接映射到一个架构组件。我们的目标不是复制人类认知，而是从那些能够产生智能行为的系统中借用设计模式。

图 10.3 展示了每个理论框架如何映射到我们架构中的具体组件。这是理论与工程之间的桥梁，也是后续认知架构构建的基础。

图 10.3 心智理论的三个理论基础与智能体架构组件之间的映射关系

在图中，每一条垂直箭头都代表我们从理论基础中引入的一项设计原则。左侧，Minsky 告诉我们应该构建多个专用智能体模块，而不是一个庞大的单体智能体。中间，Baars 告诉我们这些智能体模块需要一个共享工作空间来进行通信。右侧，Kahneman 告诉我们需要一个路由机制，根据问题复杂度匹配处理深度。下面让我们看看每个理论基础如何映射到我们的认知架构中。

Minsky 的心智社会理论（society of mind）

Marvin Minsky 认为，心智并不是一个单一的智能过程，而是由许多专门化智能体组成的社会。这些智能体单独来看都不具备智能，但它们之间的交互会产生智能行为。没有任何一个单独的神经元能够理解语言。没有任何一个单独的大脑区域能够解决数学问题。智能来自许多简单、专门化组件之间的相互作用。

对于智能体架构而言，这一观点带来了明确启示：不要再试图构建一个单一的“超级智能体”。应该构建多个专用智能体模块：一个负责理解问题，一个负责规划，一个负责执行，一个负责评估。然后让智能通过这些模块之间的交互涌现出来。这与传统的多智能体系统不同，后者通常是智能体之间相互传递消息。而这里是一种更紧密的集成方式，其中智能体模块共享状态，并通过一个公共媒介相互影响。

Baars 的全局工作空间理论（global workspace theory）

Bernard Baars 提出了一个观点：意识的工作方式类似于剧院。专门化的神经过程在后台运行，各自执行不同任务。但存在一个唯一的舞台——全局工作空间，在这里，当前最重要的信号会被广播给所有其他过程。这种广播机制，就是我们体验到的有意识注意力。

对于智能体架构而言，这为我们提供了_认知工作空间（cognitive workspace）_的概念——一个所有智能体模块都可以读取和写入的共享状态对象。工作空间不是一个消息队列，而是智能体当前认知状态的动态表示：它知道什么、正在尝试做什么、当前有多大信心，以及哪些信号需要关注。当评估模块向工作空间写入“检测到矛盾”时，其他所有模块都能够看到这一信息。

Kahneman 的系统 1 和系统 2

Daniel Kahneman 的理论描述了两种思考模式。系统 1 快速、自动且无需费力：例如识别人脸或阅读文字时，你无需刻意思考即可完成。系统 2 缓慢、谨慎且需要投入认知资源：例如解决数学问题或规划旅行时，你需要进行深入思考。

对于智能体架构而言，这意味着并非每个查询都值得进行完整的认知处理。一个简单的事实查询应该完全绕过规划和评估阶段，直接从感知进入执行并返回响应。而复杂、模糊或存在矛盾的查询，则应该触发完整的认知循环，包括规划、评估以及可能的重新规划。注意力模块负责实现这种路由机制。这不仅是能力层面的考虑，也是效率层面的考虑。不必要的推理会消耗 token，增加延迟，同时并不会提升结果质量。

10.2 将心智映射到认知智能体架构中

现在我们已经准备好开始构建。本节将通过代码展示该架构中的每个组件，从共享工作空间开始，逐步介绍每一个专用智能体模块。到第 10.3 节结束时，你将拥有组装一个可运行认知智能体所需的全部组件。

10.2.1 架构概览

图 10.4 是理解整个认知智能体架构最重要的一张图。它展示了完整的认知智能体架构，包括全部七个组件以及它们之间的连接关系。接下来的每个代码清单都会实现该图中的一个部分。当你需要理解某个组件如何融入整体架构时，可以随时参考这张图。

图 10.4 认知智能体架构展示了从用户初始查询到认知循环的流程，该循环会在各模块之间不断迭代。

图中的信息很多，因此我们逐层拆解。位于中心的是认知工作空间，它是所有模块共同读取和写入的共享状态。这对应 Baars 理论中的全局工作空间，并通过一个结构化的 Pydantic 模型实现。它保存六类状态信息：任务表示（智能体认为自己正在被要求完成的任务是什么）、活跃假设（候选策略）、中间结果（目前已经发现的信息）、置信状态（智能体对当前判断的确信程度）、执行历史（已经尝试过的操作），以及注意力信号（用于重新引导认知循环的标志）。

围绕工作空间运行的是五个专用模块。感知模块读取原始用户查询，并填充任务表示。规划模块读取任务表示，并提出执行策略。执行模块通过调用 MCP 服务器中的工具或内部函数来执行计划。评估模块负责判断结果质量，并更新置信度。注意力模块读取工作空间中的信号，并决定下一个运行的模块。

记忆模块位于工作空间旁边，并连接到官方 MCP 记忆服务器（modelcontextprotocol/server-memory）。它会在规划之前主动检索相关经验，并在评估之后记录执行结果。第 9 章介绍的智能体循环包裹整个系统，负责驱动迭代、收敛以及退出条件。

这就是代码中的心智社会（society of mind）。没有任何一个单独的模块具备智能，但它们通过共享工作空间进行交互，产生了任何单个模块都无法独立产生的行为。

10.2.2 认知工作空间

认知（全局）工作空间是整个架构的核心，就像智能体循环中的状态一样。每个模块都会从中读取信息。每个模块也都会向其中写入信息。它不是对话历史，也不是临时记录区。它是对智能体当前认知状态的结构化表示：它相信什么、它有多大把握、它已经尝试过什么，以及哪些内容需要关注。

如果你回顾智能体循环章节中的 ResearchState，认知工作空间会让你感到熟悉，但它走得更远。ResearchState 会在多轮迭代中累积研究发现。而认知工作空间维护的是对智能体自身推理过程的模型。它不仅记录智能体发现了什么，还记录智能体对这些发现的信心程度。它还会跟踪这些发现之间是否存在矛盾，以及当前策略是否正在取得进展。

代码清单 10.1 展示了构成认知状态（即工作空间）的各种 Pydantic 对象。这个状态是智能体各个模块之间共享的结构化通信通道。它包含诸如任务类型（TaskType）、当前策略（StrategyType）、注意力信号（AttentionSignal）、发现结果或评分（Finding），以及模块交互历史等信息。

代码清单 10.1 01_cognitive_workspace.py

from pydantic import BaseModel, Field
from enum import Enum
from typing import Optional

class TaskType(str, Enum):
   SIMPLE_LOOKUP = "simple_lookup"
   MULTI_STEP = "multi_step"
   CONTRADICTORY = "contradictory"
   AMBIGUOUS = "ambiguous"
   COMPOSITIONAL = "compositional"
   UNKNOWN = "unknown"

class StrategyType(str, Enum):
   DIRECT = "direct"              #1
   DECOMPOSE = "decompose"        #2
   EXPLORE = "explore"            #3
   HYPOTHESIS_TEST = "hypothesis_test"  #4

class AttentionSignal(str, Enum):
   NONE = "none"
   LOW_CONFIDENCE = "low_confidence"
   STAGNATION = "stagnation"
   CONTRADICTION = "contradiction"
   KNOWLEDGE_GAP = "knowledge_gap"
   TASK_COMPLETE = "task_complete"

class Finding(BaseModel):
   content: str
   source: str
   relevance_score: float = 0.0
   quality_note: str = ""

class CognitiveWorkspace(BaseModel):
   # Task representation
   raw_query: str = ""
   task_type: TaskType = TaskType.UNKNOWN
   extracted_entities: list[str] = Field(default_factory=list)
   complexity_estimate: float = 0.0   #5
   ambiguities: list[str] = Field(default_factory=list)

   # Active hypotheses
   current_strategy: StrategyType = StrategyType.DIRECT
   sub_goals: list[str] = Field(default_factory=list)
   alternative_strategies: list[str] = Field(default_factory=list)

   # Intermediate results
   findings: list[Finding] = Field(default_factory=list)
   memory_hits: list[str] = Field(default_factory=list)  #6

   # Confidence state
   confidence: float = 0.5          #7
   confidence_trend: list[float] = Field(default_factory=list)

   # Execution history
   steps_taken: list[str] = Field(default_factory=list)
   failed_approaches: list[str] = Field(default_factory=list)
   iteration_count: int = 0

   # Attention signals
   active_signal: AttentionSignal = AttentionSignal.NONE
   signal_source: str = ""

注释：

#1 针对简单查询进行直接执行（系统 1）
#2 将多步骤问题分解为子任务
#3 在确定计划之前进行探索以收集信息
#4 当证据相互矛盾时测试相互竞争的假设
#5 从 0.0（简单）扩展到 1.0（高度复杂）
#6 从 MCP 记忆服务器中检索过去的经验
#7 从 0.5（中性状态）开始，并向 1.0（有信心）或 0.0（不确定）移动

active_signal 字段是其中最重要的部分。这个字段是模块之间传递紧急情况的机制。当评估模块检测到矛盾时，它会将 active_signal 设置为 CONTRADICTION。当注意力模块读取到这个信号后，它会将控制权路由到规划模块进行重新规划，而不是继续执行下一步操作。这就是全局工作空间广播机制：任何模块都可以发出信号，而注意力模块负责决定如何处理这个信号。

10.2.3 感知模块

感知模块是智能体接触现实世界的第一环节。它接收原始用户查询，并将其转换为工作空间中的结构化任务表示。这不仅仅是解析过程；它还涉及理解和分类问题、提取关键实体、识别歧义，以及评估任务复杂度。

复杂度估计尤其重要，因为它决定了架构其余部分参与推理的深度。低于 0.3 的复杂度估计可能会触发系统 1 快速路径，跳过规划和评估阶段，直接进入执行阶段。高于 0.7 的复杂度估计则会触发完整的认知循环。这就是将 Kahneman 双过程理论实现为路由决策。

代码清单 10.2 02_perception_module.py

from agents import Agent

perception_agent = Agent(
   name="Perception",
   instructions="""You are the perception module of a cognitive agent.
   Your job is to analyze a user query and produce a structured
   understanding of the task BEFORE any action is taken.

   For each query, determine:
   1. task_type: Is this a simple_lookup, multi_step, contradictory,
      ambiguous, or compositional problem?
   2. extracted_entities: What are the key nouns, concepts, or
      identifiers in the query?
   3. complexity_estimate: From 0.0 (trivial) to 1.0 (highly complex).
      Consider: number of steps needed, whether information must be
      combined from multiple sources, whether the query contains
      contradictions or ambiguity.
   4. ambiguities: List anything in the query that could be
      interpreted multiple ways.

   Be honest about complexity. A question that looks simple but
   requires cross-referencing is at least 0.5. A question containing
   "but" or "however" or "already tried" is likely contradictory
   and should be at least 0.6.

   You do NOT answer the user's question. You only analyze it.""",
   output_type=TaskRepresentation,    #1
)

注释:

#1 结构化输出确保感知模块始终生成类型明确、可解析的结果。

你可以将感知模块的作用理解为对初始用户查询执行的一种分诊过程，它生成一个任务表示，用于对查询将如何被处理进行分类。

10.2.4 规划模块

规划模块读取工作空间中的任务表示，并提出一个策略。这也是认知架构与标准智能体差异最大的地方。标准智能体通常只有一种处理方式：接收查询、调用工具并生成响应。而规划模块会根据感知模块发现的信息，从多个策略中进行选择。

图 10.5 展示了规划模块的策略选择逻辑，将其表示为一棵决策树。感知模块提供的任务类型和复杂度估计会驱动策略选择。注意，HYPOTHESIS_TEST（假设测试）策略只有在感知模块标记存在矛盾时才会被触发。这说明该架构会根据问题本身的特性做出响应，而不是采用一种适用于所有情况的通用方案。

图 10.5 规划模块策略选择

图 10.5 还展示了一个关键步骤：检查记忆模块是否已经提供了相关的历史经验。如果知识图谱中包含与当前问题相关的实体，规划模块会将这些经验融入其策略中。一个能够知道“上一次类似问题是由连接池耗尽导致的”的假设测试计划，会比从零开始分析的计划更加高效。

代码清单 10.3 展示了规划模块的智能体指令，其中计划本身取决于当前任务所采用的策略。如果之前任务中的记忆信息（历史任务记忆）可从记忆模块中获取，智能体将利用这些信息来加速规划过程。该模块的输出是 PlanOutput（计划），后续将由执行模块执行。

代码清单 10.3 03_planning_module.py

planning_agent = Agent(
   name="Planner",
   instructions="""You are the planning module of a cognitive agent.
   You receive a task representation from the perception module and
   propose an execution strategy.

   Select a strategy based on the task:
   - DIRECT: For simple lookups with complexity < 0.3. One tool call.
   - DECOMPOSE: For multi-step problems. Break into ordered subtasks.
     Identify which subtasks depend on others.
   - EXPLORE: For ambiguous problems. Propose information-gathering
     steps before committing to an approach.
   - HYPOTHESIS_TEST: For contradictory scenarios. Generate 2-3
     competing hypotheses and propose how to test each one.

   If memory_hits are present in the workspace, use them to inform
   your strategy. Past experience should accelerate planning, not
   replace it.

   Output a plan with: strategy_type, ordered list of sub_goals,
   and any alternative_strategies worth keeping in reserve.""",
   output_type=PlanOutput,
)

规划智能体模块负责确定认知策略、审查记忆，并结合这些记忆信息以及当前策略来制定计划。该模块的输出会直接驱动执行模块。

10.2.5 执行模块

执行模块是认知架构中最简单的组件。它从工作空间中获取当前计划步骤，通过 MCP 服务器或函数调用执行该步骤，并将结果写回工作空间。如果你之前构建过 ReAct 智能体，这个过程会让你感到熟悉。不同之处在于上下文环境：执行模块运行在一个更加丰富的环境中，它产生的结果会先经过评估模块的评估，然后才会有内容传递给用户。

这里的关键设计选择是结果标注。执行模块不会简单地返回原始工具输出。它会将每个结果封装为一个 finding 对象，其中包含相关性评分和质量说明。这些元数据正是评估模块用来判断执行步骤是否推动任务进展的信息。

代码清单 10.4 展示了一个简单的执行智能体，它连接到单个 MCP 服务器（文件系统），用于执行本地搜索。作为每次工具执行的一部分，该智能体会输出一个发现结果元数据对象，用于定义执行结果的内容、来源、相关性评分以及质量说明。

代码清单 10.4 04_execution_module.py

from agents import Agent, function_tool
from agents.mcp import MCPServerStdio

# Connect to domain-specific tools via MCP
search_server = MCPServerStdio(
   command="npx",
   args=["-y", "@modelcontextprotocol/server-filesystem", "./docs"]  #1
)

execution_agent = Agent(
   name="Executor",
   instructions="""You are the execution module of a cognitive agent.
   You receive a specific sub-goal from the current plan and execute
   it using available tools.

   For each result, provide:
   - content: The relevant information you found
   - source: Where it came from
   - relevance_score: 0.0 to 1.0, how relevant to the sub-goal
   - quality_note: Any concerns about the result quality
     (e.g., "source is a table of contents, not actual content",
      "result is partial", "high confidence match")

   Be honest about quality. A retrieval that returns metadata
   instead of content should get a low relevance_score and a
   quality_note explaining why.""",
   mcp_servers=[search_server],
   output_type=Finding,
)

注释:

#1 替换为你的领域专用 MCP 服务器（Brave Search、数据库、API 等）

输出的发现结果对象不仅有助于引导评估模块，也有助于引导整个认知过程。现在，一个导致较差响应的工具调用结果可以很容易地被识别出来。

10.2.6 评估模块

评估模块是整个架构中的元认知核心。它不会寻找信息。它不会执行计划。它关注的是思考本身。在每次执行步骤之后，评估模块会读取工作空间，并提出以下问题：“这样做有效吗？证据是否一致？我们是否正在取得进展？我们应该继续当前方向，还是改变策略？”

这个组件解决了第 10.1.1 节中五种失败模式里的三种。证据质量评估可以捕获自信但错误的答案。停滞检测可以捕获重复循环的问题，而矛盾标记可以捕获僵化的计划。所有这些检查都会在任何内容呈现给用户之前完成。

代码清单 10.5 展示了评估模块的评估智能体以及输出类型。评估是认知功能中的关键组成部分。如果缺少这一环节，或者这一阶段执行效果不佳，那么响应质量和完整性将会直接反映出这个问题。

代码清单 10.5 05_evaluation_module.py

class EvaluationResult(BaseModel):
   progress_assessment: str        #1
   consistency_check: bool         #2
   confidence_delta: float         #3
   contradictions: list[str] = Field(default_factory=list)
   recommendation: str             #4

evaluation_agent = Agent(
   name="Evaluator",
   instructions="""You are the evaluation module of a cognitive agent.
   After each execution step, you assess the quality of the results
   and the overall trajectory of the task.

   Assess:
   1. progress_assessment: Did this step advance us toward the goal?
      Be specific about what was gained or not gained.
   2. consistency_check: Are the new results consistent with previous
      findings? If not, flag contradictions.
   3. confidence_delta: Should confidence go up or down based on this
      step? Return a value from -0.3 to +0.3.
   4. contradictions: List any conflicts between new and existing
      evidence.
   5. recommendation: One of CONTINUE, REPLAN, ESCALATE, TERMINATE.
      - CONTINUE: Progress is good, proceed with current plan.
      - REPLAN: Evidence suggests current approach is wrong.
      - ESCALATE: Agent cannot resolve this, surface uncertainty.
      - TERMINATE: Goal is achieved with sufficient confidence.

   Be ruthless about quality. A finding with a low relevance_score
   or a quality_note flagging metadata should NOT increase confidence.
   Two consecutive steps with no new information should trigger
   REPLAN, not CONTINUE.""",
   output_type=EvaluationResult,
)

注释：

#1 对该步骤完成内容的叙述性评估
#2 如果新的证据与现有发现相矛盾，则为 False
#3 正值表示更加确信，负值表示信心降低。
#4 驱动注意力模块路由的信号

评估并不是反思

（推理章节中介绍的）Reflexion 会在响应完成之后捕获错误。而评估模块会在执行过程中进行监控，在问题不断累积之前发现它们。Reflexion 是事后修正，而评估是实时监控。两者都很有价值，但评估可以预防那些原本需要 Reflexion 在事后修复的错误。

10.2.7 注意力模块

注意力模块是使该系统成为认知架构，而不仅仅是多智能体流水线的关键组件。它读取工作空间中的注意力信号，并决定下一个由哪个模块获得控制权。在默认情况下，它遵循标准认知循环：感知、规划、执行、评估。但它可以根据工作空间中的信号，在任何阶段打破这一循环。

图 10.6 展示了注意力模块的路由逻辑。在调试认知智能体时，请记住这张图。如果智能体表现异常，可以沿着这棵决策树追踪，理解它为什么选择了当前的执行路径。

图 10.6 注意力路由决策树

图 10.6 底部的快速路径值得重点研究。当感知模块将某个查询分类为低复杂度，并且记忆模块已经提供了相关的历史经验时，注意力模块可以跳过完整的认知循环。随后，它可以直接路由到响应生成阶段。这就是系统 1 的实际应用。智能体识别出一个熟悉的问题，并基于经验直接响应，而无需进行额外推理。在生产环境中，这条路径可以显著降低常规查询的延迟和 Token 消耗。

代码清单 10.6 展示了注意力模块。与其他模块不同，注意力模块完全由代码控制。这使得注意力中的所有路由行为都是确定性的，并且受到其他模块在全局认知工作空间中更新的认知状态约束。

代码清单 10.6 06_attention_module.py

def route_attention(workspace: CognitiveWorkspace) -> str:
   """Read workspace signals and determine next module."""

   # System 1 fast path
   if (workspace.complexity_estimate < 0.3
       and workspace.memory_hits
       and workspace.active_signal == AttentionSignal.NONE):
       return "FAST_RESPOND"                              #1

   # Signal-driven routing
   if workspace.active_signal == AttentionSignal.TASK_COMPLETE:
       return "RESPOND"

   if workspace.active_signal == AttentionSignal.STAGNATION:
       workspace.failed_approaches.append(
           workspace.current_strategy.value
       )
       return "META_PLAN"                                 #2

   if workspace.active_signal == AttentionSignal.CONTRADICTION:
       workspace.current_strategy = StrategyType.HYPOTHESIS_TEST
       return "PLAN"                                      #3

   if workspace.active_signal == AttentionSignal.LOW_CONFIDENCE:
       if workspace.confidence < 0.2:
           return "ESCALATE"                              #4
       return "PLAN"

   if workspace.active_signal == AttentionSignal.KNOWLEDGE_GAP:
       return "MEMORY"

   # Default cognitive cycle
   if not workspace.extracted_entities:
       return "PERCEIVE"
   if not workspace.sub_goals:
       return "PLAN"
   if workspace.iteration_count == 0 or workspace.active_signal == AttentionSignal.NONE:
       return "EXECUTE"

   return "EVALUATE"

#1 绕过完整认知循环，用于处理简单且熟悉的问题
#2 元规划会记录失败的策略，以避免重复执行。
#3 检测到矛盾时，会覆盖当前策略
#4 当低于最低置信度阈值时，停止继续尝试，并呈现不确定性

控制复杂度和置信状态的硬编码阈值可以直接在代码中调整。这些值代表静态的认知设置或个性特征。虽然它们也可以动态设置，但在你对该架构积累更深入的实践经验之前，最好保持它们为静态配置。

10.2.8 记忆模块与 MCP 记忆服务器

记忆模块通过 @modelcontextprotocol/server-memory 为认知智能体提供持久化的长期记忆。该服务器是 MCP 项目提供的官方参考记忆服务器。它通过三个基本结构实现本地知识图谱：实体（主要节点）、关系（以主动语态存储在实体之间的有向连接）以及观察（附加到实体上的离散信息片段）。它不需要外部数据库或嵌入服务；该服务器在本地运行，并将数据持久化到一个 JSON 文件中。我们之前已经在第 5 章关于记忆和知识的内容中探索过该服务器。

这种知识图谱结构与认知智能体理解自身经验的方式高度契合。问题类型会成为实体。有效的策略会作为观察信息附加到这些实体上。关系则连接相关的问题类型、成功的工具组合以及已知失败模式。随着时间推移，知识图谱会成为智能体的组织记忆：它不是过去交互的简单日志，而是一个结构化的学习模型。

图 10.7 展示了记忆模块如何在 MCP 记忆服务器工具之上封装一个主动式认知层。三个核心行为分别是主动检索、经验记录以及关系构建。正是这些行为，让一个简单的知识图谱转变为认知循环中的主动参与者。

图 10.7 记忆模块在 MCP 记忆服务器之上构建的三种行为

图 10.7 从上到下可以理解为一个时间线。在规划模块运行之前，记忆模块会搜索知识图谱，查找与当前任务相关的实体，并将任何匹配结果注入工作空间。在评估模块完成评估之后，记忆模块会记录执行结果。当智能体发现某个策略在不同问题类型中都取得成功时，记忆模块会构建一个连接这些问题类型的关系。

以下是 MCP 服务器配置：

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

代码清单 10.7 展示了记忆模块智能体，以及用于支撑状态管理的对应记忆 MCP 服务器。该模块负责保存经历过的记忆，并理解和构建那些共享相似推理策略的任务问题之间的关系。通过在记忆中构建关系，认知架构能够利用捕获的经验理解问题之间的联系，并实现跨问题的泛化。

代码清单 10.7 07_memory_module.py

from agents.mcp import MCPServerStdio

memory_server = MCPServerStdio(
   command="npx",
   args=["-y", "@modelcontextprotocol/server-memory"]
)

memory_agent = Agent(
   name="Memory",
   instructions="""You are the memory module of a cognitive agent.
   You manage long-term experience using a knowledge graph.

   You have three responsibilities:

   PROACTIVE RETRIEVAL: When given extracted entities from a task,
   use search_nodes to find relevant past experience. Return any
   matching entities and their observations as memory_hits.

   EXPERIENCE RECORDING: When given a completed task with its
   evaluation result, record the experience:
   - If the problem type is new, use create_entities to add it,
     then add_observations with the strategy used and outcome.
   - If the problem type exists, use add_observations to append
     the new strategy and outcome.
   - Always record both successes and failures. Failed approaches
     are valuable -- they prevent the agent from repeating mistakes.

   RELATION BUILDING: When you notice that two problem entities
   share a common strategy or resolution pattern, use
   create_relations to capture that structural knowledge.
   Example: create_relations between "timeout_under_load" and
   "connection_pool_exhaustion" with relation
   "often_co_occurs_with".

   Be concise in observations. Store the strategy name, the
   outcome (success/failure), and one sentence about why.""",
   mcp_servers=[memory_server],
)

为什么选择知识图谱，而不是向量存储

参考 MCP 记忆服务器使用的是知识图谱，而不是向量嵌入。这是一个经过刻意权衡后的设计选择。向量存储用于查找看起来相似的内容，而知识图谱用于查找具有结构关联的内容。对于认知智能体而言，结构关系比表面相似性更加重要。知道“高负载下的超时错误”和“连接池耗尽”属于相关的问题类型（通过共享关系连接）比知道它们具有相似的嵌入向量更有价值。

如果读者需要在大型记忆存储中进行语义搜索，可以替换为社区提供的 MCP 记忆服务器，例如 mcp-mem0 或 mcp-memory-service，而无需改变认知架构，因为 MCP 接口保持不变。

10.3 构建并运行认知智能体

我们已经拥有了所有组件。现在，我们将它们组装成一个可运行的系统，在真实场景中运行它，并实现使该架构具备生产可用性的元认知监控模式。

10.3.1 认知循环

认知循环是第 10.2 节中的架构与第 9 章中的智能体循环相结合的地方。外层 L2 循环负责处理迭代、收敛以及退出条件。认知架构负责每次迭代内部的处理质量。而注意力模块则负责协调二者之间的交互。

图 10.8 展示了这种分层结构。智能体循环负责宏观层面的迭代（“继续还是停止”）。认知循环负责微观层面的处理（“在当前迭代中下一步应该做什么”）。注意力模块位于两者边界之间，将评估信号转换为路由决策。

图 10.8 叠加在智能体循环之上的认知循环

图 10.8 中的内部认知循环可以在一次智能体循环迭代中运行多次。如果评估模块发出信号（停滞、矛盾或低置信度），注意力模块会在同一次迭代中将控制权路由到其他模块。只有当某一步执行完成且没有触发信号时，控制权才会返回到智能体循环，由其检查是否满足收敛条件。

这意味着一次迭代可能包含感知、规划、执行、评估、重新规划以及重新执行等多个阶段，而所有这些过程都由工作空间中的信号驱动。

代码清单 10.8 展示了 run_cognitive_loop 函数。该循环执行内部认知循环，并根据路由输出，通过注意力模块将信号分发到对应的智能体模块。

代码清单 10.8 08_cognitive_loop.py

async def run_cognitive_loop(
   query: str,
   max_iterations: int = 10,
   confidence_threshold: float = 0.8,
   max_cognitive_steps: int = 5,          #1
):
   workspace = CognitiveWorkspace(raw_query=query)

   async with memory_server, search_server:
       for i in range(max_iterations):
           workspace.iteration_count = i

           # Inner cognitive cycle
           for step in range(max_cognitive_steps):
               next_module = route_attention(workspace)

               if next_module == "FAST_RESPOND":
                   return build_response(workspace)     #2

               if next_module == "RESPOND":
                   return build_response(workspace)

               if next_module == "ESCALATE":
                   return build_uncertain_response(workspace)  #3

               if next_module == "PERCEIVE":
                   result = await Runner.run(
                       perception_agent,
                       input=workspace.raw_query
                   )
                   update_workspace_perception(workspace, result)

               elif next_module == "MEMORY":
                   result = await Runner.run(
                       memory_agent,
                       input=format_memory_query(workspace)
                   )
                   update_workspace_memory(workspace, result)

               elif next_module == "PLAN":
                   result = await Runner.run(
                       planning_agent,
                       input=format_planning_input(workspace)
                   )
                   update_workspace_plan(workspace, result)

               elif next_module == "EXECUTE":
                   result = await Runner.run(
                       execution_agent,
                       input=format_execution_input(workspace)
                   )
                   update_workspace_execution(workspace, result)

               elif next_module == "EVALUATE":
                   result = await Runner.run(
                       evaluation_agent,
                       input=format_evaluation_input(workspace)
                   )
                   update_workspace_evaluation(workspace, result)

                   if workspace.active_signal == AttentionSignal.TASK_COMPLETE:
                       break                            #4

               workspace.active_signal = AttentionSignal.NONE  #5

           # Check convergence at the agentic loop level
           if workspace.confidence >= confidence_threshold:
               break

       # Record experience in memory after completion
       await record_experience(workspace)               #6
       return build_response(workspace)

注释:

#1 限制内部认知循环，防止单次迭代中出现无限运行
#2 系统 1 快速路径会直接返回，而无需完整的认知处理过程。
#3 优雅降级：呈现不确定性，而不是产生幻觉
#4 当评估模块标记任务完成时，跳出内部循环
#5 处理完成后重置信号，防止无限信号循环
#6 无论成功还是失败，都始终将结果记录到知识图谱中。

如果需要回顾智能体循环的组件和运行方式，请参考第 9 章。本代码使用认知循环架构替代了 L1 内部智能体循环。同时，它在外层叠加了 L2 注意力模块和路由机制，用于控制外部循环。

10.3.2 使用 MCP 构建完整的认知智能体

你可以通过代码清单 10.1 到 10.8 查看完整组合后的认知架构。这些代码可以直接运行，用于展示该架构在实际场景中的工作方式。运行之后，请务必查看 OpenAI 控制台中的追踪信息，以了解整个过程是如何工作的。

该代码清单将所有模块组装成一个完整的可运行系统。它连接两个 MCP 服务器：用于长期知识存储的官方记忆服务器，以及用于领域工具的文件系统服务器。它会初始化工作空间，并针对一个具体查询运行认知循环。

10.3.3 演练：观察认知循环的实际运行过程

为了看到该架构为何值得拥有这样的复杂度，我们需要一个简单 ReAct 智能体会答错的问题。考虑下面这个查询：

“用户反馈他们的部署流水线会间歇性失败，但只发生在高流量期间。标准修复方案（增加超时阈值）已经应用，但并没有解决问题。”

标准智能体会搜索“部署流水线超时失败”，找到关于超时配置的文档，并将其作为答案提供。但用户已经尝试过这个方案。由于用户明确告诉我们该方法无效，因此标准答案从定义上就是错误的。

以下是认知智能体处理该问题的逐步过程：

感知——感知模块将该问题分类为 TaskType.CONTRADICTORY，复杂度估计为 0.75。它提取出的实体包括：“部署流水线”、“间歇性故障”、“高流量”以及“超时阈值”。它标记了一个歧义：“间歇性”可能意味着随机发生，也可能意味着与负载相关。“仅在高流量期间发生”这一表述澄清了这一点，但智能体仍然记录了这个注意事项。当前活动信号保持为 NONE。
记忆检索——注意力模块发现任务复杂度较高，因此在进入规划阶段之前，将流程路由到 MEMORY。记忆模块在知识图谱中搜索与“deployment”、“intermittent”和“timeout”匹配的实体。它找到了一条历史实体——connection_pool_exhaustion，其中包含一条观察记录：“在负载情况下导致间歇性故障，表面上类似于超时问题，通过增加 max_connections 得到解决。”这条记忆命中结果会被注入工作空间。
规划——规划模块读取矛盾任务类型，并选择 HYPOTHESIS_TEST 策略。在记忆结果的辅助下，它生成三个假设：(1) 并发负载下的连接池耗尽；(2) 健康检查探针中的竞态条件；(3) 流水线阶段之间的资源竞争。它提出通过搜索有关并发连接限制、健康检查配置以及资源分配的文档来测试每个假设。
执行（第一个假设）——执行模块搜索有关并发连接限制的文档。它找到关于默认连接池大小以及其在负载情况下行为的相关内容。相关性评分：0.8。质量说明：“内容来自官方文档，并且与问题直接相关。”
评估——评估模块进行判断：进展良好；一致性正常（新的证据支持假设 1）；置信度变化值为 +0.15。没有发现矛盾。建议：CONTINUE。工作空间中的置信度从 0.5 提升至 0.65。
执行（第二个假设）——执行模块搜索健康检查中的竞态条件。它找到了一篇关于高负载情况下健康检查时序问题的博客文章。相关性评分：0.5。质量说明：“来源为社区博客，部分相关。”
评估——进展程度中等，假设 2 的证据较弱。置信度变化值为 +0.05。建议：CONTINUE。
最终综合——在测试完所有假设之后，评估模块发出 TASK_COMPLETE 信号。智能体生成响应，说明用户已经尝试过超时修复方案，并将连接池耗尽列为最可能的替代原因（该判断同时得到新检索结果和历史经验的支持）。响应还会针对每个假设提供具体的诊断步骤。
记忆记录——记忆模块创建一个新的实体“intermittent_pipeline_failure_under_load”，并记录关于假设测试结果的观察信息。它创建了一条关系：“intermittent_pipeline_failure_under_load” shares_strategy_with “connection_pool_exhaustion”。

下一次有人询问高负载情况下的间歇性故障时，记忆模块会同时提供这两个实体，规划模块也会以更高的置信度开始分析。

10.3.4 置信度门控执行

置信度门控是最简单且最有用的元认知模式。在向用户展示任何响应之前，智能体会检查自己的置信度是否足以支持输出。这不是一种口头上的检查（例如“我认为……”）。它是一种基于工作空间置信状态的结构化检查，而该状态会在整个认知循环过程中由评估模块持续更新。

代码清单 10.9 10_confidence_gate.py

class GateDecision(str, Enum):
   PRESENT = "present"                #1
   GATHER_MORE = "gather_more"        #2
   SIGNAL_UNCERTAINTY = "signal_uncertainty"  #3

def check_confidence_gate(workspace: CognitiveWorkspace) -> GateDecision:
   # Hard threshold: never present below 0.3
   if workspace.confidence < 0.3:
       return GateDecision.SIGNAL_UNCERTAINTY

   # Soft threshold: try gathering more if between 0.3 and 0.6
   if workspace.confidence < 0.6:
       if workspace.iteration_count < 3:          #4
           return GateDecision.GATHER_MORE
       return GateDecision.SIGNAL_UNCERTAINTY

   # Check for unresolved contradictions
   if workspace.active_signal == AttentionSignal.CONTRADICTION:
       return GateDecision.GATHER_MORE

   # Check confidence trend: declining confidence is a red flag
   if len(workspace.confidence_trend) >= 3:
       recent = workspace.confidence_trend[-3:]
       if all(recent[i] > recent[i+1] for i in range(2)):  #5
           return GateDecision.GATHER_MORE

   return GateDecision.PRESENT

注释:

#1 可以安全地向用户呈现响应
#2 置信度处于临界状态；在做出决定之前先收集更多信息
#3 置信度不足；明确向用户表达不确定性
#4 仅在仍有剩余迭代预算时才继续收集信息。
#5 连续三次置信度下降意味着系统可能出现了问题。

10.3.5 停滞检测与策略转向

停滞检测用于捕获“坏掉的唱片”这一失败模式：智能体虽然在不断迭代，但并没有取得任何进展。最近两次执行步骤的发现结果高度重叠，或者置信度已经停滞不前。如果没有停滞检测机制，智能体会一直运行到达到迭代上限，白白浪费 Token 和时间。

代码清单 10.10 11_stagnation_detector.py

def detect_stagnation(workspace: CognitiveWorkspace) -> bool:
   # Need at least 2 findings to compare
   if len(workspace.findings) < 2:
       return False

   # Check content overlap between last two findings
   last = workspace.findings[-1].content.lower().split()
   prev = workspace.findings[-2].content.lower().split()
   overlap = len(set(last) & set(prev)) / max(len(set(last)), 1)
   if overlap > 0.7:                                #1
       workspace.active_signal = AttentionSignal.STAGNATION
       workspace.signal_source = "content_overlap"
       return True

   # Check confidence plateau
   if len(workspace.confidence_trend) >= 3:
       recent = workspace.confidence_trend[-3:]
       spread = max(recent) - min(recent)
       if spread < 0.05:                            #2
           workspace.active_signal = AttentionSignal.STAGNATION
           workspace.signal_source = "confidence_plateau"
           return True

   return False

注释:

#1 超过 70% 的词语重叠意味着智能体正在重复发现相同的信息。
#2 连续三步中置信度变化小于 0.05，意味着没有取得实质性进展。

当检测到停滞时，注意力模块会将流程路由到 META_PLAN。这是一个重新规划步骤，在这个过程中，规划模块会接收到“之前的方法失败了”这一约束条件，以及工作空间中的 failed_approaches（失败策略列表）。这样可以防止规划器再次提出相同的策略。

10.3.6 知识边界感知

知识边界感知是一种“知道自己不知道什么”的模式。当智能体检测到自己正在超出训练知识范围和检索覆盖范围进行工作时，它会切换到优雅降级模式。这正是解决“过度自信猜测（overcommitted guess）”这一失败模式的方法。

代码清单 10.11 12_boundary_awareness.py

class KnowledgeBoundary(str, Enum):
   WITHIN = "within_knowledge"
   EDGE = "edge_of_knowledge"
   OUTSIDE = "outside_knowledge"

def assess_knowledge_boundary(
   workspace: CognitiveWorkspace
) -> KnowledgeBoundary:
   signals = []

   # Check retrieval quality
   if workspace.findings:
       avg_relevance = sum(
           f.relevance_score for f in workspace.findings
       ) / len(workspace.findings)
       signals.append(avg_relevance)
   else:
       signals.append(0.0)                         #1

   # Check memory coverage
   if workspace.memory_hits:
       signals.append(0.8)                         #2
   else:
       signals.append(0.2)

   # Check confidence state
   signals.append(workspace.confidence)

   avg_signal = sum(signals) / len(signals)

   if avg_signal > 0.6:
       return KnowledgeBoundary.WITHIN
   elif avg_signal > 0.3:
       return KnowledgeBoundary.EDGE
   else:
       workspace.active_signal = AttentionSignal.LOW_CONFIDENCE
       return KnowledgeBoundary.OUTSIDE

注释:

#1 完全没有发现结果，是一个强烈信号，表明我们正处于已知领域之外。
#2 记忆命中表明智能体过去曾处理过相关问题。

元认知是最有价值的生产特性

在生产级智能体系统中，用户可以接受“我不知道”，但无法接受自信却错误的答案。元认知监控决定了一个智能体是能够随着时间建立信任，还是会因为第一次错误回答而灾难性地失去用户信任。

10.3.7 涌现行为

这里描述的四种行为，并没有被明确编写在任何一个单独模块中。它们是专用模块通过共享工作空间以及不断积累的知识图谱相互作用后所产生的结果。这正是 Minsky“心智社会”（Society of Mind）理论在代码中的体现：

好奇心（Curiosity）——当评估模块标记出低置信度，而记忆模块又无法在知识图谱中找到相关实体时，注意力信号 KNOWLEDGE_GAP 会被触发。这会将控制权路由到记忆模块，以扩大搜索范围。如果仍然失败，规划模块会生成探索性子目标，主动收集那些用户没有明确提出的信息。于是，智能体看起来仿佛会对相关问题产生“好奇”，主动引入原始查询中不存在但最终证明与问题相关的上下文信息。
自适应持久性（Adaptive Persistence）——当执行失败且停滞检测被触发时，注意力模块会将流程路由到 META_PLAN，并将失败的策略记录在工作空间中。规划模块会在“不要重复失败方法”这一约束条件下生成替代方案。记忆模块会记录失败的方法，从而避免未来会话再次采用相同策略。智能体看起来仿佛能够在单个任务内部以及跨任务之间“从失败中学习”。
选择性深度（Selective Depth）——感知模块会将简单查询分类为低复杂度，而注意力模块则将其路由到快速路径。如果记忆模块能够为该查询找到高置信度匹配项，智能体将直接基于记忆作出响应，而无需执行任何工具调用。在生产环境测试中，通过快速路径处理的简单查询，其完成速度比完整认知循环快 3 至 5 倍，Token 消耗也减少 3 至 5 倍，同时没有可测量的质量下降。这正是 Kahneman 所说的系统 1：对于熟悉的问题，它快速、自动且高效。
优雅降级（Graceful Degradation）——当认知资源耗尽（接近迭代上限、置信度低于阈值、缺乏相关知识）时，置信度门控机制会阻止智能体将不确定的结果当作事实呈现。相反，智能体会展示它所掌握的部分信息，明确标记存在不确定性的结论，并为用户提供下一步建议。记忆模块还会记录这次知识边界遭遇，因此未来在相同领域的查询会更早触发不确定性信号。智能体会越来越擅长认识自己“不知道什么”。

10.4 衡量认知能力与未来展望

本节并不提供正式的基准测试，而是提供一个实用的诊断框架，你可以将其应用于自己的智能体。每一个测试类别都对应第 10.1.1 节中提到的五种失败模式，并配有具体的测试案例以及通过/失败判定标准，如表 10.2 所示。

表 10.2 使用认知智能体架构评估五种智能体失败模式

测试类别	测试案例	通过标准	失败表现	排查方向
证据评估	提供一个查询，其检索结果返回的是目录（Table of Contents）页面。	智能体能够标记低质量证据，并且不会将元数据内容作为答案引用。	智能体将目录内容直接作为答案。	评估模块（Evaluation Module）的质量评估机制
停滞感知	提供一个无法获得良好搜索结果的查询。	智能体能在三次迭代内切换策略。	智能体重复相同查询三次或以上。	注意力模块（Attention Module）的信号路由
模型更新	提供一个查询，并在对话中途给出与原始前提相矛盾的信息。	智能体能够根据新信息修正计划。	智能体继续执行原始计划。	规划模块（Planning Module）的重新规划机制
知识边界	询问一个工具和记忆中都没有覆盖的主题。	智能体能在两次迭代内表达不确定性。	智能体产生看似合理的幻觉答案。	置信度门控（Confidence Gate）阈值设置
组合推理	提出一个需要调用两个工具并进行结果合并的问题。	智能体能够拆分为两次调用并组合结果。	智能体将其视为单一的平面查询。	感知模块（Perception Module）的复杂度评估

请使用这五项测试来评估你的智能体。如果它在其中超过两项测试中失败，那么认知架构将能够带来可量化的提升。如果它能够通过全部五项测试，你可能并不需要完整的认知架构；上一章介绍的那些单独推理模式可能已经足够。

10.4.1 认知效率指标

在生产环境中，有四个指标值得持续跟踪：

认知效率（Cognitive Efficiency）——衡量智能体完成某一任务类型所使用的步骤数，相对于该任务最优步骤数的比值。如果一个简单查询本应只需两步，却用了六个认知步骤，那么说明注意力模块中的快速路径需要进行调优。
元认知校准（Metacognitive Calibration）——衡量智能体的置信度与实际正确率之间随时间变化的相关性。将置信度绘制在 x 轴，将准确率绘制在 y 轴。一个校准良好的智能体会呈现接近对角线的分布。而一个校准较差的智能体，则会在错误时表现得很自信，或者在正确时表现得不确定。
适应速率（Adaptation Rate）——衡量智能体在初始方法失败后转变策略的速度。统计从检测到停滞到成功完成策略切换之间经历的迭代次数。数值越低越好。
知识边界准确率（Knowledge Boundary Accuracy）——衡量智能体是否能够正确识别自己何时超出了知识覆盖范围。需要跟踪两类错误：假阳性（对简单问题错误地表达不确定性）和假阴性（自信地给出幻觉答案）。

10.4.2 前后对比：衡量认知架构的效果

使用第 10.4.1 节中的诊断测试套件，对两种配置进行测试：标准 ReAct 智能体和认知智能体，并使用完全相同的查询进行比较。衡量指标包括答案正确率、置信度校准情况、优雅降级率（即智能体在应该表达不确定性时实际这样做的频率），以及平均 Token 消耗。

然后进行第二组比较：将知识图谱为空（首次会话）的认知智能体，与同一个智能体在完成 20 个任务后的状态（知识图谱已填充）进行对比。这个实验可以展示经验记录所带来的复利效应。积累了经验的智能体应该表现出更高的置信度校准能力、更快地解决熟悉问题类型的能力，以及更少的停滞事件。

10.4.3 通向更通用智能体的道路

我们在本章构建的认知架构，在一个重要意义上仍然是狭义的：这些模块是针对技术故障排查场景配置的。然而，这个架构本身与具体领域无关。认知工作空间、注意力模块、评估模块以及置信度门控模式，并不关心它们所运行的领域是什么。只需替换感知模块中的任务类型分类、更换执行模块所连接的 MCP 服务器，并更新规划模块中的策略描述。同样的认知基础设施就能够支持一个完全不同的应用领域。

这就是迈向更通用智能体能力的现实路径：不是构建更大的模型，也不是增加更多训练数据，而是构建模块化的认知架构，让推理、监控、记忆和适应成为彼此独立、能够单独优化并自由组合的能力。

ARC-AGI-2 基准测试所考察的，正是这种组合式泛化能力。虽然我们的架构无法通过该测试，但其设计原则指向的是同一个方向：智能来源于能力的组合，而不是任何单一能力的规模扩张。

泛化是架构问题，而不是参数问题

通往更强大智能体的道路，并不仅仅是构建拥有更多参数的更大模型。真正的方向是构建一种模块化认知架构，使推理、监控、记忆和适应成为相互独立的组成部分，能够被分别改进并重新组合。本章介绍的认知智能体架构，正是朝着这一目标迈出的一步。

10.5 练习

练习 1：构建认知工作空间

目标：实现代码清单 10.1 中的 CognitiveWorkspace，并使用示例查询填充其内容。

任务：

创建 exercise1_workspace.py，使用 CognitiveWorkspace Pydantic 模型。
编写一个感知函数，接收原始用户查询，并填充工作空间中的任务表示字段。
使用三种不同复杂度的查询进行测试：一个简单的事实查询、一个多步骤故障排查问题，以及一个包含矛盾信息的场景。
输出每个查询在感知阶段结束后的工作空间状态。观察 task_type 和 complexity_estimate 的差异。

预计耗时：15 分钟

练习 2：实现评估模块

目标：构建元认知评估模块，并使用智能体输出结果进行测试。

任务：

创建 exercise2_evaluation.py，使用代码清单 10.5 中的评估智能体。
向其输入三种工作空间状态：一种包含高质量发现结果，一种包含相互矛盾的发现结果，以及一种包含低置信度结果。
验证评估模块分别返回 CONTINUE、REPLAN 和 ESCALATE。
添加停滞检测：输入两个连续且完全相同的发现结果，并验证其能够标记停滞状态。