9.1 智能体架构与上下文

9.1.1 智能体的核心特征

自主规划:独立拆解任务并指定执行措施
工具协作:通过API,文件系统,代码执行等工具拓展能力,与现实世界交互
循环执行:遵循"思考-行动-观察-反思"的循环
上下文依赖:每一步的策略都依赖于之前的执行历史和当前的环境状态

9.1.2 为什么上下文是智能体的核心

不同于一次性的聊天应用，智能体需要在 多步执行 中维持一致的上下文：

早期步骤的决策可能影响后期的规划
环境观察需要被记录和回顾
执行历史需要被压缩或组织，否则会快速耗尽 token 预算
不同的任务阶段需要不同的上下文关注点

一个 agent 失败往往不是因为推理能力不足，而是因为：

关键信息在执行过程中被遗忘（上下文管理不当）
环境状态变化，但智能体仍基于过时信息决策（上下文不同步）
历史积累过长，导致 token 溢出（上下文压缩不当）

9.1.3 智能体上下文特殊挑战

挑战维度	核心痛点	解释 / 影响
长程依赖	任务跨越数十甚至数百轮交互	早期信息容易被遗忘或稀释
状态爆炸	需要同时追踪任务进度、环境变化、中间结果	上下文快速膨胀，Token 成本急剧上升
信息来源多元	用户输入、工具返回、环境观察、历史回顾	难以区分哪些信息是关键、哪些是噪声
动态重规划	计划可能需要实时调整	需要频繁修改上下文，但频繁修改易引入错误
可观测性不足	Agent 的思考过程被隐藏在 Token 流中	难以调试失败原因，难以审计决策过程

解决方法:结构化的上下文工程策略

9.1.4 智能体上下文的典型层级

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
┌─────────────────────────────────────────────┐
│  系统层：Agent 定义、角色、约束             │  稳定，不变
├─────────────────────────────────────────────┤
│  任务层：当前目标、成功标准、约束           │  任务级，变化频率低
├─────────────────────────────────────────────┤
│  状态层：进度、环境观察、动态计划           │  需要频繁更新
├─────────────────────────────────────────────┤
│  历史层：执行轨迹、观察、决策（可压缩）    │  可能很长，需要管理
├─────────────────────────────────────────────┤
│  交互层：当前步骤、即时输入、观察           │  最新、最关键
└─────────────────────────────────────────────┘

分层的好处:

不同的层级有不同的更新速率,避免无谓的重复
支持选择性压缩:可以摘要历史层,但保留状态层的完整性
清晰的结构让模型快速定位需要的信息

9.1.5 ReAct与Reflexion的上下文含义

智能体的运行模式决定了上下文的结构和更新策略

ReAct循环(思考->行动->观察):

上下文要记录每一步的Thought,Action,Observation
频繁更新,但每个循环的上下文是相对独立的
适合需要即时反馈的任务

Reflexion模式(执行->整体反思->调整策略)

上下文需要累计所有执行轨迹,然后进行整体评估
更新频率低,但是单次更新设计更多信息
适合需要从失败中学习的任务

上下文工程的启示：选择错误的运行模式，会导致上下文管理困难。例如，如果用 Reflexion 模式处理频繁交互的任务，历史会快速膨胀而无法得到及时压缩。

9.1.6 上下文管理的核心原则

1.信息分层 2.动态更新 3.选择性保留 4.结构化组织

9.1.7 上下文工程的四大模式|

写入策略,选择策略,压缩策略,隔离策略

9.1.8 生产级智能体的上下文框架

9.1.9 Agent Harness的上下文平面

背景和动机:

在大规模生产环境中，智能体系统需要在多个不同的“平面”上进行协调工作。Agent Harness 框架将这些关注点分解为五个正交的平面，其中 上下文平面（Context-Plane） 是最核心的一个。

上下文平面的四个维度

会话状态（Session State）
- 追踪智能体执行到哪一步
- 记录每一步的中间结果和输出
- 在中断后支持从检查点恢复
- 例如：OpenAI Responses 的 Step 管理，Azure Durable Functions 的 Orchestration State
记忆管理（Memory）
- 短期工作记忆：当前对话和任务的即时信息
- 长期持久记忆：跨会话的用户偏好、领域知识、解决方案模板
- 记忆的检索、更新和遗忘机制
- 例如：Google Agent Runtime（原 Vertex Agent Engine）的 Agent Platform Sessions（会话内存）vs Memory Bank（跨会话记忆）
上下文压缩与整理（Compaction/Summarization）
- 历史信息的摘要与精简
- 对话历史的管理和截断
- 多轮交互中的冗余消除
- 支持 Token 成本优化和性能提升
工件日志（Artifact Logs）
- 每一步的执行结果都被记录为有类型的工件
- 支持完整的追踪（Tracing）和重放（Replay）
- 便于调试、审计和合规验证
- 与可观测性系统（如 OpenTelemetry）集成

