构建 AI 智能体应用（六）：持续改进循环 (Improvement Loops)

Improvement Loops（Photo by Alvin Leopold on Unsplash）

系列导读: 本文是《Building Applications with AI Agents》系列解读的第六篇。
第一篇：核心架构模式演进
第二篇：工具选择策略与 MCP
第三篇：多智能体协作与编排
第四篇：验证与测量
第五篇：生产监控与可观测性
本篇将聚焦于如何构建改进循环 (Improvement Loops)，把线上的每一次交互都转化为系统进化的养分。

1. 总体框架与核心理念

1.1 什么是“改进循环”

改进循环不是某个单点技术（比如“调 prompt”或“加向量库”），而是一套可重复、可度量、可治理的工作流。它回答三个核心问题：

我们如何稳定地“看见”系统在生产中的真实表现？
我们如何把问题从“症状”推进到“根因”，并转化为可执行的改动？
我们如何证明改动是正向的、没有引入回归，并且可持续运转？

一个最小可行闭环（Minimum Viable Improvement Loop）通常长这样：

Minimum Viable Improvement Loop

Observe：采集 traces / 日志 / 指标 / 反馈
Diagnose：聚类问题、做根因分析（RCA）
Decide：形成改进 backlog，并做优先级排序
Change：实施改动（prompt / 工具 / 工作流 / 模型）
Validate：离线评测 + 线上实验（shadow / canary / A/B）
Deploy：逐步上线 + 自动回滚策略
Monitor：持续监控 + 将新信号重新纳入 Observe

闭环成立的前提不是“每次都能改对”，而是“每次都能学到，并把学习固化为流程”。

1.2 为什么“失败 = 信号”

在 agent 系统里，失败可能来自很多层：

意图理解偏差：用户想要 A，系统理解成 B
推理链偏差：中间步骤走偏导致最终结果错误
工具选择错误：选错工具或漏掉关键工具
工具参数错误：调用参数格式不合法、范围不对、缺少鉴权
外部环境变化：数据源 schema 变化、接口限流、业务规则变化
目标函数错配：指标让系统“看起来更好”，但用户体验更差

改进循环的关键价值在于：把这些失败从“线上噪声”变成“结构化样本”，并通过可观测性把失败映射到具体的改动点。

1.3 改进不仅是技术问题，也是组织问题

原文强调的一个现实是：改进循环需要跨团队对齐。工程/数据/产品/UX/安全要共同约定：

什么叫“成功”（主指标）与“不可接受”（护栏指标）
哪些变更必须走实验、必须走人工审批
变更要如何记录、如何回滚、如何追溯

没有组织机制与治理基线，技术闭环会退化成“有人想起来就调一调”的手工工艺。

1.4 2026 的工程化关键词：Observability 与 Governance

Observability（可观测性）

可观测性不是“有日志”，而是“能回答问题”。对于 agent 系统，核心是把一次任务的全过程串起来：

输入：用户请求、上下文、检索结果
过程：模型输出、思考步骤（如果保留）、节点流转、工具调用与返回
输出：最终答复/动作、结构化结果
结果：是否成功、耗时、成本、用户反馈、人工评审结论

Governance（治理）

治理关注“什么可以自动改、什么必须人工把关、出了问题怎么止血”。2025–2026 的主流做法是把治理能力内嵌到闭环中：

变更分级：低风险自动化 vs 高风险强制审批
生产护栏：权限控制、速率限制、敏感操作确认
回归防护：离线基准 + 线上护栏 + 自动回滚

2. 反馈管道（Feedback Pipelines）

反馈管道是闭环的“诊断引擎”。它要完成两件事：

把生产交互转换成结构化证据（trace、事件、评测结果、人工标注）
把证据变成可行动洞察（问题聚类、RCA、改进建议、优先级）

2.1 自动化反馈与可观测性：你需要采集什么

建议将采集分成四类信号：

轨迹（Traces）：一次请求的完整执行链路（节点、模型调用、工具调用、重试、异常）
事件（Events）：关键业务事件与状态变化（成功/失败、升级到人工、触发回滚）
指标（Metrics）：可聚合的数值指标（成功率、延迟、成本、幻觉率、升级率）
样本（Examples）：可用于评测与训练的数据切片（输入、上下文、输出、期望、评审结果）

一个常见误区是：只收“最终输出与错误日志”，缺少中间过程，导致 RCA 只能停留在“猜”。

