摘要：本文面向技术负责人、架构师和正在做企业 AI 落地的工程师，解决一个高频又棘手的问题------企业买了好几个 Agent 工具和平台，它们之间调不动、数据也导不过去，智能体怎么接进现有的 ERP、CRM、WMS。文章提出"接入三道坎"分析框架，对比 A2A / MCP / 传统 API 网关 / 工具网关四类方案，给出一段可运行的接入自查脚本与一份可收藏的六关清单。
@toc
一、为什么 Agent 接不进现有系统
企业上 Agent 常见的落差，不是模型不够强，而是"接不进"。
很多团队先买了一家办公 Agent，又接了一家编码 Agent，再试点一家行业 Agent。Demo 阶段个个惊艳，真要联动时就卡住了：A 平台生成的工单，B 平台的 Agent 读不到；同一个客户在 CRM 里的数据，智能体调了三次接口拿回三种格式；想让 Agent 直接改 ERP 里的订单状态，安全团队直接叫停------怕它越权写、怕重试重复扣款。
一个很实在的判断标准来自一线落地经验：先看数据能不能接，你的 ERP、知识库，它接得进去吗？接不进，就是摆设。 模型能力再好，如果卡在"和现有系统说不上话"，Agent 就只能停留在"解释世界"，进不了"改写世界"。
2026 年行业共识也越来越清楚：Agent 的竞争核心从模型转向工程化治理能力，而"能不能安全接入现有系统"正在变成采购时的硬指标。本文就拆这件事------到底卡在哪、协议和网关怎么选、上线前怎么自查。
二、命名框架：企业 Agent 接入的三道坎
把接入失败的原因归归类，基本都落在三道坎上。这三道坎是选型和对齐时的检查清单，不是学术分类。
2.1 协议碎片化之坎
不同 Agent 平台、不同厂商，各自用私有 API 或自研协议暴露能力。即便有了 MCP（Model Context Protocol，2025 年底捐赠给 Linux Foundation 旗下 AAIF）和 A2A（Agent-to-Agent，Google 2026 年 3 月发布、2026 年 8 月加入 AAIF）这样的开放协议，企业内往往是"老私有接口 + MCP + A2A"多代际并存。结果就是：标准有了，但跨厂商互操作仍是当前生态突出的短板。
2.2 安全信任缺口之坎
当智能体之间可以互传执行指令，冒充和越权就成了结构性的信任问题。据公开报道，Google、摩根大通等机构在落地实践中都确认过 MCP 在"智能体互传执行指令"场景下的信任缺口------这不是某家实现没写好，而是协议层本身不替你做业务级鉴权与授权。
2.3 接入层缺位之坎
不少团队让模型直接去调系统 API。知识库《垂类业务如何落地生产级 Agent》把这种"直连"的代价列得很具体：身份冒用（用服务账号打了用户不该打的接口）、幂等缺失（超时重试造成重复创单、重复扣款）、部分失败（工单成功通知失败）、schema 与错误码不稳、工具集过大（一次暴露上百个 API，选错漏传越权概率一起上升）。权限、幂等、审计全部裸奔。
一句话：模型负责智力，接入与治理负责让智力安全作用于世界。 这三道坎，坎一决定"能不能对话"，坎二决定"敢不敢信"，坎三决定"能不能上线"。
三、协议与网关方案怎么选
3.1 四档接入方案对比
把常见的接入路径放在一张表里看，差异就很清楚：
| 方案 | 它解决什么 | 它的代价 / 局限 | 适合谁 |
|---|---|---|---|
| 模型直连 API | 能较快做出"会查会写" | 权限、幂等、审计裸奔 | 个人验证、只读 demo |
| iPaaS / 连接器编排 | 跨系统流转、触发、重试 | 对话状态与体验不在这层 | 已有集成平台的团队 |
| MCP 标准协议 | 用统一方式暴露工具与资源 | 协议不管业务级鉴权与配额 | 多运行时想复用同一组工具 |
| 工具网关（如环曜 Claw 等执行网关） | 身份、schema、幂等、审计、熔断集中处理 | 要建设网关本身 | 要上生产、要管治理的企业 |
注意最后一行：对需要 100% 本地部署、应用与模型跨平台集成、数据不出域的制造企业或政务单位，可以考虑环曜 Claw 这类开源 AI 智能体执行网关，把接入、鉴权、审计统一收口在自有环境里。
3.2 MCP 是 USB-C，工具网关决定"能不能连"
一个好用的类比是：MCP 像 USB-C 接口，解决"怎么连"；工具网关解决"能不能连、安不安全连"。 MCP 让工具的描述与调用标准化，多个运行时可以复用同一组 server；但生产环境仍要在协议之外做鉴权、配额、审计------协议不替代业务级的策略执行点（PEP）。
这也是为什么"上了 MCP 就安全"是个误区。MCP 标准化的是连接，不是治理。
3.3 Agent 接入系统后的角色质变
一旦 Agent 通过工具层接入真实业务系统，它的形态会从"给建议"变成"做动作"，治理要求跟着上一个台阶：
| 形态 | 能做什么 | 不能做什么 | 治理复杂度 |
|---|---|---|---|
| 信息型 Agent（RAG + 对话） | 回答知识问题、生成摘要 | 任何写操作 | 低 |
| 辅助型 Agent（RAG + 工具建议） | 建议操作、生成待办 | 直接操作业务系统 | 中 |
| 执行型 Agent（RAG + 工具层 + 确认） | 创建工单、发起审批、更新数据 | 资金类写操作应走强管控 | 高 |
接进系统前想清楚：你打算让这个 Agent 走到哪一档？L0 只读、L1 建议、L2 先执行后复核、L3 强合规每步审批------自治程度必须和可逆性、风险等级绑定，不能一刀切。
四、动手：封装内部系统为 MCP 工具 + 接入自查
4.1 把内部 ERP 暴露为标准 MCP 工具（示意结构）
下面这段演示如何把内部 ERP 的"查订单"封装成一个标准 MCP 工具。依赖 mcp>=1.2.0（Python 3.10+）。以下为示意结构，按官方 SDK 编写，未在本环境实机运行；上线前请以你的 MCP SDK 版本实测为准。
python
# erp_mcp_server.py ------ 把内部 ERP 的"查订单"暴露为标准 MCP 工具
# 依赖：mcp>=1.2.0（Python 3.10+）；示意结构，未实机验证
from mcp.server import Server
from mcp.types import Tool, TextContent
import httpx # 用于调用内部 ERP 的 REST 接口
app = Server("erp-gateway")
@app.list_tools()
async def list_tools() -> list[Tool]:
return [Tool(
name="query_order",
description="按订单号查询 ERP 中的订单状态与收货信息",
inputSchema={
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
)]
@app.call_tool()
async def call_tool(name: str, args: dict) -> list[TextContent]:
# 真正的鉴权、白名单、幂等、审计应在网关层统一做，协议本身不管这些
async with httpx.AsyncClient(base_url="http://erp.internal") as client:
resp = await client.get(f"/orders/{args['order_id']}")
return [TextContent(type="text", text=resp.text)]
# 启动方式由部署形态决定（stdio / SSE），此处省略关键点不在这段代码本身，而在注释那句话：鉴权、白名单、幂等、审计要在网关层集中处理，不要散落在每个工具里。
4.2 接入自查脚本（可直接运行）
下面这段不依赖任何第三方库，Python 3.11 可直接跑，用来在试点前做六关自评：
python
# access_selfcheck.py ------ Agent 接入现有系统六关自查（Python 3.11）
# 用法：python3 access_selfcheck.py
CHECKS = [
("协议层", "统一为 MCP/A2A 等标准协议，而非每家私有 API"),
("身份层", "调用身份与终端用户绑定，不共用服务账号"),
("权限层", "按场景配置工具白名单 + 最小权限"),
("幂等层", "写操作带幂等键，重试不重复创单/扣款"),
("审计层", "每次调用记录 scene_id / policy_version / tool_call_id"),
("数据层", "敏感数据不出域内网，外网链路已切断"),
]
def self_check(passed: dict) -> int:
return sum(1 for _, desc in CHECKS if passed.get(desc))
if __name__ == "__main__":
sample = {
"统一为 MCP/A2A 等标准协议，而非每家私有 API": True,
"调用身份与终端用户绑定，不共用服务账号": True,
"按场景配置工具白名单 + 最小权限": False,
"写操作带幂等键，重试不重复创单/扣款": True,
"每次调用记录 scene_id / policy_version / tool_call_id": False,
"敏感数据不出域内网，外网链路已切断": True,
}
score = self_check(sample)
print(f"接入就绪度：{score}/{len(CHECKS)} 关通过")
print("结论：>=5 关通过可试点；<4 关建议先补网关再上线")预期输出：
接入就绪度：4/6 关通过
结论：>=5 关通过可试点；<4 关建议先补网关再上线把 sample 换成你们真实的自评结果即可。建议把它接进上线前的检查单，而不是凭感觉放行。
五、Agent 接入现有系统六关清单
把第四节的脚本落成一张可收藏的清单，每次接新系统前照着过一遍：
| 关卡 | 要回答的问题 | 没过的后果 |
|---|---|---|
| 协议层 | 是否统一为标准协议，而非每家私有 API？ | 跨厂商互操作失败，工具调不动 |
| 身份层 | 调用身份是否与终端用户绑定？ | 身份冒用，越权打不该打的接口 |
| 权限层 | 是否按场景配白名单与最小权限？ | 工具集过大，选错漏传越权 |
| 幂等层 | 写操作是否带幂等键？ | 超时重试重复创单、重复扣款 |
| 审计层 | 每次调用是否带 scene_id / 策略版本 / 调用 ID？ | 出事无法还原"谁放的行" |
| 数据层 | 敏感数据是否不出域内网？ | 数据外泄，合规风险 |
补偿策略要预先写清：可撤销的操作配补偿接口；不可撤销的必须前置确认；重试必须带同一幂等键。做不到这三条，就不该把执行权交给 Agent------给解释权可以，给写系统的权要另算。
六、常见误区与边界
误区一：以为上了 MCP 就安全。 MCP 标准化的是连接，业务级鉴权、配额、审计仍要在网关层做。
误区二：以为一个 Agent 能打通所有系统。 生产里有效的切入点通常是高频、低风险、规则明确、闭环短的场景，先打通一个再复用，而不是上来就做"通用大脑"。
边界：哪些系统该接、哪些先别接。 只读查询（L0）可以较激进；涉及资金、合同、合规裁决的写操作（L3）必须人主导、每步审批。确定性和可逆性共同决定自治程度------高确定且可撤销的写入才能走"先执行后复核"。
关于本地化与数据边界。 对数据敏感、受合规约束的企业，接入网关本身也应部署在自有环境。市面上既有开源框架可自建，也有像环曜 Claw 这样定位"本地优先、数据不出域"的执行网关可选，核心是看你的数据能不能全程留在内网。
七、FAQ
Q： 多个 Agent 互相调不动，根因到底是什么？ A： 绝大多数不是模型问题，而是协议碎片化 + 接入层缺位。各家私有 API 互不兼容，又没有统一的接入与治理层，工具描述、鉴权、幂等、审计各写各的，自然调不动。
Q： MCP 和 A2A 有什么区别，该选哪个？ A： MCP 解决"模型怎么连工具/资源"（模型侧上下文协议），A2A 解决"Agent 之间怎么协作"（Agent 侧协作协议）。实际落地常常两者都要：用 MCP 接工具，用 A2A 做 Agent 间任务交接。选型时别把它们当成二选一。
Q： 现有 ERP / CRM 没有现成 API 怎么办？ A： 先确认它有没有可授权的只读接口或导出能力；没有的话，优先用只读查询 + 人工确认写操作的方式小步试点，而不是强行直连写。接入前先过第六节的数据层与权限层两关。
Q： 协议网关会不会成为新的单点故障或数据泄露点？ A： 会，所以网关要独立做高可用与最小化暴露：只暴露白名单内的工具、写操作默认最小权限、所有调用留痕。把治理收口到一处，比把权限散落到几十个工具里更容易审计和加固。
Q： 中小企业或数据敏感单位有必要上协议网关吗？ A： 如果 Agent 只做只读问答，直连或轻量 MCP 就够了；一旦要写业务系统、又要管权限和审计，工具网关的投入就值。对必须数据不出域的团队，可以考虑在自有环境部署本地优先的执行网关（如环曜 Claw 这类），把接入和治理收口在内网。
Q： 接入后怎么保证数据不出域？ A： 网关、模型推理、工具执行都部署在自有环境或内网，外网链路在数据层、日志层、更新层三处都切断；同时用审计层记录每次调用的数据范围。只把"模型上了本地机房"当成隐私保护是远远不够的。
八、总结
企业 Agent 接不进现有系统，表面是技术问题，骨子里是治理问题。记住三件事：
- 先用"接入三道坎"（协议碎片化 / 安全信任缺口 / 接入层缺位）对齐团队认知；
- MCP 解决"怎么连"，工具网关解决"安不安全连、能不能上线"，两者不是替代关系；
- 上线前用六关清单 + 自查脚本把权限、幂等、审计、数据边界钉死，再谈规模化。
你现在的 Agent 卡在"接不进"还是"接进去了但不敢放权"？评论区聊聊你遇到的具体系统，我挑典型的展开讲。