企业AI 数字化转型，先把底座做好

最近讨论企业 AI 数字化，话题很容易从业务场景跳到技术名词：要不要建知识库，要不要上 MCP Gateway，要不要做 A2A，多 Agent 会不会成为下一代平台。

这些问题都重要，但顺序很容易反过来。

企业真正要解决的，通常不是“模型还不会回答问题”，而是模型回答之后能不能引用可信资料，调用工具时能不能遵守权限，执行失败后能不能恢复，高风险操作能不能让人接管，出了问题能不能查清楚谁在什么时候做了什么。

所以，企业 AI 架构的起点不应该是一张产品采购清单，而应该是一套可控的“数据、模型、工具、流程、治理”底座。

先看整体分层#

一个比较实用的分层如下：

这里最容易误解的是几个组件之间的关系：知识库负责提供上下文，工具网关负责受控地调用系统，A2A 负责 Agent 之间的协作。它们不是同一种基础设施，也不存在把三者一起部署就完成了企业 AI 转型的捷径。

知识库解决的是“依据从哪里来”#

知识库通常是企业最先想到的 AI 能力。制度、产品说明、售后政策、合同模板和操作手册经过检索后，可以为回答提供企业自己的依据。这类场景适合使用 RAG，也就是先检索企业内容，再让模型基于检索结果生成回答。

但知识库不是把 PDF 批量丢进向量数据库。

至少还要处理这些问题：

文档如何采集、解析、切分和建立版本；
每份内容的来源、责任人和有效期是什么；
用户原本没有权限查看的内容，是否会被检索出来；
关键词检索、向量检索和重排序如何组合；
回答是否能够给出来源，过期内容如何被发现；
文档知识和实时业务事实应该如何分工。

最后一项尤其重要。制度和 SOP 可以进入检索系统，但订单状态、库存数量、账户余额、客户等级这类信息不能只依赖向量检索。它们应该通过经过权限控制的实时业务 API 或工具读取。

可以简单地这样划分：

1
制度、SOP、产品资料、客服话术 -> 搜索 / RAG
2
订单、库存、余额、客户状态     -> 受控业务 API
3
退款、补货、审批、发货         -> 工作流和业务服务

知识库的难点因此不在于“有没有向量数据库”，而在于数据质量、权限继承、内容生命周期和答案溯源。没有这些管理能力，知识库规模越大，错误答案越难排查。

MCP Gateway 解决的是“工具怎么被调用”#

MCP 可以把工具、资源和上下文以相对统一的方式提供给模型或 Agent。企业实际落地时，通常还需要在 Agent 和内部系统之间增加一层工具治理能力，这一层可以称为 MCP Gateway 或 Tool Gateway。

它至少应该关注：

工具注册、描述、版本和负责人；
用户身份、租户隔离和工具级权限；
参数校验、超时、限流、重试和幂等；
敏感字段过滤、脱敏和结果大小限制；
读操作与写操作的区分；
高风险操作的人审确认；
完整的调用日志和审计记录。

这里有一个边界需要说清楚：MCP Gateway 是企业工程上的治理模式，不是 MCP 协议强制要求的组件。规模较小、工具数量有限的应用，直接使用受控的业务 API 也可能足够。只有当系统变多、工具变多、权限和审计要求变复杂时，统一网关的价值才会明显体现出来。

工具的设计也不能太随意。不要把数据库和内部 API 原样暴露给模型：

1
execute_sql(sql)
2
call_any_api(url, body)

这类工具的能力过于宽泛，权限边界和审计边界都很难定义。更合适的是面向业务意图设计窄工具：

1
查询订单状态(order_id)
2
申请退款(order_id, reason)
3
创建补货任务(sku_id, quantity)

工具越接近业务动作，越容易做参数校验、权限判断、风险分级和失败补偿。AI 的灵活性应该放在“选择哪个动作、如何组织信息”上，真正改变业务状态的部分仍然要由明确的业务服务负责。

A2A 解决的是“多个 Agent 如何协作”#

A2A 适合让具备独立能力边界的 Agent 之间发现能力、交换任务和协作。例如销售 Agent 把合同交给合同审查 Agent，再交给风控 Agent 和履约 Agent。

