Context 即 Agent：下一场 AI 产品战争，是上下文之争

本篇文章根据我在本月 43 Talks 线下活动中的分享整理而成。主理人李继刚邀请我时，给的主题词只有一个：Context。我想从 Agent 的视角出发，讨论一个判断：随着模型和 Harness 逐步趋同，真正决定 Agent 能力边界的，会越来越是 Context。

说明：正文基于 PPT 内容进行了轻度解读；配图来自本次分享 PPT 的导出图，使用 Guizang PPT Skill 制作。

五个核心判断

1. 模型能力和 Context 交织进化，交替成为瓶颈，每一轮模型能力的提升后 Context 的重要性都在提升。
2. 模型在吞噬 Harness，但永远吞噬不了 Context，因为 Context 不是能力，是事实。
3. Agent 的天花板不在模型，在 Context。
4. 谁拥有用户的上下文，谁就拥有一切。
5. 把 Context 管好，Agent 自然涌现。

Opening

一次关于 Context 的分享

大家好，今天我想分享我上周在 43 Talks 线下活动中的内容。感谢 43 Talks 和李继刚的邀请。继刚当时给这次分享的主题只有一个词：Context。我就在想，围绕 Context 还能讲什么？Context 领域已经有很多专家，有人讲工程，有人讲产品。

我想选择一个稍微不同的角度。正好最近我在做 Agent 基础设施，自己也是 Agent 的重度用户。长期以来，我一直在思考 Context 在整个 Agent 生态系统中的价值。于是我想到一个题目：《Context 即 Agent》。

接下来，我会从这个角度展开分享。

第 1 页 · Context 即 Agent

第 2 页 · 开场故事

第 3 页 · Same Model · Different Context

第 4 页 · 变化的不是 Agent，是 Context

Part 01

瓶颈不是线性移动，而是螺旋上升

第 5 页 · 第一幕：瓶颈在哪里？

第 6 页 · 不是线性路径，是交织演化

这些年，大模型和 Agent 产业一直在交织演化。每一次模型能力和 Harness 变强，我们都会重新回到 Context。最开始我们关注 Prompt，后来关注上下文，再后来关注 Harness。

第 7 页 · 2026 年，Harness 爆发了

第 8 页 · 瓶颈又回到了 Context

当模型能力提升后，我们发现提供给模型的上下文不够，反而限制了模型能力发挥。于是我们去解决上下文问题。上下文改善之后，我们又通过提升 Harness 来增强模型的行动能力。当 Harness 提升到一定程度，限制 Agent 继续变强的，又变成了上下文。

第 9 页 · 交织进化的螺旋

所以，模型能力、Harness 能力和上下文能力的提升，不是一条线性路径，而是一条交织演化、交替上升的螺旋。模型能力和上下文会轮流成为瓶颈；每一轮螺旋之后，Context 的重要性都会继续上升。

我们常说模型会吃掉很多东西：知识、信息、模式、最佳实践和概率。与此同时，模型自身的能力也在逐步提升，包括执行任务、调用工具、感知环境和运行工作流的能力。

第 10 页 · Harness 定义

这些能力原本都属于 Harness 的一部分。但我们会发现，它们正在逐步被集成到模型中，成为模型自身能力的一部分。无论是 OpenClaw、Hermes，还是各种 Agent 框架，它们之间的本质差异正在变小，执行层能力也在慢慢商品化。

第 11 页 · Agent = f （Harness，Context）

所以我们再从这个角度看 Agent。第一版公式可以写成：Agent 是关于 Harness 和 Context 的函数。前面我对 Harness 和 Context 做了很多说明，但后来我意识到，Harness 会逐步变成模型能力的一部分，并且趋于一致。它并不是一个长期稳定的变量，而是一组会持续提升、最终被并入模型的能力。

第 12 页 · Harness 不是变量，是函数本身

第 13 页 · 模型在吞噬 Harness

第 14 页 · Agent = f （Context）

换句话说，Harness 更像函数本身的一部分。过去需要外部框架完成的事情，比如调工具、执行代码、管理记忆、多步规划，正在变成模型的原生能力。所以 Agent 是什么？它更像是一个关于 Context 的函数。模型和 Harness 本质上都在函数内部，剩下那个不断变化、不断适应的变量，就是 Context。

模型会持续吞噬 Harness，并在这个过程中提升自身能力。但模型永远吞噬不了 Context，因为 Context 不是能力，而是事实。

