Kong AI Gateway 2.2 正式发布：给 MCP、模型与 Agent 花费装上控制面

2026 年 9 月 30 日，Kong 宣布 Kong AI Gateway 2.2 正式可用。按发布稿的表述，这是一个独立平台，提供四项核心能力：统一的 MCP 工具治理、模态感知（modality-aware）的成本管理、身份感知的 AI 策略，以及更广的供应商支持；同时带来新的 AI 原生体验、进阶成本管理与更广的模型覆盖，在 Kong Konnect 中正式可用、无需开启 beta。Kong 的立论值得单独拎出来看：模型、Agent 架构、协议与定价模式正以「周」而非「季度」的速度出现，企业用来治理它们的基础设施与之之间的差距正在拉大。

一、2.2 到底发布了什么

先把事实列清楚。Kong Inc. 在 2026 年 9 月 30 日宣布 Kong AI Gateway 2.2 正式可用，发布稿的副标题概括了四项能力：统一的 MCP 工具治理、模态感知成本管理、身份感知 AI 策略与更广的供应商支持。正文进一步说明它带来新的 AI 原生用户体验、进阶成本管理与更广的模型支持，并且在 Kong Konnect（Kong 的 AI Connectivity Platform）中正式可用、无需开启 beta。Kong 高级副总裁（产品）Reza Shafii 在发布稿中的表述点出了这套东西的定位：Agentic AI 的承诺不只在于 Agent 能做什么，更在于企业能否有把握地把它投入工作。

# What Kong announced on 2026-09-30: AI Gateway 2.2 is generally
# available in Kong Konnect, with no beta enablement required. The
# announcement frames it as a standalone platform providing four
# headline capabilities.

AI_GATEWAY_2_2 = {
    "release": "Kong AI Gateway 2.2",
    "status": "GA in Kong Konnect (no beta enablement)",
    "highlights": [
        "unified MCP tool governance",
        "modality-aware cost management",
        "identity-aware AI policies",
        "expanded provider support",
    ],
    "also": ["new AI-native user experience", "broader model support"],
}

治理不能再只覆盖栈里的某一个部位

二、为什么治理要从「某一层」变成「一层平台」

Kong 的论证建立在一个速度差上。它的原话是：AI 的发展速度超过了传统基础设施——新模型、Agent 架构、协议与定价模式以周为单位出现，而不是季度，这造成了 AI 创新速度与企业赖以治理它的基础设施之间不断扩大的差距。当 AI 连接横跨模型、Agent、智能工具与上下文，并且散布在越来越多样化的环境中时，把治理局限在栈的某一个部位就不可能成立。Kong 给出的解法是让 AI 拥有自己的平台与发布节奏，从而企业可以在不牺牲安全、合规、成本控制、韧性与可见性的前提下采用新东西。这句话里隐含了一个很实用的判断标准：如果一个治理方案必须跟上模型发布的节奏才算有效，那它就不能挂在一个季度发版的系统上。

# The rationale, in Kong's own words: new models, agent architectures,
# protocols and pricing models emerge in weeks rather than quarters,
# creating a growing gap between the pace of AI innovation and the
# infrastructure enterprises rely on to govern it.

def governance_coverage(ai_surfaces, governed_surfaces):
    """Governance limited to one part of the stack leaves the rest
    unaccounted for -- and AI connectivity spans models, agents,
    intelligent tools and context."""
    return {
        "covered":   [s for s in ai_surfaces if s in governed_surfaces],
        "uncovered": [s for s in ai_surfaces if s not in governed_surfaces],
    }

AI_SURFACES = ["models", "agents", "intelligent_tools", "context"]

三、统一的 MCP 工具治理：颗粒度才是答案

「统一」这个词容易掩盖真实差异，所以评估 MCP 工具治理时应该问的是颗粒度。第一，能不能枚举一个 MCP 服务器暴露的完整工具目录——如果连清单都拿不到，后面的策略都无从谈起。第二，能不能限制某个调用方「看到」哪些工具，而不仅仅是拒绝它的「调用」；这两者的成本差异很大，因为只要工具的 schema 进了提示词，token 就已经花掉了。第三，授权是按工具粒度，还是服务器级全有全无。第四，工具调用有没有连带调用方身份与结果一起记录。第五，能不能在不影响其他工具的前提下单独撤销某一个工具。这五个问题答不上来，「统一治理」就还只是仪表盘。

