AI Agent 的上下文工程——为什么 Context 胜过模型

TL;DR

• **Context Engineering（上下文工程）**是设计「AI Agent 在做决策的那一刻知道什么」的学科——那些把一个通用模型变成"属于你"的 Agent 的背景、约束、历史、偏好与环境信号。它不是提示词工程的下位分支。

• 上下文有四层：静态上下文（Static Context，你一次性写下的东西）、会话上下文（Session Context，你现在正在做什么）、任务上下文（Task Context，这个具体任务需要什么）、环境上下文（Environmental Context，Agent 周围的世界在说什么——你的日历、你的文件、你最近的三场会议）。

• 模型与 Agent 运行框架（harness）正在趋同、商品化。上下文是唯一无法被模型吸收的变量，因为上下文不是一种能力——它是事实。是"你的"事实。

• 日历驱动架构是最自然的上下文积累机制：它被动采集、自动更新，并天然围绕时间组织——而时间是每个任务都活在其上的维度。

• 下一代 AI Agent 产品不再比拼包装了哪个模型、用了哪套工具调用框架，而将比拼谁在无声中积累了最深、最能指导行动的上下文。

1. 模型不是你的 Agent 的瓶颈

如果你持续使用 AI Agent 一段时间，大概经历过类似这样的挫败：你升级到更好的模型，基准分数涨了，可你的 Agent 在你的工作上并没有明显变好。它依然抓不住会议的重点；依然用不属于你的语气起草邮件；依然给出显而易见的答案，而不是那个——考虑到过去两周你们一直在讨论的一切——真正说得通的答案。

这种模式不是随机的。它指向 AI Agent 实际运作方式的某种结构性事实。

过去三年，模型能力、Agent 基础设施（常被称为 harness）、与 Context 之间的关系一直在画螺旋——Yang Pan 在 2026 年年中一次 43 Talks 活动上把它称为「交织进化」。每次模型变强，瓶颈就转移。更好的模型暴露出你原来提供的上下文少得可怜。于是你改进上下文——更好的提示词、更长的窗口、更结构化的输入——Agent 变好了。接着 harness 进步：工具调用、多步推理、代码执行、浏览器访问。Agent 能做更多事了。然后瓶颈又转移——重新回到 Context，因为现在 Agent 能作用于更多东西，却依然不知道哪些东西对"你"重要。

这不是当前这代 Agent 系统的缺陷，而是这种架构的永久特征。正如 Yang 所说：模型能吸收 harness，却永远无法吸收 Context。harness——工具调用、记忆管理、规划、多步执行——是能力。能力会随着时间被模型吸收。Context 是事实，是你的工作、偏好、历史、约束的具体、偶然、无法简化的特殊状态。如果你从未把上周二那通客户电话里做的决定告诉模型，再多的模型升级也无法替你推断出来。

这句话的含义并不隐晦：如果你在构建或采纳 Agent 时，指望「模型持续升级」最终能解决「我的 Agent 不懂我的处境」这个问题，你是在赌一件结构性上不可能发生的事。模型会变得更聪明，却不会变得更像"你"。

那个缺口——在「能力强的 Agent」与「掌握足够信息、能正确行动的 Agent」之间——正是上下文工程（Context Engineering）的用武之地。

2. 什么是 Context Engineering？

2.1 定义 Context Engineering

Context Engineering 是这样一门学科：设计、采集、组织并维护 AI Agent 在做决策那一刻所需要的信息，使其产出不仅抽象上正确，更针对具体情境正确。这个词刻意借自软件工程：软件工程是组织代码、使其可维护、可测试、正确的学科；Context Engineering 是组织 Agent 的知识、使其在 Agent 行动那一刻准确、完整、可执行的学科。两者都是工程学科——有原理、有模式、有权衡、有失败模式。两者都不是一次性配置工作，都奖励持续投入而非一次性设置。

这个框架很重要，因为它把对话从「我该用哪个模型？」转向「我的 Agent 实际上知道什么？」——后一个问题显然更具可操作性。更好的模型或许产出更好的文字，但更好的 Context 产出更好的决策，而决策才是 Agent 存在的最终目的。正如我们在持久化 AI Agent讨论里说过的，Agent 的定义性特征不是「跑一次、给个回复」，而是「跨交互维持状态」。Context Engineering 正是让这份状态变得有用、而不只是被堆积起来的方法。

