DeepSeek Harness实战指南：Node.js构建AI推理网关-平芜编程栈

1. 项目概述：这不是一个“安装包”，而是一套AI工程化工作流的起点

“从毛坯到精装：DeepSeek Harness 上手指南”——这个标题里藏着三个关键信号：毛坯，意味着它不提供开箱即用的图形界面或预设模型；精装，代表最终形态是可交付、可复用、可嵌入业务流程的完整能力；而Harness这个词本身，在工程语境中从来就不是“插件”或“客户端”，而是“挽具”“控制装置”“集成框架”。它不生产马（模型），但决定马往哪跑、跑多快、负多重。所以，这根本不是教你怎么点几下鼠标装个浏览器插件，而是带你亲手把 DeepSeek 的推理能力，像水电管线一样埋进你自己的系统里。

我第一次看到“DeepSeek Harness”时也误以为是类似 Copilot 的 VS Code 插件，直到翻完它的 GitHub 仓库、读完package.json里的bin字段、跑通第一个curl请求才意识到：它本质是一个基于 Node.js 构建的轻量级 API 网关 + 工具链封装器。它不替代 OpenAI 兼容接口，而是帮你绕过官方 SDK 的抽象层，直接对接 DeepSeek 自家的 HTTP 接口规范，同时内置了 token 缓存、请求重试、流式响应解析、插件扩展点等生产级细节。那些热搜词里反复出现的“node.js 安装”“api key 获取”“unexpected status 401”，恰恰暴露了绝大多数人卡在“毛坯验收”阶段——连地基都没打牢，就想着贴瓷砖。

适合谁看？如果你正在做这四件事中的任何一件，这篇就是为你写的：

用 Node.js 写后端服务，需要把 DeepSeek 当作一个稳定可靠的推理模块接入；
做内部工具开发，想给非技术人员提供一个带历史记录、支持多模型切换的聊天界面；
搭建私有知识库问答系统，需要控制 prompt 注入逻辑、结果后处理和敏感词过滤；
或者只是想搞清楚为什么自己照着某篇教程填了 API Key 却总返回401 Unauthorized，连错误提示里的****都不敢截图发群问。

它解决的不是“能不能用”的问题，而是“怎么用得稳、用得省、用得明白”的问题。接下来所有内容，都围绕这个核心展开——没有玄学，只有路径、参数、日志和踩过的坑。

2. 核心设计逻辑：为什么必须用 Node.js 封装一层？直接调 API 不行吗？

2.1 直接调用 DeepSeek 官方 API 的三大隐性成本

很多人会问：DeepSeek 官网明明提供了标准 RESTful 接口文档，curl -X POST https://api.deepseek.com/v1/chat/completions加上Authorization: Bearer sk-xxx就能跑，为什么还要多此一举搞个 Harness？答案藏在三个被忽略的工程现实里：

第一，认证体系的碎片化。
DeepSeek 当前实际支持至少三类认证方式：

Authorization: Bearer <api_key>（最常见，对应官网申请的 key）；
x-api-key: <api_key>（部分旧版 SDK 和企业版网关要求）；
anthropic_auth_token: <token>（注意，这不是 Anthropic 的 token，而是 DeepSeek 内部兼容层的一个历史遗留 header，某些灰度环境仍会校验）。

热搜词里那个“auth conflict: both a token (anthropic_auth_token) and an api key (apike)”错误，就是客户端代码里同时设置了两个 header 导致的。官方文档没写清楚优先级，而 Harness 在src/auth.ts里硬编码了校验顺序：先检查Authorization，不存在则 fallback 到x-api-key，最后才尝试anthropic_auth_token。这种确定性，是你自己写fetch()时很难靠试错覆盖全的。

第二，流式响应（stream: true）的解析陷阱。
当你开启stream: true，DeepSeek 返回的不是 JSON 对象，而是一串以data:开头、用\n\n分隔的 SSE（Server-Sent Events）数据块。每个块里可能包含：

data: {"id":"...","object":"chat.completion.chunk","choices":[{"delta":{"content":"你好"},"index":0}]}
data: [DONE]（结束标识）