# Unified MCP tool governance is the capability to test hardest,
# because an MCP server is where tool inventory and authority collide.
# The questions that decide whether "unified" is real:

MCP_GOVERNANCE_QUESTIONS = [
    "Can I enumerate the full tool catalogue a server exposes?",
    "Can I restrict which tools a given caller sees, not just calls?",
    "Is authorisation per-tool, or all-or-nothing at the server?",
    "Are tool invocations logged with caller identity and outcome?",
    "Can I revoke one tool without disturbing the rest?",
]

def coverage_score(answers):
    return sum(1 for a in answers if a) / len(MCP_GOVERNANCE_QUESTIONS)

把 MCP、模型与 A2A 流量放在同一处治理

四、模态感知成本管理：为什么一个总额不够用

成本管理这块的要点在「模态感知」四个字上。价格从来不是一个数字：文本、图像、音频与视频的计费方式各不相同，输入 token 与输出 token 的定价也不同，缓存命中的 token 又是另一套价格；再叠加模型家族、供应商、租户与调用方的差异，一个混合总额几乎无法行动。可用的成本管理应该能把成本按可解释的维度拆开——输入 token、输出 token、缓存 token、模态、模型家族、供应商、租户、调用方——然后把这些桶按金额排序。这样财务拿到的是一份能解释的账单，团队拿到的是一份能优化的清单。Kong 把成本管理列为 2.2 的核心能力之一，正是因为它认为「能不能管住经济性」决定了 Agentic AI 能不能在企业里跑起来。

# Modality-aware cost management matters because price is not a single
# number: text, image, audio and video are billed differently, and so
# are input versus output tokens. A gateway that reports one blended
# figure cannot tell you which workload got expensive.

COST_DIMENSIONS = ["input_tokens", "output_tokens", "cached_tokens",
                   "modality", "model_family", "provider", "tenant", "caller"]

def explainable_invoice(cost_rows, by):
    """Hand finance a breakdown, not a total."""
    buckets = {}
    for row in cost_rows:
        buckets.setdefault(row[by], 0)
        buckets[row[by]] += row.cost
    return dict(sorted(buckets.items(), key=lambda kv: -kv[1]))

五、身份感知 AI 策略：让前两项变得可审计

身份感知是让治理闭环的那一环。一条策略只有在事后能回答三个问题时才算有用：谁发起了这次调用——是人类身份还是 Agent 身份；用了什么——哪个工具、哪个模型、哪个模型版本、什么权限范围；以及依据哪条策略放行、是否发生过人工覆盖。如果这三个问题需要工程师翻日志、逐个系统拼凑才能回答，那这套治理在出事故时是无效的。Shafii 的表述把这件事和商业价值直接挂钩：企业要有把握地把 Agent 投入工作，前提是能看清正在发生什么、能控制 Agent 访问与执行什么、并能管理随之而来的风险与经济性。

# Identity-aware policies are the part that makes the rest auditable.
# A policy is only useful if you can answer three questions about it
# after the fact -- without asking an engineer to reconstruct them.

AUDIT_TRIO = {
    "who":  "which human or agent identity initiated this call?",
    "what": "which tool, model, model version and scope was used?",
    "why":  "which policy allowed it, and was it overridden?",
}

def on_policy_violation(event):
    return {
        "action":   "block or escalate per policy",   # decide before launch
        "record":   {"identity": event.who, "surface": event.what,
                     "policy": event.matched_policy},
        "owner":    "named human owner for every long-running agent",
    }

谁在调用、调用了什么、花了多少

六、标准化之前的评估清单

如果你在考虑把一家网关作为所有 AI 流量的策略点，先做三项压力测试。第一，用最脏的那个 MCP 服务器试——工具一大堆、权限混乱、有些工具多年没人动过，看治理能力在真实目录上是否还成立。第二，要求一份可解释的账单——不是总额，而是按模态、模型家族、租户与调用方拆开的明细，并且要求它能对齐你已有的财务口径。第三，找一条长时运行的 Agent，追问三个事后问题：谁、做了什么、依据哪条策略。另外别忘了反向问题：Kong 自己在发布稿里强调 AI 需要独立的平台与发布节奏，那么你在选型时也应该问对方，上一次能力发布之间隔了多久，以及下一次是什么时候。