一个能概括其范畴的工作定义：

Context Engineering 是这样一套系统实践：定义 Agent 需要知道什么，从随现实更新的来源中采集它，把它组织成 Agent 能高效消费的结构，并在事实与约束变化时维护它。它高于提示词工程、高于 RAG、高于记忆管理——把三者协调到同一个目标上：Agent 在具备完整情境感知的状态下行动。

2.2 上下文的四个层次

Context 不是单一的东西。把它当成一袋扁平的「我喂给 Agent 的信息」，是 Agent 设计里最常见的错误——也是制造最隐蔽故障的那个错误。当所有东西不加结构地倒进同一个窗口，Agent 无法区分一条硬约束（「周五绝不发布」）和三次对话之前一句随口的话。Context 分成四个截然不同的层次，各有不同的采集机制、更新节奏与工程要求。分开理解这些层次，你才知道该把钱投到哪里回报最高。

第一层：静态上下文（Static Context）——你一次性写下的东西。这是大多数人起步的层次：项目说明、品牌指南、团队章程、编码规范、产品文档。静态上下文变化缓慢——按周到按月计——而且通常由你刻意撰写。它回答的是「这是什么类型的工作？」和「Agent 该遵守什么规则？」。这里的工程挑战不在采集，而在维护。静态上下文会腐烂：去年的编码规范可能已不再适用；kickoff 时写的项目说明，已经偏离团队真正做出的东西。没有刷新节奏的静态上下文会变成噪音，而噪音比沉默更糟——它会自信地误导 Agent 遵循过时的约束，同时所有人都纳闷为什么产出总觉得哪儿不对。

第二层：会话上下文（Session Context）——你现在正在做什么。每次与 Agent 的交互都发生在一个会话里：当前对话、手头任务、你刚打开的文件、你刚问的问题。会话上下文是最易变的层次——每分钟都在变——也恰恰是多数 Agent 处理得不错的层次，因为聊天界面天然会捕获它。这一层的工程挑战是连续性：多数会话结束后上下文就蒸发了，下一个会话从零开始。会话上下文需要被捕获、总结、移交给下一次交互——当 Agent 要跨小时、跨天工作而不是窝在一次聊天里时，这个问题就变得尖锐。这事比听起来难，是因为会话总结本身就需要判断：哪些来回是决策、哪些是探索、哪些是应该丢弃而非带向前的死胡同。

第三层：任务上下文（Task Context）——这个具体任务需要什么。每个有分量的任务都自带约束：一封融资邮件需要那份 deck、本轮条款、投资人的背景，以及和这位投资人上一次的对话。一个 bug 修复需要报错堆栈、相关代码路径、测试套件和部署历史。任务上下文比会话上下文窄，但更深——它是「写一封邮件」与「写这封能拿下本轮融资的特定邮件」之间的差别。采集任务上下文需要主动检索：拉出对的文档、查对数据库、找到对的前例。RAG 系统正是在这里运作，但光有 RAG 不够——没有「什么与这个任务相关」的模型，检索产出的结果宽而浅，还常常漏掉那篇真正要紧的文档。

第四层：环境上下文（Environmental Context）——Agent 周围的世界在说什么。这是最强也最未被利用的一层。环境上下文是 Agent 没有主动索取、却应当知晓的世界状态：你的日历写着两小时后有董事会；你的邮箱刚收到一份条款清单修订；你的项目看板显示冲刺周五结束；你最近三场会议都在谈同一个招聘决定。环境上下文有三个让它格外值钱的特性。其一，它被动采集——用户不需要记得提供它，它作为日常工作的副产品自动进入系统。其二，它自动更新——世界变了它就变，而不是等谁想起来改文档。其三，它天然围绕时间组织——日历、收件箱、提交日志、会议历史都带时间顺序，沿着"每个任务都活在其上"的那个维度可查询。这一层的工程挑战是集成：把 Agent 接到承载环境上下文的数据源上、从噪音里滤出信号、并以 Agent 能据以行动的形式呈现。今天多数 Agent 产品几乎完全没做这件事——这恰恰就是为什么它是整条上下文栈里杠杆最高的一笔投资。

退一步看，四个层次不只是分类法——它们意味着不同的投资策略。静态上下文奖励维护纪律，会话上下文奖励好的总结启发式，任务上下文奖励检索质量，环境上下文奖励集成广度。下表把操作层面的差异一眼看清：

