使用AI智能体构建应用-第十一章改进循环

在任何足够复杂的多智能体系统（Multiagent System）中，故障并非异类——它是不可避免的。这些系统在动态的现实环境中运行，与形形色色的用户、不可预测的输入以及快速变化的外部数据源进行交互。即使是设计最精良的系统，也会遇到边缘情况、模棱两可的指令以及初始设计未曾预料到的涌现行为。但是，对系统的真正考验不在于它是否会失败，而在于它如何从这些失败中学习并随时间推移不断改进。本章重点介绍如何构建反馈驱动的改进循环（Feedback-driven Improvement Loops），使智能体系统不仅能从故障中恢复，还能持续进化和自我完善。

持续改进不是单一的机制，而是一个相互关联的循环，利用反馈管道来辅助诊断问题、运行实验和进行学习。首先，必须通过反馈管道（Feedback Pipelines）来观察、理解和分类故障，从而挖掘出可操作的见解。这些管道结合了大规模的自动化分析与人在环路（Human-in-the-Loop）的审查，从原始遥测数据和真实用户交互中提取有意义的结论。接下来，所计划的改进必须在受控环境中通过实验框架（如影子部署、A/B 测试和贝叶斯老虎机算法）进行验证。这些技术提供了增量推出变更的结构化路径，在最大化影响的同时将风险降至最低。最后，改进必须通过持续学习机制嵌入到系统中，无论是通过即时的上下文调整（In-context Adjustments）还是定期的离线再训练。为了理解这种持续改进的循环，我们可以将其类比为强化学习（Reinforcement Learning），即智能体通过与环境的迭代交互来学习最佳行为。参见图 11-1。

图 11-1. 强化学习系统中智能体与环境的交互，展示了智能体如何接收观察结果、采取行动，并从环境中接收奖励和新的观察结果。

许多团队依赖预训练的基础模型，而不直接训练智能体——并且通常完全缺乏结构化的改进循环。本章探讨了如何通过实施反馈驱动机制来弥补这一差距，使智能体能够根据与环境的真实交互随时间进行适应和微调。正如我们在第七章中讨论的那样，微调（Fine-tuning）是闭合这一循环的有效方式，但在本章中，我们将讨论微调之外更广泛的技术。

然而，改进不仅仅是一个技术挑战，也是一个组织挑战。有效的改进循环需要工程、数据科学、产品管理和用户体验团队之间的协调。它们需要用于记录见解、确定改进优先级以及防止意外后果的系统。最重要的是，需要一种保持好奇心和迭代的文化——这种文化将每一次失败视为宝贵的信息来源，将每一次成功视为进一步完善的基础。

本章将持续改进分解为三个核心部分。第一部分探讨反馈管道的架构，详细介绍如何从自动化工具和人工审查员那里收集、分析和优先处理见解。接下来，我将深入研究实验框架，解释影子部署和 A/B 测试等技术如何在低风险环境中验证拟议的变更。然后，我将介绍持续学习，展示系统如何通过上下文策略和定期离线更新进行动态调整。表 11-1 概述了我们将涵盖的内容。

表 11-1. 改进循环方法论

技术	目的	优势	局限性	适用场景
反馈管道 (Feedback Pipelines)	观察、分析并优先处理交互中的问题，生成可操作的见解	数据处理可扩展；融合自动化与人工监督；主动风险检测；改进周期的基础	依赖数据质量；若无升级机制可能忽略极新颖的问题	用于诊断故障、发现模式或建立改进待办事项；适用于高容量、复杂的系统
实验 (Experimentation)	在受控设置中验证变更，衡量影响并在部署前降低风险	数据驱动；最小化风险；支持变体比较；适应真实条件	需要大量数据以确立显著性；资源消耗大；若无“门控”不适合超高风险场景	用于测试改进；非常适合增量发布、比较或需要快速反馈的动态环境
持续学习 (Continuous Learning)	根据交互和不断变化的需求嵌入动态适应能力	实时适应性；解决用户变化；增强弹性；支持个性化	存在过拟合/退化风险；计算成本高；需要稳健的监控	用于适应模式、个性化或修复系统性问题；最适合快速变化的环境或即时调整

归根结底，构建一个能够自我改进的系统不仅仅是修复损坏的东西，而是设计一个工作流，在这个工作流中，每一次失败、见解和实验都成为成长的燃料。本章提供了确保智能体系统能够适应不断变化环境所需的工具、策略和思维方式。

本书代码请见：https://github.com/alanhou/ai-agent。

使用AI智能体构建应用-第十一章改进循环

反馈管道 (Feedback Pipelines)

自动化反馈管道对于处理大规模多智能体系统产生的海量且复杂的数据至关重要。这些管道作为分析的第一道防线，持续监控交互，检测故障模式，并对问题进行聚类以浮现可操作的见解。通过利用 DSPy（声明式自改进语言程序）、微软的 Trace 和 自动提示优化 (APO) 等优化框架，以及可观测性工具，这些系统可以对智能体行为、工具使用和决策路径进行细粒度的可视化，同时实现自动化的改进。

自动化反馈管道的核心功能是系统地识别智能体工作流中反复出现的问题。例如，技能选择的反复失败可能表明用户意图与智能体推理过程之间存在错位，而工具执行的一致性错误可能揭示了工具参数生成方式中的不确定性。自动化系统擅长在海量数据集中进行模式识别，将相似的故障案例聚类在一起，使趋势变得明显且可操作。自动化管道不再依赖工程师梳理原始日志和追踪数据，而是将这些模式提炼为易于吸收的见解，标记出高影响问题以供立即关注。

图 11-2 展示了一个典型的自动化提示优化循环，比如 DSPy 和 APO 等框架所采用的方式。在这个过程中，初始提示被输入到目标模型中，目标模型生成的输出由评估模型根据数据集进行评估。得出的分数将通知优化模型，优化模型迭代地改进并提出新提示以提高性能。这种方法实现了持续的、数据驱动的增强，无需人工干预，使其成为智能体工作流中可扩展反馈管道的基石。

使用AI智能体构建应用-第十一章改进循环

图 11-2. 自动化提示优化管道，展示了从初始提示到目标模型和评估模型的流程，优化模型根据数据集驱动的分数生成改进后的提示。

由 DSPy、Trace 和 APO 等工具驱动的自动化反馈管道将原始观测数据转化为迭代改进，确保多智能体系统保持稳健和适应性。我们现在将更深入地讨论其中的几种方法。

DSPy 是斯坦福 NLP 研究人员开发的一个开源 Python 框架，用于自动优化和改进使用基础模型的系统。与依赖手动试错的传统提示工程不同，DSPy 将语言模型 (LM) 管道视为模块化的声明式程序，可以利用数据进行系统性改进。开发人员定义“签名（Signatures）”（任务的输入/输出规范），将它们组合成模块（例如，用于推理和工具使用的思维链或 ReAct），并应用优化器（如 BootstrapFewshot 或 MIPROv2）来自动生成更好的提示和少样本示例（Few-shot examples），甚至根据示例数据集和指标（例如完全匹配或语义相似度）微调模型行为。这种数据驱动的方法实现了自我改进循环，即故障模式的见解被反向传播以增强提示、工具或推理策略——非常适合智能体系统中的主动优化。DSPy 集成了流行的 LM API（如 OpenAI、Anthropic），并支持复杂工作流的多阶段编译。

