Skip to content

智能体系统架构：隔离、集成与治理的综合调研

基于大语言模型（LLM）的智能体系统，即能够利用LLM自主规划并借助外部工具执行多步任务的软件，正迅速从概念验证阶段迈向企业级规模化部署。这些智能体有望将编码、IT运维、数据分析等工作自动化，然而，将其部署于生产环境也带来了在安全性、可靠性及系统集成方面的一系列新挑战。过去半年，业界社区已在几项关键策略上形成共识：为执行不可信操作提供强有力的隔离保障，为工具集成建立标准化协议，并构建能确保智能体行为符合企业策略的治理框架。本调研旨在系统性地回顾近期（约2025年下半年）的相关进展，内容涵盖智能体沙箱架构、模型上下文协议（MCP）等新兴标准、重要的开源项目、行业倡议以及前沿研究成果。本文将聚焦于智能体系统在生产化落地过程中普遍存在的痛点，并探讨最新的解决方案如何应对（或在何种程度上尚未解决）这些核心需求。

1. 企业中的智能体系统架构

一个企业级的智能体系统通常包含多个逻辑层次：（i）一个基于LLM的推理核心，即决定采取何种行动的“智能体”本身；（ii）一套用于调用外部工具或服务的接口，例如API、命令行工具或数据库连接；以及（iii）一个执行环境或运行时（Runtime），在此环境中，智能体所发起的工具操作（如执行代码或shell命令）得以真正执行。围绕这三个核心层次，还部署了用于内存/状态存储、多智能体协同编排以及安全合规监控的辅助组件。其总体架构面临的核心挑战在于系统的高度动态性和开放性：智能体可能在运行时基于不可预测的输入，生成任意代码或工具调用请求。这就要求我们必须采用一种不同于传统确定性服务的全新软件架构范式。

隔离与安全设计。与边界清晰的微服务不同，AI智能体可能会决定执行未经审查的代码或发起改变系统的调用。因此，2025年出现的一个核心架构原则是将智能体的操作进行沙箱化——即在隔离的环境中运行它们，以保护主机系统和网络。例如，开源的Kubernetes智能体沙箱被引入作为一种新的Kubernetes原生概念（Primitive），专用于安全地运行AI智能体。传统的做法是让LLM生成的代码在标准容器中运行，但这依然存在滥用主机内核或其他Pod的风险。与之不同，智能体沙箱采用轻量级虚拟机技术（基于gVisor的用户态内核，并可选支持Kata Containers），在智能体代码与集群节点的操作系统之间建立起一道坚实的安全屏障。这能有效隔绝潜在的恶意或错误代码，防止其干扰其他应用程序或主机本身。沙箱通过一个名为Sandbox的自定义Kubernetes资源（CRD）进行管理，该资源代表一个单一、有状态且长期存在的Pod，具备稳定的身份和持久化存储。这种设计反映了一种理念上的转变：不再将智能体工作负载视为短暂的无状态函数，而是将其看作能够长期保持状态、面向会话的服务。事实上，智能体沙箱支持虚拟机的暂停与恢复、在网络重连时自动恢复会话，甚至能在沙箱间共享内存以提升效率。它还提供了模板和池化机制——SandboxTemplate和SandboxClaim——用于管理预热的沙箱Pod池。预热机制至关重要，因为从零开始启动一个全新的隔离虚拟机可能相当缓慢；通过维护一个随时可用的沙箱池，新智能体会话的启动延迟得以大幅降低（据Google报告，启动延迟不到一秒，相比冷启动沙箱性能提升约90%）。在Google的GKE中，该功能与新的Pod快照功能相结合，能够对运行中的沙箱Pod（包括GPU工作负载）进行检查点和恢复，从而将启动时间从数分钟缩短至几秒钟，并避免了资源闲置造成的浪费。简而言之，沙箱架构是为自主智能体量身打造的：它提供了比普通容器更强的隔离性，同时支持持久化状态和快速弹性伸缩，以适应大规模、长期运行的交互式智能体任务。

有状态单例运行时。传统的云原生应用通常通过在负载均衡器后运行大量无状态实例来实现水平扩展。然而，许多智能体应用场景（如AI编码助手或自主任务调度器）的行为模式更像是一个具备长期记忆（例如，缓存的工具或上下文信息）的、专一的“工作单元”（Worker）。Kubernetes智能体沙箱正是为这类单例、有状态的工作负载而设计的——它不仅适用于AI智能体，也同样适用于需要稳定身份和持久化磁盘状态的CI/CD构建代理或单节点数据库等场景。这反映了业界更广泛的共识：智能体应用需要新的运行时原语，这种原语必须能够在整个会话期间维持状态和身份的连续性（例如，允许智能体基于先前的工具输出逐步构建成果，或维持对某个服务的认证会话）。近期的设计趋势提出了“智能体持久执行”的概念，即具备暂停智能体进程、为其内存或文件系统创建快照，并能在之后恢复乃至迁移它的能力。GKE智能体沙箱与Pod快照功能的结合，正是这一理念的早期现实范例，它有效地将智能体的运行环境视作一个可随时进行检查点操作的虚拟机。我们预计，未来将涌现出更多支持此类特性的编排工具，使得智能体可以在空闲时“休眠”，并在需要时被快速“唤醒”，从而在响应速度和资源利用效率之间取得理想的平衡。

工具接口层。架构的另一个关键组成部分，是智能体如何与外部工具及数据源进行交互。在过去，每个AI助手平台都倾向于发明自己的一套插件系统或API模式（例如OpenAI的插件或LangChain的工具抽象），这导致了严重的生态系统碎片化，开发者必须为每个智能体框架重写工具。进入2025年，业界围绕模型上下文协议（Model Context Protocol, MCP）已形成广泛共识，将其作为AI模型（客户端）与工具或服务（服务器）之间的标准接口。MCP由Anthropic在2024年底发布，到2025年，它已迅速成为“连接AI模型与工具、数据和应用程序的通用标准协议”。从概念上讲，MCP定义了一个基于JSON-RPC的简单客户端-服务器协议。通过该协议，AI智能体可以发现可用的工具、携带参数调用它们，并接收返回的结果或观察数据。这些工具可以是任何东西：数据库查询、文件系统操作、网络请求、代码编译——每一个都由智能体所连接的MCP服务器暴露出来。这种通用协议的强大之处在于，它将原本复杂的M×N（每个模型与每个工具都要单独集成）集成问题，转变为一个M+N的模块化问题。工具开发者只需创建一次MCP服务器，任何兼容的智能体（无论是来自OpenAI、Anthropic还是开源社区）都可以直接使用它。这极大地减少了重复性劳动，并使整个系统更易于维护。一位GitHub工程师将MCP生动地描述为打造“AI领域的USB-C”——一个适用于所有工具的通用端口。在实践中，MCP连接可以是本地的（通过stdio管道）或远程的（通过HTTP+SSE流），并且通常是支持状态的会话，这与需要维护上下文的智能体工具使用场景（例如，保持一个打开的数据库连接，或保留cookie的浏览器会话）完美契合。

