微信扫码
添加专属顾问
Agent 能力的上限取决于上下文(Context),而非模型本身。谁掌握了用户上下文,谁就掌握了未来。核心内容: 1. 模型、Harness与Context三者交织进化,交替成为瓶颈 2. Context是决定Agent能力边界的关键事实,无法被模型吞噬 3. 管理好Context,Agent的能力将自然涌现
全文约 4333 字,阅读需要 15 分钟
43 TALKS · CONTEXT · AGENT INFRASTRUCTURE
本篇文章根据我在本月 43 Talks 线下活动中的分享整理而成。主理人李继刚邀请我时,给的主题词只有一个:Context。我想从 Agent 的视角出发,讨论一个判断:随着模型和 Harness 逐步趋同,真正决定 Agent 能力边界的,会越来越是 Context。
说明:正文基于 PPT 内容进行了轻度解读;配图来自本次分享 PPT 的导出图,使用 Guizang PPT Skill 制作。
五个核心判断
Opening
大家好,今天我想分享我上周在 43 Talks 线下活动中的内容。感谢 43 Talks 和李继刚的邀请。继刚当时给这次分享的主题只有一个词:Context。我就在想,围绕 Context 还能讲什么?Context 领域已经有很多专家,有人讲工程,有人讲产品。
我想选择一个稍微不同的角度。正好最近我在做 Agent 基础设施,自己也是 Agent 的重度用户。长期以来,我一直在思考 Context 在整个 Agent 生态系统中的价值。于是我想到一个题目:《Context 即 Agent》。
接下来,我会从这个角度展开分享。
Part 01
这些年,大模型和 Agent 产业一直在交织演化。每一次模型能力和 Harness 变强,我们都会重新回到 Context。最开始我们关注 Prompt,后来关注上下文,再后来关注 Harness。
当模型能力提升后,我们发现提供给模型的上下文不够,反而限制了模型能力发挥。于是我们去解决上下文问题。上下文改善之后,我们又通过提升 Harness 来增强模型的行动能力。当 Harness 提升到一定程度,限制 Agent 继续变强的,又变成了上下文。
所以,模型能力、Harness 能力和上下文能力的提升,不是一条线性路径,而是一条交织演化、交替上升的螺旋。模型能力和上下文会轮流成为瓶颈;每一轮螺旋之后,Context 的重要性都会继续上升。
我们常说模型会吃掉很多东西:知识、信息、模式、最佳实践和概率。与此同时,模型自身的能力也在逐步提升,包括执行任务、调用工具、感知环境和运行工作流的能力。
这些能力原本都属于 Harness 的一部分。但我们会发现,它们正在逐步被集成到模型中,成为模型自身能力的一部分。无论是 OpenClaw、Hermes,还是各种 Agent 框架,它们之间的本质差异正在变小,执行层能力也在慢慢商品化。
所以我们再从这个角度看 Agent。第一版公式可以写成:Agent 是关于 Harness 和 Context 的函数。前面我对 Harness 和 Context 做了很多说明,但后来我意识到,Harness 会逐步变成模型能力的一部分,并且趋于一致。它并不是一个长期稳定的变量,而是一组会持续提升、最终被并入模型的能力。
换句话说,Harness 更像函数本身的一部分。过去需要外部框架完成的事情,比如调工具、执行代码、管理记忆、多步规划,正在变成模型的原生能力。所以 Agent 是什么?它更像是一个关于 Context 的函数。模型和 Harness 本质上都在函数内部,剩下那个不断变化、不断适应的变量,就是 Context。
模型会持续吞噬 Harness,并在这个过程中提升自身能力。但模型永远吞噬不了 Context,因为 Context 不是能力,而是事实。
Part 02
模型本身是概率机器,默认输出往往是训练数据分布中的中位数,也就是统计意义上最正确的那一部分。如果没有 Context,模型面对我们的问题时,给出的通常都是 P50 的结果。
有了 Context 之后,情况就不一样了。Context 是解压缩模型能力的钥匙。模型已经把大量可能性压缩在概率分布中,而 Context 能把其中一条路径解压成此时此地的答案。
所以,Context 是什么?它是此时此地,是那把钥匙。早期的 Prompt 通常只是一句话,用来激发模型能力;而 Context 是一整个工作现场。
Context 为模型还原任务发生的背景和条件,让 Agent 有能力做出更正确的行动。目标、背景、历史、约束、材料、状态、偏好、成功标准,这些都属于 Context。
举个例子,如果只对模型说“帮我实现一个登录功能”,它可能会给出一个教科书式的示例。但如果把项目结构、技术栈、登录设计、数据库 Schema、团队代码风格、不能碰的模块、测试和部署方式都提供给 Coding Agent,结果就会完全不同。
回到前面的融资邮件例子。如果我们给 Agent 提供了充分背景,它也能得到我们真正想要的结果。这时,它给出的就不再是通用示例,而是符合真实需求的完整产出。
所以,你的 Agent 和我的 Agent 的差异,并不一定来自模型本身。即使用同一个模型,Agent 的表现也可能相差很大。差异往往来自不同的人对 Context 的投入。提供不同的 Context,就会得到不同的 Agent。
而且,Harness 越强,Context 就越重要。有人会认为 Harness 变强后,Context 就没那么重要了,系统都能自动处理。但实际上,越强的 Harness 越容易把 Context 中的一个小偏差放大成具体错误。
所以,当我们使用同样的模型、同样的 Agent 框架时,真正的差异在哪里?答案仍然是 Context。
Part 03
Context 不是静态的,它是活的,会生长,也有时间轴。你在使用 Agent 的过程中,不只是在消费 Context,也在反向塑造 Context。你的每一次行动,都可能让 Context 发生变化。你和 Agent 长期共同维护的,其实是一个持续变化的工作现场,这就是 Context。
我们已经习惯把大量静态内容做成知识库交给 Agent,但很多人忽视了持续变化的数据。如果把这些动态数据也作为 Context 提供给 Agent,它的能力会进一步增强。
为什么动态 Context 很少有人做?因为它确实很难,难在收集、消费和整理。一些 LLM Wiki 类产品,其实已经在尝试解决这个问题。
对于 Agent 创业者和产品开发者来说,谁能解决动态 Context 的收集、消费和整理,谁就可能打开下一代 Agent 的机会。
OpenClaw 和 Hermes 当然是 Harness 的胜利,这是很多人的共识。但从另一个角度看,它们又何尝不是 Context 的胜利?
它们降低了 Context 收集、持久化和持续积累的门槛,让 Context 可以更自然地沉淀。无感的 Context 积累,也是这类 Agent 框架成功的重要因素。
对开发者和产品人来说,Context 的收集、持久化、累积,应该自然发生,不应该要求用户刻意做什么。谁能把 Context 累积做得最无感,谁就赢。
再想一想,我们今天给 Agent 输入内容,主要还是靠打字。这本身就有成本。打字时,我们会字斟句酌,会反复修改,这些都会增加输入负担。理想的状态是,我们想到哪里就说到哪里,不需要承担额外的表达压力。
当表达本身就能成为输入,Agent 才能更容易获取 Context,我们也才能更自然地使用 Agent。如果一个产品要求用户必须准备高质量、整理过、处理过的输入,它就还不是理想的 Agent 产品。好的 Agent 产品应该让输入变得无负担,让用户不必担心输入质量,而让模型自己去分析和理解。
再从另一个角度看,有多少人能够在数字世界里清楚地描述自己?如果你的日常工作、生活资料、习惯和偏好不能被文字化、结构化地表达出来,那么对 Agent 来说,你就是一个陌生人。它不知道如何与你更好地配合,也不知道如何更好地服务你。
Part 04
今天大家都在讨论 Agent 的方向。无论创业者还是大公司,都在做 Agent。但我认为,未来的 Agent 竞争不只是 Harness 之争,更是 Context 之争,也就是上下文之争。互联网时代,巨头争夺的是入口、流量和生态;而下一阶段,真正要争夺的是上下文。谁能掌握用户和企业的上下文,谁就会拥有更大的优势。
为了掌握用户和客户的上下文,产品需要在上下文的收集、整理、分析、积累和生长过程中,提供足够好的体验。谁拥有用户的上下文,谁就在未来拥有更大的主动权。上下文还有另一个重要特点:不可迁移。
Agent 可以换,Agent 框架也可以换,但真正不能轻易更换、并且会不断产生复利的,是上下文。项目历史、代码库演进、客户对话、产品决策、团队工作方式、个人偏好和审美判断,这些沉淀越深,迁移成本就越高。
上下文本身有正反馈飞轮:在一个产品里使用越多,Context 越完整,Agent 就越好用;Agent 越好用,用户就越不想迁移,也会继续产生更多 Context。
所以,未来 Agent 产品竞争,不是比谁的界面更炫,而是比谁积累了更深的 Context。
如果你是 Agent 创业者或开发者,应该把精力放在如何帮助用户以更低门槛构建上下文上。如果你是普通 Agent 用户,也应该把更多精力放在构建自己最大、最新、最能反映真实状态的上下文上。
因此,Context 管理会成为 Agent 使用者的新能力和基本功。过去我们经历了 Prompt Engineering、Agent Engineering 和 Context Management,分别解决怎么问、怎么运行,以及凭什么做对。最后我们可以想象一个画面:如果你的所有上下文都摆在 Agent 面前,会发生什么?
相比缺少上下文的 Agent,拥有足够上下文的 Agent 更可能产生涌现能力,并为你提供更多服务。这也是未来 Agent 产业要前进的方向。经过上面的讨论,我想表达的观点是:Context 就是 Agent。当然,这只是从 Context 视角看这个问题。
我们不能否认 Agent 框架和模型能力提升在整个发展路线中的巨大意义。但我今天想强调的是,Context 同样具有巨大价值。未来,模型能力会不断提升,Harness 会越来越趋同。谁拥有更高质量、更完整、更实时更新的 Context,谁就能形成复利,并取得更多价值。
谁拥有更好的 Context,谁就能取得更多价值。
Context 即 Agent。把 Context 管好,Agent 自然涌现。从今天起,把精力花在构建自己的上下文上。
在未来模型能力不断提升、Harness 越来越趋同的情况下,谁拥有更高质量、更完整、更实时更新的 Context,谁就能形成复利,也就能取得更多的价值。
- FIN -
如果觉得我的文章给你带来价值,欢迎关注我的微信公众号“杨攀同学”和“攀哥四十二”并加星⭐️。我会经常给大家分享商业、科技、创业、AI、出海全球化方向的洞察和思考。
另一个号
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-06-30
解析Agent Loop(智能体循环)的三层分级体系
2026-06-30
Cursor、OpenClaw 同时出手,“口袋编程”时代来了:程序员只用“动嘴”!
2026-06-30
从文本到多模态:大模型非结构化数据加工与质量控制实践
2026-06-30
从Anthropic的B端战略,给迷茫中的扣子一些建议
2026-06-30
Claude最新:创始人实操手册:打造 AI 原生初创公司(中文版)
2026-06-30
本体+AI驱动的AI智能体工厂-从设计到实现
2026-06-30
微信AI,能避开豆包手机的窘境吗?
2026-06-30
LangAlpha是如何在架构上实现Harness 和 Loop Engineering
2026-04-15
2026-04-07
2026-04-07
2026-04-24
2026-04-17
2026-04-05
2026-04-02
2026-04-05
2026-04-14
2026-04-24
欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。
在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。
一、 定义
本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。
会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。
知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。
二、 账号注册与登录
登录方式:本网站支持以下登录方式,您可根据实际情况选择:
微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。
手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。
账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。
实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。
未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。
三、 服务内容与规范
知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。
服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。
禁止行为:您在使用服务时不得实施以下行为:
利用技术手段批量爬取、下载、转存知识库内容;
将知识库内容用于商业目的或未经授权地向第三方传播;
干扰本网站正常运行或侵犯其他用户合法权益;
发布违法违规信息或从事违反公序良俗的活动。
四、 知识产权声明
权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。
有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。
侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。
五、 个人信息保护
我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。
您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。
您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。
六、 免责声明
内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。
不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。
第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。
七、 违约责任
如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。
如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。
八、 法律适用与争议解决
本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。
因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。
九、 其他
本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。
本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。
我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。