作为 DSPy 的补充，微软的 Trace 是一个用于 AI 系统生成式优化的开源框架。它能够使用通用反馈信号（例如分数、自然语言批评或成对偏好）对 AI 智能体进行端到端训练和改进，而无需梯度或可微目标。通过将优化视为生成过程，Trace 使用基础模型迭代地提出和评估改进，使其适用于传统方法失效的黑盒系统。这对于在动态的多步骤环境中改进智能体行为特别有用，例如根据聚类错误的反馈来随时间推移演进推理策略或工具调用。

为了说明本节中的概念，我们将使用一个基于 LangGraph 构建的 安全运营中心 (SOC) 分析师智能体 作为贯穿始终的示例。该智能体处理网络安全任务，如调查威胁、分析日志和对事件进行分类（Triage）。其核心组件包括指导智能体方法的系统提示、用于查询日志或隔离主机等操作的工具，以及调用绑定到这些工具的基础模型（例如 GPT-5）的工作流。以下是该智能体系统提示和工具定义的简化摘录：

You are an experienced Security Operations Center (SOC) analyst specializing 
in cybersecurity incident response.
Your expertise covers:
- Threat intelligence analysis and IOC research
- Security log analysis and correlation across multiple systems
- Incident triage and classification (true positive/false positive)
- Malware analysis and threat hunting
- Network security monitoring and anomaly detection
- Incident containment and response coordination
- SIEM/SOAR platform operations

Your investigation methodology:
  1) Analyze security alerts and gather initial indicators
  2) Use lookup_threat_intel to research IPs, hashes, URLs, and domains
  3) Use query_logs to search relevant log sources for evidence
  4) Use triage_incident to classify findings as true/false positives
  5) Use isolate_host when containment is needed to prevent spread
  6) Follow up with send_analyst_response to document findings

Always prioritize rapid threat containment and accurate incident classification.

You are an experienced Security Operations Center (SOC) analyst specializing

in cybersecurity incident response.

Your expertise covers:

- Threat intelligence analysis and IOC research

- Security log analysis and correlation across multiple systems

- Incident triage and classification (true positive/false positive)

- Malware analysis and threat hunting

- Network security monitoring and anomaly detection

- Incident containment and response coordination

- SIEM/SOAR platform operations

Your investigation methodology:

1) Analyze security alerts and gather initial indicators

2) Use lookup_threat_intel to research IPs, hashes, URLs, and domains

3) Use query_logs to search relevant log sources for evidence

4) Use triage_incident to classify findings as true/false positives

5) Use isolate_host when containment is needed to prevent spread

6) Follow up with send_analyst_response to document findings

Always prioritize rapid threat containment and accurate incident classification.

我们的智能体定义了几个工具：

@tool
def lookup_threat_intel(indicator: str, type: str, **kwargs) -> str:
   """查找 IP 地址、文件哈希、URL 和域名的威胁情报。"""
   print(f'''[TOOL] lookup_threat_intel(indicator={indicator}, type={type}, kwargs={kwargs})''')
   log_to_loki("tool.lookup_threat_intel", f"indicator={indicator}, type={type}")
   return "threat_intel_retrieved"

@tool
def query_logs(query: str, log_index: str, **kwargs) -> str:
   """搜索和分析跨身份验证、端点、网络、防火墙和 DNS 系统的安全日志。"""
   print(f"[TOOL] query_logs(query={query}, log_index={log_index}, kwargs={kwargs})")
   log_to_loki("tool.query_logs", f"query={query}, log_index={log_index}")
   return "log_query_executed"

@tool
def triage_incident(incident_id: str, decision: str, reason: str, **kwargs):
   """将安全事件分类为真阳性、假阳性，或升级以进行进一步调查。"""
   print(f'''[TOOL] triage_incident(incident_id={incident_id},     decision={decision}, reason={reason},     kwargs={kwargs})''')
   log_to_loki("tool.triage_incident", f"incident_id={incident_id}, decision={decision}")
   return "incident_triaged"

@tool
def isolate_host(host_id: str, reason: str, **kwargs) -> str:
   """隔离受感染的主机以防止横向移动并控制安全事件。"""
   print(f"[TOOL] isolate_host(host_id={host_id}, reason={reason}, kwargs={kwargs})")
   log_to_loki("tool.isolate_host", f"host_id={host_id}, reason={reason}")
   return "host_isolated"

@tool
def send_analyst_response(incident_id: str = None, message: str = None) -> str:
   """向利益相关者发送安全分析、事件更新或建议。"""
   print(f"[TOOL] send_analyst_response → {message}")
   log_to_loki("tool.send_analyst_response", f"incident_id={incident_id}, message={message}")
   return "analyst_response_sent"

TOOLS = [
   lookup_threat_intel, query_logs, triage_incident, isolate_host, send_analyst_response
]

@tool

def lookup_threat_intel(indicator: str, type: str, **kwargs) -> str:

"""查找 IP 地址、文件哈希、URL 和域名的威胁情报。"""

print(f'''[TOOL] lookup_threat_intel(indicator={indicator}, type={type}, kwargs={kwargs})''')

log_to_loki("tool.lookup_threat_intel", f"indicator={indicator}, type={type}")

return "threat_intel_retrieved"

@tool

def query_logs(query: str, log_index: str, **kwargs) -> str:

"""搜索和分析跨身份验证、端点、网络、防火墙和 DNS 系统的安全日志。"""

print(f"[TOOL] query_logs(query={query}, log_index={log_index}, kwargs={kwargs})")

log_to_loki("tool.query_logs", f"query={query}, log_index={log_index}")

return "log_query_executed"

@tool

def triage_incident(incident_id: str, decision: str, reason: str, **kwargs):

"""将安全事件分类为真阳性、假阳性，或升级以进行进一步调查。"""

print(f'''[TOOL] triage_incident(incident_id={incident_id}, decision={decision}, reason={reason}, kwargs={kwargs})''')

log_to_loki("tool.triage_incident", f"incident_id={incident_id}, decision={decision}")

return "incident_triaged"

@tool

def isolate_host(host_id: str, reason: str, **kwargs) -> str:

"""隔离受感染的主机以防止横向移动并控制安全事件。"""

print(f"[TOOL] isolate_host(host_id={host_id}, reason={reason}, kwargs={kwargs})")

log_to_loki("tool.isolate_host", f"host_id={host_id}, reason={reason}")

return "host_isolated"

@tool

def send_analyst_response(incident_id: str = None, message: str = None) -> str:

"""向利益相关者发送安全分析、事件更新或建议。"""

print(f"[TOOL] send_analyst_response → {message}")

log_to_loki("tool.send_analyst_response", f"incident_id={incident_id}, message={message}")

return "analyst_response_sent"

TOOLS = [

lookup_threat_intel, query_logs, triage_incident, isolate_host, send_analyst_response

]

在实际部署中，该智能体处理诸如“来自 IP 203.0.113.45 的可疑登录尝试”之类的警报。随着时间的推移，随着威胁的演变（例如，出现新的攻击向量）、用户查询的转变或外部数据源的更改，智能体可能会遇到故障——例如误解查询、选择次优工具或生成不准确的分类。这正是反馈管道发挥作用的地方：它们检测这些问题，分析根本原因，并推动改进。例如，如果智能体的提示假设了过时的威胁模式（例如专注于基于 IP 的登录，而攻击者转向凭据填充），可能会发生“漂移（Drift）”，导致重复的假阴性（漏报）。人类工程师可以通过修改提示以包含更新的示例或在工具中添加验证步骤来解决此问题。

现代反馈工具最强大的功能之一是能够将基于文本的反馈直接反向传播到系统的提示、技能参数和推理策略中。例如，如果分析显示某些任务指令经常导致模棱两可的输出，管道可以建议对相关提示进行改进——收紧措辞、调整约束条件或重新排序推理过程中的步骤。同样，如果工具调用由于参数格式错误而反复失败，自动化系统可以建议调整这些参数的构建方式，包括引入验证步骤或动态回退（Dynamic Fallbacks）。