但很多早期项目并不需要 A2A。一个 Agent 调用多个工具，配合工作流编排、任务队列、状态持久化和人工审批，已经可以覆盖相当多的业务流程。

如果一个所谓的多 Agent 系统只是把一个大 Prompt 拆成几个角色，再让它们互相传几段文本，那么引入协议不会自动带来更好的可靠性。它反而会增加调试、超时、状态追踪和权限传递的复杂度。

我会用几个问题判断是否值得建设 A2A：

这些 Agent 是否拥有清晰且独立的能力边界；
是否由不同团队或不同系统分别维护；
是否需要独立发布、扩缩容和治理；
是否存在跨系统、跨部门甚至跨组织的任务委派；
现有工作流和工具调用是否已经无法满足协作需求。

如果大多数答案是否定的，先做好 Agent Runtime 和工作流，通常更稳妥。A2A 更像复杂协作阶段的扩展能力，而不是企业 AI 的第一层基础设施。

真正应该优先建设什么#

P0：先建立生产边界#

这些能力缺失时，AI 很难稳定进入生产：

业务流程边界：明确 AI 是提供建议、辅助决策，还是允许自动执行；
统一身份和权限：用户、组织、租户和数据权限要贯穿知识检索与工具调用；
模型网关：统一模型接入、路由、降级、成本统计、敏感信息处理和版本管理；
数据与知识治理：维护数据目录、文档版本、有效期、责任人、权限和质量规则；
Agent / Workflow Runtime：保存上下文和任务状态，处理超时、重试、幂等和人工介入；
安全与审计：关注提示注入、敏感信息泄露、过度授权、密钥管理和操作留痕；
评测与可观测性：同时观察答案正确性、引用准确性、工具调用正确率、延迟和成本。

P1：业务规模起来之后再产品化#

当接入系统和业务场景变多，再考虑建设统一的 MCP Gateway、Tool Registry、企业级 RAG 平台、会话记忆、事件总线、审批中心，以及 Prompt、模型、工具和知识库的版本发布流程。

这一阶段的目标不是把组件堆齐，而是把共性能力收拢起来，避免每个 AI 应用都自己实现一套权限、日志和重试逻辑。

P2：复杂协作场景再引入#

跨部门 Agent 市场、Agent 身份与信任体系、动态任务委派和跨企业 Agent 协作，属于更后面的能力。它们有价值，但前提是企业已经有足够多的独立 Agent 和稳定的协作需求。

一条更容易落地的路径#

比较实际的建设顺序是：

1
单一高价值场景
2
  -> 只读知识问答
3
  -> 只读业务查询
4
  -> 低风险写操作 + 人工确认
5
  -> 工作流自动执行
6
  -> 多 Agent 协作
7
  -> 跨组织 A2A

例如，企业可以先做内部制度和业务 SOP 问答，再让客服查询订单和物流信息；接着让 AI 生成退款或审批单，由员工确认后提交；当这些流程的权限、状态、审计和失败处理都跑通以后，再评估是否需要拆分多个 Agent，或者让不同系统之间通过 A2A 协作。

这条路径还有一个好处：每一步都能产生可验证的结果。第一步可以检查引用准确率，第二步可以检查权限隔离，第三步可以检查人工确认和业务状态，第四步可以检查幂等、重试和补偿。等到需要多 Agent 时，很多基础问题已经有了答案。

结语#

企业 AI 数字化转型，优先级大致应该是：

业务流程与权限治理 > 模型网关与 Agent Runtime > 知识库和业务 API > 工具治理 > A2A。

这不是说知识库、MCP Gateway 或 A2A 不重要，而是它们解决的问题不同，成熟度也不同。知识库让模型有依据，业务 API 让模型读到实时事实，工具网关让调用变得可控，工作流让执行可以恢复，A2A 则让多个独立 Agent 在复杂场景下协作。

如果统一身份、数据权限、业务 API、审计和流程状态还没有准备好，直接开始建设 A2A，最后得到的往往只是一组互相调用、却无法解释和控制的聊天机器人。

先把每一次检索、每一次工具调用和每一次状态变化管起来，企业 AI 才有机会从演示走到真正的业务流程里。