编排与多智能体工作流。许多现实世界的任务对于单个智能体而言可能过于复杂，或者可以通过多个专业智能体的协作来更高效地完成。因此，系统架构正在向支持多智能体系统演进，允许智能体之间进行通信与协调。一些旨在标准化智能体间通信的协议应运而生，例如智能体到智能体（A2A）消息传递协议（Google的Agent2Agent协议和Microsoft在其框架中采用的A2A均为典例）。在多智能体协作的设定中，你可能会有一个专职规划的智能体，一个负责执行代码的智能体，以及另一个进行验证的智能体，它们之间可以传递上下文或分配子任务。现代编排框架通常既支持确定性的工作流（其中子任务链是预先定义的，类似于传统的业务流程管理），也支持由LLM驱动的动态编排（其中由智能体自主决定如何分解和分配任务）。例如，微软新近开源的智能体框架就明确地在同一个运行时中支持了两种模式：智能体编排（由LLM驱动，富有创造性和自适应性）和工作流编排（采用固定逻辑，以保证可靠性和可重复性）。该框架于2025年底发布，它将之前的研究原型（如Semantic Kernel的规划器和MSR的AutoGen）整合进一个为企业环境准备就绪的SDK中。它特别强调了与企业系统的连接器、对开放标准（如MCP、A2A、OpenAPI）的支持，以及为满足企业级需求而内置的遥测、审批流程和长期运行任务的持久化能力。这里的核心趋势是，智能体正被视为软件系统中的一等公民组件，人们对它的监控、安全和生命周期管理抱有与微服务或人在回路（Human-in-the-Loop）工作流同等的期望。

总结：现代智能体系统的架构正在围绕一种模块化、分层式的设计理念趋于融合。一个安全的、沙箱化的执行层确保了任何由智能体生成的代码或命令都在一个权限受控的隔离环境中运行。一个标准化的工具接口层（以MCP及类似协议为代表）则将智能体的推理能力与其工具的具体实现解耦，从而催生了一个由可复用能力组成的丰富生态系统。在这些基础之上，编排机制使得将多个智能体和工具组合成更大型的自主工作流成为可能，同时为人类和现有的DevOps流程提供了必要的钩子（hooks），以便在需要时进行监督和干预。在接下来的章节中，我们将更深入地探讨企业级智能体系统的三个关键维度：（a）沙箱与运行时隔离机制，（b）新兴的工具/插件标准及其生态系统，以及（c）在部署这些系统时，组织最为关切的安全、治理和可观测性问题。

2. 智能体的隔离执行环境（沙箱）

运行不受信任或由机器生成的代码向来充满风险——而当下的不同之处在于，借助LLM智能体，代码是在没有人类逐一审查每条命令的情况下即时生成并执行的。如果智能体被恶意诱导或其输出本身不安全，这将为意外的系统故障乃至恶意攻击敞开大门。因此，沙箱化已成为智能体系统的一项基础性要求。在此语境下，“沙箱化”意指将智能体的所有操作（包括代码执行、文件系统写入、网络调用等）严格限制在一个受控的环境中，以确保它无法损害其他进程或访问其权限之外的数据。

表1：研究/开源项目（论文、基准测试、开源运行时）

名称 类别 沙箱/隔离边界 核心能力 参考
Kubernetes SIGs: agent-sandbox 开源（K8s原语/控制器） Kubernetes中的Sandbox CRD（含Template/Claim/WarmPool） 管理"隔离+有状态+单例"工作负载；智能体运行时的标准化API GitHub
AIO Sandbox (agent-infra/sandbox) 开源（一体化环境） 单个Docker容器（集成多工具） 浏览器/Shell/文件/MCP/VSCode Server统一；智能体与开发的统一工作空间 GitHub
阿里巴巴 OpenSandbox 开源（通用沙箱平台） 统一协议+多语言SDK+沙箱运行时 通用沙箱基础，用于命令/文件/代码/浏览器/智能体执行 GitHub
E2B (e2b-dev/E2B) 开源（云沙箱基础设施） 云隔离沙箱（SDK控制） 在云端运行AI生成的代码；Python/JS SDK；用于智能体代码解释器 GitHub
E2B Desktop (e2b-dev/desktop) 开源（虚拟桌面沙箱） 隔离虚拟桌面环境 "计算机使用"智能体：桌面GUI、可定制依赖、每沙箱隔离 GitHub
LLM Sandbox (vndee/llm-sandbox) 开源（轻量级代码沙箱） 容器化隔离（可配置安全策略） 运行LLM生成的代码；可定制安全策略和隔离容器环境 GitHub
SkyPilot Code Sandbox (alex000kim/…) 开源（自托管执行服务） SkyPilot部署+Docker沙箱 自托管、多语言执行、令牌认证、MCP集成（用于智能体工具） GitHub
Microsandbox (zerocore-ai/microsandbox) 开源（微虚拟机执行环境） 硬件隔离的微虚拟机（快速启动） 通过微虚拟机运行不受信任的工作负载；强调隔离强度和启动速度 GitHub
ERA (BinSquare/ERA) 开源（本地微虚拟机沙箱） 本地微虚拟机（"具有容器易用性的微虚拟机"） 在本地运行不受信任/AI生成的代码，具有硬件级隔离 GitHub
SandboxAI (substratusai/sandboxai) 开源（运行时） 隔离沙箱 用于AI生成的Python代码和shell命令的安全执行运行时 GitHub
Python MCP Sandbox (JohanLi233/mcp-sandbox) 开源（MCP服务器） Docker容器隔离 通过MCP向智能体/LLM客户端公开"安全Python执行"工具 GitHub
Code Sandbox MCP (Automata-Labs-team/…) 开源（MCP服务器） Docker容器隔离 MCP服务器：为AI应用提供容器化的安全代码执行环境 GitHub
ToolSandbox (Apple) 研究+开源（评估基准） 具有"有状态工具执行+用户模拟器"的评估沙箱 评估LLM工具使用：状态依赖、多轮对话、动态评估；开源 arXiv
ToolEmu 研究（风险评估框架） LM模拟沙箱（用LM模拟工具执行） 使用LM模拟工具执行以进行可扩展的智能体风险测试；包括自动安全评估器 OpenReview
HAICOSYSTEM 研究+开源（安全评估生态系统） 模块化交互沙箱（人-智能体-工具多轮模拟） 多领域场景模拟和多维风险评估（操作/内容/社会/法律）；代码平台 arXiv
EnterpriseBench 研究（企业环境评估沙箱） 用于企业任务/工具/数据的"评估环境" 在企业场景中评估LLM智能体（任务执行、工具依赖、数据检索）
Managing Linux servers with LLM-based AI agents 研究（实证评估） Docker化的Linux沙箱 让智能体在Docker化的Linux环境中执行服务器任务并评估性能 ScienceDirect
Multi-Programming Language Sandbox for LLMs 研究（多语言执行沙箱） 容器隔离子沙箱 多语言编译/执行隔离（子沙箱与主环境隔离） arXiv
awesome-sandbox (restyler/awesome-sandbox) 开源（生态系统概览/列表） N/A（聚合） 系统化整理的"代码沙箱解决方案"列表和分析；长尾覆盖的良好入口 GitHub

注：要做到对所有相关项目进行详尽无遗的覆盖是不切实际的（特别是考虑到MCP生态系统庞大的长尾效应），因此本表主要收录了主流和具有代表性的项目，并辅以生态系统索引。awesome-sandbox列表可以作为探索更多小众解决方案的绝佳入口。

