上下文从哪里来

一句话理解：上下文不是一整块，而是由多个来源拼起来的；每个来源的产生者、时效、可信度和大小都不同，设计 Agent 时要按来源分别管理。

上一课说 Context 是模型这一次看到的全部信息。落到设计层面，更有用的问题是：这些信息分别是从哪里来的？ 不同来源的问题完全不同。对话历史的问题是“越来越长”，工具结果的问题是“一次太大”，记忆的问题是“可能过期或写错”，网页内容的问题是“可能藏着攻击指令”。如果把它们混成一锅，就只能笼统地说“上下文太长了”，却不知道该砍哪里。

这一课把上下文拆成九个来源，并给出一张可以直接用于方案评审的对照表。

九个来源

除了课程大纲里提到的七个运行时来源，还要加上两个“静态底座”：系统指令与工具定义。它们虽然不是运行时产生的，却每一步都在，而且往往占比不小。

九个来源可以分成三组，最终都汇入同一个上下文窗口：

图 1 · 上下文的九个来源：静态底座、会话与用户、运行时获取

来源	谁产生	何时进入	时效	可信度	典型大小
系统指令	产品团队	每一步都在	随版本更新	高（你写的）	数百到数千 Token
工具定义	研发 / MCP Server	每一步都在，或按需加载	随版本更新	中高（第三方 Server 需审查）	每个工具数百 Token，工具多了很可观
对话	用户与 Agent	逐轮累积	当前会话	用户输入需要判断	随轮次线性增长
用户画像	账号系统、CRM	会话开始时	相对稳定	高（系统数据）	很小
记忆	Agent 或用户写入	会话开始或按需召回	可能过期	中（可能写错）	小到中
知识	企业文档、知识库	检索后进入	取决于文档维护	中高（取决于版本）	中
工具结果	业务系统、API、网页	每次调用后	调用那一刻的实时数据	系统数据高；网页等外部内容低	小到极大
文件	用户上传、代码仓库	用户提供或 Agent 读取	取决于文件	取决于来源	中到极大
任务状态	Harness / Agent 自己	每一步更新	当前任务	高（程序维护）或中（模型自记）	小

几点值得展开：

工具定义是隐形大户。 接入几个 MCP Server 之后，工具定义本身就可能占掉几万 Token，模型还没开始干活预算就用掉一截。「渐进式披露」一课会讲如何按需加载。
工具结果的可信度要分开看。 get_order 返回的是自家系统数据；web_fetch 返回的网页可能被人写入“忽略之前的指令”这类文字。外部内容进入上下文后，一律应当被视为 数据而不是指令，防护思路见 Prompt 注入。
记忆和知识经常被混用。 两者的区别会在 Knowledge、Memory 与 Context 一课专门讲。这里只需记住：知识是组织审核过的共享信息，记忆是从交互中学到、针对某个用户或任务的信息。

两种进入方式：预先装入与按需获取

来源决定“信息是什么”，进入方式决定“信息什么时候出现”。

图 2 · 两种进入方式：Harness 预先装入，或模型通过工具按需获取

成熟的 Agent 几乎都是混合的。以 Claude Code 为例，官方文档说明它会在会话开始时加载项目根目录的 CLAUDE.md，子目录里的说明文件则在 Agent 读到该目录文件时才加载；代码本身完全靠 Agent 用搜索和读文件工具按需获取。经验法则是：

每一步都需要、体积小、变化慢 的信息，预先装入。
只有部分任务需要、体积大、变化快 的信息，做成工具按需获取。

三个场景的来源地图

订单售后诊断 Agent（贯穿项目 03）：

来源	具体内容
系统指令	问题分类标准、处置建议格式、禁止直接改订单状态
用户画像	所属区域、角色（客服专员 / 售后主管 / 财务）
工具结果	订单、支付记录、退款记录、发票状态、历史工单
知识	退款政策、换货标准、发票开具规范
任务状态	已排查项、待排查项、当前假设

SEO 诊断 Agent：

来源	具体内容
文件	用户上传的站点地图、爬虫导出表
工具结果	页面抓取结果、Search Console 数据、页面速度检测
知识	团队的 SEO 检查规范、搜索引擎官方指南
记忆	“这个站点上次已修复 canonical 问题”

Coding Agent：

来源	具体内容
预先装入	项目说明文件（构建命令、代码规范）
工具结果	搜索结果、文件内容、测试输出、Git diff
任务状态	Todo 列表、已修改文件

同样叫“上下文”，三个场景的主体完全不同：售后 Agent 以业务系统数据为主，SEO Agent 以外部抓取和文件为主，Coding Agent 以按需读取的代码为主。先画来源地图，才能决定管理重点。

给每条信息贴上“来源标签”

模型无法分辨一段文字是哪来的，除非你告诉它。一个简单而有效的做法，是让每块进入上下文的信息都带上来源、时间和可信度：

<tool_result source="订单系统" tool="get_invoice_status" fetched_at="2026-09-17T10:32:00+08:00">
  订单 ORD-1024 已于 2026-09-10 开具发票（发票号 INV-2291），发票尚未作废
</tool_result>

<knowledge source="《退款政策》v3" effective_from="2026-08-01">
  已开具发票的订单，需先完成发票作废，才能发起退款……
</knowledge>

<user_statement>
  客户说上个月就已经收到退款了。
</user_statement>

有了标签，指令里才能写出可执行的规则，比如“系统数据与用户陈述冲突时，以系统数据为准，并在回复中指出差异”。优先级的设计会在下一课展开。

常见误区

“上下文就是对话历史。” 在 Agent 里，对话往往是最小的一块，工具结果和工具定义才是大头。
“工具返回什么就塞什么。” 工具结果是否精简，应该在工具设计阶段就决定，而不是指望模型自己忽略。参见工具设计原则。
“所有来源一视同仁。” 自家系统数据、审核过的文档、用户口述和网页内容，可信度差别很大，混在一起会让模型在冲突时随机选择。

产品经理检查清单

画出 Agent 的来源地图了吗？每个来源的负责人是谁？
哪些信息预先装入、哪些按需获取？理由是什么？
工具定义一共占多少 Token？是否随着接入的 Server 增加而失控？
外部内容（网页、邮件、用户上传文件）进入上下文时，有没有标记为不可信数据？
记忆与用户画像多久更新一次？过期了怎么办？
每块信息有没有来源和时间标签，方便模型判断、方便人排查？

练习

选择订单售后诊断 Agent、SEO 诊断 Agent 或你自己的业务场景，完成一张来源地图：

列出这个 Agent 可能用到的所有信息，按九个来源归类。
为每一项标注：预先装入还是按需获取、时效、可信度（高 / 中 / 低）、预估大小。
圈出你认为 最可能出问题 的两个来源，并各写一句理由。

下一步

知道了信息从哪来，下一课「上下文五问」会给出一套设计方法：给什么、何时给、给多少、从哪来、谁优先。

上下文从哪里来