2.2 自动化问题发现：从“看见异常”到“看见模式”

自动化检测通常结合三种方法：

规则触发：已知错误模式（例如某类工具参数缺失、鉴权失败）
异常检测：错误率/延迟/成本的突增或趋势漂移
聚类与统计：把相似失败聚成簇，快速判断“是否系统性问题”

你最终希望得到的是“可优先级化的问题簇”，而不是一堆散乱的日志。

2.3 根因分析（RCA）：在 agent 系统里要怎么做

RCA 的目标不是“找到一个背锅点”，而是建立可复用的解释链：

Workflow tracing：重建端到端链路（输入→推理→工具→输出）
Fault localization：定位故障点（prompt、路由、工具、外部依赖、数据质量）
Pattern recognition：判断是偶发还是系统性（与特定输入/用户/版本/环境相关吗）
Impact assessment：量化影响（频率、严重度、业务风险、合规风险）

一个实用的分层定位框架是：

L0：基础设施（超时、限流、网络、依赖不可用）
L1：工具层（工具缺失、参数格式、权限、返回结构变化）
L2：编排层（工作流路由错误、状态污染、重试策略不当）
L3：认知层（意图误判、推理偏差、事实性错误、幻觉）
L4：目标层（指标错配、激励错配、治理缺失）

2.4 评估器体系：LLM-as-Judge + 领域评估器

LLM-as-Judge 是什么

LLM-as-Judge 指用一个（通常更强或专门配置的）模型来对输出打分/点评。它的价值在于：

能覆盖“非结构化质量”（是否答非所问、是否有逻辑漏洞、是否风格合规）
能把大量样本快速转换成粗粒度评估信号

但它也有风险：

评估偏差：judge 的偏好不等于用户偏好
自嗨一致性：同一模型体系内部更容易“互相认可”
可被优化投机：系统学会迎合 judge，而非满足真实目标

领域评估器（domain-specific evaluators）

在可行时，优先引入可验证的领域评估器，例如：

结构化输出校验：schema/约束/一致性检查
代码/SQL：编译/单测/静态检查/执行结果
检索问答：引用一致性、证据覆盖度
安全：敏感信息泄漏检测、策略合规检测

实践中常用组合是：

领域评估器做硬约束（hard constraints）
LLM-as-Judge 做软质量（soft quality）
两者共同构成“主指标 + 护栏指标”

2.5 人类在环（HITL）：分级升级而不是“全人工”

HITL 的核心不是“引入人工”，而是“让人工只处理最值得处理的部分”。两类典型触发条件：

低确定性：模型自己不确定、或多次采样分歧大
高后果：操作影响大（安全隔离、资金交易、合规敏感）

一个常用的策略是“风险得分 = 不确定性 × 后果严重度”，超过阈值则升级。落地上要配套：

明确升级队列与 SLA
评审结论结构化（可回写到评测/数据集）
审批与回放能力（能看见完整 trace 与证据）

2.6 Prompt 与 Tool 改造：把洞察变成变更

反馈管道最终要落到可操作的改动点，常见三类杠杆：

Prompt 改造（高性价比，但要防回归）

常见改法包括：

明确约束与输出格式（减少歧义）
增加正反例（锚定边界）
分解步骤（把多步任务拆成可控子任务）
引入失败处理与升级规则（不确定时怎么做）

Tool 改造（提升可靠性与安全性）

典型收益在于：

参数校验与自动修复（减少“格式错误”类失败）
幂等与可重放（便于 shadow 与回放）
输出结构化与稳定契约（让后续节点不崩）
把高风险动作变成“需要确认”的工具

编排/路由改造（减少系统性偏差）

例如：

为特定输入类型引入专用路径（高风险走更保守策略）
重试与退避策略（外部依赖不稳定时）
状态隔离（避免跨会话污染）

2.7 自动化 Prompt 优化：DSPy 与 MIPROv2 的工程定位

当你不想靠手工反复调 prompt，而希望“用数据驱动 prompt 迭代”，可以引入自动化优化框架。以 DSPy 为例，它把 LM 应用看作可组合模块，并提供优化器来基于数据与指标自动改进提示词与少样本示例。

在 DSPy 的表述里，MIPROv2（Multiprompt Instruction Proposal Optimizer v2）是一类 prompt 优化器，它可以联合优化：

instructions（指令本身）
few-shot examples（少样本示例）

