ˊ_>ˋ 整理出来了一个 Working 的多 Agent 协同工作治理架构，在 DSH 里面做的。
主要是这几点：
1. 开放 Session 管理相关能力，包括快速阅读其他 Session 的聊天记录，直接向其他 Session 发消息，直接原地开立新的 Session（这样可以断开子母 Session 关系，这点很重要，因为有的时候子母 Agent 关系会让任务管理变得没办法 Self Contained 导致协调效率低下整个开发业务流彻底混乱）。
2. 不要用 GitButler，用 jj 做多任务管理，GitBulter 不能解决编译产物混乱的问题，而且 GitButler 的实现思路非常有毒，会把你整个业务流搞得又脏又乱。
3. 把任务管理（特别是兔子洞管理）、版本管理和 Session 权限整合成一个完整的业务流程方案，确保所有 Session 的操作都是严格受控，没有逃脱窗口的。这意味着不会把 git 和 jj 暴露给 Session，任何尝试调用都会被屏蔽，只有特殊情况可以赋予完整版本管理权限，需要手动开启。
任务管理方面：
1. 一个任务的生命周期包括：声明任务、Claim 任务并执行、签核任务。声明方、Claim 方和签核方的 session id 都是被记录的。声明任务和 Claim 任务的人不能负责签核任务，Claim 过之后其他 Session 不能插手任务。
2. 不能插手这件事情靠 jj 的封装做到，Claim 之后会自动调用 jj 开 Worktree 并初始化 Nix Flake 环境，只要任务被 Claim 了，其他人就不能向这个 Worktree 做任何 commit 操作。
3. 任务完成之后调度 Session 用干净的上下文审阅工作，收集证据并签核，如果不合格就打回去继续做，如果合格，那么工作树会被自动清除，Nix Flake 的工作区副本也会被自动 gc，不需要 Agent 再行清理。
4. 一个任务描述必须包含：问题描述、任务内含、外延、非目标这几个定义，把范围全都框定清楚，现代模型都很擅长写这个任务书（除了 GLM 不会说人话写出来的狗屁玩意别的模型可能会看不懂）。
签核标准和开发流程管理是很重要的，具体而言：
1. 任务建立的时候就记录是从哪个分支创建的任务，合并的时候只能从创建分支合并保证开发分支走向严格单向（通过封装签核流程做到）。
2. 任务有树状结构，用来追踪兔子洞问题。兔子洞问题指：解决一个问题就发现新的问题，然后又发现新的问题，这就是标准的兔子洞。Agent 在解决兔子洞的时候很有可能会做了后面忘了前面，所以任务必须以树状结构存储，子任务被签核的时候会自动注入提示词，提醒解决父任务。
3. 每个任务在开启的时候都会显式指定验收标准（SOP），在签核的时候必须针对每个验收标准提供验收证据，验收证据填不满的任务不能签核。
对于多任务管理：
1. GPT Astra 不适合做协调人的角色，哪怕你给它设置了 Goal 它也不会听你的，做了几十个 Round 之后就会彻底hang 死，表现为「我虽然有事情要协调但是我每轮都说我会协调，但我就是不做」。
2. Deepseek 的 Pro 模型在协调是非常积极的，但是它不适合去实际做开放式开发（即没有明确任务边界的任务），因为你的 goal 一旦开起来之后它的开发行为就会非常激进和失控，经常会做你没有指定的事情，或者你说一个需求它理解歪了之后给你做的一去不复返。
3. GLM 模型我只建议你用它做小活和脏活，且注意，它的机械语言风格会传染，如果它写了文档写了 Memory，那么它的英翻中翻英翻中的语言风格会立刻传染所有阅读它输出信息的模型，这会极大削弱后续沟通的清晰性和明确性。
4. 不要让一个大 Session 去协调好几个小 Session，上下文压缩最多五次模型就会进入低效状态不推进了，这意味着你完全没办法做到「无人职守自动开发」。
5. 所以最好是一个三层结构，一个协调 Session 负责写任务书，只负责开新的独立任务执行 Session（注意，不是 Sub Agent，这两个东西在 Harness 里的工作方式略有不同），这个任务执行 Session 负责管理这个任务的开发，负责 Call SubAgent 做开发，Sub Agent 开发完之后调用另外一个 Sub Agent Review 和签核，执行 Session 负责处理这一个任务的协调和签核。
6. 一级协调者值负责管理并行预算（防止 429），二级协调者（任务执行 Session）负责推动单个任务的执行，三级执行者负责实际执行和开发工作。
不要尝试群聊结构：
1. 不要尝试让这些 Session 群聊，不同模型对于群聊结构的反应是不一样的。比如你开了三个并行 GPT Astra Session，一个人声称自己是任务协调者，然后让其他两个 Session 服从它的调度，其他两个任务协调者马上就会乖乖听话，明明自己在做的事情和前面那个 Session 毫无瓜葛，但是他们还是会「为了避免冲突」停下开发。另外群聊广播不可避免的会让各个Session收到垃圾消息，有的模型比较聪明会说「跟我没关系我不回复」，但是有些模型会疯狂「好的收到」，然后搞出 Session 之间的广播风暴。这侧面烘托了钉钉和飞书是有毒的氛围。
2. 为了避免这个问题，最直接的方式就是把角色层次拉开，并且 session 之间独立。这其实是没什么问题的，因为每个 Session 都在自己的 Workspace 里面开发，几个 Session 之间不会冲突（除非是一起狂暴编译把宿主的内存搞爆炸了，发生过几次），jj 的冲突解决模型非常先进，遇到冲突谁后来谁 resolve 就行了。
对于 Goal 的适应性：
1. 对于开放式研究任务，GPT 系列模型最大的毛病就是会进入牛角尖出不来，越做效率越低。
2. Deepseek 的问题是「反正我轮数还够」，就去查手别的任务，所以 Goal 里面必须把任务边界定清晰给它停止点。
3. GLM 的问题是它会瞎试，胡乱归因，你看任务发展结构就会知道，「先猜一个原因」「用这个猜的原因去修」「原来不是这个原因」「再猜一个原因」，试着试着就会因为上下文劣化失去焦点最后变成弱智，所以不要让 GLM 做复杂任务。
另外，一点对于你的心理健康的建议：
想办法隐藏 LLM 的输出，把信息层次拉开也是为了让你看不到，唰唰列出来的那些思考过程和短影音没有任何区别，它能够给你提供大量快速的正向反馈，吸引你的注意力，但不会让你理解过多知识（因为信息量非常大）。你已经把 LLM 开起来了那你的职位就变成 Manager 了，思维模型要转变，否则你很有可能会越做越累。
主要是这几点：
1. 开放 Session 管理相关能力，包括快速阅读其他 Session 的聊天记录，直接向其他 Session 发消息，直接原地开立新的 Session（这样可以断开子母 Session 关系，这点很重要，因为有的时候子母 Agent 关系会让任务管理变得没办法 Self Contained 导致协调效率低下整个开发业务流彻底混乱）。
2. 不要用 GitButler，用 jj 做多任务管理，GitBulter 不能解决编译产物混乱的问题，而且 GitButler 的实现思路非常有毒，会把你整个业务流搞得又脏又乱。
3. 把任务管理（特别是兔子洞管理）、版本管理和 Session 权限整合成一个完整的业务流程方案，确保所有 Session 的操作都是严格受控，没有逃脱窗口的。这意味着不会把 git 和 jj 暴露给 Session，任何尝试调用都会被屏蔽，只有特殊情况可以赋予完整版本管理权限，需要手动开启。
任务管理方面：
1. 一个任务的生命周期包括：声明任务、Claim 任务并执行、签核任务。声明方、Claim 方和签核方的 session id 都是被记录的。声明任务和 Claim 任务的人不能负责签核任务，Claim 过之后其他 Session 不能插手任务。
2. 不能插手这件事情靠 jj 的封装做到，Claim 之后会自动调用 jj 开 Worktree 并初始化 Nix Flake 环境，只要任务被 Claim 了，其他人就不能向这个 Worktree 做任何 commit 操作。
3. 任务完成之后调度 Session 用干净的上下文审阅工作，收集证据并签核，如果不合格就打回去继续做，如果合格，那么工作树会被自动清除，Nix Flake 的工作区副本也会被自动 gc，不需要 Agent 再行清理。
4. 一个任务描述必须包含：问题描述、任务内含、外延、非目标这几个定义，把范围全都框定清楚，现代模型都很擅长写这个任务书（除了 GLM 不会说人话写出来的狗屁玩意别的模型可能会看不懂）。
签核标准和开发流程管理是很重要的，具体而言：
1. 任务建立的时候就记录是从哪个分支创建的任务，合并的时候只能从创建分支合并保证开发分支走向严格单向（通过封装签核流程做到）。
2. 任务有树状结构，用来追踪兔子洞问题。兔子洞问题指：解决一个问题就发现新的问题，然后又发现新的问题，这就是标准的兔子洞。Agent 在解决兔子洞的时候很有可能会做了后面忘了前面，所以任务必须以树状结构存储，子任务被签核的时候会自动注入提示词，提醒解决父任务。
3. 每个任务在开启的时候都会显式指定验收标准（SOP），在签核的时候必须针对每个验收标准提供验收证据，验收证据填不满的任务不能签核。
对于多任务管理：
1. GPT Astra 不适合做协调人的角色，哪怕你给它设置了 Goal 它也不会听你的，做了几十个 Round 之后就会彻底hang 死，表现为「我虽然有事情要协调但是我每轮都说我会协调，但我就是不做」。
2. Deepseek 的 Pro 模型在协调是非常积极的，但是它不适合去实际做开放式开发（即没有明确任务边界的任务），因为你的 goal 一旦开起来之后它的开发行为就会非常激进和失控，经常会做你没有指定的事情，或者你说一个需求它理解歪了之后给你做的一去不复返。
3. GLM 模型我只建议你用它做小活和脏活，且注意，它的机械语言风格会传染，如果它写了文档写了 Memory，那么它的英翻中翻英翻中的语言风格会立刻传染所有阅读它输出信息的模型，这会极大削弱后续沟通的清晰性和明确性。
4. 不要让一个大 Session 去协调好几个小 Session，上下文压缩最多五次模型就会进入低效状态不推进了，这意味着你完全没办法做到「无人职守自动开发」。
5. 所以最好是一个三层结构，一个协调 Session 负责写任务书，只负责开新的独立任务执行 Session（注意，不是 Sub Agent，这两个东西在 Harness 里的工作方式略有不同），这个任务执行 Session 负责管理这个任务的开发，负责 Call SubAgent 做开发，Sub Agent 开发完之后调用另外一个 Sub Agent Review 和签核，执行 Session 负责处理这一个任务的协调和签核。
6. 一级协调者值负责管理并行预算（防止 429），二级协调者（任务执行 Session）负责推动单个任务的执行，三级执行者负责实际执行和开发工作。
不要尝试群聊结构：
1. 不要尝试让这些 Session 群聊，不同模型对于群聊结构的反应是不一样的。比如你开了三个并行 GPT Astra Session，一个人声称自己是任务协调者，然后让其他两个 Session 服从它的调度，其他两个任务协调者马上就会乖乖听话，明明自己在做的事情和前面那个 Session 毫无瓜葛，但是他们还是会「为了避免冲突」停下开发。另外群聊广播不可避免的会让各个Session收到垃圾消息，有的模型比较聪明会说「跟我没关系我不回复」，但是有些模型会疯狂「好的收到」，然后搞出 Session 之间的广播风暴。这侧面烘托了钉钉和飞书是有毒的氛围。
2. 为了避免这个问题，最直接的方式就是把角色层次拉开，并且 session 之间独立。这其实是没什么问题的，因为每个 Session 都在自己的 Workspace 里面开发，几个 Session 之间不会冲突（除非是一起狂暴编译把宿主的内存搞爆炸了，发生过几次），jj 的冲突解决模型非常先进，遇到冲突谁后来谁 resolve 就行了。
对于 Goal 的适应性：
1. 对于开放式研究任务，GPT 系列模型最大的毛病就是会进入牛角尖出不来，越做效率越低。
2. Deepseek 的问题是「反正我轮数还够」，就去查手别的任务，所以 Goal 里面必须把任务边界定清晰给它停止点。
3. GLM 的问题是它会瞎试，胡乱归因，你看任务发展结构就会知道，「先猜一个原因」「用这个猜的原因去修」「原来不是这个原因」「再猜一个原因」，试着试着就会因为上下文劣化失去焦点最后变成弱智，所以不要让 GLM 做复杂任务。
另外，一点对于你的心理健康的建议：
想办法隐藏 LLM 的输出，把信息层次拉开也是为了让你看不到，唰唰列出来的那些思考过程和短影音没有任何区别，它能够给你提供大量快速的正向反馈，吸引你的注意力，但不会让你理解过多知识（因为信息量非常大）。你已经把 LLM 开起来了那你的职位就变成 Manager 了，思维模型要转变，否则你很有可能会越做越累。
