3.4 上下文工程方法论

3.4.1 方法论的必要性

上下文工程不应是随机试错，而应遵循系统化的方法论。方法论提供：

• 可重复的工作流程

• 清晰的决策框架

• 持续改进的机制

3.4.2 上下文工程生命周期

阶段一：需求分析

明确上下文工程需要解决的问题：

任务分析

• 任务类型：问答、生成、推理、执行

• 任务复杂度：单步还是多步

• 领域特性：通用还是专业领域

信息分析

• 信息来源：有哪些可用的信息源

• 信息规模：总量和单次需求量

• 信息动态性：更新频率和时效要求

约束分析

• 上下文窗口限制

• 延迟要求

• 成本预算

阶段二：设计

基于需求设计上下文架构：

架构设计

• 确定上下文的分层结构

• 设计各层的内容和格式

• 规划动态加载机制

策略选择

• 确定需要应用的核心策略

• 设计策略的具体实现方式

• 规划策略之间的协作

工具选型

• 选择检索方案

• 选择向量数据库

• 选择压缩方法

阶段三：实现

将设计落地为具体实现：

基础设施

• 搭建向量数据库

• 配置嵌入模型

• 建立数据处理流水线

上下文构建

• 实现各策略模块

• 开发上下文组装逻辑

• 构建工具调用机制

集成测试

• 端到端功能验证

• 性能基准测试

• 边界情况处理

阶段四：评估

对实现效果进行系统评估：

质量评估

• 按 3.3 节方法评估上下文质量

• 评估端到端任务效果

• 收集用户反馈

性能评估

• Token 使用效率

• 响应延迟

• 系统吞吐量

成本评估

• API 调用成本

• 基础设施成本

• 维护成本

阶段五：优化

基于评估结果持续改进：

识别瓶颈

• 分析评估数据

• 定位主要问题

• 确定优化优先级

迭代改进

• 调整策略参数

• 优化实现细节

• 尝试新技术方案

持续监控

• 建立监控仪表盘

• 设置告警阈值

• 跟踪长期趋势

3.4.3 决策框架

面对具体问题时，可以使用以下决策框架：

问题	对应策略	关键决策
信息太多放不下	选择 + 压缩	检索 vs 摘要的权衡
模型缺乏知识	写入 + 选择	知识库构建方案
输出不够准确	相关性优化	检索策略调整
响应太慢	压缩 + 缓存	预处理 vs 实时
成本太高	压缩 + 模型选择	质量 vs 成本权衡
结构混乱	隔离	结构化方案设计

3.4.4 最佳实践原则

1. 从简单开始

先实现基础版本，再逐步优化。不要一开始就追求完美的上下文架构，而是先用最简单的方案验证核心功能。简单方案更容易调试，能快速暴露真实问题。过早优化往往导致对错误问题的过度工程化。

2. 数据驱动

基于数据和评估做决策，而非直觉。建立评估基准，记录每次改动的效果。很多"看起来更好"的改进实际上没有提升甚至适得其反。只有数据才能告诉你真相。定期回顾指标，用 A/B 测试验证假设。

3. 模块化设计

各策略独立实现，便于替换和升级。检索、压缩、结构化等模块应该解耦，通过清晰的接口交互。这样可以独立测试、独立优化，也方便在技术迭代时替换单个组件而不影响整体系统。

4. 持续迭代

上下文工程是持续优化的过程。用户需求会变化，业务数据会增长，模型能力会升级。定期审视现有方案，识别新的优化机会。建立反馈闭环，将生产环境的问题和用户反馈转化为改进行动。

5. 关注端到端

最终指标是用户体验，而非中间指标。检索召回率很高但用户不满意，说明某个环节有问题。不要沉迷于优化某个子指标而忘记最终目标。建立端到端评估机制，确保各环节的优化最终转化为用户价值。

3.4.5 团队协作

上下文工程通常涉及多个角色：

• AI 工程师：实现核心策略和系统

• 数据工程师：处理数据流水线和存储

• 产品经理：定义需求和评估标准

• 领域专家：提供专业知识支持

3.4.6 实战案例库

以下案例展示了上述方法论在真实场景中的应用：

案例 A：企业级知识库检索系统（Enterprise Knowledge Base）

背景：某大型制造企业拥有海量内部文档（Wiki、技术手册、维修记录），员工需要快速查找解决生产线问题的方案。

挑战：

• 信息孤岛：数据分散在 SharePoint、Confluence 和文件服务器。

• 专业术语多：通用模型难以理解内部缩写（如 "ABC-123 故障"）。

• 权限复杂：不同层级员工可见内容不同。

上下文工程方案：

1. 需求分析：确认为"检索密集型"任务，准确性优先于创造性。

2. 设计：采用 RAG 架构，配合混合检索（Hybrid Search）。

   • 分层：

     • 系统层：固定的企业安全规范和输出格式。

     • 知识层：动态检索的文档片段（Top-5 chunk）。

     • 任务层：用户当前的查询和元数据（部门、设备ID）。

3. 关键实现：

   • 术语增强：在写入阶段，利用 LLM 将内部缩写扩展为全称，建立同义词库。

   • 权限过滤：在检索阶段（Pre-retrieval），根据用户 ID 过滤索引，确保不出权限。

4. 评估指标：

   • Recall@5 从 45% 提升至 82%。

   • 用户满意度（CSAT）从 3.2 提升至 4.7。

案例 B：多智能体协作编程（Collaborative Coding Agents）

背景：一个致力于自动化代码生成的开源项目，使用多个智能体协同完成从需求分析到代码实现的流程。

挑战：

• 上下文传递丢失：产品经理智能体的详细需求，传到开发者智能体时变得模糊。

• 幻觉累积：早期的错误理解在后续环节被放大。

• 上下文超限：多轮协作后，完整的对话历史迅速撑爆窗口。

上下文工程方案：

1. 隔离与结构化：

   • 使用标准化的 JSON schema 定义 Agent 间的通信协议。

   • 每个 Agent 只接收与其职责相关的上下文片段（Context Slicing）。

2. 压缩与检查点：

   • 在交接点（Hand-off）引入"总结者 Agent"，将上一步的输出压缩为"已确认的决策点"。

   • 必须包含的锚点信息（如技术栈版本、核心 API 签名）始终保留，不被压缩。

3. 效果：

   • 复杂功能一次通过率（Pass@1）提升 40%。

   • Token 消耗降低 60%。

建立清晰的协作机制和责任分工，是大规模上下文工程项目成功的关键。