链载Ai

标题: 从提示词工程（Prompt Engineering）到上下文工程（Context Engineering） [打印本页]

---

作者: 链载Ai    时间: 2 小时前
标题: 从提示词工程（Prompt Engineering）到上下文工程（Context Engineering）

“上下文工程”指的是：系统性地设计、组织和动态管理大语言模型（LLM）输入窗口中的上下文信息，以确保模型在执行任务时具备最优表现的技术与艺术结合。

这一概念由 Cognition 的 Walden Yan 明确提出：

被 Shopify CEO Tobi Lutke 等多位 AI 实践者在社交媒体广泛转发，迅速走红。

如 Dex Horthy （数据平台 Hex 的联合创始人）所言：

“Own your context window.”

🔍 为什么它现在变得重要？

上下文窗口不断扩大（Claude 3.5 已到 200K，GPT-4o 是128K，GPT-4 Turbo是128K，Gemini 1.5甚至到达100万 token），但更大上下文≠更好效果。相反：

• 塞太多无关信息，会稀释重点；
• 塞得不够或格式混乱，又会导致 hallucination 或 reasoning failure；
• 多模态信息（图、音、视频、函数调用等）加入后，结构复杂度指数级增长。

这就要求我们从 prompt 工程迈入 context 工程的新阶段。

🔧 实践中的解法框架

以下是多位 AI 开发者对“Context Engineering”的具体定义与操作方法：

1. Harrison from LangGraph

LangGraph 是为“上下文工程”而生的图状 RAG 框架，用于搭建带状态的、多轮交互式 Agent 应用。

https://x.com/hwchase17/status/1937648042985030145

2. Lance Martin 的类比：像 RAM 管理器

“就像操作系统负责将关键数据调入 CPU 的 RAM 中一样，LLM 应用也需要上下文工程师管理 Prompt、检索内容与工具调用的组合逻辑。”

https://rlancemartin.github.io/2025/06/23/context_engineering/

3. Kwindla 的推荐：以“工作流状态”组织上下文

对于语音 Agent 或任务代理，应该把对话流设计成状态机，每个状态只需要引入完成该任务的必要上下文。

https://gist.github.com/kwindla/f755284ef2b14730e1075c2ac803edcf

4. Andrej Karpathy 的总结

“上下文工程既是科学，也是艺术。”

https://x.com/karpathy/status/1937902205765607626

他列举了上下文组成的各种组件，包括：

• 任务描述；
• few-shot 示例；
• 历史状态；
• 检索内容（RAG）；
• 工具使用记录；
• 多模态输入等。

最好的上下文工程需要在高性能、低延迟、低成本之间找到最佳点。

---

欢迎光临 链载Ai (https://www.lianzai.com/)

Powered by Discuz! X3.5