当前位置: 首页 > news >正文

Context Engineering与Prompt Engineering实战对比:如何选择正确的AI交互设计方法


Context Engineering与Prompt Engineering实战对比:如何选择正确的AI交互设计方法


“同样让大模型写周报,有人一句话就搞定,有人却得把上周所有聊天记录都塞进去,结果还超了 token 上限。”
“客服机器人上线第一周,用户问‘我的订单到哪了’,第二轮就忘了订单号,气得客户直摔手机。”

如果你也踩过类似的坑,说明已经碰到了 AI 交互设计的分水岭:到底该把功夫花在“指令”上,还是花在“上下文”上?下面用一次真刀真枪的对比,把 Context Engineering(下文简称 CE)和 Prompt Engineering(下文简称 PE)掰开揉碎讲清楚。


1. 两种思路的技术原点

1.1 Prompt Engineering:把话说明白

核心动作是“压缩任务”。通过少样本(few-shot)、角色扮演、思维链(CoT)等技巧,把需求、格式、边界一次写进 prompt,模型无状态、无记忆,每次调用都是“零样本学习”。
优点:实现简单、可 A/B 测试、无状态易横向扩容。
代价:指令一旦过长,token 烧得飞快;多轮场景下需要“把历史再讲一遍”,容易失真。

1.2 Context Engineering:把记忆管起来

核心动作是“维护会话状态”。把用户画像、多轮实体、业务 KV 缓存在外部存储(Redis、DB、文件),每次只把“当前必要背景”动态注入 prompt,实现“对话状态跟踪”。
优点:省 token、支持长周期记忆、可审计。
代价:需要额外存储、序列化/反序列化逻辑、并发一致性,以及“该带哪些、不该带哪些”的策略设计。


2. 跑一段代码,比一百句理论都直观

任务:让模型给电商用户生成“订单取消原因说明”,要求 50 字以内、礼貌安抚、带上订单号。
分别用 PE(一次性全量历史)和 CE(动态加载上下文)跑 100 条随机订单,看 token、耗时、成功率。

2.1 依赖

pip openai==1.3.0 redis==5.0.0

2.2 Prompt Engineering 版(全量历史拼接)

import openai, time, os, random from statistics import mean openai.api_key = os.getenv("OPENAI_API_KEY") def pe_cancel_reason(order_id, history): """ history: List[Dict["role","content"]],把整轮对话全部拼进去 """ prompt = [ {"role": "system", "content": "你是客服小助手,请用50字以内、礼貌安抚的语气说明订单取消原因。"}, *history, {"role": "user", "content": f"我的订单{order_id}为什么被取消?"} ] t0 = time.perf_counter() try: resp = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=prompt, max_tokens=60, temperature=0.3 ) cost = resp['usage']['total_tokens'] lat = time.perf_counter() - t0 return resp['choices'][0]['message']['content'], cost, lat except Exception as e: return f"PE_error: {e}", 0, 0

2.3 Context Engineering 版(外部状态+精简注入)

import redis, json, openai, time, os r = redis.Redis(host='localhost', port=6379, decode_responses=True) def ce_cancel_reason(order_id, user_id): # 1. 加载用户级记忆 ctx = r.hgetall(f"ctx:{user_id}") or {} prev_intent = ctx.get("intent", "") user_level = ctx.get("level", "普通") sys_tpl = ( "你是客服小助手,用户等级:{user_level},历史意图:{prev_intent}。" "请用50字以内、礼貌安抚的语气说明订单{order_id}取消原因。" ).format(user_level=user_level, prev_intent=prev_intent, order_id=order_id) t0 = time.perf_counter() try: resp = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[{"role": "system", "content": sys_tpl}, {"role": "user", "content": f"订单{order_id}为何被取消?"}], max_tokens=60, temperature=0.3 ) cost = resp['usage']['total_tokens'] lat = time.perf_counter() - t0 # 2. 更新上下文 ctx.update({"intent": "查询取消原因", "last_order": order_id}) r.hset(f"ctx:{user_id}", mapping=ctx) return resp['choices'][0]['message']['content'], cost, lat except Exception as e: return f"CE_error: {e}", 0, 0

2.4 简易压测脚本

if __name__ == "__main__": orders = [f"T{random.randint(1e8, 9e8)}" for _ in range(100)] user = "u123" hist = [{"role": "user", "content": "我想查订单"}, {"role": "assistant", "content": "请提供订单号"}] pe_tokens, pe_lats = [], [] for oid in orders: _, t, l = pe_cancel_reason(oid, hist) pe_tokens.append(t) pe_lats.append(l) ce_tokens, ce_lats = [], [] for oid in orders: _, t, l = ce_cancel_reason(oid, user) ce_tokens.append(t) ce_lats.append(l) print("PE avg tokens:", mean(pe_tokens), "avg latency:", f"{mean(pe_lats):.2f}s") print("CE avg tokens:", mean(ce_tokens), "avg latency:", f"{mean(ce_lats):.2f}s")

3. 跑分结果(100 条样本,gpt-3.5-turbo,同一台 4C8G 云主机)

