Zleap-Agent：自带稀疏注意力的 Agent Harness

开源链接：https://github.com/Zleap-AI/Zleap-Agent

大家好，我是 Jomy。去年开始，我和我的团队一直在研究企业内部的本地化 AI 落地。

企业场景和个人玩具不一样。数据不能随便出内网，成本也不能无限往上堆。所以很多时候，我们不能默认用最贵、最大的模型。

我们选择了小参数模型，也一直在研究怎么把本地模型用好。昨天讲解的 SAG 技术，解决的是底层数据检索和上下文生成。

但研究完数据层之后，我们发现 Agent Harness 层也有同样的问题。

过去一年，大家都在说上下文变长了。

显卡更便宜了，推理框架更成熟了，模型能吃进去的 token 越来越多。于是很多人有一个错觉：

既然上下文变长了，那就把工具、记忆、历史、规则都塞进去。

问题是，窗口变大，不代表注意力变便宜。

模型行业自己也知道这个问题。很多研究都在做稀疏注意力、滑动窗口、长上下文压缩，本质上都是一件事：

不要让模型每一步都看所有东西。

我们觉得，这件事不只应该在模型架构里做。

Agent Harness 层也应该做。

而且更简单。

今天这篇，分享一下我们的思路。

注意力很珍贵

上下文窗口变长，只代表模型能装下更多 token。

不代表它每一步都能准确使用这些 token。

能放进去，不代表模型能稳定用上。尤其是本地小模型。它本来就没有那么强的指令遵循能力，也没有那么强的长上下文定位能力。你再把几十个工具、几百条历史、各种记忆和规则全塞进去，它不是变聪明了，而是先被迫做一遍信息筛选。

现在很多 Agent Harness 的设计，默认背后有一个很强的模型。

Claude Code 就是一个典型例子。它把 Claude 包成一套 agentic coding 工具链，让模型可以读代码、改文件、跑命令、接 MCP、用 hooks、开 subagents。

OpenClaw、Hermes 这类新工具，也在往同一个方向走：给模型加执行环境、加工具、加长期记忆、加自动化能力。

这些系统很重要。它们把 Agent 往前推了一大步。

但问题也在这里。

工具越来越多，记忆越来越长，规则越来越厚，日志越来越完整。最后还是让模型自己在里面找路。

这不是本地小模型才会遇到的问题。大模型只是更能扛，所以问题不那么明显。但注意力浪费最后都会变成三件事：

更慢。更贵。更容易错。

Workspace

Zleap-Agent 的判断不一样。我们不是先问“Agent 能接多少工具”。我们先问：

这一刻，它到底应该在哪个 workspace 里？

Workspace 是 Zleap-Agent 最重要的概念。

它不是子 Agent，也不是工具分组。

Workspace 是 context 和 tools 的隔离层。

这件事其实很好理解。

就像人使用操作系统。

主 workspace 是桌面。桌面不应该塞满所有软件里的所有按钮、所有文档、所有历史记录。它只负责让你知道有哪些软件可以打开，以及现在该打开哪个。

进入销售 workspace，就像打开 CRM。你看到客户、合同、跟进记录和销售工具。

进入财务 workspace，就像打开财务软件。你看到发票、报销、预算和审批规则。

进入内容 workspace，就像打开内容编辑器。你看到选题、素材、发布记录和写作经验。

同一个 Agent，站在不同工作台前。

但它不需要每次都看到所有东西。

这和子 Agent 很不一样。子 Agent 更像临时找了另一个人帮忙。它有自己的角色，自己的提示词，自己的上下文。做完之后，把结果丢回来。

Workspace 不是这样。

Workspace 仍然是同一个 Agent 在工作。只是当前可见的工具、上下文和记忆变了。更关键的是，每个 workspace 都有自己的工作记忆。这些记忆会留在这个 workspace 里，不会随便串到主空间，也不会串到别的 workspace。

主空间只负责调度，不应该拿到所有细节。

这点很重要。因为主空间如果拿到了所有工作区的记忆和工具，它就又变回了那个“大脑塞满一切”的传统 Agent。

还有一个自然的延伸：LLM 不一定要被写死在 Agent 里。

未来完全可以给不同 workspace 配不同模型：普通沟通用便宜模型，复杂分析用强模型，视觉工作区用多模态模型，本地敏感数据用本地模型。

这就自然形成了模型自动路由，也形成了端云协调：能在本地做的，就在本地做；需要更强能力的，再交给云端模型。

不是先选模型，再硬塞任务。

而是先选 workspace，再由 workspace 决定最合适的模型。

把 Context 当内存

Context 不应该只被看成一段 prompt。

我们过去太习惯把 prompt 当成一段文本。把 system、人格、工具说明、历史、记忆全部拼起来，最后发给模型。

这很粗糙。

在 Zleap-Agent 里，我们把 Context 像内存一样分成几个区域，大致可以总结为：

Context = System Prompt + Workspace Prompt + Tools + Memory + History

System Prompt 是系统提示词 + 人格。它定义这个 Agent 的底层行为和表达方式。它不应该随着 workspace 来回变。

Workspace Prompt 是当前工作区的说明。它告诉模型：你现在在哪个工作台前，你能做什么，你不能做什么。

