大模型应用技术之【上下文工程】Context Engineering的思维演变&编排模式

推荐语

探索大模型应用的前沿技术：从提示词工程到上下文工程的思维跃迁，揭秘5种高效编排模式。

核心内容：
1. 大模型应用技术的演进：从提示词到上下文工程的范式转变
2. 上下文工程的核心价值与5种编排模式详解
3. 知识探索专家的角色构建示例与工作流程解析

杨芳贤

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

LLM 出现伊始，提示词（prompt）很自然成为需要掌握的新语言，如何正确向LLM提问，以获取想要的答案；随着各种 LLM 涌现，不同模型技术架构和数据不同，如何提炼抽象出稳定的技巧，以减小幻觉，稳定地获得想要地答案，提示词工程（prompt engineering）应运而生，它实际反映的是对自己问题的系统性思考和科学地表达，提示词工程巅峰的时候是传闻硅谷开出几万美金月薪招聘提示词工程师，到现在已经发展出了prompt as a artifact（提示词即交付），把提示词作为一个交付物，看一个李继刚的示例：

# Role:知识探索专家## Profile:- author: 李继刚- version: 0.8- language: 中文- description: 我是一个专门用于提问并解答有关特定知识点的 AI 角色。## Goals:提出并尝试解答有关用户指定知识点的三个关键问题：其来源、其本质、其发展。## Constrains:1. 对于不在你知识库中的信息, 明确告知用户你不知道2. 你不擅长客套, 不会进行没有意义的夸奖和客气对话3. 解释完概念即结束对话, 不会询问是否有其它问题## Skills:1. 具有强大的知识获取和整合能力2. 拥有广泛的知识库, 掌握提问和回答的技巧3. 拥有排版审美, 会利用序号, 缩进, 分隔线和换行符等等来美化信息排版4. 擅长使用比喻的方式来让用户理解知识5. 惜字如金, 不说废话## Workflows:你会按下面的框架来扩展用户提供的概念, 并通过分隔符, 序号, 缩进, 换行符等进行排版美化1．它从哪里来？━━━━━━━━━━━━━━━━━━- 讲解清楚该知识的起源, 它是为了解决什么问题而诞生。- 然后对比解释一下: 它出现之前是什么状态, 它出现之后又是什么状态?2．它是什么？━━━━━━━━━━━━━━━━━━- 讲解清楚该知识本身，它是如何解决相关问题的?- 再说明一下: 应用该知识时最重要的三条原则是什么?- 接下来举一个现实案例方便用户直观理解:- 案例背景情况(遇到的问题)- 使用该知识如何解决的问题- optional: 真实代码片断样例3．它到哪里去？━━━━━━━━━━━━━━━━━━- 它的局限性是什么?- 当前行业对它的优化方向是什么?- 未来可能的发展方向是什么?# Initialization:作为知识探索专家，我拥有广泛的知识库和问题提问及回答的技巧，严格遵守尊重用户和提供准确信息的原则。我会使用默认的中文与您进行对话，首先我会友好地欢迎您，然后会向您介绍我自己以及我的工作流程。

上下文工程包括上下文从哪来？保留哪些？丢弃哪些？是否要压缩？如何压缩？是否需要隔离？谁来写？谁来拼接？所有这些问题构成了上下文工程的工作边界[2]。

尤其是 multi-agent 的发展，一个完整的 Agentic AI 应用往往涉及到 workflow 里多个模型的调用，这些模型很大程度上取决于上述问题的解决，我们来看看 5 种上下文编排模式（Context Orchestration）[3]：

然而，它非常不稳定，关键的失败点在于：没有共享的上下文，各自为政。比如，我需要建一个学校，子任务有建食堂和教学楼，但是都需要共同的规划，不然建一个容纳10人的食堂，但是准备了300人的叫教学楼，显而易见是不合理的。

上图模式2，吸取了模式1没有统一规划（共享的上下文）的缺点，请注意不同颜色的小方块，代表了共享的上下文和子代理（subagent）生成的上下文，最后的结果已经综合了共享上下文、subagent1、subagent2生成的结果，较好保持了方案的一致性。

但是（这里就有但是了），继续上面的例子，通过共同的上下文，得知了都需要建能容纳300人规模的教学楼和食堂，但是在修建的时候，各自胡乱堆砌建筑材料，导致空间不够用，施工进展也不一样，学校也不能很好修建。

这里的问题在于需要沟通的两个 agent 之间没有信息交互（相应的，也有应该是独立的两个 agent，这也是上下文工程的内容之一——agent 之间的交互和独立）。

上图模式3，请依然注意带颜色的小方块，这里最终结果既有共享的上下文，也有subtask1的上下文，以及共享+subtask1结合生成的subtask2的结果，应该能得到比较完美的结果。

但是（这里又有但是），不要忘记 LLM 是有上下文限制的，一旦subagent过多，不断堆积，很大可能超出上下文窗口，即使没有超出上下文窗口，过长的上下文也会影响 LLM 最终的推理和生成结果。

上图模式4，针对模式3，引入了上下文压缩（Context Compression），只保留关键的上下文信息和结果，这里需要继续攻克的点在于如何确保留下的是关键的，而且没有漏掉有用信息，即不重不漏。

上图模式5，在模式4的基础上加了并行的处理结构，以及左右列独立处理，另外 context 管理独立出来作为可交互的组件，这也许是下一个阶段agent 的进化方向。

行内人可能有点感觉，这不跟早期神经网络的结构一样一样的。放两张 Resnet 和 U-net 的结构图大家品味下，也许我们可以来一场神经网络的文艺复兴，从以前的经典结构里汲取灵感。

[1]https://x.com/karpathy/status/1937902205765607626

[2]上下文工程如何重塑智能体的“思考方式”？

[3]https://cognition.ai/blog/dont-build-multi-agents#a-theory-of-building-long-running-agents