双 RTX 5090 + DSH + Qwen 3.8：本地 Agent 已经能稳定完成复杂软件重构

前言：我真正想验证的，不是"能不能跑起来"

最近我一直在测试一套本地 Agent 开发环境：

text 复制代码

DeepSeek Harness（DSH）
+
Qwen 3.8 27B
+
llama.cpp
+
双 RTX 5090 24GB

一开始，我真正担心的其实不是速度，也不是模型能不能加载。

我担心的是：

一个本地 27B 级模型，真的有足够的"智力"完成复杂软件工程任务吗？

因为"能聊天"和"能完成复杂 Agent 任务"完全是两回事。

真正的软件开发任务往往要求模型连续完成：

text 复制代码

理解旧项目
↓
阅读多个源文件
↓
理解现有架构
↓
发现设计缺陷
↓
提出重构方案
↓
修改多个模块
↓
保持接口兼容
↓
增加新功能
↓
运行测试
↓
发现问题
↓
继续修改
↓
再次验证
↓
最终完成整个任务

如果模型只是偶尔写几段代码，这并不能证明本地 Agent 真正可用。

所以这次我专门拿一个真实的 RAG 知识库项目做了一次完整重构。

结果超出了我的预期。

DSH + Qwen 3.8 + 双 5090，不仅能运行，而且能够稳定地完成一次持续时间较长、涉及多个模块、包含架构判断和代码修改的复杂 Agent 开发任务。

这件事情让我第一次觉得：

高性能本地 Coding Agent 已经不再只是实验性质的 Demo，而开始具备实际工程价值。

一、为什么我特别关注"双 RTX 5090"？

目前很多本地大模型方案一讨论到大显存，很容易走向：

text 复制代码

A100
H100
A6000
RTX 6000 Ada
企业级服务器

这些方案当然很好。

但对于普通开发者、独立开发者、小团队甚至企业研发部门而言，有一个现实问题：

获取成本和部署门槛都比较高。

而双 RTX 5090 的意义在于：

text 复制代码

消费级硬件
+
标准工作站
+
可以买到整机
+
不需要专门搭建数据中心环境

也就是说，这是一种真正具有复制性的方案。

我想验证的并不是：

"有钱买顶级服务器当然能跑。"

而是：

一台普通人能够实际采购和部署的高端工作站，能不能真正承担本地 Agent 开发？

从这次结果看，答案已经非常接近：

可以。

二、我的硬件目标：不是跑最大模型，而是跑"最好用的 Agent"

这次我的思路一直不是追求：

text 复制代码

参数量越大越好

而是寻找一个实际生产力比较高的平衡点：

text 复制代码

模型智力
×
推理速度
×
Context
×
Agent 工具能力
×
显存占用
×
稳定性

最终使用：

text 复制代码

GPU：RTX 5090 × 2
显存：24GB × 2
总物理显存：48GB

模型：
Qwen 3.8 27B GGUF

量化：
Q8_K_XL

推理：
llama.cpp

Agent：
DeepSeek Harness / DSH

一开始我尝试超长 Context：

text 复制代码

256K

结果 CUDA OOM。

随后降到：

text 复制代码

100K

模型运行非常稳定，生成速度一度达到：

text 复制代码

40+ tokens/s

但实际做复杂 Agent 任务以后，我发现：

text 复制代码

100K

对长时间 Coding Agent 来说仍然可能偏小。

最终进一步调整到：

text 复制代码

200K Context

依然成功运行。

此时大致还有：

text 复制代码

GPU0：约 3GB 空闲
GPU1：约 0.5GB 空闲

于是最终形成了一个我认为非常实用的配置：

text 复制代码

Qwen 3.8 27B Q8
+
双 RTX 5090
+
200K Context
+
约 30～40+ tok/s

三、为什么 200K Context 对 Agent 特别重要？

这是我这次测试中感受非常深的一点。

普通聊天可能：

text 复制代码

32K

都已经足够。

但 Agent 完全不同。

一个 Coding Agent 的上下文里面不断累积：

text 复制代码

System Prompt
+
用户需求
+
项目说明
+
README
+
源代码
+
多次 Read
+
Bash 输出
+
Edit 历史
+
Agent Thinking
+
测试结果
+
错误信息
+
后续计划

所以对于 Agent：

Context 并不仅仅决定"能输入多少文字"。

它实际上很接近：

Agent 的工作记忆。

如果工作记忆不够，任务执行到中途就可能出现：

text 复制代码

早期需求被裁剪
↓
模型忘记之前做过什么
↓
重复读取
↓
重复修改
↓
前后逻辑不一致
↓
任务逐渐失控

我实际就遇到过 100K 配置下，长任务进行过程中需要人为发送：

text 复制代码

继续

才能让模型接着执行。