上下文平面的核心原则

上下文平面的本质是将智能体的“思维过程”转化为“可审计、可验证、可恢复”的执行流。每一个推理步骤都对应一个明确的行动（Action），该行动产生的结果都被记录为结构化的工件，这些工件通过追踪系统被串联起来，形成完整的执行链路。

设计示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
┌─ 智能体执行 ──────────────────────────────────────┐
│                                                      │
│  [思考] → [决策工具] → [执行工具] → [观察结果]     │
│    ↓         ↓           ↓          ↓               │
│  会话状态   行动日志    结果工件    状态更新       │
│                                                      │
└──────────────────────────────────────────────────────┘
           ↓
    [上下文平面]
    ├─ Session State: 步骤3/10, 等待工具返回
    ├─ Memory: 提取相关历史经验
    ├─ Compaction: 压缩早期步骤历史
    └─ Artifacts: 记录所有工具调用和结果
           ↓
    [可观测性系统]
    ├─ Traces: 完整的执行链
    ├─ Metrics: 延迟、成本、成功率
    └─ Logs: 结构化的事件日志

与其他平面的关系

系统平面	核心职能	核心交互与机制
工具平面	外部工具和 API 的集成	工具执行的输出被记录为工件
上下文平面	状态、记忆、压缩、工件	核心，管理所有中间信息
推理平面	LLM 的推理策略和提示优化	消费上下文平面的记忆和状态
协调平面	多智能体间的通信和同步	通过工件交换信息，状态同步
可观测平面	追踪、监控、告警	消费上下文平面的工件和日志

9.2 单智能体上下文管理

9.2.1 工作记忆管理

信息优先级

优先级	存储/处理方式	说明
最高	任务目标、核心约束	始终保留
高	当前计划、即时状态	完整保留
中	近期执行记录	根据窗口压缩
低	早期历史	摘要或外存

滑动窗口策略

只保留最近N步的详细记录

9.2.1.1 Agent SDK的上下文收集方式

1.主动检索(Agentic Search)

智能体运用bash命令(grep,find,head,tail等)在文件系统中主动探索和检索相关内容

特点:

优势:准确性高,灵活性强,不依赖预构建的索引
劣势:延迟较高(需要多次API的调用),可能探索低效
适用场景:对动态信息.边界情况的精确查询

1
2
3
4
5
6
7
8
9
问题：「代码中哪些地方处理了错误日志？」

智能体执行：
1. grep -r "error_log" /src --include="*.py"  (找出包含关键词的文件)
2. 浏览找到的 3 个文件
3. 使用 grep -n "error_log" file.py 定位具体行号
4. 用 head -n 50 file.py | tail -n 20 查看关键部分

结果：精准获取所需上下文

2.语义检索(Semantic Search)

使用向量嵌入技术检索内容

特点

优势:速度块,概念性查询能力强
劣势:精度依赖于分块策略和嵌入模型,需要维护索引
适用场景:概念级别的查询

权衡建议：

从 agentic search 开始，只在需要更快响应时才加入 semantic search
两种方式可以互补：agentic search 精准验证，semantic search 快速初筛

3.子智能体(Subagents)

为特定的任务创建专用的子智能体,让其独立探索,只返回摘要结果特点:

优势:上下文隔离,并行处理多个查询,子代理可专业化
劣势:增加系统复杂度,有额外延迟
适用场景:需要深度探索大量信息的任务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
主智能体：「分析这个代码库的性能瓶颈」

触发两个子智能体并行：
- 子智能体 A：探索所有使用数据库的代码路径
  返回：「发现 3 个 N+1 查询问题」(而非全部代码细节)

- 子智能体 B：分析内存使用模式
  返回：「内存泄漏点在缓存模块」(而非完整内存跟踪)

主智能体接收两个摘要，综合分析，保持上下文清晰

4.压缩(Compaction)

当上下文接近窗口限制时,对之前的消息进行高保真压缩

特点:

用途:处理超长任务的上下文溢出
机制:模型总结关键信息,保留关键代码,丢弃冗余工具输出