除了反应性改进外，自动化管道还支持主动优化。通过持续分析传入数据，它们可以在潜在风险演变为严重故障之前将其显现出来。例如，早期检测用户查询模式的漂移可以触发提示调整，以确保智能体与不断变化的用户期望保持一致。这些主动见解使团队能够在潜在问题升级为大问题之前解决它们。

然而，自动化管道并非万无一失。虽然它们擅长识别模式和提出变更建议，但它们无法完全考虑上下文的细微差别或根据更广泛的战略目标优先考虑改进。这就是人工监督变得至关重要的地方——工程师必须审查、验证，并在必要时推翻这些系统的建议。因此，自动化管道不是人类洞察力的替代品，而是强大的放大器，使工程师能够将他们的专业知识集中在最重要的地方。

本质上，自动化反馈管道创建了一个可扩展的、自我改进的循环：它们跨越提示、工具和推理流进行观察、聚类、分析并提出改进建议。通过高效管理故障数据并生成可操作的见解，这些系统构成了稳健的反馈驱动开发周期的基础，使多智能体系统能够不断适应和进化以响应现实世界的需求。

自动问题检测与根本原因分析

随着智能体系统复杂性的增加，手动监控和调试很快变得不可扩展。自动问题检测和根因分析 (RCA) 对于快速、大规模地识别和诊断问题至关重要。

在我们的 SOC 智能体示例中，设想系统每天处理数百个警报。自动检测可以标记出 query_logs 调用失败的激增，其中查询参数格式错误（例如，由于智能体生成了后端无法解析的过于复杂的类 SQL 查询）。使用 Trace 等工具，管道会记录每次调用，将类似的错误（例如“无效的查询语法”）聚类，并将它们与智能体提示中的上游推理步骤相关联。

自动问题检测利用基于规则的触发器、异常检测算法和统计聚类的组合来筛选海量的日志和事件。这些系统可以标记某些模式：

特定技能或工具的反复失败
错误率或响应时间的突然激增
用户参与度或满意度指标的异常
跨智能体版本或部署环境的行为差异

现代反馈管道通常采用机器学习或统计技术来检测原本可能被忽视的微妙趋势——例如智能体决策模式的逐渐漂移，或特定用户输入与下游故障之间的相关性。

一旦检测到问题，根因分析 (RCA) 旨在回答不仅是什么失败了，还有为什么。RCA 不仅仅是事后调试；它是对用户意图、智能体推理、系统架构和外部环境之间关系的持续、迭代的探究。有效的 RCA 通常遵循以下几个步骤：

工作流追踪 (Workflow tracing)： 重建导致故障的智能体决策、工具调用和用户交互的端到端链条。
故障定位 (Fault localization)： 隔离导致崩溃的精确组件——例如被误解的提示、不恰当的技能选择或具有限制性参数逻辑的工具。
模式识别 (Pattern recognition)： 确定故障是孤立事件还是重复趋势的一部分，可能与特定的用户群组、数据输入或系统状态有关。
影响评估 (Impact assessment)： 评估问题的频率和严重程度以确定响应优先级。

至关重要的是，智能体系统中的 RCA 往往揭示故障并非纯粹的技术问题——它们可能源于模糊的任务定义、训练数据的缺失或系统未设计处理的不断变化的用户期望。在某些情况下，RCA 会揭示组织盲点，例如激励错误行为的成功指标或不再符合用户需求的工作流。

可操作的 RCA 不仅仅是追责；它为有意义的系统改进提供了机会——无论是通过提示或工具的改进、技能编排的变更，甚至是重新思考用户需求的表达和沟通方式。

以自动问题检测和 RCA 为锚点的稳健反馈管道，将团队从无休止的灭火（Triage）转变为有纪律的、洞察力驱动的过程，在这个过程中，每一次失败都被挖掘用于学习。这是将遥测数据转化为质变的第一步——为智能体系统中随后的所有实验和持续学习循环奠定基础。

人机协同审查 (Human-in-the-Loop Review)

虽然自动化系统擅长标记异常并显现多智能体工作流中的重复模式，但在许多情况下，仅靠自动化分析是不够的。某些问题——特别是涉及模糊的用户意图、伦理细微差别、相互冲突的目标或新颖的边缘情况——需要人类直觉、领域专业知识和上下文判断。人机协同 (HITL) 审查是对自动检测和 RCA 的重要补充，确保反馈管道保持有效、全面并与更广泛的组织目标保持一致。

对于 SOC 智能体，HITL 可能会升级自动 RCA 标记为模糊分类的案例（例如，可能来自虚拟专用网络的假阳性“可疑登录”，或者是真正的入侵）。安全工程师审查追踪记录，验证提示的解释，并决定修复方案，如在提示中添加伦理准则（例如，“在确认对关键业务的影响之前，避免隔离主机”）。

图 11-3 描绘了 HITL 审查工作流，其中输入数据由智能体处理以生成候选输出。这些候选项由人类评估员进行审查，评估员提供手动反馈完善或批准它们，从而生成交付给最终用户的人工批准的输出。审查过程中的系统反馈会循环回系统增强智能体的性能，确保与自动化单独无法处理的复杂需求保持一致。这种结构凸显了整合人类判断以解决 SOC 智能体在细微威胁评估升级中所见的模糊性和高风险决策的重要性。

使用AI智能体构建应用-第十一章改进循环

图 11-3. HITL 审查工作流，输入数据流经智能体生成候选输出，经人工审查并提供手动反馈，最终形成支持系统反馈循环的已批准输出给最终用户。

HITL 审查不仅仅是自动化的安全网；它是一个结构化的升级过程，将人类判断力引入最复杂、最模糊或影响最大的系统问题中。自动化管道标记超过预定义阈值、表现出无法解释的模式或呈现未解决冲突的事件——这些事件随后被路由进行人工评估。升级标准可能包括：

没有明确技术解释的持续错误
涉及监管或伦理含义的工作流中的异常
高价值或任务关键型任务中的失败
来自自动化工具的相互冲突的建议或诊断

为了在人类和 AI 决策之间找到适当的平衡——确保人类专注于高价值干预而不被压垮——升级应优先考虑模型确定性最低或后果最严重的案例。对于低确定性案例，将置信度分数直接集成到智能体的输出中：许多基础模型（例如 GPT-5）可以通过包含诸如“以以下内容结束您的响应：certainty: [基于准确性信心的 0-1 分数]”之类的指令，在输出响应的同时输出自我评估的确定性分数（0-1）。可以设置阈值（例如，如果确定性 < 0.7 则升级），或对概率输出使用熵度量（例如，分类 logits 中的高熵表示模糊性）。跨多次运行的方差（例如，集成 3-5 次推理，如果输出差异 > 20% 则升级）或外部评估器（例如，一个评分一致性的辅助基础模型批评者）可以进一步量化不确定性。在 SOC 智能体中，低确定性分类（例如，分数 < 0.8 的威胁分类）可以自动升级进行审查，过滤掉常规的高置信度案例。

对于高影响案例，根据领域特定的严重性进行评估：在 SOC 智能体中，标记具有“高”严重性评级（例如潜在的数据泄露）或影响关键资产（例如管理员帐户）的事件。将其与风险评分结合——例如，将不确定性乘以后果（如果得分 > 阈值则升级）——以此确定优先级。像 DSPy 这样的工具可以使用历史数据离线优化这些阈值，模拟升级率以平衡负载（例如，目标是将升级到人工的案例控制在 10% 以内，以避免疲劳）。这种混合方法确保 AI 处理大量常规决策，而人类在最需要判断力的地方进行干预，从而培育可扩展、值得信赖的系统。通过定义明确的升级触发器，团队可以防止自动化系统做出不恰当或短视的干预，并确保细微的案例得到应有的关注。

