微信扫码
添加专属顾问
我要投稿
AI领域新趋势:上下文工程如何超越提示工程,成为智能体性能的关键因素?核心内容: 1. 上下文工程的定义与核心目标(效率、成本、质量优化) 2. 与提示工程的关键差异:从"怎么做"到"看什么"的转变 3. 智能体时代的上下文窗口架构三大分类(引导/信息/可操作上下文)
Context Engineering(上下文工程)是 AI 领域一个新兴的术语。讨论的重点从 “提示工程” 转向一个更广泛、更强大的概念。理解为:「为任务提供所有上下文,使 LLM 能够最好的解决问题」。
随着智能体的兴起,决定智能体成功或者失败的「最大因素」是提供的上下文的质量,而不是模型的是否强大。
简单的说,上下文工程是一系列旨在优化、管理和控制输入给 LLM 的上下文信息,目标是模型最大化性能、效率、成本效益等。
现代化的智能体也需要有上下文才能更好的工作。Andrej Karpathy(没错,还是那个男人 https://www.youtube.com/watch?v=7xTGNNLPyMI[1])说过,LLMs 就像一种新的操作系统,LLM 是 CPU,而上下文窗口就是 RAM,作为模型的内存。需要对精挑细选后再放入 CPU 中。
这个 Twitter 上大家讨论也很活跃:https://x.com/karpathy/status/1937902205765607626?lang=en[2]
目前还没有统一的或者比较流行的架构,但是一般来说会分为三类:
甚至有人开始想做成一种规范:
当然一个好的上下文工程,还需要实现很多细节,内容也不局限在上面这些。
今年以来,LLMs 在推理和工具层面的能力不断的提升。
一个任务经常需要长时间的运行,不断的调用工具并反馈给 LLM,持续的对话回合也非常长。这种数据的累计对于 LLM 和 智能体都是一个负担,同时也会消耗大量的 token,提高着用户的使用成本,增加了网络延迟等问题。还会经常伴随着几个问题:
所以,一个好用的智能体,「上下文工程、上下文管理策略是关键!」
可以分为长时记忆和短时记忆。把信息保存在起来,可以帮助智能体完成任务。
Anhtropic 的多智能体研究院也说过:
❝The LeadResearcher begins by thinking through the approach and saving its plan to Memory to persist the context, since if the context window exceeds 200,000 tokens it will be truncated and it is important to retain the plan.
❞
当要执行一个新任务时,如果智能体有记忆的能力。这时候可以选择于任务相关的数据,包括示例、行为、事实等。
目前流行的做法是,把长时记忆用规则文件保存以来,比如 Cluade 使用 CLAUDE.md。
但是,如果需要存储大量的事实或者关系数据,这时候使用嵌入型数据库或者知识图谱就比较合适了。
同时合理运用 RAG 技术,也提高了智能体使用工具和知识的能力和准确性。
代码例子:
[
{
"role": "system",
"content": "You are a helpful assistant..."
},
{
"role": "user",
"content": |
Here's everything that happened so far:
<slack_message>
From: @alex
Channel: #deployments
Text: Can you deploy the backend?
</slack_message>
<list_git_tags>
intent: "list_git_tags"
</list_git_tags>
<list_git_tags_result>
tags:
- name: "v1.2.3"
commit: "abc123"
date: "2024-03-15T10:00:00Z"
- name: "v1.2.2"
commit: "def456"
date: "2024-03-14T15:30:00Z"
- name: "v1.2.1"
commit: "ghi789"
date: "2024-03-13T09:15:00Z"
</list_git_tags_result>
what's the next step?
}
]
slack_message、list_git_tags、list_git_tags_result 都是通过上下文管理,从工具或者其他地方提取的数据。放进去之后,LLM 就能更好了解到用户意图。
智能体的交互可能经过几百个回合,这时候会堆积大量的数据。Claude Code 的策略是当超过 95% 的窗口限制时,运行 “自动压缩”,可以是:
常见的就是采用多智能体,进行关注点分离。把任务拆分给多个智能体来执行。每个智能体都拥有自己一套工具、指令、上下文窗口等。
其次还可以使用环境隔离,比如智能体生成代码,然后把代码放在一个独立的环境执行,最后把结果再返回给智能体。
https://www.youtube.com/watch?v=7xTGNNLPyMI: https://www.youtube.com/watch?v=7xTGNNLPyMI
[2]https://x.com/karpathy/status/1937902205765607626?lang=en: https://x.com/karpathy/status/1937902205765607626?lang=en
[3]https://github.com/contextwindowarchitecture: https://github.com/contextwindowarchitecture
[4]https://docs.google.com/document/d/1qR9qa00eW8ud0x7yoP2XicH38ibP33xWCnQHVRd0C4Q/edit?tab=t.0: https://docs.google.com/document/d/1qR9qa00eW8ud0x7yoP2XicH38ibP33xWCnQHVRd0C4Q/edit?tab=t.0
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-09-04
想成为一名合格的 AI PM,先抛弃过去那些让你成功的经验
2025-09-03
谷歌Nano Banana 的十五个应用案例
2025-09-03
Google官方发布Nano Banana使用文档,放弃邪修回归正道吧!
2025-09-03
AI三问:Agent、LLM、RAG,一文厘清!
2025-09-03
别谈“全面 AI 转型”,要搞“单点 AI 爆破”
2025-09-03
Midoo.AI 发布:AI Agent 能否破解教育行业千亿美金的「无解方程」?
2025-09-03
惊险!腾讯ima搜出来的资料差点出事……
2025-09-03
RAG构建知识库还在忍受慢和重?试试Rust原生ChromaDB,轻量、高速、易用!
2025-08-21
2025-06-21
2025-08-21
2025-08-19
2025-06-07
2025-06-12
2025-06-19
2025-06-13
2025-07-29
2025-06-15
2025-09-03
2025-09-03
2025-09-03
2025-09-03
2025-09-02
2025-08-28
2025-08-28
2025-08-28