从AGENTS.md到企业级部署：AI Agent的落地挑战

AI Agent正从开发者的笔记本电脑和原型验证阶段，快速进入企业生产环境。但企业级部署意味着安全、合规、可扩展性和可靠性成为硬性门槛——这些恰恰是原型阶段最容易被忽视的维度。VMware Tanzu Platform的Nick Kuhn做客Practical AI播客，与Daniel Whitenack和Chris Benson深入探讨了Agent进入企业后的变与不变。

从文本规范到平台工程

AGENTS.md这类文件代表了一种朴素的Agent配置方式：用自然语言描述Agent的能力边界和行为规范。这在个人项目或小团队中足够用，但拿到企业环境里就远远不够了。

Nick Kuhn的核心观点是，企业不需要为Agent发明一套全新的基础设施范式。过去十几年平台工程积累的经验——构建包、服务网格、身份管理、沙箱隔离——大部分可以直接复用。区别在于，Agent引入了新的交互模式：它们需要调用工具、访问外部数据源、与其他Agent协作，这些都对传统平台能力提出了新要求。

平台工程（Platform Engineering） 是近年来 DevOps 领域的重要演进方向，核心思路是将构建、部署、运维等能力抽象为内部开发者平台（IDP），让应用团队通过自助式接口消费基础设施，而非直接操作底层资源。其典型产物包括构建包（Buildpack）、服务网格（Service Mesh）、统一身份管理等。服务网格如 Istio 通过边车代理统一接管服务间通信，提供服务发现、mTLS 加密、流量治理和可观测性，而不需要业务代码感知；构建包则把「从源码到可运行镜像」的流程标准化封装。对 Agent 而言，复用这些能力意味着它天然获得限流、熔断、灰度发布、链路追踪等能力，而不必为 AI 工作负载重新造轮子。这也是 Nick Kuhn 强调「增量演进」而非「推倒重来」的技术基础。

Agent Build Pack、MCP网关与共享内存

播客中讨论了几个具体的企业级组件：

Agent Build Pack：类似于传统应用的构建包概念，为Agent提供标准化的打包和部署方式。这让Agent能够像普通微服务一样被平台管理和编排，而不是作为特殊存在游离在运维体系之外。

MCP网关：Model Context Protocol正在成为Agent连接外部工具和数据的通用协议。但企业不能放任每个Agent直连各种外部服务，需要一个网关层来统一管理认证、限流、审计和策略执行。这与API网关的思路一脉相承。

共享内存：多个Agent协作时需要共享上下文，但共享内存的设计必须考虑隔离性和一致性。Nick指出，这部分仍在快速演进中，没有银弹方案。

Model Context Protocol（MCP） 由 Anthropic 于 2024 年底开源，用于标准化大模型应用与外部工具、数据源之间的连接方式。它采用客户端-服务器架构：Agent 侧作为 MCP 客户端，工具或数据源以 MCP 服务器形式暴露能力，双方通过 JSON-RPC 交换「工具列表」「资源读取」「提示模板」等结构。MCP 解决的是「每个 Agent 各写一套工具集成代码」的碎片化问题，使工具供应商一次实现即可被任意兼容 Agent 调用。但在企业中，直接让每个 Agent 连接所有 MCP 服务器会带来凭证扩散、调用不可审计、策略无法统一的问题，因此需要 MCP 网关作为中间层，集中处理身份认证、访问策略、速率限制和调用日志，其定位类似 API 网关之于 REST 服务。

身份、沙箱与安全边界

企业部署Agent时，身份管理是最棘手的问题之一。传统应用中，服务身份和用户身份相对清晰。但Agent可能代表用户执行操作，也可能自主决策后调用工具，这使得权限模型变得复杂。

沙箱化是另一个关键议题。Agent执行的代码或调用的工具可能带来安全风险，需要在隔离环境中运行。Nick强调，企业在这方面的容错空间极小——一个Agent的越权操作可能导致数据泄露或合规违规。

这些挑战并非无解。平台工程领域已有的零信任架构、最小权限原则、运行时隔离等技术，经过适配后可以覆盖大部分Agent场景。

零信任（Zero Trust） 架构的核心原则是「永不信任，始终验证」，即不再默认内网可信，每次访问请求都必须经过身份验证和授权。在 Agent 场景下，零信任尤其重要，因为 Agent 可能代表用户发起调用，也可能自主决策后触发工具执行。最小权限原则（Least Privilege） 要求 Agent 只获得完成当前任务所必需的最小权限，并通过短时效令牌（如 OAuth 2.0 的 token exchange 或 SPIFFE 身份）限制其能力范围。运行时沙箱则通过 gVisor、Kata Containers、Firecracker microVM 等技术，将 Agent 执行的代码限制在隔离环境中，即使被提示注入攻击利用，也难以横向移动或窃取宿主机数据。三者结合，构成企业 Agent 安全边界的技术底座。

企业采纳Agent的务实建议

对于正在评估或已经开始采纳Agent的企业，Nick给出了几条务实建议。

从具体场景切入，而非追求通用Agent平台。先找到一两个边界清晰、风险可控的用例，验证技术栈和运维流程，再逐步扩展。

把Agent当作应用来管理。不要因为它是"AI"就给予特殊待遇。版本控制、CI/CD、监控告警、日志审计——这些标准实践同样适用于Agent，甚至更加重要。

重视人机协作的界面设计。企业场景中，Agent很少完全自主运行，通常需要人在关键节点审批或干预。这个协作界面的设计质量，直接影响Agent能否真正被业务团队接受。

对软件开发团队的长期影响

播客最后展望了Agent对企业研发团队的长期影响。一个可能的趋势是，开发者的角色从"写代码"向"定义Agent行为边界和编排多Agent协作"迁移。AGENTS.md这样的规范文件可能演变为更正式的接口定义，成为团队协作的核心工件之一。

平台团队则需要提前思考：当Agent成为企业应用的标准组成部分时，现有的平台能力还有哪些缺口？安全策略、可观测性、成本控制——这些维度的需求会随着Agent数量的增长而放大。

Nick的分享传递了一个清晰信号：Agent的企业化不是推倒重来，而是在现有平台工程基础上做增量演进。那些在微服务、容器化、DevOps上积累深厚的组织，在Agent时代反而更有优势。