方式	实时性	精准度	成本	最佳用途
Agentic Search	中	高	低	精确查询、验证假设
Semantic Search	高	中	中	快速初筛、概念搜索
Subagents	低	高	中	并行深度探索
Compaction	-	中	低	长时间任务的上下文管理

推荐策略:

优先从agentic search开始,评估是否满足需求
只在性能不足的时候加入semantic search
需要并行处理和上下文隔离的时候适用subagents
为长时间任务预留compaction机制

9.2.2 状态追踪

显式状态块

在上下文中维护显式的状态信息

1
2
3
4
5
6
<current_state>
  <task>处理用户退款请求</task>
  <progress>3/5 步骤已完成</progress>
  <current_step>等待退款审批</current_step>
  <blockers>需要财务部门确认</blockers>
</current_state>

状态更新

每次行动后更新状态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
def update_state(old_state, action, result):
    new_state = old_state.copy()
    new_state["last_action"] = action
    new_state["last_result"] = result
    new_state["step_count"] += 1

    if is_completed(result):
        new_state["progress"] = update_progress(...)

    return new_state

9.2.3 计划管理

计划表示

在上下文中维护当前计划

1
2
3
4
5
6
<plan>
  <step n="1" status="completed">收集用户信息</step>
  <step n="2" status="completed">验证订单状态</step>
  <step n="3" status="in_progress">发起退款申请</step>
  <step n="4" status="pending">通知用户结果</step>
</plan>

计划调整

根据执行情况调整计划:

1
2
3
4
5
Thought: 原计划第3步失败，需要调整策略
Revised Plan:
- 3a. 联系客服主管获取特殊授权
- 3b. 重新发起退款申请
- 4. 通知用户结果

9.2.4 执行历史压缩

成功操作压缩

成功的操作进行压缩可以简化记录

1
2
3
4
5
6
原始：
Action: search_products(query="蓝牙耳机", limit=10)
Observation: [10个产品的详细信息...]

压缩后：
✓ 搜索"蓝牙耳机"，找到10个结果

失败操作保留:

失败的操作保留更多细节,防止重复错误

1
✗ 尝试 API_A 失败（超时）- 应使用 API_B

9.2.5 工具结果处理

9.2.6 上下文窗口监控

监控上下文使用情况:

1
2
3
4
5
6
def check_context_usage(context):
    token_count = count_tokens(context)
    if token_count > 0.8 * MAX_CONTEXT:
        trigger_compression()
    if token_count > 0.95 * MAX_CONTEXT:
        trigger_emergency_cleanup()

9.2.7 错误恢复

当智能体遇到问题时的上下文处理:

记录错误状态
回溯检查点
调整计划
清理无效信息:移除错误操作的中间信息

9.2.8 持久化执行与工件管理

对于长时间运行或者涉及多个工具调用的智能体任务,建议采用持久化执行模式(Durable Execution Pattern)

工件(Artifact)的定义和使用

工件是指智能体执行过程中的每一步输出,包括:

工件类型 / 状态维度	内容示例	核心用途
步骤输出	工具调用结果、模型生成文本	下一步的输入
执行状态	当前进度、已完成步骤、待执行计划	中断恢复
决策记录	为什么选择某个操作	事后分析和审计
元数据	时间戳、成本、延迟等	性能监控

检查点与恢复机制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
def step_1_query_analysis(user_input):
    """第1步：查询分析，并保存工件"""
    parsed = parse_query(user_input)
    checkpoint_save({
        "step": 1,
        "status": "completed",
        "output": parsed,
        "timestamp": now()
    })
    return parsed

def step_2_knowledge_retrieval(parsed_query):
    """第2步：知识检索，依赖第1步的工件"""
    try:
        docs = retrieve_documents(parsed_query)
        checkpoint_save({
            "step": 2,
            "status": "completed",
            "output": docs
        })
        return docs
    except Exception as e:
        # 记录失败，可以从这里重试
        checkpoint_save({
            "step": 2,
            "status": "failed",
            "error": str(e)
        })
        raise

# 恢复执行：检查最后成功的检查点
last_checkpoint = load_last_checkpoint()
if last_checkpoint["step"] >= 2:
    # 从第2步的输出继续
    docs = last_checkpoint["output"]
else:
    # 从第1步重新开始
    parsed = step_1_query_analysis(user_input)
    docs = step_2_knowledge_retrieval(parsed)

工件的持久化和可重放

** 存储位置**：使用结构化存储（如 PostgreSQL + JSON 字段，或 DuckDB）而不是仅日志文件
版本控制：为每个工件记录版本号和生成时间，便于追溯
内容哈希：记录工件内容的 SHA-256 哈希值，确保重放时的一致性验证
重放验证：在恢复后，可选择性地重新执行某些步骤，对比输出与保存的工件是否一致，检测非确定性问题

