跨国深谈← 返回←把智能体当普通应用来部署:企业级 AI 落地的老办法新用途

把智能体当普通应用来部署:企业级 AI 落地的老办法新用途

关联

人物 Daniel Whitenack · Chris Benson · Nick

公司 Tanzu · Cloud Foundry

概念 智能体 · 平台即服务 · buildpack · agents.md · MCP · MCP 网关 · 沙箱 · 记忆 · LLM · 物理隔离

把 AI 智能体部署进一家没有互联网、到处是合规审查的大企业，最大的障碍可能不是技术，而是一个很朴素的思路转变：智能体其实就是又一个应用，用二十年的平台工程经验去管它就行了。说这话的是 Nick,Broadcom Tanzu(VMware 旗下)的技术营销负责人，也是播客 Cloud Foundry Weekly 的主持人，他将出席中西部 AI 峰会。

企业环境到底特殊在哪

Nick 概括企业环境的几个特征：网络受限甚至完全没有互联网——他合作的一些客户是真正的物理隔离(air gap),东西要靠人搬进数据中心；高度监管，要应对 PCI、SOX、HIPAA、FIPS 等一长串合规要求；出错后果严重。他举例：大学毕业实习时做的第一个项目是一家美国杂货零售商的仓库库存系统，一堆 Unix 上的 C 和 shell 脚本，「那东西一宕机，五分钟之内，仓库的卡车就会在州际公路上积压」。企业的规模和容错要求和消费级完全不是一个量级 。

智能体 = 又一个应用

解决企业环境部署痛点的老办法是平台工程。Nick 所在的 Tanzu 平台基于开源项目 Cloud Foundry(比 Kubernetes 和 Docker 还早，2011 年左右从 VMware 起步)，核心理念是：开发者只管推代码，平台负责一切——构建最佳实践的容器、证书、负载均衡、健康监控、应用之间的沙箱隔离、按需绑定数据库等服务。

几条命令(push、bind、scale)就能上生产。企业最看重的是：统一、可重复的模式，这样才能审计和安全加固，让开发者写业务逻辑而不是摆弄基础设施，而不是一百个团队一百种「雪花」配置 。

Nick 的判断是：智能体应该走同一条路。现在的智能体跑在开发者笔记本上，「我一合上盖子，一切都停了」，而企业要的是智能体 24/7 按需可用，嵌在 CI/CD 流水线或电商系统里，而且要和应用、数据尽量同地部署——LLM 离要调用它的微服务有 30 跳远，物理规律叠加出来的延迟在大规模下就是问题。这是很多团队没想到的 。

具体怎么做：Agent Buildpack 与一整套服务

传统做法是推一个编译好的 JAR 文件，平台识别出是 Java 应用就用 Java buildpack——一套构建最佳实践容器的命令集。Nick 团队把这个概念搬到了智能体上：推一个 agents.md(一种人类可读的语言，告诉智能体该做什么、怎么表现，比如「你是资深工程师，监视这个 Jira 队列，审查进来的工单」)，平台一分钟内把它作为容器跑起来，可以随意扩容 。

智能体和应用最大的差异在状态：传统智能体工具(harness)把记忆写成一堆 MD 文件放在文件系统里，但云上的实例是临时的，一关机记忆就「消散到虚空里」。所以 Nick 团队加了共享内存服务，按团队隔离——A 团队的智能体启动时立刻拿到 A 团队的历史：应用架构、做过什么、路线图——于是每次安全审查都能基于上下文做判断 。

工具侧走 MCP(模型上下文协议，一种让应用与 LLM 对话的标准方式)：智能体的工具来自托管在平台上的 MCP 服务器——在 Broadcom,这是开发者唯一被批准的使用方式。再用 **MCP 网关**统一管理和收敛：把几十个 MCP 服务器注册到网关，控制谁能绑定到哪些服务器和工具；支持终端用户凭据一路传递(而不是全公司共用一个通用服务账号)；因为一切流量过网关，天然产生指标——比如发现「某个智能体对删除仓库这个工具调了 20 万次，也许该报警了」。