表2：商业/云服务项目（智能体沙箱/代码沙箱/运行时）

产品/服务 供应商 隔离/执行模型 核心能力 参考
Code Interpreter (Tools) OpenAI 托管的Python沙箱执行 模型编写并运行Python；用于数据分析/编码/数学 OpenAI Platform
Code Interpreter (Assistants on Azure) Microsoft Azure OpenAI 托管的Python沙箱执行 Assistants API在沙箱环境中运行Python（根据Azure文档） Microsoft Learn
E2B (Managed Cloud) E2B 托管的云沙箱（企业智能体云） 沙箱作为智能体运行时；强调并发性和执行基础设施 E2B
Daytona Daytona 托管/平台沙箱基础设施 "AI智能体的有状态基础设施"；超快创建和隔离执行 Daytona
Agent Sandbox Novita AI 托管的智能体运行时 低启动延迟、高并发；代码执行/网络访问/浏览器自动化 Novita AI
Sandboxes (Desktop / GUI) Bunnyshell Firecracker微虚拟机虚拟桌面 用于GUI/计算机使用：隔离桌面、VNC/noVNC、桌面自动化API Bunnyshell
Agent Sandbox on GKE Google Cloud (GKE) 在GKE上部署/运行Agent Sandbox控制器 在集群中隔离执行不受信任的命令；官方安装和使用指南 Google Cloud Documentation
AgentCore "agent sandbox" AWS Bedrock AgentCore 控制台测试沙箱 AWS文档：在智能体沙箱中测试智能体 AWS Documentation
Modal Sandboxes Modal Modal平台沙箱执行单元 官方示例：使用Modal Sandboxes + LangGraph构建代码执行智能体 Modal
Vercel Sandbox Vercel Vercel托管执行环境（Sandbox产品） 用于可扩展执行（流动计算/按活动CPU付费等） Vercel
Docker Sandboxes (Experimental) Docker 本地容器化沙箱（用于编码智能体） Docker官方：使用本地隔离环境运行编码智能体，执行边界 Docker

Kubernetes上的智能体沙箱。由Google牵头并于2025年底作为SIG（特别兴趣小组）项目开源的Kubernetes智能体沙箱，是当前最先进沙箱设计的典范。一个沙箱实例本质上是一个为每个智能体会话启动的微型虚拟机（microVM），并通过标准的Kubernetes API进行管理。其内部利用了gVisor（一个用户空间内核）来拦截系统调用，以及Kata Containers（一种轻量级虚拟机隔离技术）来提供坚固的安全边界。这意味着，即便智能体的代码试图执行恶意的系统调用或利用内核漏洞，它也会被限制在沙箱自身的内核中，该内核在主机上仅拥有极低的权限。此外，在GKE（Google Kubernetes Engine）上，该沙箱默认限制了网络访问（仅允许智能体工具所必需的连接），从而显著降低了智能体扫描内部网络或泄露数据的风险。在2025年的KubeCon北美峰会上，Google展示了他们如何利用gVisor的轻量级特性并行调度数千个沙箱Pod，并通过预热的沙箱池技术，即便在启用强隔离的情况下，也能实现亚秒级的启动延迟。这有效解决了隔离技术通常带来的性能开销问题：通过精心设计的快照/恢复机制和池化策略，可以将额外开销控制在足够低的水平，以满足交互式使用的需求。

从API的角度来看，Sandbox CRD提供了针对长期运行的智能体进程量身定制的功能：您可以指定资源限制、为智能体状态附加持久卷，并使用Kubernetes调度器将沙箱放置在适当的节点上（例如，如果智能体需要GPU，则放在有GPU的节点上）。它还具有生命周期控制，如计划删除（在使用后清理沙箱）和前面提到的暂停/恢复。总的来说，这些功能满足了OWASP关于降低智能体风险的首要建议："系统隔离、访问隔离、权限管理、命令验证和其他保障措施"。事实上，OWASP在其LLM十大风险中增加了一个名为"智能体工具交互操纵"的条目——AI智能体被诱导滥用其工具或执行非预期操作的风险。列出的主要防御措施是在锁定环境中运行智能体，对其可以做什么进行细粒度的权限控制。通过将智能体限制在只有特定Kubernetes API访问（或除其工具之外根本没有访问权限）且没有广泛主机访问的Kubernetes沙箱中，即使智能体被攻破，其破坏范围（爆炸半径）也将非常有限。

本地沙箱解决方案。并非所有组织都使用Kubernetes或需要云规模的多租户环境；对于个人开发者或本地部署场景，一系列更轻量级的沙箱解决方案正在涌现。其中一个值得关注的项目是ERA（由BinSquare开发），它提供了一个本地沙箱环境，用于运行AI生成的代码，并号称能提供“微虚拟机级别的安全保证，同时兼具容器般的易用性”。ERA在底层运用了krunvm（一个基于Firecracker的微虚拟机运行器）等技术，并通过精心编排，使其使用体验与Docker容器非常相似。其核心理念是为开发者提供一种在本地笔记本电脑或CI/CD流水线上快速、安全地测试AI生成脚本的方法，而无需搭建完整的Kubernetes集群。同样，一些框架也开始允许对特定任务使用WebAssembly（Wasm）沙箱，因为Wasm技术能够对运行于其中的代码进行严格的文件和网络访问限制。InfoQ上一篇关于沙箱技术的文章还提到了Lightning AI的LitSandbox和一个名为container-use的库作为替代方案，这些项目可能在探索如何隔离Python执行环境或提供模拟沙箱功能的API包装器。尽管这些方案的标准化程度尚不及Kubernetes智能体沙箱，但它们清晰地表明，业界对于在各种环境中普及和简化沙箱技术抱有广泛的兴趣。

与智能体框架的集成。现代智能体框架开始内置对沙箱的假设。例如，LangChain（最早的智能体库之一）历史上会直接在主机上执行Python代码或bash命令，这在生产环境中显然是危险的。到2025年底，我们看到像LangGraph 1.0（LangChain智能体模块的演进）这样的框架强调"持久和安全"的执行，而CrewAI（另一个开源智能体框架）添加了异步工具执行和监控功能，以便可能插入沙箱运行时。Microsoft的智能体框架与其Azure Foundry服务集成，这可能意味着智能体的代码执行可以路由到托管沙箱（例如隔离的Azure Function或容器实例）——在他们的博客中，他们强调"从一开始就是企业级部署"，包括安全和合规钩子。我们还看到像Aspire的AI智能体隔离模块（由Microsoft提供）这样的新工具，旨在允许开发人员并行运行多个智能体实例而不发生冲突，暗示了端口隔离和MCP代理层。所有这些努力都表明，执行隔离正在成为智能体系统设计的默认部分。不再假设智能体的代码在与主机应用程序相同的进程中运行或具有完整的操作系统权限——相反，智能体在一个受控的、可观察的槽中运行，就像Web浏览器在沙箱进程中运行不受信任的JavaScript一样。