并通过候选生成与搜索（包含 Bayesian Optimization）来找到更优组合。工程上，它更像“编译器”：输入是程序/模块、训练样本与评价指标，输出是一个在该指标上更优的程序版本。

重要提醒：自动化优化不是“自动上线”。它应该接入你的实验平台与回归防护，尤其要关注：

指标是否代表真实目标（避免优化投机）
是否引入了成本/延迟回归
是否在关键人群/关键场景上变差

2.8 聚合与优先级：把反馈变成路线图

当问题簇变多后，必须引入聚合与优先级机制，否则团队会被噪声淹没。一个实用的优先级框架是：

频率（Frequency）：发生得多吗
严重度（Severity）：影响大吗（安全/合规/资金/信任）
可行性（Feasibility）：改动成本与风险
战略对齐（Alignment）：是否支撑关键业务目标

把它落到一个统一 backlog，并为每个条目绑定：

证据链接（trace、样本、评测）
根因标签（prompt/tool/编排/依赖/目标）
回归风险与验证计划

3. 实验验证（Experimentation）

实验验证是“安全进步的桥梁”。因为 agent 系统强耦合、涌现行为多，哪怕一个小改动也可能引发级联影响。实验体系的目标是：

在尽量真实的条件下评估改动
控制风险，把损害限制在可控范围
让“上线”成为一个可回滚、可复盘的过程

3.1 低风险部署策略：shadow / canary / rolling / blue-green

Shadow deployment（影子部署）

新版本在生产输入上并行运行，但输出不对用户生效，只做记录与对比。适合：

高风险逻辑变更（路由/工具链/规划策略）
需要真实数据分布才能暴露的问题

关键要求：

可重放与可对比（相同输入、稳定上下文）
输出对齐指标（质量、延迟、成本、护栏）
交互型流程要做模拟（shadow 无法真正“问用户”）

Canary / rolling / blue-green

Canary（金丝雀）：小流量先上，观察护栏指标
Rolling（滚动）：逐实例升级，降低整体风险
Blue-green（蓝绿）：双环境切换，回滚更简单

选择逻辑通常由“风险等级 × 系统架构可切换性 × 状态依赖程度”决定。

3.2 A/B 测试：从工程分流到统计结论

A/B 测试用于把“感觉更好”变成“证据更好”。它需要三件事：

明确指标：任务成功率、用户满意度、幻觉率、延迟、成本
避免污染：用户/会话被随机切换会导致体验不一致与统计偏差
控制状态：agent 有长期状态时更复杂

Sticky session（粘性分流）与状态隔离

如果用户跨会话需要保持一致体验，通常要做“粘性分流”（同一用户始终在同一组）。同时要避免状态污染：

组 A 与组 B 使用隔离的 state store
或对 state 做版本化（带版本号写入/读取）

指标设计：主指标与护栏指标

主指标回答“是否更好”，护栏回答“有没有变坏得不可接受”。例如：

主指标：任务成功率、用户留存/满意度
护栏：安全违规率、幻觉率、成本、P95 延迟、升级率

3.3 自适应实验：Bayesian Bandits（贝叶斯老虎机）

当你希望实验“边跑边学”，而不是固定 50/50 分流，bandit 是典型选择。它把不同版本看作多个“臂”，根据在线奖励信号动态分配流量，在探索（继续试新版本）与利用（多给更优版本）之间平衡。

落地关键点是“奖励设计”：

奖励必须与真实目标一致，避免优化代理指标
奖励要与护栏联动，防止短期收益换来长期风险

适用场景包括：

多版本 prompt/路由策略的持续优化
个性化与动态环境（用户分布不断变化）

3.4 回归防护：上线不是终点

建议把回归防护写成生产级机制：

离线基准：固定测试集与关键场景集
线上护栏：质量、安全、成本、延迟的阈值与报警
自动止血：触发阈值后自动回滚到稳定版本
可复盘：回滚必须绑定原因与证据，回写 backlog

4. 持续学习（Continuous Learning）

持续学习的目标是让系统在变化中保持适应力，但同时避免“越学越歪”。它通常分三层：

会话内适应：in-context learning（即时、低风险、但不持久）
中短期固化：把有效策略固化到 prompt/工具/工作流
长期更新：离线重训与对齐（持久，但风险与成本更高）

4.1 In-Context Learning：会话内即时适应

in-context learning 指在不更新模型参数的情况下，通过把示例、约束、记忆片段写入上下文，让模型在当前会话中“学到”更合适的行为。

