MCP 接资料、A2A 接代理后，企业该先拆哪两层架构？

Anthropic 在 2024 年 11 月 25 日公开 Model Context Protocol（MCP），把 AI 连接资料来源、工具与系统的方法标准化；Google 则在 2025 年 4 月 9 日宣布 Agent2Agent Protocol（A2A），让不同代理可以彼此发现能力、交换任务并协调执行。这两个方向一起出现后，企业很容易误以为只要把所有代理、工具与资料都接起来就行了。实际上，最该先拆开设计的是两层：工具连接层与代理协作层。

第一层：工具连接层，负责资料与能力的可控接入

MCP 解决的核心问题，是让模型或代理以一致方式碰到档案、知识库、资料表、后台工具与外部服务。这一层的治理重点不是任务分工，而是资料范围、权限、版本、来源可信度、速率限制、日志与错误回报。企业若在这一层没先定义清楚，代理即使能用工具，也只会更快拿到不该拿的资料，或把旧资料当成最新依据。

第二层：代理协作层，负责任务交接与状态管理

A2A 强调的是代理与代理之间如何分工合作，例如一个代理负责接收需求、另一个代理负责查文件、第三个代理负责排程或建立工单。这一层要处理的不是资料栏位，而是能力发现、任务生命周期、谁负责回复、如何回传中间结果、哪些步骤需要人介入。若把这些责任混进工具连接层，系统就很容易变成每个代理既懂流程又直接碰资料，最后谁该负责哪一个动作反而说不清楚。

工具可连，不代表代理就该互相放行

很多团队会把“可以接上”误认成“可以互相信任”。但就算两个代理都能通过标准协议沟通，也不代表它们应该共享相同权限、看到相同上下文或执行相同动作。较稳健的做法，是先让每个代理只暴露明确能力与输入输出格式，再通过协作层限制可交办任务、可回传资讯与人工审批点，避免一个代理把另一个代理变成绕过权限的跳板。

先把责任边界写进架构，不要写进提示词

若企业只靠提示词交代“不要乱做事”，通常撑不到正式上线。真正可维护的做法，是把资料来源、工具授权、任务状态、代理角色、回复责任与人工复核规则写进系统架构与日志设计中。提示词可以帮助模型理解任务，但责任边界必须由系统保证，而不是寄望每次生成都刚好守规矩。

从单一代理加单一协作场景开始

对大多数企业而言，起点不需要是多代理大平台。较实际的试点，是先选一个已经需要查资料又需要跨角色交接的流程，例如客服升级处理、报名文件预审、提案知识检索或专案交接问答。先让一个代理通过 MCP 安全取用知识，再让第二个代理只负责接手特定任务。这样比一次把所有代理都串起来，更容易验证边界是否正确。

米亚科技的建议

若企业开始评估 MCP、A2A 或类似 agent protocol，建议先画出两张图：一张是工具连接图，列出哪些资料与工具可被哪些代理读取；另一张是代理协作图，列出哪些代理可以把什么任务交给谁、哪些步骤要回到人工审批。把这两层拆开后，企业才能在标准化协议成熟时放心扩充，而不是把整个系统绑在难以追踪的黑箱流程上。