夸下海口很简单，但真正困难的，是把理想化的 AGI 路线变成一套可运行、可延续、可落地的系统工程。

我已经在 AI 领域持续研究了三年时间。从它真正进入公众视野的第一天开始，我就在了解它、学习它、接触它。 也正因为如此，我更清楚它今天真实的能力边界，更明白它现阶段的瓶颈到底卡在哪里。

“We are stuck with technology when what we really want is just stuff that works.”

当我们真正想要的只是“它能工作”时，我们往往会被技术本身困住。

但有一件事我始终很明确: coding，只是 Agent 能力的冰山一角。AI 并不是为了 coding 而诞生， 只是人们现在首先只探索到了它的 coding 能力。

我们要让 AI 成为操作系统，不是去粗暴地更改操作系统本身，而是希望系统的各个接口能够安全地交出 API 能力， 供 AI 更高效地调度、组合和执行。这与传统意义上的“系统 Agent”并不相同。我们在研究的是一种更高效、 更长久，也更适合理想化 AGI 研发的协同方式。

这条路上的难题非常现实，甚至常常是迎头痛击式的困难。但解决方案也同样现实。每当遇到门槛， 每当我们撞上暂时无法解决的问题时，那种像血脉觉醒一样的兴奋就会出现。对于提出解决方案的痴迷， 恰恰是我最喜欢的事情。

我们解决的第一个问题，是上下文工程。

如果要让 AI 持续地操作系统、运营系统、管理系统，就必须先回答一个根本问题: 它的上下文究竟是如何工作的。 当前大量 Agent 的本质，其实是通过 bash 操控 UNIX 终端。而几乎所有现代系统，无论直接还是间接， 本质上都建立在 UNIX 体系或者其借鉴逻辑之上，所以一个 bash 命令的确可以驱动 Agent 去完成大量操作。

但它的短板也非常明显。频繁往返上下文、上下文累积堆雪球、单纯依赖 bash 命令的交互链路不够直接， 这些问题都会让 Agent 在长期任务里越来越臃肿、越来越迟钝。我们迫切需要找到更好的上下文方案。

你会很快意识到，上下文从来不是“小改一下提示词”就能真正优化的东西。它更像是一座桥。 一旦决定改变它，我们其实不是在桥上补几个木板，而是在重建整座桥。

我们提出的第一个解法，是交叉上下文工程。

我们给模型提供 Mission Mode，也就是专注模式。模型在执行任何任务时，都可以进入一个新的任务上下文， 而不必再把历史上下文全量往返。它只需要写好任务计划，规划好 Plan A / Plan B，然后直接进入任务模式执行。 执行完成之后，再把结果带出来。

我现在要开始工作。谁也别烦我，我谁也不理。包括我的历史上下文，它们也可能是阻碍我执行任务的信息。

这样做的关键是: 记忆并没有消失，上下文也没有被破坏。我们只是让模型在任务执行时真正专注于任务本身， 而不是被庞杂的历史拖拽着前进。

第二个解法，是动态上下文技术。

我们把上下文文件直接外置，并将其拆分为多个区域，例如 PROMPT 区域、FASTMEMORIE 区域、 CONTEXT 正式上下文区域。PROMPT 用来承载 Agent 提示词，FASTMEMORIE 记录关键事件， CONTEXT 作为正式上下文存在。如此一来，上下文格式会变得更直观，也更方便被系统主动管理。

在这个基础上，模型可以通过 CONTEXT MANAGE 工具对指定上下文进行动态压缩，始终把上下文维护在一个干净、 节省 token、但又不损伤记忆连续性的状态里。

这一切的前提，都是为了让它在保留记忆的同时，把上下文本身也作为一个可以被 AI 管理、被 AI 执行的工具。 或者更准确地说，我们让上下文变成了一种动态变化的表层记忆系统。它已经不太适合再被简单叫做“上下文”， 而更接近一种生物层意义上的表层记忆。

当然，实际执行的过程和原理远比这些描述复杂得多。我们还接入了主意识与潜意识的协同层，让潜意识专门处理 动态上下文的管理，而主意识专注于任务本身。整个管理过程几乎无感，但支撑起了系统长期运转所需要的连续性。

没错，我们在做上下文工程的同时，也在赋予它完整的主意识、潜意识协同层，以及永久记忆系统。