于是我后来直接将 Context 提升到了：

text 复制代码

200K

这对于复杂工程任务的连续性帮助非常明显。

四、真正让我改变看法的，是一次真实 RAG 项目重构

硬件参数和 tok/s 都不是最重要的。

真正让我觉得这套方案"能用了"的，是它完成了一个我本来非常担心本地模型无法胜任的任务。

这是一个企业知识库 RAG 项目。

原项目 README 中的架构大致是：

text 复制代码

基于 RAG（检索增强生成）的企业知识库问答工具，
支持两种问答架构与 Web 界面 / 命令行两种使用方式：

1. DeepAgent 智能体
   rag_agent.py

   LLM 自主决定：
   - 是否检索
   - 检索什么关键词
   - 是否进行多次检索

2. LangGraph 工作流
   workflow.py

   固定：
   检索 → 生成

也就是说，原来的系统实际上有两个独立入口：

text 复制代码

简单稳定的 Workflow

和：

text 复制代码

更灵活但成本更高的 Agent

用户需要自己决定使用哪一种。

五、原系统的问题是什么？

这两种模式各有优势。

LangGraph Workflow

优势：

text 复制代码

快
稳定
调用次数少
成本低
行为可预测

但是碰到复杂问题时：

text 复制代码

检索一次
↓
生成一次

可能不够。

如果第一次召回质量不好，就很容易回答失败。

DeepAgent

优势是：

text 复制代码

可以自主判断
↓
换关键词
↓
重新检索
↓
再次分析
↓
多次检索

复杂问题明显更强。

但是：

text 复制代码

简单问题也走 Agent

就有点浪费。

六、我要求 Agent 完成的任务：加入"自动模式"

这次真正的重构目标并不是简单增加一个 API。

而是要求系统自动判断：

这个问题到底应该交给 Workflow，还是交给 DeepAgent？

最终新 README 变成：

text 复制代码

基于 RAG（检索增强生成）的企业知识库问答工具，
支持两种问答架构、自动路由与 Web 界面 / 命令行两种使用方式：

- DeepAgent 智能体（rag_agent.py）
- LangGraph 工作流（workflow.py）
- 自动路由（router.py）

其中新增：

text 复制代码

自动路由

负责：

text 复制代码

按问题复杂度
↓
在 Workflow / Agent 之间自动选择

而且还不是简单二选一。

它还增加了：

text 复制代码

Workflow 回答失败
↓
自动回退到 Agent
↓
重新检索并回答

这就已经是一个完整的运行策略。

七、最终形成的自动路由架构

新的处理流程可以概括成：

text 复制代码

用户问题
   ↓
router.py
   ↓
启发式复杂度判断
   │
   ├── 明显简单
   │      ↓
   │   Workflow
   │
   ├── 明显复杂
   │      ↓
   │   DeepAgent
   │
   └── 灰区
          ↓
      LLM 分类
          ↓
   Workflow / Agent

但 Workflow 还有第二层保护：

text 复制代码

Workflow
   ↓
生成答案
   ↓
判断置信度
   │
   ├── 正常
   │      ↓
   │     返回
   │
   └── 低置信度 / 无法回答
          ↓
      自动回退
          ↓
      DeepAgent
          ↓
      多轮检索
          ↓
        返回

最终新 README 中已经明确描述：

自动路由：启发式复杂度预判 →（灰区）LLM 分类 → 低置信度回退兜底。

这已经不是"让 AI 写一个函数"。

而是：

让 Agent 理解整个系统以后，重新设计 RAG 的调度策略。

八、为什么我一开始担心 Qwen 27B 做不到？

这个任务其实同时要求模型具备几个能力。

首先，它必须理解旧系统：

text 复制代码

rag_agent.py
workflow.py
vector_store.py
app.py
main.py
README

然后建立完整架构认知。

接下来必须理解两个模式之间的取舍：

text 复制代码

什么时候固定 RAG 足够？
什么时候必须 Agent？

然后还要设计：

text 复制代码

router.py

以及：

text 复制代码

启发式规则
LLM 分类
置信度判断
Fallback

之后还需要修改：

text 复制代码

Web API
CLI
/info
/query
README

最后保证：

text 复制代码

旧模式继续可用
+
新增 auto 模式
+
接口兼容
+
流程不冲突

所以这不是：

text 复制代码

写一个 CRUD

也不是：

text 复制代码

补一个函数

而是一项真正涉及：

text 复制代码

系统理解
+
架构设计
+
跨文件重构
+
状态维护
+
工具调用
+
代码实现

的任务。

九、DSH 的价值开始真正体现出来

如果只是直接调用 Qwen API，模型只能：

text 复制代码

输入 Prompt
↓
输出代码

但 DSH 给模型增加了 Agent Harness。

实际执行过程中，我看到的是类似：

