本文深度剖析了 Aloy(一个面向企业营销团队的 AI 数字资产管理系统)在架构设计上的关键演进,详细阐述了其如何从一个早期的、基于固定管道的 Agent 系统,逐步收敛至一个与 Anthropic Claude 官方 Skill 设计范式对齐的、更为成熟和动态的统一架构。文章旨在为构建复杂、可扩展、可维护的企业级 AI Agent 系统提供一个经过实践检验的参考框架。
从 M×N 到 M+N:企业级 AI Agent 架构的“组合爆炸”难题与统一范式演进
作者: 老板
发布于: GameStarted.Life
日期: 2026年2月19日
引言:企业级 AI Agent 的“组合爆炸”困境
在构建企业级人工智能(AI)Agent 系统的过程中,开发者常常会遇到一个棘手的挑战,我们称之为“组合爆炸”(Combinatorial Explosion)。设想一个为跨国企业服务的数字资产管理(DAM)系统,其核心 Agent 之一“Gatekeeper”负责内容的合规性审查。该企业在全球 M 个市场(如中国、德国、美国)运营,拥有 N 个不同的品牌,每个品牌都有其独特的视觉识别(VI)和品牌指南。一个朴素的实现方法是为每个市场和品牌的组合创建一个特定的合规检查“技能”(Skill),例如 check-compliance-for-market-de-and-brand-x。这种方法的直接后果是,系统需要维护和管理的 Skill 数量将以 M×N 的速度急剧增长。每增加一个新的市场或品牌,都需要新增 N 或 M 个新的 Skill,这使得系统变得异常脆弱、难以扩展和维护。
本文将以我们正在构建的 AI DAM 系统“Aloy”为例,分享我们如何直面并解决这一“组合爆炸”难题的完整思考与架构演进过程。我们将展示 Aloy 如何从一个基于固定管道的 v4 架构,经历 v5 的三层架构探索,最终在吸收了 Anthropic Claude 官方 Skill 设计范式 [1] 的精髓后,演进为一个更为优雅和高效的 v6 统一架构。这一新架构的核心思想,是将 M×N 的组合问题,分解为一个仅需 M+N 个组件的线性问题,从而在根本上解决了系统的扩展性与可维护性挑战。
第一部分:Aloy 架构的演进之路:从固定管道到动态组合
Aloy 的架构并非一蹴而就,而是经历了一个不断迭代、逐步逼近问题本质的演化过程。理解其演进的轨迹,对于领会最终 v6 统一架构的精妙之处至关重要。
§ 1.1 v4 架构:硬编码的“固定管道”
Aloy 的早期版本(v1-v4)采用了一种当时业界普遍的 Agent 设计模式:每个 Agent 被设计为一个功能固定的“黑箱”,接收特定的输入,产生特定的输出。例如,CreatorAgent 接收一个结构化的创作意图,输出一个图文内容;而 GatekeeperAgent 则接收该内容,输出一份合规报告。Agent 之间通过硬编码的业务逻辑串联起来,形成一条固定的处理管道。
这种模式的优点是简单直观,易于在项目初期快速实现。然而,其弊端也同样显著:
僵化与脆弱:整个系统是静态的。如果业务流程发生变化,例如在合规检查后增加一个事实核查步骤,就需要修改 Orchestrator Agent 的核心代码。Agent 的能力与其自身实现被紧紧地耦合在了一起。
无法动态适应上下文:最致命的是,它无法解决前文提到的“组合爆炸”问题。Gatekeeper Agent 内部的合规逻辑是固定的,它无法根据待审查内容的上下文(例如,识别出这是一篇德语文章)来动态切换其合规检查策略。唯一的解决方案是创建多个 Gatekeeper Agent 的变体,但这显然是不可持续的。
§ 1.2 v5 架构:三层系统的探索与反思
为了解决 v4 架构的僵化问题,我们在 v5 版本中引入了“能力与知识分离”的核心思想,并独立设计出了一套包含“三层 Skill 架构”和“三层 Context 系统”的复杂模型。尽管这套模型最终被 v6 架构所取代,但它标志着我们从“面向实现”到“面向抽象”的关键一步,其设计思想为最终的统一架构奠定了基础。
三层 Skill 架构
我们尝试将 Agent 的能力分解为三个层次:
- 知识包 (Knowledge Packs):纯粹的业务知识,不包含任何执行逻辑。例如,“德国市场合规知识包”或“某品牌视觉指南知识包”。
- 能力技能 (Capability Skills):通用的、可执行的逻辑单元。例如,一个通用的“合规检查”技能,其内部逻辑是抽象的规则匹配。
- 组合技能 (Composite Skills):一个理论上的“运行时”概念,即在执行任务时,系统动态地将一个“知识包”和一个“能力技能”组合起来,形成一个面向具体场景的完整能力。例如,将“德国知识包”和“合规检查技能”组合成一个临时的“德国合规检查能力”。
三层 Context 系统
与之并行,我们设计了一套上下文管理系统,同样分为三层,旨在为 Agent 提供决策所需的环境信息:
- L1 Enterprise Context:企业级的全局规则与策略。
- L2 Brand Context:特定品牌下的品牌指南与资产。
- L3 Campaign Context:具体营销活动中的历史数据与用户反馈。
v5 架构的反思
v5 的设计极大地提升了系统的灵活性,其“知识与能力分离”的思想方向是完全正确的。然而,它的实现机制过于复杂。我们设计了专门的 SkillRegistry 来管理和组合 Skill,并用 ContextInjectionProcessor 来动态地向 Agent 的 Prompt 中注入上下文。最核心的问题在于,我们创造了两套并行的三层体系(Skill 和 Context),它们本质上是“同一个思想的两次投影”,这导致了不必要的概念冗余和实现复杂度。
正是在这个关键节点,我们暂停了开发,转而寻求业界成熟的最佳实践。对 Anthropic Claude 官方 Skill 设计范式的深度研读,为我们拨开了迷雾,指明了通向 v6 统一架构的清晰道路。
第二部分:范式对齐——当 Aloy 遇见 Claude
对 Anthropic 官方 Skill 设计范式的研究,成为了 Aloy 架构演进的催化剂。我们发现,v5 架构中那些略显笨拙的抽象,实际上是对一个更优雅、更底层范式的初步探索。我们所需要的不是另一层复杂的抽象,而是“回归第一性原理”——将我们的概念与 Claude 的原生能力对齐。
§ 2.1 Claude Skill 范式的核心启示
在 Anthropic 的设计哲学中,一个 Skill 远不止是一个可执行的函数。它是一个封装了知识、工作流和最佳实践的“指导手册”,其核心由以下几个关键概念构成:
1. Skill 是一个文件夹:一个 Skill 的载体是一个文件夹,其中必须包含一个
SKILL.md文件,以及可选的scripts/(可执行脚本)、references/(参考资料)和assets/(静态资源)目录。这种结构将“指令”与“资源”清晰地分离开来。
2. Progressive Disclosure(渐进式信息披露):这是 Claude Skill 设计中最为精妙的一点。它通过一个三层机制,在不牺牲专业深度的前提下,极大地节省了宝贵的上下文窗口(Context Window)资源。
- 第一层(YAML Frontmatter):
SKILL.md文件头部的元数据(如name,description),这部分信息会被始终加载,让 Agent 对 Skill 有一个高层级的认知,知道“何时”应该考虑使用它。
- 第二层(SKILL.md Body):当 Agent 根据
description判断一个 Skill 与当前任务相关时,它才会加载SKILL.md的主体部分。这里包含了详细的、分步骤的工作流指令,告诉 Agent “如何做”。
- 第三层(Linked Files):
SKILL.md的指令可以引用references/目录下的其他文件。Agent 只有在执行到需要特定知识的步骤时,才会按需加载这些参考文件,获取完成任务所需的“领域知识”。
3. 设计模式而非硬编码:Anthropic 提出了五种关键的设计模式,其中“模式4:上下文感知工具选择”(Context-aware Tool Selection)和“模式5:领域特定智能”(Domain-specific Intelligence)与 Aloy 的需求高度相关。它们倡导的不是创建无数个具体的工具,而是让一个通用的 Skill 能够根据上下文线索,智能地调整其行为或应用不同的知识规则。
§ 2.2 统一架构:从概念映射到实现收敛
这些来自 Claude 的核心启示,如同一面镜子,清晰地映照出 Aloy v5 架构中值得保留的闪光点与亟待简化的冗余之处。我们意识到,无需自行发明复杂的组合与注入机制,只需将我们已有的概念与 Claude 的原生范式进行一次“概念对齐”,即可实现一个更为优雅的 v6 统一架构。
下表清晰地展示了这次“大收敛”的核心映射关系:
| Aloy v6 统一概念 | 映射至 Claude Skill 范式 | 映射至 Aloy v5 旧概念 | 核心职责与实现 |
|---|---|---|---|
| :--- | :--- | :--- | :--- |
| Capability Skill | Skill (SKILL.md • scripts/) | Capability Skill | 通用执行能力。一个包含 SKILL.md 的文件夹,定义了“做什么”和“如何做”。例如 compliance-check Skill。 |
| Knowledge Asset | Reference Files (references/) | Knowledge Pack | 领域知识。存储在 Skill 文件夹内 references/ 目录下的 Markdown 文件,包含特定领域的纯知识。例如 market-de.md。 |
| Skill Pack | Skill Pack | (无直接对应) | 能力的集合。一个包含多个相关 Capability Skills 和 Knowledge Assets 的逻辑分组,便于分发和管理。例如 gatekeeper-pack。 |
| Context-Aware Selection | Pattern 4: Context-aware Tool Selection | Composite Skill (运行时组合) | 动态选择行为。Agent 根据上下文(如识别到德语)在运行时选择最合适的 Skill 的行为,而非一个具体的“组合 Skill”实体。 |
| Context Injection | Progressive Disclosure | ContextInjectionProcessor | 上下文注入机制。通过向 System Prompt 中动态添加指向 Knowledge Asset 的引用,引导 Agent 使用特定知识。 |
这次映射带来的最大变化是实现层面的简化。我们废除了自行设计的、复杂的 SkillRegistry 和 ContextInjectionProcessor。在 v6 架构中,Agent 的动态能力不再依赖于我们编写的复杂 TypeScript 代码,而是回归到 Agent 的第一性原理:依靠大语言模型(LLM)自身强大的自然语言理解能力,通过阅读和遵循 SKILL.md 中的指令,并结合上下文中提供的线索(Knowledge Asset 的文件路径),来动态地、智能地完成任务。
这种转变不仅大幅降低了代码的复杂度,更重要的是,它将架构的灵活性建立在了一个更稳固、更具扩展性的基础之上——即 LLM 本身的能力演进。
第三部分:Aloy v6 统一架构详解:一个实例
理论的阐述最终需要通过实践来检验。现在,让我们通过一个具体的、端到端的实例,来演示 Aloy v6 统一架构是如何优雅地解决“组合爆炸”问题的。这个例子将完整地展示其工作流程、数据流和设计思想。
场景:一篇针对德国市场的、关于“T100 电动车”的营销文案被提交到 Aloy 系统中,需要 Gatekeeper Agent 对其进行合规性审查。
§ 3.1 架构蓝图:简化的 Skill Pack 结构
在 v6 架构下,我们不再需要复杂的注册表或注入器。取而代之的是一个清晰、基于文件系统的 Skill Pack 结构。所有与 Gatekeeper Agent 相关的能力和知识都被组织在一个名为 gatekeeper-pack 的文件夹中:
/skills/
└── gatekeeper-pack/
├── compliance-check/ # 1. 通用能力 Skill (Capability Skill)
│ └── SKILL.md # -> 指导 Agent “如何”进行合规检查的 SOP
└── references/
├── market-de.md # 2. 领域知识资产 (Knowledge Asset)
├── market-cn.md # -> 德国/中国市场的具体合规规则
└── brand-maxus.md # -> Maxus 品牌的具体品牌指南
这个结构清晰地体现了“能力”与“知识”的分离:
compliance-check/目录代表一个通用的、可复用的能力。references/目录则是一个可独立维护的知识库,业务人员可以在这里添加或修改任何市场的规则,而无需触及任何代码。
§ 3.2 端到端工作流:一次合规审查的旅程
现在,让我们跟随这篇德语营销文案,看看它在 Aloy v6 系统中的完整旅程。
步骤 1:任务分发与上下文识别
- 用户通过 Aloy 的前端界面提交文案。系统的 Orchestrator Agent 接收到任务,通过初步的 LLM 分析,识别出两个关键的上下文元数据:
language: 'de'和product: 'T100'。 - Orchestrator Agent 判断该任务需要进行合规审查,于是将任务连同其上下文元数据一起,路由给 Gatekeeper Agent。
步骤 2:Agent 初始化与 Skill 发现 (Progressive Disclosure L1)
-
Gatekeeper Agent 被唤醒。它的核心指令(System Prompt)非常简洁,仅包含对其可用 Skill Pack 的引用。
Gatekeeper Agent’s System Prompt:
“You are the Gatekeeper… You have the following skills available. Use their descriptions to decide when to use them:
<skill>/skills/gatekeeper-pack/compliance-check</skill>” -
Agent 运行时(Mastra/Claude)看到
<skill>标签,自动加载compliance-check/SKILL.md文件头部的 YAML Frontmatter。这部分内容极小,仅包含 Skill 的名称和一段关键的描述。# /skills/gatekeeper-pack/compliance-check/SKILL.md (YAML Frontmatter) name: compliance-check description: "Performs a compliance check on a given text asset. It can adapt its rules based on the provided market context (e.g., 'de', 'cn'). You MUST be provided with a market context to use this skill."
步骤 3:动态上下文注入
-
Aloy 的后端服务(
ContextService)根据任务的元数据language: 'de',在发送给 Agent 的最终 Prompt 中,动态地构建一个Context片段。这个片段只包含指向相关知识资产的文件路径,而不是文件内容本身。Final Prompt to Gatekeeper Agent:
“User: Please review the following asset.
Asset Content: ‘Das neue T100 Elektroauto…’ (德语内容…)
Context:
- Market Rules:
<file>/skills/gatekeeper-pack/references/market-de.md
- Brand Guidelines:
<file>/skills/gatekeeper-pack/references/brand-maxus.md”
- Market Rules:
步骤 4:Skill 加载与知识融合 (Progressive Disclosure L2 & L3)
-
Gatekeeper Agent 接收到完整的 Prompt。它阅读了
compliance-checkSkill 的description,并看到了 Prompt 中提供了Market Rules上下文。它判断出compliance-checkSkill 与当前任务高度相关。 -
此时,Agent 才会加载
compliance-check/SKILL.md的主体部分(L2),这里包含了详细的工作流指令。 -
SKILL.md的指令会引导 Agent 去阅读Context部分提供的文件路径,从而按需加载market-de.md和brand-maxus.md的具体内容(L3)。# /skills/gatekeeper-pack/compliance-check/SKILL.md (Body) ## Workflow: Compliance Check 1. **Identify Context**: Read the file paths provided under the `Context:` section in the user's prompt. These files contain the specific rules you must follow. 2. **Apply Market Rules**: Read the `market-*.md` file. Check the asset content against every rule listed in this file. 3. **Apply Brand Guidelines**: Read the `brand-*.md` file. Verify brand voice, tone, and visual mentions. 4. **Synthesize Report**: Create a report detailing which rules passed and which failed. For failures, provide the exact rule violated and a suggestion for remediation.
步骤 5:执行与输出
- Agent 严格遵循
SKILL.md中定义的步骤,依次读取market-de.md和brand-maxus.md的内容,将其中定义的规则(例如,德国广告法对能耗标签的要求)应用到德语营销文案的审查中。 - 最终,Gatekeeper Agent 输出一份完全基于德国市场和 Maxus 品牌规范的、详细的合规审查报告。
§ 3.3 M+N 问题的解决之道
v6 架构的优雅之处在于,如果公司决定开拓法国市场(一个新的 M),我们不需要创建任何新的 Skill。业务团队只需在 references/ 目录下新增一个 market-fr.md 文件。当一篇法语文章被提交时,ContextService 会自动识别并注入这个新文件的路径,Gatekeeper Agent 会遵循完全相同的工作流,只是读取了不同的知识资产,从而无缝地实现了对法国市场的支持。
我们不再需要 M×N 个 Skill,而只需要 N 个核心的 Capability Skill 和 M 个独立的 Knowledge Asset。系统的复杂度从乘法关系降维到了加法关系,从根本上解决了“组合爆炸”的难题。
结论:回归第一性原理,构建可演进的 AI 系统
Aloy 架构从 v4 到 v6 的演进,不仅仅是一次技术升级,更是一次在设计哲学上的“回归第一性原理”。我们最终认识到,构建一个强大而灵活的 AI Agent 系统的关键,不在于编写多么复杂的代码来“控制”Agent,而在于如何最有效地利用和引导大语言模型本身固有的、强大的自然语言理解和推理能力。
v6 统一架构的核心,正是建立在这一认知之上。它总结了三大核心原则:
- 能力与知识分离 (Separation of Capability and Knowledge):将“如何做”(
Capability Skill)与“用什么知识做”(Knowledge Asset)彻底解耦。这使得能力的复用性和知识的可维护性都达到了最大化。 - 描述驱动选择 (Description-driven Selection):Agent 的动态行为,来自于它对 Skill
description的自然语言理解。我们信任并利用 LLM 的能力,让它自己去判断在何种上下文下应该使用何种 Skill,而不是通过硬编码的逻辑来指定。 - 上下文引导执行 (Context-guided Execution):通过向 Agent 的 Prompt 中动态注入指向“知识资产”的引用,我们为 Agent 的每一次执行都提供了精确、即时的“导航”。Agent 遵循
SKILL.md的通用指令,但其最终行为却被注入的特定上下文所塑造。
这一系列原则共同将系统的复杂度从 M×N 的乘法灾难,降维至 M+N 的线性增长,为构建真正可扩展、可维护、可演进的企业级 AI Agent 系统提供了一条清晰可行的路径。Aloy 的故事证明,最优雅的架构往往不是最复杂的,而是最贴近其核心技术(在这里,即 LLM)本质的。这或许是所有 AI 系统架构师在未来的探索中,都值得铭记于心的准则。
参考文献
[1] Anthropic. (2026). The Complete Guide to Building Skills for Claude. Anthropic. Retrieved from internal documentation claude_skill_guide.pdf.