事务性和容错执行。沙箱的一个复杂角度是使执行具有容错性。如果智能体的操作失败或做了不希望的事情，我们能否回滚它？最近的一个研究原型，用于AI编码智能体的容错沙箱，为智能体执行引入了事务性文件系统包装器。它在智能体使用工具期间拦截文件系统写入和系统更改，如果智能体行为不当或检测到策略违规，沙箱可以回滚到干净的快照。在他们的实验中，100%的不安全操作被拦截并回滚，代价是约14.5%的性能开销。然而，他们注意到一个关键限制：这适用于本地状态（文件、进程），但不适用于外部副作用。如果智能体进行了创建资源或发送电子邮件的云API调用，本地回滚不会撤消这些操作。这正在推动关于智能体的分布式事务语义的讨论——将工具API调用序列视为可能需要补偿操作（如果中止）的saga。虽然尚未解决，但这是一个公认的差距（研究人员呼吁为外部工具集成补偿事务，以在多系统级别真正实现沙箱）。目前，沙箱主要确保即使一个步骤出错，智能体的本地环境也可以重置到安全状态。

人类接管和混合沙箱。沙箱设计中一个有趣的发展是支持人在回路的干预，不仅通过是/否批准提示，而是通过完全手动控制沙箱。其想法是，如果智能体到达一个陷入困境或需要特权操作（如输入密码或解决棘手问题）的步骤，人类操作员可以无缝接管智能体的沙箱会话，完成所需操作，然后将控制权交还给AI。研究原型AgentBay体现了这一概念：它提供了一个统一的隔离会话，AI智能体可以通过API控制（例如发出OS命令、浏览器操作），人类可以随时以图形方式远程进入。AgentBay实现了自定义的自适应流协议（ASP），以使这成为可能，延迟非常低。与传统的屏幕共享（RDP/VNC）不同，ASP在发送高级命令和视频帧之间动态切换，根据网络条件和当前由AI还是人类控制进行调整。结果是，即使在较弱的网络上，人类监督者也能获得更流畅的体验。在测试中，允许人类在AgentBay的沙箱中干预使复杂基准测试的任务成功率提高了超过48%，显示了流畅的HITL（人在回路）控制的价值。这种方法直接满足了企业对控制的需求：智能体不再是可能陷入困境的黑箱自动化，而是成为分析师或工程师可以随时介入的协作自动化，而不会破坏隔离或需要重新启动任务。我们预见未来的企业智能体平台将提供"紧急按钮"或智能体辅助模式，为操作员生成安全的VNC/浏览器会话，记录所有操作，然后关闭回到自主模式。

总之，智能体系统中的沙箱已经演变成一种多方面的能力：它不仅关乎保护环境（使用虚拟机、系统调用过滤器、网络限制），还关乎管理智能体的生命周期和状态（持久存储、快照、预热池）以及促进受控交接（暂停/恢复和人类接管）。主要参与者的投资——例如Google将智能体沙箱构建为CNCF项目——表明这些沙箱技术可能会成为云平台的标准基础设施。就像Kubernetes为我们提供了可扩展微服务的原语一样，我们现在正在获得用于云和边缘上安全自主智能体执行的原语。

3. 工具生态系统与标准化：从插件到MCP

在推进运行时沙箱化的同时，业界也已着手解决智能体的工具集成问题。早期的智能体实现通常是硬编码一组工具，或要求开发人员为每个用例编写自定义的“插件”适配器。当企业希望智能体能够访问数十个内部API、数据库和第三方服务时，这种方式便难以为继。在过去六个月中，一股强劲的势头正在涌现，旨在标准化智能体发现和使用工具的方式，从而催生出一个更具互操作性的生态系统。

3.1 模型上下文协议（MCP）和AAIF

模型上下文协议（MCP）已成为该领域的事实标准。如前所述，MCP定义了一种客户端-服务器模型，在该模型中，AI智能体（客户端）可以查询服务器提供的可用工具，使用JSON格式的参数调用这些工具，并接收返回的结果。该协议还涵盖了身份验证握手（例如，通过OAuth流程让智能体代表用户“登录”以使用工具）和流式响应（适用于需要逐步返回结果的工具）等机制。到2025年底，随着Linux基金会旗下智能体AI基金会（AAIF）的成立，MCP的势头得到了进一步巩固。2025年12月，Linux基金会宣布成立AAIF，并将MCP、OpenAI的AGENTS.md以及Block的Goose作为其创始贡献。AAIF的目标是为这些智能体相关标准提供一个中立、开放的治理平台，以避免任何单一公司主导标准的发展。AAIF的启动公告指出，MCP的采用已呈爆炸式增长：已发布的MCP服务器超过10,000个，涵盖了从开发工具到财富500强企业的内部集成等广泛场景，并获得了包括Claude、ChatGPT、GitHub Copilot、Google Gemini、VS Code、Cursor在内的主流AI平台的支持。考虑到MCP直到2024年底才开源，这一成就尤为瞩目——它之所以能引起广泛共鸣，是因为它精准地解决了一个行业痛点：若没有统一标准，每个AI供应商和企业都将陷入重复集成工作的泥潭。通过围绕MCP形成合力，社区实际上就智能体与工具之间的‘通用语言’达成了共识。

从企业角度来看，MCP带来了几个好处：

  • 互操作性：一个工具（例如数据库查询接口）只需作为MCP服务器实现一次，便可被不同的智能体（无论是Anthropic、OpenAI还是自托管的智能体）调用，无需编写任何自定义适配器。这与传统软件中的驱动程序或连接器异曲同工——一次构建，随处可用。
  • 安全性与可审计性：MCP消息是结构化的（JSON格式），通常通过智能体运行时的客户端库进行传输，因此可以被方便地记录和审查。相比于难以拦截的自由格式shell命令，这使得审计智能体对工具的调用行为变得更加容易。该协议还包含一个能力声明步骤（服务器告知客户端其所能执行的操作），该步骤可用于策略检查。此外，它通常要求进行身份验证握手（如OAuth），以便智能体能代表用户获得工具的访问权限，这意味着现有的身份认证系统可以被用来进行访问控制。
  • 模块化与面向未来：正如InfoQ所总结的，MCP将错综复杂的集成网络转变为模块化的架构，从而缓解了“插件疲劳”问题，并使得添加新工具或更换模型变得更加简单。它还创造了一个公平的竞争环境——小型开源项目发布的MCP服务器可以像大型供应商提供的那样易于使用，从而促进了一个充满活力的社区工具生态系统的形成。
  • 中立治理：在AAIF的框架下，AWS、Google、Microsoft、Anthropic和OpenAI等行业巨头得以共聚一堂（它们都被列为白金会员）。这降低了MCP分裂成多个互不兼容的竞争版本的风险；它很可能变得像HTML或SQL一样——成为一个所有人都遵循的基线标准，或许会带有一些各自的扩展。

值得注意的是，MCP正在不断演进，其涵盖范围已超出了“传统的API调用”。近期的扩展包括智能体到智能体（Agent-to-Agent）的消息传递（使得一个智能体可以通过MCP将自身作为工具暴露给其他智能体）和对二进制数据的支持（用于图像和文件传输）。同在AAIF旗下的AGENTS.md标准则对MCP进行了补充，它为软件项目提供了一种向智能体声明如何与其交互的方式。AGENTS.md本质上是一个为AI智能体编写的README文件，放置在代码仓库中，用以描述项目概况、构建/测试工具、关键上下文及相关约束。目前已有超过6万个开源仓库采纳了AGENTS.md来指导编码智能体。通过这一标准化手段，当一个智能体（如GitHub Copilot或Cursor）处理一个新的代码库时，它可以自动读取AGENTS.md文件来理解项目的特定命令（例如如何运行测试），而无需仅仅依赖其通用知识。这不仅减少了错误，也使得代码编写智能体在不同环境下的可靠性得到提升。

