Pydantic-AI中多代理系统提示与历史消息传递机制解析

在基于Pydantic-AI框架构建多代理系统时，开发者可能会遇到系统提示（System Prompt）与历史消息传递的协同问题。本文将从技术实现角度深入分析这一机制的原理、典型问题场景及解决方案。

核心问题现象

当采用链式代理架构时（如Agent A→Agent B→Agent C），后续代理会继承前序代理的历史消息，但系统提示却未能按预期更新。具体表现为：

• Agent A设置系统提示"A1"（运行正常）
• Agent B预期使用"B2"+上下文，实际仍使用"A1"
• Agent C预期使用"C3"+上下文，实际仍使用"A1"

技术背景解析

Pydantic-AI的消息处理机制包含两个关键部分：

1. 系统提示：通过@agent.system_prompt装饰器定义，决定代理的基础行为模式
2. 历史消息：通过message_history参数传递，保存对话上下文

在链式调用中，新代理实例应具备：

• 独立系统提示（定义当前代理角色）
• 继承的历史消息（保持对话连续性）

问题根源

出现系统提示"粘滞"现象的原因在于：

1. 历史消息队列中包含前序代理的系统提示消息
2. 新代理运行时未正确覆盖系统提示层级
3. 上下文（ctx）参数未有效传递到新提示生成过程

解决方案

方案一：显式重置系统提示

# 在每次代理调用时强制注入新系统提示
result = agentB.run(
    ...,
    message_history=history,
    system_prompt_override="B2" + ctx.deps
)

方案二：结构化历史消息

建议采用消息类型标注区分：

class MessageType(Enum):
    SYSTEM = "system"
    USER = "user"
    AGENT = "agent"

# 在处理历史消息时过滤前序系统消息
filtered_history = [
    msg for msg in history 
    if msg.type != MessageType.SYSTEM
]

方案三：代理上下文继承

通过上下文工厂确保参数传递：

def agent_factory(base_ctx):
    agent = Agent(...)
    
    @agent.system_prompt
    def prompt(ctx):
        return f"Custom {base_ctx}" + ctx.deps
    
    return agent

最佳实践建议

1. 消息分类存储：对不同来源的消息添加类型标记
2. 上下文验证：在系统提示函数中添加ctx参数校验
3. 代理隔离：每个代理应维护独立的提示版本
4. 历史消息净化：在跨代理传递时过滤系统级消息

扩展思考

该问题本质上反映了对话系统中两个维度的矛盾：

• 纵向一致性：需要保持对话上下文的连贯
• 横向隔离性：需要保证各代理角色的独立

成熟的解决方案通常采用消息路由机制，通过中间件处理消息转换和过滤，这为Pydantic-AI未来的架构演进提供了方向参考。

通过正确理解消息处理流程的层次结构，开发者可以构建出既保持上下文连贯性，又能实现角色灵活切换的多代理系统。