上下文工程：让AI看到该看的东西

作者：尔东陈在路上｜知乎原文：上下文工程：让AI看到该看的东西

作者：尔东陈在路上｜发布日期：2026-08-06｜原文：https://mp.weixin.qq.com/s/Ef6l-_sHdoq9RWifP5JJTg

这是我前段时间在备课的时候整理的AI上下文工程的基本逻辑，记录下来备忘。

什么是上下文工程

上下文工程（Context Engineering）是为 Agent 精心编排「这一次任务该看到什么」的工程实践。提示词工程解决的是「怎么把要求写清楚」；上下文工程解决的是「把哪些证据、规则、历史带进窗口，才能让期望结果更可能发生」。如果说提示词像「写好一道考题」，上下文工程更像「每次考试前，帮考生整理这次真正需要带进考场的资料」——不是全带，也不是不带，而是恰好够用。

一次 Agent 对话的上下文，远不止你敲的那句话

真正挤占「上下文预算」的，通常可以拆成以下几类（以一次真实 Agent 会话的用量为例；条数与 token 数因平台、已启用能力而异）：

类别条数（例）Token（例）典型内容谁在塞进去

System prompt

—

~494

角色设定、行为边界、默认回复风格

平台自动挂载

Tool definitions

19

~9,504

内置工具说明：读文件、改文件、跑命令、搜索等

进入 Agent 模式时加载

Rules

1

~2,776

用户/项目规则（如 CLAUDE.md、Cursor Rules）

规则文件自动注入

Memories

按需

数百～数千

跨会话记住的偏好、事实、项目约定

相关时由产品检索并注入

Skills

1

~5,193

已触发 Skill 的 SKILL.md 正文与操作步骤

匹配/手动触发时加载

MCP & dynamic tools

4

~2,177

外部 MCP 服务的工具描述与参数 schema

安装并启用 MCP 后加载

Subagent definitions

11

~1,139

可委派子代理的能力说明与调用约定

Agent 编排层自动挂载

Conversation

13

~8,313

多轮对话、@ 引用、截图、工具回执、命令行输出

你输入 + Agent 回写累积

这些内容都在挤占同一份上下文预算。上表合计约 3 万 tokens——其中 Tool definitions、Conversation、Skills 往往是最大头；你敲进去的那句用户话，只是 Conversation 里很小一块。Memories 不一定每次都出现：没有相关记忆、或平台未启用该能力时，用量面板里可能看不到这一行。

记住：上下文窗口是同一份「预算」。System prompt、内置工具定义、Rules、Memories、Skill 正文、MCP 描述、Subagent 定义、对话历史与工具回执……全都在抢这份预算。

发送"hello"后，大模型实际收到了什么

假设你在对话窗口仅输入了一句 hello，Agent 模型实际收到的远不止这一句，大致会按分层组装：

【System prompt】~数百 tokens你是 CodeBuddy，一名帮助开发者答疑和辅助编程的 AI 工具……【Tool definitions】往往数千～上万 tokens- Read / Write / Shell / Grep / …（每个工具的名称、参数、使用说明）【Rules】所有回复均使用中文。组件文件放在 components/ 目录。（...其它项目规则...）【Memories】（若有相关记忆被命中）用户偏好使用简体中文回复。该项目前端使用 React + TypeScript。【Skills】（若本次已触发）已加载 Skill：xxx（SKILL.md 全文与步骤说明）【MCP & dynamic tools】（若已启用）- 某 MCP 服务的工具列表与参数 schema【Subagent definitions】（若支持委派）- explore / shell / … 等子代理的能力说明【Conversation】用户：hello

用户只看到自己输入的 hello，但模型侧是「系统层 + 能力层 + 记忆层 + 对话层」一起进窗口。所有"存货"信息都会参与大模型的推理过程，占用上下文窗口预算。

上下文越大，大模型的注意力和计算资源会被分散，能聚焦在关键信息上的能力反而下降。因此，管理好上下文内容、控制输入信息的体积和相关性，是提升输出质量的重要方法。

上下文工程最佳实践