这种模式特别适合以下场景：

长流程任务：需要调用多个工具、跨越数十个推理步骤的任务
高成本操作：避免因中间失败而重复执行昂贵的 LLM 调用或 API 请求
合规要求：需要完整的审计日志和决策追踪
多智能体协作：下游智能体需要准确了解上游智能体的执行结果和状态

9.2.9 计划文件作为上下文持久化机制

plan.md成为跨上下文会话的持久化的核心机制 plan.md记录了执行状态,问题定义,方案选择,验收标准

跨会话上下文恢复

当会话上下文丢失（如窗口关闭或上下文膨胀触发压缩）时，计划文件充当检查点。开启新会话时只需指向已有计划文件，即可从断点继续，无需重建上下文。这本质上是将上下文从易失的会话内存“外化”到持久化的文件系统。

结构化设计

高质量的计划文件包含问题描述、方案选择、需修改的文件列表、验收标准（复选框形式）等结构化字段。这种结构化设计确保了上下文在跨会话传递时保持完整性和可操作性。

与检查点机制的关系

计划文件与 9.2.8 节讨论的检查点机制形成互补——检查点保存执行状态的快照，计划文件则保存任务的完整语义描述。两者结合实现了从“做什么”到“做到哪了”的完整恢复。

计划文件结构示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# 任务计划：功能 X 实现

## 问题描述

用户需要在仪表板中添加实时数据更新功能。当数据源更新时，前端自动刷新，无需手动重载。

## 方案选择

选择 WebSocket 方案而非轮询，理由：
- 减少服务器负载
- 降低延迟至 200ms 以内
- 便于扩展多个数据源

## 需修改的文件

- [ ] backend/websocket_handler.py - 实现 WebSocket 服务
- [ ] frontend/dashboard.js - 连接 WebSocket 并更新 UI
- [ ] tests/test_websocket.py - 单元测试
- [ ] docs/ARCHITECTURE.md - 更新文档

## 验收标准

- [ ] WebSocket 连接成功建立
- [ ] 数据更新延迟 < 500ms
- [ ] 单个连接内存占用 < 10MB
- [ ] 全部单元测试通过
- [ ] 文档已更新

## 执行进度

### 已完成

- 完成 backend/websocket_handler.py 的基础实现
- 编写了连接管理和消息广播的核心逻辑

### 当前进行

- 正在调试 frontend/dashboard.js 的数据绑定

### 待执行

- 完成单元测试编写
- 性能测试和优化
- 文档更新

9.3 多智能体上下文传递

9.3.1 多智能体系统概述

多智能体有多个协作的智能体组成,每个智能体专注于特定能力和任务

9.3.1.1 Agent SDK中的子智能体的上下文隔离

子智能体不仅是任务的分解工具,更重要的是上下文隔离机制每个子智能体具有独立的上下文,只有必要的信息才会返回给父智能体

上下文隔离的核心机制:

关键特性:

独立上下文:子智能体的处理细节完全独立,不会污染父智能体的上下文
摘要返回:只返回必要结果且是精选的摘要结果
并行执行:多个智能体可以同时工具,叫快乐整体速度

隔离如何降低上下文成本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
❌ 不使用子智能体（单智能体方案）：
- 将 100 页 PDF 加载到上下文：50K tokens
- 模型逐页分析：产生大量中间输出（日志、临时结论等）
- 总体上下文膨胀至 150K+ tokens
- 注意力分散，效率低

✅ 使用子智能体（隔离方案）：
- 主智能体：定义分析任务（1K tokens）
- 启动子智能体：处理 100 页 PDF（子智能体内部上下文 50K）
- 子智能体内部进行详细分析、生成中间输出（子智能体内消化）
- 子智能体返回摘要：5 个关键发现（返回 2K tokens）
- 主智能体接收摘要：总上下文仅 3K tokens
- 成本：原方案 150K vs 隔离方案 50K + 2K + 1K = 53K（下降约 65%）

何时创建子智能体

场景	决策	理由
并行处理多个独立任务	✅ 创建	充分利用并行加速
子任务产生大量中间数据	✅ 创建	隔离数据污染
需要专用的工具或提示词	✅ 创建	专业化处理
简单的信息查询	❌ 不需要	延迟得不偿失
顺序依赖的任务	❌ 不需要	并行无益

9.3.2 上下文传递的挑战

