0. 引子
Agent 如何"看见"世界？
它没有眼睛，没有耳朵，只有一个输入窗口。无论外面的世界多复杂，Agent 能感知的只有一样东西：Context。
一段 prompt 是 context，一次工具调用的返回是 context，一个文件的内容是 context，一条报错信息也是 context。
对于 Agent 来说：Everything is context。
这篇文章讲述 context 如何从一段静态文字，演进为 Agent 感知世界的唯一接口。这个演进过程，就是Context Engineering的诞生之路。
1. Context 的起源 — In-Context Learning
传统机器学习的范式很简单：一个任务，训练一个模型。
情感分析是一个模型，机器翻译是另一个模型。能力固化在参数里，换任务就要重新训练。
LLM 打破了这个范式。GPT 系列证明了一件事：一个足够大的语言模型，可以通过context来切换任务。你不需要重新训练，只需要换一段 prompt。
传统模型：任务 → 训练 → 专用模型
LLM：通用模型 + Context → 任意任务
这像什么？像是从专用硬件到通用计算机的转变。
早期计算是专用的——一台机器做一件事。通用计算机的出现改变了这一切：同一台机器，换一个程序，就能做不同的事。
程序是计算机的 Context。
更神奇的是 few-shot learning。给模型几个示例，它就能学会新任务：
- • 输入：高兴 →positive
- • 输入：难过 →negative
- • 输入：开心 →?
模型会输出positive。
没有训练，没有微调，示例本身就是学习。传统机器学习需要收集数据、设计特征、训练模型——而 LLM 只需要几个例子放进 context。
这就是In-Context Learning：能力不再只存在于参数中，Context 成为能力的载体。
这是 Context Engineering 的起点——我们发现，Context 可以承载能力，就像程序可以承载计算逻辑。
2. 手动构建 Context — Prompt Engineering
既然 Context 能承载能力，那如何设计更好的 Context？
Prompt Engineering 应运而生。
最简单的是角色设定：
你是一个资深的代码审查专家…
然后是结构化指令：
任务
审查以下代码
要求
- 检查安全漏洞
- 检查性能问题
- 给出改进建议
代码
…
再进阶是思维链（Chain-of-Thought）：
让我们一步步思考…
还有 ReAct，让模型交替进行推理和行动：
Thought: 我需要先查看文件结构
Action: list_files
Observation: …
Thought: 现在我需要…
如果把 LLM 比作一个程序，Prompt 就像是它的配置文件——定义了行为模式、输入格式、输出规范。好的配置让程序行为可预测、可控制。
Prompt Engineering 的本质是什么？人工精心设计每一个 token，让有限的 context 窗口发挥最大价值。
但局限也很明显：手动、静态、不可扩展。
当知识库有一百万文档时，你不可能手动把相关内容塞进 prompt。
3. 自动检索 Context — RAG
有限的 context 窗口，无限的外部知识。怎么办？
RAG（Retrieval-Augmented Generation）给出了答案：让相关信息自动找上门。用户提问 → 检索相关文档 → 拼入 Context → 生成回答。不再需要把所有知识塞进 prompt，只需要在需要时检索最相关的部分。
这像什么？像是程序从文件系统读取数据，而不是把所有数据硬编码在代码里。
Context 的稀缺性
这里要引入一个关键概念：Context Rot（上下文腐化）。
随着 context 窗口中 token 数量增加，模型准确回忆信息的能力会下降。因为 Transformer 架构让每个 token 都要关注其他所有 token，形成 n² 的关系。当 n 变大，注意力被稀释。
这意味着：Context 是稀缺资源，边际效用递减。不是塞得越多越好，而是要找到最小的高信号 token 集合。
RAG 的局限
RAG 本质上是一个固定模式的搜索工具：固定触发、固定流程、固定能力。
它的突破在于：从"人工塞 Context"到"自动取 Context"。但它的局限也在于"固定"——如果 Agent 需要的不是检索，而是执行一段代码、调用一个 API 呢？
4. 动态生成 Context — Tools
RAG 是工具的特例，Tools 是 RAG 的泛化。
RAG：固定触发 → 检索 → 返回文本
Tools：Agent 决定 → 任意工具 → 返回结果
这里先澄清一个概念：Workflow是 LLM 和工具通过预定义路径编排，Agent是 LLM 动态决定自己的流程。关键区别在于谁在做决策。
Tools 让 Agent 成为可能：不只检索还能执行，不只固定触发而是 Agent 自主决定，不只一个而是工具集。这像 Unix 中的可执行程序——cat读文件，grep搜索，sh执行命令。简单、专注、c可组合。
工具的输出拼入 Context，成为 Agent 的新感知。这是一个闭环：行动产生新的 Context，新的 Context 驱动下一步行动。Agent 第一次能"做事"并"看到结果"。
MCP：工具的标准化
当 Agent 需要连接越来越多外部系统时，每个系统都需要单独的集成代码。MCP（Model Context Protocol）解决了这个问题——它是 Agent 世界的 USB-C。
MCP 提供统一协议，让 Agent 用同一种方式连接所有支持 MCP 的服务。它让Tools 成为可发现、可组合的生态系统。
MCP 的意义不只是减少重复工作。它让Tools 成为可发现、可组合的生态系统。Agent 不需要预先知道所有工具，可以在运行时发现和使用新工具。
5. 封装 Context 模式 — Skills
有了工具，Agent 能做很多事。但问题也来了：
工具太多，Context 不够用。每个工具的定义、调用参数、返回结果都要占用 token。当 Agent 连接几十上百个工具时，光是工具定义就可能吃掉大量 context 窗口。
而且原子工具太底层了。读文件、写文件、执行命令——这些是能力的原材料，不是能力本身。
"代码审查"是一个能力。它需要：
- • 读取代码文件
- • 理解项目结构
- • 按照特定标准检查
- • 输出结构化的审查意见
如何把这些组合成一个可复用的能力？
Skill：可发现、可加载的 Context 包
Skill的本质是：一个包含指令、脚本和资源的文件夹，Agent 可以在需要时发现和加载。
这个定义有三个关键点：
- 文件夹结构：不是一段 prompt，而是有组织的资源集合
- 可发现：Agent 知道有哪些 Skill 可用
- 按需加载：只在相关时才加载到 Context
Skill 的核心设计原则是Progressive Disclosure（渐进式披露）：
为什么这样设计？因为 Context 是稀缺资源。
如果把所有 Skill 的完整内容都塞进 Context，会触发 Context Rot。渐进式披露让 Agent 只加载需要的信息，保持 Context 的高信噪比。
Skill vs Shell 脚本
Unix 哲学在这里再次闪光：用管道组合小程序，完成复杂任务。
cat access.log | grep "ERROR" | sort | uniq -c | sort -rn | head -10这行命令组合了 6 个小程序，完成了"找出最常见的 10 种错误"这个复杂任务。
Skill 和 Shell 脚本有相似之处：
- Tool→ 单个命令（
cat,grep,sort） - Skill→ Shell 脚本（组合多个命令的工作流）
但 Skill 比 Shell 脚本更灵活：
- • Shell 脚本是固定的流程
- • Skill 是指导 + 资源，Agent 可以灵活运用
Skill 还可以包含可执行代码。有些操作用代码比用 token 生成更高效、更可靠。比如排序一个列表，用代码是 O(n log n)，用 token 生成则昂贵且不确定。
从 Context Engineering 的视角看，Skill 是可复用的 Context 模式——预定义好什么信息该进入 Context，以什么顺序，用什么方式处理。
6. Context 的管理 — 长程任务的挑战
前面几章讲的是 Context 的来源：从哪里获取信息。
但还有另一个维度：Context 的管理。当任务跨越几十分钟甚至几小时，产生的 token 远超 context 窗口时，怎么办？
Compaction：压缩历史
最直接的方法是压缩。
当对话接近 context 窗口上限时，让模型总结之前的内容，用摘要替换原始对话，然后继续。
压缩的艺术在于选择保留什么。过于激进的压缩会丢失关键细节，过于保守则达不到效果。
一个低风险的压缩策略是清理工具调用结果。当一个工具调用已经在历史深处，Agent 通常不需要再看原始返回值。
Structured Note-taking：Agent 的笔记本
更优雅的方法是让 Agent自己做笔记。
Agent 定期把重要信息写入外部文件（比如 NOTES.md），这些笔记持久化在 context 窗口之外。需要时再读回来。
这就像人类做笔记：我们不会记住所有细节，但会记录关键点，需要时查阅。
一个有趣的例子是 Claude 玩 Pokémon。Agent 需要跨越数千个游戏步骤保持连贯性——记住目标、追踪进度、学习哪些攻击对哪些敌人有效。通过自己维护笔记，Agent 可以在 context 重置后继续多小时的策略执行。
Sub-agent：分而治之
第三种方法是多 Agent 协作。
主 Agent 负责高层规划，子 Agent 负责具体执行。每个子 Agent 有自己干净的 context 窗口，可以深入探索，最后只返回精炼的结果。
子 Agent 可能消耗数万 token 进行探索，但只返回 1000-2000 token 的精华。这实现了关注点分离——详细的搜索 context 隔离在子 Agent 内，主 Agent 专注于综合分析。
选择哪种方法？
- Compaction：适合需要大量来回对话的任务
- Note-taking：适合有明确里程碑的迭代开发
- Sub-agent：适合需要并行探索的复杂研究
这三种方法可以组合使用。
隔离环境：跨 Session 的外部记忆
当任务跨越数小时甚至数天时，每个新的 context window 都是一张白纸。想象轮班工程师交接，但每个人上班时都失去了前一班的记忆——这就是长程 Agent 的挑战。
解决方案是隔离的运行环境：文件系统持久化代码和文档，Git 记录改动可回滚，进度文件记录工作日志。每个 session 结束时把环境留在"干净状态"，下一个 session 读取进度文件和 git log，几秒内就能继续工作。隔离环境是 Agent 的"外部记忆"，弥补了 context window 的有限性。
关键是认识到：即使模型能力不断提升，在需要最强性能的场景下，Context 管理仍然是核心挑战。
7. Context 的完整来源 — Environment
现在让我们退后一步，看看全貌。
前面的每一章，我们都在用操作系统做类比：
- • Context 像程序的输入
- • Prompt 像配置文件
- • RAG 像文件系统读取
- • Tools 像可执行程序
- • Skills 像应用程序
这不是巧合。我们正在为 Agent 构建一个操作系统。
- Environment→ 操作系统（完整运行环境）
- Agent→ 用户/Shell（决策主体）
- Tools→ 命令行程序（原子能力）
- Skills→ 应用程序（封装的能力组合）
- Context→ stdin/stdout（统一信息接口）
这让人想起 Unix 的设计哲学：Everything is a file。在 Unix 中，硬件、进程、网络连接都被抽象为文件，程序通过统一的文件接口与世界交互。
Unix 的设计哲学在这里完美映射：
- Everything is a file →Everything is context
- 小程序做一件事 → Tool 做一件事
- 用管道组合程序 → 用 Skill 组合 Tools
- 文本作为通用接口 → Context 作为通用接口
- Shell 作为胶水 → Agent 作为胶水
关键洞察：Agent 不直接接触 Environment，一切通过 Context 感知。
就像 Unix 程序通过 stdin 读取输入、stdout 输出结果，Agent 通过 Context 感知世界、表达意图。
为什么是 Coding Agent？
这里要回答一个更根本的问题：为什么我们如此强调 Coding Agent？
因为我们相信：Agent 是通向 AGI 的可行路径。而 Coding Agent 是这条路径上最关键的形态。
原因很简单：任何开放式任务，都可以转化为计算机操作。而代码执行是连接一切的桥梁。
想想看：
- 写一篇报告 → 操作文件系统 + 调用写作工具
- 分析数据 → 执行 Python 脚本 + 生成可视化
- 部署服务 → 执行命令行 + 配置环境
- 设计产品 → 调用设计工具 API + 生成原型
代码是通用的胶水。会写代码的 Agent，理论上可以完成任何可以用计算机完成的任务。
换句话说：任何现在由人操作计算机完成的任务，未来都有可能由 Agent 自主完成。
代码执行的独特价值
代码执行不只是"能做事"，它还解决了 Context Engineering 的核心挑战：
1. 过滤数据，减少 token
# 不用代码执行：10000 行数据全部进入 Contexttool_call: get_spreadsheet(id="abc123")→ 返回 10000 行，全部进入 Context# 用代码执行：在执行环境中过滤data = get_spreadsheet(id="abc123")pending = [row for row in data if row["status"] == "pending"]print(f"Found {len(pending)} pending orders")print(pending[:5]) # 只返回 5 行到 Context2. 保护隐私
中间数据可以留在执行环境中，不进入模型的 Context。敏感信息（邮箱、电话）可以被自动脱敏。
3. 持久化状态
Agent 可以把中间结果写入文件，跨越 context 重置继续工作。甚至可以把成功的代码保存为可复用的函数——这就是 Skill 的雏形。
这就是为什么 Environment 的核心是代码执行能力：
对于 Coding Agent：
- 代码文件的内容 → Context
- 终端的执行结果 → Context
- 测试的通过/失败 → Context
- 编译的错误信息 → Context
- LSP 的类型提示 → Context
Environment 是 Context 的终极来源。Context 是 Agent 与世界的唯一接口。代码执行是 Agent 改变世界的主要方式。
8. 结语：Context Engineering 的全貌
回顾这段旅程：
每一步都在回答同一个问题：如何让 Agent 获得更好的 Context？
- Prompt Engineering：手工打磨每一个 token
- RAG：自动检索相关信息
- Tools：动态执行获取新信息
- Skills：封装可复用的 Context 模式
- Environment：提供完整的信息来源
而 Context 管理（Compaction、Note-taking、Sub-agent）则回答另一个问题：如何在有限窗口里最大化 Context 的价值？
Context Engineering = 来源 × 管理
这一切，最终指向一个更大的图景：
我们正在为 Agent 构建操作系统。
Unix 用 50 年证明了一套设计哲学的生命力：
- Everything is a file
- 小程序做好一件事
- 用管道组合程序
- 文本作为通用接口
Agent 的世界正在复现这套哲学：
- Everything is context
- Tool 做好一件事
- 用 Skill 组合 Tools
- Context 作为通用接口
最后，回到开篇的问题：
Agent 如何"看见"世界？
答案始终是：Context。
Agent 的能力上限 = Context 的质量上限
这就是 Context Engineering。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