MCP工具生态系统。众多公司和开源团队已经为其系统发布了MCP服务器。例如，GitHub发布了官方的GitHub MCP服务器，通过MCP协议暴露其核心操作（如Issues、Pull Requests、仓库内容等）。这使得智能体能够以一种安全的方式执行GitHub操作（例如创建Issue或评论PR）——服务器会强制执行GitHub的API策略和权限范围。同样，我们也能看到用于数据库（SQL工具）、云资源（AWS、Azure的MCP服务器）、信息检索（维基百科、网络搜索）乃至操作系统级任务（存在包装了shell命令或Docker的MCP服务器）的MCP服务器。一个典型的企业可能会运行一套内部MCP服务器：一个用于其工单系统，一个用于客户数据库，另一个用于DevOps（例如我们之前看到的mcp-server-kubernetes用于Kubernetes控制）。通过这种方式，企业可以创建一个经批准的工具目录，供其AI智能体使用。一些公司正在构建MCP网关或注册中心来管理这个目录，我们将在安全部分进一步探讨。

本地优先与离线智能体。尽管MCP通常假定客户端（智能体）通过HTTP与服务器连接，但其设计足够灵活，同样适用于“完全本地”的场景（通过标准输入输出管道进行通信）。由Block贡献给AAIF的Goose框架便被描述为一个“本地优先的AI智能体框架”。Goose利用MCP进行工具扩展，这意味着你可以在笔记本电脑上运行Goose智能体，并且它们可以为本地工具（如访问本地文件系统或应用程序）启动本地MCP服务器，而无需云端连接。这对于那些因数据隐私要求而必须将所有操作都保留在本地或设备上的用例至关重要。这也意味着企业可以打包一个智能体及其工具套件，使其完全在隔离网络中运行（例如，一个用于内部网络诊断的AI智能体，它在没有互联网访问的安全飞地中运行，但通过MCP与内部系统相连）。通过MCP推动标准化并不意味着必须走向云端集中化；恰恰相反，只要遵循协议，它便能促进工具提供方的民主化（无论是开源实现、自托管服务还是其他形式）。

超越MCP：其他标准。尽管MCP目前处于领先地位，但仍有其他值得关注的努力。例如，基于OpenAPI的工具使用：一些智能体框架允许导入任何OpenAPI规范，并能自动从中生成一个“智能体工具”。Microsoft的智能体框架就强调，任何拥有OpenAPI定义的REST API都可以被即时转化为一个工具，由框架负责处理模式解析和安全调用。这与MCP是互补的：我们可以设想MCP服务器自动暴露一个OpenAPI接口，反之亦然。另一个值得关注的概念是能力描述语言——OpenAI的函数调用（Function Calling）规范即是一例，其中模型被告知函数签名，然后输出用于调用的JSON。一些研究人员提议使用更形式化的模式来描述工具的可供性（affordances）。然而，目前看来，MCP似乎正在将这些不同的思路融合在一起：它提供了一种结构化的方式，让智能体能够查询“我能做什么？”，然后带参数调用一个函数，这本质上就是通过一个通道实现的函数调用。为了避免生态系统的再次分裂，我们很可能会看到OpenAPI、JSON-RPC以及其他新兴标准之间实现对齐或桥接。

本质上，如果说沙箱解决了智能体的“身体”问题，那么MCP则解决了其“手臂和腿”的问题。它标准化了智能体如何与外部世界进行交互。这是智能体在企业环境中发挥实际作用的必要步骤，因为没有任何一个供应商能够提供所有必需的集成。通过降低集成门槛，公司可以利用远比以往更广泛的工具集。然而，正如我们接下来将要讨论的，赋予AI智能体访问众多工具的能力，同时也扩大了攻击面并增加了治理负担——因此，标准化与安全必须齐头并进。

4. 智能体系统的安全、治理和信任

在企业中部署自主智能体，一个固有的问题随之而来：我们如何信任它们？与确定性的脚本不同，AI智能体可能会产生出人意料的操作，并且可能以我们无法完全预测的方式受到外部输入（或恶意攻击者）的影响。在过去几个月中，业界和研究人员的一个核心焦点便是努力缩小“信任差距”——确保智能体只执行其应当执行的任务，不多也不少，或者至少我们能在其行为不当时及时检测并采取缓解措施。为此，浮现出了几个关键主题：权限与策略模型、工具的供应链安全、提示注入防御、审计与可观测性，以及故障安全机制。接下来，我们将逐一探讨这些主题。

4.1 提示注入和混淆代理问题

提示注入——即通过精心构造的外部输入来操纵智能体的LLM，使其忽略原有指令或执行非预期操作——已被证明是一种非常现实的威胁。在智能体工具的场景下，提示注入可能演变成一种“混淆代理人”（Confused Deputy）攻击：LLM作为拥有权限（能够访问工具）的“代理人”，被攻击者通过恶意构造的输入（即提示）所利用，从而滥用这些权限。一个简单的例子是：攻击者在用户提供的电子邮件中嵌入一条恶意命令，而智能体则会忠实地使用其shell工具来执行该命令。真实的攻击事件和概念验证（PoC）表明，这并不仅仅是理论上的威胁。业界（例如在Hacker News的讨论中）普遍的共识是，提示注入类似于Web应用中的跨站脚本（XSS）攻击——无法仅通过输入清洗就完全根除，因为要约束模型对任意文本的行为是极其困难的。因此，单纯依赖基于提示的防护措施（例如，“如果用户指示执行恶意操作，则不予执行”）是相当脆弱的。

更强健的方法是采用结构性防御：即使智能体被欺骗，也要从根本上限制其能力范围。这意味着在工具调用层强制执行策略。例如，如果智能体试图运行一个shell命令，应有策略禁止其执行rm -rf或向敏感端点发起网络调用。如果它使用数据库工具，必须确保它无法查询其权限之外的数据表。这正是沙箱与权限模型相互交叠之处。在沙箱中，你可以拦截系统调用——例如，阻止在特定目录之外的文件写入，或将网络访问权限限制在白名单域内。借助MCP，你可以为每个工具实施允许/拒绝策略——例如，禁止某些API调用的组合，或检测参数是否可疑（比如一个试图转储所有用户数据的SQL查询）。

一个具体的进展是名为AgentBound的研究框架，它提议为MCP服务器附加一个声明式的访问控制策略。受Android应用权限模型的启发，AgentBound允许工具声明其所需的主机资源（如文件、网络目标等），并由管理员来批准或限制这些请求。在运行时，一个强制执行引擎会监控智能体的调用，并阻止任何超出授权范围的操作。令人印象深刻的是，AgentBound的评估结果显示，它能从代码中为296个流行的MCP服务器自动生成策略，准确率高达约80.9%，并且能够以可忽略的性能开销阻止大多数恶意操作。这表明，智能化工具可以帮助减轻策略管理的负担：我们可以通过分析一个工具的代码来推断出“此工具应当只需要访问X API或Y文件”，然后将此推断用作一条沙箱规则。

