Zed 2026测评：从AI补全到代理驾驶舱的完整实践

Zed在2026年的定位已经不是“那个启动很快的编辑器”，而是“AI高级用户的代理驾驶舱”。这句话我最近跟好几个做AI应用开发的朋友聊，大家都有同感：别人还在把AI当插件往编辑器里塞，Zed已经把模型路由、上下文管理、Agent执行循环全部做进了编辑器核心。你可以在Zed里同时挂云端模型和本地模型，通过统一代理层把多个Provider路由到同一个入口，再让Agent看着你的项目真实地修改代码、跑命令、读报错。这篇测评就是从我实际使用的角度，把Zed的AI能力从头到尾拆一遍，重点讲那些文档里不太会写、但你自己配一定会踩的东西。

如果你属于下面这几类人，这篇内容对你会有价值：日常重度使用AI编程、手上有多个模型API、需要接本地大模型、想在编辑器里跑Agent而不是只补全代码。如果你只是偶尔让AI写个函数——Zed也能干，但“驾驶舱”的乐趣你可能感受不到，先看完再决定要不要上车。

1. Zed的AI能力全景：从“补全工具”到“代理驾驶舱”

1.1 AI能力的三层架构

我第一次认真看Zed的AI能力，发现它跟传统编辑器最大的区别是：它把AI拆成了三个互不干扰又互相配合的层次。

最底层是补全层。这一层做的事情跟你熟悉的Tab补全一样，光标停在半截函数后面，模型给出后续代码。但Zed的补全不是简单地把整个文件丢给模型，而是基于项目语义索引做了上下文裁剪，只把光标附近的符号、导入、函数签名送上去。实测下来，在大型代码仓库里补全的准确率明显比“全文件硬塞”高，响应速度也快，原因是prompt体积小了。

中间层是行内编辑层。这块对应Zed里的Inline Assistant，选中一段代码按快捷键，模型会直接在当前光标下方给出改后方案，你按Tab确认、按Esc拒绝。这一层非常适合做小范围重构：重命名变量、提取函数、改注释风格。它的特点是“不打断你的心流”，改了之后马上能看diff，不用切窗口，不用创建一个对话上下文。

最上层是Agent层。这才是Zed在2026年真正拉开差距的地方。Agent不是简单问答，而是一个能访问项目文件、能执行终端命令、能自己决定改哪几个文件、跑什么测试的“执行循环”。你在面板里提一个目标，它会规划步骤、读取代码、写改动、跑命令、根据报错修正自己，最后把改动汇总给你。这个过程的透明度很高，每一步它做了什么、为什么那么做，都会清晰地列在会话流里。

这三层结构，决定了Zed不是“给编辑器加了个AI聊天窗”，而是把AI当成了一等公民，嵌入到编码的每一个动作里。后面我会重点讲Agent层，因为这才是“驾驶舱”的核心。

1.2 “代理驾驶舱”到底是什么意思

“代理驾驶舱”这个词，不是我发明的，是Zed社区里流行起来的一个说法。拆开来看，它包含两层意思：代理，和驾驶舱。

先看“驾驶舱”。Zed把AI交互做成了一个中心化的工作台，你用一串快捷键唤出面板，管理所有AI会话、所有模型、所有文件上下文，就像坐在驾驶位上看仪表盘一样，一切可控可见。它不像某些工具那样，AI存在于某一个侧边栏按钮后面，藏得很深。Zed的AI面板默认就有快捷键（macOS上是Cmd+Enter，Windows/Linux上是Ctrl+Enter），召唤速度非常快，而且面板里能同时显示当前模型、上下文文件数、Agent运行状态，一眼就知道现在是什么情况。

再看“代理”。这才是2026年Zed最有意思的部分。Zed本身不绑定某一家模型，它提供了一套Provider机制，让模型接入层完全可插拔。你在配置里可以定义多个模型源：OpenAI兼容接口、Anthropic风格接口、Ollama本地接口、甚至任何符合自定义规则的HTTP服务。而为了让这些模型源“统一对外”，Zed支持把请求先走一个本地代理层，这个代理层可以做鉴权、路由、模型名映射、日志记录。

