什么 Context 才是 Agent 真正的“大脑“？一文讲透上下文工程

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

过去两年，大模型能力不断提升。

从：

GPT-3.5 ↓ GPT-4 ↓ GPT-4.1 ↓ Claude ↓ Gemini

模型越来越强，Context Window 也越来越大：

8K ↓ 32K ↓ 128K ↓ 256K ↓ 1M Tokens

于是很多开发者开始认为：

Context Window 越大，Agent 就越聪明。

但真正做过 Agent 项目的人都会发现：事实恰恰相反。

很多 Agent 即使拥有：

200K Context

依然会出现：

记忆混乱 任务遗忘 工具调用错误 规划失败 重复执行

为什么？因为真正决定 Agent 能力的，从来不是：

Context Window

而是：

Context Engineering

也就是：

如何构建、组织、更新和管理 Context。

越来越多团队开始意识到：未来 Agent 的竞争，不是谁拥有最大的模型。

而是谁拥有：

最优秀的 Context Runtime。

一、为什么 LLM 经常"变笨"

很多人都有过这种体验。

第一轮：

回答非常准确

第五轮：

开始答非所问

第十轮：

忘记之前内容

第二十轮：

开始胡说八道

为什么？很多人认为：

模型能力下降

其实不是，真正原因通常只有一个：

Context 已经污染。

例如：

用户问题 ↓ 工具返回 ↓ 日志 ↓ 系统 Prompt ↓ Memory ↓ 历史聊天

全部堆积在一起，最终：

真正重要的信息 ↓ 被淹没

这就是：

Context Pollution

上下文污染。

二、Context 到底是什么

很多开发者认为：

Context = 聊天记录

这是最常见的误区，实际上在 Agent Runtime 中 Context 通常包含：

System Prompt User Goal Conversation Planner State Memory Recall Tool Result Task Graph Environment Runtime State

也就是说：

Prompt 只是 Context 的一部分。

真正完整的 Context 更像：

Agent 当前看到的整个世界。

三、为什么说 Context 才是 Agent 的大脑

很多文章说：

LLM = Brain

其实并不准确，LLM 更像：

CPU

负责计算，真正决定计算结果的是：

输入数据。

也就是：

Context

例如：

CPU + 垃圾数据 = 垃圾结果

同样：

GPT-5 + 错误 Context = 错误决策

因此：

模型决定推理能力。

而：

Context 决定推理质量。

四、企业级 Agent 的 Context 架构

推荐采用五层 Context。

Context │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ System Runtime Memory Prompt State Context ↓ ↓ ↓ └─────────────┼──────────────┘ ↓ Tool Context ↓ User Context

不同 Context：生命周期完全不同。

五、System Context：系统身份

例如：

你是一名鸿蒙开发助手。

包括：

角色 规则 权限 能力边界

几乎不会变化，生命周期 Application 级别。

六、Goal Context：目标上下文

例如：

帮我制定学习计划。

Planner 会生成：

Goal ↓ Task DAG

整个执行过程中：Goal 始终存在。

七、Memory Context：长期知识

Memory 不应该全部塞进 Prompt。

正确做法：

Recall ↓ Inject

例如，用户：

继续昨天的话题。

Runtime：

Memory Search ↓ Top K ↓ Inject Context

而不是：

整个数据库 ↓ 全部输入

八、Tool Context：工具执行结果

很多 Agent 最大的问题，工具调用越来越多。

例如：

Web Search ↓ Database ↓ Browser ↓ Calendar

如果全部保留，Prompt 会越来越长。

推荐：

Tool Cache

只保留：

最新状态 摘要结果 关键字段

而不是：

完整 JSON

九、Runtime Context：真正决定 Agent 能力

这一层很多文章几乎不会讲。

实际上，企业 Runtime 都会维护：

Current Task Current Agent Retry Count Failure State Execution Status Dependency

例如：

{"task":"create_plan","status":"running","retry":1}

Planner ➡️ Scheduler ➡️ Supervisor 全部共享：

Runtime Context

因此真正的大脑其实不是：

LLM

而是：

Runtime Context

十、鸿蒙 App 如何实现 Context Center

推荐目录：

src ├── runtime │ ├── context │ ├── center.ts │ ├── system.ts │ ├── runtime.ts │ ├── memory.ts │ ├── tool.ts │ └── goal.ts

统一接口：

exportinterfaceContextProvider{load():Contextupdate(ctx:Context)}

Context Center：

classContextCenter{privateproviders=[]merge():Context{}}

所有 Agent，统一读取：

Context Center

而不是：

直接拼 Prompt

十一、为什么未来 Runtime 都会有 Context Engine

过去：

Prompt ↓ LLM

未来：

Goal ↓ Context Engine ↓ LLM

Context Engine 负责：

过滤 排序 压缩 摘要 合并 更新

最终生成：

Optimal Context

越来越多 Agent Framework 都开始引入 Context 管理层，而不是直接依赖模型上下文窗口。

十二、AI Native App 的终局

把前面几篇文章串起来：

Planner ↓ Scheduler ↓ Memory ↓ Multi-Agent ↓ Context Engine

最终形成：

Goal ↓ Planner ↓ Task Graph ↓ Supervisor ↓ Context Engine ┌─────────┼─────────┐ ↓ ↓ ↓ Memory Runtime Tool State └─────────┼─────────┘ ↓ LLM ↓ Agent Team ↓ ArkUI

你会发现，未来真正复杂的已经不是：

Prompt

而是：

Context Runtime

总结

如果用一句话理解 Context：

Context 不是聊天记录，而是 Agent 在当前时刻能够感知、理解和决策所依赖的全部运行时信息。

过去，大模型时代关注的是：

Model Engineering

后来，Agent 时代关注的是：

Agent Engineering

而未来，真正决定 Agent 上限的，很可能是：

Context Engineering

因为：

模型负责思考，而 Context 决定模型看到什么；Agent 是否足够聪明，最终取决于它拥有什么样的 Context。