如果能看到这篇文档的话，说明我的博客架构，是可靠的。
从4月底实习到现在，我做了许多有意思的项目，其中一个就包括重构我的博客。但有意思的是，我只有几篇博客是在这个平台上完成的。原因是对我来说，写一篇博客需要耗费大量时间，我不希望花费的时间产生的收益为0，也就是我的文本没有被正确保存。因此我只会选择在飞书文档，或者本地typora中记录。建立一个自动保存的博客，建立一个后端数据库，对今天的ai来说太简单了，可是我还是无法相信它。因此前几个月我就在想，vibe coding这个形式应该要终结了，真正的开发不应该只是一个demo。
因此我开始探索如何更好的使用agent，此时我还未设计测试架构，而是关注context。关于context的重要性，不必多说，但是如何管理一个项目的context，并且如何让人与agent的协作更好，还是一个待探索的问题。
当时我建立了context-guard 1.0。这个项目的设计很简单，记录用户的所有query，如果用户的query是一个超长的文本，则记录摘要。记录agent的回复，同query的设计。同时，我做了一个针对bug的设计。在开发的过程中，agent难免会产出一些bug，或者说产出与用户意图差距很大。并且这个bug很可能不止出现一次，那么当这个bug第二次出现的时候，agent应该自主修复，而不是人类检查后提醒他。
所以当时我的设计是每次遇到bug都要总结经验。首先是从用户的query中判断，当前内容是否是一个bug的描述，如果是，那么在修复完成后要记录修复的经验，不管这个bug是修好还是没修好，都需要总结经验，便于下次遇到后能快速修复。并且这些内容都是有时间标签，让agent有一个事件先后的概念。显然，这里最重要的环节是测试，但由于我当时的水平不够，我的agent不能写出很稳定的测试。
当时，我设计了一个测试的工作台，agent工作结束后自动触发测试的工作台，但这样的效果很差。原因在于，我不知道如何去设计一个测试。但是这个skill在整个开发过程中，确实能够很好维护项目context，我可以看到agent在用这个skill去查询结果，查询bug。
但是在项目较多，项目复杂度高的工作环境下，任务完成的好坏其实不在于agent，而在于人的思维切换。这个也不需要赘述，所以我开始思考，什么样的人机协作，能让我快速切换不同的任务，并且能快速沉浸到下一个任务中去。还有就是在项目较复杂的情况中，什么样的形式能够帮我快速理清思路。
我想到了思维导图。
去年我vibe过一个思维导图软件，当时使用的是replit+cursor。软件大体功能非常完备，我也用它画了一个思维导图，帮助我复习基础物理考试。
但那次考试，我的分数很低。
因为我忘记了一个公式，即使那个公式我记录到了思维导图。
而且思维导图最致命的点在于，对于观看者来说非常清晰，但是对于制作者来说非常浪费时间。而我当时花费了大量的时间来画这个导图，即使我的软件操作非常简单，但是里面的节点设计，里面的公式文本，都需要自己总结。
而思维导图对我来说，并不适合记忆。
从那之后，我再也没用过这款软件，再也没有更新过。
而一年后，我在选择项目的梳理形式中，又回到了思维导图，只是这次的形式不太一样。
context-guard 2.0 ，是一个“节点 + 模块”的设计。
具体工作台的功能与设计，我会在其他文章中说明，而现在我们聊聊为什么要这样设计。
第一，这样的形式能让我的思路非常清晰。
每一个模块的名称都是我设计的，因此我对整个项目的核心部分，分支部分都非常了解，我可以通过map梳理我的思路，梳理开发的方向。我也可以快速的梳理当前的开发进度，知道还需要完善哪些部分。最重要的是，这种形式消除了我的脑雾，让我对总体的架构认知非常清晰，以至于我可以快速的向别人介绍这个项目的技术细节是什么。
第二，这是一种agent的记忆管理方式。
在一个较为复杂的项目中，如何管理项目的context极为重要，当你用一个session干很多任务的时候，整体的效率往往不高。agent很久之前做过事件A，但是由于后续的任务和A关联极小，在不断的compact过程中，事件A的信息将会成为几句话。当agent再次遇到这个事件时，将无法获取任何有效信息，还需要从头开始探索。显然这样会浪费大量资源。当然你会想到，为什么不把每一个事件都完整的记录下来呢？这是一个非常有意思的问题，但是这就要归属于我的另一个还在开发的项目，暂未公开。但是可以确定的是，不是所有的事件都值得完整记录的。
你会发现，我上述的过程是多个事件发生在一个session里。这显然不是一个优雅的context管理方法，但是这确实是真实的工作环境。在一个项目中，你给ai的context在单个session里，想要新开一个session你又需要完整的描述。除非你有一套自己的context管理skill，将每一个session用到的context都记录下来。但是sessionA的context我只有一部分能用上，可能是开始阶段介绍背景的context，随后这两个session就做不同的任务。
嗯，聪明的你会想到，codex，cursor，claude code不是都支持这种方式吗？
你说的这些难点，我点击这个分支就能继续开发了呀，有什么难度。
如果不刻意管理上下文，你很难说你的session在分支前就有你所有想要的context。很可能你的session是abcdefg，但你只需要abf，那么请告诉我，此时你要怎么提取出你想要的context?
那问题来了，context要如何设计，才能实现context 复利，也就是说让你做过的事情都沉淀为经验，并且你能快速让agent找到这部分经验。
我使用“树”的思路，在节点上封装了一层模块，不仅对人来说更容易理解，分类，对agent来说也能将注意力集中在单个模块的开发。并且这样也利于后续的测试。每一个节点/模块都有：
- 记忆：由agent自动总结生成，也可以人类写入，更多的是一些规范，要求，说明等。
- idea：人类的想法，随手记录，但不触发工作。
- todo：由想法转为行动，列下todo，agent自动执行
- bug：agent 产生的错误/与人类意图未对齐的部分。描述bug，agent自动执行
整体的map设计非常简单，但是想要充分发挥他的作用，对我来说还是很困难，因为要亲自设计context的存储。具体细节本文不会赘述。
聪明的你又会想到，直接用llm wiki不就行了，为啥还设计个map，这不是增加复杂度吗？
这个问题我有初步的答案，但是还需要思考，因此这里先不做回复，这确实是个好问题。
第三，利于复杂项目的开发，测试，验收。
由于模块的设计，在开发前就已经划分好了粒度，使得agent在工作时能聚焦于当前模块，以及和当前模块产生关系的模块。不需要人类去让他寻找需要的上下文，整个架构一开始就具有上下文结构，你只需要和ai讨论，描述清楚需求，将bug/todo挂载到节点，就能启动开发。并且这种设计结构也利于测试。单元测试，模块间的测试都非常清晰。具体的工作流程将会在后文表述。
这个形式可能还有很多优点，但目前我先写这三点。
显然，如果你想对自己的项目有一个清晰的了解，你需要自己去建立模块，建立节点。如果你想要解放自己的大脑，让ai去自动生成模块，自动组织模块和节点，我也实现了，但是你需要去自己理解ai的设计，这并不是一种很好的开发方式。但是只要你搭建好项目的初始框架，后续用ai生成子模块，子节点，也能实现非常好的效果，这也是我目前尝试的开发方式。
显然，我真正想要的效果并不是人类去挂载节点，而是有一个主agent去做意图理解，去做节点的挂载，由此引出我对整个架构的agent设计。
整体的结构很简单。当架构搭建好后，从用户的视角来看，用户只需要在最开始和主agent沟通清楚需求，然后审核一遍主agent的挂载的节点以及生成的摘要，在最后审核agent完成的结果，就足够了。这确实是所有agent架构开发者想要实现的目的，而我的设计也比较简单。由于模型能力越来越强，在执行阶段不需要用户干预，就能很好的执行任务，只要任务是清晰的，context是充分的。
但简单的架构背后有非常复杂的设计，想要这个系统足够稳健，细节的设计非常多。由于我个人有多种订阅套餐，且我在服务器，在电脑有不同的agent，不同的工作环境，因此我为context guard设计了cloud：云端同步。用一个服务器链接所有的agent，不需要这些agent使用同一套harness，同一个模型供应商，因为这个map的context存储是通用的，单个项目的开发/测试规范是通用的，因此可以使用不同的模型做不同的工作。一个套餐的资源枯竭了可以无缝替换别的套餐，context是在map中，而不是在供应商的session中。
但显然，cloud的context和本地的context设计也是不同，具体的细节将会在新的文章中提到。简单来说就是执行agent的context管理与总体项目的context管理有较大差异，执行的context关注的是当前任务，而cloud的context是全局项目，执行agent可以查询总体context，但不能在执行过程中改写总体context。当流程结束后，再总结，合入总体context。这个设计也比较简单，但想要做好依然需要详细的规范文档。
并且这个项目要做到ai native，也就是你可以在任何agent 平台接入各个环节的agent。你可以和你的grok bot讨论想法，直接让他去作为主agent，去路由节点等等，不需要手搓agent架构，随时用性价比最高的模型平台。
可是，这个项目给谁用？
显然，这不是我想要的最终形态，但这是一套自动化流程的基础，未来我想做的是基于这个的context管理，也就是企业中人与agent，人与人的context管理。这是非常非常困难且复杂的，很可能我的设计只是最终形态的很小一部分，但是最基础，最关键的一部分。
cursor最近也在不断更新，不断探索automation，那做这个有啥用，能比cursor更好用？
先进的公司，如anthropic，openai，已经有一套基于slack的非常复杂的企业context组织架构。但显然，世界上并不只有cursor,openai,anthropic。更小/更大的公司仍然在开发自己的自动化流程，在头疼人与人之间的context传递，在不断探索更高效的工作方式。