“毋在浮沙筑高台”：汪源谈智能体想从 80 分跨到 90 分，全卡在上下文

Sonnet 3.7 之后，模型已不再是瓶颈。

责编 | 王启隆

出品丨奇点折射（ID：rgznai100）

“现在的智能体产品已经到了 80 分的水平，接下来从 80 分走到 90 分，难点不再是大模型能力，不再是 Harness 工具不够，而是上下文的质量。”

前网易副总裁汪源，在网易将近 18 年，参与孵化了云音乐、严选、网易数帆等一批产品。2024 年离职创业，做了久痕科技，产品叫 remio，定位“以个人数据为中心的通用办公助理”。

在 2026 奇点智能产品大会上，他带来了一个角度相对底层的分享：整个智能体行业，正在忽视一件事——上下文。模型能力已经不是瓶颈，工具链也有越来越多的人在填坑，但质量最差、投入最少的那一环，是信息怎么被采集进来、怎么被转成模型能真正消费的格式、怎么被高效检索。

他在台上打开的那份 PPT，本身也是他产品的一个演示——它用 remio 对大会提供的模板做了批量风格迁移，几分钟完成。

以下为汪源的演讲实录：

智能体系统已是百万行代码级的复杂软件

智能体现在其实已经变成一个比较复杂的系统了。这里面大概有一些关键的数据，比如说几个月前很火的“龙虾”（OpenClaw）。大概在今年年初（12 月份或者 1 月初）的时候，因为它是开源的，我们就去分析了一下它的源代码。

我的印象是，当时它就已经有 73 万行左右的代码量了。这 70 多万行代码里面，90%都是 Peter 一个人写的，因为他是一个使用 AI coding 特别疯狂的人，所以他一个人码了 70 多万行代码。

然后两三个月前，Claude Code 因为不小心泄露了源代码，大家看了一下，也是有 50 多万行。而且这些代码还不包括没有被泄露的测试、评估等相关代码。所以我理解，现在相对有一定成熟度的智能体软件，基本上是百万行的代码量，已经是一个有一定复杂度的软件系统了。

这跟有些做了很多年的开源数据库差不多。整个智能体系统分成了很多不同的结构或模块，有管输入输出的，有管环境感知的，有管推理规划的，有管工具调用的，有管安全评估和控制的等等，模块非常众多。

但是，我们可以从更抽象、更高阶的层面去看整个智能体系统最核心的层次。我认为整个智能体系统虽然复杂，但最主要的是三个层面的体系和工作：一个是上下文工程，一个是大模型本身，第三个大家通常称之为Harness（驾驭工程）。

为什么这三个最核心？因为它们每个都有非常明确的职责。

上下文工程决定了输入，也就是大模型能够获得什么输入。针对这样的输入，大模型本身决定了会产出什么样的输出。但是最终这些输出能产生什么样的业务结果，是由 Harness 工程决定的。

比方说，Harness 工程的安全系统会决定一个输出（比如工具调用或操作指令）能不能去执行；你的工具链系统决定了大模型的输出能不能顺利被执行。如果系统里没有相应的工具，大模型即便产生了一个正确的调用指令，也不能带来成功的结果。所以从宏观角度，整个智能体系统可以拆解成三件套：上下文决定输入，大模型决定输出，Harness 决定结果。

瓶颈正在发生转移，现在卡在上下文

我们观察到，整个智能体系统的瓶颈正在发生转移。

过去在 2023 年的时候，非常多的工作受限于模型能力不够，所以你有一些很好的设计和概念也没法落地。比如当时有个非常火的开源项目叫 AutoGPT，短短几天就达到了 7 万个 Star。它在 2023 年其实就是做了一个很早期的 Agent Loop，跟今天核心的循环没有本质区别，但这个项目几乎没有带来任何可用性，因为那时的模型能力很差。

还有一个例子，2023 年 GPT-4 刚出来不久，Cursor 团队就推出了 AI Agent，但那时的 Cursor 基本上是个“废柴”。它的理念已经很领先了，但模型能力完全不够。

在 AI coding 场景里，大致来讲像 Sonnet 3.7 这样的版本是一个分水岭。3.7 之前的 AI Agent coding 基本上不能干活，你会感觉到大模型的使用成本还不如自己上手，所以那时主要还是在做代码补全，你一路按 Tab 键它就给你补全掉了。

但 3.7 之后直到今天，大家的需求变成了“我提一个需求过去，你就要帮我完成并做好测试”，真正的 AI Agent 才变得可行。所以早期最主要的瓶颈是模型能力。

到了中期（大概是整个 2025 年），我们可以看到 Anthropic 推出了一系列现在已经成为行业事实标准的规范——MCP 和 Skill。MCP 和 Skill 共同解决的是 Harness 层面的问题。MCP 让很多第三方的现有服务能以公共方式开放能力被调用；Skill 使得大模型在各行各业的场景里，能拿到一份好的“使用说明书”，知道怎么去执行工作。所以在整个 2025 年，整个行业都在拼命优化 Harness 层面的能力。

