otter_ai干这一行越久，越发现一个反常识的现象：很多人一提到"让AI变强"，第一反应就是微调。预算充足的直接上万卡全参预训练，预算紧一点的也起码做个LoRA，似乎不把模型拿去训练一轮，就不算真正在做事。但过去这半年，我在一个智能体项目里彻底改了想法——靠上下文工程，完全不碰权重，也能让通用大模型干出接近定制模型的效果，而且迭代速度实打实提上来了。我的项目打磨周期从按周算，变成了按天算，有时候一个下午就能完成一轮完整的效果改进。
前阵子圈里传了不少那类通用智能体项目的上下文管理思路，标题动不动就是"不微调也能提速10倍"。数字虽然夸张，但底层逻辑我觉得是站得住的。今天就把我怎么理解、怎么搭、怎么踩坑的整套东西整理出来，讲透上下文工程到底在解决什么问题、适用什么人、怎么落地，以及什么时候你该老实回去微调。
1. 为什么"不微调"反而更快：上下文工程的基本盘
1.1 微调的真实代价
先算一笔账。假设你想让模型学会某种特定业务风格，标准微调流程是：收集几千到几万条高质量样本、逐条清洗和标注、准备训练脚本、跑LoRA或者全参训练、做一套评估、还得防灾难性遗忘。光数据准备这一步，团队里至少一个人要投入两到三周，还不算中间返工。
最难受的不是时间，是"改需求"。老板看完第一版效果说"语气再专业一点""这个场景反应要更谨慎"，你要重训。LoRA还好，重新跑几小时能出结果，但数据要重新标、Prompt要跟着调，整个链路重新走一遍。全参微调更不用提，一次训练烧掉的钱和卡，够买几台像样的工作站。
上下文工程就不一样了。不碰权重，不准备训练集，改的就是"每次调用模型时喂进去的上下文"。想调整行为，改几段文字、调两个示例就行，部署上就是改配置。这个差异在"快速试错"阶段是致命的。
我一直跟团队说：微调是重武器，适合你已经确认方向、需要把特定能力固化下来的阶段；上下文工程是轻步兵，适合需求还在变、方向还没定型的阶段。大多数项目前期根本不该碰微调。
1.2 上下文工程到底在做什么
上下文工程这个词听起来玄乎，说白了就是：你决定模型每次能看到什么、先看什么后看什么、哪些信息必须强调、哪些信息要裁剪掉。它管的是"模型视野"，而不是"模型能力"。
我习惯用类比来解释。把大模型想象成刚入职的顶级咨询顾问，脑子非常好使，但每次进会议室你只能给他一叠材料，他看完材料就发言。微调等于送他去进修三个月，改变他本身的判断习惯；上下文工程等于精心准备每一场会议的材料——哪些数据放第一页、哪些目标写进会议开场、哪些案例附在末尾。
现代大模型的推理能力其实已经足够强，很多"看起来不聪明"的表现，本质上是材料没给够、给错了顺序、给了互相矛盾的指令。上下文工程就是在解决这个"信息投喂"的质量问题。它不改变模型的底色，但能让模型把已有的推理能力全部发挥出来。
1.3 "迭代速度提升10倍"是怎么算出来的
标题里的10倍不是玄学，我拆着算一下你就明白。
传统微调一次完整迭代：数据收集2~3周 + 清洗标注1周 + 训练1~7天 + 评估调优1周，取一个紧凑节奏也要4~6周，平均算5周。
上下文工程一次迭代：改系统提示词模板（小时级）+ 加两条示例（分钟级）+ 跑一轮回归用例（小时级），正常一天内完成，快的时候半小时。5周对半天，差别是几十倍的量级。哪怕你每次改完还要做多场景回归、写评估脚本，一个迭代周期控制在3天内也完全没问题。比起微调，说"提升10倍"都是保守的。
这里有个前提：项目跑在足够强的通用模型上，推理能力不能掉链子。你要是拿一个能力很弱的基座模型硬扛复杂任务，上下文工程能做的非常有限，这个边界我在第4章会展开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心拆解：某通用智能体项目式上下文工程的五层结构
我参考了那类通用智能体项目公开分享的思路，再结合自己的实践，把上下文工程拆成五层。每一层管一件事，合起来就是一套能稳定落地的完整方案。
2.1 第一层：角色与目标的强约束
很多人写系统提示词就是一句话"你是一个助手"，这远远不够。一个合格的顶层指令要同时包含四个要素：角色的能力边界、交付物的形态、衡量成功的标准、不允许做的事情。
举个例子，我做合同审查助手时，顶层指令写的是：
text复制你是合同审查助手，只负责租赁合同与采购合同两类文书的合规风险识别。
输出必须包含：风险等级（高/中/低）、风险条款原文位置、法规依据、修改建议。
禁止输出：与合同无关的法律意见、格式美化建议、超出给定文本范围的推测。
当你无法在文本中找到明确依据时，必须明确标注"存疑"。
这条提示词值多少？值几千条标注数据。因为它直接把模型的输出空间从"开放域"压缩成"限定域"，行为约束效果接近微调，但成本趋近于零。
这里我踩过一个坑：最初只写了正向要求，没写"禁止"清单。结果模型总爱自作主张加建议，跑了一批测试才发现。谁都不想让模型在客户场景里多嘴，所以"负面清单"一定要写，而且要写得具体。别写"要谨慎"这种空话，要写"禁止输出XX类型内容"这种具体条目。
2.2 第二层：动态记忆的分级管理
Agent类项目最头疼的是上下文里塞了太多历史对话，模型越到后面越"傻"。这类方案的核心思路，是把记忆分级：
- 工作记忆：当前用户对话、当前工具返回值，完整保留，不加压缩。
- 短期记忆：最近几轮的关键结论，用结构化摘要存，替代原始对话。
- 长期记忆：用户画像、历史偏好、业务规则，每次从库里按需检索，动态组装进上下文。
实际落地我建议维护三个变量：
javascript复制const contextState = {
workingMemory: [], // 当前轮次的原始消息，最多保留 N 条
shortTermSummary: "", // 每轮结束更新的压缩摘要
longTermProfile: {} // 用户维度的高频事实，持久化存储
};
关键动作：每轮对话结束时，把本轮新结论合并进 shortTermSummary，并截断工作记忆。这样不管用户聊了多长，喂给模型的有效上下文永远是"摘要 + 最近几轮 + 本轮信息"，长度可控，核心信息不丢。
2.3 第三层：工具调用的Schema注入
智能体只要会调工具，上下文工程的重点就要覆盖"如何让模型正确选择并调用工具"。很多项目失败的根因，是工具定义写得像标准API文档，模型根本看不懂什么时候该用。
好的工具描述要回答三个问题：这个工具什么时候用？入参分别是什么含义？返回值长什么样、拿到之后怎么用？我的一个小技巧，是给每个工具加一句"典型使用场景"：
javascript复制const tools = [
{
name: "query_stock_price",
description: "查询指定股票的最新价格。当用户询问某只股票的当前行情、涨跌幅时使用。示例：用户说\"帮我看看XX现在的价格\"，应调用本工具并传 stock_code=600519。",
parameters: {
type: "object",
properties: {
stock_code: { type: "string", description: "六位股票代码" }
}
}
}
];
就加了一句示例话术，工具调用准确率在我一个项目里从78%涨到93%。不需要微调，只需要把工具Schema当作"说明书"来写，而不是"接口文档"来写。
2.4 第四层：Few-shot示例的按需挑选
Few-shot是上下文工程里性价比极高的手段，但直接塞一堆示例会适得其反。核心是"按需挑选"：根据当前请求的特征，从示例库里匹配最相关的2~4条示例，而不是每次都带全部。
示例库按场景打标签，比如"合同审查-租赁-高风险""客服回复-退款-情绪安抚"。来了一个请求，先做意图分类和关键词匹配，再取出对应的示例组。示例数量少、相关性高，模型模仿的准确度反而比堆30条无关示例更好。
另外注意，示例的格式必须和期望输出的格式严格一致，包括标点、换行、标题层级。模型对格式异常敏感，你示例里用了一级标题，它输出就爱用一级标题。这份"格式强迫症"可以反过来利用——用示例精确定义输出风格。
2.5 第五层：输出格式的结构化约束
最后一层是让模型输出能够被稳定解析的格式。我的选择是：能用JSON Schema就用JSON Schema，并要求模型先输出一个"思考摘要"再输出结构化结果，稳定性提升明显。
text复制请你按JSON格式输出，结构严格遵循：
{
"thinking_summary": "用一两句话说明你判断的依据",
"risk_list": [
{
"level": "高/中/低",
"reason": "风险描述",
"evidence": "原文摘录",
"suggestion": "修改建议"
}
]
}
"先思考再结构化"这个技巧看着简单，但在复杂任务里能显著减少"编造字段"和"字段值不合法"的问题。原理不复杂：模型先把推理过程固定在短文本里，再生成结构化内容时就有据可依。实测下来，我项目里的字段合法性错误率下降了大约六成。
3. 实操落地：一整套可直接参考的上下文管理方案
光讲概念是空中楼阁。这部分我把自己项目中真正跑起来的一套方案完整拆开，你可以照着搭。
3.1 模块化系统提示词模板
千万别把所有指令写成一大坨文本，维护到后面你会崩溃。我按功能拆模块，运行时再按需拼接：
text复制[角色定义模块]
[能力边界与负面清单模块]
[任务流程模块：收到请求后先做什么再做什么]
[输出格式模块]
[知识引用规则模块]
拼装顺序有讲究。实测下来，"角色定义"放最前、"知识引用规则"放最后、中间放"任务流程"效果最好。这个顺序和大模型的注意力分布规律有关——文本开头和结尾的内容被"记住"的概率最高，所以最重要的身份声明放开头，最需要严格遵守的边界规则放结尾，中间放流程细则。
提示：每次调整模块内容后，保留一个历史版本记录。上下文工程最大的隐形风险不是改错，而是改来改去找不到"上一版其实效果更好"的版本。做个简单的版本日志能救命。
3.2 会话上下文的压缩与摘要策略
长对话场景，我推荐两条路配合用。
一条是"滚动窗口 + 半程摘要"。对话超过阈值后，把前一半原文替换成一段摘要，后一半保留原文。这样模型短期内能精确引用最近内容，同时不丢失整段对话的来龙去脉。阈值建议按Token算，我常用的配置是：总上下文预算1.2万Token，历史摘要压到4000以内，原始对话留6000，输出预留2000。
另一条是"关键结论提取"。每一轮结束后，用一个小模型或正则辅助，抽取出本轮必须长期记住的事实（用户身份信息、偏好、达成的约定），写进长期档案。注意定期做"档案去重"，不然重复信息会在几轮之后把窗口撑爆。
3.3 Token预算分配与成本控制
这个表格是我在项目里定的默认预算模板，你可以按成本需求调整：
| 区块 | 预算占比 | 说明 |
|---|---|---|
| 系统提示词 | 10%~15% | 尽量别超过，过长会挤占示例和对话空间 |
| 示例与工具定义 | 20%~30% | 按需装载，不用一次性全塞进去 |
| 历史对话与摘要 | 30%~40% | 用摘要压缩，避免原始全文堆叠 |
| 当前输入与工具结果 | 20%~30% | 当前任务的核心信息，优先级最高 |
| 输出预留 | 至少15% | 预留不够回答会被截断，这是新手最容易忽略的 |
预算之外提一个点：上下文内容一定要定期"体检"。跑一批真实请求，统计每块的Token消耗、哪些内容实际被模型引用。很多时候你会发现示例占了20%却从未被命中，果断砍掉，换成更相关的，效果立刻回升。
3.4 验证效果：最少可行的评估集
上下文工程迭代快，但没有评估就是盲改。我的建议是：维护一个50~80条的迷你评估集，覆盖项目最核心的场景，每次改完上下文就跑一遍。
评估集不用复杂，按三个维度打分：准确率（关键字段是否正确）、格式合规率（输出能否被稳定解析）、风格符合度（语气与业务风格是否一致）。跑完看哪些用例挂了，反向定位是上下文哪一层出了问题。
我自己踩过的教训是：别靠两三条用例反复测。模型推理有随机性，几条用例通过不代表整体稳定。这个迷你评估集虽然土，却是上下文工程里最能防止"自我感觉良好"的工具。
4. 踩坑记录与排查实录
这部分全部是真金白银换来的经验，整理成问题速查，按症状排查就行。
4.1 症状一：对话超过十轮，模型开始"失忆"
现象：用户之前提过的事实，后面模型忘了，甚至前后矛盾。
排查路径：
- 先看上下文组装逻辑，是不是工作记忆被截断后没有保留关键结论。
- 再看摘要更新逻辑，是每轮都更新，还是攒了几轮才更新？我最初在整轮对话结束时做摘要，漏信息概率很高；改成"每轮用户输入前"先合并上一轮结论，漏信息问题基本消失。
- 最后检查长期档案有没有实际写入，很多时候是逻辑写了但存储键用错了，导致读完写不进。
处理：把上下文状态可视化。每个请求进来都记录"当前喂了什么给模型"，一眼就能看出是谁把关键信息丢了。
4.2 症状二：加了示例反而更差
现象：从3条示例加到6条，准确率不升反降。
原因多半是示例之间风格矛盾，或者示例与当前任务相关性差。模型在矛盾信息里会随机挑一个模仿，表现自然飘。
处理：示例宁缺毋滥。每个场景最多保留4条，每条都要标注"这个示例解决什么问题"。跑分时按"加法"和"减法"两个方向都测——删掉某条示例看分数是升是降，用数据决定去留。
4.3 症状三：输出合法但答案"不像人话"
现象：JSON结构全对、字段都对，但读起来机械感很强，客户不满意。
这是只做结构化约束、没做风格约束的典型问题。解决：在顶层指令里加一行"表达风格"要求，或者在示例里放两条"语气自然"的参考回答。更直接的做法是要求模型先写一版人话，再压缩成字段。虽然多一个步骤，但对体验要求高的场景完全值得。
4.4 什么时候该认输：上下文工程的上限
说点实在的。上下文工程不是万能的，如果你撞上以下几种情况，建议认真考虑微调：
- 需要模型掌握某种上下文无法描述的微弱信号，比如特定领域极其细微的风格差异。
- 每次请求都要携带海量固定知识，上下文预算根本装不下，压缩又会损失关键信息。
- 推理成本已经高到无法承担，而微调后的模型能大幅降低每次调用的Token消耗。
我的判断标准很简单：如果同一个Prompt改了三轮，评估分数还在原地打转，那问题大概率不在上下文，而在模型本身。这时你需要的不是更多技巧，而是换个更强的模型，或者老实做微调。上下文工程是放大器，不是无中生有的魔法。
4.5 一次完整调试案例：从82%到96%
最后分享一个具体案例。某项目在做客服工单自动分类，最初系统提示词只写了角色和目标，评估得分82%。
问题定位：错误集中在两类。一是"退款"和"退货"两个概念经常被混在一起，二是长文本工单里关键信息被无关内容淹没，模型抓不住重点。
处理过程：第一步，在负面清单里加一条"退款指资金返还，与退货（实物寄回）严格区分"；第二步，加两条示例，全部来自混淆最严重的真实工单；第三步，调整上下文顺序，把"工单摘要"提到"工单全文"之前，保证模型先看到提炼后的关键信息。
三轮改动后，评估分数从82%涨到96%。全程没碰权重、没写一行训练代码，耗时约两个下午。这种"改文本就提分"的体验，就是上下文工程最直接的价值证明。
5. 最后想说的
上下文工程不是什么玄学，背后是"注意力资源分配"这么一件朴素的事。模型变强不一定归功于调参或训练，很多时候只是因为你终于把"该看的信息"和"不该看的信息"在上下文窗口里摆对了位置。
我个人体会最深的，是这套方法对协作方式的改变。以前改效果像走流程——提需求、攒数据、排队训练；现在更像是写作——写清楚、写精炼、写对位置。门槛低了，参与的同事反而多了，想法验证得也快了。
如果你手上正好有个智能体项目卡在"效果不行"的瓶颈期，先别急着上微调。花一个下午把你喂给模型的上下文结构重新梳理一遍，给每一层做减法，你会发现：先管好模型眼前看到的东西，往往比给它换一副大脑更实际。