2026年7月2日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

Context 即 Agent:下一场 AI 产品战争,是上下文之争

发布日期:2026-06-30 19:56:29 浏览次数: 1516
作者:杨攀同学

微信搜一搜,关注“杨攀同学”

推荐语

Agent 能力的上限取决于上下文(Context),而非模型本身。谁掌握了用户上下文,谁就掌握了未来。

核心内容:
1. 模型、Harness与Context三者交织进化,交替成为瓶颈
2. Context是决定Agent能力边界的关键事实,无法被模型吞噬
3. 管理好Context,Agent的能力将自然涌现

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

全文约 4333 字,阅读需要 15 分钟


43 TALKS · CONTEXT · AGENT INFRASTRUCTURE

本篇文章根据我在本月 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
第 1 页 · Context 即 Agent
第 2 页:开场故事
第 2 页 · 开场故事
第 3 页:Same Model · Different Context
第 3 页 · Same Model · Different Context
第 4 页:变化的不是 Agent,是 Context
第 4 页 · 变化的不是 Agent,是 Context

Part 01

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

第 5 页:第一幕:瓶颈在哪里?
第 5 页 · 第一幕:瓶颈在哪里?
第 6 页:不是线性路径,是交织演化
第 6 页 · 不是线性路径,是交织演化

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

第 7 页:2026 年,Harness 爆发了
第 7 页 · 2026 年,Harness 爆发了
第 8 页:瓶颈又回到了 Context
第 8 页 · 瓶颈又回到了 Context

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

第 9 页:交织进化的螺旋
第 9 页 · 交织进化的螺旋

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

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

第 10 页:Harness 定义
第 10 页 · Harness 定义

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

第 11 页:Agent = f (Harness,Context)
第 11 页 · Agent = f (Harness,Context)

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

第 12 页:Harness 不是变量,是函数本身
第 12 页 · Harness 不是变量,是函数本身
第 13 页:模型在吞噬 Harness
第 13 页 · 模型在吞噬 Harness
第 14 页:Agent = f (Context)
第 14 页 · Agent = f (Context)

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

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

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

Part 02

为什么 Context 是决定性变量

第 16 页:第二幕:为什么是 Context?
第 16 页 · 第二幕:为什么是 Context?
第 17 页:没有 Context,模型只能给你 P50
第 17 页 · 没有 Context,模型只能给你 P50

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

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

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

第 19 页:模型是压缩的能力
第 19 页 · 模型是压缩的能力
第 20 页:Prompt 是一句话,Context 是工作现场
第 20 页 · Prompt 是一句话,Context 是工作现场

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

第 21 页:Context 定义
第 21 页 · Context 定义

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

第 22 页:场景对比:Coding Agent
第 22 页 · 场景对比:Coding Agent

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

第 23 页:代码为什么长成这样,才是 Context
第 23 页 · 代码为什么长成这样,才是 Context
第 24 页:场景对比:融资邮件
第 24 页 · 场景对比:融资邮件

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

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

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

第 26 页:Harness 越强,Context 越重要
第 26 页 · Harness 越强,Context 越重要

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

第 27 页:Agent 的天花板在 Context
第 27 页 · Agent 的天花板在 Context

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


Part 03

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

第 28 页:第三幕:Context 是活的
第 28 页 · 第三幕:Context 是活的
第 29 页:Context 会生长
第 29 页 · Context 会生长

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

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

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

第 31 页:动态 Context 卡在哪里?
第 31 页 · 动态 Context 卡在哪里?

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

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

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

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

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

第 34 页:真正的胜因
第 34 页 · 真正的胜因

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

第 35 页:Context 应该自然发生
第 35 页 · Context 应该自然发生

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

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

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

第 37 页:要无负担输入
第 37 页 · 要无负担输入

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

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

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


Part 04

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

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

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

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

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

第 42 页:不可迁移性
第 42 页 · 不可迁移性

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

第 43 页:Context 的正反馈飞轮
第 43 页 · Context 的正反馈飞轮

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

第 44 页:未来 AI 产品竞争
第 44 页 · 未来 AI 产品竞争

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

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

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

第 46 页:Prompt Engineering / Agent Engineering / Context Management
第 46 页 · Prompt Engineering / Agent Engineering / Context Management

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

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

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

第 48 页:Context 即 Agent
第 48 页 · Context 即 Agent

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

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


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

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

- FIN -

如果觉得我的文章给你带来价值,欢迎关注我的微信公众号“杨攀同学”和“攀哥四十二”并加星⭐️。我会经常给大家分享商业、科技、创业、AI、出海全球化方向的洞察和思考

另一个号

精彩历史文章
当 Agent 世界以 100 倍速度进化,人类还在开周会
请停止为人类开发软件!2026年最大的机会,是给Agent“造基建” | 43 Talks年度大场
AI Coding 的终局不是生成,而是抛弃
AI 的另一个未来,是真正的「千人千面」
论全球化产品中的文字素养
GPT-4o 发布,「AI 时代」我们需要什么耳机?
数字世界:美国 Web,中国 App

抖音聊天挑战微信?先读过攀哥的 IM 应用三定律

一位科技创业者的 2022 年终书单

一篇写给开发者的社区提问指南

中国云服务走向全球?先把 Status Page 搞定

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