在构建企业级 AI Agent 系统时，一个核心问题会不断出现：
应该将所有能力集中在一个 Agent 中，还是拆分为多个 Agent？Skill、Tool、MCP、A2A 的边界到底在哪里？
本文是对这一问题的一次结构化总结。
在很多早期设计中，Skill 常被误解为“可以调用的能力单元”。
但更准确的定义是：
Skill 本质上是上下文中的操作规程，而不是 runtime 可执行函数。
例如：
它们更接近：
而不是：
因此可以抽象为：
| 概念 | 本质 |
|---|---|
| Tool | 可执行动作 |
| Skill | 行为规范 / 方法论 |
| 文档索引（如 AGENTS.md） | 手动 Skill 组织方式 |
所谓“渐进式披露”，本质只是 Skill 的按需加载机制，并不等价于执行系统。
一个常见直觉是：
既然 Agent 能理解上下文，那是否可以把所有业务能力（HR、CRM、财务等）统一放进一个 Agent？
但在企业环境中，这种设计会带来结构性问题：
不同业务域语义混杂，导致推理边界不清晰。
敏感数据（人事、财务、合同）难以隔离。
无法追踪“哪个规则影响了最终决策”。
当 Skill / Tool 数量增长时，选择错误概率显著上升。
企业级 Agent 系统更合理的结构是：
可以抽象为：
用户 → 入口 Agent → 业务域 Agent → Tool 层
关键点：
A2A 的核心不是 tool invocation，而是：
不同业务 Agent 之间的任务委派与协作机制
典型能力包括：
它适用于：
但它不负责执行底层操作。
在实际工程中，一个关键事实是：
通用 Agent 客户端通常只支持 MCP tools/resources，而不原生支持 A2A 网络。
因此：
这就引出了一个关键架构问题：
如何让 MCP 客户端访问 A2A Agent 网络？
在企业架构中，通常需要增加一个 Gateway 层：
该层负责：
其作用是：
将 A2A 网络“转换”为 MCP 可调用的工具集合
但需要注意：
可以总结为四层结构：
业务 Agent 不应维护“用户长期记忆”，否则会造成语义污染与权限扩散。
必须负责：
企业级 Agent 系统的本质不是：
一个强大的通用 Agent
而是：
一个可治理的 Agent 网络系统
其中：
企业级 AI 架构的正确方向是：
通过分层设计，将“理解用户”的能力集中在交互层，将“业务决策”分布在领域 Agent，将“执行能力”下沉到 Tool 层，并通过 A2A 实现 Agent 网络协作，通过 MCP 提供统一外部接入能力。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。