换句话说，Zed不是直接硬编码连某一个服务，而是允许你把它指向一个“代理网关”。这个网关可以是你用cc-switch或同类工具搭的本地统一入口，也可以是团队内网的一台Nginx反向代理服务器。模型方只看到网关，Zed也只认网关，中间怎么转发、怎么均衡、怎么记录，全都由你掌控。

这两层拼起来，就是一个“代理驾驶舱”：你在驾驶舱里操作，动力系统在代理层里协调。对AI高级用户来说，这种架构的价值是决定性的。因为一旦你手头有多个API、多个本地模型、多个团队环境，你就需要一套统一管理的路由方式，而不是在每一个工具里分别填几千个环境变量。

1.3 谁适合把Zed当AI主力编辑器

我试用过很长时间之后，得出一个结论：Zed的AI能力不是给所有人生效的，它有非常清晰的受众边界。

最合适的人是那些把AI当成“同级协作者”而不是“自动补全者”的开发者。什么意思？就是你会给AI一个任务，让它自己去翻代码、试运行、改错，你只在关键节点做裁决。这种人用Zed的Agent模式，效率提升是几何级的。因为它真的能独立完成一个跨文件的改动，而不是只会生成一段代码让你自己粘。

第二类合适的是多模型重度用户。如果你手头既有云端API，又在本地跑量化模型，还经常需要对比不同模型对同一段代码的改写效果，那么Zed的Provider配置和面板内模型切换功能，会让你舒服很多。你甚至可以给同一个任务挂两个模型，分别跑一遍，然后自己对比结果。

不太适合的，是那种“AI最好别乱动我代码”的保守派。Zed的Agent虽然权限可配置，但它的设计哲学就是“让AI动手”，如果你每次都只想让它给建议、不想让它碰文件，这个编辑器会让你觉得它太主动了。不过这个问题通过调整配置也能解决，后面我会讲怎么收敛Agent的权限。

2. 代理驾驶舱的引擎层：模型接入与代理配置

2.1 官方AI通道：开箱即用的模型列表

新版Zed装完之后，如果直接用AI功能，它会引导你登录账户，然后给你一列官方可选的模型。这个流程对新手很友好，但对高级用户来说，意义不大。因为官方通道往往绑定了固定的模型列表、固定的计费方式，以及固定的请求链路。我本人的建议是：官方通道可以用，但你至少要会配自定义通道，因为你迟早会遇到这些问题——官方列表里没有你想用的模型、公司内网不允许直接连公有云、团队要求统一走内部网关。

Zed的模型配置有两种方式：一种是通过图形界面的模型配置（设置里搜索AI/模型相关选项），另一种是直接编辑settings.json。对于追求控场的高级用户，我几乎只推荐后者，理由是更精确、可代码化、也方便在团队里分发。

2.2 自定义模型端点：把Zed指向任何兼容网关

Zed的自定义模型配置核心有两段：一段是定义Provider类型，一段是定义Model目录。下面是一个典型的配置片段，适用于把Zed指向一个OpenAI兼容的本地网关：

{ "providers": { "my_local_gateway": { "type": "openai", "base_url": "http://127.0.0.1:8080/v1", "api_key_env_var": "MY_GATEWAY_API_KEY" } }, "models": { "my_gateway/code-fast": { "provider": "my_local_gateway", "name": "code-fast", "kind": "chat" } } }

这里有一个细节：api_key_env_var不会直接写死密钥，而是指定一个环境变量名。这个设计非常合理，因为配置文件常常会提交到代码仓库，密钥放进去等于裸奔。你需要在启动Zed之前，在当前Shell环境里导出这个变量：

export MY_GATEWAY_API_KEY="sk-xxxx"