当案例被升级时，一个多学科审查团队——通常包括工程师、产品经理、数据科学家和 UX 专家——会系统地分析标记的问题。审查过程通常包括以下内容：

上下文分析： 在受控环境中重现故障或异常，以了解事件序列和决策点。
追踪检查： 检查日志、追踪和决策链，以阐明智能体如何解释用户意图并选择行动。
影响评估： 评估问题的范围和严重性，同时考虑技术正确性和用户体验 (UX)。
解决方案设计： 推荐有针对性的干预措施——从提示细化到工作流重新设计、新技能开发，甚至面向用户功能的更改。在 SOC 示例中，如果漂移导致主机过度隔离，人类可以通过更新 isolate_host 工具以包含确认步骤来修复它。

有效的 HITL 审查协议强调文档和可重复性。决策被记录，理由被捕获，结果被跟踪，以确保未来的事件能够更有效地解决，并且随着时间的推移识别出系统性问题。

HITL 审查通常受益于纯工程之外的多样化视角。产品经理可以澄清观察到的失败是否反映了与用户需求更深层次的错位。数据科学家可能会识别出其他人看不见的模式或边缘情况。UX 研究人员可以发现自动化指标可能遗漏的用户交互中的摩擦点。这种协作方法确保改进不仅在技术上是正确的，而且对最终用户来说也是有意义和有价值的。

HITL 审查的最终价值在于其对组织学习的贡献。每个被审查的案例都成为不断发展的知识库中的一个数据点——为培训新团队成员、告知系统设计和完善反馈循环提供参考。吸取的经验教训被反馈到提示和工具细化、技能开发和系统文档中，从而减少未来类似故障的发生。

通过平衡自动化与人工监督，HITL 审查确保多智能体系统保持可扩展且值得信赖。它将反馈管道从单纯的错误纠正机制转变为洞察力、弹性和持续改进的引擎。

提示与工具细化 (Prompt and Tool Refinement)

一旦反馈管道和 HITL 审查出现可操作的见解，下一步就是实施有针对性的改进。在智能体系统中，系统改进最直接和最有影响力的杠杆是提示（提供给语言模型的指令和上下文）的设计以及外部工具（智能体可以使用的函数、API 和操作）的构建和调用，因此细化提示可以是提高整体性能的一种非常有效的方式。

提示细化 (Prompt Refinement)

提示是用户意图和智能体行动之间的桥梁。提示措辞、结构或上下文的微小变化都会极大地影响智能体的解释、推理和输出。反馈循环通常会揭示以下问题：

模棱两可的指令导致不一致或不相关的响应
过于宽泛的提示导致幻觉或偏离任务的输出
僵化、狭窄的提示无法推广到现实世界的可变性
任务边界、升级或错误处理方面缺乏清晰度

细化始于分析：审查失误，追踪智能体推理，并隔离提示的哪一部分导致了不良结果。改进措施可能包括：

为清晰而重写： 使指令更加明确，减少歧义，并指定预期的响应格式。
添加范例 (Exemplars)： 在提示中提供正面和负面的例子，以锚定智能体的推理。
分解任务： 将复杂的多步骤指令拆分为更小的顺序提示或中间推理阶段。
上下文扩展： 纳入额外的上下文、约束或相关背景，以更有效地指导智能体。

使用AI智能体构建应用-第十一章改进循环

DSPy 擅长通过从一组示例中编译优化后的提示来自动化提示细化。对于 SOC 智能体，我们可以使用 DSPy 来细化 ReAct 模块的内部提示，通过更好地使推理和工具调用与预期响应保持一致来改进智能体处理警报的方式。这对于解决反馈中识别出的次优工具选择或不一致输出等问题特别有用。以下是一个 DSPy 代码示例，它使用少量合成测试用例优化用于 SOC 事件处理的 ReAct 模块（在实践中扩展到 100 多个带注释的示例以获得更好的结果）：

import dspy
dspy.configure(lm=dspy.OpenAI(model="gpt-4o-mini"))

def lookup_threat_intel(indicator: str) -> str:
    """模拟：查找指标的威胁情报。"""
    return f"Mock intel for {indicator}: potentially malicious"

def query_logs(query: str) -> str:
    """模拟：搜索和分析安全日志。"""
    return f"Mock logs for '{query}': suspicious activity detected"

# 少量合成测试用例（警报 -> 预期响应）
# 在实践中，应源自真实日志或注释后的故障；
# 目标是拥有 100+ 个示例以获得更好的优化效果
trainset = [
    dspy.Example(alert='''Suspicious login attempt from IP 203.0.113.45 to admin account.''',
                 response='''Lookup threat intel for IP, query logs for activity, triage as true positive, isolate host if malicious.''')
                     .with_inputs('alert'),
    dspy.Example(alert="Unusual file download from URL example.com/malware.exe.",
                 response='''Lookup threat intel for URL and hash, query logs for endpoint activity, triage as true positive, isolate host.''').with_inputs('alert'),
    dspy.Example(alert="High network traffic to domain suspicious-site.net.",
                 response='''Lookup threat intel for domain, query logs for network and firewall, triage as false positive if benign.''').with_inputs('alert'),
    dspy.Example(alert='''Alert: Potential phishing email with attachment hash abc123.''',
                 response='''Lookup threat intel for hash, query logs for email and endpoint, triage as true positive, send analyst response.''').with_inputs('alert'),
    dspy.Example(alert='''Anomaly in user behavior: multiple failed logins from new device.''',
                 response='''Query logs for authentication, lookup threat intel for device IP, triage as true positive if pattern matches attack.''').with_inputs('alert'),]

# 为 SOC 事件处理定义 ReAct 模块
react = dspy.ReAct("alert -> response", tools=[lookup_threat_intel, query_logs])

# 带有简单指标的优化器
# (这里为了演示使用完全匹配；
# 生产环境中应使用更细致的指标，如语义相似度)
tp = dspy.MIPROv2(metric=dspy.evaluate.answer_exact_match, auto="light", 
                  num_threads=24)

optimized_react = tp.compile(react, trainset=trainset)

import dspy

dspy.configure(lm=dspy.OpenAI(model="gpt-4o-mini"))

def lookup_threat_intel(indicator: str) -> str:

"""模拟：查找指标的威胁情报。"""

return f"Mock intel for {indicator}: potentially malicious"

def query_logs(query: str) -> str:

"""模拟：搜索和分析安全日志。"""

return f"Mock logs for '{query}': suspicious activity detected"

# 少量合成测试用例（警报 -> 预期响应）

# 在实践中，应源自真实日志或注释后的故障；

# 目标是拥有 100+ 个示例以获得更好的优化效果

trainset = [

dspy.Example(alert='''Suspicious login attempt from IP 203.0.113.45 to admin account.''',

response='''Lookup threat intel for IP, query logs for activity, triage as true positive, isolate host if malicious.''')

.with_inputs('alert'),

dspy.Example(alert="Unusual file download from URL example.com/malware.exe.",

response='''Lookup threat intel for URL and hash, query logs for endpoint activity, triage as true positive, isolate host.''').with_inputs('alert'),

dspy.Example(alert="High network traffic to domain suspicious-site.net.",

response='''Lookup threat intel for domain, query logs for network and firewall, triage as false positive if benign.''').with_inputs('alert'),

dspy.Example(alert='''Alert: Potential phishing email with attachment hash abc123.''',

response='''Lookup threat intel for hash, query logs for email and endpoint, triage as true positive, send analyst response.''').with_inputs('alert'),

dspy.Example(alert='''Anomaly in user behavior: multiple failed logins from new device.''',

response='''Query logs for authentication, lookup threat intel for device IP, triage as true positive if pattern matches attack.''').with_inputs('alert'),]

