最近看到 DeepSeek 的 SuperAgent，我又把我们这段时间做的东西拿出来聊了一遍。里面关于主编排、任务分工、持续运行的讨论，和我们在本地做的一些实践挺接近。
我们已经在 Codex 里用一个固定的对话作为主编排，让它接任务、拆任务，再交给其他对话去处理。围绕这套东西，我们还做了本地上下文管理和协作协议，也逐渐接入了一些事件和定时触发。
借着这次讨论，我想把这个过程复盘一下：这套东西为什么会长成现在这样，实际用起来解决了什么，又有什么问题一直留到了现在。
从本地上下文开始
今年上半年，从 OpenClaw 开始，我就在持续实践 Personal Agent。后面又用到 Hermes 等不同产品，也研究过记忆、检索，以及怎么把 Obsidian 这一类本地工具接进来。
我对上下文管理一直比较有意识。最初就是一个文件夹对应一个项目，把进度、状态和相关资料，以 Markdown 明文的方式放在本地。这样换一个对话，项目之前做过什么、现在到了哪里，还可以接着看。
当时做的项目很多是阶段性的，包括一些开源产品的探索。集中处理一段时间，告一段落，并不需要每天都很密集地往下迭代。
但我同时会用好几个 Agent。Codex、Claude、Hermes，或者其他工具，不同模型适合做不同的事情，也要考虑订阅和算力余量。同一个项目，可能今天在这里推进，明天又换到另一个工具里继续。
而且就算只用一个产品，里面也会有不同的 Session、不同的 Agent。项目的上下文要能在这些地方接得上。
我们做的 FLG，就是用来处理这件事情的。可以把它理解成一套放在本地的项目上下文记录和维护规则，让不同工具、不同对话里的 Agent，都能沿着同一份项目状态继续工作。
这里面还有一个很实际的区别：我做的很多事情是运营、营销和项目推进。它们的事实和状态变得很快，今天多了一个信息，原来的判断就可能需要调整。
所以只记录“现在准备怎么做”，对我来说还不够。我们在 FLG 里很重视决策日志，要把判断为什么成立、哪些方向已经考虑过，以及什么变化会让它需要重新讨论，一起留下来。
否则换一个 Agent，它可能会重新提出一个我们已经讨论过、也已经放弃的方案。而我们当时为什么放弃，恰好就是接下来做判断需要的上下文。
到七八月份，这套东西已经搭得差不多了。项目能在不同工具和对话之间继续往下走，但对我来说，另一个问题开始变得明显。
我需要一个固定的对话
项目做得越长，左边的对话框就越多。七八个、九个，再往上加，我开始很难分清楚重点。
上下文已经放在本地，Agent 也能帮我整理得不错，但我有时候还是不知道应该打开哪一个对话。手上这个问题要继续聊，还是单独拆出去？要拆的话，应该怎么拆？
我还得记住最近做了哪些东西，哪些已经结束，哪些值得再深入一点。对话越来越多以后，这些事情本身就开始占用精力。
八月份，我们在 Codex 里固定了一个对话作为总编排。我当时的想法很直接：对人来说，需要有一个具象的对话入口。我有事情就先到这里说，不用每次先判断自己应该去哪里。
在 OpenClaw 里，我们上半年就已经实际用过 subagent，把工作交给其他 Agent 去做。到了 Codex 这里，我们把这种分工放进了一个持续使用的项目入口里。
主编排负责接住我的自然表达，判断这件事情应该怎么处理，需要继续哪个对话，或者拉起一个新的子对话。具体工作交出去，结果再带回来。
如果是一轮就能完成的事情，做完以后可以归档，减少面板里一直堆着的对话。需要多轮跟进的时候，我也会直接切到子对话里，持续参与。子对话再把进展和结果回传给主编排。
我对这些任务会有自己的预期。它大概应该做到什么程度，需要我参与多少，回来的结果能不能验收，这些都在实际协作里慢慢确定。
FLG 也就接在这里。对话可以拆开，工具可以切换，但项目已经确认的状态和判断要继续保留。主编排负责组织眼前的工作，FLG 帮我们把后面还需要用的上下文留住。
再往后，我们又加了一些事件、Hook 和定时触发。人仍然是主要的触发者，同时也有一些工作可以在信息发生变化，或者到了某个时间之后继续跑起来。
这套东西就是在具体使用中，一点点迭代到现在的。
任务跑起来以后
所以看到 SuperAgent，我会觉得里面有不少熟悉的东西。把任务接进来、分出去，再让结果回来，这些我们已经在日常工作里用了很长一段时间。
对照具体实现，也能看到差别。DeepSeek 这个原型把任务状态、事件触发和中断后的恢复等能力放进运行系统里。我们更多是在现有 Agent 产品上，通过协议、本地记录和一些自动化，把自己的工作串起来。
这些地方当然还可以继续做得更扎实。但我实际用下来，最困扰我的问题，经常出现在人需要参与的时候。
我处理的工作里面，有复杂的项目、人际关系、资源管理，还有各种取舍。一个地方变了，其他地方可能都要跟着动。你需要不停地参与判断，决定接下来怎么做。
与此同时，Agent 可以很快拉起很多事务。这个在查资料，那个在推进方案，另一个又有了新的结果。它们都在往前走，中间还会突然进来其他事情。
到了后面，我有时候反而有点不知道自己现在在做什么，最近到底推进了哪些东西，哪一件应该再深入下去。
本来做主编排，就是想解决对话太多、不够聚焦的问题。它确实改善了入口和分工，但当同时进来的事务越来越多，人的精力和上下文切换，还是会遇到边界。
比如我正在做一个原型，需要不断探索和调试，同时又要写一份方案。光这两件事情，我就已经很难同时深入地做了。
这可能也和反馈密度有关。等待 AI 的时间比较长，中间留出的间隔比较大，我相对还能切换到另一件事情上。但如果六个、十个任务都在跑，而且不断有结果需要我看、有问题需要我判断，我就很难切换过来。
能够把流程设定好，让 AI 持续串起来做的工作，对我来说通常是相对确定的。我的工作里，还有很多东西需要随着具体情况反复调整，人要一直在里面。
有人可能会说，那就把规则设定得更清楚：出现什么条件，就做什么调整。这些工程化的处理有用，我们也一直在做。
但人参与进去以后，他能不能接住这些反馈，当时有没有精力继续想，注意力是不是已经被另一件事占用了，这些也会影响工作怎么往下走。
人会受外界很多因素影响，状态并不稳定。系统可以按设定继续运行，我未必能一直以同样的状态参与。
所以我觉得，在这套工作流里面，人有时候就是最大的卡点，甚至是在拖后腿的那一个。
广度和深度，阶段性地选一个
有了 AI，我们会觉得自己可以处理非常多的并发。但落实到一件具体的事情，在一个具体阶段，我觉得广度和深度还是只能选一个。
比如下午就要做一个重要汇报，手上的资料还不够好，临时又有信息发生变化，需要马上调整。这个时候，我大概率只会把注意力放在这一件事情上。
其他任务即使可以同时跑，也不适合继续往里面投入注意力。
这里说的是阶段性的选择。一个人当然可以在不同时间做不同的事情，也可以既有统筹能力，又能深入处理问题。但在当前这个阶段，如果我要把一件很费脑的事情想透，就得承认自己没办法同时深入另外好几件事。
记忆、看板、主动提醒，可以帮我知道事情到了哪里。真正进入一份方案，理解里面的取舍，再把它调整到自己满意的程度，还是需要投入一段比较完整的注意力。
这也让我想到工作里的另一种情况：让一个人制定验收标准，又让他负责所有具体进度。当他开始为推进负责，就有可能在过程中不自觉地降低自己的验收标准。
前者需要往深处看，后者要照顾更大的范围。如果都压在同一个人、同一个阶段里，这两件事情就会互相影响。
对我来说，主编排和这些工程化能力已经有很实际的价值。它们让不同 Agent 能接着同一个项目做，也让我不需要自己去管理所有对话的分工。
但继续设计这套工作流的时候，我还得把人的边界放进去。现在应该展开多少事情，哪一件值得深入，我自己要投入什么样的注意力，这些仍然需要判断。