1. 项目概述：当Agent开始“记不住事”，我们到底在压缩什么？
你有没有遇到过这样的情况：一个精心设计的Agent，在处理一份30页的PDF合同分析任务时，前20页还能条理清晰地提取条款、比对风险点，到了第25页突然开始胡说八道，把“违约金上限为合同总额5%”错记成“无上限”；或者在多轮客服对话中，用户反复强调“不要推荐蓝牙耳机”，Agent却在第7轮又热情安利了一款——不是它不聪明，是它的“短期记忆”被撑爆了。这背后，就是标题里那个看似技术、实则决定成败的核心问题：Agent上下文工程。
这个词最近半年在一线开发圈里热度飙升，但它绝不是“提示词工程”的简单升级版。提示词工程解决的是“怎么问”，而上下文工程解决的是“能记住多少、记住哪些、怎么记得牢”。尤其在长任务场景下——比如法律尽调、医疗病历分析、跨周项目进度追踪、复杂工单闭环处理——Agent面对的不是单句提问，而是一整套动态演进的信息流：原始文档、中间推理草稿、用户实时反馈、历史决策记录、外部知识检索结果……所有这些，都要塞进大模型那有限的上下文窗口里。这个窗口，就是我们常说的上下文预算，它不是内存大小，而是模型一次“凝神思考”所能承载的信息总量上限。主流开源模型如Qwen2-72B、Llama3-70B，上下文窗口标称128K，但实测中有效信息密度往往只有60%~70%，真正能稳定支撑复杂推理的“安全预算”可能只有70K tokens。而一个带格式的PDF解析后文本，轻松就占掉20K；一次完整的Chain-of-Thought推理链，再吃掉15K；再加上系统指令、工具调用描述、历史对话摘要……预算红线，分分钟被踩穿。
所以，“上下文压缩”根本不是为了省几个token，而是为了在有限的认知带宽内，保核心、舍冗余、建索引、留线索。它考验的不是算法技巧，而是对任务本质的理解力：哪些信息是推理的“氧气”，哪些只是背景噪音？哪些必须原样保留（比如法律条款中的精确数字和引用编号），哪些可以安全概括（比如用户情绪描述中的形容词堆砌）？压缩后的效果，也不能只看“是否还通顺”，而要回归业务目标：合同审查的漏检率是否上升？客服响应的重复确认次数是否增加？这就是效果验证的硬核所在——它不是测模型输出的流畅度，而是测Agent在真实工作流中完成任务的鲁棒性。这篇文章，就是我过去三个月在三个生产级Agent项目里，从踩坑到建立标准流程的实战手记。不讲虚的理论，只说我们每天在调试日志里看到的、在A/B测试报告里确认的、在客户投诉回溯中定位到的具体问题与解法。如果你正在开发需要处理长文档、多轮交互或复杂状态的Agent，这篇内容就是你明天早会就能直接拉出来讨论的Checklist。
2. 核心思路拆解：为什么不能只靠“删减”和“摘要”？
刚接触上下文工程时，我和很多开发者一样，第一反应就是“上摘要模型”。找一个号称“专精长文本压缩”的LLM，把10万字的财报喂进去，让它吐出5000字摘要，再把摘要塞给主Agent。听起来很美，实测下来，效果惨烈。我们在一个金融风控Agent项目里做过对照实验：用Qwen2-72B自身做摘要，输入120K tokens财报，输出4800 tokens摘要，再让同一模型基于摘要做风险评级。结果发现，关键风险点识别率下降了37%，尤其是“关联交易未披露”这类需要跨章节比对的隐性风险，几乎全部漏检。问题出在哪？根源在于，通用摘要模型的目标函数和Agent任务目标函数存在根本性错位。
摘要模型的优化目标是“信息保真度”和“语言流畅度”，它追求的是让人类读者看完摘要后，能大致还原原文主旨。而Agent的上下文，服务的对象是另一个模型（主推理模型），它的目标是“推理支撑度”——即这段文本能否提供足够、准确、可定位的证据，支撑模型完成特定决策。举个具体例子：原文有一段：“根据《XX条例》第3.2.1条，上市公司控股股东不得以任何形式占用公司资金。截至2024年Q1，A公司向其控股股东B集团累计拆借资金人民币2.37亿元，该款项未在2023年年报附注‘其他应收款’中列示。” 一个优秀的人类分析师会立刻抓住三个关键锚点：法规条款编号（3.2.1）、金额（2.37亿元）、违规行为（未列示）。但通用摘要模型很可能把它压缩成：“A公司存在向控股股东拆借资金且未充分披露的风险。”——法规依据没了，精确金额没了，连“未列示”这个具体违规动作都模糊成了“未充分披露”。对人类读者，这算合格摘要；对Agent，这就等于砍掉了推理的腿。
因此，我们彻底放弃了“端到端摘要”的幻想，转向一种更底层、更可控的分层压缩策略。这个策略的核心思想是：把上下文视为一个由不同功能模块组成的“工作台”，每个模块承担不同角色，压缩手段也必须按角色定制。我们将其划分为四个层级：
指令层（Instruction Layer）：包含系统角色设定、任务目标、输出格式要求、安全约束等。这是Agent的“宪法”，必须100%保留，且需前置。我们发现，把系统指令放在上下文末尾，哪怕只偏移200 tokens，也会导致模型忽略关键安全规则，比如“禁止输出用户身份证号”。因此，指令层不压缩，只做“位置固化”。
事实层（Fact Layer）：即任务依赖的原始数据，如合同文本、病历记录、用户历史订单。这是压缩的主战场，但绝非简单删减。我们采用“锚点保留+语义聚类+结构标记”三步法。锚点（如法规条款编号、医学诊断编码ICD-10、订单ID）必须原样保留；同类信息（如多个相似的用户投诉描述）聚合成一条带计数的概括句；所有结构化信息（表格、列表、代码块）必须用明确标记包裹，防止模型误读为普通段落。
推理层（Reasoning Layer）：Agent自己生成的中间步骤，如思维链（CoT）草稿、工具调用结果、多源信息比对结论。这一层最容易膨胀。我们的做法是“动态截断+证据回溯”。当推理链超过预设长度（我们设为总预算的25%），自动截断后续步骤，但强制在截断点插入一条“证据索引”，例如：“[证据索引：Table_3, Row_5] 与前述供应商资质审核结论冲突，需复核”。这样，即使后续推理丢失，主模型也能通过索引快速定位到关键矛盾点。
状态层（State Layer）：记录任务当前进展、已执行动作、待办事项、用户显式偏好（如“不要推荐蓝牙耳机”）。这是Agent的“工作备忘录”，必须高度结构化。我们不用自然语言描述，而是采用轻量级JSON Schema，例如：
{"task_progress": "step_3_of_5", "user_preferences": ["no_bluetooth_headphones"], "pending_actions": ["verify_invoice_amount"]}。JSON本身比等效自然语言节省约40% tokens，且机器可解析性100%。
这种分层思路，本质上是把“压缩”这个模糊概念，转化成了“为不同认知模块分配精准带宽”的工程问题。它不追求全局最小化，而追求局部最优化——确保每个模块拿到的，恰好是它完成自己职责所需的最少、最准信息。这比任何黑盒摘要模型都更可靠，也更容易调试和验证。
3. 核心细节解析：压缩不是艺术，是可量化的工程实践
一旦确立了分层策略，下一步就是把“压缩”这件事，变成一套可配置、可审计、可复现的工程流水线。很多人以为压缩就是调用一个API，传入文本和目标长度，坐等结果。但在生产环境里，这无异于蒙眼开车。我们花了大量时间打磨每一个环节的细节，最终形成了一套覆盖“评估-选择-执行-校验”全周期的压缩工作流。下面，我将逐层拆解其中最关键的实操细节，这些细节，都是我们在日志里反复看到、在监控大盘上反复验证过的“生死线”。
3.1 预压缩评估：先看清“病灶”，再开刀
在动任何压缩操作之前，我们强制执行一个“上下文体检”步骤。这个步骤不产出压缩结果，只产出一份详细的Token消耗热力图。它会精确告诉你，当前待处理的上下文里，每一类信息各占多少tokens，以及它们的“信息密度”如何。我们使用自研的ctx-analyzer工具（基于HuggingFace的transformers库，针对主流tokenizer做了适配），输入原始上下文，输出一个结构化报告。报告包含三个核心维度：
来源分布（Source Breakdown）：明确区分指令、原始文档、历史对话、工具返回、用户输入等不同来源的token占比。在我们的电商客服Agent中，曾发现一个严重问题：工具调用返回的JSON数据，因未做格式化（minified），包含了大量无意义的空格和换行，占用了12%的总tokens。修复方法极其简单：在工具调用后、注入上下文前，加一行
json.dumps(response, separators=(',', ':'))，立竿见影节省了近1500 tokens。语义密度（Semantic Density）：通过计算每100 tokens内出现的实体（人名、地名、数字、专业术语）数量，粗略评估信息浓度。低密度区域（如大段的客套话、重复的免责声明、模板化邮件开头）是首要压缩目标。我们设置了一个阈值：密度低于0.8（即每100 tokens少于0.8个实体）的段落，自动标记为“高冗余候选区”。在法律合同分析中，这部分通常占全文15%~20%，删除后对核心条款识别率零影响。
结构冗余（Structural Redundancy）：专门检测重复模式。比如，一份采购订单可能有50行商品明细，每行都以“Item #X: ”开头。
ctx-analyzer会识别出这个前缀模式，并计算其总开销。在实际项目中，我们发现仅“Item #”这个固定前缀，在一份含200行的订单里就浪费了近900 tokens。解决方案不是删除，而是用结构化标记替代：“[ITEM_LIST_START]...[ITEM_LIST_END]”，并附上元数据{"count": 200, "fields": ["name", "qty", "unit_price"]}。这不仅节省tokens，更提升了模型对列表结构的理解能力。
提示：这个“体检”步骤绝不能跳过。我们曾在一个政府公文分析项目里，因为没做预评估，直接对一份含大量扫描件OCR文本的文件进行通用摘要，结果OCR识别错误（如“第十五条”被识成“第+五条”）被摘要模型平滑掉，导致法规引用完全失效。事后回溯，体检报告早已标红预警：“OCR文本密度异常低（0.2），疑似识别错误高发区”。一次5分钟的体检，避免了两天的返工。
3.2 压缩算法选型：没有银弹，只有场景匹配
市面上的压缩方案五花八门，从规则引擎到微调小模型，再到RAG重排。我们的原则是：能用规则解决的，绝不上模型；能用轻量模型的，绝不上大模型。以下是我们在不同场景下验证有效的选型逻辑与参数配置：
纯规则压缩（Rule-based Compression）：适用于指令层、状态层及高度结构化的事实层（如JSON、XML、表格）。核心是正则表达式与语法树遍历。例如，压缩一段包含大量
<p>标签的HTML合同文本，我们不用LLM，而是用BeautifulSoup解析DOM，只保留<p>、<h2>、<table>等语义标签，移除所有<div class="footer">、<span style="color:gray">等装饰性标签。实测下来，对一份50页HTML合同，规则压缩可稳定节省35%~40% tokens，且100%保真。关键参数是“保留标签白名单”，我们将其固化为配置项，不同业务线可按需调整。嵌入向量重排（Embedding-based Re-ranking）：这是处理长文档（如PDF、Word）最有效的方案，远超通用摘要。其逻辑是：先用Sentence-BERT等模型，将文档切分成句子/段落后，计算每个片段与当前任务Query的语义相似度，然后按相似度降序排列，取Top-K片段拼接。这里的Query不是用户原始问题，而是我们构造的“任务意图向量”，例如，对于“找出所有违约责任条款”，Query是
"contract clause + liability + breach + penalty"。我们对比了多种嵌入模型，最终选定all-MiniLM-L6-v2，原因很简单：它在100ms内完成1000个句子的向量化，而text-embedding-3-large虽然精度高5%，但耗时增加8倍，无法满足实时Agent的SLA。K值的选择有公式：K = (Target_Budget * 0.6) / Avg_Tokens_Per_Segment。其中0.6是经验安全系数，Avg_Tokens_Per_Segment通过预体检获得。这个方案在法律尽调项目中，将关键条款召回率从72%提升至94%。轻量级摘要模型（Lightweight Summarizer）：仅用于无法结构化的长段落，如用户自由输入的投诉描述、专家访谈录音转文字。我们弃用了所有大模型，转而微调了一个TinyBERT（4M参数），训练目标非常明确：最大化关键实体（人名、时间、金额、地点）的保留率，而非ROUGE分数。训练数据来自历史工单，标注员只标出“必须保留的实体”，模型学习如何在压缩中“护住”这些锚点。部署后，它在保持98%关键实体的前提下，平均压缩比达到5.2:1，而Qwen2-72B的同任务压缩比仅为3.1:1，且实体丢失率高达17%。
注意：所有压缩算法都必须配置“保底机制”。例如，嵌入重排后，如果Top-K片段总tokens仍超预算，启动二级规则压缩（如移除所有形容词、副词）；轻量摘要模型输出后，强制进行NER（命名实体识别）校验，若关键实体缺失，则回退到原始片段。没有保底，就没有生产可用性。
3.3 效果验证设计：用业务指标说话，而非模型分数
这是整个上下文工程中最容易被忽视，也最致命的一环。很多团队用ROUGE-L、BLEU等NLP指标来评估压缩效果，这完全是南辕北辙。ROUGE-L衡量的是压缩文本与人工参考摘要的n-gram重合度，而我们的目标是：压缩后的上下文，能否让Agent在真实业务场景中，做出和原始上下文下一样好（或更好）的决策。因此，我们的效果验证体系，完全围绕业务漏损（Business Leakage）设计。
我们定义了三个核心验证指标，全部来自线上真实流量：
关键路径完成率（Critical Path Completion Rate, CPC）：跟踪Agent在处理长任务时，是否能顺利完成所有预设的关键步骤。例如，在保险理赔Agent中，关键路径是：
识别事故类型 → 提取医疗费用明细 → 匹配保险条款 → 计算赔付金额 → 生成拒赔/赔付理由。CPC = （成功走完全部5步的会话数 / 总会话数）* 100%。我们发现，当上下文预算紧张时，CPC会首先在第3步（匹配条款）出现断崖式下跌，因为条款引用信息被压缩丢失。CPC是我们的“血压计”，任何压缩方案上线前，必须确保CPC波动在±0.5%以内。人工介入率（Human-in-the-Loop Rate, HILR）：统计需要人工客服接手的会话比例。这是最直接的用户体验指标。在银行反欺诈Agent中，HILR从压缩方案上线前的12.3%降至10.8%，表面看是进步，但深入分析发现，下降主要来自“简单查询”类会话，而涉及“复杂交易链路分析”的会话HILR反而上升了1.2%。这说明压缩方案在简单场景有效，但在核心复杂场景失效。因此，我们要求HILR必须按会话复杂度分层统计，不能只看总体。
决策一致性指数（Decision Consistency Index, DCI）：这是最硬核的指标。我们选取一批具有明确、客观答案的历史案例（如：一份已结案的合同纠纷，其“违约方判定”有法院判决书背书），让Agent在原始上下文和压缩后上下文两种条件下，分别给出判定。DCI = （两次判定结果一致的案例数 / 总案例数）* 100%。DCI必须≥95%才能上线。在医疗诊断辅助Agent中，我们曾有一个压缩方案DCI为92%，深入排查发现，它系统性地将“糖尿病肾病（DKD）”误判为“慢性肾病（CKD）”，原因是压缩时合并了二者描述。这个发现直接推动我们为医学术语建立了专属的“不可压缩实体词典”。
验证不是一次性动作，而是持续过程。我们上线了“影子模式”（Shadow Mode）：新压缩方案与旧方案并行运行，新方案的输出不参与决策，只记录其结果并与旧方案比对。所有指标都接入Prometheus监控，设置告警阈值。当DCI连续5分钟低于94.5%，自动触发告警，通知工程师介入。效果验证，不是项目结束的仪式，而是日常运维的呼吸。
4. 实操全流程：从一份30页PDF到稳定上线的7步法
理论和细节讲得再多，不如一次手把手的实操。下面，我将以我们最近上线的一个“企业级招标文件智能分析Agent”为例，完整复现从接到需求到压缩方案稳定上线的7个关键步骤。这个Agent需要处理平均页数为32页、最大达87页的PDF招标书，从中提取：投标人资格要求、技术规格偏离表、商务条款关键点（付款方式、违约责任、知识产权归属）、评标办法细则。整个流程，我们严格遵循SOP，耗时4.5个工作日，零线上事故。
4.1 步骤一：需求解构与预算基线测定（Day 1, 上午）
这不是技术活，而是产品沟通。我们召集业务方（招标采购部）、法务、以及Agent开发负责人，共同完成一份《任务要素清单》。清单不写技术，只列业务事实：
- “投标人必须具备近3年同类项目业绩，需提供合同关键页扫描件” → 这意味着我们必须能定位并提取合同页，不能只摘要。
- “技术规格表中，带‘★’号条款为实质性要求，任何偏离即废标” → 这意味着‘★’符号及其所在行，必须100%保留，不可概括。
- “商务条款中，‘知识产权归属’条款必须原文输出，不可 paraphrase” → 这是一条硬性保真要求。
同步，我们用ctx-analyzer对10份典型招标书样本进行体检，得出初始预算基线：平均原始上下文为82,400 tokens，其中PDF文本占78%，系统指令占3%，历史对话（如有）占19%。我们设定安全目标：压缩后总tokens ≤ 65,000，为推理留出至少15,000 tokens余量。这个基线，是后续所有工作的锚点。
4.2 步骤二：分层策略设计与规则库搭建（Day 1, 下午）
基于需求清单和基线，我们设计分层策略：
- 指令层：固化位置，添加“强提醒”前缀：“【SYSTEM PROMPT - DO NOT IGNORE】...”。
- 事实层（PDF）：采用“嵌入重排 + 规则增强”双轨制。重排Query构造为：“tender document + qualification requirement + technical specification + commercial term + evaluation method”。规则增强包括：强制保留所有带‘★’的行；强制保留所有含“must”、“shall”、“prohibited”的句子；对表格，只保留表头和首行、末行数据，中间行用
[DATA_ROWS: 42]占位。 - 推理层：启用动态截断，阈值设为12,000 tokens（总预算的18%），截断点必须插入证据索引。
- 状态层：定义JSON Schema，包含
current_section（当前分析到哪一章）、extracted_entities（已提取的关键实体列表）、confidence_score（当前分析置信度）。
所有规则，全部写入YAML配置文件compression_config.yaml，版本化管理。这是可审计的源头。
4.3 步骤三：算法实现与本地验证（Day 2）
我们用Python实现了压缩流水线，核心模块：
pdf_parser.py：基于pymupdf，精准提取文本、保留字体加粗/斜体标记（用于识别‘★’）。retriever.py：加载all-MiniLM-L6-v2，实现Query向量化与余弦相似度计算。rule_engine.py：执行所有硬性规则，如正则匹配r'★.*?(?=\n|$)'提取关键条款。compressor.py：编排上述模块，按优先级执行（规则 > 重排 > 轻量摘要）。
本地用一份32页招标书测试，原始82,150 tokens，压缩后64,890 tokens，符合预算。重点验证：所有带‘★’的17行条款100%保留；技术规格表中，42行数据被压缩为[DATA_ROWS: 42]，但表头和首末行完整；系统指令位于最前端。通过。
4.4 步骤四：影子模式部署与A/B测试（Day 3-4）
将压缩流水线打包为Docker镜像，部署到测试集群。开启影子模式：Agent主流程仍使用旧压缩方案，新方案的输出仅写入日志，并与旧方案结果比对。我们选取了500份线上招标书请求，运行48小时。监控数据显示：
- CPC：新方案94.2%，旧方案94.5%，Δ=-0.3%（可接受）。
- HILR：新方案8.7%，旧方案8.9%，Δ=-0.2%（改善）。
- DCI：在50个已知答案的测试案例中，新方案一致性为96.0%，达标。
但发现一个隐藏问题：新方案在处理含大量图片的PDF时，OCR文本质量差，导致重排结果偏差。我们立即在pdf_parser.py中加入图片质量检测，对低质量图片区域，跳过OCR，改用“此处为图片，含关键资质证明”占位符。这个补丁当天下午就合入主干。
4.5 步骤五：效果验证报告与上线评审（Day 4, 下午）
生成《压缩方案效果验证报告》，核心是三张表：
| 指标 | 旧方案 | 新方案 | 变化 | 是否达标 |
|---|---|---|---|---|
| CPC | 94.5% | 94.2% | -0.3% | 是（≤±0.5%） |
| HILR | 8.9% | 8.7% | -0.2% | 是 |
| DCI | 95.2% | 96.0% | +0.8% | 是 |
| 压缩效率 | 原始Tokens | 压缩后Tokens | 压缩比 | 平均耗时 |
|---|---|---|---|---|
| 全部样本 | 82,400 | 64,890 | 1.27:1 | 1.8s |
| 关键风险点 | 检测方式 | 结果 | 应对措施 |
|---|---|---|---|
| OCR低质图片 | 图片DPI检测 | 发现12处 | 已加入占位符逻辑 |
| 法规条款编号丢失 | NER校验 | 0处 | 通过 |
| ‘★’条款遗漏 | 正则匹配 | 0处 | 通过 |
报告提交给技术委员会，5分钟内批准上线。
4.6 步骤六：灰度发布与实时监控（Day 5, 上午）
上线非全量。我们按用户地域分组，先对华东区10%的流量开放新方案。所有核心指标（CPC、HILR、DCI）实时推送到Grafana大盘，设置5分钟粒度刷新。同时，日志系统对每一条新方案处理的请求，打上compression_version:v2.1标签，便于快速回溯。灰度期间，监控一切平稳，无告警。
4.7 步骤七：全量发布与知识沉淀（Day 5, 下午）
灰度4小时后，各项指标稳定，无异常。执行全量发布。发布后，我们做的第一件事，不是庆祝，而是更新两份文档：
COMPRESSON_WIKI.md：在Wiki中新增本次招标文件压缩的专用规则，如“★条款保留逻辑”、“技术规格表压缩占位符规范”。LESSONS_LEARNED.md：记录本次踩坑：“OCR图片质量对重排效果影响巨大，后续所有PDF解析模块，必须内置DPI检测与分级处理逻辑”。
这7步，就是我们交付一个生产级上下文压缩方案的全部。它看起来繁琐，但每一步都对应着一个曾经让我们彻夜难眠的线上故障。流程不是束缚，而是把经验，变成了可复制的肌肉记忆。
5. 常见问题与独家避坑指南：那些文档里不会写的真相
在上百次的上下文工程实践中，有些问题反复出现，其根源往往不在技术，而在认知偏差或流程疏忽。我把这些血泪教训，整理成一份“避坑指南”，每一条都对应一个真实发生的线上事件。它们不是理论推演，而是日志里的截图、监控里的曲线、用户投诉里的原话。
5.1 问题：压缩后Agent“一本正经地胡说八道”，但ROUGE分数很高
现象：在新闻摘要Agent中，压缩方案ROUGE-L得分92.5，远超基线85.3。但上线后，用户投诉“把‘某公司股价大跌’摘要成‘某公司股价大涨’”。日志显示，模型在压缩时，将原文“Despite a 15% drop in share price, the company reported strong earnings...”中的“drop”错误识别为“up”，并据此生成了错误摘要。
根因分析：这是典型的语义陷阱。ROUGE只看词形匹配，不理解“despite”引导的让步状语从句。模型在压缩时，为了凑字数，优先保留了“strong earnings”这个高分词组，而丢弃了前面的否定逻辑词“despite”和“drop”。它不是变笨了，是在ROUGE的指挥棒下，学会了“作弊”。
独家解法：引入逻辑连词保护机制（Logical Conjunction Guard）。在预处理阶段，用依存句法分析器（如spaCy）识别所有逻辑连词（but, however, despite, although, because, therefore等）及其所连接的主谓宾。这些连词及其直接修饰的动词/名词，被标记为“不可压缩锚点”，强制保留。在上面的例子中，“despite”和“drop”会被一起锁定。实测后，此类逻辑反转错误归零，ROUGE-L略有下降（至91.8），但业务准确率（Business Accuracy）从78%跃升至96%。记住：当业务指标和模型指标冲突时，永远相信业务指标。
5.2 问题：压缩方案在测试集上完美，一上生产就崩
现象：一个用于分析内部Wiki知识库的Agent，本地测试100%通过。上线后，HILR在2小时内从5%飙升至35%。紧急回滚后发现，崩溃点集中在“搜索结果聚合”环节。
根因分析：测试用的Wiki样本，是工程师精心挑选的“干净”页面。而生产Wiki，充满了编辑者随手插入的“TODO: 补充XX细节”、“【草稿】请勿引用”等标记。这些标记在测试时不存在，但在线上，它们被当作正文纳入上下文，且因含有大量高频停用词（TODO, please, draft），在嵌入重排中获得了意外高分，挤掉了真正的关键内容。
独家解法：实施生产环境特征对齐（Production Feature Alignment）。在测试阶段，我们不再用“干净样本”，而是从线上流量中，随机抓取1000份真实请求的原始上下文，进行脱敏（替换敏感词为[REDACTED]），作为测试集。同时，在压缩流水线最前端，加入一个轻量级“噪声过滤器”，用正则匹配常见Wiki编辑标记（TODO.*?,\[draft\],<!--.*?-->），并将其移除或降权。这个改动，让测试与生产的gap消失了。教训是：测试环境不是越“理想”越好，而是越“真实”越好。
5.3 问题：压缩后性能提升，但Agent变得“犹豫不决”
现象：一个实时股票分析Agent，压缩后响应时间从2.1s降至1.3s，但用户反馈“它总是问我‘您能再确认一下您的风险偏好吗？’，明明我三句话前就说过了”。
根因分析：这是状态层压缩过度的典型案例。我们为了节省tokens，将用户偏好从{"risk_tolerance": "moderate", "investment_horizon": "5_years", "asset_classes": ["equity", "bond"]}压缩成了{"rt": "mod", "ih": "5y", "ac": ["eq", "bd"]}。缩写后，主推理模型无法100%确定"mod"代表“moderate”还是“modest”，"5y"是“5 years”还是“5 months”，于是它选择“安全起见”，再次询问。
独家解法：推行状态层“无损缩写”原则（Lossless Abbreviation Principle）。所有状态字段的key和value，必须使用在领域内绝对无歧义的缩写。我们为此建立了一个《领域缩写词典》，由业务方和开发共同维护。例如，在金融领域，“moderate”只能缩写为"MOD"（全大写），"5_years"缩写为"5Y"（数字+大写字母），"equity"缩写为"EQ"。词典中，每个缩写都配有唯一、明确的全称定义。任何未收录的缩写，一律禁止使用。这个原则看似死板，却彻底解决了状态信息的“失真”问题。现在，Agent的首次响应准确率稳定在99.2%。
5.4 问题：不同Agent间的压缩策略无法复用，每次都是从零开始
现象：为客服Agent开发了一套优秀的压缩方案，当想迁移到销售预测Agent时，发现80%的规则不适用，几乎要重写。
根因分析：我们犯了“只见树木，不见森林”的错误。每个Agent的压缩策略，都深深耦合在其**任务本体（Task Ontology）**上。客服关注“用户情绪”、“问题分类”、“解决方案”，销售预测关注“历史销量”、“促销活动”、“竞品价格”。压缩的焦点，必须随本体变化。
独家解法：构建任务本体驱动的压缩框架（Ontology-Driven Compression Framework, ODCF）。框架核心是一个YAML格式的task_ontology.yaml，定义了该Agent任务的全部核心概念、属性、关系。例如，客服本体：
concepts: - name: user_sentiment attributes: [intensity, polarity, trigger_phrase] - name: issue_category attributes: [primary, secondary, severity] relations: - from: user_sentiment to: issue_category type: "influences"压缩流水线的所有模块（重排Query、规则条件、状态Schema）都从这个本体中动态生成。当切换到销售预测本体时，只需更换task_ontology.yaml，整个压缩策略自动适配。我们已在5个不同领域的Agent中应用ODCF，复用率从20%提升至75%。这告诉我们：压缩不是针对文本，而是针对任务的本质。
这些问题，每一个都曾让我们焦头烂额。但正是这些“坑”，塑造了今天我们这套稳健、可扩展的上下文工程方法论。它没有魔法，只有对业务的敬畏、对细节的偏执，以及一次次跌倒后爬起来，把教训刻进代码里的坚持。