text 复制代码

Think
↓
Read app.py
↓
Read README
↓
Think
↓
Bash
↓
Read vector_store.py
↓
Think
↓
Edit app.py
↓
Think
↓
Edit app.py
↓
Read
↓
Edit main.py
↓
继续分析
↓
继续修改

也就是说，模型不再只是：

"预测下一段代码。"

它开始以 Agent 的方式工作：

text 复制代码

观察
↓
分析
↓
行动
↓
读取反馈
↓
再次思考
↓
继续行动

这才是本地大模型真正让我感兴趣的地方。

十、让我意外的是：它真的能保持复杂任务的一致性

我之前对 27B 模型最大的不确定性不是：

text 复制代码

会不会写 Python

而是：

连续几十个步骤以后，它还能不能记得自己为什么要这么改？

实际结果比预期好。

例如它修改 app.py 时，并不是改完一个地方就结束。

它会继续：

text 复制代码

检查 /query
↓
发现需要处理 mode="auto"
↓
修改
↓
检查 similarity_search 返回结构
↓
确认数据结构
↓
继续调整 RAG 分支

然后继续：

text 复制代码

修改 /info
↓
加入路由配置信息

再继续：

text 复制代码

修改 main.py
↓
加入 ask 命令
↓
注册 command
↓
更新 usage

这是我认为很关键的一点：

Agent 的行为存在明显的任务延续性。

十一、双 5090 的意义，不只是"48GB 显存"

单看规格：

text 复制代码

24GB × 2 = 48GB

似乎只是一个显存数字。

但实际部署以后，我认为它最大的价值是：

text 复制代码

足够大的模型
+
高精度量化
+
超长 Context
+
不错的生成速度

可以同时成立。

如果只有一张 24GB 卡，很容易被迫在这些因素中做很大的妥协：

text 复制代码

模型变小
或者
量化更激进
或者
Context 大幅降低
或者
部分层回 CPU

而双卡以后：

text 复制代码

27B
+
Q8
+
200K Context
+
GPU Offload

可以同时运行。

这让"本地 Agent"第一次不像一个为了适配硬件而不断缩水的方案。

十二、为什么我认为 5090 双卡方案特别值得推广？

主要有两个原因。

第一：可获得性

很多高显存方案理论上很好，但普通开发者真正部署时会遇到：

text 复制代码

渠道
服务器规格
机房
电源
散热
驱动
采购

各种问题。

而 5090 本质上仍然属于消费级 GPU。

可以直接搭建：

text 复制代码

X870E / 高端主板
+
高功率电源
+
大机箱
+
RTX 5090 × 2

甚至可以买整机。

这使它成为：

真正可以复制的本地 AI 工作站方案。

十三、第二：性能已经跨过"能干活"的门槛

这可能比价格更重要。

如果本地模型只有：

text 复制代码

5 tok/s

或者只能跑：

text 复制代码

7B

那么无论多便宜，都很难替代云端 Agent。

而目前这套环境实际可以达到：

text 复制代码

27B Q8
+
200K Context
+
30～40+ tok/s

再加上 DSH Agent 工具能力。

这种组合已经让我觉得：

本地模型的瓶颈不再首先是"能不能用"。

接下来真正要讨论的是：

text 复制代码

哪些工作适合本地 Agent？
哪些工作仍然值得使用顶级云模型？

这已经是完全不同的阶段。

十四、200K Context 是这套系统非常关键的一环

这次实验还有一个非常重要的体会：

Agent 的智力不仅由模型参数决定。

实际 Agent 能不能完成任务，还依赖：

text 复制代码

模型本身能力
+
Harness
+
Context
+
工具
+
任务管理

一个聪明模型如果只有很短 Context，长任务一样会失忆。

对于 Coding Agent，我现在甚至认为：

text 复制代码

Context

的重要程度远高于过去聊天场景中的理解。

因为长任务必须持续记住：

text 复制代码

初始目标
已经阅读过哪些文件
已经修改了什么
为什么这么修改
还有什么没完成
前面的工具输出
测试失败原因

所以 200K 并不是为了宣传参数。

它实际上承担的是：

复杂任务持续执行的工作内存。

十五、本地 Agent 最重要的不是"绝对智商"

这次实验也改变了我对模型能力的一些理解。

过去容易直接比较：

text 复制代码

Qwen
vs
Claude
vs
GPT
vs
DeepSeek

然后问：

谁更聪明？

但 Agent 环境里，更实际的问题应该是：

这个系统最终能不能把任务完成？

因为一个 Agent 的最终能力来自：

text 复制代码

LLM
×
Context
×
工具
×
Harness
×
反馈循环

即使本地 27B 模型单轮推理能力不一定达到最强闭源模型水平，只要它能够：

text 复制代码