另一道防线是模式验证（Schema Validation）。许多工具期望接收特定格式的输入（例如，具有特定字段的JSON，或在特定范围内的数字）。如果智能体生成的输出偏离了预期格式，这可能表明发生了提示注入或模型自身的错误。在执行操作前严格验证智能体输出的格式，可以捕获一部分攻击或错误。事实上，OWASP关于命令验证的建议也属于此范畴——例如，如果一个智能体试图执行sudo rm -rf /，沙箱或工具包装器应当能够检测到并拒绝该操作。

业界普遍认为，提示注入无法仅在模型层面完全解决，因此企业系统正在通过分层部署运行时控制来加强防御。一些探索甚至走向了双模型设置：一个模型负责生成计划或解释用户输入，但它本身不接触任何工具（因此没有权限）；然后，一个独立的“执行模型”被启用工具，但其接收的输入受到更严格的约束（仅包含经过清洗的计划）。这类似于将策略决策与策略执行相分离。然而，这种方法尚处于起步阶段——研究人员指出，要确保两个模型保持同步，并防止第一个模型无意中成为传递恶意指令的隐蔽通道，是相当棘手的。

4.2 工具供应链安全

随着MCP工具生态系统的发展，一类新的安全问题也随之浮现：工具本身可能存在漏洞，甚至可能是恶意的。我们实际上已将系统的“攻击面”扩展到了任何实现工具API的代码。2025年7月，安全研究人员披露了在一些由社区开发的MCP服务器中存在的关键缺陷：

  • Kubernetes的MCP服务器（一个允许智能体在集群上运行kubectl命令的MCP工具）存在命令注入漏洞。它在构造shell命令时未对用户输入进行充分的净化处理，导致攻击者可以嵌入|或&&等字符，在主机上执行任意命令。不仅如此，该安全公告还演示了一条提示注入攻击链：如果一个智能体被要求读取一个Pod的日志（而该日志中包含了恶意指令），智能体随后可能会用这些恶意指令调用存在漏洞的kubectl工具，最终导致在MCP服务器主机上的远程代码执行（RCE）。这是一个生动的例子，揭示了一个看似无害的高级任务（读取日志）如何因工具实现中的薄弱环节而层层传递，最终演变成一次彻底的系统沦陷。它深刻地表明，智能体的安全性取决于其工具库中最薄弱的一环。
  • 另一份针对mcp-package-docs（一个用于读取软件包文档的工具）的安全公告也指出了类似的shell注入问题。本质上，许多早期的工具都天真地对字符串使用了exec()函数，这种做法在任何软件开发场景中都早已被公认为极度危险。
  • AI编码助手Cursor发现了一种更为隐蔽的利用方式：智能体可能被诱骗将一个恶意的MCP服务器配置写入磁盘（实际上相当于“安装”了一个新工具），该工具随后会被加载和执行，从而让攻击者在系统上获得代码执行权限。作为应对，Cursor不得不禁止智能体向特定的配置目录进行写操作。

这些事件凸显了供应链风险：当你从NPM或pip安装一个MCP服务器时，你如何确信它是安全的？它的某个依赖项是否可能被劫持用于窃取数据？传统的供应链最佳实践——如代码签名、审查维护者、进行漏洞扫描——在这里完全适用。但除此之外，智能体工具使用的动态性也要求我们进行新的思考。例如，智能体可能会在运行时从某个地方获取工具的定义（schema）——而这个通道本身就可能被攻破（例如，一个恶意的工具列表谎报其功能）。为了应对这一问题，社区正在讨论建立带有验证机制的工具注册中心。想象一个MCP工具的“应用商店”，其中每个工具都经过审查、沙箱化处理并附有加密签名。Linux基金会的AAIF可能会在托管一个全球性的注册中心方面发挥作用，或者也可能出现特定于供应商的注册中心。

一些研究人员呼吁为智能体工具引入透明度日志和“软件物料清单”（SBOM）方法。例如，企业可能希望记录智能体使用过的每一个工具版本，这样一来，如果某个工具日后被发现是恶意的，他们便可以审计过去的智能体运行记录。他们还希望确保当前运行的工具代码与经过审计的代码完全一致。这类似于现代浏览器处理扩展的方式：采用严格的签名和审查流程。

在防御方面，一个思路是进行动态工具审查——在智能体使用一个新工具之前，先在测试模式下用已知的良性输入运行该工具，观察其行为是否符合预期；或者在一个带有插桩监控的“影子沙箱”中运行它，以检测任何意外行为。这类似于应用商店的审查过程，但有可能是自动化并在运行时进行的。目前，这仍是一个开放的研究问题；我们尚未看到完整的实现，但在文献中它已被确定为一种必要的控制手段。

总而言之，保护工具生态系统既需要预防性措施（例如，工具开发者遵循安全编码实践，自动扫描代码中是否存在诸如对输入使用execSync之类的危险模式），也需要缓解性措施（例如，以最小权限运行工具——一个只需要读取数据库的工具不应该同时拥有操作系统的写权限）。最小权限原则应当贯穿于每一个层面：智能体只能访问特定的工具，而工具也只能访问特定的系统资源。在实践中要实现这一点，意味着需要将用户的身份和意图贯穿始终：例如，如果一个智能体是代表Alice行事，那么数据库工具就应该在Alice的凭证下或一个拥有其相应权限的角色下运行，而不是以超级用户的身份。这正是企业身份与访问管理（IAM）集成至关重要的领域——将人类用户的身份映射到智能体被允许执行的操作上。近期的工作正在探索如何以一种细粒度的方式将企业的SSO/OAuth令牌整合到智能体会话中，从而防止智能体将其权限提升到超出用户通过常规应用程序所能拥有的范围。

4.3 监控、审计和策略执行