# 为 SOC 事件处理定义 ReAct 模块

react = dspy.ReAct("alert -> response", tools=[lookup_threat_intel, query_logs])

# 带有简单指标的优化器

# (这里为了演示使用完全匹配；

# 生产环境中应使用更细致的指标，如语义相似度)

tp = dspy.MIPROv2(metric=dspy.evaluate.answer_exact_match, auto="light",

num_threads=24)

optimized_react = tp.compile(react, trainset=trainset)

这段代码优化了 ReAct 模块的提示（例如，用于推理步骤和工具调用），以更好地匹配提供的示例，从而在无需手动调整提示的情况下有效地细化智能体的行为。由此产生的 optimized_react 可以集成到 SOC 智能体的工作流中，从而能够更可靠地处理各种警报，并减少诸如幻觉或偏离任务输出之类的问题。

在高级反馈系统中，甚至可以针对观察到的故障模式自动进行提示调整，尽管所有更改都应经过验证——最好是在离线测试和实时影子部署中进行——以防止退化或意外的副作用。

工具细化 (Tool Refinement)

在现代智能体架构中，仅靠提示很少够用。智能体越来越依赖一套外部工具——API、代码函数、数据库查询或自定义技能——来检索信息、执行交易或采取具体行动。反馈管道经常会浮现如下问题：

针对给定用户任务选择了不正确或次优的工具
参数不匹配或工具调用的输入格式错误
工具集中的空白——由于缺少或不完整的工具，智能体无法完成任务
工具链故障，其中一步的输出没有针对下一步进行适当的格式化

工具细化是一个多层次的过程：

细化内部逻辑： 优化工具内的提示或模型以更好地处理和分类数据。
扩展能力： 通过结合优化的推理，增强工具以覆盖更广泛的场景。
改进集成： 确保工具输出可靠、可操作的结果以满足智能体的需求。

使用AI智能体构建应用-第十一章改进循环

DSPy 通过优化工具在智能体模块内的选择和链接方式来支持工具细化。扩展前面的例子，假设反馈揭示了事件分类工具集中的空白（例如，智能体经常跳过分类步骤，导致次优决策）。我们可以添加一个新的用于分类的模拟工具，更新 ReAct 模块包含它，使用强调正确工具链的示例扩展训练集，并重新优化。这改进了工具选择启发式算法和集成，使智能体对现实世界的可变性更加稳健。以下是扩展的 DSPy 代码：

import dspy
dspy.configure(lm=dspy.LM("openai/gpt-4o-mini"))

# 定义威胁分类任务的 DSPy 签名
class ThreatClassifier(dspy.Signature):
   """将给定指标（例如 IP、URL、哈希）的威胁级别分类为 'benign'（良性）、'suspicious'（可疑）或 'malicious'（恶意）。"""
   indicator: str = dspy.InputField(desc="要分类的指标，如 IP 地址、URL 或文件哈希。")
   threat_level: str = dspy.OutputField(desc="分类后的威胁级别：'benign'、'suspicious' 或 'malicious'。")

# 使用思维链（ChainOfThought）进行推理分类的 DSPy 模块
class ThreatClassificationModule(dspy.Module):
   def __init__(self):
       super().__init__()
       self.classify = dspy.ChainOfThought(ThreatClassifier)
  
   def forward(self, indicator):
       return self.classify(indicator=indicator)

# 用于优化的合成/手动注释数据集（在实践中，使用 50-200+ 个来自真实 SOC 日志的示例）
# 每个示例都包含一个指标和基本事实威胁级别
trainset = [
   dspy.Example(indicator="203.0.113.45", threat_level="suspicious").with_inputs('indicator'),  # 已知恶意 IP
   dspy.Example(indicator="example.com/malware.exe", threat_level="malicious").with_inputs('indicator'),  # 恶意 URL
   dspy.Example(indicator="benign-site.net", threat_level="benign").with_inputs('indicator'),  # 安全域名
   dspy.Example(indicator="abc123def456", threat_level="malicious").with_inputs('indicator'),  # 恶意软件哈希
   dspy.Example(indicator="192.168.1.1", threat_level="benign").with_inputs('indicator'),  # 本地 IP
   dspy.Example(indicator="obfuscated.url/with?params", threat_level="suspicious").with_inputs('indicator'),  # 边缘情况：混淆的 URL
   dspy.Example(indicator="new-attack-vector-hash789", threat_level="malicious").with_inputs('indicator'),  # 新型威胁
]

# 评估指标（威胁级别的完全匹配；生产环境中使用语义匹配或自定义评分器）
def threat_match_metric(example, pred, trace=None):
   return example.threat_level.lower() == pred.threat_level.lower()

# 优化模块（这将细化内部提示以更好地处理各种情况）
optimizer = dspy.BootstrapFewshotWithRandomSearch(metric=threat_match_metric, max_bootstrapped_demos=4, max_labeled_demos=4)
optimized_module = optimizer.compile(ThreatClassificationModule(), trainset=trainset)

# 工具中的使用示例：优化后，在 classify_threat 中使用
def classify_threat(indicator: str) -> str:
   """使用优化的 DSPy 模块对威胁级别进行分类。"""
   prediction = optimized_module(indicator=indicator)
   return prediction.threat_level

import dspy

dspy.configure(lm=dspy.LM("openai/gpt-4o-mini"))

# 定义威胁分类任务的 DSPy 签名

class ThreatClassifier(dspy.Signature):

"""将给定指标（例如 IP、URL、哈希）的威胁级别分类为 'benign'（良性）、'suspicious'（可疑）或 'malicious'（恶意）。"""

indicator: str = dspy.InputField(desc="要分类的指标，如 IP 地址、URL 或文件哈希。")

threat_level: str = dspy.OutputField(desc="分类后的威胁级别：'benign'、'suspicious' 或 'malicious'。")

# 使用思维链（ChainOfThought）进行推理分类的 DSPy 模块

class ThreatClassificationModule(dspy.Module):

def __init__(self):

super().__init__()

self.classify = dspy.ChainOfThought(ThreatClassifier)

def forward(self, indicator):

return self.classify(indicator=indicator)

# 用于优化的合成/手动注释数据集（在实践中，使用 50-200+ 个来自真实 SOC 日志的示例）

# 每个示例都包含一个指标和基本事实威胁级别

trainset = [

dspy.Example(indicator="203.0.113.45", threat_level="suspicious").with_inputs('indicator'), # 已知恶意 IP

dspy.Example(indicator="example.com/malware.exe", threat_level="malicious").with_inputs('indicator'), # 恶意 URL

dspy.Example(indicator="benign-site.net", threat_level="benign").with_inputs('indicator'), # 安全域名

dspy.Example(indicator="abc123def456", threat_level="malicious").with_inputs('indicator'), # 恶意软件哈希

dspy.Example(indicator="192.168.1.1", threat_level="benign").with_inputs('indicator'), # 本地 IP

dspy.Example(indicator="obfuscated.url/with?params", threat_level="suspicious").with_inputs('indicator'), # 边缘情况：混淆的 URL

dspy.Example(indicator="new-attack-vector-hash789", threat_level="malicious").with_inputs('indicator'), # 新型威胁

]

