现有多 Agent 框架的真实痛点
市面上多 Agent 项目不少，但真正跑起来后，问题集中在几个地方：
- 任务是谁拆的，不清楚
- 中间谁改了方案，不清楚
- 结果为什么变成这样，也不清楚
- 出了问题想回溯，几乎做不到
本质上，这些项目解决的是"让更多 Agent 一起干活"，但没人管"怎么把这件事管起来"。系统不是死在能力不够，而是死在流程混乱——谁都能插一手，最后谁都不负责。
Edict 的做法：把分工和审核写进系统流程
Edict 的架构直接对标三省六部制度，每个环节有明确的角色边界：
- 太子：负责分拣任务入口
- 中书省：拟定执行方案
- 门下省：审核方案，不合格直接打回
- 尚书省：分发到具体执行单元
- 六部：各自处理对应领域的具体事务
这里面最值得注意的设计是"门下省审核封驳"——方案不行就打回重来，不是硬着头皮往下跑。这一点把多 Agent 系统从"演示 Demo"拉回到了真实协作的逻辑里。真实团队就是这么运转的：有人提案，有人否决，反复几轮才定稿。
不止是概念，工程层也做了
Edict 没有停留在架构图上。仓库里把看板、状态流转、归档、权限、工作区这些配套设施都做进去了。也就是说，你不仅能看到任务在跑，还能追踪它跑到哪一步、谁接过手、哪里被打回。
这就和那些只是给几个 Agent 起个角色名、然后扔进一个聊天循环里的项目拉开了差距。
这个方向的判断
多 Agent 这件事，重点可能从来不是"多"。真正难的是分工、审核、追踪、收口。说直白点：不是"能不能做"的问题，而是"做出来以后谁兜底"。
Edict 提出的核心假设是：把一套经过验证的多人协作治理逻辑，移植到 Agent 系统里，稳定性会优于目前主流的扁平式多 Agent 架构。这个假设是否成立还需要更多实际场景验证，但方向值得关注——它至少在正确的层面上提问题。
对于正在搭建 Agent 工作流的开发者来说，Edict 里对流程、职责和审核机制的处理思路，比具体代码实现更有参考价值。有时候新技术做着做着，最后要补的反而是老问题：谁负责、谁审核、谁执行、谁收尾。这几件事，古人确实想得比我们早。