上下文工程不应是随机试错，而应遵循系统化的方法论。方法论提供：
- 可重复的工作流程
- 清晰的决策框架
- 持续改进的机制
graph LR
A["需求分析"] --> B["设计"]
B --> C["实现"]
C --> D["评估"]
D --> E["优化"]
E --> B
图 3-6：上下文工程生命周期
明确上下文工程需要解决的问题：
任务分析
- 任务类型：问答、生成、推理、执行
- 任务复杂度：单步还是多步
- 领域特性：通用还是专业领域
信息分析
- 信息来源：有哪些可用的信息源
- 信息规模：总量和单次需求量
- 信息动态性：更新频率和时效要求
约束分析
- 上下文窗口限制
- 延迟要求
- 成本预算
基于需求设计上下文架构：
架构设计
- 确定上下文的分层结构
- 设计各层的内容和格式
- 规划动态加载机制
策略选择
- 确定需要应用的核心策略
- 设计策略的具体实现方式
- 规划策略之间的协作
工具选型
- 选择检索方案
- 选择向量数据库
- 选择压缩方法
将设计落地为具体实现：
基础设施
- 搭建向量数据库
- 配置嵌入模型
- 建立数据处理流水线
上下文构建
- 实现各策略模块
- 开发上下文组装逻辑
- 构建工具调用机制
集成测试
- 端到端功能验证
- 性能基准测试
- 边界情况处理
对实现效果进行系统评估：
质量评估
- 按 3.3 节方法评估上下文质量
- 评估端到端任务效果
- 收集用户反馈
性能评估
- Token 使用效率
- 响应延迟
- 系统吞吐量
成本评估
- API 调用成本
- 基础设施成本
- 维护成本
基于评估结果持续改进：
识别瓶颈
- 分析评估数据
- 定位主要问题
- 确定优化优先级
迭代改进
- 调整策略参数
- 优化实现细节
- 尝试新技术方案
持续监控
- 建立监控仪表盘
- 设置告警阈值
- 跟踪长期趋势
面对具体问题时，可以使用以下决策框架：
| 问题 | 对应策略 | 关键决策 |
|---|---|---|
| 信息太多放不下 | 选择 + 压缩 | 检索 vs 摘要的权衡 |
| 模型缺乏知识 | 写入 + 选择 | 知识库构建方案 |
| 输出不够准确 | 相关性优化 | 检索策略调整 |
| 响应太慢 | 压缩 + 缓存 | 预处理 vs 实时 |
| 成本太高 | 压缩 + 模型选择 | 质量 vs 成本权衡 |
| 结构混乱 | 隔离 | 结构化方案设计 |
1. 从简单开始
先实现基础版本，再逐步优化。不要一开始就追求完美的上下文架构，而是先用最简单的方案验证核心功能。简单方案更容易调试，能快速暴露真实问题。过早优化往往导致对错误问题的过度工程化。
2. 数据驱动
基于数据和评估做决策，而非直觉。建立评估基准，记录每次改动的效果。很多“看起来更好”的改进实际上没有提升甚至适得其反。只有数据才能告诉你真相。定期回顾指标，用 A/B 测试验证假设。
3. 模块化设计
各策略独立实现，便于替换和升级。检索、压缩、结构化等模块应该解耦，通过清晰的接口交互。这样可以独立测试、独立优化，也方便在技术迭代时替换单个组件而不影响整体系统。
4. 持续迭代
上下文工程是持续优化的过程。用户需求会变化，业务数据会增长，模型能力会升级。定期审视现有方案，识别新的优化机会。建立反馈闭环，将生产环境的问题和用户反馈转化为改进行动。
5. 关注端到端
最终指标是用户体验，而非中间指标。检索召回率很高但用户不满意，说明某个环节有问题。不要沉迷于优化某个子指标而忘记最终目标。建立端到端评估机制，确保各环节的优化最终转化为用户价值。
上下文工程通常涉及多个角色：
- AI 工程师：实现核心策略和系统
- 数据工程师：处理数据流水线和存储
- 产品经理：定义需求和评估标准
- 领域专家：提供专业知识支持
以下案例展示了上述方法论在真实场景中的应用：
背景：某大型制造企业拥有海量内部文档（Wiki、技术手册、维修记录），员工需要快速查找解决生产线问题的方案。
挑战：
- 信息孤岛：数据分散在 SharePoint、Confluence 和文件服务器。
- 专业术语多：通用模型难以理解内部缩写（如 “ABC-123 故障”）。
- 权限复杂：不同层级员工可见内容不同。
上下文工程方案：
- 需求分析：确认为“检索密集型”任务，准确性优先于创造性。
- 设计：采用 RAG 架构，配合混合检索（Hybrid Search）。
- 分层：
- 系统层：固定的企业安全规范和输出格式。
- 知识层：动态检索的文档片段（Top-5 chunk）。
- 任务层：用户当前的查询和元数据（部门、设备 ID）。
- 分层：
- 关键实现：
- 术语增强：在写入阶段，利用 LLM 将内部缩写扩展为全称，建立同义词库。
- 权限过滤：在检索阶段（Pre-retrieval），根据用户 ID 过滤索引，确保不出权限。
- 评估指标（示例口径）：
- Recall@5、MRR、NDCG 等检索指标的变化趋势。
- 用户满意度（CSAT）与后续追问率等体验指标。
背景：一个致力于自动化代码生成的开源项目，使用多个智能体协同完成从需求分析到代码实现的流程。
挑战：
- 上下文传递丢失：产品经理智能体的详细需求，传到开发者智能体时变得模糊。
- 幻觉累积：早期的错误理解在后续环节被放大。
- 上下文超限：多轮协作后，完整的对话历史迅速撑爆窗口。
上下文工程方案：
- 隔离与结构化：
- 使用标准化的 JSON schema 定义 Agent 间的通信协议。
- 每个 Agent 只接收与其职责相关的上下文片段（Context Slicing）。
- 压缩与检查点：
- 在交接点（Hand-off）引入“总结者 Agent”，将上一步的输出压缩为“已确认的决策点”。
- 必须包含的锚点信息（如技术栈版本、核心 API 签名）始终保留，不被压缩。
- 效果（常见观察）：
- 复杂任务的一次通过率与返工率可被明显改善。
- 通过压缩、切片与缓存，Token 消耗在高重复场景下可显著下降。
建立清晰的协作机制和责任分工，是大规模上下文工程项目成功的关键。