# 评估指标（威胁级别的完全匹配；生产环境中使用语义匹配或自定义评分器）

def threat_match_metric(example, pred, trace=None):

return example.threat_level.lower() == pred.threat_level.lower()

# 优化模块（这将细化内部提示以更好地处理各种情况）

optimizer = dspy.BootstrapFewshotWithRandomSearch(metric=threat_match_metric, max_bootstrapped_demos=4, max_labeled_demos=4)

optimized_module = optimizer.compile(ThreatClassificationModule(), trainset=trainset)

# 工具中的使用示例：优化后，在 classify_threat 中使用

def classify_threat(indicator: str) -> str:

"""使用优化的 DSPy 模块对威胁级别进行分类。"""

prediction = optimized_module(indicator=indicator)

return prediction.threat_level

这种细化增强了工具从真实 API 数据中准确分类威胁级别的能力，通过优化基础模型的解释提示来处理更广泛的响应——包括无结果的情况、部分匹配或新兴威胁。

每个提示或工具的细化都应记录明确的理由——观察到了什么问题，做了什么更改，以及如何衡量其有效性。这种规则确保改进是可追溯和可重复的，并为未来的团队提供关于什么有效以及为什么有效的知识库。

改进应进行迭代验证，使用离线评估（使用留出的日志或合成案例）和受控的现场实验（例如，影子部署、A/B 测试）。监控部署后的性能至关重要：即使是看似微小的提示调整也可能产生系统范围的影响，特别是在复杂或高度智能化的环境中。

随着时间的推移，系统化提示和工具细化的累积效应是巨大的。智能体变得更可靠，更不脆弱，并且更好地与用户需求保持一致。反馈驱动的细化还揭示了更高层次的模式——误解的常见来源或能力上的经常性差距——这些可以为架构改进和未来的智能体设计提供信息。

提示和工具细化是智能体系统中进步的实践工具。通过将洞察力与行动联系起来，并进行深思熟虑的迭代，团队可以确保每一次故障或摩擦点都成为打造更强大、更灵敏、更具能力的 AI 的机会。

聚合和优先处理改进

随着智能体系统复杂性和规模的增长，由反馈管道和人工审查产生的可操作见解流也在增加。团队很快就会发现，并非每一个错误、失误或增强都能——或应该——立即解决。如果没有一个聚合和优先处理改进的系统，团队可能会被噪音淹没，追逐低影响的修复，或者为了表面症状而错过系统性问题。

第一步是聚合 (Aggregation)：将来自多个来源的见解整合到一个统一的、可访问的视图中。反馈可能源自自动监控系统、RCA 报告、用户投诉、HITL 审查或工程师的直接观察。聚合平台（如集中式仪表板、可观测性工具或结构化问题跟踪器）有助于将分散的数据转化为连贯的改进待办事项 (Backlog)。关键实践包括：

去重 (Deduplication)： 将相似的问题聚类在一起（例如，重复的提示失败或重复的工具调用错误）以避免分散精力。
标记和分类 (Tagging and categorization)： 按根本原因、受影响的工作流、用户影响或系统组件标记问题，以便于分类和过滤。
链接到上下文 (Linking to context)： 将支持日志、追踪、用户报告和 RCA 文档附加到每个改进项，以便进行有效的分流和行动。

手头有了统一的待办事项后，下一个挑战是优先级排序 (Prioritization)。并非所有的改进都是平等的——有些改进对系统可靠性、用户满意度或业务成果有巨大的影响。有效的优先级排序需要平衡几个维度：

频率 (Frequency)： 这个问题多久发生一次？频繁但细微的问题加起来可能会造成显著的用户摩擦或运营开销。
严重性/影响 (Severity/Impact)： 业务或用户影响是什么？导致关键故障、安全风险或主要不满的问题应排在首位。
可行性 (Feasibility)： 修复有多难？速战速决（低投入、高影响）通常被优先考虑，而复杂的改进可能需要仔细的范围界定或排序。
战略一致性 (Strategic alignment)： 改进是否与当前的产品目标、即将推出的功能或合规性要求一致？有时，修复之所以必不可少，不是因为它的频率，而是因为它在促成重大举措或监管里程碑方面的作用。
复发和风险 (Recurrence and risk)： 如果不解决，类似的故障是否可能再次发生？系统性问题——那些植根于架构、训练数据或智能体推理的问题——应被标记以获得更深入的关注。

使用AI智能体构建应用-第十一章改进循环

优先级框架——从简单的影响/投入矩阵到更正式的敏捷 (Agile) 或看板 (Kanban) 系统——可以帮助团队达成共识并随着系统动态的发展调整计划。至关重要的是将改进待办事项视为一个动态的工件，而不是静态的待办清单。定期审查周期、“漏洞分流”会议和跨团队同步确保优先级根据新事件、不断变化的用户需求或战略调整进行持续重新评估。随着改进的实施和验证，吸取的经验教训应反馈到聚合过程中——闭合循环并确保重复出现的模式能为未来的预防提供信息。

聚合和优先级的规则将反馈的原始洪流转化为清晰、可操作的路线图。通过将有限的资源集中在最具影响力、最可行和战略上最一致的变更上，团队可以加速系统演进，建立用户信任，并防止可能减缓进度的“技术债务”的积累。在变化迅速且风险极高的智能体系统中，这个过程不是奢侈品——它是必需品。

实验 (Experimentation)

实验是多智能体系统中安全进步的引擎。它是连接见解与部署的桥梁，使团队能够验证变更、衡量其实际效果，并在广泛推出更新之前降低风险。鉴于智能体架构的复杂性和互联性，即使是微小的调整——如微调提示、更新工具参数或细化编排逻辑——也可能产生深远且有时无法预测的后果。如果没有严格的实验框架，团队就有引入退化、破坏可靠性或偏离用户和业务目标的风险。

设计良好的实验流程提供了结构化的、增量的变革路径。与其从想法直接跨跃到生产，不如在紧密模仿现实世界的受控环境中引入和评估变更。这通常始于预发布 (Staging) 或发布候选 (RC) 环境——这是标准的最佳实践，更新在隔离的、类似生产的设置中进行测试，以便在不影响线上用户的情况下及早发现问题。由此，团队可以分层采用先进的部署技术，如影子部署、金丝雀发布 (Canary rollouts)（逐渐向一部分流量公开）、滚动更新 (Rolling updates)（逐个实例增量升级）或蓝/绿部署 (Blue/green deployments)（在两个相同的环境之间切换）。这种方法不仅能及早发现意外的副作用，还能在替代配置之间进行直接比较，为数据驱动的决策铺平道路。

影子部署 (Shadow Deployments)

想象一下，当现场表演不间断进行时在后台排练一出戏——这就是行动中的影子部署。在这里，更新后的智能体（例如，具有针对查询歧义的精细推理）会“影子跟随”生产版本，并行处理相同的输入。但只有实时系统的输出会到达用户；影子系统的输出被记录下来用于审查，从而保护每个人免受事故影响。

影子部署是在现实条件下验证系统变更的有力方法——而无需将用户暴露于风险之中。这种并列比较使团队能够在真实的运营负载下观察、测量和诊断新智能体或更新后的智能体逻辑的行为。影子部署对于高影响或高风险的变更特别有价值——例如规划工作流的更新、与外部系统的集成或重大的提示修改——如果这些变更未经检查就发布，可能会产生严重后果。主要优势包括：