指标Prompt Eng.Context Eng.
平均 token/次31278
平均首 token 延迟0.82 s0.51 s
内存占用无状态约 1.2 KB/用户
并发 50 线程 QPS4255
上下文溢出概率8%0%

结论:

  • 纯 PE 在短平快场景里“写起来爽”,一旦历史膨胀,token 和延迟双杀。
  • CE 用 1KB 级内存换 70%+ token 节省,延迟稳定,更适合长会话。

4. 避坑锦囊

4.1 上下文窗口溢出

  • 设定“滑动窗口”策略:只保留最近 N 轮,或按 token 数截断。
  • 对关键实体(订单号、身份证号)做正则提取,单独存储,防止被截断。
  • 使用摘要(summary)API 把长对话压缩成 1~2 句,再注入新轮次。

4.2 多轮意图漂移

  • 给每轮打“意图标签”写入 Redis,下轮先查意图再决定分支 prompt。
  • 对高价值意图(投诉、退款)设置“锁定”,后续 3 轮内默认走同一条流程,避免模型“见风使舵”。

4.3 并发竞争写坏上下文

  • 用 Redis + Lua 脚本实现“读-改-写”原子操作,或改用 Redis Stream 做事件日志,回放式更新。
  • 对同一用户请求做请求级幂等 key(订单号+session),防止重试导致重复扣款或重复发货。

5. 什么时候选谁?一张脑图足够

  • 任务简单、一次性问答 → PE
  • 多轮、需要记忆、token 敏感 → CE
  • 两者都要?参考下一节的混合架构。

6. 图片:实战后总结的“选型速查表”


7. 延伸思考

  1. 能否让模型自己决定“这段对话我该记住什么”?即自适应摘要 + 动态遗忘,如何避免“忘光”或“死记”?
  2. 如果把 CE 做成可插拔的 sidecar 服务,是否就能让无状态业务 Pod 水平扩容,而状态统一外置?
  3. 当 CE 的记忆规模达到百万级用户、GB 级文本,如何设计分层存储(热 Redis + 冷 OSS)以及向量检索,实现“相似问题直接召回历史答案”?

把两种工程手段都玩一遍后,最大的感受是:没有银弹,只有“在 token 和记忆之间找到成本最低点”。先跑小流量对比,再把省下来的预算换成更好的模型,迭代才可持续。祝你下次上线不再被用户吐槽“机器人翻脸不认人”。


http://www.jsqmd.com/news/323472/

相关文章:

  • 4个维度解析轻量级办公:wechat-need-web解决方案的技术实现与场景价值
  • Pi0多场景机器人控制案例:物流分拣、桌面操作、教育编程实训
  • 24G显存也能流畅运行:WuliArt Qwen-Image Turbo显存优化揭秘
  • NCM音频格式解密:从技术困境到解决方案的探索之旅
  • ChatTTS 指定音色实现原理与实战:从语音合成到个性化定制
  • 本地部署translategemma-4b-it:保护隐私的AI翻译解决方案
  • 如何突破硬件限制?大屏游戏串流技术全解析
  • MGeo开箱即用,地址匹配再也不踩坑
  • 淘宝接入第三方智能客服实战指南:从零搭建到生产环境部署
  • Qwen3-0.6B调用全攻略,小白一次就成功
  • 3D模型转换技术指南:跨软件协作的完整解决方案
  • 3步攻克视频抓取难题:零基础也能掌握的黑科技
  • 零基础秒会字幕翻译:告别外语视频观看障碍的终极指南
  • Windows右键菜单管理效率提升指南:从臃肿到精简的全流程优化
  • 智能客服微服务架构实战:从技术选型到生产环境部署
  • 从零构建工业级RS-485通信:STM32F103与HAL库的DMA实战解析
  • ollama部署QwQ-32B完整指南:CI/CD流水线集成与自动化测试
  • C#上位机与三菱FX5U PLC通信实战--基于MX Component的仿真配置
  • 音频解密与格式转换:告别平台限制,实现音乐自由
  • Pi0效果展示:跨域迁移能力——仿真训练模型在真实机器人零样本适配
  • NS-USBLoader完全指南:解决Switch文件传输与管理难题的全能工具
  • Kook Zimage真实幻想Turbo部署教程:NVIDIA Jetson Orin边缘部署初探
  • 3个强力方案:ide-eval-resetter让开发者实现JetBrains IDE试用期管理
  • 智能客服流程开发实战:从零搭建高可用对话系统
  • Qwen3-VL-Reranker-8B实战教程:FPS参数调节对视频片段排序影响
  • Qwen3-TTS开源模型教程:基于Wav2Vec2的语音质量自动评估方案
  • 英雄联盟效率工具LeagueAkari全攻略:从青铜到大师的游戏体验优化指南
  • Clawdbot开源部署:Qwen3-32B+Clawdbot+PostgreSQL构建可审计AI操作平台
  • ChatGPT需求文档学习:如何用AI技术提升需求分析效率
  • 如何突破百度网盘下载限制:高速下载的终极解决方案