01 一条消息，三种命运

用户说："把它改成蓝色。"

三个智能体面对同一条用户消息，看到的东西完全不同：

这就是多智能体系统中上下文管理的核心矛盾：给得太多会污染，给得太少会丢失关键信息。buddyMe 用了三种截然不同的策略来应对这个问题，每一种都有不得不付出的代价。

本文将深入 MainAgent、Sub-Agent、EvalAgent 三层智能体的上下文机制，逐一拆解每种策略的设计动机、实现细节和利弊权衡。

02 四个角色，四个上下文边界

buddyMe 系统中共有 4 个活跃角色，各自拥有独立的 LLM 客户端和上下文边界：

三个 LLM 客户端在 AgentMain.__init__() 中同时创建：

self._client = self._create_client(model_name)           # 主模型
self._sub_client = basic_llm.create_client("sub_agent_code_plan")  # 子任务辅助
self._eval_client = self._create_client(model_name)       # 评估专用（独立）

03 上下文生命周期：从用户输入到评估报告

理解利弊之前，先看清上下文在整个系统中是如何流转的：

注意三个关键设计决策：

04 MainAgent：持续上下文的代价

MainAgent 是整个系统的"大脑"，在整个会话生命周期内维护三层记忆：

利：为什么需要持续上下文

弊：持续上下文的四个隐患

05 Sub-Agent：独立上下文的得与失

每个子任务的执行都是一次全新的 LLM 对话。核心设计原则：消息不继承，状态通过文本注入。

三条数据传递通道

利：独立上下文带来的稳定性

弊：独立上下文的五个盲区

06 EvalAgent：最干净的评估者

EvalAgent 是系统中最"干净"的智能体——每次评估都是一次无状态的单次 LLM 调用，固定 2 条消息，temperature=0.0。

# 构造函数 — 唯一的实例属性是客户端
def __init__(self, client):
    self._client = client  # 独立客户端，防止上下文冲突

# 每次评估 — 固定 2 条消息
response = await self._client.chat(
    messages=[
        {"role": "system", "content": self._SYSTEM_PROMPT},
        {"role": "user", "content": prompt},
    ],
    temperature=0.0,
)

评估数据来源

所有数据通过方法参数传入，从 SessionState（每轮重置）和磁盘文件（实时读取）获取：

利：绝对独立的评估

弊：最干净也最孤独

07 跨框架对比：buddyMe 不是唯一的解法

buddyMe 的上下文管理策略并非唯一选择。不同框架对"隔离 vs 共享"的取舍截然不同：

上下文策略光谱

详细对照

08 五个设计张力点

buddyMe 的上下文架构中存在五个核心张力，每个都是在工程实践中不得不做的取舍：

09 三层利弊全景对比

通俗化类比：公司项目组

10 改进路线图：从"够用"到"优秀"

当前设计在 buddyMe 的应用场景（AI 辅助编程）中是合理且务实的。但在更复杂的多 Agent 场景下，以下改进方向值得探索：

短期优化（1-2 周）

中期改进（1-2 月）

长期演进（3-6 月）