永久记忆并不是最难的部分。真正困难的，是让 Agent 在长期任务中始终保持干净、稳定、节省成本且可持续的思考能力。

关于老生常谈的永久记忆系统，其实它的实现复杂度，远低于表层记忆系统。我们设计的架构，让表层记忆系统本身已经非常接近永久记忆，只不过它不执着于记忆原文，而更强调结构、状态与关键事实的持续保留。

至于永久记忆系统本身，我们采用的是一套独立的 MEMORY 工具组。它通过写日记加 SQLite 的方式工作，让模型先通过关键词命中定位记忆，再通过 MEMORY CHEAK 找到记忆锚点，再由 MEMORIE READ 回溯历史内容。这套机制足够稳定，也足够可控。

但历史记忆的大部分时间其实并不重要。相比堆积更多的“旧信息”，我们更倾向于把精力放在更精密的表层记忆系统上。所以这里我们不打算在永久记忆本身继续展开，而是进一步谈上下文工程策略，因为那才是真正决定 Agent 长期执行质量的地方。

“Simplicity is prerequisite for reliability.”

可靠性的前提，是足够的简洁。

Edsger W. Dijkstra

我们要解决的问题，从来不只是上下文长度。

真正的问题在于，我们需要一套更优越的上下文工程控制方案，去面对所有平台都在遭遇的现实瓶颈。我们观察到，大多数 Agent 在执行大项目时，依然在频繁调用 bash 工具去阅读、去排查、去验证，而几乎每一步都会往返一次历史上下文。

在历史上下文没有引入我们设计的动态方案之前，模型调查一个 Bug，往返几十次上下文，token 的累积损耗就可能高得惊人，甚至逼近一百万级别的 input tokens。那是非常不健康的工作方式。

说得戏谑一点，如果结果真是这样，那为什么还要让模型费劲地调用那么多工具、查阅那么多信息？为什么不干脆把整个源码一次性丢给 Agent，让它直接 apply patch 或 edit files 开始工作？那样也许都不至于损耗到近百万 tokens，而且还更快，至少省掉了来回查阅的时间。

正是基于这些问题，我们的上下文工程还在不断推进新的研发。我们不会因为某个局部技巧暂时有效就停下来。我们更倾向于默默地研发，直到它能相对完整地问世。这个过程也许很长，也许很久，但我们一直在实验性地前进。

当很多人还在尝试理解他们自己都说不清的上下文问题，或者陷在 AGENT 工具调用的表象里时，我们已经带着 Agent 在第一梯队的前沿继续推进。那我们就没有理由自卑。至少在这件事上，我们就是这个时代前沿的一部分。

Next complexity layer

一个模型通常只适合应付一个专项工作流。可一旦你希望它去操作一个系统，就必须给它接入更多工具、更多提示词、更多职责。而一个模型拥有越多工具、越多提示词，就意味着它的智力会被更高强度地消耗。它不再清晰、干净、锐利，而会逐渐被调度负担本身榨干。

模型很适合执行专项工作流，比如编程；但它未必适合一边编程，一边管理系统，再一边协调其他模块。为了解决这个边界问题，我们不得不提出 AGENT 协同。但我们的协同，不是行业里常见的“为了协同而协同”。

很多人搭建了多 Agent 协同结构，却没有真正实现 1 + 1 大于 2。如果一个模型自己就能完成的工作，额外拉进来多个模型，往往只会制造噪音。真正的协同必须是按需协同，是模型真正学会求助，在真正需要帮助、而且确实能够被帮助时才发生。

让不同的模型负责不同的职责，不是为了看起来像协同，而是为了让模型之间真的互相沟通、互相帮助，并由母体 MATRIX 统一调度与管理。

我们引入了模型自分裂技术，让 MATRIX 不再是一个亲自工作的 Agent，而成为一个调度管理型的 Agent 母体。它拥有成百上千的工具，在必要时可以自分裂出不同的子 Agent，为它们配置不同的提示词、不同的工具组、不同的职责边界。

这些流窜 Agent 与母体保持持续沟通。一旦需要额外的工具支持、额外的帮助，母体就可以及时介入。换句话说，我们让 Agent 像蚁群一样工作。MATRIX 因为掌握大量工具而失去一线执行能力，却获得更强的调度能力。

你如果从“执行力、理解力、调度力”三个维度去看模型的能力边界，很多事情就会突然变得非常清楚。

一个模型在工具少、提示词少的情况下，执行能力强，但理解能力弱，调度能力也弱。工具少、提示词多时，它执行能力下降，理解能力增强，但调度能力依旧有限。可一旦工具多、提示词也多，它的调度能力与理解能力都会提升，只是执行本身未必仍然敏锐。

只要理解这个特性，我们就能设计出不同种类的 Agent。例如拥有大量工具与提示词的 MATRIX 母体，负责分发任务；再由少量工具、少量提示词、执行能力更强的流窜 Agent 去真正工作。

没错，你刚刚听到了一个很新颖的词汇: AGENT 自分裂技术。