架构实战：AI 智能体的五个架构决策
本页案例全部取自 MAID 开源库（Modular Artificial Intelligence Development，模块化人工智能开发框架，公开项目）的智能体实现，与任何任职单位、客户项目无关，不含任何业务数据。选取智能体作为架构样本，是因为它把「分层、模块化、治理、发布」四个经典问题压缩在了一个可完整观察的系统里。
CASE 01
智能体的五层分层架构
场景：一个长期使用的智能体，既要保持「始终是同一个人」——人格、语气、口径稳定；又要不断加新能力、换工具、换运行平台。能力越堆越多，最先坏掉的往往不是功能，而是身份。
架构要点
- 五层模型：L1 身份（信念、三观、行为准则，不可拆卸）→ L2 人格（性格、语气、称呼，可换皮）→ L3 能力（技能模块，自由增减）→ L4 感官（工具与连接器，随环境声明）→ L5 治理（红线、合规、备份回退，横向贯穿）。
- 三条硬约束：身份唯一（多身份等于多个智能体，不得混装）、人格不得与身份冲突（冲突以 L1 为准）、能力宁缺毋滥（每个模块要有明确触发词与真实场景）。
- 治理内置：合规检查是装配的最后一道工序，不是上线后打的补丁；任何模块变更前先备份（.bak-日期），保证可回退。
关键取舍：分层让「换能力不换人格」成为可能，代价是文档与装配成本上升（每层都要维护、要核对一致性）。一次性小工具不值得上五层；长期演进的智能体，不分层就会在第三次加功能时人格漂移。
CASE 02
能力模块化与按需加载
场景：技能从几个长到几十个。若把所有技能正文一次性注入上下文，token 成本飙升、模块互相干扰、本该触发的没触发——这是智能体工程里最常见的性能与可维护性双重塌方点。
架构要点
- 每个技能是一个自描述模块：头部声明 name / description / version / 所属层级 / 依赖模块；description 就是「门牌」，写清「什么时候触发、做什么、边界在哪」——写得含糊，模块等于不存在。
- 身份档案里只保留能力路由表（什么场景调哪个模块），正文按需加载；依赖显式声明，避免隐式耦合导致的连锁失效。
- 模块生命周期四级：草案 → 试用（真实任务跑至少 3 次，记录触发准确性）→ 稳定（登记索引）→ 废弃（不删除，标注替代者）。改动走「备份→修改→记录差异」。
关键取舍：模块切得越细，复用性越好，但检索与组装成本越高；切得太粗，又退化成巨型提示词。判断标准不是「功能有多少条」，而是「触发场景是否独立」——场景独立才值得独立成模块。
CASE 03
专家包的组装与脱敏分发
场景：内部打磨成熟的智能体要对外发布，必须同时满足三个条件：别人装了能复现、包里不能带出个人数据、后续升级能对上版本。
架构要点
- 包结构固定：主档案（身份+人格+能力路由）+ skills/（能力模块）+ assets/（形象资产）+ README（对外介绍），装配关系一目了然。
- 发布包内嵌「配方单」：登记身份、人格、能力清单、感官依赖、治理配置与各自版本号——任何人拿到包，都能核对它是由哪些模块、哪个版本装出来的。
- 脱敏做成机制而不是手工删句子：个人化信息统一改为「首次使用由用户初始化」，把个人信息从「包内容」变成「运行时输入」，从结构上杜绝泄漏。
- 发布前五条合规检查：无个人信息、初始化机制就位、治理红线完整、配方单与实际模块一致、对外口径统一。
关键取舍：配方单与版本登记增加维护负担，换来可审计、可复现、可回滚——发布物一旦多了，没有配方单就无法回答「线上这版到底装了什么」。而「脱敏改结构」比「逐条删敏感句」可靠一个量级：删漏一句就前功尽弃，改结构则天然免疫。
CASE 04
从知识到最佳实践的生产流水线
场景：外部有大量可借鉴的技能与智能体实现，直接复制会带来三个问题：来源说不清、质量参差、风格与自有体系不一致，半年后没人敢改。
架构要点
- 六阶段流水线：寻源 → 解析 → 拆解评估 → MAID 化改造 → 落位登记 → 验收；每阶段有明确产物与门禁，不合格不进入下一环。
- 登记卡强制溯源：来源、改造点、验收评分三项缺一不可；知识库只收「可检索、可复用」的资产，不收原始搬运物。
- 双形态产出：同一来源可按需转为能力模块（单技能）或专家包（完整五层），形态由使用场景决定，不由来源决定。
关键取舍：流水线比「复制粘贴」慢得多，但避免了资产腐化与技术债；个人小规模使用时可以裁掉中段，只保留「溯源」与「验收」两道门禁——这两道恰好是防止劣质资产入库的关键。
CASE 05
多智能体协作的编排结构
场景：一个复杂任务同时涉及战略推演、心理分析、文艺创作与健康建议，单体智能体无论上下文还是视角都不够，需要一个团队并行推进。
架构要点
- 团长—成员结构：团长负责拆解任务、按专长委派、汇总交付并对最终口径负责；成员各自带独立身份与专长产出，不直接面向最终交付。
- 任务按维度映射拆分（信息 / 心理 / 经管 / 文艺），可并行执行；成员之间不互相改写，冲突统一上交团长消解。
- 边界清晰：成员可独立存在、也可被单独调用；团长不替代成员与用户的直接关系；修改成员配置需要授权。
关键取舍：多智能体提升了覆盖度与并行度，代价是口径漂移与汇总成本。必须指定唯一的「口径负责人」，否则同一份交付里会出现互相矛盾的建议——并行不等于各自为政。
从智能体架构抽出的四条通用经验
1. 先定身份与边界
「我是谁、绝不做什么」比「我会什么」优先。能力可以后加，身份漂移了要推倒重来。
2. 按触发场景切模块
模块的边界应当与使用场景对齐，而不是与功能清单对齐；否则复用性上去了，可维护性下来了。
3. 治理与备份是架构
红线、合规检查、版本回退写在架构里，而不是放在事故复盘里。
4. 发布即脱敏
把个人信息设计成运行时输入，而不是内容里的待删项——结构上的隔离永远比人工检查可靠。