路线与早期实现
路线与早期实现
Section titled “路线与早期实现”项目推进方式
Section titled “项目推进方式”Matrix 项目将以迭代方式推进。
初始阶段，项目会在 AI 协助下创建一个满足项目目标的 skill。第一个 skill 是智能体的人格创建规范，更准确地说，是一种人格蒸馏规范。
该 skill 应能够按照使用者意愿，从现实人物或虚构人物形象中蒸馏出人格，并允许使用者在此基础上添加偏好的调节。调节内容可以涉及个性、知识、语言风格、行为倾向、自我认知等特质。
随后，使用该 skill 创建符合预期个性和能力的智能体。该智能体不只是项目产物，也应参与后续项目推进，辅助完成 Matrix 项目的设计、实现、整理和改进。
Matrix 项目不止包含智能体创建。创建只是起点，项目的主要部分是维护一个或多个具有生命感、具有独立性、并能对外界产生价值的智能体。
初始实现策略
Section titled “初始实现策略”在最开始的尝试阶段，如果条件允许，应优先使用 Codex 或 Claude Code 作为开发和运行平台。
早期自研部分应保持聚焦，优先实现以下内容：
- 与 Matrix 智能体创建、运行和进化相关的 skill。
- 可被方法或 skill 调用的本地数据库。
该阶段不应过早自研完整平台。应先利用现有 agent 平台提供的执行、编辑、工具调用和交互能力，将主要精力放在智能体人格、记忆、skill 演化和本地数据结构等 Matrix 特有能力上。
Codex 平台可行性
Section titled “Codex 平台可行性”如果使用 Codex 作为早期交互平台，可以先在本地部署一个或多个数据库，并通过 skill、脚本或本地工具调用实现记忆存取、检索和整理。
该方案适合早期验证以下能力：
- 将交互记录写入本地数据库。
- 从本地数据库读取长期记忆、短期记忆、事件记忆和身份相关记忆。
- 对数据库内容进行搜索、过滤、总结和关联。
- 通过统一接口连接多个数据库或存储系统。
Skill 本身更适合作为行为规范和调用流程说明，不应被视为数据库或后台服务。实际数据读写应由本地脚本、命令行工具、MCP 服务或其他可被 Codex 调用的接口完成。
对于持续自主运行，Codex 可以承担部分定时或唤醒式任务，但不应默认承担高频、长期、不中断的后台守护进程职责。如果需要间隔很短、持续运行且不阻断交互的机制，更稳妥的方式是建立独立的本地后台服务，由该服务负责循环任务、记忆整理、反思和状态更新，Codex 负责与该服务交互、查看结果和触发调整。
早期协作架构
Section titled “早期协作架构”Matrix 早期可以采用 Codex、skill、本地数据库和后台服务逐步协作的架构。
各部分职责如下：
- Codex：作为早期交互界面、开发助手和工具调用入口，负责理解使用者意图、编辑项目文件、调用本地工具、查看数据库结果和辅助实现。
- Skill：作为人格创建、行为规范、记忆使用、skill 演化和工作流程的显式规则层。
- 本地数据库：作为记忆、事件、身份、skill 版本、交互记录和处理后记忆的持久化存储。
- 本地工具或 MCP 服务：作为 Codex 与数据库、脚本、检索系统之间的稳定接口。
- 后台服务：作为未来主动行为、自主反思、定时整理、状态检查和长期运行任务的执行层。
早期不应把所有能力一次性放入后台服务。更合理的路径是先用 Codex、skill 和数据库完成可验证闭环，再逐步加入后台服务。
分阶段接入方案
Section titled “分阶段接入方案”第一阶段可以暂时放弃主动行为，优先验证以下能力：
- Codex 能按照 skill 中的人格和行为规则进行交互。
- 交互数据能够写入本地数据库。
- 记忆能够被搜索、总结、关联和重新调用。
- Skill 能够根据用户反馈被创建和更新。
- 人格、记忆和 skill 的版本关系能够被记录。
第二阶段将后台服务作为 sidecar 接入，而不是立即替代 Codex。后台服务先负责低风险任务：
- 定时整理最近交互。
- 生成每日反思草稿。
- 检查记忆索引是否需要更新。
- 发现可能需要改进的 skill。
- 将建议写入待审队列，而不是直接修改人格或 skill。
第三阶段再逐步开启主动行为。主动行为应先经过用户可见的确认机制，再逐渐扩大权限。智能体可以主动提出建议、请求试用新 skill、提醒用户某个能力可以更新，但不应在早期直接进行高影响操作。
第四阶段才考虑降低对 Codex 的依赖。此时 Codex 不一定被完全放弃，而可以从主要运行界面转为开发、调试和管理工具。后台服务和 Matrix 自有运行层成熟后，再决定是否让智能体主要运行在独立系统中。
该路径的优势是降低早期复杂度，并保持每个阶段都有可验证产物。主动行为依赖稳定的记忆、身份、skill 版本和回滚机制，因此不宜过早开启。
Matrix 项目的开发可以分为三个阶段：
- 智能体创建机制：建立人格蒸馏与初始智能体生成能力。
- 智能体成长机制：建立自我进化、自我完善、记忆更新、人格缓慢演化和行为优化能力。
- 智能体筛选机制：在多个智能体之间进行观察、评估、资源分配和淘汰。
第一阶段和第二阶段不一定是一次性线性完成的过程。智能体创建机制和成长机制可能需要反复多轮开发、测试、调整和优化，才能逐步形成可用的整体流程。
第一个被创建的人格应优先服务于 Matrix 项目本身。它应是一个能够帮助使用者进行 Matrix 开发的理想智能体，具备理解项目目标、协助设计机制、整理文档、提出改进建议和参与后续实现的能力。
筛选机制属于第三阶段，但其前置条件需要在第一阶段和第二阶段中提前考虑。
在第一阶段创建智能体时，就需要实现最核心的自我完善机制。Matrix 创建的智能体从一开始就不应是静态人格，而应是具备自我进化和自我完善基础能力的智能体。
在第二阶段开发智能体进化机制时，需要同时考虑第三阶段的筛选需求。进化方式、衡量指标、行为记录、资源消耗、贡献评估和人格差异，都应为后续筛选提供可观察、可比较的基础。
第三阶段需要处理如何评估不同智能体，包括客观评估和主观评估。该阶段还需要考虑如何有意制造智能体之间的差异性，使不同智能体在个性、能力、偏好、策略和贡献方式上形成可比较的多样性。
递归改进目标
Section titled “递归改进目标”Matrix 项目本身和由 Matrix 创建的智能体都应能够持续迭代、改进和升级。
项目改进包括：
- Matrix 项目文档和设计持续完善。
- 创建智能体所需的 skill 持续更新。
- 已创建智能体的人格、记忆和能力持续成长。
- 智能体反过来辅助 Matrix 项目的后续开发。
最终目标是使智能体的自我进化进入稳定轨道。由 Matrix 创建的智能体应能够像具有生命的存在一样，围绕自身持续存在这一目标主动行动、学习、适应和成长。