但真实网络中，TCP 分包会导致单次read()可能只读到半条data:，或者一次读到两条合并的data:。Node.js 原生http.IncomingMessage没有内置 SSE 解析器，而 Harness 的src/stream-parser.ts实现了一个状态机：它缓存未完成的 chunk，按\n\n切分，再逐条 JSON.parse，遇到[DONE]主动关闭流。这个看似简单的功能，我实测对比过 7 个开源 SSE 库，只有 2 个能稳定处理 DeepSeek 的特殊换行格式（它在data:后面多加了一个空格）。

第三，模型路由与降级策略缺失。
DeepSeek 当前公开模型包括deepseek-chat（通用对话）、deepseek-coder（代码专用）、deepseek-r1（最新推理模型）。但官方 API 并不提供自动路由——你必须在请求体里显式指定model: "deepseek-chat"。而 Harness 的config/model-routing.json允许你定义规则：

{ "default": "deepseek-chat", "rules": [ { "match": ".*代码.*|.*function.*", "model": "deepseek-coder" }, { "match": ".*数学.*|.*公式.*", "model": "deepseek-r1" } ] }

当用户提问“帮我写个快速排序函数”时，Harness 自动匹配正则，把请求转发到deepseek-coder，响应后再统一包装成标准 OpenAI 格式返回。这种动态路由能力，是裸调 API 无法实现的。

2.2 Harness 的分层架构：为什么选 Node.js 而不是 Python 或 Go？

Node.js 在这里不是跟风选择，而是由三个刚性需求决定的：

1. 与前端生态的零成本协同。
如果你的“精装”目标是做一个 Electron 桌面应用（比如deepseek-harness-desktop），或者一个基于 React/Vue 的内部管理后台，Node.js 进程天然能作为本地代理服务器存在。它不需要额外启动 Python Flask 或 Go Gin 服务，直接复用npm start启动的进程，通过http://localhost:3000/api/chat就能被前端调用。而 Python 的uvicorn或 Go 的net/http虽然性能更好，但会多一层进程通信开销，且调试时热更新体验远不如 Node.js 的nodemon流畅。

2. 插件系统的沙箱安全边界。
Harness 的插件机制（如热搜词里的“阿卡丽插件”“豆包去水印插件”）本质是运行在 V8 引擎里的 JavaScript 模块。Node.js 提供了vm.createContext()和vm.runInContext()，能严格限制插件代码的全局变量访问权限。比如一个“敏感词过滤插件”只能拿到input.text和output.choices[0].message.content，无法读取process.env.API_KEY或require('fs')。而 Python 的exec()或 Go 的 plugin 包，要么沙箱能力弱，要么加载动态库有平台兼容性问题。

3. npm 生态对 AI 工具链的深度覆盖。
从@google/generative-ai（适配 Gemini）到langchain（编排 LLM 流程），再到sharp（图像处理）、pdf-parse（PDF 文本提取），几乎所有 AI 前置/后置处理工具都有成熟的 npm 包。Harness 的src/plugins/目录下，一个“PDF 摘要插件”只需 3 行代码：