但是今天，在我们与客户、用户的交流中发现，现在越来越多的问题，如果它表现不好，核心原因是上下文不够。它不再是因为没有工具，也不再是因为模型能力不行，而是我们给到这个系统的输入本身就是不对的，质量不够高，或者信息不全面。

所以我理解，现在整个行业的投资并不是特别均衡。大模型吸引了特别多的投资，工具链受到的关注度也比较高，行业里有那么多人不赚钱也在拼命写 Skill 贡献经验。但是整个行业在上下文层面，也就少量 To B 的公司在专注做，大家的关注度和投入非常少。我有一个观点：现在的智能体产品已经到了 80 分的水平，但接下来我们肯定希望它能从 80 分走到 90 分。在这里面，难点不再是大模型能力，不再是 Harness 工具不够，而是上下文的质量。

上下文是一个独立的系统和基础设施

从产品视角看，我给两个具体的例子。

第一个例子，两三周前在我身上发生的真实情况。领导推荐我去参加一个培训活动，为此我需要填写一张 Word 文档的报名表，里面有三页内容。我把这张表交给了我们的产品 remio，它仅仅花了大概三分钟，就把所有信息全部自动找出来，并且成功填到了表里。

虽然中间有些小瑕疵，但 90% 都是自动完成的。要完成这件事，你肯定需要一个会编辑 Word 的工具，模型能力也要比较强，但这里面最难的是：你怎么样才能做到软件里有关于我的这么多信息，而且都是精准的？这其实才是最难的。

第二个例子来自我们的一个会员用户。他专门用我们的产品来组织和管理上下文。他会频繁录制会议录音；常态化地开着我们的网页浏览器插件，实时保存访问过的所有网页内容；还会把电脑上所有的文档（PPT、PDF、Word）全部交给 remio 实时处理。这样他就知道，自己所有的上下文都在 remio 体系里。在任务一开始时，他会让 remio 找到相关的所有资料，再交接给 Cursor 或 Gemini 等其他智能体去处理。可见，上下文其实是一个相对独立的系统和基础设施。

怎么样做好一个比较好的上下文基础设施？我觉得主要有三点。

第一点，解决“信息有没有”的问题。如果没有信息，再强的模型也没法凭空编造出来。我们的核心理念是：把一个用户接触过的所有信息都实时记录下来。但做法有讲究，整个行业其实走过弯路。

比如 Rewind 和微软的 Recall，它们是在电脑上实时录制屏幕（每秒截屏）和声音。这种方式非常差，因为你收到一个文档存下来了，录屏程序抓不到文档内容，除非你打开文档每秒翻一页。而且从一堆图片里还原文档内容，是一件特别复杂的事情。

还有一种方式是脖子上挂个录音设备，一天开 8 小时。但声音只占上下文不到 10%的信息输入，每天大量的信息其实来自视觉输入。你在公司办公不会天天说话，但已经做了很多事。所以获取信息需要多种手段：在线资料用浏览器插件；本地文件实时建索引、做解析；开会做录音；Notion、飞书等内容做实时同步。

第二块，把信息转成大模型能稳定消费的输入。信息抓到了只是第一步，直接把 PDF 喂给大模型它是读不懂的，它必须现场编织解析程序再去调用，这中间会丢失非常多的信息。

举个例子，我之前分享过的两页很常见的 PPT，绝大多数软件只能看到标题，看不到内容。ChatGPT 花了五分钟费劲折腾，终于读到了图片内容。为什么？因为这种图不是典型的图片格式，而是 Windows 早期的矢量图格式 WMF。这种格式解析很困难，但在典型 PPT 里占比很高（我自己的 PPT 里将近 30%都有）。所以你今天用一些产品对 PPT 做总结问答，结果奇怪，很可能就是它根本没读到完整内容。

还有 PPT 里复杂的页面布局。现在大部分软件简单粗暴地把资料转成 Markdown。Markdown 很优雅，但表达能力受限，转码后只剩下文本，连接线和逻辑关系全没了，问答效果肯定很差。

为此，我们做了一个叫KRL的语言，把页面布局转成精简但信息高效的表达，有了这个表达，送给普通的初级模型也能回答得很好。

再比如 Excel。大部分软件认为它是规范表单，默认头两行是表头，下面是数据。但实际上很多 Excel 里面分成不同的复杂区块，需要多行联合形成表头。不认真分析就会发生问答错误。

第三块，解决“怎么找得快、找得准”的问题。一个资深用户的资料可能有 30 万到 50 万份，相当于一个个人搜索引擎。

在这一块，行业里也有个误区，算是被 Cursor 带坏的。Cursor 处理代码数据时，用了一种简单粗暴但他们觉得优雅的方式：不建索引，需要时直接用文件系统的检索命令（find、grep、ls、ripgrep）去找。在代码场景下，切分支重建索引成本确实太高，这有点道理。但这同时也导致了很多人觉得所有场景都不需要建索引了。

这是一个大误区。我们用真实办公场景（1500 个资料）做了评测：如果你建了好的向量化语义索引和倒排索引，召回率和排序质量远远超过文件系统检索。在 Cursor 里可能要循环找三四次，而在有完善索引的 remio 里，一次性就能达到 90%以上的召回率，而文件系统检索只能达到 70%。

