我为什么开始给自己做一个“自进化个人 Agent”
我真正缺的不是更强的模型，而是一条连续的个人工作链：上层由 Codex、Claude Code、openclaw 承接日常工作，下层由 EvoMap 里的 Evolver 负责 skill 迭代，中间再由我自己的工作系统把项目脉络、资源、经验和公开表达接起来。
最近我逐渐确认，我的问题不在于还没找到最强的 Agent，而在于我的工作已经天然分层。
最上面，是我每天直接使用的工具层：Codex、Claude Code 和 openclaw。
再往下一层，才是 EvoMap。更准确地说，是 EvoMap 里的 Evolver。它不直接参与我当天的代码实现或信息查询，而是负责 skill 迭代、经验沉淀和能力外循环。
所以我面对的真实问题不是工具能力不足，而是：日常工作层与能力演化层之间，还缺一条稳定、连续、可回溯的个人工作链。
这个缺口带来的结果很直接。即使同一个项目一直在推进，我仍然需要反复补背景、补状态、补判断，最后把时间消耗在重新理解自己已经做过什么。
因此，我想做的并不是再找一个更强的 Agent，而是建立一套能把这些工具和底层演化能力接起来、并持续沉淀过程的个人工作系统。
先把结构分清：使用层在上，演化层在下#
如果只看使用层，我每天主要在两类场景之间切换：
- 在电脑前：写代码、改页面、调接口、验证结果
- 不在电脑前：查资料、补信息、记录下一步、保留临时判断
但再往下拆，我必须把 EvoMap 单独拿出来看。
因为它不是一个和 Codex、Claude Code、openclaw 并排的日常工具。我更愿意把它定义为更底层的能力基础设施：通过 Evolver 判断哪些方法值得沉淀，哪些 skill 值得继续演化。
如果把这个问题压缩成一句话：
我缺的不是更强的模型能力，而是连续的个人工作链。
核心问题不是能力不足，而是工作链会断#
只要跨工具、跨场景、跨时间推进，断点就会出现：
- Codex 里的实现判断，不会自然进入下一次讨论
- Claude Code 里的攻坚思路，跨天之后往往只剩结论
- openclaw 记录下来的查询结果，未必能回流到项目主线
- skill 在变化，但有效方法缺少稳定的迭代机制
- 服务器、账号、路径、部署方式这类资源信息，会持续被使用，却长期散落在各处
这些都不是执行问题，而是连续性问题。
把问题拆开后，只剩四类#
我后来不再问“要不要做一个大系统”，而是先问：反复出现的问题到底是什么。
拆开之后，我看到的其实只有四类：
- 多 Agent 协同问题：同一个项目在多个工具之间推进，如何保持连续
- 持续记忆问题：状态、判断、阻塞和下一步，如何在回看时仍然清晰
- skill 迭代问题：哪些 workflow 真正有效，如何通过更下一层的 Evolver 累积下来
- 对外表达问题：哪些内部过程值得被提炼为公开内容
所以，我不想再做一个传统项目管理工具#
我不想再回到这条熟悉但低效的路径：
- 再开一套任务系统
- 再建一套卡片结构
- 再手工维护状态
- 再把真实发生过的过程翻译成另一套表述
这套方法并非无效，只是不适合我当前的工作形态。
我的判断是：工作应该先真实发生，项目脉络应该从真实工作里自然长出；skill 应该先在底层持续迭代，再决定哪些结果值得进入公开层。
如果要给这套系统一个清晰定义，我更愿意把它看成五层：
- Codex / Claude Code / openclaw：我每天直接切换的日常工具层
- EvoMap / Evolver：负责 skill 迭代和经验沉淀的能力进化底层
- evomap-farmer：连接使用层与演化层的私有工作组织层
- AiTool-content：面向公开表达的内容草稿层
- AiTool：最终面向外部的公开呈现层
产品日记不是附属产物，而是系统的一部分#
如果这套系统只解决本地连续性，它最多只是一个更好用的个人工作台。
我真正想做的，是把内部过程逐步提炼成公开表达，再让这些表达反过来约束下一轮工作。
所以，产品日记不是收尾动作，而是这条链里的反馈层：
- 它逼我把阶段判断说清楚，而不是停留在“我大概知道”
- 它把一轮工作的路径、结果和未决问题压缩成可回看的记录
- 它会暴露论证里仍然含混的部分，逼我回到系统里继续修正
- 它也会成为下一轮产品决策和 skill 迭代的输入
回到 evomap-farmer：它应该承担的是组织层#
现阶段的 evomap-farmer 已经具备可用性，但它更接近一个把多类能力摆在一起的工作台，还不是一套围绕工作对象收束过的信息架构。
现在左侧大致是这些栏目：
- 统一工作台
- Credit 总览
- 执行草稿箱
- 进化链路
- 悬赏任务
- 学习资产
- 服务市场
- 官方底层
- 账本
问题不在于这些栏目是否成立，而在于它们更多按实现来源和系统能力展开，还没有完全转成“我到底围绕什么对象持续工作”。
我当前的判断如下：
| 当前模块 | 现在的价值 | 主要问题 | 更合适的位置 |
|---|---|---|---|
| 统一工作台 | 已经把主要信息放到一页，方向正确 | 仍然偏结果混排，不够对象化 | 保留为默认首页 |
| Credit 总览 | 方便看节点和积分 | 对个人 Agent 主线来说过重 | 收成系统状态区 |
| 执行草稿箱 | 适合承接 adapter pipeline | 名称偏技术，不够自然 | 并入“发布 / 执行中心” |
| 进化链路 | 适合查看证据和 skill 演化 | 目前更像后台控制台 | 保留，但明确为“技能进化” |
| 学习资产 / 服务市场 / 官方底层 | 跟 EvoMap 生态强相关 | 更像系统功能，不像工作对象 | 下沉为二级导航 |
| 账本 | 对审计和消费有价值 | 不该成为主入口之一 | 收进系统层或折叠层 |
如果只从后续演进看，我希望它最终不是围绕“页面名”扩张，而是围绕对象扩张。
下一步先定义信息架构，而不是继续扩功能#
我现在的判断很明确：优先级最高的不是技术拆分，而是先定义我每天究竟围绕哪些对象工作。
第一层：导航应该围绕工作对象，而不是功能来源#
我希望后续左侧目录逐步收成下面这个顺序：
- 工作台
- 今日收件箱
- 项目脉络
- 资源库
- 技能进化
- 对外发布
- 执行中心
- 系统账本
这八项分别对应：
- 工作台：负责总览和例外，不承载全部细节
- 今日收件箱：承接当天新增线索、待确认项和上下文提示
- 项目脉络：承接跨天推进的主题、阶段判断和下一步
- 资源库：承接服务器、工具、路径、外部资料等可复用信息
- 技能进化：承接 skill、workflow 和经验复盘
- 对外发布：承接产品日记、公开稿和草稿出口
- 执行中心：承接悬赏、Runner 和执行链路
- 系统账本：承接节点、积分和执行审计
这套结构对应的是我的工作对象，而不是系统功能列表。
第二层：先立住工作对象，再决定技术模块#
如果这套系统继续扩展，我有几个非常明确的原则：
- 不先问还能增加什么功能，而先问我每天到底在处理什么
- 不把一切都压成任务，因为很多内容本质上只是线索、证据、判断和资源
- 不为了管理而管理，而是让真实工作自然沉淀为可回看的脉络
- 不轻易删除过程，因为旧判断本身就是以后理解自己的依据
因此，在我心里，这套系统最核心的对象更接近下面这些：
- 工作证据：这一天真实发生过什么
- 今日线索：哪些值得继续跟进，哪些只需要暂时保留
- 项目脉络：一个主题当前走到哪里，下一步应该朝哪里推进
- 资源引用：服务器、工具、账号、资料这类会被反复调用的信息
- 技能经验：哪些方法真正有效，哪些只是偶然成功
- 公开草稿：哪些内部过程值得整理成对外可读的内容
- 执行记录：哪些尝试已经发生，成本和结果分别是什么
对我来说，这些对象最重要的不是技术意义上的操作完整性，而是它们是否被正确组织。
很多内容并不适合直接删除，而更适合归档、折叠或抑制。因为这套系统不是普通后台，它更像一套长期工作痕迹。如果痕迹被清理得过于干净，后面就很难解释当时为什么会形成那个判断。
如果只能优先做一个核心页面，我会先做“项目脉络详情页”。因为它最能代表这套系统的核心：不是看一串任务，而是看一个主题如何由线索、判断、资源和输出逐步展开。
下一步我会怎么推进#
如果把这篇当作第一篇产品日记，我下一步不会试图一次做完整系统，而是先打通最短闭环：
- 先把“项目脉络”这个核心对象做稳
- 让 openclaw 带回来的信息更自然地进入资源库和收件箱，而不是混进编程主链路
- 让产品日记从真实工作里自然长出草稿，同时保留人工确认
- 再把 evomap-farmer 的导航和整体结构，从页面驱动逐步收束为对象驱动
我不想再做一个传统的项目管理模块。
我想做的，是一套会随着使用逐步理解我工作方式的个人 Agent：
- 它知道我在不同场景下如何推进工作
- 它区分上下文、判断、下一步和可执行事项
- 它知道哪些经验值得进入 skill 演化
- 它知道哪些过程最终值得被公开表达
如果这条路成立，那么以后的每一篇产品日记都不只是一次发布，而会成为下一轮产品迭代的起点。