这张表让纯文字未必显眼的东西一目了然：每一层的失效方向都不同。静态上下文败于「错」，会话上下文败于「没了」，任务上下文败于「浅」，环境上下文败于「缺失」。一套只处理其中一两层的 Context Engineering 策略，会让其余层次成为沉默的失败模式——而沉默的失败最难诊断，因为 Agent 依然产出内容，只是内容与现实悄悄错位。

2.3 Context Engineering 不是什么

定义一个新兴学科，最好先划清它区别于什么——因为 Context Engineering 与几项常被混淆的相邻实践有重叠，而这些区别恰恰揭示真正的功夫在哪里。

Context Engineering 不是提示词工程。提示词工程是「为单次模型调用写出有效指令」的手艺。Context Engineering 是「哪些信息能到达模型」的系统设计。好提示词配上烂上下文，产出的是措辞漂亮但错误的答案；烂提示词配上好上下文，往往反过来更胜一筹。提示词工程优化的是怎么问。Context Engineering 决定的是问什么。

Context Engineering 不是 RAG。检索增强生成（RAG）是把相关文档拉进模型输入的一种技术。它是 Context Engineering 工具箱里的一件工具——主要在任务上下文这一层有用——但它不是这门学科本身。Context Engineering 还涵盖什么时候不该检索（静态上下文不该被检索，它应当始终在场）、什么时候该推而不是拉（环境上下文按自己的节奏到来），以及如何组织 Context 好让检索真正生效。

Context Engineering 不是记忆管理。Agent 的记忆——无论是短期的（对话历史）还是长期的（跨会话的持久事实）——是一个存储问题。Context Engineering 是一个相关性问题。记忆告诉你 Agent 见过什么；上下文告诉你 Agent 此刻需要看到什么才能做对决定。没有上下文管理的记忆，会变成「一切发生过的东西」的垃圾场，而其中大部分与当前任务无关。

这三条区别背后有一个值得点破的共同模式：

从前三门学科到 Context Engineering 的转变，是从供给侧思维到需求侧思维的转变。提示词工程、RAG、记忆管理都在优化我们给 Agent 什么；Context Engineering 优化的是 Agent 真正需要什么——往往比我们给的更少，但更精准地瞄准手头的决策。

3. 为什么别的东西都商品化了，Context 却在复利

AI 栈的每一层都在重复同一个模式：起先是差异化优势的东西，最后变成入场券。而且周期很短、还在加速：

• 约 2024 年：RAG 还是需要定制管线的先进技术。到 2025 年年中，它已作为默认功能进入所有主流 Agent 框架——变成入场券。

• 约 2025 年：多步工具调用与函数调用还是需要精心设计 harness 的研究级能力。到 2026 年年初，前沿模型原生就能做——又一个层次被吸收。

• 约 2026 年：浏览器 Agent、代码执行沙盒、结构化输出解析还需要专用基础设施。到年中的时候，模型 API 已开始直接吸收这些——模式依旧成立。

这条弧线一致且不变：模型吞噬 harness。每一轮都比上一轮快，每一次吸收都抬高了「基础 Agent」的能力下限，同时收窄了产品能在执行层功能上做出差异化的表面积。

如果你的 Agent 产品的主要卖点是「我们包了一个好模型、再给它工具」，这个卖点已经在贬值。模型厂商没有原地踏步——每一次发布都会吸收掉更多过去需要外部基础设施的能力。

Context 是这个模式的例外。不是因为 Context 技术上更难——有的方面难，有的不难——而是因为 Context 与能力在结构上不同。更好的模型能学会更可靠地调用工具，却学不会你客户上周在电话里说了什么——除非有人捕获了它、组织了它、交付了它。Context 不是技能，是证据。

这就产生了复利效应。你创造的每一份上下文资产——每份项目文档、每份会议纪要、每份决策记录、每个偏好信号——都在拉大有 Context 的 Agent 与没有的 Agent 之间的差距。一个带着你两年会议历史、已落地的决策、不断演进的偏好的 Agent，与没有这些的 Agent 相比，不是好一点半点，而是类别的差异。

