自我提升智能体：修复、学习与可控变革
在LangGraph上实现的无需担忧自我改进的智能体：运行时自我修复、跨运行学习，以及仅在评估和金丝雀测试通过后才应用的变更。
来源: Self-improving Agentic AI Applications — Feedback loop integration
ReAct风格的智能体能够做好规划、调用工具、获取信息，并完成多步骤任务。但问题在于当它投入实际使用后，如果出现错误，人们会追问该如何处理。它能否察觉到问题？能否在不重新启动整个工作流程的情况下恢复？能否记住哪些方法有效，从用户的修正中学习，进而改进自身的行为？
人们将这些问题统称为“智能体反馈循环”，但这个称谓具有误导性。下图所示的架构将LangGraph与MongoDB、Vertex AI上的Gemini以及Arize Phoenix相结合，实现了运行时恢复、从经验中学习、持续评估以及可控的改进功能。
为何简单的反馈循环很危险
人们通常认为的反馈循环其实很简单：
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
它的吸引力在于简单，但同时也充满风险。当大型语言模型自我评估其输出并立即调整后续行为时，一个错误可能变成教训，教训可能转化为记忆，而这种记忆又会影响后续成千上万的决策。
更安全的设计基于不同的原则：智能体修复当前的执行结果，平台通过多次执行进行学习，而控制层则决定哪些行为会被纳入正式使用。
举个具体例子：某个智能体负责推荐薪资发放或扣款代码。有一次它选错了代码，因为没有获取针对该状态的薪资政策。这种简单的学习流程如下：
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
这方面可能会出现多种问题。诊断结果可能错误。该规则可能仅适用于某一类型的薪资交易。后续的政策变动可能会使该经验变得过时。恶意用户输入可能会影响分析结果。而且该经验可能在某些情况下有效，却在其他情况下适得其反。
因此，更好的设计是将该经验视为假设而非事实。
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
这种变化十分微妙。智能体并不会不断自我重写，而是其所在的平台在持续评估并改进它。
具有不同权限的三个层面
可以想象由三个相互关联的层面来辅助理解。
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
每个平面以不同的速度运行，并拥有不同的权限级别。运行时平面在毫秒或秒级时间内工作，其唯一任务就是可靠地完成当前请求。学习平面会分析数分钟、数小时乃至数天内的多次运行数据，从而判断汇总后的证据表明了什么。控制平面则负责判断某个拟议的改进是否足够安全，可以纳入实际运行中。在自适应智能体平台的设计中，没有什么比将这三个平面分开更为重要的了。
1. 运行时自愈
从最紧迫的问题入手：某个工具调用失败了。简单的实现方式只是重新尝试。
Tool failed
↓
Retry
↓
Retry
↓
Retry
不过，重新尝试并不能实现自动修复。要实现修复，必须先明确究竟是什么出了问题，并选择合适的恢复策略。更完善的 LangGraph 工作流程应更接近于此：
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
该图表中的几个观点值得关注。
行动前先进行验证
想象一个能够执行会产生副作用的操作的智能体：更新员工数据、创建薪资扣款、提交交易、修改账户或发送通知。事后检查结果为时已晚。该架构需要在任何可能带来后果的更改之前设置操作防护机制。该机制会综合考虑权限、业务规则、现有证据、操作是否可逆、风险等级以及是否需要人工审批。只有满足这些条件，工具才能运行。
这重新定义了验证的意义。问题不再是从“操作是否正确？”，而是转变为更为安全的“我们是否有足够的证据和权限来批准此操作？”
工具的输出同样不可信
还有另一个风险被忽视了。智能体会读取来自网站、文档、API、搜索引擎、数据库以及其他智能体的内容，这些材料会进入大语言模型的上下文之中。因此，工具的返回结果也成了提示注入的又一途径，所以在工具执行与推理之间必须设置一个确定的工具结果净化器。
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
典型的安全过滤功能包括强制规定输出类型与长度、拒绝格式错误的结构、对可能具有指令性质的文本进行转义，以及标记可能的注入尝试。有一条严格的规定：绝不能使用大型语言模型来检查可能具有攻击性的文本。
将验证器与评估器分开
一种常见的做法是在每次请求时都让大型语言模型判断“这个答案正确吗？”。这不仅会增加延迟和成本，还会赋予模型过大的权限。应当首先进行确定性验证，例如：
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
如果软件能够证明某个答案是错误的，就没有必要再询问其他模型。只有真正的语义歧义才会传递给批评器，即便如此，批评器也不会掌控工作流程。它的作用仅限于诊断，大致如下：
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
确定性策略路由器随后从四种结果中选择一种：
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
分工十分明确：大语言模型负责提供证据与判断，而软件策略则拥有决策权。
修复应当改变策略
只有当情况有所不同时，重试才有意义。以执行此操作的智能体为例：
Search policy
↓
Generate recommendation
↓
Fail validation
如果修复仍使用相同的查询、相同的证据以及相同的推理方式重复上述流程，那便不是恢复，而是重复而已。
Search policy
↓
Generate recommendation
一个强大的代理会监控几个字段。
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
这时就适用一条简单的规则。
same failure
+
same strategy
+
same evidence
=
do not retry
每当相同的故障再次遇到相同的处理策略时，代理应更换策略、转交给人工处理或安全地失败。仅靠retry_count无法解决这一问题，因此生产环境中的自愈功能需要修复预算。这些预算可以限制大语言模型调用、工具调用、耗时、成本以及语义修复尝试的次数。目标并非一直坚持直到问题解决，而是将有限的资源用于真正有效的恢复策略。
确认修复是否有效
不同的尝试仍可能无法带来改善。假设评估者对初始结果进行评分：
quality score = 0.54
首次维修之后：
quality score = 0.55
第二次之后：
quality score = 0.56
从理论上讲这是进步，但实际上却是停滞不前。修复德尔塔门可以解决这个问题。
delta = score_after_repair - score_before_repair
当每次的修复带来的收益微乎其微时，资源就会停止投入。
small delta
+
small delta
=
human review or safe failure
这可以避免最常见的智能体故障之一——那种看似在忙碌实则几乎毫无成效的昂贵推理循环。
人工审核是一种决策方式
人工审核不应被视为故障。对于某些任务而言，它本身就是最恰当的最终决策。而且“人工审核”涵盖多种不同的结果。
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
每种结果的发展路径各不相同，因此都应在图表中明确显示。LangGraph的中断与恢复机制非常适合这种情况，因为工作流可以被保存为检查点、暂停，待审核者回复后再继续执行。
2. 从多次运行中积累经验
运行时修复解决了如何挽救当前请求的问题；而经验学习则探讨该请求能为未来的请求提供哪些启示。这类功能通常在后台运行。一旦智能体给出回复：
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
无需等待某个大型语言模型思考另一个模型可能学到了什么。延迟保持在较低水平，且离线评估的结果也会更加丰富。
反馈并非真相
反馈信号来自多个方面：用户点击向下评价，行业专家修正答案，下游API拒绝某项交易，合规审计在两周后发现错误。这些反馈并不具有同等价值。试想以下第一组不相等的例子：
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
因此，反馈应作为原始证据保存，并按可靠性进行排序，大致如下：
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
这能避免将情感倾向误认为是事实真相。
一些最宝贵的反馈往往出现得较晚
智能体常常启动那些成效无法立即显现的工作流程。
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
有用的信号会在LangGraph运行结束后很久才出现，这意味着每个重要决策都需要有因果关联的追溯路径。应将run_id传递给下游系统，以便后续结果能够追溯到背后的决策。否则，学习系统虽然能知道某件事失败了，但却无法确定是哪个智能体的决策该受表扬还是该受责备。这就是典型的归因问题。
记忆需要管理
一旦智能体在多次运行中不断学习，记忆就会变得既强大又危险。有三类记忆值得区分开来。
- 轮廓记忆存储用户或实体的偏好，比如对简洁解释的偏好。
- 情景记忆记录发生的事件，例如第182次运行失败是因为未能获取状态策略。
程序性记忆对行为的影响最大，因此需要最严格的管控。任何一次失败的运行都绝不能生成可用于生产的程序规则。正确的路径应如下所示：
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
课程设计应以假设、证据、范围、信任度以及生命周期作为框架，而非简单地将文本存储在向量内存中。
学习得到的记忆无法超越权威知识
智能体会检索两类信息。权威知识包括政策、法规、配置、参考数据以及合同中的业务规则；学习得到的知识则包括偏好、经验、先前的策略、观察结果以及经验教训。这两类信息应在逻辑上保持分离，并有合理的优先级顺序：
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
否则，那些被牢固记住的规则可能会悄悄取代实际的政策。
规则会过时
六个月前还有用的方法现在可能已经不对了。政策、产品、API、用户行为以及模型都在不断变化，因此需要对这些规则进行生命周期管理。
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
为每一节课设置验证时间戳，必要时还需规定过期时间或重新验证规则。规则变更可触发对该规则下所有课程的重新评估，从而使这些数据转化为受管控的知识，而非只会不断增长的嵌入向量集合。
3. 离线学习层面
下一层负责整合多次实际运行中收集到的数据证据。
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
假设一周的跑步数据呈现出这样的分布：
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
现在该平台能够识别出哪些问题是系统性的。这与要求某个出错的智能体反思某一次具体的失败操作截然不同。学习模块能够发现其中的规律。
并非所有故障都是提示问题
提示工程并不总是解决方案。如果某个智能体在给出建议前总是忘记获取权威策略，那么在系统提示中添加一条要求其记住的指令或许会有帮助。更有效的解决办法可能是设定结构性规则：
Graph rule:
Policy retrieval must occur before this decision.
其他反复出现的故障可能需要对这些部分进行修改：
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
成熟的优化引擎会提出多个候选修复方案，而不会自动重写提示词。
评估处于核心位置
如果系统能够生成优化方案，却无法判断这些方案是否更好，那就不存在学习循环，只有变异循环。评估是该架构的基石。
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
评估必须涵盖最终答案以及得出该答案的思路过程。两个智能体可能会给出相同的回复。智能体A的作法如下：
Agent A
search -> answer
而代理B正在做这件事：
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
仅从最终答案来看，它们是等价的。但轨迹分析显示显然并非如此。
仅靠一个大型语言模型作为评判者不够
让Gemini生成答案后再让另一个Gemini对其进行评分确实有用，但存在关联误差风险，因为评分者可能具有与生成器相同的缺陷。更可靠的评估方式应结合多种信息来源。
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
LLM评估模型也应定期与人工标注的示例进行对比。这有助于判断在其评分影响哪些内容会被推荐之前，该评估模型的可信度究竟如何。
可观测性是学习的一部分
传统的监控仅关注服务是否正常运行，而智能体可观测性则需要探究智能体为何会做出特定决策。良好的生产环境会记录整个LangGraph执行过程的完整轨迹。
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
每次运行都应具有稳定的标识，以便将多条记录关联起来。
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
这种关联关系正是循环机制的原始素材。可观测性不再仅仅是调试工具，而成为了学习系统的一部分。
为何只读追加事件有助于提升效率
将整个执行过程都存储在同一个 MongoDB 运行文档中固然诱人，起初可行，但规模扩大后就会出现问题。因此应保持运行记录的简洁性。
run_id
agent
release
outcome
latency
tool count
repair count
cost
然后将执行过程记录为只读事件。
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
这能够保持因果顺序，避免文档过度膨胀，简化分布式追踪，并提升故障分析的准确性。
可复现性需要的不只是提示词版本
智能体的行为不仅仅取决于其系统提示词。
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
因此，每次生产批次都应指定一个不可更改的代理版本。从概念上讲：
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
如此一来，失败的运行就可以在之后重新复现。如果没有这个机制，调试工作就会变成询问是哪个版本产生了结果，之后便陷入沉默。
控制平面：改进措施才能获得上线资格
最终，学习系统会发现反复出现的故障并提出改进方案。最糟糕的做法是立即部署这些改进，应当先通过一系列审核流程：
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
在每个阶段，都需要将候选版本与当前版本进行比较。它可能会提升正确性但增加延迟，减少幻觉现象却提高人工干预的需求，或者对某类任务有帮助却对另一类任务产生负面影响。因此，版本升级需要多项约束措施。
教学内容也需要“探针”
长期记忆会带来一个有趣的后果：当新的程序化教学内容被激活并注入未来智能体的上下文时，它们的行为会发生变化，因此注入教学内容实际上等同于改变提示词。这种激活操作应被视为一种实验，而非立即应用于所有符合条件的运行实例。
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
如果该课程降低了性能，就将其回滚。这样一来，内存就不再是一种神秘的适应性机制，而变成了可测量的软件版本。
最终架构
综合起来，这个适应性智能体平台大致如下所示：
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
责任边界被刻意设定得十分明确。运行时代理负责修复执行过程中的问题，学习系统则负责生成假设，而控制层则决定哪些行为值得被信任。
重新思考“自我提升”
听到“自我提升的代理”这一说法时，许多人会想象人工智能会不断重写自身的系统提示词，或在每次对话后进行更新。但对于生产系统而言，这种思维模式是错误的。更正确的理解应是一个循环过程：
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
这里的智能并非仅限于大语言模型，系统的不同组件都承担着智能功能：
- LangGraph 图结构决定了执行顺序。
- 普通代码验证器负责执行已知的规则。
- 大语言模型处理所有模糊不清的情况。
- MongoDB 用于存储状态和积累的经验。
- 追踪模块负责收集相关证据。
- 评估器会对质量进行打分。
- 当风险较高且答案不明确时，由人工做出决策。
- 控制平面负责管理任何行为变化。
这种分布式架构使得该智能体成为一种自适应智能体系统。
合理的构建顺序
无需一次性构建整个循环。一个可行的流程应从可靠的执行以及每次运行时的追踪记录开始。在此基础上还需加入操作保护机制、结果与答案验证、有限范围的修复措施以及人工审核。接下来是质量衡量：追踪记录、故障评估与分类，以及必要的回归测试数据集。只有当质量能够被可靠地衡量时，经验学习才会发挥作用，此时需要引入候选方案、限定范围的内存管理、证据汇总、过时控制以及延迟反馈机制。最后阶段则是可控改进，包括故障聚类、候选方案生成、重放评估、影子流量测试以及金丝雀发布策略。
顺序很重要：
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
在评估机制建立之前就急于采用“自我学习”功能，通常会导致系统变化速度超出工程师的应对能力。
目标
不应追求能够自我修改的智能体，更好的目标是打造一个能够判断智能体何时应当进行修改的平台。仅凭记忆之前的对话并不足以让循环机制获得信任，还需要在这些阶段之间建立有序的流程：
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
正是这种链条支撑起了以证据为驱动的自适应智能体系统，也是智能体人工智能若要从演示性功能迈向可靠的生产级软件所必需的架构。
相关阅读
- 循环工程：构建具备自我改进能力的AI智能体的四种嵌套循环 —— 阐述了如何通过四种嵌套控制循环（ReAct、重试、队列、爬山法）以及判断器、预算计量器和篡改检测机制，使智能体在保险核保等场景中具备可靠性。