在macOS上，如果你从Launchpad启动，Shell环境变量不一定被继承，我建议用launchctl setenv MY_GATEWAY_API_KEY sk-xxxx预先注入，或者干脆写进~/.zshenv。这个问题非常隐蔽，很多人配好了发现请求一直在401，查到最后都是环境变量没进来。

接好之后，在AI面板顶部切模型时，就能看到my_gateway/code-fast这个条目。输入一个请求，Zed会把这个请求按OpenAI的格式发给http://127.0.0.1:8080/v1，后面的路径由网关自己解析。

2.3 用cc-switch做统一模型路由

如果你有多个模型服务，或者想给多个AI客户端共用一套模型配置，强烈建议把“直接配置”升级成“代理路由”。我自己在用的方案是基于cc-switch搭的本机统一入口。cc-switch这类工具的核心作用是：把散落在各个客户端里的BaseURL、APIKey、模型名映射全部收拢到一处，对外暴露一个统一的本地代理端口。这样Zed、OpenCode、以及其他工具只需要填同一个地址，更换底层模型时只改cc-switch的配置，客户端完全不用动。

我用的时候，实际效果是这样的。cc-switch监听在127.0.0.1:9090，我给它配了三个上游：一个云端通用模型、一个代码专用模型、一个本地量化模型。然后我在Zed里只配了一个Provider，BaseURL填http://127.0.0.1:9090/v1。三个模型在cc-switch侧通过模型名路由，Zed侧什么都不用改。哪天我把云端模型换掉，只需要在cc-switch里改上游配置，然后重启服务，Zed那边完全感知不到变化。

这比我之前在OpenCode里直接用“cc-switch代理全部模型”的工作流还要省事。OpenCode本身是一个终端AI编程工具，它的模型配置更灵活，但每多一个客户端就多一份配置成本。有了统一路由之后，整套流程就变成了：cc-switch负责“模型路由”，Zed负责“代码交互”，两边各干各的，互不干扰。

这里要提醒一个点：cc-switch默认可能只监听127.0.0.1，如果你想让同一局域网下的另一台机器（比如一台不装模型的MacBook）也能访问这台机器上的模型路由，需要在cc-switch配置里把监听地址改成0.0.0.0，并放行防火墙端口。我在第4部分会展开讲这个局域网代理的场景。

2.4 开发环境里的其他“代理”别搞混

说到“代理”，开发环境里其实有好几种完全不同的东西，配置的时候很容易搞混。我第一次搭的时候就在这上面绕了很久。

第一类是“模型路由代理”，也就是我们上面说的cc-switch、以及任何把模型API转发到另一个地址的本地服务。这是Zed AI配置里真正需要关心的。

第二类是“业务反向代理”，典型是Nginx反代某个WebSocket端口，或者给内部服务做统一入口。比如有人会问“Nginx代理FreeSWITCH的WS端口路径怎么解析”，这属于业务部署层面的东西，跟AI模型接入没有直接关系。除非你拿Nginx在服务器上给模型网关做统一入口——这个做法我更推荐，因为Nginx稳定、方便加TLS、能直接做域名路径转发。如果你有一台内网GPU服务器作为模型的承载者，团队想统一走一个内部的HTTPS端点，Nginx的location反代可以很干净地完成。

第三类是“下载代理”，比如Gradle下载依赖时配的代理地址、Git的全局代理配置。这类代理的作用是帮助工具访问外网资源，它的配置影响的是“拉取依赖”这个场景，不会影响Zed的模型请求。有的人会发现“我Git配了代理怎么Zed的模型还是连不上”，原因就在这里——两条链路完全独立。

搞清楚这三者的区别之后，排查问题会快很多。我见过有人把Git的代理地址填到Zed的BaseURL里，那肯定是要报错的。

3. AI Agent实测：Zed能不能真的当驾驶员

3.1 上下文怎么喂：slash、@文件与项目语义索引

Agent再强，它的工作质量也取决于你喂给它的上下文。Zed的上下文管理做得比较讲究，我实际用下来，有四种投喂方式，各有各的使用场景。