而且因为 Context 不可迁移——这一点 Yang Pan 特别强调——复利是黏性的。你可以一个下午就从 A 模型换到 B 模型，可以一个周末换掉 Agent 框架，却无法迁移两年积累下来的 Context。它住在那个采集它、组织它、并从中学习的产品里。这种锁定来自真正的效用，而非导出数据的阻力：你留下来，是因为离开等于从头再来。

4. Context 如何积累——为什么日历是天然载体

如果 Context 是决定性变量，下一个问题就非常实际：Context 到底怎么进入系统，而不变成用户的第二份工作？

知识管理的历史上，满地都是要求用户手动打理 Context 的系统。Wiki、Notion 工作区、个人 CRM、会议纪要模板——它们都以同一种方式失败：要求用户持续自律。而「规模化的持续用户自律」是个幻想。

替代方案是被动积累：Context 作为用户过日常工作生活的副产品进入系统，而不是一项单独的整理任务。这正是日历驱动架构难以夸大的结构性优势所在。

日历不只是时间网格，它是承诺的活地图。上面的每个事件都编码着：你与谁交谈、在做什么、哪些截止日临近、哪些项目处于活跃状态。当 Agent 能访问日历，它就在用户一个字都不用解释的情况下获得了环境上下文。日历告诉它：这场会议每周重复，说明这个话题是持续的；这个事件挂着一份 deck，说明上一次的上下文仍然相关；这个截止日在逼近，而关于它上一次的会议以一项悬而未决的决定收场。

日历天生就是时间性的。它沿着"每个任务都活在其上"的维度——时间——来排列上下文。会议准备发生在会议之前，跟进发生在之后，截止日驱动的工作随日期临近而升温。一个日历原生的 Agent 不需要别人告诉它什么紧急——它自己能从时间线上读出来。

把这和基于聊天的 Context 积累比一比。聊天界面只采集用户明确敲进去的东西，对对话之外的一切毫无感知：它看不见触发任务的那个日历事件、排在其前的那条邮件线程、或者从另一个渠道共享来的那份文档。聊天能很好捕获会话上下文，却对环境上下文完全失明。两种架构的差异，在每一个对上下文深度有意义的维度上都会显现：

这不是主张所有 Agent 都该日历驱动，而是主张：最有价值的上下文——环境上下文——最自然的采集方式，是观察用户真实活动的系统，而不是等用户叙述。日历是最密的信号，但不是唯一的：文件系统、邮件、版本控制、项目看板都承载环境上下文。最后胜出的产品，是那些把所有这些来源无声集成在一起的产品。这与我们在日历驱动 AI 范式里探讨的是同一种动力：当 Agent 从日历而不是聊天窗口运作时，它就继承了一个关于你的承诺、关系与截止日的模型——这些 Context，聊天式 Agent 每次都需你明确描述一遍。

5. 你真正想要的锁定

「锁定」（lock-in）这个词在软件语境里通常带贬义——而且往往名正言顺。专有数据格式、导出限制、API 锁定都是反用户模式。

Context 锁定不一样。它不是厂商人为制造的摩擦，而是「产品越用越好用」的自然结果。当 Agent 积累 Context——你的会议历史、你的决策、你的偏好、你的项目演进——留下来的价值会自然增长。你被锁住，不是因为它很难离开，而是因为离开意味着放弃一项花了数月乃至数年才建成的资产。

这就形成了一个正向反馈环，Yang Pan 称之为飞轮：更多的使用产生更多的 Context，更多的 Context 让 Agent 更好用，更好用的 Agent 带来更多使用，而每一圈都加深 Context、抬高切换成本。这对用户和产品都是健康的关系：用户得到一个持续进化的 Agent，产品靠真正的效用赢得留存。

对 AI 产品构建者，战略含义很清楚。最可靠的护城河不是模型，也不是功能清单，而是产品替用户积累的 Context 深度——以及这份积累在多大程度上是无声发生的、无需用户打理。

对用户——尤其是把整门生意跑在少数几个工具上的单人创业者与独立创始人——含义同样清楚。选择 Agent 产品，越来越是在选择「哪个产品会随时间为你的工作积累出最好的 Context」。短期的功能对比抓错了重点。那个认识你的客户、你的项目、你的偏好、你的历史的产品，会胜过功能更丰富却对你一无所知的替代品。这也是为什么把日历当作运行时而非容器的 AI 日程 Agent，能积累出通用聊天 Agent 无法企及的上下文深度——每一个已排事件、每一次改期、每一份会议附件，都无需用户额外动作就成为上下文层的一部分。