现场演示的「boss 关卡」：把智能体通过 webhook 连到 GitHub 仓库，提交一个 issue,智能体即时从平台启动、拉代码、做安全审查、把结果推回 issue。每次 Git 提交都可以让安全审查、代码质量、设计审查等智能体在各自的沙箱里即时拉起，彼此不互通、不能上网、不能提权、不接触宿主系统 。

出事怎么办：老牌安全经验直接套用

谈到之前智能体蜂群失控的事件，Nick 的态度很实在：不能保证预防一切，但那些 AI 实验室缺的恰恰是企业界二十年攒下的基本功——加固的沙箱、严格的网络分区(「这是高度监管分区，锁得死死的」，哪怕传统防火墙本来都能挡住很多)、以及真正在工作的监控。他提到事件里「他们的监控没在工作，而且他们并没有真正监控它」。依赖栈、容器、操作系统都要保持打补丁、可靠 。

落地节奏与组织建议

技术上：小步前进，别想一口吃成胖子。对多数企业，拿到一个安全、被批准的 LLM 访问仍是最大障碍——一切要过 AI 委员会，「我们去委员会展示想法，然后等六个月看结果」。批准了就迭代：先跑一个简单智能体，下一步加 MCP 工具自然就明显了 。

组织上：新团队(被压着「到处用 AI」KPI 的那种)要主动办每周办公时间、午餐学习会，给全公司一个开放的起步入口；老团队要主动伸手帮忙，把多年经验带过来。别让新团队发号施令、老团队靠边站，打破筒仓。

Nick 在大会演讲开场问「谁在工作中用过 Cursor、Claude Code 这类工具」，全场举手——采用速度远超想象。对个人，抗拒改变会被贴标签搁置；带着开放心态提出经验，你的关键教训才更可能被新方式采纳 。

展望

Nick 预测企业团队结构和角色会剧变，新角色会被创造出来。但 counters 「AI 抢工作」的恐惧，他自己的体感是：「我比以往任何时候都更忙，因为我有所有这些智能体，它们需要我提供东西」——他在做一直想做却没时间做的事。接下来半年他看好语音交互、人机交互新形态，以及 LLM 之外的机器人方向 。

本集带走

• 智能体当应用管：别因为「智能体」三个字就推翻平台工程——统一可重复的部署模式、平台统一处理安全和合规，直接平移过来用。
• 先解决状态问题：笔记本上的 MD 文件记忆上不了云，要给智能体接共享内存服务(可按团队隔离)，否则实例一停记忆就没了。
• 智能体尽量和应用、数据放近：跨 30 跳网络调 LLM,延迟在大规模下会成灾；物理隔离的客户可以跑本地模型 + 本地 GPU。
• 工具收敛到 MCP 网关：注册、鉴权(终端用户身份透传)、指标监控一站式，异动(如对危险工具的异常调用)能报警。
• 落地靠小步 + 过委员会：拿到一个被批准的 LLM 是第一关，批准一个简单智能体后再迭代加工具。
• 新老团队要互伸之手：新团队办办公时间降低入门门槛，老团队主动带经验进场；个人层面，开放心态比抗拒更有出路。
• 安全回到基本功：加固沙箱、网络分区、真正在跑的监控——失控蜂群事件缺的正是这些。

那个系统一宕机，五分钟之内，仓库的卡车就会在州际公路上积压。
And if that thing went down, like, within five minutes, like, the warehouse was backing up trucks, like, on the interstate.
—— Nick · [13:28]

比如，这一个智能体对「删除仓库」这个工具调了 20 万次——哦，也许我们该对此报警了。
Like, well, this one agent, you know, made 200,000 tool calls to, you know, delete repo. Like, oh, like, maybe we should alert on that.
—— Nick · [26:01]

我还经常看到：组织里一项新技术出现，就建一个新团队，然后那个新团队发号施令。
I think a lot of times too, I see in organizations, like a new technology will come up, and a new team will be built, and that new team will decree.
—— Nick · [34:57]

我现在比以往任何时候都更忙，因为我有所有这些智能体，而它们需要我提供东西。
I am, like, working harder than I ever have because I have all these agents, and they, like, they need stuff from me.
—— Nick · [46:03]