第一种是直接对话里写。适合那种“帮我解释一下这个报错”的轻量问题。Zed会自动把当前打开文件的开头几行和一些符号信息带上，但不会主动拖入整个文件，所以回答会比较概括。

第二种是@文件引用。在输入框里打一个@，Zed会弹出一个文件列表，你可以把相关文件显式地加进上下文。这个方式对Agent最关键，因为Agent需要看完整实现才能动手改。

第三种是slas命令。Zed支持自定义slash命令，比如你写一个/review，后面跟上文件或选择区域，它会按预设的系统提示词去执行。这相当于给Agent配了一套套“角色卡”，每次不用重复描述需求。我通常在~/.config/zed/agent_prompts里放一堆自定义的提示词文件，比如干重构的、写测试的、查日志的。

第四种最值得一提，是项目语义索引。Zed会为当前项目生成一份语言感知的索引，Agent在规划任务时可以“凭记忆”定位到相关文件和符号，不需要你把所有东西都显式丢给它。这意味着你可以提一个很开放的任务，比如“给整个项目里所有未处理的错误响应补上重试机制”，它自己知道该去翻哪些文件。这个能力在大型仓库里非常省事，但代价是首次打开大项目时索引需要一点构建时间。

我的习惯是：具体到文件的改动，用@文件；涉及全局结构的改动，靠语义索引；什么时候都不能忘了给它一个明确的“完成定义”——哪些断言必须通过、哪些场景可以不覆盖，说清楚之后Agent的收敛速度会快很多。

3.2 一个真实任务的Agent执行全程

光说不练没意义。我找一个上周实际做的任务来复盘。项目是一个Go语言写的内部服务，我让Zed的Agent做这样一件事：

在现有HTTP客户端上新增一个支持指数退避和最大重试次数的重试封装，并补上单元测试，确保测试能通过。

任务下达之后，Agent的动作是这样的。它先在项目里找到现有的HTTP客户端文件，读了一下构造函数和错误类型，接着新建了一个retry.go文件，里面实现了重试逻辑。第一次实现时，它把退避间隔写得比较简单，是固定500毫秒。这个版本其实已经能跑通测试，但我追加了一句“需要做随机抖动避免惊群效应”，它随即修改了实现，用rand.New(...)在基础间隔上加了15%到30%的抖动范围。

然后它自己创建了一个retry_test.go，写了几个场景：成功、连续失败后成功、达到最大次数后返回错误。写完之后它直接调用了终端里的go test ./...，第一次跑挂了，原因是它的测试里模拟“恢复”的方式是通过修改全局变量，但Go的net/http/httptest如果按常规方式写会更稳。Agent看到测试失败输出，主动改了测试实现，换成了httptest的Server，第二次跑通过了。

整个过程中，我几乎没干预。它改文件、跑命令、读报错、修正自己，完全是一个自动化闭环。最后它把改动汇总成一个摘要，我按Tab接受了全部改动，再自己快速review了一遍，确认没有越界的地方。

这个案例给我最大的感受是：Agent能不能靠谱，不取决于它单次生成代码的水平，而取决于它能不能“运行起来验证自己”。Zed的Agent因为有终端执行权限，它不是一个盲写的代码生成器，而是一个自我纠错的执行体。这一点在复杂任务里价值极大。

3.3 高频操作与快捷键流：定位改动、前后跳转

很多人搜索“Zed前后跳转快捷键”，其实想要的是在两处代码之间快速往返。在Agent自动改完文件、你按Tab接收改动之后，你需要快速定位它改了哪里，然后回到自己刚才写代码的位置。

Zed里有两个常用的跳转动作：一个是返回上一个光标位置，一个是前进到下一个位置，类似浏览器里的后退/前进。键位在不同平台和不同版本里不一定一样，我建议你直接打开Keymap搜索go back和go forward，绑定成自己顺手的方向键。我自己是把它们绑成了Ctrl+O和Ctrl+I（Vim模式下），这样在review Agent改动的时候，按一下就能在“我最后编辑的位置”和“Agent改动的位置”之间来回跳动，非常方便。