6. 这如何改变你构建和使用 Agent 的方式

如果你接受 Context Engineering 是一门学科、Context 会复利，那么无论对构建者还是用户，都有一串实际推论。下面的清单按杠杆排序：越靠前成本越低、复利越快。

对构建者，设计目标变了。问题不再是「我们的 Agent 能执行什么功能？」，而是「我们能积累多少 Context，而用户毫无察觉？」

1. **按 Context 产出评估功能，而不是按能力数量。**每个功能都应该按「它作为副产品被动生成了什么 Context」打分。一个「发送跟进邮件」功能，如果同时把邮件存进会议历史、关联到日历事件、并更新联系人记录，那么一个用户动作就生成了三份上下文资产；一个只把邮件发出去的功能，什么也没生成。几个月下来，这两个产品的差距不是功能差距——是上下文鸿沟。

2. **让 Context 采集感觉像「用产品」，而不是「喂产品」。**Yang Pan 把这一点说得很尖锐：如果一个产品要求用户准备高质量、结构化、经过编辑的输入，它就还不是一个真正的 Agent 产品。语音输入、日历集成、自动会议捕获、文件系统监听，都能让 Context 积累隐形。文本输入虽然普适，却藏着一笔隐形成本：打字迫使人组织措辞、编辑、自我审查。最好的 Context 是在用户还没来得及打磨之前就被捕获的。

3. **从第一天就为 Context 可迁移性而设计。**如果用户的 Context 只存在你的专有数据库里，切换成本短期对你有利，长期却侵蚀信任。可导出的、结构化的 Context——即便迁移并不完美——传递的信号是：你对自己的产品有信心到敢用「积累的价值」来竞争，而不是靠扣留数据。

这三条优先级不是彼此独立的。Context 产出（第 1 条）驱动复利飞轮；隐形采集（第 2 条）决定飞轮是否真的转起来——因为没有飞轮是靠手动录入数据转动的；可迁移性（第 3 条）让飞轮成为竞争优势而不是陷阱。

对用户，投入的计算变了。如果 Context Engineering 是决定性变量，那么花在打磨提示词上的时间，应该重新分配到构建 Context 上：

1. **把日历当作 Context 来源，而不是排程工具。**你放进日历的每个事件——连同与会人、描述、附件文档、指向往期会议的链接——都是 Agent 可用的 Context。「与 Sarah 开会」和「与 Sarah 开会：Q3 pipeline 复盘，已附 deck v3，需跟进 6 月 15 日关于企业定价的讨论」之间的差别，就是「发一条通用提醒的 Agent」与「真正能帮你做准备的 Agent」之间的差别。

2. **选择观察你工作的工具，而不是只响应命令的工具。**一个盯着你的日历、文件系统和沟通渠道的工具，会被动构建 Context；一个等你往聊天框里敲指令的工具，只能以你打字的速度积累 Context——而你打字永远比干活慢。

3. **记录决策，不只是任务。**会议纪要、决策记录、偏好信号不是行政负担，而是 Agent 的燃料。你今天记下的每个决策，都是让 Agent 三个月后不再问你同一个问题的 Context。

结论

AI Agent 发展的弧线正弯向一个单一变量。模型会趋同，harness 会被吸收。剩下的——不可约、不可迁移的——是 Context。

Context Engineering 是认真对待这件事的学科。它不把 Context 当成事后诸葛亮、靠更好的提示词或更长的窗口来打补丁，而是把它当成一流的工程问题，有自己的层次、模式与权衡。四层模型——静态、会话、任务、环境——是一个起步框架，帮你思考你的 Agent 知道什么、这些知识从哪来、以及当现实变化时如何维护它。

下一阶段 AI 的赢家，不是模型最好的那批，而是无声、持久、准确地为用户及其工作构建出最深厚 Context 的那批。日历驱动架构不是抵达这一结果的唯一路径，却是最自然的一条——因为日历本来就是承诺、关系与截止日栖息的地方。

Yang Pan 在演讲结尾留了一句话，我一直记得：把 Context 管好，Agent 自然涌现。译成英文少了点诗意，却同样为真：照顾好 Context，Agent 自会照顾好其余一切。