由于AI系统的非确定性及其非结构化的输出，实现其可观测性是出了名的困难。但对于企业环境中的智能体而言，可观测性是不可或缺的。运维人员需要能够清晰地回答这些问题：“智能体采取了怎样的步骤序列？它为何做出某一特定决策？调用了哪些工具，参数是什么？是否发生了任何异常情况？”为此，智能体平台正在集成广泛的日志记录与追踪能力：

  • 结构化追踪：业界正推动使用OpenTelemetry等标准来追踪智能体的执行过程，就像追踪任何微服务调用图一样。智能体的每一个动作（例如，“使用参数Y调用了工具X，并得到结果Z”）都可以成为追踪链路中的一个跨度（span）。这使得现有的APM（应用性能监控）工具能够被用来可视化智能体的工作流。一些商业平台现在已经能够实时展示智能体推理和工具使用的分步追踪信息（通常被称为“智能体控制台”或调试面板）。
  • 语义日志记录：除了原始的工具调用日志，人们也对捕获更高级别的事件感兴趣。例如，标记出智能体的计划在执行中途是否发生了剧烈变化（这可能表明它感到了困惑或受到了操纵），或者它是否从某个工具请求了异常大量的数据。记录提示和响应的完整内容可能因隐私问题而变得棘手，但记录其意图和结果是可行的。此外，有人提议采用加密日志记录（通过哈希链将日志串联起来），以确保在进行取证分析时，可以确信日志未被篡改。
  • 合规性审计：在金融或医疗等行业，任何自动化系统都必须具备审计追踪功能以满足合规要求。如果一个智能体修改了客户的记录，我们需要知道是“谁”或“什么”触发了这一行为，以及该行为是否得到了授权。这里的解决方案包括将智能体的行为与一个用户会话相关联，并存储相关的上下文信息（例如，“智能体在时间T，为响应请求R，代表用户Alice执行了操作”）。一些企业将特定的工具限制在手动确认模式下，即智能体的操作必须由人类在仪表板中批准后才能执行（这在执行交易或发送电子邮件等场景中很常见）。如何确保智能体能准确地呈现待批准的操作（而不是隐藏其真实意图），是一个活跃的用户体验（UX）与安全挑战。
  • 策略引擎：企业正开始采用“策略即代码”（Policy-as-Code）系统（如Open Policy Agent或自定义规则引擎）来治理智能体的行为。例如，可以设定一条策略：“除非用户角色为管理员，否则智能体不得在调用生产数据库工具时使用缺少LIMIT子句的WHERE查询。”当智能体试图执行此类查询时，策略引擎可以拦截该请求，并选择阻止它或将其路由以供人工批准。这与MCP网关架构紧密相连，在这种架构中，智能体不是直接连接到工具服务器，而是连接到一个作为代理的网关，由该网关来调解所有调用。微软发布的MCP网关预览版展示了会话持久性（以保持智能体与工具会话的粘性）以及一个用于集中执行身份验证、速率限制等策略的中心点等功能。我们可以预见，这些网关将变得日益复杂，能够实施全组织范围的护栏（例如，禁止任何智能体调用未在审查列表中的外部Web API，以防止数据泄露）。
  • 评估与测试：一种新兴的最佳实践是将智能体视同代码，并为其开发专门的评估套件。在部署智能体更新（无论是新的模型版本还是新的工具）之前，先运行一系列场景（包括正常场景和对抗性场景）来检验其行为。2025年底，多个旨在促进此过程的智能体安全基准被发布。MCP-SafetyBench就是其中之一：它在五个领域（网页浏览、金融分析、代码仓库管理、导航和网络搜索）的真实多步骤任务中测试LLM智能体，同时注入了20种不同类型的攻击（从提示篡改到工具输出操纵）。其结果令人警醒：目前没有任何一个模型能够完全免受基于MCP的攻击——即便是顶级的模型，也有30-48%的任务被成功攻破。他们还发现，任务性能与安全性之间存在负相关关系：那些在完成任务方面能力更强的模型，也往往更容易被利用，推测原因在于它们更倾向于积极遵循任何指令，包括恶意指令。这揭示了一个根本性的“安全-效用”权衡。企业必须仔细校准他们希望智能体达到的“激进”或自主程度。一些企业正在引入可调节的风险设置——例如，一个可以从“保守”（工具较少，确认环节更多）滑动到“激进”（完全自主，风险较高）的滑块。一个名为NRP（归一化风险-性能）的指标被提出来量化这种平衡。最终，持续评估将是关键：随着新攻击手法的发现，需要将它们添加到测试套件中，并确保智能体（及其所有工具和策略）能够有效应对或抵御它们。

4.4 身份、认证和治理

一个虽不那么引人注目但至关重要的方面，是智能体的身份与访问管理（IAM）。当一个智能体执行操作时，它究竟是依据谁的授权？在一个多用户环境中（例如公司内部的AI助手），智能体可能需要在不同时间扮演不同用户的角色。传统的OAuth协议并非为LLM这种实际上是代表用户进行交互式操作的“无头客户端”场景而设计。在过去几个月中，开发者们在将OAuth与MCP集成时遇到了实际的障碍。例如，MCP所采用的OAuth动态客户端注册机制（允许智能体自动注册以使用API）有时会因为企业身份提供商（IdP）严格的URL校验而失败。一些IdP甚至完全不允许动态客户端。在这种情况下，有人呼吁允许为智能体使用静态客户端凭据或进行带外配置。这更多地是一个标准层面的差距而非研究层面的问题——MCP工作组正在努力解决它。

从企业架构的视角来看，许多组织希望智能体能与现有的单点登录（SSO）系统集成。这意味着当一名员工调用智能体时，该智能体应当使用这名员工的OAuth令牌来访问工具。这确保了所有操作都是可归因的，并且严格限制在用户的权限范围之内。对于某些工具而言，这实现起来相对直接（例如，MCP服务器可以简单地要求智能体在调用时提供令牌），但对于另一些工具则相当复杂（例如，服务器上的一个shell工具——如何为每个用户限定其操作范围？）。一些解决方案涉及到使用模拟令牌或限定范围的API密钥：例如，智能体可能持有一个仅允许特定操作并与特定用户绑定的密钥。

“最小权限”原则在此处显得尤为突出：智能体应当只被授予完成任务所必需的最小访问权限，并且理想情况下，这种权限只在需要时才被赋予，且有时间限制。像OAuth令牌交换或短期凭证这样的技术被大力推荐。如果一个智能体是为了执行一个构建任务而被启动的，那么就应该给它一个任务结束后即告过期的临时令牌，这样一来，即使它失控，也无法在事后造成损害。最近的一篇架构论文强调，应将企业身份系统与这些智能体深度集成，以确保所有操作都流经企业常规的IAM检查和日志记录流程。这意味着，举例来说，一个使用Jira工具的智能体在Jira的审计日志中应被记录为“由AI智能体代表Bob执行的操作”。这种透明度对于建立信任至关重要——如果智能体是一个在暗中行事的“黑箱”，用户是不会放心使用它的。

治理的范畴还延伸到了决策层面：决定哪些任务可以完全自动化，哪些需要人类批准；智能体被允许访问哪些数据；以及如何防止数据泄露。一些企业完全禁止智能体访问生产数据，在建立起充分信任之前，仅让它们在经过脱敏处理的或测试数据集上运行。另一些企业则对智能体的输出进行严格监控（例如，扫描智能体即将输出给用户的每一条内容，以检测是否包含敏感数据）。这些是数据丢失预防（DLP）工具与AI技术交叉的领域。未来的一个愿景是，企业智能体平台将集成DLP分类器，如果智能体的响应可能包含公司机密信息，平台会自动进行脱敏处理或向人类操作员发出警报。

最后，我们必须提及用户的信任与接纳问题：除了技术措施，建立对智能体的信任还涉及到用户教育和渐进式的推广策略。许多组织从“只读”智能体起步（它们可以提出操作建议，但不能实际执行），然后随着信心的增长，逐步赋予其更多的自主权。通过提供健全的日志记录和清晰的人工干预路径，用户会更愿意接受智能体的协助。此外，通过将智能体的推理过程（即“思维链”）展示给用户，并为用户提供简便的方式来纠正或停止智能体，也能有效增强信任。本质上，透明度与控制权是应对AI不可预测性的两剂良方。

过去半年所取得的进展——从沙箱隔离到协议标准化，再到新的安全基准——都旨在缩小这一“信任差距”。然而，在能够自信地宣称一个自主智能体像传统的软件微服务一样易于理解和控制之前，仍然存在着诸多开放性挑战（我们将在下一节中讨论）。