典型用途：

用户偏好与风格（输出格式、语言、严谨程度）
任务局部规则（业务约束、临时策略）
纠错与澄清（用户指出错误后立即修正下一步）

核心工程难题是“上下文管理”：

rolling window：滑动窗口保留最新关键信息
语义压缩：把冗长历史压缩成可用摘要
向量检索记忆：把长期信息存储为可检索片段，再按需注入

关键原则：

只把可复用且高价值的信息写入长期记忆
将“事实”与“偏好”分离存储与注入，减少污染

4.2 Reflection 与自精炼：让系统从轨迹中学

reflection（反思）类方法的核心是：把一次任务的执行轨迹当作学习对象，通过自评与修正来提高下一次表现。常见形态包括：

Self-Refine：先生成，再批判，再改写
Reflexion：对失败案例总结“可复用教训”，并在后续注入
ReAct：在推理与行动（工具调用）之间交替，便于定位失败点

工程上要把反思“产品化”，否则容易变成无成本控制的多轮生成：

仅对高价值/高风险任务开启多轮自精炼
将反思结果结构化（规则、示例、边界条件）
与评测指标绑定，确保反思带来可测改进

4.3 离线重训与对齐：把改进变成持久能力

离线重训（offline retraining）通常包括：

数据策展：从生产 trace 中抽样、去隐私、打标签、平衡分布
模型更新：轻量适配（例如 LoRA/QLoRA）或偏好对齐（例如 DPO/GRPO 等）
验证与上线：离线评测 → shadow → canary → 全量

2025–2026 的一个重要趋势是：更强调“可验证目标”与“评测先行”。原因很简单：如果你无法稳定评估，就无法稳定学习。

风险清单：

过拟合：只对历史数据变好，对新分布变差
回归：某一类任务变好，另一类关键任务变坏
目标偏移：模型学会迎合评估器而非满足用户真实需求

4.4 记忆与技能演化：持续学习的“系统层”问题

当 agent 具备长期记忆与可扩展工具集时，持续学习会进入“系统演化”阶段：

记忆更新策略：什么时候写入、什么时候遗忘、如何防止错误记忆固化
技能集管理：新工具上线如何发现、如何评测、如何灰度启用
灾难性遗忘：新能力提升是否导致旧能力退化

治理建议：

为记忆写入设置强约束（来源可信、可追溯、可撤销）
为工具引入契约测试（输入/输出稳定性与安全性）
定期回归评测（覆盖关键能力与关键人群）

5. 高级/新兴闭环模式（2025–2026）

5.1 Autonomous Retraining Loop：完全自主改进闭环

理想形态是把“发现问题→生成修复→验证→上线”做成半自动甚至全自动流水线，但必须强调前提：

有强可观测性：能知道哪里坏、为什么坏
有强评测：能验证“真的变好”
有强治理：能限制自动化变更的风险面

在高风险领域，更现实的做法是“自动提案 + 人工审批 + 自动验证”。

5.2 Verifiable Reward：只在可验证结果领域实现可靠自进化

“可验证奖励”指奖励信号来自可重复、可客观判定的验证过程，而不是主观打分。它在以下领域特别强：

代码生成：能编译、能过测试、能满足静态规则
数学推理：答案可校验、步骤可核验
结构化任务：输出满足 schema 与约束、可执行并得到确定结果

为什么“只在可验证结果领域可靠”：

因为闭环需要高质量反馈信号；在不可验证的任务里，奖励噪声大、偏差大，系统更容易学到投机策略或被评估器偏好带偏
在可验证领域里，反馈更接近“事实”，更适合自动化优化与强化学习式更新

工程化结论：

优先把高风险、强约束场景改造成“可验证任务”（可验证的子目标、可验证的中间产物）
把不可验证部分交给 HITL 或更保守策略

5.3 Multi-Agent Self-Improvement：多代理协作自优化

多代理系统的改进闭环通常比单体更难，因为问题可能出在：

分工与协议：谁负责什么，交接标准是什么
信息共享：共享过多导致污染，共享过少导致重复与盲区
一致性：多个代理给出冲突结论时如何裁决

实践建议：

先定义协作协议与产物格式，再谈优化
用“群体评测”覆盖协作路径（不仅评单代理输出）
为一致性引入裁决机制（投票、critic、可验证子任务）

6. 组织与工程最佳实践（2026）