现实验证： 影子系统体验完整的真实用户行为谱系，显现出经常逃避受控测试环境的差异和涌现问题。
安全探索： 工程师可以尝试大胆的改进或架构变更，确信任何错误、退化或性能下降都不会到达生产环境。
边缘情况发现： 罕见或不可预测的场景——如格式错误的用户输入、模棱两可的指令或集成问题——可以在部署前被检测和分析。
与互补策略集成： 影子部署可以辅以蓝绿部署（维护两个相同的环境，仅在验证后切换流量）以在影子测试后实现无缝、零停机的推出，或金丝雀部署（逐渐将少量实时流量路由到新版本）以支持生产中的增量实时验证，从而降低整体风险并促进从测试到全面部署的更平滑过渡。

高质量的仪表化 (Instrumentation) 是关键：严格比较追踪记录、指标（准确性、延迟）和输出。通过三角测量差异来区分突破与错误。

挑战出现在依赖 HITL 的智能体中（例如，那些询问用户批准的智能体）——影子无法在没有暴露风险的情况下进行交互。可以通过历史回放或合成数据模拟响应，或者对于交互式流程混合使用暂存或 A/B 测试。

本质上，影子部署在不承担风险的情况下，在真实场景中验证并悄然建立信心。

使用AI智能体构建应用-第十一章改进循环

A/B 测试 (A/B Testing)

如果说影子部署是在场边观察，那么 A/B 测试则将变体推向聚光灯下——在控制组 (A) 和实验组 (B) 版本之间分配实时流量以进行正面交锋。用户与其中之一进行交互，从而在协作智能体群的任务成功率或减少响应中的幻觉等指标上产生可量化的成功。这对于可衡量的微调非常出色，例如在实时聊天中运行提示变体的 A/B 测试以优化用户满意度，而影子部署可能会错过微妙的参与度变化。如图 11-4 所示，A/B 测试的常见设置涉及将用户随机分配到不同的智能体变体，以实现直接的、真实世界的比较。

使用AI智能体构建应用-第十一章改进循环

图 11-4. 智能体配置的 A/B 测试，用户在智能体的两个变体（A 和 B）之间平均分配（50/50），根据实时交互评估性能差异。

这种平均分配确保了公平的曝光和可靠的指标，使团队能够自信地确定哪种变体在实际场景中表现更好。A/B 测试的优势包括：

现实相关性： 结果反映了真实的用户行为和输入多样性，提供了变更是否能在孤立测试用例之外推广的有力证据。
直接比较： 团队可以快速确定哪个版本在实际操作条件下提供更好的结果。
统计严谨性： 设计得当的 A/B 测试确保观察到的差异是有意义的——而不是随机变化或偏差抽样的结果。

为了最大化 A/B 测试的价值，团队应该：

定义与拟议变更目标一致的清晰、可操作的指标。
确保足够的样本量以达到统计显著性，最大限度地减少假阳性或假阴性的风险。
防止交叉污染（例如，用户在单次会话中在版本之间切换）以保持结果的完整性。
监控短期和长期影响，因为某些变更可能会产生快速收益但引入长期问题。

定性审查仍然很重要：例如，版本 B 的完成率下降可能反映了更深入、更周到的参与——而不是彻底的失败。

然而，当智能体存储长期交互状态（如聊天历史记录或持久用户上下文）时，A/B 测试可能会更加困难，因为如果用户在会话之间被重新分配到不同版本，可能会产生不一致。为了缓解这种情况，团队可以实施“粘性”用户分配（确保用户随时间推移保留在同一变体中），在会话级别而不是用户级别进行测试，或者隔离状态管理以防止跨版本污染——可能通过为每个测试组复制或版本化状态存储。

现代实验平台（例如 LaunchDarkly、Optimizely 或自定义仪表板）自动化了大部分流量分配、指标收集和分析工作，使团队能够专注于解释结果并根据见解采取行动。

贝叶斯老虎机 (Bayesian Bandits)

如果您的 A/B 测试可以即时学习，在实验中期将用户转移到成功的变体，而不是僵化地分割流量，那会怎样？这就是自适应实验的力量，其中贝叶斯老虎机 (Bayesian Bandits) 作为多智能体系统的智能升级脱颖而出——动态平衡探索（尝试新想法）与利用（坚持有效的方法），以在不可预测的环境中加速改进。

想象一台有多个拉杆的赌场老虎机，每个拉杆提供未知的支付几率。在贝叶斯老虎机中，每个拉杆代表一个系统变体——比如用于智能体查询处理的替代提示或多智能体群中不同的编排策略。随着交互的展开，算法观察奖励（例如，成功的任务解决、更低的延迟或更高的用户评分），并使用贝叶斯更新来细化其对每个拉杆性能的信任度。随着时间的推移，它将更多流量输送到有希望的拉杆，同时少量测试其他拉杆，确保您不会错过隐藏的宝石。

举一个具体的智能体示例，假设你正在优化一个 SOC（安全运营中心） 多智能体系统，测试三个用于解决模糊威胁查询的推理链。老虎机算法开始时均匀分配，但随着数据的涌入，假设其中一个链将威胁分类准确率提高了 15%。它会将 70% 的查询重新分配到那里，同时仍然探测其他链以发现用户行为的变化。这在多智能体设置中特别有效，因为交互可能计算成本高昂，或者仅在负载下才显示出涌现行为。事实上，像知识感知贝叶斯老虎机 (KABB) 这样的框架将其扩展到动态协调专家智能体，利用语义洞察来选择子集以执行知识密集型查询等任务。贝叶斯老虎机的一些主要优势包括：

响应性： 系统近乎实时地学习并转移流量分配，降低机会成本并加速改进。
效率： 绝大多数用户一旦识别出最佳性能配置，就会立即体验到它，而不是在次优变体上“浪费”同等流量。
可扩展性： 设计良好的贝叶斯老虎机系统可以扩展到大量参数，从而比配置和审查一系列固定实验能够更快速地探索行动空间。

然而，自适应实验也需要：

指标精准： 奖励必须反映真实的系统目标（例如，用户满意度、任务成功），以避免针对误导性的指标进行优化。
深思熟虑的初始化： 中立的先验和正则化有助于避免系统过早偏向任何变体。
警惕的监督： 团队必须注意病态的反馈循环或以牺牲长期目标为代价利用短期趋势的情况。

贝叶斯老虎机在流动、数据丰富的智能体世界中大放异彩——想想推荐智能体中的实时个性化或自主团队中的自适应工作流——提供比传统方法更快、更智能的演进。

持续学习 (Continuous Learning)

我们现在转向持续学习，在这里，智能体系统被设计为根据现实世界的交互、反馈和不断变化的用户需求，随时间推移进行适应、改进和优化性能。与静态模型或预先编写脚本的工作流不同，持续学习智能体旨在接收新数据、细化其行为并动态更新推理策略。这个过程将自动适应与精心管理的监督相结合，以防止意外后果，例如对短期趋势的过拟合或引入退化。

持续学习包含两个核心机制：上下文学习 (In-context learning) 和在线学习 (Online learning)。这些机制能够在不同尺度上实现改进——从会话内的实时微调到跨工作流的增量更新。正如第七章所讨论的，这些建立在基础非参数技术（例如范例检索、Reflexion）之上，并可以在适当的情况下结合参数方法（如微调）。在这里，我们要强调将它们集成到改进循环中，使用实时生产数据（例如用户交互、遥测和故障日志）来收紧循环：反馈管道显现问题，实验验证修复，持续学习嵌入它们以产生即时或持续的影响。

上下文学习 (In-Context Learning)