[ { "context": "Editor && VimMode == true && vim_mode != insert", "bindings": { "ctrl-o": "editor::GoBack", "ctrl-i": "editor::GoForward" } } ]

如果你不用Vim模式，也可以直接把Alt+Left和Alt+Right映射到这两个动作上，符合大多数编辑器的习惯。

另外一个被低估的快捷键是“查看当前文件的改动记录”，在Zed里能快速看到每一次编辑的diff。配合AI使用，流程是这样的：Agent改完 -> 面板里看改动摘要 -> 按Tab接收 -> 在diff视图里逐行确认 -> 有不满意的直接行内修改。这套流程我每天重复几十遍，熟练之后效率非常高。

3.4 多模型交叉验证：让Agent当裁判

高级用户手里通常不止一个模型。我把多模型用出了“Agent裁判”的玩法，这里分享一下。

当我对一个重构方案拿不准时，会让两个不同模型分别给出实现，然后对比它们的思路。具体在Zed里的操作是：同一个对话里切换模型，或者开两个分栏，各挂一个不同模型的Agent，让它们做同一件事。有时候两个模型的产出差异非常明显，一个倾向于减少依赖、原生实现，另一个倾向于引入第三方库。这种差异正是我要看的——它帮我从不同角度审视问题。

有些场景我会固定用某个模型当审查员。比如让一个模型负责写代码，换另一个模型去读它写的diff，专门找Bug和边界问题。Zed的面板支持在会话中随时换模型，所以这个流程很顺滑。这里我常用的配置是：主干开发用综合能力强的模型，审查用推理型模型，本地跑一个轻量模型处理“改注释、格式化、写测试数据”这类机械活。你如果配置了统一代理路由，模型切换几乎是无感的。

不过要提醒一点：模型切换并不代表回答质量一定变好。同一个Provider里的不同模型，如果上下文处理方式不同，对长文件的响应差异会很大。后面我列了一个常见问题表，专门说这类情况。

4. 本地大模型与离线场景：把驾驶舱开进内网

4.1 为什么高级用户都留一路本地模型

你可能有疑问：手头有云端API，为什么还要折腾本地模型？我自己的理由有三个：成本、数据隐私和断网可用。

成本方面，Agent类型的任务是极度消耗Token的。一次Agent执行循环，可能会调用几十次模型推理，累计的Token成本比单纯聊天高出一个数量级。如果把一部分机械性任务（生成的代码模板、注释补全、测试数据生成）分流到本地轻量模型上，一个月下来费用差别很明显。

数据隐私方面，内网项目经常不允许把代码片段传到外部API。Zed的Agent本身就带有项目上下文，如果走了外部API，等于把项目信息送出去。这时候只接本地模型，是最稳的方案。我见过不少团队现在的做法是：日常聊天用云端，涉及核心业务代码的修改任务强制走本地模型。

断网方面就更直接了，人总有在高铁上、在客户现场突然想编码的时候，本地模型是那会儿唯一能救你的东西。

4.2 macOS本地部署的模型选型与Zed对接

在macOS上部署本地大模型，有一个现实问题：显存（统一内存）决定你能跑多大的模型。我自己在MacBook Pro上试过不少组合，最后留了一套稳定的“双模型”方案：一个7B到8B级别的量化代码模型，负责日常补全和简单Agent任务；一个更小一点的专用模型，负责处理日志和配置类的机械操作。

选型上我的判断是这样：写代码需要模型有较强的指令跟随和工具调用能力，纯看参数规模不一定说明问题。早期我试过一个6B模型，补全效果还行，但让它跑Agent循环时经常“听不到”终端输出的错误信息，导致自我纠错能力很弱。换成一个专门针对代码优化过的8B量化模型后，Agent的成功率明显上来了。如果你要处理长文件、做跨文件的重构，那就得上更大的版本，但开两个大模型在本地不太现实，所以我会把大任务留给云端。