第 15 页 · 模型永远吞噬不了 Context

Part 02

为什么 Context 是决定性变量

第 16 页 · 第二幕：为什么是 Context？

第 17 页 · 没有 Context，模型只能给你 P50

模型本身是概率机器，默认输出往往是训练数据分布中的中位数，也就是统计意义上最正确的那一部分。如果没有 Context，模型面对我们的问题时，给出的通常都是 P50 的结果。

第 18 页 · Context 是解压缩的钥匙

有了 Context 之后，情况就不一样了。Context 是解压缩模型能力的钥匙。模型已经把大量可能性压缩在概率分布中，而 Context 能把其中一条路径解压成此时此地的答案。

第 19 页 · 模型是压缩的能力

第 20 页 · Prompt 是一句话，Context 是工作现场

所以，Context 是什么？它是此时此地，是那把钥匙。早期的 Prompt 通常只是一句话，用来激发模型能力；而 Context 是一整个工作现场。

第 21 页 · Context 定义

Context 为模型还原任务发生的背景和条件，让 Agent 有能力做出更正确的行动。目标、背景、历史、约束、材料、状态、偏好、成功标准，这些都属于 Context。

第 22 页 · 场景对比：Coding Agent

举个例子，如果只对模型说“帮我实现一个登录功能”，它可能会给出一个教科书式的示例。但如果把项目结构、技术栈、登录设计、数据库 Schema、团队代码风格、不能碰的模块、测试和部署方式都提供给 Coding Agent，结果就会完全不同。

第 23 页 · 代码为什么长成这样，才是 Context

第 24 页 · 场景对比：融资邮件

回到前面的融资邮件例子。如果我们给 Agent 提供了充分背景，它也能得到我们真正想要的结果。这时，它给出的就不再是通用示例，而是符合真实需求的完整产出。

第 25 页 · Context 让 Agent 看起来变聪明

所以，你的 Agent 和我的 Agent 的差异，并不一定来自模型本身。即使用同一个模型，Agent 的表现也可能相差很大。差异往往来自不同的人对 Context 的投入。提供不同的 Context，就会得到不同的 Agent。

第 26 页 · Harness 越强，Context 越重要

而且，Harness 越强，Context 就越重要。有人会认为 Harness 变强后，Context 就没那么重要了，系统都能自动处理。但实际上，越强的 Harness 越容易把 Context 中的一个小偏差放大成具体错误。

第 27 页 · Agent 的天花板在 Context

所以，当我们使用同样的模型、同样的 Agent 框架时，真正的差异在哪里？答案仍然是 Context。

Part 03

Context 是活的，会在使用中生长

第 28 页 · 第三幕：Context 是活的

第 29 页 · Context 会生长

Context 不是静态的，它是活的，会生长，也有时间轴。你在使用 Agent 的过程中，不只是在消费 Context，也在反向塑造 Context。你的每一次行动，都可能让 Context 发生变化。你和 Agent 长期共同维护的，其实是一个持续变化的工作现场，这就是 Context。

第 30 页 · 真正缺的是动态 Context

我们已经习惯把大量静态内容做成知识库交给 Agent，但很多人忽视了持续变化的数据。如果把这些动态数据也作为 Context 提供给 Agent，它的能力会进一步增强。

第 31 页 · 动态 Context 卡在哪里？

为什么动态 Context 很少有人做？因为它确实很难，难在收集、消费和整理。一些 LLM Wiki 类产品，其实已经在尝试解决这个问题。

第 32 页 · 谁解决动态 Context，谁解锁下一代 Agent

对于 Agent 创业者和产品开发者来说，谁能解决动态 Context 的收集、消费和整理，谁就可能打开下一代 Agent 的机会。

第 33 页 · OpenClaw 和 Hermes 是 Harness 的胜利

OpenClaw 和 Hermes 当然是 Harness 的胜利，这是很多人的共识。但从另一个角度看，它们又何尝不是 Context 的胜利？

第 34 页 · 真正的胜因

它们降低了 Context 收集、持久化和持续积累的门槛，让 Context 可以更自然地沉淀。无感的 Context 积累，也是这类 Agent 框架成功的重要因素。

第 35 页 · Context 应该自然发生

对开发者和产品人来说，Context 的收集、持久化、累积，应该自然发生，不应该要求用户刻意做什么。谁能把 Context 累积做得最无感，谁就赢。

