Google ADK+AWS EKS跨云组队|amazon|aws|python|服务器|电子表格|知名企业|调用|谷歌|跨云组队

2024年Q3，一个三人工程师小组在GitHub上开源了一套工具链：用Google的Agent Development Kit（ADK，智能体开发套件）调用Gemini大模型，部署在AWS的EKS（Elastic Kubernetes Service，弹性Kubernetes服务）上，最终产出一个能自动生成多格漫画的跨云多智能体系统。项目上线两周，Star数突破1200。

这套组合最刁钻的地方在于：它把两家云厂商的拳头产品串成了闭环，却没用任何"官方集成方案"。

从"各自为战"到"跨云搭积木"

传统上，Google ADK的示例代码清一色跑在Google Cloud Run或Vertex AI上；AWS EKS的教程则默认你用Amazon Bedrock调模型。这个项目的作者Bill，Google Developer Experts（GDE，谷歌开发者专家）成员，偏要反着来。

他的逻辑很直接：客户的数据在AWS，团队熟悉EKS的运维体系，但Gemini 3的图文生成能力确实比同价位竞品稳。与其等两家签合作协议，不如自己架桥。

具体架构分三层：ADK作为智能体编排层，负责把"生成四格漫画"拆解为脚本、分镜、上色、排版四个子任务；Gemini 3通过MCP（Model Context Protocol，模型上下文协议）stdio接口提供多模态输出；EKS则托管整个服务，利用Fargate实现无服务器扩缩容。Bill在文档里写了一句自嘲："这不是最佳实践，这是能跑起来的实践。"

MCP：被低估的"万能转接头"

项目里最关键却最少被讨论的部分，是MCP协议的使用。这个由Anthropic开源的标准，本意是让AI助手安全地调用本地工具——比如读取你的代码库、操作数据库。

Bill团队把它用成了跨云信使。ADK智能体通过MCP stdio服务器与Gemini交互，数据流完全不经过Google Cloud的托管端点，直接走AWS VPC内的私有链路。这意味着：企业客户可以把漫画生成服务架在自家AWS账户里，模型推理却调用Google的API，合规审计时只需解释"我们调了个外部HTTP接口"，而非"我们把数据搬到了另一家云"。

Python代码刻意保持极简。Bill在README里强调：拒绝任何"为了演示而演示"的装饰性代码，核心MCP服务器不到150行，依赖仅`google-adk`和`mcp`两个库。"市面上90%的Python MCP示例都是圣诞树，亮闪闪但搬不动。我们要的是螺丝刀。"

Gemini CLI：被忽视的"云原生胶水"

另一个少有人注意的细节是Gemini CLI的部署方式。Google官方推荐本地安装，Bill团队却把它塞进了AWS CloudShell——AWS浏览器内置的临时终端环境。

这一招解决了两个痛点：一是版本一致性，CloudShell的Amazon Linux 2023镜像通过pyenv锁定Python 3.13，nvm锁定Node 20，Docker版本用dvm（Docker Version Manager）固定，彻底告别"我本地能跑"；二是权限穿透，CloudShell自动继承AWS Console的IAM角色，无需额外配置AK/SK密钥。

实测启动命令只有三行：`npm install -g @google/gemini-cli`装CLI，`gemini auth`走OAuth，`gemini /model gemini-3`切到最新模型。终端回显的239.8 MB内存占用，刚好卡在CloudShell的免费额度内。