在Zed里接本地模型，我推荐走Ollama或者vLLM这类标准接口服务，因为Zed对应的Provider类型已经比较成熟了。Ollama起一个服务之后，BaseURL指向本机的http://127.0.0.1:11434/v1，模型名填你通过ollama pull下来的模型标签，比如qwen2.5-coder:7b-instruct-q4_K_M。Zed的配置里kind选chat，其余跟接云端模型没有本质区别。

有一个本地模型特有的问题：响应速度。本地模型的初Token时间（首字延迟）一般比云端慢，尤其在macOS上如果模型没有完全载入GPU，CPU推理会非常难受。所以我会做两个优化：一是配置模型保持常驻，不要每次请求都重新加载；二是把上下文长度调低，避免模型反复处理冗长的prompt。

4.3 局域网代理与统一端点

如果你不只是自己用，而是想让同一局域网内的其他开发机也共用这台机器上的模型资源，就需要把模型服务从“本机可见”升级成“局域网可见”。

具体操作分两步。第一步是让模型服务监听所有网卡，不能只绑127.0.0.1。以Ollama为例，需要设置环境变量让它监听0.0.0.0，然后在macOS防火墙里放行对应端口。如果你用的是cc-switch做统一路由，也一样要把它的监听地址改掉，这跟我前面说的“cc-switch开启局域网代理”是同一个操作。

第二步是给其他人一个统一的BaseURL。这里有两种做法：直接让他们把BaseURL指到你这台机器的IP和端口（适合内网测试）；或者在你的机器上再加一层Nginx，用域名路径做反向代理，顺便把TLS证书套上。第二种适合正式一点的小团队环境，因为可以在Nginx层做访问控制、记录请求日志、统一限流。

配置好之后，其他机器上Zed的Provider配置长得几乎一样，只是BaseURL从http://127.0.0.1换成了http://你的IP:端口。我测试下来，局域网内的延迟通常在1到3毫秒以内，和本机直连几乎没有区别。

这里有个非常值得注意的问题：一旦模型服务暴露到局域网，它就不再是“你一个人用的东西”了。你必须在代理层加上鉴权，至少要一个共享的APIKey，不能让局域网里任何人裸连你的模型网关。Zed本身支持给Provider配置headers，你可以在请求里带上鉴权头，这样即使你的BaseURL被猜到，没有密钥也调不通。

5. 常见问题与排查技巧实录

5.1 代理配置“看着没问题但请求500”

这是我遇到最多的问题，没有之一。配置完全照着文档抄，Provider状态也显示连接成功，但一发请求就报500或者SSL错误。

第一类原因是自签名证书。如果你在Nginx上挂了自签名的HTTPS证书，Zed默认会校验证书链，不认私有CA的话请求会直接失败。解决办法是把你的CA根证书导出来，在系统钥匙串里信任它，再把Zed完全重启。注意不是重载配置，是彻底退出再启动，因为TLS会话可能存在旧进程里。

第二类原因是BaseURL最后的路由路径不对。OpenAI兼容接口大多要精确到/v1，你填了http://host:8080，少了/v1，网关会返回一个默认为HTML的404或者500页面，Zed就把这个当成请求失败。排查办法是先拿curl打一下实际地址，确认返回的是JSON结构：

curl http://127.0.0.1:8080/v1/models -H "Authorization: Bearer test-key"

第三类原因是本地代理服务没有把请求转发到上游，或者上游Key过期了。很多人只看Zed报错“500 Internal Server Error”，就以为是Zed的问题，其实去cc-switch或Nginx的日志里看，多半是上游返回了401或者403。我现在的习惯是排查链路问题时，先看三层日志：Zed侧、代理网关侧、上游服务侧。哪里断的，一目了然。

5.2 Agent陷入循环或只说不做

