Lumen 最初并不是以一个完整平台的形式出现的。
开始这个项目时，我没有准备一份详细的产品规划，也没有想过它最终会拥有多少功能。那时真正推动我动手的，主要是三个很直接的原因：我对 AI Agent 感兴趣，它确实能够帮助我的生活；我对当时使用的 Agent 产品并不满意；同时，我也需要一个可以自由实现和测试新想法的地方。
第一个原因，是实际需求
在开始开发 Lumen 之前，我已经关注 Agent 一段时间了。相比只负责回答问题的聊天模型，Agent 更接近一种能够持续完成任务的系统。它可以读取文件、搜索信息、调用工具，根据得到的结果继续判断，并把一个任务从开始推进到结束。
这对我来说并不只是一个有趣的技术概念。
我平时需要处理学校作业、个人项目、研究、代码和大量文件。很多时候，我缺少的并不是一个告诉我“应该怎样做”的模型，而是一个能够真正把不同步骤连接起来的工作环境。它需要理解任务，也需要知道什么时候应该搜索、读取文件、运行代码或继续检查结果。
所以，我开始做 Lumen，并不是为了证明自己也能开发一个 AI 软件。更直接的原因是，我确实需要这样的工具。
第二个原因，来自我对 OpenClaw 的不满
在建立 Lumen 之前，我使用过一段时间的 OpenClaw。它让我更具体地接触到了 Agent 产品，也让我确认，这类系统确实有可能进入日常工作，而不只是作为一次性的技术演示存在。
但使用得越久，我就越难接受它的界面设计。
这种不满并不只是某一个按钮不好看，或者某一个页面不够精致。真正的问题是，整个产品给人的感觉始终缺少整理。不同元素互相竞争，信息层级不够清楚，许多功能像是不断叠加上去的，而不是经过统一判断后被放在一起。
在我看来，这与项目本身拥有的资源和技术能力并不相称。
一个由成熟开发者制作，并获得大量投入的 Agent 产品，最终却用一种接近开发面板的方式面对普通用户，这件事让我很难理解。后来手机版上线，我看到的许多讨论里，同样有人反复提到它的界面和交互问题。
底层系统当然可以很复杂，但复杂不应该被直接留给用户。
一个 Agent 可能拥有模型、工具、记忆、权限和任务状态，也需要展示大量信息。但这并不意味着它必须看起来混乱。界面不是技术完成之后再加上去的一层装饰，它决定了用户如何理解这些能力，也决定了一个复杂系统是否真的能够被长期使用。
我逐渐意识到，我想要的并不只是一个功能更强的 Agent。我还希望它能够以一种清楚、自然，并且让我愿意每天打开的方式出现。
既然我无法接受现有的答案，那就自己做一个。
Lumen 最早的版本其实非常简单。
它当时还叫 Local Intelligence Console，只包含基本的模型对话、会话栏、Context 面板和输入框。它更像一个可以运行本地模型的个人工作台，距离后来意义上的 AI Platform 还很远。
但从一开始，我就没有把界面当成最后才处理的部分。
输入框的大小、侧栏的密度、按钮的重量、设置页的层级、深色模式的背景，甚至几个图标有没有处在同一条线上，都会影响一个软件是否舒服。这些修改单独看起来很小，有时甚至只是几个像素的差别，但它们共同决定了一个项目究竟是临时工具，还是可以长期留在桌面上的产品。
第三个原因，与实验有关
我平时会从视频、文章和其他项目中看到很多新的想法。有时是一种新的 Agent 架构，有时是不同的记忆方式、工具规划方法、研究流程或交互设计。
看到这些内容时，我经常会产生一个问题：如果把它真正放进一个系统里，它会不会有用？
问题在于，在 Codex 或 OpenClaw 这样的成熟环境中，这类实验通常并不容易。
Codex 是一个很强的开发工具，但它本身不是一个可以由我自由改变的 AI 产品。OpenClaw 已经形成了自己的架构、设计判断和产品边界。想在这些系统里加入一种新的运行逻辑，往往不只是实现那个想法本身，还需要先理解大量原有结构，再处理兼容和限制。
很多时候，我真正想验证的部分只占整个工作的很小一部分，其余时间都花在适应别人已经做出的决定上。
因此，我需要一个属于自己的实验环境。
在 Lumen 里，我可以看到一个想法后直接尝试实现它。如果它有价值，就让它进入系统；如果效果不好，就删除、重做，或者换一种方法。新的模型可以接入测试，不同的工具规划方式可以进行比较，搜索结果可以逐渐发展成更完整的证据系统，Agent 也可以从一次简单的工具调用，慢慢变成能够持续计划、执行和检查的任务循环。
这些功能并不是在项目开始时就被完整规划好的。
Lumen 的发展更像是一连串问题推动出来的结果。
模型回答缺少可靠来源，于是开始建立网页证据系统。文件处理不够稳定，于是加入更完整的解析和检索。功能越来越多，手动测试开始变得困难，于是建立独立的 Test 工作区。一次普通请求无法承担较长的任务，于是又开始设计可以暂停、恢复、取消和重试的运行方式。
每解决一个问题，新的问题又会出现。
Lumen 也从一个简单的本地聊天界面，逐渐形成了 Chat、Test 和 Agent 三个相互区分的工作区。它开始拥有文档处理、视觉理解、网页搜索、代码执行、研究流程、任务运行时、记忆和安全边界。
回看整个开发过程，我发现 Lumen 一直同时承担着三种角色。
它首先是一个我自己需要使用的工具，所以功能不能只停留在演示中。它也是我对现有 Agent 产品的一种回应，所以界面和使用体验不能被当成次要部分。与此同时，它还是一个实验平台，需要允许新的想法被快速放进去，经过真实测试，再决定是否留下。
这三个原因后来也逐渐变成了项目的方向。
Lumen 不需要为了显得成熟而模仿现有平台，也不需要为了拥有更多功能而接受混乱。它可以吸收其他项目中的好想法，但不必继承它们全部的结构。它需要拥有足够复杂的底层能力，同时尽量让这种复杂性在界面上保持安静。
最初启动这个项目时，我并不知道它最后会变成什么。
我只是知道，现有工具没有真正满足我的需求，而我看到的很多想法，也缺少一个合适的地方可以被实现。
所以，我建立了那个地方。
后来，它有了自己的对话系统、工具、研究架构、运行时和桌面应用，也逐渐形成了一套相对稳定的视觉语言。但这些变化并没有改变项目最初的原因。
Lumen 仍然来自一个很简单的判断：
如果一个工具确实能够帮助我的生活，而现有的实现又无法让我满意，那么与其继续等待别人把它做好，不如亲自开始。