Agent 体系架构：Agent · Skill · Rule 的分层设计哲学

一句话理解：一个 Agent 什么都能干，但十个 Agent 各干各的也不对——需要三层结构来组织它们：Agent 负责"谁来做"，Skill 负责"能做什么"，Rule 负责"不能做什么"。

一、从一次生产事故说起

📚 综合案例：基于作者在多个项目中观察到的共性风险归纳，非单一客户脱敏

2025 年 4 月，某 SaaS 团队引入 AI 编码助手完成了一次支付模块重构。整个过程看起来顺利——需求描述给进去，代码出来了，测试也跑过了。

两周后，用户投诉金额计算出现精度丢失。排查发现，AI 在重构过程中把一段货币计算从 Decimal 改成了 float，理由是"提高性能"。没有人拦截这个决策，因为没有任何机制要求它在修改类型时停下来等待审查。

单 Agent 架构的问题不是 AI 写错了代码——是它在写代码的同时还在做架构决策，而这两件事本不应该由同一个执行者在同一时刻完成。

这就是本章要解决的核心问题：如何给 AI Agent 系统建立结构，让它在加速的同时，不失去控制。

二、为什么单 Agent 不够用

那次事故暴露的，是单 Agent 架构三个无法回避的结构性缺陷。

角色混淆是最根本的问题。同一个 Agent 同时扮演架构师和程序员，就像既当运动员又当裁判。它在执行代码修改时，不会主动停下来问"这个类型变更会不会影响下游精度"——因为没有一个独立的角色被赋予这个职责。

上下文碎片化加剧了判断失误。一个有限的上下文窗口，要同时承载需求描述、技术规范、安全限制、API 定义、历史对话——每个领域分到的信息都不完整。Agent 在碎片信息上做决策，结果是前后矛盾：第一轮输出用了 Decimal，第三轮优化时悄悄改成了 float，没有任何机制记录这个变更的意图。

串行执行放大了偏差代价。因为只有一个 Agent，所有步骤只能顺序进行，上游带进来的错误一路传导到最后。发现问题时，前面所有的工作都要推倒重来。

三、三层体系：给 Agent 系统立宪

解决上述问题的路径，不是换一个更强的模型，而是引入结构——把"谁来做"、“能做什么”、"不能做什么"拆成三个独立的逻辑层。

三层之间的关系是：Agent 调用 Skill 执行任务，Rule 约束所有 Agent 和 Skill 的行为边界。Rule 层不属于任何一个 Agent，它是整个系统的"宪法"。

回到开头的事故：如果有独立的审查 Agent（Agent 层分离角色），如果类型变更会触发静态分析检查（Skill 层能力），如果有规则明确禁止在货币计算中使用浮点类型（Rule 层约束），这次事故有三道机会被拦截。

Agent 层：单一职责的执行者

每个 Agent 绑定一个固定角色，一个 Agent 只做一件事。

需求 Agent 只做需求分析，不做技术选型。编码 Agent 只按 spec 执行代码生成，不做架构决策。审查 Agent 只做质量检查，不修改代码。每个 Agent 有独立的 Memory 和 Context，互不污染。

这种分离不是形式主义。编码 Agent 不需要知道需求会议的细节，它只需要读到 spec 里的 API 定义。需求 Agent 不需要关心代码用了什么设计模式，它的产出止于 proposal。独立的上下文意味着每个 Agent 的信息密度可以最大化——它只处理它该处理的信息。

Skill 层：可跨 Agent 共享的能力包

Skill 是 Agent 的能力单元，封装了对 LLM 的调用和工具的调用。关键在于"解耦"——同一个 Skill 可以被多个 Agent 共享，不需要为每个 Agent 重复定义能力。

审查 Agent 用的代码检查规则，编码 Agent 在提交前可以调用同一套做预检。这意味着质量标准只定义一次，在多个节点复用。

Rule 层：三道防线

Rule 层是所有 Agent 都必须遵守的约束，独立于 Agent 和 Skill 之外。它通过三个时刻执行：

• 编译时：注入到每个 Agent 的 System Prompt，成为它的"行为宪法"
• 执行时：插入工具调用链的检查点，拦截违规操作
• 输出时：验证最终结果是否符合约束

三道防线的意义在于容错：即使某一层失效，其他层还能拦截。

四、六个专项 Agent 的角色分工

三层架构搭好之后，需要确定具体由哪些 Agent 来覆盖软件开发全流程。六个角色，每个角色的输入、输出、职责边界都是固定的。

需求 Agent：输入是原始需求文档和会议记录，输出是结构化需求描述（proposal），职责止于需求分析，不做技术选型。它存在的意义是把"用户说了什么"翻译成"系统应该做什么"，这两件事之间的鸿沟往往是整个项目最大的风险源。