Agent执行循环设计得再好，也难免有“原地打转”的时候。比较典型的症状是：它反复读同一个文件，反复改变量名，但始终没有完成你让它做的事。

出现这个现象，我一般先怀疑是不是上下文给太多了。当你的项目里有大量文件被Agent拖入上下文，模型的注意力会被稀释，它容易在小范围里“钻牛角尖”。解决办法是重新开一个会话，把任务拆小，只把关键文件@进去，把“完成定义”写清楚。

第二类原因是任务描述太模糊。你说“优化一下这个模块”，它不知道该往哪个方向优化。我会要求它先给方案，等它列出改动计划之后，再让它执行。Zed的Agent面板里支持先在对话里讨论方案，确认之后再进入执行模式，这个节奏很实用。你甚至可以设置固定的prompt：每次接到任务，第一步必须输出改动计划，等用户确认后才动文件。

第三类原因是模型本身能力不够。有些本地小模型处理复杂指令时，会生成大段的分析文本，但缺失了真正的工具调用动作。遇到这种情况我不再纠结，直接换模型，或者把这个任务切到云端模型上。

5.3 本地模型输出慢、回复被截断

本地模型跑起来之后，最影响体验的就是慢和被截断。

慢的根源通常是模型没有完全跑在GPU上。macOS上可以用ollama ps看当前加载的模型和它的运行设备，如果显示CPU，说明你没有充分使用统一内存加速。我试过最直接的办法是：在模型服务配置里把num_gpu调成999（表示使用所有可用GPU层），并关掉一些不必要的后台任务。如果你是纯CPU环境，那就只能降模型规模或者降低上下文长度。

被截断则要看生成参数。某些本地服务默认的max_tokens比较小，生成到一半就停了。你需要在Provider配置里把生成参数调大，或者在上游模型服务里明确设置。Zed的自定义模型配置里，通常是有办法传request_body或者特定参数的，不同版本入口不一样，我一般直接改settings.json，把最大的输出Token数从默认值提到4096或更高。

5.4 问题排查速查表

6. 我现在的最终配置方案与一点心里话

最后分享一下我目前实际在用的方案，也算给看完的人一个可以直接参考的起点。我的机器上跑着两个环境：一台MacBook Pro日常开发，一台内网Linux服务器专门跑模型网关。

MacBook上装的Zed，Provider配置有三路。第一路指向内网服务器的统一代理地址，走的是OpenAI兼容格式，负责日常的Agent任务，这一路的模型配置由Nginx后面的模型网关统一管理。第二路指向本机的Ollama，跑一个8B量化代码模型，负责补全和离线场景。第三路是cc-switch开的本机统一接口，给那些不直接走Nginx的工具用，比如OpenCode。

这套配置最大的价值，是把“模型选择”和“编码体验”彻底解耦了。我在Zed里不用关心每个任务背后具体是哪个模型，只需要在面板里按模型的“用途”切换：写代码选综合旗舰、审查选推理型、机械任务选本地轻量。哪天某个模型服务要升级、要切换，我只需要动网关侧配置，编辑器这边完全不受影响。

要说踩过最大的坑，其实是“配置了一次就以为永远不用再动”。模型服务更新、API格式微调、新模型上线，都可能导致链路里的某一段悄悄变化。我现在每个月都会做一次“链路健康检查”：用curl打一下每个端点的/models，确认响应正常，再在Zed里发一个极小的测试请求，确保这个月没出什么幺蛾子。这个习惯帮我省掉了不少临时排障的时间。

如果你也想把Zed配成自己的代理驾驶舱，我建议不要一上来就追求大而全。先在Zed里接一个你日常最常用的模型，把Agent流程跑顺，再逐步加本地模型和统一代理。等这三层都稳定了，你会发现自己写代码的方式已经不太一样：不再是一个人对着终端抓耳挠腮，而是坐在驾驶舱里，给副驾下指令，看它执行，你再拍板。这种感觉，确实值得体验一次。