4. 扩展 Workspace

指南 3 讲的是用现成手段调教单个 Agent。这一章往外走一步——扩大 Agent 的活动范围，给它接上原本没有的工具和能力。

由浅入深四件事：

1. 自定义命令 ——把常用提示词封装成一键触发的快捷指令
2. Sandbox ——Agent 跑代码用的临时隔离容器（这一节是科普性的，帮你理解产品里看到的”沙箱”面板）
3. MCP 服务 ——给 Agent 接一个独立运行的工具服务
4. 自定义 UI 标签 ——把业务系统的界面嵌进 Workspace（工程团队的话题）

可以按需要往下读，越往下越偏工程。

自定义命令

如果你发现自己反复发同一类提示词给 Agent，就该把它做成命令。打开 Workspace 顶部的 自动化 → 命令，新建一个，命令名形如 /review。

命令类型

• Plain ——固定文本，触发后直接发给 Agent
• Struct ——带变量的模板，触发时弹表单让你填值

Struct 模板用双花括号定义变量：

请帮我 review 仓库 {{REPO}} 的 {{BRANCH}} 分支上最近一次提交。
重点关注：{{FOCUS}}

在对话框里输入 /review 触发时，会弹出 REPO、BRANCH、FOCUS 三个输入框，填好后作为这次对话的初始消息发出去。

命令的内容来源

• Custom ——直接在配置里写
• 资源库 Prompt ——从资源库引用一份共享的 Prompt。Prompt 更新时所有引用方自动同步

后者适合多个 Agent 共用同一套命令。

Sandbox：Agent 跑代码的临时容器

Workspace 自带的运行环境（文件 / 终端）足够 Agent 做日常的文件操作和命令调用，但当 Agent 需要真的跑一段代码——执行一个 Python 脚本验证想法、跑一段 SQL 看结果、临时编译一个工具——它需要一个干净、隔离、可以随时丢弃的环境。这就是 Sandbox。

Sandbox 不是 Workspace 自身的运行环境，而是 Agent 按需创建的另一个容器。每个 sandbox 有自己独立的镜像、CPU、内存和超时时间，用完即销毁，不会污染 Workspace 的文件系统。

谁来创建 sandbox

平台内置了一组 MCP 工具暴露给 Agent，让它可以自主管理 sandbox：

• create_sandbox ——按需创建一个
• sandbox_run_command ——在里面执行命令
• sandbox_read_file / sandbox_write_files ——读写 sandbox 内的文件
• kill_sandbox ——用完销毁

也就是说，Agent 想”跑一段代码看结果”时，它会自己调用这些工具——你不需要做任何配置。Sandbox 是开箱即用的能力，不是需要你启用的扩展。

你能在哪里看到它

Workspace 里有一个 沙箱 面板，列出当前活跃的所有 sandbox：每个的镜像、资源、剩余存活时间。你也可以从这里手动创建一个 sandbox 用于调试——填镜像地址、CPU、内存、超时时间，确认即可。

镜像选择

每次创建 sandbox 时都需要选一个 Docker 镜像。平台预热了两个常见的，秒级启动：

• node:22-bookworm ——Node.js 环境
• python:3.12-bookworm ——Python 环境

也可以填任意 Docker 镜像地址——首次启动需要拉取，之后会被缓存。如果团队有自己的标准镜像（预装某些工具或内部 CLI），可以放在 registry 里供 Agent / 用户使用。

这一节你需要记住的

1. Workspace 自身的运行环境是固定的，无法更换镜像
2. Agent 需要跑代码时，会通过 MCP 工具创建一个 sandbox——按任务选镜像、用完就丢
3. 你不需要额外配置 sandbox，它是平台自带能力
4. 想看 Agent 当前在跑哪些 sandbox，去 Workspace 的 沙箱 面板

MCP 服务

MCP（Model Context Protocol）是一个标准化的协议，让 Agent 调用独立运行的服务所提供的工具。和 Skills 的区别在 Agent 的组成 里讲过：Skills 是文件挂载到容器、Agent 自读自用；MCP 是协议层调用外部服务，适合”接外部系统、跨网络、有自己的状态”。

接入一个现成的 MCP 服务

如果团队已经部署好了一个 MCP 服务，接入只需要在 Agent 配置里填几行：

打开 Agent 配置 → 设置，找到 MCP 配置 区域。配置格式：

{
  "mcpServers": {
    "my-service": {
      "type": "http",
      "url": "http://my-service.internal/mcp"
    }
  }
}

支持两种传输：

类型	适用场景
http	远程 HTTP Streamable 服务
stdio	本地进程，需要 command + args 字段

保存后 Agent 重启，启动时会自动连上，那个服务暴露的所有工具就成了 Agent 可调用的能力。

部署你自己的 MCP 服务

如果你需要给 Agent 一个全新的能力，而且这个能力有自己的数据、状态或后台进程，那就值得做成 MCP 服务。

写一个 MCP 服务本质上是写一个普通后端服务，按 MCP 规范 暴露 tool 接口。常见做法是用官方 SDK：

• TypeScript ——@modelcontextprotocol/sdk
• Python ——mcp

部署之后把它的 URL 填进 Agent 配置，Agent 就能用了。具体的部署细节属于工程话题，超出了本指南的范围——团队里有工程师的话，建议直接和他们对接。

自定义 UI 标签（Mini SaaS）

这一节是工程团队的话题。不写代码的用户可以跳过。

Workspace 顶部的 tab 栏（文件 / 终端 等）是可以扩展的——你可以把一个独立的 web 界面注册成 Workspace 的一个 tab，Agent 干活的同时，用户能直接看到相关业务的实时状态。

这种集成模式叫做 Mini SaaS ——一个独立部署的微服务，通过三个标准化通道集成回平台：

• 管理 UI ——独立的管理界面，维护领域数据（如术语库、规则集、知识库）
• MCP 服务 ——供 Agent 调用的工具接口
• UI 标签 ——嵌入 Workspace 的自定义面板

如果你的业务场景需要这种深度集成，建议联系 Neutree Agent Platform 团队沟通方案。

接下来

到这里 Agent 的”能力面”已经有了完整的扩展手段。下一章讲怎么让 Agent 不止靠人工对话触发 —— 指南 5：触发 Agent。