设计 Agent：消费 proposal，输出架构文档和 API 定义（design + spec）。它是第一个做技术决策的角色，也是后续所有 Agent 的"契约提供者"——编码 Agent 按 spec 实现，测试 Agent 按 spec 验证。

编码 Agent：按 design 和 spec 逐任务执行代码生成，不做架构决策。它是执行者，不是决策者。如果发现 spec 有歧义，它的正确行为是停下来，而不是自行判断。

审查 Agent：只审查，不修改代码。这个约束看起来苛刻，实际上是核心原则：修改权和审查权分离，才能保证审查的独立性。审查 Agent 输出问题列表，由编码 Agent 根据问题列表修改。

测试 Agent：根据 spec 生成测试用例，执行测试，输出覆盖率报告和失败日志。它的参照系是 spec，而不是代码本身——测试的是"代码是否实现了 spec 要求"，而不是"代码是否能跑通"。

诊断 Agent：分析错误日志和代码上下文，输出根因分析和修复建议，不自行修复。修复权归编码 Agent，诊断 Agent 只提供判断依据。这个角色在生产事故排查中价值最高——它不带代码实现偏见，专注于"为什么出错"。

五、四种协作拓扑与选择时机

六个 Agent 不是永远按固定顺序协作。任务的特征决定拓扑的选择，拓扑的选择决定效率和质量的取舍。

串行链是默认的开发模式：需求→设计→编码→审查→测试。适用于有明确先后依赖的流水线。代价是效率最低——每个 Agent 必须等上游完成，整体延迟是各环节的累加。

并行扇解决的是独立任务的吞吐问题。模块 A、B、C 没有相互依赖，就分别交给三个编码 Agent 并行执行，最后统一合并。这是 Multi-Agent 相比单 Agent 最直接的效率优势，但它要求任务之间真正独立——有隐性依赖的任务强行并行，合并时会出现冲突。

监督-执行引入了一个监督 Agent 负责任务分解、分配和结果验收。执行 Agent 池可以动态扩缩，监督 Agent 对不符合标准的输出退回重做。适合代码重构这类需要统一质量标准、单任务体量较大的场景。监督 Agent 本身的质量决定整体系统的上限，是这种拓扑的核心风险点。

辩论式成本最高，信息损失最小。两个或多个 Agent 从不同角度分析同一个问题，通过多轮对话逼近最优解。单 Agent 倾向于选择"看起来最常见的"方案；辩论式能暴露"哪个方案最合理"。适合架构评审、需求歧义澄清、高风险技术选型。

一个实际项目通常混用多种拓扑：需求→设计阶段用串行链，模块开发阶段用并行扇，最终代码合并审查用监督-执行，架构方案有争议时切换辩论式。

六、tasks.md：跨 Agent 的状态总线

六个 Agent 独立执行，就需要一个机制告诉它们彼此的进展。tasks.md 承担的是状态总线的角色——它不是一个任务清单，而是整个 Multi-Agent 系统的神经系统。

状态机有三条不可突破的规则：

单写多读：同一时刻只有一个 Agent 修改某个 task 的状态。编码 Agent 和审查 Agent 不能同时写同一个 task，否则会产生状态竞争。

产物绑定：每个状态变更必须附带对应的工作产物。编码 Agent 把 task 从 in_progress 改为 review，必须附上代码变更路径。审查 Agent 把 task 改为 rejected，必须附上问题列表。没有产物的状态变更是无效的——你不知道"完成"了什么。

禁止跳跃：不允许跳过 review 状态直接标记 completed。这条规则的存在是为了防止时间压力下的"绕过"——在生产系统中，被跳过的审查几乎必然在未来某个时刻引爆。

tasks.md 的价值不只是追踪进度，而是在六个 Agent 的异步执行之间建立可追溯的因果链：谁在什么状态下做了什么，产生了什么产物，遭到了什么质疑，最终如何解决。事后复盘生产事故，这条因果链是关键证据。

七、框架选型：在正确的时间选正确的工具

三大主流范式在架构哲学上有本质差异，选型之前先确认自己在哪个阶段——但这里要先说明一个重要的生态变化：AutoGen 已不再是一个独立演进的活跃框架。📄 2026 年 4 月，微软正式发布 Microsoft Agent Framework 1.0，把 AutoGen 和 Semantic Kernel 合并为统一的生产级 SDK，由原班团队打造；遗留的 AutoGen 代码库仍会获得维护，但新功能投入已经转向 Agent Framework，多家评测机构也观察到 AutoGen 的独立版本迭代明显放缓。这意味着，如果你的技术栈以微软/Azure 生态为主，"辩论式"拓扑更合理的落地方式已经是 Microsoft Agent Framework 内置的 group-chat 编排，而不是单独引入 AutoGen。