新的时代需要新的内容格式

第一，我们需要一个更好的内容表达形态。2024 年年中之前，我们也是把资料转成 Markdown 加图片。但后来发现 Markdown 缺陷太大。PC 时代我们有 PDF 和 Office；互联网时代我们有 HTML 和 CSS；到了 AI 时代，大家都用 Markdown，但它的表达能力太受限了。

所以从去年 Q4 开始，我们做了一个内容表达语言叫 KRL。它其实是一个 JSON，但做了特殊设计。我们应该是第一个同时面向高 Token 效率、高可编辑性、高保真度的 AI 时代统一内容形式。

它的保真度能达到 99.7%。把 PPT 抽取成 KRL，再重新生成 PPT，前后几乎一模一样，肉眼看不出区别。同时，用于内容理解时，它只有原始大小的 1.2%；用于生成和编辑时，大小只有 5.6%。从语义表达质量上来讲，KRL 的问答质量能达到 9 分以上，而 Markdown 只有 3.5 分。

这在内容生产层面非常有价值。比如生成和编辑 PPT，Cursor 是目前行业里效率最高的，但跟我们比差距很大。我们只要生成 KRL 语言一渲染就变成 PPT 了，不需要写动态程序代码去操作原始格式。我们的速度比它快两三倍，成本只有 1/4 到 1/3。

做局部编辑或者模板迁移也非常顺畅。比如我把原始资料套用 GTC 主办方的模板，几分钟就搞定，还能把多个页面合并并保持风格。这任务交给其他产品，它们会很挣扎。

第二，基于端侧智能算力的推理加速。海量数据应该尽可能用本地算力处理。一来本地算力没太大成本；二来用户把几十万份资料全传到云端会非常恐慌，尤其是欧美用户对隐私保护非常关注。

我们要有好的策略来分配端侧的 NPU 和 GPU。NPU 功耗低（大概两三瓦），适合做常态化、耗时长的预处理，比如建索引、向量化计算。GPU 计算快但功耗高（笔记本上大概 10 瓦），持续运行几分钟风扇就会狂响，适合需要快速出结果的场景。

我们在端侧做了很多推理加速：用 GPU 做 OCR 识别提升 3 倍以上速度，版面分析提升 5 倍；用本地算力做语音转写，速度提升将近 40 倍；用 NPU 做 embedding 向量化计算，速度提升将近 20 倍。在端侧做运算，可以把会议纪要这种典型场景的成本降到云端方案的 1/5。所以很多云端软件只能提供每月 300 分钟免费试用，而我们可以提供 1500 分钟。

有一句话叫“毋在浮沙筑高台”。现在智能体很火热，大家觉得有无限可能，但其实整个系统架在一个像沙子一样的底盘上。轮胎和底盘很差，虽然也能跑，但动不动就爆胎，离理想状态还很远。

上下文基础设施是制约智能体表现的很大因素。要做好它：第一，信息要能存下来；第二，输入要变成大模型能消费的高质量格式（比如我们提出的 KRL）；第三，千万不要迷信简单粗暴的文件系统检索，一定要建好索引；第四，充分利用端侧的 NPU 和 GPU 算力。希望大家能共同关注上下文基础设施，不要睁一只眼闭一只眼糊弄过去，一起把它做得更好。

Q&A 问答环节

提问：KRL 格式是否开源开放？

汪源：刚才有朋友问是不是开放的。现在的状态是这样的，这个格式是开源、开放的。KRL 也能生成正确的格式，因为它很好学，几百行的文档模型就读懂了。但是把这种格式直接生成 PPT 属于我们产品的能力，这个不开放。如果你使用 KRL，可以接上我们产品的命令行工具（CLI），两者是可以接起来的。

提问：你们是基于什么样的场景产生了定义 KRL schema 的念头？以及如果 schema 有改动，怎么保证在大部分场景下效果是提升的，而不是下降的？

汪源：这是两个问题。第一个，我们一开始把内容都表达成 Markdown，发现处理不了很多问题。另一种形式是用软件包直接读取 PPT 或 Word 的 XML 原始格式，但发现开源软件包里 bug 一大堆。所以我们认为，不如干脆做一个高质量的中间语言，体积非常小，但表达的信息全面且精准。于是就萌生了这个念头开始做。一开始就我一个人做，直到今天大部分工作还是我一个人在做。现在有了 AI coding，老工程师也焕发第二春了，每天编代码产出还挺高。

第二个问题，怎么保证改动后的效果。我们会收集大量的文档做评测。做智能体软件，功能实现的代码往往不是最多的，做评测的代码比它还多。比如我们那个 99.7% 的保真度是怎么测出来的？我们拿好几百个文档全部跑完，把前后的 PPT 每一页截成图片，逐个像素去对比，看是不是 100% 一致。在这个过程中，其实我们大部分时间不是在开发功能，而是在做评测。

（投稿或寻求报道：zhanghy@csdn.net）