上下文工程的日常动作分成两类：提供精准的上下文，以及管理上下文。前者解决「喂什么、怎么喂得准」；后者解决「窗口有限，塞不下时怎么办」。

一、提供精准的上下文

目标：把「少而准的证据」稳定送进 Agent，让模型基于真实材料推理，而不是凭训练记忆瞎编。

策略 1 · 系统全局配置（对话外持久化）

把跨会话都成立的约束，写到对话外部，而不是每轮口头重复：

落点典型载体适合写什么

项目规则

.claude.md / CLAUDE.md、Rules / Instructions

可验证的硬约束：语言、命名、目录、禁止事项

长期记忆

Memories

稳定偏好与事实：常用栈、个人习惯、项目背景

建议控制在约 200 行以内，写具体可检查条款（「回答永远使用中文」「组件放在 components/」），少写空泛形容词（「代码要优雅」）。

策略 2 · 更精准地引用上下文

用 @ 引用真实材料，不要让 Agent 猜项目长什么样。明确指向真实文件、图片、设计稿、代码片段。

示例：

请基于 @src/components/TodoItem.tsx 把完成态的划线动画改得更顺一点

修 Bug 时同理：贴完整报错（含路径与行号）+ @ 报错点名的文件，并要求先读再改。

用更专业化的术语写好提示词——同一件事，表述越具体、术语越对口，模型越容易对齐正确上下文。比如：「改好看点」→「把主按钮的 padding、字重、hover 态对齐设计稿的层级」。

提供精准上下文，本质仍是 RAG——先给证据，再让模型基于证据生成。

开发常用「补上下文」速查：

  • 改样式 → @ 对应 CSS/组件 + 可选截图

  • 修 Bug → 完整报错 + @ 相关文件

  • 对齐规范 → 全局规则 / Memories + 相关 Skill

  • 跨文件重构 → 先 @ 入口，再让 Agent 按需读取（避免一次贴全仓库）

二、管理上下文

每个对话 Session 的上下文窗口有限，不能无限制往里塞；窗口越满，注意力越容易被稀释，关键约束反而被淹没。需要主动管理「存货」。

1. 新开对话窗口
任务切换、主题跑偏、或历史已经很脏时，干净开局往往比继续硬聊更高效。

2. 压缩对话内容
用工具内置的压缩 / summarize，把冗长历史收成摘要，腾出窗口给当前任务。

3. 用 Sub-agent 执行任务
将已经梳理好的结论、约束和待办，迁移给子代理，由子代理专门跟进后续任务，使主 Session 保持精简。

4. 用 handoff 技术迁移上下文
将整理好的关键内容迁移到新对话，实现不同 Session 间的高效交接，避免在单一对话中积压过多内容。

5. 切换不同模型
不同模型的上下文窗口大小不同；需要读更大范围代码、或当前窗口告急时，可换更大窗口的模型（同时留意成本与速度差异）。

6. 定期更新 Skill / MCP / Rules
过时的规则、冗余的 Skill、用不到的 MCP 工具定义，都会长期占用「隐身」预算。定期清理与更新，让进窗口的系统层保持精干。

形象比喻：上下文工程 = 操作系统的内存管理

•LLM = CPU：大语言模型就像中央处理器，负责理解和执行指令，但本身不"记忆"用户历史。

•上下文窗口 = RAM（运行内存）：模型能够"记住"的内容有限，总容量受限。

•System Prompt + Rules = 操作系统内核 + 全局配置：定义了 Agent 的全局行为，类似操作系统内核控制运行逻辑和权限。

•Memory = 多级缓存 + 虚拟内存：需要按需调度、压缩，决定哪些缓存进快内存，哪些换出、合并。

•上下文工程 = 操作系统的内存管理机制：本质上就是"给谁留门，踢谁出去，怎么腾空间"，兼顾性能与成本——确保重要信息常驻，其他数据能随用随读。

—— 尔东陈在路上

posted @ 2026-10-15 18:05  尔东陈在路上  阅读(3)  评论(0)    收藏  举报