📌 项目地址：cft0808/edict | ⭐ 15,913 颗星 | 🔧 Python | 📜 MIT
上个月我评审一份供应链协议，用CrewAI跑了三个Agent。结果出来，付款条款里“违约责任”没了。我又试了AutoGen，加了个人工审核节点，但忙起来忘看，系统自动通过了。问题不在LLM本身，在于Agent之间没有互相制约的强制检查——就像写代码没有lint和单元测试，写完直接上线。
然后我看到了edict（GitHub 15,913个星），一个用唐朝三省六部制度重构的多Agent协作框架。它的README里写了一段话我印象深刻：“每个旨意必须经过门下省审核，不可跳过。” 我决定拿它跑个真实任务，验证这个强制审核到底管不管用。
强制审核：门下省不是装饰性功能
edict的架构是定死的：用户下旨→太子分拣（闲聊自动回复，正式任务才建）→中书省规划→门下省审议→尚书省派发→六部（户、礼、兵、刑、工、吏）+ 早朝官并行执行 → 回奏。每个角色有独立的workspace和skills，模型可以单独配置。
最关键的差异是门下省。CrewAI也可以加一个reviewer Agent，但它没特权；edict的流转路径在kanban_update.py里用状态机强制固定了——只有门下省审核通过，状态才能从“门下审议”变成“尚书派发”。用户没有“跳过”选项。
我用Docker启动：
docker run -p 7891:7891 cft0808/edict看板跑在localhost:7891，内置了模拟数据，30秒走完全流程。然后我做了一个破坏性测试：在中书省规划阶段，我故意让它生成一个缺少“风险评估”步骤的方案。任务流转到门下省，看板上任务卡片的状态立刻变成“封驳”，门下省回复：“方案中未包含风险评估章节，建议补充后再提交。” 我点卡片详情，完整流转链显示：门下省在11:23:45收到，11:23:50给出审核结论。没有模糊的警告，就是直接打回。而且我试图点“恢复”或“强行流转”，界面没有提供这种操作——因为状态机不允许。
相比之下，CrewAI执行同一个任务，我同样让规划Agent漏掉关键步骤，系统直接提交给了执行Agent，没有任何中间检查。后面的输出自然也是错的。
可观测性：从黑盒到玻璃盒
edict的“军机处看板”有10个面板。我用得最多的是三个。
旨意看板：任务按状态列排列（待处理、执行中、封驳、完成等）。每个Agent头部有心跳徽章——🟢活跃、🟡停滞、🔴告警。测试时户部Agent卡在“执行中”超过3分钟，心跳变黄。点开任务详情看到完整流转链：每一步谁处理、耗时、输出内容。CrewAI的verbose=True日志也能看到，但那是连续文本流，远不如看板一眼定位。
省部调度：一张页面展示各状态任务数量、部门分布横向条形图、Agent健康卡片。我发现兵部堆积了5个任务，点进去看到兵部Agent配置的LLM响应慢。直接在“模型配置”面板把兵部的模型从GPT-4换成Claude 3 Haiku，点击“应用”后大约5秒，系统自动重启Gateway，兵部响应恢复。换模型不用改代码重启进程，对于频繁测试不同LLM的场景很方便。
奏折阁：已完成任务自动归档为奏折，记录完整五阶段时间线：圣旨→中书→门下→六部→回奏。支持一键复制为Markdown。复盘时，我发现门下省漏审了一个条件——但奏折记录了门下省输出的原文，里面有“方案包含需外部数据但未注明数据源”，直接定位到问题。没有奏折归档，你只能翻控制台日志，而日志里夹杂着其他无关消息。
热切换和技能管理：不是花哨，是真用得上
另外两个面板虽小但有用。模型配置可以让每个Agent独立选择LLM，应用后生效。技能配置可以查看各省部已安装的skills，并添加新技能。我试过给工部添加一个“PDF解析”技能，在技能面板上传zip包，没重启服务就生效了。因为每个Agent有自己的skills目录，看板API调用后动态加载。
运行成本：12个Agent不是免费的
12个Agent同时跑（11个业务角色+1个早朝官），每个独立workspace、独立skills、独立模型。我跑一个中等复杂度任务（生成一份技术方案），调用GPT-4共12次（12个Agent各一次），总token约4500。加上看板Web服务的内存占用，大约2-3GB。这不是低配机器能跑的。简单任务比如发天气播报，完全没必要开edict。
不过edict在README里也说了，可以用Docker运行预置Demo，不需要API Key。先看Demo再决定是否部署，这条对评估者友好。
适用场景与限制
适合：对产出质量有强制要求、需要完整审计链的复杂任务。合同条款审核、技术方案评审、合规检查——门下省的强制审核能减少人工复核的工作量。我测试生成合规合同时，门下省发现缺少“不可抗力”条款直接打回，后续结果质量稳定，不用逐条核对。
不适合：简单任务或低风险场景。12个Agent开销大，不会比直接调用LLM快。还有一个限制：edict的流转路径固定，不支持动态Agent组。如果你需要完全自由的多Agent对话协作（比如AutoGen的GroupChat），edict不够灵活。它的强项是制度性流程，不是自组织网络。
对比其他框架
| 维度 | CrewAI | AutoGen | MetaGPT | edict |
|---|---|---|---|---|
| 审核机制 | 无 | 可选Human-in-loop | 可选review | 门下省强制审核·可封驳 |
| 实时看板 | 无 | 无 | 无 | 军机处10面板 |
| 任务干预 | 无 | 无 | 无 | 叫停/取消/恢复 |
| 流转审计 | 日志 | 日志 | 日志 | 奏折归档（完整时间线+输出） |
| Agent健康监控 | 无 | 无 | 无 | 心跳徽章+活跃度检测 |
| 热切换模型 | 无 | 无 | 无 | 看板内一键切换，5秒生效 |
| 部署难度 | 中 | 中 | 高 | 低·Docker一行 |
edict最有价值的地方在于：它把软件工程里的“可信编译”思想搬到了多Agent协作——不是让Agent自由发挥，而是给它们套上制度框架，每一步有据可查。1300年前的制度设计，刚好解决2025年AI框架最头疼的不可控问题。
如果你想30秒看效果：
docker run -p 7891:7891 cft0808/edict不需要API Key。启动后访问localhost:7891，内置模拟数据，走一遍全流程再说。