上下文膨胀：如果每个智能体都接收完整上下文，Token 消耗会快速增长
信息干扰：无关智能体的信息可能干扰当前智能体的判断
一致性维护：多个智能体需要对共享信息有一致的理解

9.3.3 上下文共享机制

1.共享黑板模式

引入一个共享的记忆库(黑板),所有智能体都能读取和写入这个公共空间

工作方式:智能体A将发现写入黑板,智能体B读取并推理
一致性:通过访问控制和版本管理
优点:信息同步块,避免点对点通信的复杂度
缺点:需要处理并发写入冲突

2.通信对话模式

工作方式:智能体A直接给智能体B发信息
优点:明确的责任链,点对点隔离
缺点:通信链路可能复杂,长链条导致信息衰减

9.3.4 高级协作模式 : 链式智能体协作

链式协作(Chain-of-Agents: CoA):让多个智能体通过接力方式阅读和处理上下文任务

上下文在智能体链中逐步传递和积累,突破单模型上下文限制

9.3.5 上下文传递策略

最小必要原则

只传递智能体完成任务所需的最小信息

角色专属记忆

为每个智能体维护结构化的角色专属记忆

私有记忆:只保存与自身角色相关的对话和结论
视角隔离:
优势:减少干扰,保证角色一致性

接口抽象

定义清晰的信息传递接口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
{
  "from": "researcher",
  "to": "coder",
  "message_type": "task_handoff",
  "content": {
    "summary": "用户需要一个日历功能",
    "requirements": ["添加事件", "提醒功能"],
    "constraints": ["使用 Python", "无需数据库"]
  }
}

9.3.6 共享状态管理

1
2
3
4
5
6
7
8
9
{
  "global_state": {
    "task_id": "task_123",
    "overall_progress": "50%",
    "key_decisions": [...],
    "artifacts": [...],
    "blocking_issues": []
  }
}

9.3.7 调试与追踪

消息日志记录所有智能体间的通信。每一个消息的发送者、接收者、时间戳、内容类型和 Payload 都应被完整记录。这不仅用于排查错误，也是分析智能体协作模式和效率的重要数据源
上下文快照关键节点的上下文状态。在任务的关键转折点（如子任务完成、决策变更时），保存各个智能体的上下文快照。这允许开发者“时光倒流”，查看系统在特定时刻的全局状态，复现 Bug。
决策追踪每个智能体的决策依据。智能体为什么采取这个行动？是基于哪条上下文信息？使用了哪个 Prompt？记录 ReAct 循环中的 “Thought” 过程，使智能体的行为透明可解释
性能指标上下文大小、传递延迟。监控上下文在传递过程中的膨胀情况，以及智能体之间的通信延迟。通过可视化图表识别瓶颈：是某个智能体处理太慢，还是上下文过大导致传输耗时

9.3.8 主流多智能体框架

框架	核心特点	适用场景	上下文管理
LangGraph	基于图的控制流，强大的状态管理	企业级工作流	显式状态机，支持检查点
CrewAI	角色驱动，极易上手	快速原型，团队协作	角色专属记忆
AutoGen	对话驱动，代码执行能力强	复杂问题解决	会话历史管理
Swarm	轻量级，Handoff 模式	探索性实验	最小化手动管理

选择建议:

需要精细控制 → LangGraph
快速构建 → CrewAI
代码密集型任务 → AutoGen
简单探索 → Swarm

9.3.8.1 MCP服务器与上下文开销优化

Model Context Protocol (MCP) 是一个标准化的协议，用于智能体与外部服务（如 Slack、GitHub、Asana 等）的集成

MCP 的上下文优势：

传统的智能体集成方式：

手动编写每个 API 集成代码
处理认证、错误处理、结果格式化等细节
这些细节会占用上下文空间，或增加工具定义的复杂度

MCP 方式：

预构建的 MCP 服务器可以封装服务侧 API 调用和常见认证适配，但受保护的 HTTP MCP 服务仍需按规范配置授权服务器发现、token 传递、scope 与权限边界
智能体只需调用高级工具（如 search_slack_messages、get_asana_tasks）
减少上下文中的工具定义和说明文本

上下文成本对比:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
❌ 手动集成（假设 10 个集成）：
- 每个 API 的认证逻辑：200-500 tokens
- 每个 API 的错误处理：200-300 tokens
- 每个 API 的结果解析：150-250 tokens
- 总计：4000-8000 tokens 仅用于集成代码和说明