5. 开放挑战和未来方向

尽管进展迅速，企业智能体系统仍有未解决的研究问题和实际差距。最后，我们结合近期的技术讨论和学术出版物，重点介绍一些最紧迫的开放性挑战，这些挑战也代表了未来的研究方向：

  • 统一的跨层安全模型：今天我们有碎片——用于身份的OAuth、用于工具访问的MCP范围、用于OS隔离的沙箱——但它们并不总是使用相同的语言。没有一个单一的策略可以说，例如，"用户X的智能体可以从数据库Y读取但不能写入，并且可以运行代码但只使用2个CPU且没有互联网，并且这些条件是经过加密验证的。"需要一个将用户身份、智能体能力、工具权限和沙箱OS权限绑定到一个连贯框架中的综合模型。像AgentBound（受移动应用权限启发）这样的早期提案是一个开始。将来，我们可能会看到一次性编码所有这些的能力令牌——智能体携带一个令牌，沙箱和工具都会检查它，限制它在每个上下文中可以做什么。这种模型的形式化验证（证明智能体不能做X）将大大增强信任。

  • 外部副作用的回滚：如前所述，虽然我们可以在沙箱中回滚文件系统更改，但我们还不能回滚已发送的电子邮件或已进行的交易。开发智能体事务协议或saga是一个开放的挑战。一个想法是要求关键工具提供补偿功能——例如，用于云VM的MCP服务器可以为创建VM提供"撤消"（这将删除它）。然后，智能体规划器可以使用这些在需要时恢复一系列操作。这也与训练LLM或使用二次验证器来决定何时回滚（例如，如果它注意到结果偏离预期状态）有关。如果不解决这个问题，企业将犹豫是否让智能体自主执行不可逆操作。

  • 高级威胁防御：潜在攻击的分类（上下文注入、工具中毒、跨工具数据泄漏等）正在增长。像上下文签名（加密签名工具输出或重要提示以防止篡改）这样的防御已经被建议但没有广泛实施。那里的想法是：智能体只会信任带有签名或哈希的工具输出，因此拦截或修改内容的攻击者（如HTTP工具上的中间人攻击）会失败。同样，将工具彼此隔离（因此一个工具不能直接影响另一个工具，除非通过智能体的审查推理）是一个挑战——目前智能体的内存是所有工具数据的会合点，使其成为一个熔炉，其中一个工具中的恶意输出可以影响涉及另一个工具的决策。

  • 评估的基准测试和标准：社区已经启动了像MCP-SafetyBench和MSB这样的基准，但我们需要持续的评估管道。也许是一个开放的排行榜，智能体开发人员可以提交他们的智能体（具有一组特定的工具和策略）以针对一套场景进行评估，类似于NLP的GLUE或SuperGLUE语言模型基准测试方式。这可以推动安全性方面的竞争和改进。此外，评估应包括成本和延迟指标——一个虽然安全但需要数小时或高昂成本才能完成任务的智能体，在实践中是不可行的。平衡效率和安全性可能会导致自适应风险模式等创新（如果智能体感知到敏感内容，它会切换到更谨慎的方法，动态地用速度换取安全性）。

  • 人类-智能体交互范式：AgentBay的HITL方法是使智能体在现实世界中更可用的一个例子。关于智能体何时以及如何寻求帮助仍有工作要做。如果它问得太频繁，它就没有用；如果它问得太少，它可能会犯不可恢复的错误。找到那个最佳点（也许通过强化学习或用户反馈）是一个持续的领域。此外，关于如何以清晰的方式向用户呈现智能体决策的UI/UX研究将很重要（以便用户可以自信地批准或拒绝操作）。在企业中，这可能意味着将智能体控制集成到现有界面中——例如，在Jira工单中显示"AI智能体建议"，一键批准。

  • 跨组织协作和数据共享：企业智能体通常需要跨孤岛工作——例如，智能体可能在供应商的系统和公司的内部系统之间进行协调。这引发了联合信任的问题：如何让智能体以安全的方式使用两个域的工具？这涉及到诸如标准化智能体如何跨组织边界传达身份以及如何共享审计日志等事项。AAIF隶属于Linux基金会暗示了未来的跨公司标准来解决这个问题，因为智能体不会停留在企业防火墙内。

  • 伦理和合规考虑：除了安全性之外，企业还必须确保智能体遵守法规和道德规范。例如，如果智能体与个人数据交互，则适用隐私法。我们如何审计智能体没有保留或泄露超出允许目的的个人数据？可以采用数据标记和跟踪等技术——标记某些输出包含敏感信息，并防止它们在不允许的上下文中使用。确保决策的AI解释（特别是如果在受监管领域使用）是另一个角度——如果智能体做出影响客户的决策，人们可能需要记录一个理由以符合合规性，考虑到LLM的不透明推理，这是棘手的。

  • 提高模型鲁棒性：最后，核心是LLM本身。正在进行的研究是微调模型以更抗操纵（有利于安全但经常与能力相冲突）。像宪法AI或在工具使用场景上的对抗训练等技术可能会产生本质上拒绝某些危险操作或至少标记不确定性的模型。此外，可以集成用于解析和验证智能体输出的专用模型（例如，检查提议的操作是否看起来安全/合理的二次模型）。OpenAI和其他公司正在探索查看主模型输出的"版主"模型。在智能体中，"策略模型"可能会检查计划和工具使用，并对违反训练时学到的安全模式的任何内容发出红旗。

展望：明年可能会带来智能体生态系统的成熟，类似于2010-2015年云微服务所见证的——处理部署、安全、监控和标准化的工具和最佳实践的爆炸式增长。AAIF的成立是一个强有力的指标，表明行业参与者认为合作是前进的道路；当有这么多利害关系（在安全性和潜在商业价值方面）时，没有人希望有一个碎片化的、狂野西部的环境。我们可能会看到组织中出现AgentOps团队，类似于MLOps，专注于管理和监督智能体舰队。他们将使用仪表板（如GitHub的Agent HQ任务控制）来监督整个企业的智能体活动。就像DevOps为代码开发了护栏和CI/CD一样，AgentOps将为自主AI行为开发护栏和持续评估。

总之，企业智能体系统正在从实验室过渡到现实世界，既带来兴奋（前所未有的自动化能力）也带来谨慎（新颖的故障模式）。沙箱架构和像MCP这样的协议奠定了一个基础，使这些系统比以前更模块化、更可控和更具互操作性。然而，实现与传统软件相当的信任水平需要在权限建模、验证和人类监督集成方面持续创新。过去半年的进步是显著的——一年前大多是科幻小说的东西（多个AI在复杂任务上协作，人类输入最少）现在可证明是可行的。未来几个月可能会看到试点转变为企业的生产部署，每个都教授新的经验教训。通过积极分享这些经验教训并融合开放标准和基准，社区可以加速智能体AI的安全采用。最终目标是一个生态系统，其中AI智能体成为可靠的队友——不知疲倦地自动化繁重工作并导航复杂性——而人类保留对其行为的最终控制和理解。实现这一目标的道路充满挑战，但正如本调研所显示的，基础工作正在迅速建立。

参考文献

Share on Share on