Colab MCP实战：把本地Agent接到云端Notebook
本地 Coding Agent 有两个很现实的限制：
本机算力有限
不想让不可信代码直接跑在电脑上
Google 已经把 Colab 做成一个 MCP Server：任何兼容 MCP 的 Agent，都可以把 Colab Notebook 当成远程可执行工作区，创建和重排 Cell、写 Python、执行代码、安装依赖，并把结果保存在一个可人工接管的 Notebook Artifact 里。
这比普通“远程执行 Python”更有意思，因为 Notebook 本身同时是：
Code
Execution State
Result
Visualization
Documentation
特别适合数据分析、模型实验和临时计算。
但如果准备把它接进生产 Agent，真正应该关心的不只是 uvx 配置，而是 Workspace 隔离、依赖供应链、Artifact、数据边界和“谁能执行什么”。
最小安装只有几步
本地需要：
Python
git
uv
安装 uv：
pip install uv
MCP 配置可以直接使用：
{
"mcpServers": {
"colab-proxy-mcp": {
"command": "uvx",
"args": [
"git+https://github.com/googlecolab/colab-mcp"
],
"timeout": 30000
}
}
}
然后在浏览器里打开一个 Colab Notebook，让 Agent 执行：
Load the sales dataset,
forecast next month,
and visualize the result.
Agent 可以：
创建 Markdown Cell
创建 Python Cell
安装依赖
执行代码
生成图表
整理 Notebook
为什么 Notebook 比普通 Shell 更适合分析 Agent
Shell Agent 往往得到：
stdout
stderr
files
Notebook 则天然有：
步骤结构
Cell 级代码
中间结果
图表
解释文本
一轮分析完成后，用户可以直接 Review：
第 3 个 Cell 为什么这样清洗？
第 6 个图表用的是什么字段？
它的可解释性比一串终端日志高很多。
但不要把一个 Notebook 当成多个任务的共享沙箱
生产里最危险的做法：
所有 Agent
→ 同一个长期 Notebook
会残留：
变量
DataFrame
文件
环境依赖
凭证
输出
任务 B 很可能读到任务 A 的状态。
更合理：
Run
→ Notebook Workspace
至少做到：
一个高风险 Run 一个独立 Notebook
Notebook Manifest
public record NotebookWorkspace(
String workspaceId,
String runId,
String subjectId,
String tenantId,
String notebookId,
WorkspaceStatus status,
Instant createdAt,
Instant expiresAt) {
}
状态：
CREATED
RUNNING
WAITING_HUMAN
COMPLETED
CLEANING
EXPIRED
Cell 本身应该有类型
不要把 Agent 所有动作都当普通代码。
我会区分：
INPUT
TRANSFORM
ANALYSIS
VISUALIZATION
INSTALL
EXPORT
例如：
{
"cell_id": "cell-18",
"type": "INSTALL",
"source": "!pip install xgboost==3.0.2",
"risk": "MEDIUM"
}
INSTALL 应该走更严格 Policy。
pip install 是真实供应链风险
Google 官方示例允许 Agent 安装 Notebook 基础镜像中不存在的库。
开发环境很好用。
生产里不能默认无限制：
pip install whatever-model-suggests
更安全：
Internal Package Mirror
Allowed Package List
Pinned Version
Hash Validation
例如：
packages:
allow:
pandas: "2.3.1"
matplotlib: "3.10.5"
xgboost: "3.0.2"
deny_unlisted: true
Notebook 的输入数据也必须走 Artifact Registry
不要让 Agent 自己猜路径：
/home/user/data.csv
而是：
artifact://sales/2026-08-23/input.csv
Gateway 负责下载到 Workspace。
public record NotebookInputArtifact(
String artifactId,
String sha256,
long sizeBytes,
DataClass dataClass,
String mountedPath) {
}
Notebook 只看到当前 Run 允许的文件。
不要让 Notebook 直接拥有整个云存储凭证
危险：
GOOGLE_APPLICATION_CREDENTIALS
AWS_SECRET_ACCESS_KEY
直接放在 Notebook Environment。
任何生成代码都可以读取并外传。
更合理：
Agent requests artifact
↓
Gateway checks authority
↓
short-lived URL / proxy stream
↓
Notebook reads file
网络默认也应该收紧
数据分析 Agent 通常不需要访问整个互联网。
可以根据任务给：
NO_NETWORK
PACKAGE_MIRROR_ONLY
ALLOWLIST
FULL_NETWORK
默认从低权限开始。
例如：
network_profile: PACKAGE_MIRROR_ONLY
避免一个数据分析 Prompt Injection 最后变成：
上传内部 CSV 到公网
Colab 的一个巨大优势：用户可以中途接管
Google 强调，Notebook 是一个真实 Artifact，用户可以在任何时候跳进去看状态、检查 Cell 或人工修改。
这特别适合：
Human-in-the-Loop Analysis
例如 Agent 已经做到：
数据清洗完成
异常值策略有两个选择
此时暂停：
Option A: winsorize
Option B: drop
让分析师决定。
但人工修改以后必须让 Agent 知道版本变化
假设用户改了 Cell 5。
Agent 仍然基于旧 Cell 5 继续推理，会产生状态漂移。
所以每个 Cell 应该有：
version
hash
人工修改：
cell-5 v2
Agent 下一步必须刷新 Notebook Snapshot。
Notebook Snapshot
public record NotebookSnapshot(
String notebookId,
long revision,
List cells,
String environmentHash,
Instant capturedAt) {
}
每次重要执行之前检查：
expected revision
==
current revision
不一致则重新读取。
输出也不要只留在 Notebook
最终 Artifact 可以有：
Notebook
CSV
PNG
Model
Report
每个输出都进入 Artifact Registry。
例如：
{
"artifact_id": "forecast-92",
"type": "CSV",
"source_notebook": "nb-18",
"source_revision": 12,
"sha256": "..."
}
这样后续 Workflow 不需要重新解析整个 Notebook。
一个 Agent 生成模型文件时风险更高
例如：
model.pkl
Pickle 不是安全的数据交换格式。
不要在其他服务里直接加载不可信 Pickle。
更推荐：
ONNX
SafeTensors
JSON parameters
或者在同类隔离沙箱中加载。
Notebook 成本也要进入 Run Budget
Agent 可能安装大包、跑 GPU、反复训练。
预算不应该只有 Token。
public record ComputeBudget(
Duration maximumRuntime,
long maximumCpuSeconds,
long maximumGpuSeconds,
long maximumDiskBytes,
BigDecimal maximumCost) {
}
达到限制：
PAUSE / TERMINATE
而不是让 Notebook 一直跑。
一类很常见的死循环：模型不断重新跑重任务
例如：
训练模型
↓
结果不理想
↓
改一个参数
↓
重新训练
↓
继续
所以要限制：
max_expensive_cells
例如：
execution:
max_training_runs: 4
max_cell_runtime: 10m
Cell Cache 可以省很多计算
如果输入、代码和环境都没变：
Cell Output 可以复用
Cache Key：
source_hash
+ input_artifact_hash
+ environment_hash
但有：
time()
random
network
这类非确定性 Cell 不应该默认 Cache。
Environment Hash 很关键
同一代码在：
pandas 2.2
和：
pandas 2.3
可能结果不同。
所以 Notebook Artifact 不能只保存 .ipynb。
还需要：
Python Version
Package Lock
Runtime Image
例如：
{
"python": "3.12.4",
"requirements_lock_hash": "...",
"runtime": "colab-2026-08"
}
“可复现 Notebook”需要再跑一次
Agent 跑完以后，Notebook 很可能依赖当前 Kernel 的隐藏状态。
例如 Cell 顺序：
5
2
7
3
人工看文件却以为从上到下能执行。
所以发布前应该：
Restart Runtime
Run All Top-to-Bottom
只有第二次仍成功，才标记：
REPRODUCIBLE
这是一条非常硬的 Gate。
我会给分析 Notebook 加 6 个发布检查
1. All Cells Run Top-to-Bottom
2. No Hidden Dependency
3. Input Artifacts Versioned
4. Package Versions Locked
5. Output Artifacts Registered
6. No Secrets in Cells / Outputs
任何一项失败：
不能交付为正式分析结果
MCP Tool 的权限同样需要限制
Agent 不应该因为连接了 Colab MCP，就可以控制所有 Notebook。
Discovery 应只暴露：
当前 Run Notebook
而不是用户账户下所有 Notebook。
最小能力可以拆：
notebook.read
notebook.edit
cell.execute
package.install
artifact.export
其中 package.install 和 artifact.export 风险更高。
一个实际的能力 Manifest
capability: colab.cell.execute
risk: medium
resource:
notebook: nb-18
limits:
max_calls: 50
max_runtime: 120s
network: restricted
这比给 Agent 一个：
colab_admin
好得多。
什么场景最适合 Colab MCP
我会优先用在：
数据探索
临时 ETL
可视化
模型原型
Benchmark
Notebook 报告
不太适合直接承担：
长期在线服务
高频生产交易
需要严格低延迟的 API
Notebook 是工作区，不是生产微服务。
从 Notebook 进入生产还要再走一步
例如 Agent 在 Colab 验证了一个预测模型。
正确链路：
Notebook Experiment
↓
Reproducibility Gate
↓
Export Artifact
↓
Model Registry
↓
Offline Eval
↓
Canary
↓
Serving
不要：
Notebook 看起来不错
→ 直接让业务系统调用
Colab MCP 真正有意思的地方，不只是“Agent 可以远程跑 Python”。
它提供的是一个：
可执行
可观察
可人工接管
可保存 Artifact
的云端工作空间。
但一旦从个人实验升级到企业 Agent，必须补上：
Run 隔离
Artifact 权限
依赖供应链
网络策略
计算预算
Notebook 版本
可复现 Gate
否则只是把“在本机乱跑代码”的风险搬到了云端。
真正生产化的目标不是让 Agent 获得更多计算权限，而是让它获得足够完成当前实验、但不会顺手获得整个云环境的权限。
更多企业级 AI 应用、Agent、RAG 与大模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/