import * as pdf from 'pdf-parse'; export async function process(input: any) { const buffer = await fetch(input.file_url).then(r => r.arrayBuffer()); const data = await pdf(buffer); return { text: data.text.substring(0, 2000) }; // 截断防超长 }

换成 Python，你得自己处理 PDF 解析库的 C++ 依赖编译；换成 Go，得找第三方 PDF 解析包并处理内存管理。Node.js 在这里赢在“开箱即用”的工具密度，而非单线程性能。

提示：不要被“Node.js 是单线程”吓住。Harness 的核心逻辑（HTTP 请求、JSON 解析、正则匹配）全是 CPU-bound 的轻量操作，V8 的 JIT 编译器优化后，单核 QPS 轻松过 300。真正耗资源的是模型推理本身——那部分永远在 DeepSeek 的服务器上执行，你的 Node.js 进程只负责调度和胶水。

3. 实操全流程：从零开始搭建一个可验证的 Harness 环境

3.1 环境准备：Node.js 版本与依赖的精确控制

Node.js 的版本选择不是小事。DeepSeek Harness 的package.json明确要求"engines": {"node": ">=18.17.0"}，原因很实在：

Node.js 18.17+ 才默认启用--experimental-permission（权限控制），Harness 用它来限制插件访问文件系统；
node:util模块的promisify和TextEncoder在 18.0 有兼容性 bug（热搜词里那个node:util does not provide an export named错误，就是 18.0 早期版本的坑）；
fetch()全局 API 在 18.0 是实验特性，18.17 才转正，而 Harness 的src/client.ts大量使用fetch替代axios，减少包体积。

安装步骤（Windows/macOS/Linux 通用）：

卸载所有旧版 Node.js（尤其通过.msi或.pkg安装的），用命令行确认：

node -v # 如果输出 v16.x 或 v17.x，必须卸载 which node # 查看安装路径，手动删除

下载Node.js 18.19.1 LTS（当前最稳版本，非最新 20.x）：
- Windows：去官网下载node-v18.19.1-x64.msi，安装时务必勾选 “Add to PATH” 和 “Automatically install the necessary tools”（它会自动装 Python 3.10 和 build tools，避免后续编译 native 模块失败）；
- macOS：用 Homebrewbrew install node@18，然后echo 'export PATH="/opt/homebrew/opt/node@18/bin:$PATH"' >> ~/.zshrc；
- Linux：用 NodeSource 仓库curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - && sudo apt-get install -y nodejs。
验证安装：
```
node -v # 必须输出 v18.19.1 npm -v # 必须输出 9.9.0 或更高（npm 9 是 Node.js 18 默认捆绑版本）
```
注意：不要用 nvm 或 fnm 管理多版本！Harness 的package-lock.json锁死了依赖树，混用版本管理器会导致node_modules冲突，报错Cannot find module 'xxx'。就用系统级安装的唯一版本。

3.2 获取与配置 API Key：绕过“OpenAI API Key 分享”的陷阱

DeepSeek 的 API Key 获取路径非常明确，但极易被误导：

错误路径：搜索“openai api key 分享”“opencode invalid api key”，点进各种论坛帖，复制别人分享的 key（已失效或限流）；
正确路径：打开 https://platform.deepseek.com → 登录（支持微信/手机号）→ 左侧菜单“API Keys” → 点击“Create new secret key” → 复制生成的sk-xxx字符串。

这个 key 有三个关键属性，决定了你后续的配置方式：

作用域（Scope）：默认是all，但你可以创建只读 key（read:models）或仅限特定模型的 key（model:deepseek-coder）；
有效期（TTL）：默认永不过期，但强烈建议在 Harness 的config/auth.json中设置"key_ttl": "30d"，Harness 会自动在到期前 3 天刷新 key；
速率限制（Rate Limit）：免费版是 10 QPS（每秒请求数），商用版可提工单调整。Harness 的src/rate-limiter.ts用令牌桶算法实现本地限流，避免触发 429 错误。

配置文件实操：
在 Harness 项目根目录创建config/auth.json：

{ "api_key": "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "base_url": "https://api.deepseek.com", "timeout_ms": 30000, "retry_times": 3, "key_ttl": "30d" }

base_url不能写成https://api.deepseek.com/v1，因为 Harness 的src/client.ts会在路径拼接时自动加上/v1；
timeout_ms设为 30000（30秒）是底线，DeepSeek 的deepseek-r1模型在复杂推理时可能耗时 25 秒以上；
retry_times设为 3，Harness 会在网络超时或 5xx 错误时自动重试，但不会重试 401 错误（因为 key 无效重试也没用）。

实操心得：第一次运行npm start时，Harness 会读取auth.json并立即发起一个GET /v1/models请求验证 key 有效性。如果返回401，它会在控制台打印：
❌ Auth failed: Invalid API key. Please check your config/auth.json.
此时不要慌，立刻去官网重新生成 key——99% 的情况是复制时多了空格或少了字符。用echo "sk-xxx" | wc -c检查长度，有效 key 是 48 位（含sk-前缀）。

3.3 启动与验证：用 curl 发起第一个请求

Harness 默认监听http://localhost:3000，它不是一个 Web 页面，而是一个符合 OpenAI 兼容协议的 API 代理。验证是否启动成功，不用打开浏览器，用终端：

# 1. 启动 Harness（确保在项目根目录） npm start # 2. 在另一个终端窗口，发送测试请求 curl -X POST http://localhost:3000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \ -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "你好，请用中文简单介绍你自己"}], "stream": false }'

预期成功响应（截取关键字段）：

{ "id": "chatcmpl-xxx", "object": "chat.completion", "created": 171xxxxxx, "model": "deepseek-chat", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "我是深度求索（DeepSeek）研发的大语言模型..." }, "finish_reason": "stop" }] }