✅ MCP 方式（同样 10 个集成）：
- MCP 服务器处理所有细节（不占用上下文）
- 工具定义：`tool: search_slack_messages`, `tool: get_asana_tasks` 等
- 总计：500-1000 tokens 仅用于工具列表

示例结果：工具定义与认证细节越标准化，上下文开销越低；具体节省比例需按工具 schema 长度实测

MCP在多智能体中的应用:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
场景：构建一个团队协作系统

主智能体
├─ 能力 1：规划任务（不需要外部API）
├─ 能力 2：分配给 Asana（通过 MCP）
├─ 能力 3：发送 Slack 通知（通过 MCP）
└─ 能力 4：查阅 GitHub（通过 MCP）

无需在上下文中重复编写这些集成代码。
每个集成通过标准的 MCP 工具接口暴露。

子智能体
├─ 搜索子智能体：可访问 Google Drive MCP（搜索文档）
├─ 代码子智能体：可访问 GitHub MCP（分析代码）
└─ 研究子智能体：可访问 Web Search MCP（网络搜索）

每个子智能体只加载相关的 MCP 工具，进一步细化上下文。

从上下文工程的角度，MCP 服务器的标准化是一个重要的基础设施发展：

可重用性：一个 MCP 服务器可以被多个智能体和框架使用
上下文节省：集成逻辑不再占用智能体的上下文
快速扩展：添加新的 API 集成无需修改智能体提示词
社区驱动：GitHub 上的 MCP 服务器生态不断增长，降低自定义成本

使用 MCP 的最佳实践：

优先使用现有的 MCP 服务器，而非自定义集成
为 MCP 工具提供清晰的描述，即使在 MCP 层已定义
监控 MCP 工具的实际使用，移除不必要的工具以保持上下文精简
在多智能体中分配工具，让每个智能体只访问相关的 MCP 工具

9.3.9 子智能体架构与上下文隔离

上下文隔离的价值

问题:单一智能体执行复杂任务,上下文会被多个子任务的细节污染,导致以下问题:

上下文腐烂(context rot)
注意力分散
决策质量下降

解决方法:将单独子任务委派给专用子智能体,子智能体有自己的上下文窗口

9.3.10 并行智能体的上下文编排实践

上下文隔离策略并行会话的上下文天然隔离

维度	单会话顺序处理	并行智能体架构
上下文膨胀	任务堆积，急速增长	各会话独立控制
注意力分散	需要在多任务间频繁切换	每个智能体专注单个目标
恢复成本	一处中断影响全局	中断隔离在单个会话
总耗时	顺序累积	并行大幅缩短

共享计划文件作为协调机制

多个并行会话通过文件系统中的计划文件（plan.md）进行协调。一个会话的调研结果写入计划文件，另一个会话基于该计划执行实现。这是 9.3.3 节讨论的共享黑板模式（Blackboard Pattern）在实际开发工作流中的自然应用。

例如：

调研会话：调查最新的框架最佳实践，将发现整理到 plan.md 的“技术选型”部分
规划会话：读取调研成果，生成详细的实现计划
实现会话：按照计划逐步编码
测试会话：验证实现是否符合验收标准

Research->Plan->Build循环

多源上下文融合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# plan.md - 性能优化项目

## 调研会话的贡献

研究了 4 篇最新论文，对比了 3 个开源方案...
（来自 Research 会话）

## 规划会话的贡献

基于调研成果，选择方案 A，理由：...
分解为 5 个子任务：Task 1, Task 2, ...
（来自 Planning 会话）

## 实现会话的贡献

已完成 Task 1, Task 2，遇到 Bug X，已解决...
当前进度：60%
（来自 Build 会话）

## 历史决策

2026-03-15：选择了 Python 而非 Go（参考会议记录）
2026-03-18：改用异步架构以提升吞吐量（参考代码审查）

9.4 智能体记忆与学习

9.4.0 状态(State)与记忆(Memory)的语义区分

状态(State):

当前执行步骤的输出
工作流的完成进度
中间计算结果与检查点
可被重放和调试的执行轨迹

状态是面向计算过程的 1.可靠性:中断后能从检查点恢复 2.可观测性:记录系统做了说明,便于调试和审计 3.可重放性:完整的输入和输出序列可以被重新执行,用于验证和测试实现方式（如 OpenAI Responses、Azure State Persistence）通常将状态存储在专用的状态管理系统中，支持版本控制和原子性操作。

记忆(Memory)

为智能体学习和决策保留的,经过精心整理的长期或者短期人类可理解的信息,包括:

用户的偏好和背景知识
解决问题的经验教训
领域特定知识
对话摘要与关键决策点