这里给出一个明确的倾向性建议，而不是中立的"各有优劣"：

从 CrewAI 开始，不要一上来就用 LangGraph；如果你的团队本来就在微软 / Azure 技术栈上，直接从 Microsoft Agent Framework 起步，不必再单独引入 AutoGen。

CrewAI 的声明式配置让你在几小时内跑通第一个 Multi-Agent 流程，快速验证你的角色划分和拓扑设计是否合理。需求没稳定之前就用 LangGraph，你会把大量时间花在框架学习上，而不是业务价值上。

当以下信号出现时，迁移到 LangGraph：

• 你需要精确控制某个节点的执行条件（条件分支、循环回退）
• 你需要人类在环介入（Human-in-the-loop）
• 你需要完整的执行审计日志
• 系统进入生产环境，稳定性要求高于开发速度

📄 LangGraph 已于 2025 年 10 月正式 GA，2026 年上半年进一步加入了逐节点超时控制、增量状态通道（DeltaChannel）等生产级能力，是目前在企业级多 Agent 部署中被反复提及、生态最成熟的图编排框架之一。

辩论式（多 Agent 多角度推理）拓扑现在有两条可选路径：如果你的系统深度绑定 Azure/.NET 生态，直接用 Microsoft Agent Framework 内置的 group-chat 编排模式——它继承了原 AutoGen 的多 Agent 会话能力，同时具备 Semantic Kernel 的会话状态管理、类型安全和可观测性；如果你的团队是 Python 原生、且已经在用 LangGraph 或 CrewAI 作为主框架，更务实的做法是在其中一个节点内部实现"多 Agent 对话逼近共识"的逻辑，而不是为此单独再引入一个第四框架。对于仍在维护的 AutoGen 0.2.x / AG2 遗留代码库，可以继续运行，但新项目不建议以 AutoGen 作为起点。

💡 以上关于各框架"适合阶段""学习曲线"的判断综合了多份 2026 年上半年的第三方评测，属于工程经验层面的倾向性归纳，而非官方基准测试结论；具体到你的项目，仍建议用一个小范围 PoC 验证后再做技术栈决策。

八、把三层结构用到一次真实的重构任务上

理论在真实场景里才有重量。回到本章开头的支付模块重构，用三层架构重新走一遍这个任务，看看每一层在哪个环节发挥作用。

任务背景：支付模块货币计算逻辑重构，涉及类型系统变更，下游依赖三个业务模块。

这张图里有几个值得注意的细节：

需求 Agent 在 proposal 里明确写入了"货币计算禁止浮点"——这不是技术要求，是业务要求，需求 Agent 负责把它从用户语言翻译成可执行的约束，传递给下游。

设计 Agent 的 spec 里同时规定了类型和 API 响应格式——Decimal 类型在后端保证精度，string 格式在 API 层防止 JSON 的浮点序列化问题，这两个决策要在 spec 阶段同时做，而不是等到编码时发现。

编码 Agent 在提交前调用了静态分析 Skill 做预检，自行发现并修正了一个问题——这是 Skill 层复用的典型场景，审查 Agent 用的同一套规则，编码 Agent 在提交前用一遍，不等到审查才发现。

审查 Agent 拦截的问题（toFixed(2) 的浮点中间计算）是静态分析没有覆盖到的语义问题——独立审查视角的价值在这里体现：它看的不只是代码是否合法，而是业务约束是否被真正遵守。

没有结构的 Agent 系统，加速度越大风险越高。三层架构的价值不是让 Agent 慢下来，而是给加速建立边界，让出错的代价可控、可追溯、可修复。

下一章将基于这套架构，实现第一个实战角色：需求 Agent——从会议录音到结构化 proposal 的完整实现。

本专栏的开源落地工具：IvyFlow

本专栏的整套方法论——多角色工作流、阶段守卫、OpenSpec+Superpowers 双驱动、Skill/Rule/Agent 三层分层——并非纸上谈兵。它们的落地载体是 IvyFlow，一个 AI-Native 开发工作流 CLI 工具，也是本专栏作者的开源项目。

IvyFlow 用一条命令（ivy init）在项目中部署 5 种角色（Developer / PM / QA / Architect / DevOps）共 20+ 条命令和约 30 个 Skill，将专栏中讨论的"Phase Gate、Delta Spec 反写、TDD 强制循环、SubAgent 并行扇"全部编码为脚本校验而非纯 Prompt 约定——守卫脚本会硬性拦截 AI 跳过阶段的行为，让流程纪律从"建议"变成"物理约束"。

• GitHub：github.com/jseko/IvyFlow
• 官方网站：jseko.github.io/IvyFlow
• 安装：npm install -g ivyflow-cli && ivy init

如果你读完本专栏想立刻落地，IvyFlow 就是这套体系的开箱即用入口。