如果失败，按此顺序排查：

curl: (7) Failed to connect to localhost port 3000: Connection refused→ Harness 没启动，检查npm start终端是否有✅ Server running on http://localhost:3000日志；
{"error":{"message":"Invalid API key","type":"invalid_request_error","param":null,"code":"invalid_api_key"}}→auth.json里的 key 错了，或官网 key 已被 revoke；
{"error":{"message":"Model not found","type":"invalid_request_error","param":"model","code":"model_not_found"}}→model字段写错了，可用模型名见官网文档，注意大小写（deepseek-chat不是DeepSeek-Chat）；
{"error":{"message":"Request timeout","type":"server_error","param":null,"code":"timeout"}}→timeout_ms设太小，或网络到 DeepSeek 服务器不通（国内用户需确认是否走直连，非代理）。

3.4 插件开发实战：从“豆包去水印”需求出发写第一个插件

热搜词里“豆包去水印插件”是个典型场景：用户上传一张带“豆包”Logo 的截图，希望 Harness 自动识别并擦除 Logo。这背后需要 OCR + 图像编辑能力，而 DeepSeek 本身不处理图片。Harness 的插件机制就是为此设计的——它把非文本任务交给插件，再把结果喂给 LLM。

插件开发三步法：

创建插件目录：在src/plugins/下新建remove-douyin-watermark.ts；

实现处理逻辑：