Tools 是当前工作区里可以用的工具。不是全局工具池。

Memory 是当前需要被带进来的记忆。不是完整历史。

History 是用户近期的消息。不是整个对话的回放。

这些内容有两种加载方式。

一种是 prefetch，也就是程序提前放进来的内容。比如当前用户的长期偏好、当前 workspace 最近相关的事件、这个 workspace 常用的经验。这些内容应该短、准、可控。

另一种是 agentic，也就是模型需要的时候自己去拿。比如它看到一条旧记忆的摘要，但用户追问“详细说说”，这时它再去读详情。比如它看到一个经验标题，觉得这次任务很像，再去展开完整方法。

在 Runtime 中必须严格规定好：

哪些是预取的。哪些是按需读取的。

否则所谓上下文管理，最后还是一锅粥。

所以在不同 workspace 中切换，本质上就是切换不同的 Workspace Prompt + Tools + Memory + History。System Prompt 保持一致，Agent 的人设和行为风格也就保持了一致。

记忆要分区

接下来我们详细讲一下 Memory 的设计。

它是 workspace 能够跑通的关键。

如果 Memory 只有一个“长期记忆”的篮子，那还是太粗。

人类自己也不是这样记东西的。我们会记一个人，记一件事，也会记一套经验。

Zleap-Agent 也是这样。我们把记忆分成了三类。

第一类是对人的记忆。比如这个用户喜欢直接说结论，讨厌空话；比如他经常做企业产品；比如他希望 Agent 用中文沟通。这类记忆应该跟用户绑定。因为同一个 Agent 在组织里可能被很多人使用，A 的偏好不能影响 B。

第二类是对事的记忆。比如某个客户上次沟通到哪一步，某个合同为什么卡住，某次活动复盘里发现转化率掉在了哪一环。这类记忆既跟用户有关，也跟 workspace 有关。销售 workspace 里的客户推进，不应该跑到财务 workspace 里。财务 workspace 里的报销规则，也不应该污染内容 workspace。

第三类是经验。比如“做客户复盘时，先看最近三次沟通记录，再看成交阶段变化”；比如“写周报时，先按目标、进展、风险、下周计划组织”；比如“处理报销问题时，先判断是票据缺失、预算超额，还是审批链卡住”。

经验可以被用户共享，但必须脱敏。

它应该留下方法，而不是留下某个人的隐私、某个客户的细节、某个项目的原始资料。

这就是为什么 workspace 必须有自己的记忆。不是为了概念好看，而是为了避免污染。

记忆一旦串了，Agent 就会开始胡说。

更严重的是，在企业场景里，记忆串了就是安全事故。

数据库驱动

一旦 Agent 要在组织里被多人共享，问题就不再只是“怎么记住”。

而是：

谁的记忆，能被谁看到？

哪个 workspace 的记忆，能进入哪个 workspace？

哪些经验可以被用户共享，哪些信息必须永远隔离？

所以从 day 0 开始，Zleap-Agent 就不是按单人本地文件夹来设计的。

我们把 Agent 的数据都交给数据库来管理。

一个好的 Agent，未来一定会在组织里被很多人共享。销售用它，运营用它，财务用它，研发用它，老板也用它。每个人都有自己的偏好、权限、历史和任务。每个 workspace 又有自己的上下文、工具和记忆。

这种结构，不能靠文件系统解决。

文件系统更像原始日志。你可以把东西写进去，也可以读出来。但它不适合做多租户隔离，不适合做细粒度权限，不适合高频 agent loop，也不适合管理多层记忆分区。

Zleap-Agent 的记忆系统不是偶尔读一次文件。

它是每一轮 agent loop 都要参与的系统。

模型进入哪个 workspace，要查当前 workspace 的记忆。模型调用工具之后，要判断哪些信息值得留下。任务结束之后，要沉淀事件。多个用户共享同一个 Agent 时，还要保证用户之间不串记忆，workspace 之间不串记忆，用户共享经验又能被安全复用。

这就是数据库驱动的意义。

它不是“把文件换成表”。

它是把 Agent 的运行过程变成一个可以分区、可以审计、可以回滚、可以复用的系统。

总结

模型行业在模型层研究稀疏注意力，是为了让模型不要看所有 token。

Zleap-Agent 在 Harness 层做 workspace，是为了让 Agent 不要看所有上下文。

一个在模型里面做。

一个在系统外面做。

但目标是一样的：

把注意力用在真正重要的地方。

所以我们说，Zleap-Agent 不是又一个 Agent 框架。

它想提出的是一个新的 Agent Harness 范式。

未来的 Agent，不应该靠一个越来越长的 prompt 去硬撑。它应该有工作区，有分区记忆，有数据库底座，有模型路由，有清晰的上下文边界。

这样，小模型才能真正可用。

大模型也会更快、更准、更省钱。

今天，我们也正式开源了 Zleap-Agent 的 Preview 版本。这个版本主要是为了把具体的逻辑和思路展示出来，里面还有很多细节没有优化。如果你对这个方向感兴趣，也欢迎一起参与到开源版本的迭代中来。

下一篇文章，也是这个系列的最后一篇文章，我会给大家分享一下，我们基于 SAG 和 Zleap-Agent，在产品应用上的新思路。明天见！