在前面的章节中,我们探讨了治理多个智能体如何在一个健壮系统架构中协作的模式。现在,我们将把镜头拉近,聚焦于任何此类生态系统的基本单元:单个自治智能体(individual autonomous agent) 。本章专门讨论定义智能体内部架构、并让其核心组件“运转起来”的 agent-level patterns。
这些模式构成了智能体关键能力的蓝图:它如何感知环境、如何管理记忆、如何组织推理、以及如何对世界采取行动。
掌握这些单体模式,是构建面向企业生产级解决方案所需的复杂协作型多智能体系统的第一步。
为了让这些模式尽可能实用,我们将采用“旅行前先看地图(map before the journey) ”的方法:先从一份战略指南开始,提供一个用于智能体开发的成熟度模型。先理解整体图景,你就能在上下文中理解每个具体模式应放在哪里,以及为什么它对构建不仅强大而且可靠、有明确目的性的智能体至关重要。
在本章中,我们将覆盖以下主题:
- agent-level patterns 的实施战略指南
- Single Agent Baseline
- Agent-Specific Context and Memory
- RAG
- Structured Reasoning and Self-Correction
- Multimodal Sensory Input
- 企业推广(enterprise rollout)指南
- 衡量成功:按模式划分的评估指标(evaluation metrics by pattern)
让我们从战略指南与 Agent Maturity Model 开始。
agent-level patterns 的实施战略指南(Strategic guide to implementing agent-level patterns)
了解单个模式只是第一步。下一步,是以战略方式应用它们,构建既强大又实用的智能体。正确做法是渐进式采用这些能力,按智能体角色不断增长的复杂度与责任范围逐层叠加(layering)。
实现智能体能力所需的组件(Components required to implement agent capabilities)
成熟度模型为智能体开发提供了一条战略路线图:从一个简单的工具使用者(tool user)成长为一个复杂、具备感知能力的专家(perceptive specialist)。通过识别你的智能体所需能力,你可以在恰当时间选择并实现恰当的一组模式。
让我们更深入地看看实现智能体能力所需的组件,如第 1 章引入的“agent anatomy diagram(智能体解剖图)”所示。这些模式描述的是:在该解剖图中,一个单智能体内部各组件之间的交互方式——也就是单个智能体内部组件之间如何相互作用的模式化描述。
Figure 9.1 – The agent anatomy
在第 4 章中,我们用一组动词与动作来定义智能体的解剖结构,例如 Sense、Reason、Plan、Act、以及 Recall(Memory),并将其作为自治系统的基本构件。我们把这些动词比喻为智能体的“器官(organs)”所执行的功能。它们使智能体能够在一个持续的运行闭环中工作。
然而,了解解剖结构只是第一步。要走向生产就绪系统,我们还需要应用特定的 agent-level patterns,将这些组件调整到适配企业数据现实、以及业务流程智能体自动化所需复杂逻辑的形态。下表把我们之前讨论过的解剖组件映射到本章覆盖的设计模式:将关注点从“智能体是什么”转向“智能体的每种能力如何被工程化,以实现可靠性与规模化”。
表 9.1 – 采用 agent-level patterns 的组件与模式对应关系(Components and patterns for adopting agent-level patterns)
| Component | Capabilities | Interaction among components implemented by patterns | Summary |
|---|---|---|---|
| Act and tools | 执行直接命令并使用简单工具 | Single Agent Baseline | 智能体作为基础自动化器运行。它使用 Act 模块执行工作流,并通过 Tools 模块与外部 API 交互。 |
| Memory | 处理多轮对话并记住关键信息 | Agent-Specific Memory | 智能体具备状态性(stateful)。Memory 组件持久化会话历史与用户偏好,以维持上下文。 |
| Memory | 访问并对外部、领域特定数据进行推理 | Context-Aware Retrieval (RAG) | 智能体以事实知识为锚点。Memory 组件被增强以检索外部数据,从而减少幻觉(hallucinations)。 |
| Reason and plan | 透明推理并纠正自身错误 | Structured Reasoning and Self-Correction | 智能体变得可靠。它使用 Reason 组件思考问题,并使用 Plan 组件组织复杂任务。 |
| Sense | 理解并处理来自文档与 UI 的视觉信息 | Multimodal Sensory Input | 智能体作为通往世界的网关运行。Sense 组件在处理前摄取多模态输入(图像、音频等)。 |
Table 9.1 – Components and patterns for adopting agent-level patterns
内部智能体架构:这些模式如何拼在一起(Internal agent architecture: how the patterns fit together)
这些模式不是彼此孤立的特性,而是智能体内部架构中集成的组件。它们增强了智能体的核心认知闭环:Perceive --> Reason --> Act:
-
感知层(Perception layer) :这是智能体通往世界的入口。它处理原始输入,并为推理引擎做好准备。
- 启用模式(Pattern enabled) :Multimodal Sensory Input 使该层不仅能处理文本,还能处理图像、声音以及其他数据格式。
-
记忆与知识层(Memory and knowledge layer) :该层提供智能体有效推理所需的上下文。它不属于核心闭环的一部分,但作为认知层的关键资源存在。
- 启用模式(Patterns enabled) :Agent-Specific Memory 提供会话历史与用户偏好;RAG retriever 在需要时按需获取外部知识。
-
认知与推理层(Cognition and reasoning layer) :这是智能体的“大脑(brain)”,由 LLM 驱动。它负责规划、决策并形成回应。
- 启用模式(Patterns enabled) :Structured Reasoning and Self-Correction 在此运行,确保智能体思维过程健壮、透明,并与目标对齐。
-
行动层(Action layer) :该层执行认知层做出的决策,是智能体与环境交互的地方。
- 启用模式(Pattern enabled) :Single Agent Baseline 定义了智能体在该层使用工具(API 与函数)以产生实际改变的核心能力。
现在,让我们按照前述成熟度模型表格中的描述,逐一深入每一个模式的细节。请注意:为了从一个成熟度等级进入下一个等级,你需要考虑实现下一等级对应的模式。这样,你就能得到一条非常清晰的路径:从当前所处位置走向目标状态——从企业在 agentic AI 上的复杂度、能力、采纳程度(adoption)与成熟度层级的角度来看亦是如此。
Single Agent Baseline
在深入更复杂的模式之前,我们先建立一个基线。Single Agent Baseline 模式代表智能体系统最简单的形态:由单个智能体负责处理完整工作流,并通过访问多种工具来完成任务。它是大多数 agentic 实现的起点,也可作为衡量更高级架构的基准(benchmark)。
背景(Context)
该模式适用于:任务复杂到需要使用工具,但又不需要多智能体协作所带来的额外开销(overhead)。它是构建面向任务的 agentic 系统最常见的起点。
问题(Problem)
如何组织一个基础但可用的智能体,使其能够执行一系列半自治(semi-autonomous)的动作来达成目标?
解决方案(Solution)
解决方案是创建一个由 LLM 驱动的单一智能体。为该智能体提供一组工具(函数或 API)以及通过指令 prompt 描述的目标。借助诸如 ReAct(Reason-Act)或更复杂的 Fractal Chain of Thought(FCoT)等推理框架,智能体的 LLM 内核会独立决定:调用哪些工具、以什么顺序调用、以及使用什么参数来收集信息并完成任务。整个思考过程(即 reasoning)与执行逻辑(即 planning)都封装在这一个智能体内部。
下图展示了该架构。Figure 9.2 展示总体的高层模式,而 Figure 9.3 则给出该智能体处理具体任务时更明确的工作流。
Figure 9.2 – The Single Agent Baseline pattern
既然我们已经看到高层架构,下面通过一个具体示例来走一遍该模式的实现方式。
示例:一个简单的贷款审批智能体(Example: A simple loan approval agent)
一家银行希望自动化贷款申请的初步审查。该任务交由 SingleLoanAgent 处理:
- Agent's goal:基于信用评分阈值 680,决定贷款申请应被批准还是拒绝
- Available tool:
get_credit_score工具,可根据申请人 ID 获取信用评分
智能体的执行流程如下:
- Receive task:智能体收到目标:处理
applicant_id: 'john_doe_123'且loan_amount: 50000的贷款申请。 - Reasoning:智能体的 LLM 判断:要评估贷款,首先需要申请人的信用评分。
- Tool selection and execution:它识别
get_credit_score是正确工具,并以applicant_id='john_doe_123'调用该工具。 - Observation:工具执行并返回 720。
- Final reasoning and action:智能体拥有所需信息后,将评分(720)与阈值(680)比较。由于评分足够,它得出最终动作应为批准贷款。
- Response:智能体返回最终答案:Approved。
Figure 9.3 – Single Agent loan agent workflow
示例实现(Example implementation)
下面给出一个单智能体处理贷款申请的简化实现。为便于理解,LLM 的推理与决策步骤用模拟方式呈现:
# A mock tool for the agent to use
def get_credit_score(applicant_id: str) -> int:
"""Retrieves the credit score for a given applicant ID."""
print(f"TOOL CALLED: Getting credit score for {applicant_id}...")
# In a real system, this would call an external API
if applicant_id == "john_doe_123":
return 720
return 640
class SingleLoanAgent:
def __init__(self):
# The agent has a dictionary of available tools
self.tools = {"get_credit_score": get_credit_score}
def process_application(self, applicant_id: str, loan_amount: int):
"""Processes a loan application for a given applicant."""
print(f"\nAGENT: Received task for applicant {applicant_id}.")
# 1> Agent reasons it needs the credit score and calls the tool
credit_score = self.tools["get_credit_score"](applicant_id)
print(f"AGENT: Observed credit score is {credit_score}.")
# 2> Agent reasons about the final decision based on the tool's output
# In a real system, this would be a second LLM call
prompt = f"""
Evaluate the following loan application.
Applicant ID: {applicant_id}
Credit Score: {credit_score}
Loan Amount: ${loan_amount}
Based on a credit score threshold of 680, should this loan be 'Approved' or 'Denied'?
"""
# Simulate the LLM making a decision based on the tool's output
response = "Approved" if credit_score >= 680 else "Denied"
print(f"AGENT DECISION: The loan for {applicant_id} is {response}.")
return response
# --- Execute the Workflow ---
loan_agent = SingleLoanAgent()
loan_agent.process_application(applicant_id="john_doe_123", loan_amount=50000)
后果(Consequences)
优点(Pro):
- 简单性(Simplicity) :主要优势是实现与调试都更简单。相比多智能体系统,单智能体的行为与状态更容易管理与观测。
缺点(Con):
- 可扩展性(Scalability) :随着工具数量或领域复杂度增加,这种架构的扩展性较差。单一智能体可能被过载,其 prompt 也会变得过于复杂、难以有效管理,从而导致性能下降,并提高出错概率。
实施建议(Implementation guidance)
Single Agent Baseline 提供了一个完整、封闭的执行闭环,使智能体能够通过 function calling 使用工具来实现特定目标。然而,这个简单智能体是无状态(stateless) 的:它不记得过去的交互,并把每个新任务都当作第一次处理。要创造更智能、个性化的体验,智能体必须能够以某种可访问的共享记忆记住先前发生过的事情。
下一个模式 Agent-Specific Context and Memory 正是为满足这一基础需求。它为智能体配备自己的状态管理系统,使其能够随时间推移对任务与环境保持连贯理解。
Agent-Specific Context and Memory
要让智能体以智能方式行动,它必须了解自身所处的上下文(感知当前环境)并记住在该环境中的过往交互。Agent-Specific Context and Memory 模式解决的是:智能体需要维护并利用其自身专属的上下文信息来指导决策过程的需求。这既包括它最初的指令/目标,也包括它的编排链路(chain of orchestration):也就是说,如果它有一个父级 AI orchestrator,那么它需要知道从父级下发给它的指令是什么;否则,它将依赖直接给到它的指令与目标。该模式将智能体从一个简单的命令执行器提升为具备状态的实体(stateful entity),能够学习并适应。
背景(Context)
对于任何需要执行超越简单“一次性(one-shot)命令”的智能体而言,这一模式都至关重要。它是对话型智能体、长时任务自动化、以及任何“过去事件会影响未来行动”的系统的基础。
问题(Problem)
智能体如何在时间维度上维持对其任务与上下文环境的连贯理解,尤其是在多轮交互(multi-turn interactions)中?
解决方案(Solution)
解决方案是为每个智能体配备自己的记忆或状态管理系统。这使得智能体能够构建对其上下文的持久理解,并与它当下接收到的即时指令相分离。这类记忆通常被分为两种:
- [State management] 短期记忆(Short-term memory) :通常在 LLM 的上下文窗口内管理,用于保存当前任务或对话的即时历史。常用技术包括对话摘要(summarization)或最近消息的滑动窗口(sliding window),以保持上下文相关且简洁。
- 长期记忆(Long-term memory) :更持久的存储机制,例如向量数据库或 key-value store。智能体可在其中存储并检索关键事实、用户偏好、以及过去的结论,以便在未来会话中使用。Retrieval-augmented generation(RAG)是访问这类记忆的常见模式。
注意(Note)
仅仅把完整对话历史直接塞进 LLM 的上下文窗口,往往适得其反。研究表明,模型倾向于遗忘长上下文中“lost in the middle”的信息,并可能被无关噪声分散注意力。有效的记忆管理是必不可少的。
示例:一个有状态的对话式贷款智能体(Example: A stateful conversational loan agent)
用户与一个对话式智能体交互以启动贷款申请。智能体使用记忆来维持连贯对话:
- Agent goal:在多轮交互中引导用户完成贷款申请,并记住对话上下文
有状态交互按如下方式展开:
- Turn 1(user) :我需要申请一笔房贷。
- Turn 1(agent) :智能体回复:我可以帮你处理。申请人的 ID 是什么?随后它更新短期记忆摘要为:用户在咨询房贷。
- Turn 2(user) :我的 ID 是 ‘jane_doe_456’。
- Turn 2(agent) :智能体收到新消息后,将记忆摘要与新消息结合,形成完整图景。它理解 ‘jane_doe_456’ 是本次房贷咨询的申请人 ID。它回复:谢谢。Jane Doe 的贷款金额是多少?并再次更新记忆。
由于具备记忆,智能体避免重复提问,并保持自然、合乎逻辑的对话流。
Figure 9.4 – Agent-specific memory
示例实现(Example implementation)
该示例展示一种用于管理短期记忆的简单摘要方法:
class ConversationalLoanAgent:
def __init__(self):
self.conversation_history = []
self.memory_summary = "No prior conversation."
def _update_memory(self):
"""Summarizes the conversation to manage context size."""
# In a real implementation, this would be an LLM call to summarize.
if len(self.conversation_history) > 1:
last_exchange = (
f"User: '{self.conversation_history[-2]['content']}', "
f"Agent: '{self.conversation_history[-1]['content']}'"
)
self.memory_summary = (
"The conversation is about a loan application. "
f"The last topic was: {last_exchange}"
)
print(f"MEMORY UPDATED: {self.memory_summary}")
def handle_message(self, user_message: str):
"""Handles a new message from the user in a conversation."""
self.conversation_history.append(
{"role": "user", "content": user_message}
)
# The agent's prompt includes the memory summary for context
prompt = f"""
Conversation Summary: {self.memory_summary}
Latest User Message: "{user_message}"
Respond to the user's latest message in a helpful manner.
"""
# Simulate LLM response based on the full context
# response = self.llm.generate(prompt)
if "loan" in user_message:
response = "I can help with that. What is the applicant's ID?"
else:
response = "Thank you. What is the loan amount?"
self.conversation_history.append(
{"role": "agent", "content": response}
)
self._update_memory()
return response
# --- Execute the Workflow ---
agent = ConversationalLoanAgent()
print("--- Turn 1 ---")
agent.handle_message("I need to apply for a home loan.")
print("\n--- Turn 2 ---")
agent.handle_message("My ID is 'jane_doe_456'.")
后果(Consequences)
优点(Pro):
- 有状态行为与个性化(Stateful behavior and personalization) :该模式使连贯的、有状态行为成为可能。它让智能体能够从经验中学习、记住用户偏好,并随时间调整自身行动。
缺点(Con):
- 复杂性与上下文漂移(Complexity and contextual drift) :实现健壮的记忆系统会增加复杂度。记忆管理不当会导致智能体回忆过时或无关信息,这种现象称为上下文漂移(contextual drift),会降低性能。
实施建议(Implementation guidance)
对于短期记忆,可从简单策略起步,例如保留最近 N 轮对话的“滑动窗口(sliding window)”,或像示例中那样使用摘要。对于长期记忆,将 RAG 系统连接到向量数据库是标准做法。要谨慎选择写入长期记忆的信息:聚焦于高价值数据(如用户画像、关键决策、已定事实),避免把噪声污染进记忆。
为智能体提供通用或共享记忆,使其能够维持对任务或对话的连贯内部模型。然而,要把推理锚定在外部、事实性知识上,还需要一种更专门的机制,以便按需访问特定信息。
下一个模式 RAG 正是提供这一能力:它允许智能体查询海量知识库以找到相关信息并增强响应,从而显著降低幻觉(hallucination)风险。
Sensing with RAG
尽管智能体的一般记忆能够提供对话上下文,但 RAG 模式提供了将其推理锚定在外部、事实性知识上的具体机制。它是提升智能体性能、减少幻觉(hallucinations)、并将其连接到专有或实时信息的最有效、也最广泛采用的模式之一。
背景(Context)
当智能体的任务需要超出 LLM 静态、预训练知识范围的事实准确性时,该模式至关重要。它广泛用于客服支持、研究、法律分析,以及任何必须基于特定文档体系做出决策的领域。
问题(Problem)
LLM 预训练于海量但静态的数据集,这意味着其知识可能过时,或缺乏企业特定上下文。如何让智能体在不进行昂贵再训练(retraining)的情况下,访问并推理最新的、专有的或领域特定的信息?
解决方案(Solution)
RAG 模式实现了一条将智能体连接到一个或多个外部知识源的流水线:在 LLM 生成响应之前,先检索相关事实并用它们增强 prompt。该过程包括:
- Indexing(索引) :清洗企业文档,将其切分为可管理的 chunks,并转换为向量 embedding,随后存入向量数据库。
- Retrieval(检索) :当智能体收到查询时,系统基于语义相似度从向量数据库中检索最相关的文档 chunks。
- Augmentation(增强) :将检索到的 chunks 作为额外上下文插入到智能体的 prompt 中。
- Generation(生成) :LLM 使用增强后的上下文生成响应,使其基于所提供的信息而“有据可依”。
提示(Tip)
RAG 的复杂度可以不同。简单 RAG 是直接的 “retrieve-and-generate” 工作流;而 agentic RAG 会引入专门智能体执行诸如查询重写(query reformulation)或迭代检索(iterative retrieval)等任务,以改进结果。
示例:启用 RAG 的贷款智能体(Example: A RAG-enabled loan agent)
SingleLoanAgent 需要基于最新、最复杂的内部放贷政策做出决策:
- Agent goal:通过查阅当前最新的内部政策文档来评估一笔高额贷款申请
- Knowledge source:一个包含该银行全部放贷政策的向量数据库
RAG 增强的工作流如下:
- Receive task:智能体收到一笔 $750,000 的贷款申请。
- Retrieval:在做决定之前,智能体调用其
RAGRetriever工具,查询:policy for high-value loan。检索器对向量数据库执行语义搜索,找到一个文档片段写道:
“Policy #23B: Loans over $500,000 require a credit score of 740 and a manual review.” - Augmentation:智能体的推理 prompt 被该政策内容增强。
- Grounded reasoning:智能体的 LLM 结合新上下文进行推理:它看到申请人的 720 分低于这类金额贷款所需的 740。
- Grounded response:智能体返回一个明确基于检索政策的决策:
“Denied due to insufficient credit score as per Policy #23B for high-value loans.”
Figure 9.5 – Context-aware retrieval (RAG) agent
示例实现(Example implementation)
该示例模拟一个 RAG 系统:智能体通过检索相关政策文档来做出更细致(nuanced)的决策:
# --- RAG Components Simulation ---
class RAGRetriever:
def __init__(self):
# In a real system, this connects to a vector database
self.knowledge_base = {
"high_value_loan": "Policy #23B: Loans over $500,000 require a credit score of 740.",
"standard_loan": "Policy #17A: Standard loans require a credit score of 680."
}
def retrieve(self, query: str) -> str:
"""Retrieves a relevant document based on the query."""
if (
"high value" in query.lower()
or "500000" in query
or "750000" in query
):
return self.knowledge_base["high_value_loan"]
return self.knowledge_base["standard_loan"]
# --- RAG-Enabled Agent ---
class RAGEnabledLoanAgent:
def __init__(self):
self.retriever = RAGRetriever()
# self.tools = {"get_credit_score": get_credit_score} from previous pattern
def process_application(self, applicant_id: str, loan_amount: int):
# credit_score = self.tools["get_credit_score"](applicant_id)
credit_score = 720 # Simulating tool call for this example
# 1> Retrieve relevant context before reasoning
retrieved_context = self.retriever.retrieve(
f"policy for loan of ${loan_amount}"
)
print(f"CONTEXT RETRIEVED: {retrieved_context}")
# 2> Augment the prompt with the retrieved context
prompt = f"""
CONTEXT: {retrieved_context}
TASK: Evaluate the loan for {applicant_id}
with a score of {credit_score} and amount of ${loan_amount}.
State your reasoning based on the provided context.
"""
# 3> Simulate the LLM's grounded reasoning
# response = self.llm.generate(prompt)
if loan_amount > 500000 and credit_score < 740:
response = (
"Denied due to high loan amount and insufficient "
"credit score as per Policy 23B."
)
elif credit_score < 680:
response = (
"Denied due to credit score below the threshold "
"in Policy 17A."
)
else:
response = "Approved."
print(f"AGENT DECISION: {response}")
return response
# --- Execute Workflow ---
rag_agent = RAGEnabledLoanAgent()
rag_agent.process_application(
applicant_id="jane_doe_456",
loan_amount=750000
)
后果(Consequences)
优点(Pros):
- 准确性与信任(Accuracy and trust) :RAG 通过将回答锚定在事实数据上,大幅减少幻觉并提升响应准确性,从而建立用户对系统输出的信任。
- 知识新鲜度(Knowledge freshness) :只需更新知识源即可实时更新智能体知识,无需再训练 LLM。
缺点(Cons):
- 依赖检索质量(Dependency on retrieval quality) :RAG 系统的表现高度依赖索引数据质量与检索机制有效性。如果检索器拉取了无关上下文,可能会让 LLM 困惑并降低响应质量。
- 上下文漂移(Contextual drift) :可能出现所谓 RAG drift:索引知识本身变得陈旧或过时,导致系统性能随时间衰减。
实施建议(Implementation guidance)
检索质量至关重要。投入构建健壮的文档处理流水线:有效清洗与切分源数据。embedding 模型与向量数据库的选择应贴合你的具体领域。面对复杂查询,可考虑实现 agentic RAG:由专门智能体改写用户初始查询、执行迭代搜索,并综合多份检索文档的结果,为 LLM 提供尽可能好的上下文。
RAG 模式为智能体提供了有效推理所需的外部知识。然而,仅仅拥有正确信息还不够;智能体还必须具备一个健壮的内部过程,能够围绕这些信息进行思考,从而得出可靠结论。
下一组模式聚焦于 Structured Reasoning and Self-Correction,提供引导智能体思维过程的技术,使其更合逻辑、更透明,并与目标更一致。
Structured Reasoning and Self-Correction
智能体的推理能力是其自治性的核心。本组模式聚焦于结构化智能体的内部思维过程,以提升推理质量并启用自我纠错,从而超越简单的单步决策(single-step decision-making)。
背景(Context)
当智能体结论的可靠性(reliability)与可解释性(explainability)至关重要时,会使用这组模式。它们在复杂、多步骤任务中尤其有价值,因为此类任务中智能体误读指令或遗漏关键约束的风险很高。
问题(Problem)
如何确保智能体的推理过程合乎逻辑、透明,并与其核心指令对齐,尤其是在复杂、多步骤任务中?
解决方案(Solution)
解决方案是实现高级 prompting 技术与内部验证闭环(internal validation loops),以引导 LLM 的推理过程并鼓励其复核自身工作。这些技术通常会被组合使用:
- Persistent Instruction Anchoring(来自第 6 章) :将关键指令或目标用显著标签(例如
#OBJECTIVE:)嵌入 prompt,并通过重复或放置在上下文开头与结尾来对抗 “lost in the middle” 问题。 - Instruction Fidelity Auditing(Self-Correction)(来自第 6 章) :将智能体设计为在最终输出前对自身结果进行自检。这是一个多步骤过程:首先生成初稿响应;随后运行 “critique” 步骤,将输出与原始指令与上下文进行对照评估。
- Chain-of-Thought(CoT)及其 “vanilla” 变体:不要求立刻给出答案,而是提示智能体 “think step by step”。这迫使 LLM 外化其推理过程,往往能得到更准确结果,并为其逻辑提供清晰的可审计轨迹(audit trail)。其变体包括 Graph of thought、Tree of thought 等。
- Fractal Chain-of-Thought(FCoT) :通过逐步细化的 Context Aperture,我们从宏观(macro)到中观(meso),再到微观(micro)在不同粒度层级上“放大/缩小”。在每个层级,我们定义并应用双重目标函数:一个用于最大化、另一个用于最小化我们希望沿着其进行 hill-climbing 的某个因子。在每次迭代/循环中,我们自我反思并纠正上一轮推理中遗漏的内容。
Figure 9.6 – A self-correction loop, where an agent generates a preliminary output and then critiques it against its goals, leading to a more reliable final result
示例:一个自我纠错的贷款智能体(Example: A self-correcting loan agent)
RAGEnabledLoanAgent 使用自我纠错闭环,以确保其决策完全符合通过 RAG 检索到的复杂政策:
- Agent goal:评估一笔高额贷款,并给出能够正确且完整应用相关内部政策的决策
- Retrieved context:智能体检索到
Policy #23B: Loans over $500,000 require a credit score of 740 and a manual review.
自我纠错工作流如下:
- Initial reasoning(CoT) :智能体收到一笔 $750,000 贷款申请,信用分 720。它用 CoT 生成初步决策:
Step 1:该贷款为高额贷款。
Step 2:适用 Policy #23B。
Step 3:720 低于 740。
Preliminary Decision:Denied。 - Self-critique:在返回答案前,智能体内部审计器被提示对初步决策进行复核,对照检索到的上下文,重点寻找遗漏细节。
- Correction identified:批评步骤识别到一个问题:
Critique:拒绝的结论是正确的,但推理不完整。Policy #23B 还提到申请可进入 “manual review”。该选项应包含在最终答案中。 - Final, corrected output:智能体吸收 critique 后生成更完整、更准确的最终决策:
FINAL DECISION: Denied for automatic approval based on Policy #23B. However, the application is eligible for a manual review.
示例实现(Example implementation)
以下实现演示一个使用 critique loop 的 SelfCorrectingAgent。它不会直接返回第一个结果,而是被编排为暂停、对照检索到的政策约束复核初稿输出,并在必要时生成纠正后的最终响应:
class SelfCorrectingAgent:
def __init__(self):
# self.tools = {"get_credit_score": get_credit_score} from previous pattern
# self.retriever = RAGRetriever() from previous pattern
pass
def process_with_self_correction(self, applicant_id: str, loan_amount: int):
# credit_score = self.tools["get_credit_score"](applicant_id)
# context = self.retriever.retrieve(f"policy for ${loan_amount}")
credit_score = 720
context = (
"Policy 23B: Loans over $500,000 require a credit score "
"of 740 and a manual review."
)
# 1> Generate a preliminary decision using CoT and Anchoring
preliminary_prompt = f"""
OBJECTIVE: Provide an initial loan decision based on the context.
CONTEXT: {context}
DATA: Applicant {applicant_id} has score {credit_score},
wants ${loan_amount}.
Think step-by-step and provide a preliminary decision.
"""
# Simulate LLM generating the first draft
preliminary_decision = (
f"Step 1: Loan is ${loan_amount}, which is high-value. "
f"Step 2: Policy 23B applies. "
f"Step 3: Score is {credit_score}, which is less than 740. "
f"Step 4: PRELIMINARY DECISION: Denied."
)
print(f"PRELIMINARY REASONING: {preliminary_decision}")
# 2> Generate a critique of the preliminary decision
critique_prompt = f"""
OBJECTIVE: You are an auditor. Verify if the preliminary decision
correctly follows all rules in the context.
CONTEXT: {context}
PRELIMINARY DECISION: {preliminary_decision}
Does the decision correctly apply the policy?
Is there anything missed? For example, does the policy mention
a manual review?
"""
# Simulate LLM generating the critique
critique = (
"Critique: The decision to deny is correct, but Policy 23B "
"also mentions a 'manual review' as an option. "
"The reasoning should include this."
)
print(f"SELF-CRITIQUE: {critique}")
# 3> Generate a final, corrected decision
# final_prompt = f"..."
final_decision = (
"FINAL DECISION: Denied for automatic approval based on Policy 23B. "
"However, the application is eligible for a manual review."
)
print(f"FINAL AGENT DECISION: {final_decision}")
return final_decision
# --- Execute Workflow ---
self_correcting_agent = SelfCorrectingAgent()
self_correcting_agent.process_with_self_correction(
"jane_doe_456",
750000
)
后果(Consequences)
优点(Pro):
- 可靠性与透明性(Reliability and transparency) :这些模式会带来更健壮、更可靠、更透明的推理过程。外化的思考过程使开发者更容易调试智能体行为,也让审计人员更容易理解某个决策为何被做出。
缺点(Con):
- 延迟与成本(Latency and cost) :这些技术会因额外推理或验证步骤而增加延迟与计算成本。例如,一个自我纠错闭环至少需要两次独立的 LLM 调用,而不是一次。
实施建议(Implementation guidance)
为了获得最大效果,应将这些模式组合使用。对所有复杂 prompt,都使用 Persistent Instruction Anchoring 来让智能体保持在任务轨道上。初次推理阶段使用 Chain-of-Thought 生成透明、逐步的分析。最后,对于高风险(high-stakes)决策,加入 Self-Correction loop:用第二个 prompt 明确要求 LLM 扮演 critique 或 auditor 的角色,对照原始上下文与约束复核初次 CoT 推理。
结构化推理模式为智能体提供了健壮的内部思维过程。然而,现实世界中大量数据并非文本形态。要真正有效,智能体还必须能够感知并理解视觉信息,例如文档、图表与用户界面。下一个模式 Multimodal Sensory Input 赋予智能体这一关键能力,使其能够像人类一样“看见”并解读世界。
Multimodal Sensory Input
要在依赖视觉文档与用户界面的工作流中高效运作,智能体必须能处理的不仅仅是文本。Multimodal Sensory Input 模式将智能体的感知范围扩展到语言之外,使其能够将图像、截图与视觉数据作为推理过程的一部分进行解读。这使智能体从一个简单聊天机器人,进化为能够以视觉方式理解其环境的真正 co-pilot。
背景(Context)
该模式对文档密集型行业的智能体至关重要,例如金融(处理发票)、医疗(分析医疗表单)、物流(读取运输标签)。当企业要求智能体在工作流中解读截图、发票或商品图片时,它尤其相关。
问题(Problem)
智能体如何在依赖视觉文档与用户界面的工作流中有效运作?
解决方案(Solution)
解决方案是将多模态能力集成到智能体的感知组件(perception component)中。这使智能体能够处理图像、通过光学字符识别(OCR)提取文字,并理解空间布局以执行动作。实现上主要有两种路径,在“可控性”与“简洁性”之间形成权衡:
- 实现由专用工具组成的流水线(pipeline of specialized tools) :该方法使用一系列单一用途模型或服务。智能体先将图片发送给专用工具(例如 OCR 服务)提取文字,再把提取文本交给另一个 LLM 进行推理。这种方式对流程各步骤提供更强的控制力。
- 采用原生多模态模型(native multimodal model) :更先进的方法是使用本身就是多模态的单一基础模型,例如 Google 的 Gemini 系列。这类模型被训练为可同时处理图像、文本、音频与视频输入。智能体可将图片与文本 prompt 直接喂给模型,由模型在一步内同时完成视觉解析与推理。
上述两种路径描述了智能体如何处理感知数据。但一个相关挑战是:智能体如何从其环境中安全、可靠地获取这些数据。随着智能体不仅感知数字环境,也感知物理世界,这一点尤其关键。为治理这种信息交换,正在形成标准化协议:
- Model Context Protocol (MCP) :MCP 为智能体提供一种标准化且安全的方式,在其组织内部发现并与工具交互。它是构建单个智能体的基础构件,使智能体能够安全获取资源(例如来自 IoT 设备)或上下文信息,作为其推理过程的输入。
- Agent-to-Agent (A2A) protocol:A2A 协议面向智能体之间的通信,常跨越组织边界。它是构建复杂工作流或多智能体 orchestrator 的基础构件,使不同智能体(例如你公司与合作伙伴公司的智能体)能够安全通信以达成共同目标,并处理授权与认证等需求(例如 OAuth)。
示例:从图像中处理贷款申请(Example: Processing a loan application from an image)
一个贷款智能体需要处理一份以扫描图片形式提交的申请:
- Agent goal:从贷款申请图片中提取关键信息并做出初步决策
流水线方法(Pipeline approach)
- Perception:智能体收到申请表图片。
- Tool use (OCR) :它将图片发送给专用
ocr_service工具。 - Observation:工具返回提取文本:
Applicant: John Doe, Loan Amount: $600,000. - Reasoning:智能体将该提取文本传入其 LLM 核心进行最终推理与决策。
Figure 9.7 – Multimodal processing via multimodal pipeline
原生多模态方法(Native multimodal approach)
- Perception:智能体收到图片与一个文本 prompt:
Analyze this loan application form image and provide a decision. - Reasoning:它将图片与文本一并发送给原生多模态 LLM。该单模型一步完成 OCR 与决策,返回完整分析结果。
Figure 9.8 – Native multimodal LLM multimodal processing
示例实现(Example implementation)
下面的代码对比两种实现策略。首先 PipelineMultimodalAgent 展示基于工具的方式:由专用 OCR 服务提取文本,然后将其传给 LLM。其次 NativeMultimodalAgent 展示更精简的方式:将图片直接传给多模态模型以同时完成分析与推理:
# --- Implementation 1: Pipeline of Specialized Tools ---
def ocr_service(image_bytes: bytes) -> str:
"""Mock OCR service that extracts text from an image."""
# In a real system, a call to a service like Google Cloud Document AI would be made
print("TOOL CALLED: OCR Service")
return "Applicant: John Doe, ID: john_doe_123, Loan Amount: $600,000"
class PipelineMultimodalAgent:
def process_application_from_image(self, image_file: bytes):
"""Processes a loan application submitted as an image using a pipeline."""
print("\n--- AGENT PERCEPTION (Pipeline) ---")
# Step 1: Use an external tool for OCR
extracted_text = ocr_service(image_file)
print(f"OCR EXTRACTION: '{extracted_text}'")
# Step 2: Use an LLM to reason over the extracted text
print("AGENT REASONING: Sending extracted text to LLM for decision.")
# ... additional agent logic here ...
return "Decision based on pipeline processing."
# --- Implementation 2: Native Multimodal Model ---
# Placeholder for a native multimodal LLM
class NativeMultimodalLLM:
def generate_content(self, text_prompt: str, image_file: bytes) -> str:
"""Simulates a native multimodal model call."""
print("MODEL: Receiving image and text simultaneously...")
return (
"Interpreting image data... Extracted text: "
"'Applicant: John Doe, ID: john_doe_123, Loan Amount: $600,000'. "
"Final analysis: Approved."
)
class NativeMultimodalAgent:
def __init__(self):
self.llm = NativeMultimodalLLM()
def process_application_from_image(self, image_file: bytes):
"""Processes a loan application with a native multimodal model."""
print("\n--- AGENT PERCEPTION (Native Multimodal) ---")
prompt = "Analyze this loan application form image and provide a decision."
response = self.llm.generate_content(
text_prompt=prompt,
image_file=image_file
)
print(f"MODEL RESPONSE: '{response}'")
# ... additional agent logic to parse response and act ...
return "Decision based on native multimodal processing."
# --- Execute Workflows ---
dummy_image = b"some_image_bytes"
pipeline_agent = PipelineMultimodalAgent()
pipeline_agent.process_application_from_image(dummy_image)
native_agent = NativeMultimodalAgent()
native_agent.process_application_from_image(dummy_image)
后果(Consequences)
优点(Pro):
- 用例扩展(Expanded use cases) :该模式显著扩展智能体的适用场景,使其从语言工具升级为能够与人类使用同一界面交互的数字助理。例如,多模态智能体可以通过解读审批流程中的图片来缩短理赔处理时间。
缺点(Con):
- 成本与延迟(Cost and latency) :多模态模型计算开销更高,延迟也可能更高。它们通常需要专门基础设施(如 GPU),并且相较于纯文本模型,需要不同的测试与验证方法。
实施建议(Implementation guidance)
根据你的具体需求选择路径。流水线方法往往是良好的起点:它允许你使用业界最优的专用服务(例如高精度 OCR 工具),并对每一步提供更强的控制与可观测性(observability)。原生多模态模型方法更易编排,也可能在需要对图像与文本进行深度整体理解的任务上更强大,但可能提供更少的细粒度控制。
我们已探讨的模式定义了智能体内部认知闭环(cognitive loop)的 what 与 how,但企业面临的挑战在于确定 when:从理论蓝图过渡到线上生产环境,需要一个在雄心与可靠性之间取得平衡的战术序列。在下一节中,我们将把这些模式转化为分阶段路线图(phased roadmap),确保每项能力都叠加在“信任与可衡量成功”的稳定基础之上。
Guidance for enterprise rollout
与 Maturity Model 对齐的分阶段实施,是部署一个有能力智能体的最有效方法。这样做能让团队先建立信任与可靠性的基础,并随着系统规模扩大再逐层叠加更高级的能力。
| Phase | Patterns to implement | Rationale |
|---|---|---|
| Phase 1: Foundational automation | Single Agent Baseline, Agent-Specific Memory | 从一个简单、事务型(transactional)的智能体开始,聚焦高频、低风险任务(例如内部 IT 帮助台机器人)。这能快速证明价值并建立核心基础设施。 |
| Phase 2: Building expertise | Context-Aware Retrieval (RAG) | 通过连接知识库(例如技术文档)来增强智能体,使其成为可信的信息来源(trusted source of information)。 |
| Phase 3: High-trust autonomy | Structured Reasoning, Multimodal Input | 面向关键流程,引入自我纠错以提升可靠性,并加入视觉能力以处理真实世界的视觉数据。这将支持高风险工作流,例如金融智能体:处理扫描发票,并在审批前对自身工作进行自审(self-audit)。 |
Table 9.2 – Example rollout sequence for agent capabilities
Measuring success: evaluation metrics by pattern
为了证明架构选择的合理性,必须量化每个模式所带来的价值。定义清晰的指标可以让你跟踪效果并推动持续改进。
| Pattern | Metric | Instrumentation |
|---|---|---|
| Single Agent Baseline | Task completion rate / tool call success rate | 记录每个任务的最终结果(成功/失败)。监控日志中失败或错误的工具 API 调用。 |
| Agent-Specific Memory | Session coherence score / reduction in repeated questions | 使用人工评审对对话质量打分。跟踪用户需要重复提供“智能体本应记住的信息”的频率。 |
| Context-Aware Retrieval (RAG) | Hallucination rate / factual accuracy score | 将回答与黄金数据集(golden dataset)对照评估,衡量捏造信息出现的频率。 |
| Structured Reasoning | Self-correction trigger rate / reduction in final errors | 跟踪 critique 步骤识别缺陷的频率。对比初稿输出与最终输出的错误率。 |
| Multimodal Sensory Input | Data extraction accuracy / success on visual tasks | 将 OCR 或字段抽取准确率与 ground-truth 数据对齐评估。对需要图像输入的工作流,跟踪任务完成情况。 |
Table 9.3 – Sample metrics for evaluating agent-level patterns
Summary
本章探讨了定义单个自治智能体能力的关键模式。我们确立了:构建强大智能体是一个渐进过程——从简单基线出发,逐步叠加更复杂的行为,包括记忆、知识检索、推理与感知。
关键结论如下:
- Agents are built, not summoned:有能力的智能体来自有意为之的架构选择。本章讨论的模式为这些选择提供了蓝图。
- Start simple, scale intelligently:走向成熟智能体的战略路径,应从 Single Agent Baseline 起步,并在智能体责任增长时逐层叠加 Memory、RAG、Structured Reasoning 等模式。
- Grounding and reliability are paramount:在企业场景中要让智能体被信任,它必须基于事实(RAG),并且其推理过程必须健壮且透明(Self-Correction)。
- Perception is the next frontier:通过 Multimodal Sensory Input 处理视觉信息的能力,使智能体从文本处理器跃迁为能在以人为中心的工作流中运作的真正 co-pilot。
通过有意识地应用这些模式,我们可以设计出可靠、智能、并且适用性明确(fit for purpose)的单体智能体。这些有能力的智能体是任何更大系统的基础构件。现在我们已经对如何构建一个合格的单体智能体有了扎实理解,下一步就是探索如何将这些构件组装起来。在下一章中,我们将考察system-level patterns,它们讨论多个智能体如何在一个一致且健壮的架构中交互、协作并被治理(governed)。