大脱钩：企业能力图
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照要求保留源链接、格式以及代码块，仅翻译正文部分。谢谢！
The Core Question
如果外部 SaaS 产品通过 MCP 暴露功能，为什么内部企业系统不这么做呢？如果它们也这么做了，“our software” 与 “their software” 之间的边界会怎样？
Answer: 边界消失。内部和外部系统在统一的能力图中成为等价节点，这会彻底改变企业对架构、供应商和控制权的思考方式。
大多数关于 MCP 的讨论都聚焦于 AI 代理调用外部服务——你的助理查询你的 CRM，从文档平台拉取数据，触发自动化工具中的工作流。这很有价值，但这只是整体的一半。
同样的模式同样适用于内部系统：
- 你的定制 ERP。
- 你自建的分析管道。
- 那些由平台团队维护的庞大内部工具集合。
这些系统都可以通过相同的协议暴露能力。一旦这样做，就会出现有趣的现象。编排层——无论是路由请求、管理身份验证还是处理授权——不再关心能力的来源。它会路由 get_customer_credit_limit，而不需要知道或在乎该能力是位于内部的 Oracle 实例还是外部的 Experian API。
（Meridian 是一个虚构的 CRM——用来代表你已经在考虑的主流平台。该模式不受供应商限制，适用于所有情况。）
内部和外部成为实现细节。企业看到的是一个统一的能力图，其中一些由内部提供，一些由外部提供，所有能力都可以通过同一接口访问。
对称性的影响
从“自行构建 vs 购买”到“暴露 vs 消费”
传统的 build vs. buy 决策将两种选项相互对立：
| 传统视角 | 能力优先视角 |
|---|---|
| 在内部构建功能（可控但成本高） | 在内部暴露能力 |
| 购买带 UI 的产品（更快但被锁定） | 从外部供应商消费能力 |
集成方式在两种情况下都是相同的——相同的协议、相同的编排层、相同的开发者体验。评估纯粹围绕能力本身展开：成本、质量、可靠性、合规性以及专业化。
- 决策形态变化 – 你不再比较“我们自定义的工具配自定义 UI”与“他们的产品配他们的 UI，我们需要让所有人接受培训”。
- 可逆性提升 – 将外部供应商换成内部实现（或反之）不需要任何架构更改；编排器抽象了来源。
这种可逆性在答案不断变化的环境中是战略金矿。
当前企业现状
- AI 能力出现的速度快于评估周期的处理速度。
- 供应商格局每月变化——收购、转型、新进入者、突发淘汰。
- 六个月前看似合理的自行构建 vs 购买决策，如今显得值得怀疑。
- 随着每个新 AI 工具都需要自己的连接模式，集成复杂度急剧上升。
- 技术债务因当时合理的点对点连接而累积。
每位我交谈的企业架构师都描述了这种混乱的某种版本。局面始终在变动。
基于能力的架构直接响应
| 挑战 | 能力架构响应 |
|---|---|
| AI快速演进 | 在不重新接线消费者的情况下切换能力提供者 |
| 供应商不确定性 | 通过标准接口降低锁定 |
| 构建/购买的灵活性 | 内部和外部能力以相同方式集成 |
| 集成复杂性 | 单一协议，而非 N × M 点对点连接 |
| 技术债务 | 干净的抽象防止集成意大利面式混乱 |
这并不是在为遥远的未来做准备，而是关于在当下生存。使你的架构今天仍然可维护的模式——隔离、明确的契约、标准接口——正是你在答案不断变化的环境中所需要的。
向企业的推介并非“为未来采用此方案”。而是**“现在采用此方案以保持敏捷”。**
Orchestrator：新层
随着企业部署基于能力的架构，一个新层次逐渐成形：Orchestrator。它不仅仅是 API 网关或服务网格，虽然与两者有共同的基因。Orchestrator 负责：
- Capability discovery – 有哪些能力可用？此身份可以访问哪些能力？Orchestrator 维护注册表并处理动态发现。
- Request routing – 当请求进来时，它会被发送到哪里？路由依据能力类型、数据驻留要求、负载、成本优化或自定义规则。
- Authentication & authorization – 此身份能否在此数据上使用这些参数调用此能力？Orchestrator 在内部和外部能力之间一致地执行访问控制。
- Audit & observability – 被调用了什么、何时、由谁、使用了哪些参数、返回了什么结果？Orchestrator 维护合规所需的审计追踪。
- Context management – 会话状态是什么？哪些权限被委派？有哪些约束适用？Orchestrator 在整个交互过程中保持上下文。
系列的其余部分将深入探讨 Orchestrator 的设计模式、治理模型以及真实案例研究。
跨能力调用
编排器成为企业的 能力控制平面 —— 不是能力本身（它们仍然分布在内部系统和外部提供商中），而是使这些能力 可访问、可治理、可组合 的层。
这是一类全新的基础设施。
- 还不完全是集成平台（虽然它处理集成）。
- 还不完全是 AI 框架（虽然它支持 AI）。
- 还不完全是身份管理（虽然它处理身份）。
它是 能力优先企业的粘合组织。
平台团队的新角色
当下
- “我们拥有Meridian实例。”
- “我们维护内部分析平台。”
- “我们运行集成中间件。”
每个系统都是独立的职责，拥有各自的专长。
在能力优先模型中
平台团队成为 能力策展人。他们不再仅仅维护系统，而是 策划能力图谱。他们的职责转变为：
| 原职责 | 新职责 |
|---|---|
| 管理CRM实例 | 确保CRM能力可用、性能良好且得到适当治理——不论来源 |
| 在系统之间构建集成管道 | 定义能力合约并确保提供者（内部或外部）符合要求 |
| 对特定应用界面进行用户培训 | 确保能力可被发现并为AI和人类使用提供完善文档 |
| 为产品谈判供应商合同 | 根据价值评估能力提供者——质量、可靠性、成本、合规性 |
这是一次有意义的提升。平台团队从 系统管理员 转变为 能力经纪人，从 工具维护者 转变为 图谱架构师。
企业 AI 织体
组合包括：
- 统一能力图 – 内部和外部系统是等价节点。
- 编排层 – 发现、路由、授权、审计。
- 上下文渲染 – 按需生成界面。
- AI 代理 – 主要能力消费者。
…构成了全新的东西：企业 AI 织体，使 AI 原生运营成为可能的连接层。
织体支持的场景
-
跨系统操作，无需集成项目
“更新客户记录，调整其信用额度，并通知客户团队” 变成跨 CRM、财务系统和通信平台的单一编排流程——无需自定义集成。
-
优雅的能力替换
当供应商涨价或质量下降时，可在不更改消费者侧的情况下切换到替代方案。编排器重新路由，其他一切保持不变。 -
具备适当企业访问权限的 AI 代理
与其给 AI 工具直接的全部 API 密钥（安全噩梦），或不给任何权限（毫无用处），编排器在提供适当授权和审计的前提下进行中介访问。 -
跨组织边界的联邦能力
合作伙伴、供应商和客户可以将能力暴露到你的图中（配合相应的访问控制），实现组织间工作流，而无需点对点集成。
为什么这不是一个“十年愿景”
每家大型企业都在应对 AI 采纳的挑战，并且遇到相同的障碍：
- 我们如何让 AI 安全地访问我们的系统？
- 我们如何避免构建 N × M 的集成？
- 我们如何在保持治理的同时实现实验性？
基于能力的架构 是在这些压力下浮现的答案。
- MCP（或其演变后的形式）是从混乱中结晶出的标准，提供了实现的可能。
- 编排层是企业在意识到需要系统化管理能力时所构建的。
MCP 当前的形态并不是重点；重点是这种模式行得通，主要参与者已经围绕它达成一致，架构方向已经明朗。MCP 在 2028 年的样子可能与今天不同，但它打开的门不会再关闭。
问题不在于这种架构是否会出现，而在于你的企业是领先还是跟随。
价值存在何处？
如果能力变得标准化且可互换，如果接口成为 短暂的渲染层，并且内部和外部系统成为 图中的等价节点，价值到底寄宿在哪里？
- 二十年来，SaaS 供应商在其数据周围筑起了护城河。
- 你的 CRM 不仅提供 CRM 功能——它还累积了你的机构记忆（互动、交易、模式）。
- 那不是一个功能；它是一个 人质。
能力优先的架构让这种劫持变得可见。当编排器请求客户数据时，能力层以旨在将数据留在供应商墙内的摩擦进行响应，客户便会注意到。
这为企业带来了一个不舒服但可能解放的现实：我们已经推迟了二十年的数据主权问题。
第三部分
系列下一篇:
大脱钩：数据主权修正
能力优先架构如何颠覆 SaaS 权力结构。
支持统计
-
Enterprise AI Agent Adoption
- G2’s August 2025 survey: 57 % of companies have AI agents in production, 22 % in pilot. → G2 2025 年 8 月调查：57 % 的公司已在生产环境中使用 AI 代理，22 % 处于试点阶段。
- PwC research: 79 % of organizations have adopted AI agents to some extent. → PwC 研究：79 % 的组织在某种程度上已采用 AI 代理。
- Source: Deepak Gupta – MCP Enterprise Adoption Guide
-
Multi‑Agent System Designs
- 66.4 % of enterprises use multi‑agent system designs rather than single‑agent approaches, creating demand for coordination protocols. → 66.4 % 的企业使用多代理系统设计而非单一代理方法，导致对协同协议的需求增加。
- Source: Deepak Gupta – MCP Enterprise Adoption Guide
-
Agentic AI Project Challenges
- Gartner predicts > 40 % of agentic AI projects will be canceled by the end of 2027 due to unclear ROI and implementation challenges. → Gartner 预测，由于 ROI 不明确和实施挑战，> 40 % 的代理 AI 项目将在 2027 年底前被取消。
- Source: Gartner Press Release
-
AWS Agentic AI Security Framework
- (Content truncated in original; insert relevant details here when available.) → (原文内容已截断；如有可用细节，请在此处插入。)
All citations are as provided in the original text. → 所有引用均如原文所示。
# AWS Agentic AI Security Scoping Matrix
**Source:** AWS Security Blog
AWS published the *Agentic AI Security Scoping Matrix*, defining four security scopes ranging from basic tool use to fully autonomous systems.
---
# AI Agent Security Concerns
**Source:** CIO – *Autonomous AI Agents = Autonomous Security Risk*
Gartner predicts that **25 % of enterprise breaches will trace back to AI‑agent abuse by 2028**.
---
# MCP and A2A Protocols
**Source:** Koyeb – *A2A and MCP: Start of the AI Agent Protocol Wars?*
An analysis of how **MCP** (tool integration) and Google’s **A2A** (agent‑to‑agent coordination) are positioned as **complementary rather than competing standards**.