第 36 页 · 很多人不愿意输入，不是因为不会用

再想一想，我们今天给 Agent 输入内容，主要还是靠打字。这本身就有成本。打字时，我们会字斟句酌，会反复修改，这些都会增加输入负担。理想的状态是，我们想到哪里就说到哪里，不需要承担额外的表达压力。

第 37 页 · 要无负担输入

当表达本身就能成为输入，Agent 才能更容易获取 Context，我们也才能更自然地使用 Agent。如果一个产品要求用户必须准备高质量、整理过、处理过的输入，它就还不是理想的 Agent 产品。好的 Agent 产品应该让输入变得无负担，让用户不必担心输入质量，而让模型自己去分析和理解。

第 38 页 · 不能用 Markdown 定义，就不存在

再从另一个角度看，有多少人能够在数字世界里清楚地描述自己？如果你的日常工作、生活资料、习惯和偏好不能被文字化、结构化地表达出来，那么对 Agent 来说，你就是一个陌生人。它不知道如何与你更好地配合，也不知道如何更好地服务你。

Part 04

下一场战争，是上下文之争

第 39 页 · 下一场战争：上下文之争

第 40 页 · 下一场：上下文之争

今天大家都在讨论 Agent 的方向。无论创业者还是大公司，都在做 Agent。但我认为，未来的 Agent 竞争不只是 Harness 之争，更是 Context 之争，也就是上下文之争。互联网时代，巨头争夺的是入口、流量和生态；而下一阶段，真正要争夺的是上下文。谁能掌握用户和企业的上下文，谁就会拥有更大的优势。

第 41 页 · 谁拥有用户的上下文，谁就拥有一切

为了掌握用户和客户的上下文，产品需要在上下文的收集、整理、分析、积累和生长过程中，提供足够好的体验。谁拥有用户的上下文，谁就在未来拥有更大的主动权。上下文还有另一个重要特点：不可迁移。

第 42 页 · 不可迁移性

Agent 可以换，Agent 框架也可以换，但真正不能轻易更换、并且会不断产生复利的，是上下文。项目历史、代码库演进、客户对话、产品决策、团队工作方式、个人偏好和审美判断，这些沉淀越深，迁移成本就越高。

第 43 页 · Context 的正反馈飞轮

上下文本身有正反馈飞轮：在一个产品里使用越多，Context 越完整，Agent 就越好用；Agent 越好用，用户就越不想迁移，也会继续产生更多 Context。

第 44 页 · 未来 AI 产品竞争

所以，未来 Agent 产品竞争，不是比谁的界面更炫，而是比谁积累了更深的 Context。

第 45 页 · 把精力花在构建自己的上下文上

如果你是 Agent 创业者或开发者，应该把精力放在如何帮助用户以更低门槛构建上下文上。如果你是普通 Agent 用户，也应该把更多精力放在构建自己最大、最新、最能反映真实状态的上下文上。

第 46 页 · Prompt Engineering ／ Agent Engineering ／ Context Management

因此，Context 管理会成为 Agent 使用者的新能力和基本功。过去我们经历了 Prompt Engineering、Agent Engineering 和 Context Management，分别解决怎么问、怎么运行，以及凭什么做对。最后我们可以想象一个画面：如果你的所有上下文都摆在 Agent 面前，会发生什么？

第 47 页 · 把 Context 管好，Agent 自然涌现

相比缺少上下文的 Agent，拥有足够上下文的 Agent 更可能产生涌现能力，并为你提供更多服务。这也是未来 Agent 产业要前进的方向。经过上面的讨论，我想表达的观点是：Context 就是 Agent。当然，这只是从 Context 视角看这个问题。

第 48 页 · Context 即 Agent

我们不能否认 Agent 框架和模型能力提升在整个发展路线中的巨大意义。但我今天想强调的是，Context 同样具有巨大价值。未来，模型能力会不断提升，Harness 会越来越趋同。谁拥有更高质量、更完整、更实时更新的 Context，谁就能形成复利，并取得更多价值。

谁拥有更好的 Context，谁就能取得更多价值。

Context 即 Agent。把 Context 管好，Agent 自然涌现。从今天起，把精力花在构建自己的上下文上。

在未来模型能力不断提升、Harness 越来越趋同的情况下，谁拥有更高质量、更完整、更实时更新的 Context，谁就能形成复利，也就能取得更多的价值。

文章来自于"杨攀同学"，作者 "杨攀同学"。