上下文学习为基于基础模型的系统提供了最直接、最灵活的适应手段。上下文学习不依赖于模型微调或架构变更，而是赋予智能体在单个会话中动态修改其行为的能力。通过将示例、中间推理步骤或上下文信号直接嵌入到提示中，智能体可以即时被“教导”新行为——在运行时适应，而不是仅依赖静态的预训练权重。

考虑一个协助用户进行代码调试的智能体。如果智能体在某种特定类型的错误上持续挣扎，工程师可以修改提示以包含一个演示正确解决方案的说明性示例。此更改立即生效，仅限于当前会话，使智能体能够在不需要更广泛系统再训练的情况下改进其响应。此外，智能体可以实时利用用户反馈——例如更正或澄清——来进一步细化其推理并在同一次交互中调整其后续步骤。上下文学习的主要优势包括：

针对用户的适配： 根据个人用户偏好或反复出现的问题定制响应，提供个性化体验。
实时反馈整合： 动态调整行为以响应用户的澄清或后续指令，增强响应能力。
引导式推理： 集成显式推理步骤或中间输出，以引导智能体得出更可靠或可解释的结论。

有效上下文学习的一个关键推动因素是稳健的上下文管理。由于基础模型的上下文窗口有限，系统必须仔细筛选要在提示中包含哪些信息、如何构建它，以及何时删除或压缩过时的细节。诸如滚动上下文窗口、语义压缩和基于向量的记忆检索等技术有助于确保最相关的信息在整个交互过程中保持可访问。

然而，上下文学习具有固有的局限性。在会话中所做的更改是短暂的——一旦会话结束，任何学到的适配都会丢失。为了保存有价值的见解以供将来使用，成功的上下文策略应被升级为更持久的机制，例如提示工程、工作流更新或完整的模型再训练。

在实践中，上下文学习通常作为适配的第一道防线——能够在实时交互中对改进进行快速、低风险的测试。在将这些方法编纂成更广泛的工作流或在全系统范围内合并之前，它充当新推理策略或提示结构的试验场。这使得上下文学习对于处理特定于会话的故障、快速迭代小的细化，或解决传统方法可能失效的高度动态和不可预测的用户输入特别有用。

上下文学习的优势在于其即时适应性、最小风险以及提供会话级个性化和实时细化的能力。然而，这些适应本质上是暂时的；所做的任何更改范围有限，并且一旦会话结束就不会持久。因此，虽然上下文学习非常适合快速原型设计细化和响应不断变化或不可预测的用户需求，但源自这些交互的有价值见解最终必须通过提示工程、工作流更新或模型再训练来形式化，以实现持久的改进。

在深思熟虑地集成到持续学习管道中时，上下文学习不仅提供了即时改进的强大机制，而且为可扩展的、长期的系统优化奠定了重要基础。

离线再训练 (Offline Retraining)

离线再训练代表了一种结构化的、定期的方法，利用来自反馈管道和实验的累积数据，将持久的改进嵌入到智能体系统中。与受限于会话的上下文适应不同，离线再训练涉及收集成批的交互数据——例如用户查询、智能体输出和标记的结果——并使用它们在受控的非生产环境中更新提示和工具，甚至微调底层模型。这种方法特别适合解决随时间推移发现的系统性问题，例如推理或工具使用中反复出现的偏差，而不会干扰实时操作。

在 SOC 智能体示例中，假设反馈揭示了由于攻击向量演变导致威胁分类中出现假阳性模式。团队可以将历史日志和注释聚合到数据集中，然后使用 DSPy 等框架优化提示或在基础模型上微调轻量级适配器（如第七章所讨论的）。该过程通常遵循以下步骤：

数据整理 (Data curation)： 从生产追踪中收集并标记示例，确保多样性和平衡以避免偏见。
模型更新 (Model updates)： 在留出数据上应用少样本优化 (Few-shot optimization) 或全微调等技术，关注准确性或延迟等指标。
验证 (Validation)： 离线对照基准测试再训练的组件，然后通过影子部署在发布前进行测试。

主要优势包括：

持久性： 更改跨会话、跨用户持久存在，提供与不断变化的环境的长期一致性。
可扩展性： 批量更新对于高容量系统效率很高，使团队能够合并大型数据集而无需实时开销。
风险缓解： 离线性质使得可以进行彻底测试，减少退化的机会。

然而，离线再训练需要仔细管理，防止对历史数据的过拟合或忽略新兴趋势。局限性包括计算成本（尽管可以通过 LoRA 等高效方法缓解）以及需要定期调度以保持模型新鲜。它最好用于基础性细化，例如用新的威胁示例更新 SOC 智能体的提示或在最近的日志上重新训练工具分类器。

在与反馈和实验集成时，离线再训练通过将见解转化为持久的增强来闭合改进循环。对于依赖预训练模型的团队来说，它提供了通往定制化的桥梁，无需持续的在线调整，确保智能体随时间推移稳健进化。

结论

持续改进不仅仅是多智能体系统的一个特性——它是其长期成功的基本要求。随着这些系统变得越来越复杂，与不同的用户交互，并在不断变化的环境中运行，它们适应、学习和自我细化的能力对于保持可靠性、性能和与用户需求的一致性变得至关重要。本章探讨了持续改进的关键支柱：反馈管道、实验和持续学习，每一项都在推动迭代进步中发挥着独特而相互关联的作用。

反馈管道作为改进循环的诊断引擎，从实时交互中捕获数据，识别重复出现的故障模式，并通过自动化和人工驱动的过程显现可操作的见解。从根本原因分析到聚合和优先处理改进，这些管道为识别什么需要改变以及为什么改变建立了系统基础。

实验框架提供了在全面部署之前验证改进所需的受控环境。影子部署、A/B 测试和贝叶斯老虎机等技术使团队能够最小化风险、衡量影响，并确保每一个变更都对整个系统做出积极贡献。

最后，持续学习确保改进不仅仅是孤立的补丁，而是将适应性直接嵌入到系统的行为中，重点关注上下文学习，它提供了即时的、会话级的细化。

至关重要的是，这些组件都不是孤立运行的。反馈循环汇入实验工作流，这反过来又指导微调再训练。自动化管道加速洞见生成，而人工监督确保变更与战略目标保持一致。文档作为这些过程之间的结缔组织，保存组织记忆并实现跨团队协作。

持续改进不是一个线性过程——它是一个观察、调整、验证和部署的持续循环。随着多智能体系统越来越深入地集成到关键工作流中，稳健的反馈机制、设计良好的实验和自适应学习过程的重要性只会增加。投入到这些能力的组织不仅会减少故障并提高可靠性——它们还将解锁预测用户需求、响应新兴趋势并在规模上交付有意义创新的能力。

归根结底，持续改进既关乎系统设计，也关乎组织文化。它需要一种心态，即不把每一次失败视为挫折，而是视为一个信号——一个学习、迭代和进化的机会。通过构建能够观察自身、从自身行为中学习并有意适应的系统，团队可以创建不仅能运作，而且能蓬勃发展的智能体生态系统。

翻译整理自Building Applications with AI Agents一书，仅供学习交流使用

反馈管道 (Feedback Pipelines)

自动问题检测与根本原因分析

人机协同审查 (Human-in-the-Loop Review)

提示与工具细化 (Prompt and Tool Refinement)

提示细化 (Prompt Refinement)

工具细化 (Tool Refinement)

聚合和优先处理改进

实验 (Experimentation)

影子部署 (Shadow Deployments)

A/B 测试 (A/B Testing)

贝叶斯老虎机 (Bayesian Bandits)

持续学习 (Continuous Learning)

上下文学习 (In-Context Learning)

离线再训练 (Offline Retraining)

结论

Hi，您需要填写昵称和邮箱！