特工指挥中心需要一个事实来源
代理指挥中心需要一个单一、持久的状态层来执行任务和可见性。 UI是仪表板;它读写的层是基材。
要点
- 个人人工智能代理的构建者需要一个单一、持久的状态层来执行任务和可见性;通用板和原始原木不适合。
- “命令中心”(声明、执行、审查、迭代)是 UI;它读取和写入的底层是数据层。
- Neotoma 提供类型化实体、观察和具有幂等性和确定性 ID 的 MCP 访问,因此完成是明确的并且任务不会重新执行。
- 多层记忆(工作、每周、语义、自我完善)位于真理层之上; Neotoma 是这些层消耗和更新的持久存储。
- 将 Neotoma 定位为代理仪表板和指挥中心的后端,为构建者提供了一个基础,而不是滚动自己的 SQLite 和同步。

Pawel Jozefiak 最近写了一篇关于运行个人人工智能代理的文章 以及他构建的用于管理它的工具。他从 Notion 转向 Obsidian,再到由 SQLite 支持的自定义开发板,然后转向具有焦点模式和菜单栏可见性的本机 SwiftUI 应用程序。
他遇到的关键错误是任务重新执行,因为没有可靠地记录完成情况。他最终得到了一个六层记忆系统(工作记忆、每周滚动、永久索引、深度档案、语义搜索、自我完善管道)和一个清晰的结论。通用任务工具和完整代理 IDE 之间存在差距。缺少的是代理生命周期的“指挥中心”:声明、执行、审查、迭代,具有实时可见性。
我正在构建 Neotoma,一个代理记忆的真相层。它不构建仪表板或代理。它提供了指挥中心将使用的层。
他描述的差距
Jozefiak 的选项要么太通用(Trello、Linear),要么太技术性(终端、JSON)。通用委员会不了解代理状态。谁主张什么?代理正在工作还是正在等待审核?如何记录完成情况,以便代理不会运行同一任务两次?原始日志和 JSON 根本不会为您提供面板。
他需要介于两者之间的东西:代理和人类共享任务状态的单一位置,具有清晰的声明、完成和状态语义,并且速度足够快,以便轮询或实时更新不会失败。这个“单一地点”是一个数据问题。指挥中心是UI。它读取和写入的东西是基材。
真相层提供什么
Neotoma 存储类型化的实体、观察结果和关系。它通过 MCP 公开它们,以便任何代理(Claude Code、Cursor、计划运行程序)都可以存储和更正状态。内置幂等性和确定性 ID。
当代理声明任务时,它会存储或更正状态为“正在进行”的实体。完成后,它会再次更正状态为“完成”。相同的幂等性密钥,每次都有相同的结果。 Jozefiak 遇到的错误(未记录完成,任务重新执行)正是幂等、持久写入要防止的。
想要显示“代理正在做什么”的仪表板或本机应用程序将查询同一商店:按类型(例如任务)列出实体,按状态过滤,显示受让人和时间戳。代理和仪表板共享同一个事实来源。没有自定义 SQLite,没有可能漂移的同步层。仪表板是 Neotoma 的视图。
六层内存适合的地方
Jozefiak 的六层(工作记忆、每周滚动、永久索引、深度档案、语义搜索、自我改进)是策略层和应用层的关注点。他们决定保留什么、压缩什么、总结什么以及将什么反馈到代理的行为中。
Neotoma 不进行压缩或汇总。它是这些层读取和写入的持久、结构化存储。工作记忆可能是“最后 N 个观察结果”或“过去 48 小时内接触过的实体”。每周滚动可能会将新的观察结果(摘要、索引)写回 Neotoma。语义搜索可能会在同一个实体图上运行。边界清晰:Neotoma 是真相层;它上面的层实施保留策略和检索策略。
为什么这对构建者很重要
如果您正在构建个人代理并且需要任务状态、状态跟踪和可见性,那么您有两条路径。您可以滚动自己的存储(SQLite、文件、自定义 API),然后在顶部构建面板或仪表板。您将自己遇到完成语义、幂等性和跨会话一致性。或者,您可以使用已经为您提供实体、观察结果、出处和 MCP 访问权限的基质。指挥中心成为该底层的客户端。代理人是另一个客户。读和写状态相同。
我不是在建造指挥中心。我正在构建它所在的层。 Neotoma 是代理仪表板和生命周期工具的数据平面。如果 Jozefiak 所描述的空白被产品(WizBoard 风格或其他形式)填补,那么这些产品将需要一个后端。真相层就是那个后端。
这如何符合我所押注的趋势
在我最近写的六个代理趋势中,我认为代理将成为有状态的经济参与者,错误将在经济上变得可见,工具碎片化将持续存在,并且使用将被计量。约泽菲亚克所遇到的指挥中心缺口正是这些压力的交叉点。
当代理有状态且长时间运行时,您需要查看它们在做什么。趋势一:“产品界面将代理历史记录公开为可检查的而非短暂的”,这正是指挥中心的本质。当错误导致金钱或声誉损失时,您需要了解代理人当时所知道的情况。趋势二:可追溯性和“代理人知道什么?”使任务和状态的单一事实来源成为必要的,但拥有它并不好。
当您使用多个工具和模型时,请状态片段。趋势5:指挥中心和代理都需要读取和写入相同的状态,这就是为什么基板必须位于UI下方。当使用量被定价时,由于未记录完成情况而重新执行相同的任务是明显的浪费。趋势六:幂等、持久完成既是一种优化,也是一种正确性保证。
我在自己的代理工作流程中对 Neotoma 进行了测试,并记录了“代理任务生命周期”模式:存储任务实体,使用状态和历史记录的观察,通过 MCP 使用幂等键正确更新,以便完成是明确的。该模式将为命令中心视图(声明、执行、审查、迭代)提供支持,而无需每个构建者重新发明自己的 SQLite 和同步逻辑。我还在描述 Neotoma 的方式中添加了“代理仪表板/命令中心后端”,以便其他想要构建此类工具的人知道他们可以在其上构建基础。