import * as sharp from 'sharp'; import * as axios from 'axios'; export async function process(input: any) { // input 来自前端，结构为 { image_url: "https://xxx.png" } const response = await axios.get(input.image_url, { responseType: 'arraybuffer' }); const image = sharp(response.data); // 简单水印擦除：用模糊+覆盖（生产环境应换为 CV 模型） const metadata = await image.metadata(); const watermarkArea = { left: Math.round(metadata.width * 0.8), top: Math.round(metadata.height * 0.05), width: Math.round(metadata.width * 0.15), height: Math.round(metadata.height * 0.08) }; const processed = await image .extract({ left: watermarkArea.left, top: watermarkArea.top, width: watermarkArea.width, height: watermarkArea.height }) .blur(10) .toBuffer(); // 返回 base64，供前端展示 return { result_image: `data:image/png;base64,${processed.toString('base64')}` }; }

注册插件：在src/plugins/index.ts中添加：

import { process as removeWatermark } from './remove-douyin-watermark'; export const PLUGINS = { 'remove-douyin-watermark': removeWatermark };

前端调用方式（以 curl 演示）：

curl -X POST http://localhost:3000/plugin/remove-douyin-watermark \ -H "Content-Type: application/json" \ -d '{"image_url": "https://example.com/douyin-screenshot.png"}'

响应会是{ "result_image": "data:image/png;base64,..." }，前端<img src="data:image/png;base64,...">即可显示处理后的图。

注意事项：
插件代码运行在 Node.js 的主线程，严禁同步阻塞操作（如fs.readFileSync），必须用await；
sharp库需要libvips依赖，Windows 用户安装时若报错sharp: Command failed，运行npm install --arch=x64 --platform=win32 --target=18.19.1 sharp强制指定架构；
插件返回的数据会原样透传给前端，不经过 LLM 处理，所以敏感信息（如原始图片 URL）不要放在input里，应在插件内通过环境变量或配置文件获取。

4. 深度配置与高级技巧：让 Harness 真正“精装”起来

4.1 模型路由与上下文管理：告别硬编码 model 字段

手动在每次请求里写"model": "deepseek-coder"很低效。Harness 的config/model-routing.json支持两种智能路由：

基于内容关键词的静态路由：

{ "default": "deepseek-chat", "rules": [ { "match": "(?i)code|function|algorithm|python|javascript", "model": "deepseek-coder", "weight": 1.2 }, { "match": "(?i)math|equation|formula|calculus", "model": "deepseek-r1", "weight": 1.5 } ] }

(?i)表示忽略大小写；
weight是权重系数，用于 A/B 测试——当多个规则匹配时，按权重加权选择，避免非此即彼的硬切。

基于用户画像的动态路由（需对接自有用户系统）：
在src/routing/dynamic-router.ts中，你可以扩展：

export async function getRouteForUser(userId: string, inputText: string): Promise<string> { // 查询数据库，获取用户历史偏好模型 const userPrefs = await db.query('SELECT preferred_model FROM users WHERE id = ?', [userId]); if (userPrefs[0]?.preferred_model) return userPrefs[0].preferred_model; // 回退到关键词路由 return staticRoute(inputText); }

这样，一个长期用deepseek-coder的开发者，登录后所有请求自动路由到该模型，无需每次指定。

上下文长度管理：
DeepSeek 的deepseek-chat上下文窗口是 128K，但实际使用中，过长的 history 会导致 token 计算超限。Harness 的src/context-manager.ts提供三种策略：

truncate: 从 oldest message 开始删，直到总 token 数 < 120K；
summarize: 用 LLM 自动压缩历史（调用deepseek-r1生成摘要）；
priority: 保留 system message 和最近 5 条 user/assistant 交互，其余丢弃。

配置在config/context.json：

{ "strategy": "truncate", "max_tokens": 120000, "summary_prompt": "请用 50 字以内总结以下对话要点：{history}" }

4.2 安全加固：防止 API Key 泄露与越权访问

Harness 默认不带鉴权，这是故意为之——它假设你部署在内网或加了反向代理（Nginx/Caddy）。但如果你要暴露到公网，必须手动加固：

1. 环境变量隔离 API Key：
修改config/auth.json，改为：

{ "api_key": "${DEEPSEEK_API_KEY}", "base_url": "https://api.deepseek.com" }

然后启动时：

DEEPSEEK_API_KEY=sk-xxx npm start

这样 key 不会出现在 Git 里，也不会被ps aux | grep node看到。

2. IP 白名单（需 Nginx 配合）：
在 Nginx 配置中：

location /api/ { allow 192.168.1.0/24; # 内网段 allow 2001:db8::/32; # IPv6 段 deny all; proxy_pass http://localhost:3000; }

3. 请求签名验证（防重放攻击）：
Harness 的src/middleware/signature.ts支持 HMAC 签名：

前端用crypto-js生成hmac_sha256(timestamp + body, secret)；
后端在X-Signatureheader 中校验，拒绝timestamp超过 300 秒的请求。
配置config/security.json：

{ "enable_signature": true, "signature_secret": "your-secret-key-here", "max_age_seconds": 300 }

4.3 性能调优：QPS 突破 100 的实测参数

免费版 DeepSeek 限流 10 QPS，但 Harness 通过连接池和批处理能提升吞吐：

1. HTTP Agent 复用：
在src/client.ts中，axios实例配置：

const agent = new https.Agent({ keepAlive: true, maxSockets: 50, // 单个域名最大连接数 maxFreeSockets: 20, // 空闲连接数 timeout: 60000 // 连接超时 });

实测将并发连接数从默认 5 提升到 50，QPS 从 12 提升到 28（受 DeepSeek 服务端限流约束）。

2. 请求批处理（Batching）：
对于高频小请求（如实时输入补全），启用config/batching.json：

{ "enable": true, "max_delay_ms": 100, // 最大等待 100ms "max_requests": 10 // 最多合并 10 个请求 }

Harness 会把 100ms 内的多个/chat/completions请求合并成一个batch请求（DeepSeek 支持），再拆分响应返回。实测在 50 并发下，平均延迟降低 35%。

3. 缓存策略：
对重复问题（如“你是谁？”），启用 Redis 缓存：

npm install redis

配置config/cache.json：

{ "enable": true, "redis_url": "redis://localhost:6379", "ttl_seconds": 3600 }

缓存 key 是sha256(model + messages)，命中率可达 65%（内部知识库场景）。

5. 常见问题与避坑指南：那些文档里不会写的真相

5.1 “Unexpected status 401 unauthorized: authentication fails” 的 7 种真实原因

这个错误是 Harness 新手最高频问题，但原因远不止“key 写错了”。根据我监控 32 个生产实例的日志，真实分布如下：

原因	占比	诊断方法	解决方案
Key 复制时带不可见字符	42%	`echo "$KEY"	hexdump -C`查看`0a`(换行)、`20`(空格)
Key 被官网 revoke	28%	访问 https://platform.deepseek.com/api-keys ，看 key 状态是否为`Revoked`	重新生成新 key，旧 key 无法恢复
请求 Host 头错误	12%	`curl -v`看请求头，`Host: api.deepseek.com`必须匹配	Harness 默认设置正确，但若加了反向代理，Nginx 需加`proxy_set_header Host $host;`
跨域请求未带 Authorization	8%	浏览器 F12 → Network → 看 preflight OPTIONS 请求	前端用`fetch`时加`credentials: 'include'`，后端`Access-Control-Allow-Headers: Authorization`
Node.js 版本低于 18.17	5%	`node -v`输出 v18.0.0	卸载重装 18.19.1
HTTPS 代理干扰	3%	`curl -v --noproxy "*" https://api.deepseek.com/v1/models`	关闭系统代理，或`export NODE_TLS_REJECT_UNAUTHORIZED=0`（仅测试）
防火墙拦截 outbound 443	2%	`telnet api.deepseek.com 443`是否通	开放出站 443 端口

实操心得：当401出现时，第一步永远不是改代码，而是用curl直接调 DeepSeek 官方接口：
curl -X GET https://api.deepseek.com/v1/models -H "Authorization: Bearer sk-xxx"
如果这个都 401，说明是 key 或网络问题；如果这个 OK，但 Harness 401，说明是 Harness 配置问题。

5.2 “DeepSeek Harness Desktop” 无法启动的底层原因

deepseek-harness-desktop是 Electron 封装版，但它不是简单打包。常见启动失败原因：

1. Electron 版本与 Node.js 不兼容：
Electron 24+ 要求 Node.js 18.17+，但 Electron 22 只支持 Node.js 16。package.json中：

"devDependencies": { "electron": "^24.0.0", "electron-builder": "^24.0.0" }

必须匹配。升级 Electron 时，运行npx electron-rebuild -v 24.0.0 -w -p重建 native 模块。

2. Windows Defender 误报：
Electron 打包的 exe 被标为“潜在危险程序”，导致启动黑屏。解决方案：

临时关闭 Defender 实时保护；

或在electron-builder.yml中加签名：

win: target: - target: nsis certificateFile: ./cert.p12 certificatePassword: ${CERT_PASSWORD}

3. GPU 加速冲突：
Electron 默认启用 GPU 加速，但某些集显驱动会 crash。启动时加参数：

deepseek-harness-desktop.exe --disable-gpu --disable-gpu-compositing

或在main.js中：

app.commandLine.appendSwitch('disable-gpu'); app.commandLine.appendSwitch('disable-gpu-compositing');

5.3 插件开发的 5 个致命陷阱

插件内调用console.log会阻塞主线程：
Harness 的日志系统是异步的，但console.log是同步 I/O。插件中用process.stdout.write()替代，或统一用logger.info()。
require('child_process')在插件中被禁用：
Harness 的vm沙箱移除了child_process模块。想执行 shell 命令？用execa库：
```
import { execa } from 'execa'; const { stdout } = await execa('ls', ['-l']);
```
插件无法访问process.env的敏感变量：
process.env.API_KEY在插件里是undefined。正确做法：在config/plugins.json中定义：
```
{ "remove-douyin-watermark": { "api_key": "${WATERMARK_API_KEY}" } }
```
Harness 启动时注入，插件通过process.env.WATERMARK_API_KEY获取。
插件返回Buffer会被 JSON.stringify() 错误序列化：
return { image: Buffer.from('...') }会变成{ image: {} }。必须转成 base64：
```
return { image: imageBuffer.toString('base64') };
```
插件热更新不生效：
Harness 默认不监听插件文件变化。开发时，在package.json中：
```
"scripts": { "dev": "nodemon --watch src/plugins --exec ts-node src/index.ts" }
```

6. 后续演进：从 Harness 到自主可控的 AI 基础设施

Harness 的终点不是“能用”，而是成为你 AI 基础设施的控制平面。我团队已在生产环境跑了一年，下一步规划很清晰：

短期（1-3 个月）：

接入私有化部署的 DeepSeek 模型（通过config/local-models.json指向http://deepseek-internal:8000/v1）；
实现插件市场：前端展示插件列表，用户一键安装（npm install @harness/plugin-pdf-summary）；
埋点监控：统计各模型调用量、平均延迟、错误率，生成 Grafana 看板。

中期（3-6 个月）：