记忆是面向推理和个性化的,主要目的是为了: 1.个性化 2.学习 3.上下文连续性

实现方式:将记忆存储在语义数据库或向量库中，支持检索和更新

两者的配合:

状态保证了工作流的容错和可恢复性,是健壮性的基础记忆支撑了智能体的进化和个性化,是智能体质量提升的动力

9.4.1 智能体记忆的层次

即时记忆:当前任务的工作记忆,对应上下文窗口中的即时信息会话记忆:单词会话的完整历史,可压缩后保留要点持久记忆:跨会话保留的长期知识,可存储在外部数据库中

9.4.2 记忆与状态信息类型

类型	示例	存储位置
事实	用户偏好、配置	持久记忆
经验	成功/失败的操作	持久记忆
技能	学到的解决方案	持久记忆
执行状态	当前任务进度、待恢复检查点	会话状态或检查点存储
细节	操作的具体参数	即时记忆

9.4.3 记忆更新机制

显式记忆

用户明确要求记住

隐式记忆

在交互中自动学习

反思记忆模式

基于Reflexion框架的自我改进循环

** Actor（执行者）**：尝试执行任务，生成轨迹。
Evaluator（评估者）：评估执行结果的质量（如测试通过率、准确性）。
Self-Reflection（反思者）：分析失败原因，生成“自我反思”，总结教训。
Memory（记忆）：将反思结果存入长期记忆。

1
2
3
4
5
6
7
8
9
--- 第一次尝试 ---
Actor: 尝试使用 requests 库抓取网页。
Evaluator: 失败，返回 403 Forbidden。
Self-Reflection: 目标网站有反爬策略，需要设置 User-Agent。

--- 第二次尝试 ---
Actor: (检索到上次的反思) 设置 User-Agent 伪装成浏览器重试。
Evaluator: 成功。
Memory Update: "抓取该网站时必须设置 User-Agent 头" -> 存入知识库。

9.4.4 从经验中学习

成功经验复用;失败经验规避

9.4.5 知识积累

领域知识:随着使用积累用户知识:了解特定用户

9.4.6 记忆检索

混合检索的核心:RRF(Reciprocal Rank Fusion) 算法原理：对于每一项文档 $d$，计算其融合得分： $$ \text{Score}(d) = \sum_{r \in R} \frac{1}{k + \text{rank}(r, d)} $$

R：不同的检索器集合（如语义、关键词、时间）。
rank(r, d)：文档 $d$ 在检索器 $r$ 结果中的排名（1, 2, 3…）。
k：平滑常数（通常取 60），用于防止高排名文档主导分数。

优势: 零样本;鲁棒性;公平性

9.4.7 记忆管理挑战

容量管理:记忆不能无线增长,需要重排序,定期清理过期信息和压缩低频信息
一致性维护:记忆可能过时或矛盾,需要版本追踪,冲突检测,定期验证
隐私保护:敏感信息需要保护,包括访问控制,数据加密和保留策略

9.4.8 全时异步主动调度

1.碎片时间利用:利用用户的"空挡时间" 2.主动行为预测:系统在后台部署轻量级意图预测模型，预判 Agent 下一步可能需要的领域知识与偏好 3.状态"就绪":在用户的查询真正触发前，系统已在后台并行地将各类记忆（文档、会话、偏好）抽取、组合并预热加载到高速缓存中。当 Prompt 最终到达时，所需的增强上下文便已如构建好的“魔方（Cube）”般瞬间就位，仅需几毫秒即可完成轻量读取

9.4.9 跨对话记忆持久化

引入MEMORY.md索引文件

容量与结构：

大小限制：最多 200 行或 25KB，确保可快速加载
每条记忆：约 150 字符，包含标签和简要描述
四种记忆类型：
- 项目模式（Project Patterns）：架构决策、代码风格、模块依赖关系
- 用户偏好（User Preferences）：代码格式、沟通风格、优先级偏好
- 工具配置（Tool Configs）：常用命令别名、环境变量名、密钥名称、权限范围和配置位置
- 领域知识（Domain Knowledge）：业务规则、技术约束、常见陷阱

记忆文件不得保存真实 secret、token、密码、Cookie、登录状态、生产连接串或个人敏感信息。需要记录凭据依赖时，只记录占位变量名、用途、权限范围和批准的配置位置。

加载策略：新会话启动时，系统首先加载 MEMORY.md，使用其内容增强初始上下文。由于体积小，加载时间 < 100ms，不会影响 TTFT

记忆做梦机制