6.1 生命周期管理：把 agent 当成长期运行的软件系统

建议将 agent 生命周期写成明确流程：

设计：目标、边界、指标、风险等级
构建：工作流、工具、权限、数据与评测集
测试：离线评测、红队、回归
部署：shadow/canary/蓝绿、回滚预案
监控：质量、安全、成本、漂移、升级率
优化：进入闭环，沉淀知识库

6.2 安全底线：最小权限、最小暴露、持续红队

agent 的安全性不只在模型层，也在工具层与编排层。典型基线包括：

最小权限：工具按任务授予最小必要权限
最小暴露：避免把敏感上下文无差别注入模型
高风险操作确认：将“写操作”工具化并强制确认
持续红队：定期对抗测试提示注入、数据外泄、越权调用

6.3 文档即系统：可追溯的改进历史

闭环要能“传承”，必须把改进过程写下来：

观察到什么问题（证据）
为什么这么判断（根因）
改了什么（变更）
怎么验证（实验）
结果如何（指标）

把它做成知识库，会显著降低重复踩坑与新人上手成本。

6.4 度量与成功标准：生产评估管道是核心资产

建议将指标分三层：

业务层：任务完成率、转化、用户努力降低
系统层：延迟、成本、稳定性、回归发生率
治理层：升级率、违规率、风险事件数量、回滚次数

把评估管道内嵌到生产，是 2026 之后系统能否持续进化的分水岭。

附录 A：术语表（中英对照）

Improvement Loops（改进循环）：围绕“观测→诊断→变更→验证→上线→监控”的持续闭环体系
Feedback Pipelines（反馈管道）：把生产交互转为洞察与改进 backlog 的系统
Observability（可观测性）：能用数据回答“系统为什么这样表现”的能力，而非仅有日志
Governance（治理）：对风险变更的分级控制、审批、护栏、回滚与追溯机制
Trace / Tracing（轨迹/追踪）：把一次请求的全链路执行串起来的记录
RCA（Root Cause Analysis，根因分析）：从症状定位到可复用解释链的过程
HITL（Human-in-the-Loop，人类在环）：对高风险/低确定性案例的人工升级处理机制
LLM-as-Judge：用模型对输出质量进行打分/点评的评估方式
Shadow Deployment（影子部署）：并行运行新版本但不影响用户输出
Canary（金丝雀发布）：小流量先上、观察护栏后再扩大
Blue-Green（蓝绿发布）：双环境切换，便于快速回滚
A/B Testing：流量随机分组对比效果的实验方法
Sticky Session（粘性会话）：同一用户/会话固定进入同一实验组，避免污染
Bayesian Bandits（贝叶斯老虎机）：在线自适应分配流量的实验方法
In-Context Learning：通过上下文注入实现会话内即时适应
Reflection（反思）：基于执行轨迹总结教训并改进下一次行为
DSPy：用模块化方式构建 LM 程序，并用数据驱动优化提示词/示例的框架
MIPROv2：DSPy 中可联合优化 instructions 与 few-shot 的 prompt 优化器
Verifiable Reward（可验证奖励）：来自可客观验证过程的奖励/反馈信号

附录 B：从 0 到 1 的落地清单

定义目标与风险等级（哪些必须人工、哪些可自动）
搭建可观测性（traces + 指标 + 样本回放）
建立评测体系（主指标 + 护栏指标，离线可跑）
上线 shadow 路径（同输入对比，先不影响用户）
建立问题聚类与 RCA 流程（形成统一 backlog）
建立实验平台（A/B、粘性分流、状态隔离）
建立回归防护（护栏阈值、报警、自动回滚）
建立知识库与变更追溯（每次改动可复盘）
迭代机制固定化（定期 triage、跨职能同步）

附录 C：指标与护栏模板

C.1 主指标（Outcome Metrics）

任务成功率（Task Success Rate）
用户满意度/评分（CSAT）
用户努力降低（例如追问次数、人工介入次数）

C.2 护栏指标（Guardrails）

安全违规率（敏感信息泄漏、越权工具调用）
幻觉率（无证据断言、引用不一致）
成本（每次请求 tokens/费用、工具调用成本）
延迟（P50/P95/P99）
升级率（HITL 负载是否可控）

C.3 变更验证最小集合

离线回归：关键场景集 + 随机抽样集
线上 shadow：质量/成本/延迟的对比
线上 canary：护栏阈值 + 自动回滚