夜雨聆风
当前，大模型与智能体正在赋能软件开发的各个环节，大幅降低软件开发门槛。但在面对复杂的项目级开发时，“单智能体全包揽”模式短板随之凸显：需求与实现脱节、上下文对话偏移、关键决策缺乏可追溯性、测试环节被简化甚至省略。这些问题往往导致AI生成代码难以满足工程落地标准，需要人工投入大量时间反复修正。
一个深层次的命题摆在面前：如何让AI系统真正像人类研发团队一样，按照标准化分工和流程有序协作，形成架构设计、质量审查、测试驱动开发以及自动化审计的全链路能力体系？
近期，一个出自北大团队、名为枢机（ShuJi）的开源项目，给出了一条融合东方智慧的解题思路。该项目创新性地将中国古代“三省六部制”的治理逻辑，引入多智能体架构，搭建起一套多角色、可审计、文档驱动的自主开发流水线，为智能化软件开发提供了一条高度透明度、工程化的落地路径。
枢机项目地址：https://github.com/Fakerol-111/ShuJi
枢机项目作者：北京大学软件与微电子学院硕士生 张杰伦
枢机核心架构：
以“三省六部”拆解软件工程职责
枢机的设计灵感，源自中国一千多年前的三省六部制——通过明确的角色分工、层级协作与流程闭环，实现复杂软件开发的有序推进。
具体而言，系统将软件开发流程映射为9个具有明确职责边界的智能体部门，搭配作为决策主体的用户角色，完整覆盖软件开发全流程。
1、顶层决策：皇帝与内阁
皇帝（用户）：作为任务发起者与最高审批者，对任务关键节点的规划和审查文档进行审批；
内阁（需求理解）：分析理解用户需求，通过内置规则引擎匹配合适工作流，将任务下发至具体部门，相当于项目经理；
2、三省协同：方案设计与执行调度
中书令（方案设计）：聚焦整体方案设计，产出设计文档，不直接编写代码；
门下侍中（独立审查）：对方案进行合规性与合理性审查把关，行使“封驳权”；
尚书令（执行调度）：统筹具体的执行调度，将任务分派到六部实现工程落地。
3、六部落实：全栈软件工程闭环
尚书令下辖多个核心执行智能体，各自在软件开发全流程中扮演专业角色：
吏部（详细设计）：将宏观方案拆解为模块级的详细设计，明确具体研发规范；
兵部（测试与接口契约）：在编码前，编写集成测试或定义接口契约，践行测试驱动开发理念；
工部（TDD 编码）：支持批量计划循环，将大任务拆分为多批次，专职进行代码编写与自我验证；
刑部（独立测试验证）：负责全量集成测试的运行与验证，并输出质量报告；
礼部（规范检查与审计）：负责代码风格、安全规范检查，并对接审计系统。
三个关键机制，实现精细化工程管控
枢机架构设计的核心并非用AI替代开发者，而是通过三个关键机制让AI研发从“个人经验驱动”转向“标准化流程驱动”。
第一，文档即契约
各智能体部门之间统一依托带有YAML frontmatter的结构化文档进行信息交互：设计、开发、审查等各环节均以固定文档为通信依据，有效确保上下文信息不偏移、决策可追溯、历史可回看。
第二，朱批审批
方案和审查类文档产出后，需要经过用户确认方可放行。当下游智能体试图调用路由工具或追加内容时，控制引擎会自动检查相关方案的审批状态；一旦发现方案处于待审批或已驳回状态，底层将自动触发硬拦截并返回阻断原因。这意味着智能体无法把用户未确认的方案自行推进到编码阶段，实现流程的精细管控。
第三，流程自动适配
在多智能体运行中，一个常见痛点是“小题大作”——一个简单的Bug修复任务，系统却调动中书令做全套设计，白白消耗大量Token。
枢机的内阁能够基于轻量化规则引擎，根据任务复杂度自动选择工作流：修复Bug任务直达工部、刑部，开发新功能走完整的设计-审查-编码-测试链条，重构或性能优化则匹配专项流程。遇到无法准确判定的场景，系统会主动询问用户意见，而非自行猜测。
枢机如何解决真实开发场景中的深层问题？
角色分工和文档通信解决了多智能体之间“谁做什么、信息怎么传递”的问题，但真实开发中还有更多深层问题需要解决。
1、面对流程“失控”问题：以结构化引擎规范智能体工作流
在传统的智能体编排中，任务流转往往高度依赖大模型自身的逻辑推断，极易导致智能体在复杂长任务中出现跳过关键步骤、遗忘依赖关系，甚至陷入循环等问题。
枢机引入声明式工作流控制引擎，重新界定AI工作边界：由内阁先依据任务复杂度制定合理的研发计划，然后整体步骤操作、任务调度均由专属引擎驱动。各开发环节依靠有向无环图绑定依赖逻辑，系统可自动识别流程死锁。所有操作进度实时保存，支持暂停与恢复。
当遇到同工具重复调用、只读不写等异常情况时，系统不再允许智能体“自由发挥”，而是自动匹配对应的故障处理指南，注入干预提示词引导模型自我纠正。
2、针对长上下文“偏移”问题：以文档体系沉淀项目记忆
大部分多智能体项目依靠大模型对话记录传递上下文信息，对话越长、参与角色越多，关键信息越容易丢失，语义偏差问题愈发突出，项目经验也难以有效留存。
枢机用一套结构化的文档系统替代了对话传递，以此作为项目的“确定性记忆”：系统定义了需求、设计、方案、详细设计、审查、任务、契约、报告、分析、规范和分步设计等11种文档类型。每种文档都有约定的语义、存储目录和唯一ID。
智能体之间靠文档ID传递上下文，下游智能体通过专门的读取工具获取完整文档信息。文档通过特定字段维护上下游依赖关系，用户可基于血缘追溯（build_lineage）能力，从最终交付物出发，逐层追溯“需求→设计→方案→契约→报告”的整条研发链路。
这套机制的本质是将大模型短期的“对话记忆”，替换为持久化、可查询的“项目档案”。项目完成后，用户拥有的不仅是一堆代码，还有一套完整的工程文档链，实现项目经验的有效沉淀。
3、应对过程“黑盒”问题：以全链路审计实现研发可追溯
与文档体系互为表里的是枢机的审计系统，为AI研发提供高透明度和过程可追溯性。
系统内置的审计模块会捕获所有文档的创建、修改、追加及审批等操作记录，并自动写入审计日志。每一次文档的迭代变更，都会被系统自动计算unified diff并归档，供用户随时追溯修改历史。
在独立于项目主Git的隔离仓库中，系统定时对工作区执行快照备份（Git Commit + 会话上下文快照）。所有快照存储在指定目录下，不影响项目自身的Git提交历史。用户可在客户端中浏览历史检查点，一键安全恢复，确保特殊研发场景下的故障回滚能力。
开源部署设计：本地运行、多模型兼容
枢机选择了一种务实的开源策略：项目完整代码基于MIT协议对外开放，以桌面应用形态（Tauri v2，Rust + React + TypeScript）分发，API key存储在本地，整套开发流水线完整运行于用户本地设备。
这种“本地优先”的架构既是技术选择，也是其设计理念的延伸——如果枢机定位是“可审计的开发流水线”，那么流水线本身的运行环境也应该是用户可控的。依托本地独立运行的部署模式，用户可自主掌握数据与执行流程，保障数据安全。
API 层面上，项目保持厂商中立原则，原生适配Anthropic、OpenAI、DeepSeek及任意OpenAI 兼容接口。用户可按“经济/均衡/质量”三档预设一键切换，也可为不同部门独立配置不同厂商和模型。审查角色用轻量模型控制成本，核心设计角色搭载更强模型保证质量，兼顾开发效能与成本管控，实现资源利用效益最大化。
项目内置了5分钟Demo引导流程，用户可快速感受从内阁路由到工部编码、刑部验证的完整协作链路。
枢机将传统治理智慧融入现代AI工程体系的创新设计，为AI软件开发系统落地应用提供了差异化的解题思路。这个答案的效果如何，还需要更多实际项目场景的验证。
值得关注的是，在AI研发从“辅助编码”加速迈向“自主开发”的趋势下，枢机提供了一个极具参考价值的实践方向：将不可控的AI行为装进可控的标准流程框架中，在AI能力持续增长的同时，同步建设多智能体协作治理能力，以适配真实软件开发的工程落地与合规需求。
— END —
文章编辑：张小Q