读代码
↓
思考
↓
修改
↓
运行
↓
观察错误
↓
继续修复

它最终完成复杂工程任务的能力可能远高于单轮 BenchMark 给人的直觉。

十六、这次任务给我的信心是什么？

不是因为：

text 复制代码

Qwen 写出了一个 router.py

而是因为它完成了整个链路：

text 复制代码

理解原有 RAG 系统
↓
识别两套架构的优缺点
↓
设计自动路由
↓
实现启发式判断
↓
加入 LLM 灰区分类
↓
设计低置信度 fallback
↓
修改 Web API
↓
修改 CLI
↓
修改系统信息接口
↓
保持原有架构
↓
更新 README

而这一切是在：

text 复制代码

本地模型
+
本地 GPU
+
本地推理服务

上完成的。

这才是最让我觉得有价值的地方。

十七、本地部署还有一个常被低估的优势：任务可以"放心跑"

云模型非常强。

但复杂 Agent 开发意味着：

text 复制代码

大量上下文
+
大量 Read
+
大量 Edit
+
大量工具调用
+
几十分钟甚至更长任务

这时候本地模型有一个很现实的优势：

不需要在每一步都考虑 token 成本。

你可以让 Agent：

text 复制代码

多读几次
多检查几次
多跑几轮

可以更大胆地给：

text 复制代码

100K
200K

级上下文。

对于工程探索型任务，这种自由度非常重要。

十八、本地模型和云模型并不是非此即彼

我并不认为这意味着：

text 复制代码

以后不需要云模型

相反，更合理的架构可能是：

text 复制代码

日常开发
代码阅读
RAG
内部知识库
数据分析
长时间 Agent
        ↓
     本地模型

极难推理
关键架构评审
特殊任务
        ↓
    顶级云模型

本地 Agent 的价值不是一定要把云模型彻底替掉。

而是：

大量原本只能依赖云模型的工作，现在终于可以自己承担。

十九、为什么这件事情值得更多开发者尝试？

因为它已经具备三个条件：

text 复制代码

硬件可以买
模型可以下载
软件栈可以复现

核心组件都是相对标准的：

text 复制代码

RTX 5090 × 2
+
llama.cpp
+
Qwen
+
DSH

不需要：

text 复制代码

8×H100

也不需要大型机房。

如果更多开发者开始测试类似配置，我们可能很快会看到一类新的开发环境：

text 复制代码

传统开发工作站
        ↓
AI 开发工作站

机器里除了：

text 复制代码

IDE
数据库
Docker
浏览器

还长期运行着：

text 复制代码

一个属于自己的 Coding Agent

二十、我的最终结论

这次实验真正证明给我的不是：

双 5090 可以跑 Qwen 27B。

这个早就不是最重要的问题。

真正重要的是：

双 RTX 5090 + Qwen 3.8 + DSH，已经能够作为一个稳定、连续、可实际参与复杂软件工程开发的本地 Agent 环境。

目前我的实测配置：

text 复制代码

GPU：
RTX 5090 24GB × 2

模型：
Qwen 3.8 27B

量化：
Q8_K_XL

推理：
llama.cpp

Context：
200K

Agent：
DeepSeek Harness

生成速度：
约 30～40+ tokens/s

实际任务：
企业 RAG 知识库架构重构

任务内容：
原有 Workflow + DeepAgent
        ↓
增加自动路由
        ↓
启发式复杂度判断
        ↓
LLM 灰区分类
        ↓
Workflow 低置信度检测
        ↓
自动 fallback 到 DeepAgent
        ↓
同步修改 Web / CLI / README

最终：

text 复制代码

任务完成
模型稳定
上下文稳定
Agent 能持续工作

这让我对消费级硬件上的本地 Agent 有了比 Benchmark 更强的信心。

二十一、我现在真正想推荐的，不是一块显卡，而是一种部署思路

如果你是一名：

text 复制代码

软件开发者
AI 开发者
独立开发者
小团队负责人
企业内部 AI 平台开发者

并且你希望：

text 复制代码

代码不出本地
知识库不出内网
Agent 可以长时间运行
拥有超长 Context
不需要计算每一次 API token 成本

那么：

text 复制代码

双 RTX 5090
+
27B 左右高质量本地模型
+
200K 级 Context
+
DSH 类 Agent Harness

已经非常值得认真考虑。

它不再只是：

"发烧友在家跑大模型。"

而开始变成：

一台真正能够承担 AI 软件工程任务的个人计算设备。

我原本最担心的问题是：

Qwen 27B 的智力够不够？

这次完整重构以后，我的答案变成了：

至少对于相当一部分真实的软件工程和 RAG 开发任务，它不仅够用，而且已经能真正把事情做完。

而对 Agent 来说：

能稳定地把复杂任务做完，比一次回答看起来有多聪明，更重要。