当跨越多个会话进行长期项目时，智能体定期执行“做梦”操作来清理和整合记忆：

执行时机：

项目完成时
每次大型功能交付后
当 MEMORY.md 接近容量上限时

处理流程：

回顾（Review）：扫描过去会话的日志，识别对当前项目的影响
合并（Merge）：当发现相同主题的多条旧记忆时，合并它们
去重（Deduplicate）：消除矛盾的记忆，保留最新信息
时间归一化：将相对日期（“上周”）转换为绝对日期（“2026-04-15”），便于长期追踪

9.4.10 记忆与上下文的协作

记忆系统与上下文工程密切配合：

1. 记忆提供长期信息

将持久记忆检索到当前上下文。这是最基础的协作模式。当用户提问涉及到之前的会话或特定知识时，系统从记忆模块中检索相关内容，并将其注入到当前的 Prompt 上下文中。这解决了 LLM 固有上下文窗口有限和无记忆的问题。

2. 上下文产生新记忆

从当前交互中提取值得记忆的内容。在对话过程中，上下文窗口中不断产生新的信息。系统需要实时或定期分析上下文，提取出有价值的信息（如用户偏好、新事实、关键决策），并将其写入到记忆模块中。这是智能体不断学习和进化的基础。

3. 记忆优化上下文

了解用户后可以简化上下文。随着对用户记忆的加深，智能体可以更精准地理解用户意图，从而不需要在上下文中反复包含冗长的说明或背景信息。例如，如果记忆中已经知道用户是 Python 专家，上下文中的代码解释就可以更加精简，节省 Token 并提升沟通效率。

9.1 智能体架构与上下文#

9.1.1 智能体的核心特征#

9.1.2 为什么上下文是智能体的核心#

9.1.3 智能体上下文特殊挑战#

9.1.4 智能体上下文的典型层级#

9.1.5 ReAct与Reflexion的上下文含义#

ReAct循环(思考->行动->观察):#

Reflexion模式(执行->整体反思->调整策略)#

9.1.6 上下文管理的核心原则#

9.1.7 上下文工程的四大模式|#

9.1.8 生产级智能体的上下文框架#

9.1.9 Agent Harness的上下文平面#

背景和动机:#

上下文平面的四个维度#

上下文平面的核心原则#

与其他平面的关系#

9.2 单智能体上下文管理#

9.2.1 工作记忆管理#

信息优先级#

滑动窗口策略#

9.2.1.1 Agent SDK的上下文收集方式#

1.主动检索(Agentic Search)#

2.语义检索(Semantic Search)#

3.子智能体(Subagents)#

4.压缩(Compaction)#

9.2.2 状态追踪#

显式状态块#

状态更新#

9.2.3 计划管理#

计划表示#

计划调整#

9.2.4 执行历史压缩#

成功操作压缩#

失败操作保留:#

9.2.5 工具结果处理#

9.2.6 上下文窗口监控#

9.2.7 错误恢复#

9.2.8 持久化执行与工件管理#

工件(Artifact)的定义和使用#

检查点与恢复机制#

工件的持久化和可重放#

9.2.9 计划文件作为上下文持久化机制#

跨会话上下文恢复#

结构化设计#

与检查点机制的关系#

计划文件结构示例#

9.3 多智能体上下文传递#

9.3.1 多智能体系统概述#

9.3.1.1 Agent SDK中的子智能体的上下文隔离#

上下文隔离的核心机制:#

隔离如何降低上下文成本#

何时创建子智能体#

9.3.2 上下文传递的挑战#

9.3.3 上下文共享机制#

1.共享黑板模式#

2.通信对话模式#

9.3.4 高级协作模式 : 链式智能体协作#

9.3.5 上下文传递策略#

最小必要原则#

角色专属记忆#

接口抽象#

9.3.6 共享状态管理#

9.3.7 调试与追踪#

9.3.8 主流多智能体框架#

9.3.8.1 MCP服务器与上下文开销优化#

9.3.9 子智能体架构与上下文隔离#

上下文隔离的价值#

9.3.10 并行智能体的上下文编排实践#

上下文隔离策略并行会话的上下文天然隔离#

共享计划文件作为协调机制#

Research->Plan->Build循环#

多源上下文融合#

9.4 智能体记忆与学习#

9.4.0 状态(State)与记忆(Memory)的语义区分#

状态(State):#

记忆(Memory)#

两者的配合:#

9.4.1 智能体记忆的层次#

9.4.2 记忆与状态信息类型#

9.4.3 记忆更新机制#