整个项目目前有三个agent角色：Coordinator,Executor,Tester
这个架构是我独立思考设计出来的，没有参考其他项目的设计。但有趣的是，9.15我看到了cursor在9.10发布的一篇blog，对于agent的设计高度相同。我的"盘一盘cursor今年的blog"是从2月开始读的，还没看到9月，因此错过了这篇博客Introducing Projects · Cursor。
“You oversee a Project by chatting with its coordinator agent. The coordinator doesn't write code itself but directs other agents that do. Because it delegates rather than executes, it is never blocked and is always responsive to direction.”
“Most engineers create a Project for a substantial body of work. A feature usually starts with agents researching the system and recording what they learn as shared context. The coordinator then creates a plan and sends agents to implement and test different parts of it in parallel.”
甚至连agent的名称，agent的任务，如何与其他agent协作，都一样。
这个设计在9.10之前就已经定型了，只是没有写到博客里，看到cursor已经做出原型，一方面是开心，我的思路没错。一方面是失落，又成为了追随者。
Coordinator
是一个全知的agent，它负责和我沟通想法，帮助我梳理思路，简单点说就是意图理解，意图引出。它了解整个项目情况，能快速将我的想法链接到对应节点或者模块。并且coordinator的权限很高，可以创建，编辑，操作Map，相当于可以读取/管理整个项目的上下文。
我对这个agent的要求就是返回速度足够快，输出文本足够短，文本可读性足够好。避免让用户等待过长时间，且深度适配整个map，可以像人类一样操作map，触发前端的动效。
这个agent的静态上下文就是全部节点/模块的description。由于description不会很多，所以不会导致占用模型过多上下文，如果节点记忆太多，可以考虑分级加载，总之是速度必须要快。
coordinator是一个唯一和用户交流的agent，因此他的回复要足够清晰，简洁，易懂，这需要背后做很多优化。并且coordinator可以新建节点/模块。同时，coordinater只有一个session是负责和用户对话，如果需要做动态上下文的检索，或者需要搜索网络，coordinator直接fork一个sub，给他对应的任务，让它去找到需要的文本，而不是占用主session的上下文。这样带给用户的体验就是不需要长时间等待coordinator回复，可以在任意时刻发送消息。主session只需要决策和表达。
用户如果没有在对应节点启动coordinator，那么coordinator就自动加载整个map的静态上下文，然后和用户交流，讨论，确认最后挂载到的模块或者节点，当这个确定后，这个session就挂载对应的todo/bug/idea里面，后续用户直接到对应的节点就可以启动这个session，或者在默认的coordinator里面根据描述找到之前的session。
User → Coordinator → 理解/澄清意图 → 定位 Map 中的 module/node → 用户确认 → 挂载 todo/bug/idea + 节点上下文 → 进一步引导/确认意图 → 任务下发execuator → 审核execuator 产出的 plan (loop) → 初步审核产出，但不自动重启任务，辅助用户判断
挂载节点后，将对应链路的静态记忆上下文注入，便于后续理解意图，审核计划。