从提示工程到上下文工程：构建真正可用的大模型应用

推荐语

从提示工程到上下文工程，揭秘构建可靠大模型应用的核心方法论。

核心内容：
1. 提示工程的局限性及工业级应用中的挑战
2. 上下文工程的关键要素与优化策略
3. 构建完整LLM应用所需的系统性能力支持

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

在过去的几年中，“Prompt Engineering（提示工程）”曾一度成为大语言模型（LLM）应用开发的代名词。然而，随着模型能力和应用复杂度的不断提升，我们逐渐意识到：“Prompt”只是冰山一角，而真正决定大模型应用效果的，是更为系统、更具工程性的“Context Engineering（上下文工程）”。

一、提示工程的局限

提示工程强调的是“任务描述”本身——如何用一句话或一段文本告诉模型你想让它做什么。在日常使用 ChatGPT 或 Copilot 时，这种方式行之有效：我们给出简短命令，模型返回结果。

但在工业级应用中，现实远比“写一个好提示”复杂得多。你需要的不仅仅是“问得对”，而是“喂得对”。也就是说，要构建一个真正可靠的 LLM 应用，核心不在于你对模型说了什么，而在于你给它什么样的上下文。

二、上下文工程：连接人、任务与模型

“上下文工程”是一种关于如何填满上下文窗口的艺术与科学。它是一门科学，因为它涉及多个要素的精心编排：

• 任务描述与说明（说明用户意图）

• 少样本示例（Few-shot）（启发模型学习）

• RAG 检索增强生成（补充外部知识）

• 多模态输入（图文、代码、表格等混合形式）

• 用户操作历史与状态（对话或任务链中的连续性）

• 工具调用接口与参数（函数调用、代码执行等）

• 信息压缩与结构化表达（保证 token 成本可控）

如果上下文太少或形式不当，模型理解力会下降；如果填入太多无关内容，不仅成本升高，还可能让模型“迷失方向”。因此，上下文工程是一项高度非平凡的优化任务。

它又是一门艺术，因为它依赖于一种新的直觉：

你需要具备一种类似“LLM 心理学”的洞察力：模型倾向于如何“思考”？它对什么样的模式、线索更敏感？如何设计提示链条，使其沿着正确的推理路径前进？这类洞察无法完全依赖规则，需要经验、直觉和反复试验。

三、上下文工程只是 LLM 应用的一部分

上下文工程虽然重要，但它只是构建 LLM 应用中的一个模块。为了将模型从“能生成”变成“能完成业务任务”，还需要一整套系统性的能力支持：

• 问题拆解与流程控制：将复杂任务拆成多步链式操作

• 模型选择与调度：不同任务调用不同模型（快、便宜、强）

• 上下文窗口管理：精准地组织和压缩信息内容

• UI/UX + 验证反馈环：生成结果是否准确？能否验证？如何纠错？

• 安全性与合规性：防止越权、注入、幻觉带来的风险

• 评测与监控：持续优化提示效果与应用质量

• 异步并行与预取优化：降低响应时延，提高系统吞吐

• 系统的扩展性与可组合性：支撑未来任务迁移与复用

这些构成了一个全新的软件形态层，我们可以称之为：LLM Application Orchestration Layer（大模型应用编排层）。

四、别再叫它“ChatGPT 包壳”

把这些复杂能力称为“ChatGPT wrapper（包壳）”显然严重低估了它的系统性与技术难度。真正的工业级 LLM 应用系统，更像是一个融合了编排、优化、推理与人机接口的新型中间件平台。

在这个意义上，“Ontology”（本体结构）正在成为上下文工程的核心支柱。因为你的业务流程本身就是上下文。你越能将业务对象、流程状态、工具能力编码进上下文，模型就越能融入真实业务，成为智能代理的一部分。

五、总结：新的工程范式正在成型

从提示工程到上下文工程，从人写 prompt 到系统自动编排上下文，从“能说”到“能做”，我们正在见证一种全新范式的崛起。

未来的大模型系统，不再只是 API 调用，而是一种集 信息组织、任务推理、系统调度、用户交互 于一体的复杂软件工程。理解并掌握上下文工程，是构建下一代智能应用的关键一步。