今天，我把 DeepSeek Harness v0.1.0-rc.6 装到了一台 Windows 电脑上。

安装过程其实不算复杂。真正让我停下来研究的，是启动之后那个界面。模型、插件、Agent 预设、权限、工作区，全被放进同一个控制台里。

我当时没有马上输入任务，而是盯着屏幕看了一会儿。怎么说呢，它不像一个等你提问的聊天机器人，更像一张还没接上线的控制台。按钮都在那里，真正决定它会变成什么的，是你准备接进去的数据、规则和工作习惯。

刚看到首页时，我第一反应不是让它写 Listing，也不是让它分析广告。我先盯着「选择工作区」看了几秒。

因为做亚马逊的人都知道，真正麻烦的从来不是问一句话，而是把搜索词报告、Business Report、SQP、评论、库存和文案串成一个能重复执行的流程。

这也是我今天最兴奋，又最不敢兴奋过头的地方。每次看到新的 Agent 工具，我脑子里都很容易先演完一部科幻片，选品自动跑、广告自动调、Listing 自动改，仿佛明天就能少招两个人。。。冷静几分钟以后才想起来，连团队内部的指标口径都还没完全统一，工具再聪明，也只会把混乱跑得更快。

聊天框只能回答一次，工作流才可能替团队积累能力。

一、它不是一个新的 DeepSeek 模型

DeepSeek Harness 是 DeepSeek AI 开源的 Agent Harness。这个词听着有点技术，你可以先把它理解成智能体的运行底座。

DeepSeek 模型像发动机，Harness 更像驾驶舱。它把模型、插件、权限、工作区和 Agent 预设放在同一个系统里。

发动机决定动力，驾驶舱决定这股动力往哪里去，什么时候加速，什么时候必须踩刹车。对卖家来说，后半句反而更重要。广告费不是游戏币，Listing 也不是改坏了还能随手读档的测试文本。

对我这种亚马逊卖家来说，最有吸引力的并不是它能聊天，而是它能先选一个工作区，再围绕里面的文件持续工作。

图 1DeepSeek Harness 首页。开始任务前先选择工作区和运行模式。

比如我可以建立一个「US站广告诊断」文件夹，只放脱敏后的搜索词报告、广告活动报告和目标 ACOS 规则。Agent 只围绕这个目录分析，边界比把资料散落在聊天记录里清楚得多。

以前我用聊天工具分析报表，常常有一种临时请外援的感觉。每次都要重新解释产品、站点、目标 ACOS 和判断口径。解释到最后，自己已经快分析完了。工作区的价值，是把这些背景从一次性对话，慢慢变成可以重复使用的上下文。

先说边界DeepSeek Harness 不是 Seller Central，也不会在没有插件、接口和授权的情况下自动读取店铺后台。亚马逊应用需要业务数据、分析规则和相应工具共同配合。

二、直接让 Codex 帮你安装

我今天没有让读者手动折腾一长串命令，而是直接把 GitHub 仓库地址交给 Codex，让它负责检查环境、安装、验证和启动。

说实话，这一步改变了我对安装教程的看法。过去看到 GitHub 项目，我会先往下翻命令，心里默默计算今晚要踩几个环境坑。现在我更愿意先把目标交给 Codex，让它完成那些重复但必须严谨的检查，我只在需要授权和判断的地方介入。

如果你正在使用 Codex 桌面端，新建一个任务，把下面这段话完整发给它。

可直接复制给 Codex

请安装 DeepSeek Harness。项目地址是 https://github.com/deepseek-ai/deepseek-harness 。先检查 Windows 上的 Node.js 和 npm 环境，再按官方方式安装 @deepseek-ai/dsh。安装完成后运行版本检查，启动 Web UI，验证 http://127.0.0.1:3080 可以访问。遇到 PowerShell 脚本限制时使用 npm.cmd、npx.cmd 和 dsh.cmd。不要修改无关文件，完成后告诉我安装版本、启动命令和访问地址。

Codex 会先检查 Node.js 和 npm。涉及从 npm 下载软件时，桌面端可能弹出授权提示，确认目标是官方包 @deepseek-ai/dsh 后再允许。

我这次实测，Codex 识别到 Node.js v24.14.0 和 npm v11.9.0，随后全局安装 DeepSeek Harness v0.1.0-rc.6，并用帮助命令验证 dsh 可用。

安装完成后，还可以继续发第二条指令。

启动指令启动刚安装的 DeepSeek Harness Web UI。确认 3080 端口正常监听，再告诉我访问地址。如果服务已经运行，不要重复启动。

启动成功后，浏览器打开 http://127.0.0.1:3080。这个地址只指向本机，不是公开网站。

为什么我更推荐这种方式？因为 Codex 能把环境检查、命令选择和结果验证串起来。读者不需要先搞懂 PowerShell 为什么拦截 npm.ps1，也不用猜安装到底有没有成功。

这不是说命令行不重要。恰恰相反，我只是把人的注意力从机械输入命令，挪到更值得判断的地方。它装了什么，为什么要这个权限，服务有没有真正启动，这些问题还是得有人负责。

当然，最好知道它背后做了什么。Windows 备用命令如下，出现故障时方便手动排查。

npm.cmd install --global @deepseek-ai/dsh

dsh.cmd --version

dsh.cmd web

三、第一次配置，先放慢一点

首次进入时，系统会提示添加 DeepSeek API Key。输入框为空的截图可以用于文章，但真实密钥千万别出现在截图、提示词或共享文档里。

图 2首次启动的 API Key 配置提示。没有密钥时也可以先选择稍后配置。

随后进入模型设置。截图中能看到 DeepSeek 官方提供方，也可以添加提供方或自定义提供方。具体字段和支持范围要以当前安装版本为准。

图 3模型设置页。可填写 DeepSeek API Key，并按需添加其他提供方。

从亚马逊卖家角度，我会把 API Key 和业务文件彻底分开。密钥只进入配置页，报表目录里不保存任何凭证。

这一步看起来有点谨慎，但跨境团队的广告、利润和供应链数据都很敏感。新系统先做好边界，后面才睡得着。

我输入配置时确实犹豫了一下。不是不信任开源项目，而是做店铺久了以后，人会形成一种近乎条件反射的警惕。任何能读文件、跑命令、连接外部服务的工具，我都会先问三遍，它能看到什么，它能改什么，出错以后谁来兜底。

这种谨慎不酷，却很值钱。跨境运营里很多损失不是因为不会增长，而是因为一次误操作把本来稳定的东西弄坏了。

四、权限不是越大越好

通用设置里可以选择 Agent 预设、权限、语言、外观和发送方式。截图中的权限是 Workspace Write。

图 4通用设置页。建议从 Workspace Write 和独立测试目录开始。

我的做法很简单。先建一个专门的测试目录，只放脱敏数据，不把整个硬盘或团队共享盘交给 Agent。

你可以把工作区想成给新员工准备的试用工位。第一天不会把财务章、店铺主账号和所有供应商合同一起塞给他。先给一份资料、一个任务和一条清楚的验收标准，看看做事方式对不对。Agent 也一样。

例如把最近 30 天的搜索词报告复制进去，再放一份规则文档，写清目标 ACOS、最小点击样本和否定条件。

稳妥起步第一阶段只让 Agent 读取数据并生成审核清单，不直接修改广告，不调用可能产生外部影响的工具。

五、四种模式怎么选

首页可以切换标准模式、PTC 模式、极简模式和创造模式。这个下拉菜单，是我觉得最值得亚马逊团队认真看的地方。

图 5首页的四种运行模式。不同模式对应不同工具组合与任务复杂度。

标准模式功能最完整，界面说明里包括文件编辑、Shell、文件与网页检索、Skills、计划、目标、子代理和工作流。日常报表分析和运营资料整理，可以先从这里开始。

PTC 模式在标准能力上加入 Code Mode SDK，让模型通过 TypeScript 程序组合多步操作。它更适合已经懂脚本和流程编排的团队，不建议新手一上来就用。

极简模式只保留持久 bash 和 str_replace_editor，更像一个轻量编码 Agent。创造模式则用于创建自定义 Agent preset。

说真的，我刚装好时也想直接点最强的。后来一想，广告优化最怕的不是工具弱，而是规则没写清就自动执行。。。

复杂模式解决不了模糊流程。

六、插件决定它能做多少事

插件设置页能看到终端、Agent 循环和网页搜索。截图里的说明非常直白，终端负责限制 Agent 运行的每一条命令，Agent 循环控制工具调用方式，网页搜索由 DeepSeek 搜索提供方承担。

图 6插件配置页。终端、Agent 循环和网页搜索共同决定 Agent 的执行能力。

对亚马逊卖家来说，插件思路可以映射成三类能力。

第一类是文件能力，用于读取 CSV、文本、图片和运营文档。第二类是计算能力，用于清洗搜索词、合并 SKU、计算 ACOS 和转化率。第三类是外部连接能力，用于访问经过授权的数据源。

我更愿意把插件理解成 Agent 的手脚。模型再会思考，没有合适的手脚，也只能坐在驾驶舱里给建议。可手脚越多，能碰到的东西也越多，所以插件不是装得越满越高级。装一个，就应该知道它多拿走了哪项权限，多增加了哪个故障点。

但当前截图并不能证明系统已经内置 Seller Central 连接器，也不能据此承诺自动调价、自动否词或自动改 Listing。

能分析和能执行，是两回事。

七、Agent 预设才是团队化的入口

Agent 预设页面把标准、PTC、极简和创造模式拆成了卡片。界面说明里明确写着，预设是一组插件、工具、提示词和能力。

图 7Agent 预设页。可以复制内置预设，也可以通过创造模式建立自定义预设。

这让我想到一个很现实的亚马逊团队结构。选品、广告、Listing、评论和周报，本来就不该用同一套提示词。

我们以前总喜欢找一个全能运营，最好选品会、广告会、文案会、表格会，顺便还能盯库存。后来会发现，全能往往意味着所有判断都装在一个人的脑子里。这个人状态好，团队就顺。这个人请假，整个流程突然开始失忆。

我会先设计 5 个只读 Agent。

① 广告体检 Agent，读取搜索词和广告活动报告，只输出异常、证据和建议。

② Listing 审核 Agent，对照产品资料、关键词和禁用词，输出原文、建议版本和修改原因。

③ 评论洞察 Agent，把差评分成产品问题、物流问题和认知偏差，再给出产品改进优先级。

④ 库存风险 Agent，对照销量和可售库存，标出可能断货或积压的 SKU。

⑤ 周报 Agent，把前面四个 Agent 的结果汇总成负责人能直接审阅的复盘。

这才是 Harness 真正有意思的地方。不是多开几个聊天窗口，而是让每个角色拥有自己的数据、规则和权限。

当这些规则被写进预设，它们才第一次从老运营的直觉里走出来，变成新人可以看、团队可以改、负责人可以追问的东西。我觉得这比单次生成一篇漂亮文案重要得多。

八、先从搜索词报告跑一个闭环

如果你今天就想试，我建议别碰最复杂的流程。拿一份脱敏后的搜索词报告，跑一个最小闭环。

这个建议听着不够性感。装了这么大一套系统，最后只让它读一张 CSV，多少有点像买了一辆越野车，第一天只在小区地库绕了一圈。可新流程最怕的就是一上来跨越十个环节，结果错了都不知道该怪数据、规则、插件还是模型。

第一步，建立独立工作区，只放一份搜索词 CSV 和一份广告规则说明。

第二步，明确业务口径。例如目标 ACOS 为 28%，点击少于 8 次不直接否定，点击达到 12 次且零订单才进入否定候选。

第三步，要求 Agent 输出三组结果，加词机会、否定候选和样本不足的观察词。

第四步，所有结论必须引用原始数字，并标出数据来源。

第五步，不执行任何广告修改，只生成一份人工审核清单。

可直接使用的任务描述读取工作区内的搜索词报告，按目标 ACOS 28% 分析。点击少于 8 次不直接否定，点击达到 12 次且零订单进入否定候选。输出加词机会、否定候选和观察词。每条建议引用原始数据，不执行修改。

跑完之后，不要只看它给了多少建议。重点检查字段有没有读错、计算是否一致、规则有没有漏掉、结论能不能追溯到原始行。

如果这四件事都过关，再考虑加入第二张报表。

第一周它可能比你手动做还慢。你要整理字段、补规则、纠正一次又一次误解，甚至会怀疑自己是不是在花时间照顾一个电子实习生。可这些修改只要被留下来，下一次就不用从零解释。省下来的不是某一次的十分钟，而是同一种判断被重复使用的可能。

九、Listing 和评论怎么结合

Listing 优化看起来是写文案，其实是一组约束。字符限制、品牌语气、关键词、产品规格和合规表达，任何一项错了都可能返工。

我会要求 Listing Agent 固定输出三部分，原文、建议版本、修改原因。这样运营人员能看见它动了哪里，不会被一段流畅文案糊弄过去。

评论 Agent 则负责提取用户真正关心的场景。假如大量买家反复提到一个人也能安装，这句话就可能进入主图文案、五点或 A+。

看到评论聚类时，我脑子里不会只有一个百分比。我会想到那个周末独自在车库里装产品、手上还拿着说明书的买家。他留下的「一个人也能装」，可能比我们会议室里想出来的十句卖点都更接近真实需求。

从评论到产品，再从产品回到 Listing，这条链路比单纯叫模型写五点有价值多了。

十、遇到网页打不开，先检查服务

我今天也踩了一个很典型的坑。浏览器突然显示 127.0.0.1 拒绝连接。第一眼看着像网络问题，其实通常只是本机服务没有运行。

页面弹出错误的那一刻，我还是下意识去看网络。折腾了几秒才反应过来，127.0.0.1 根本没离开这台电脑。那个瞬间有点好笑，像在自己家门口按门铃没人开，于是先怀疑整座城市停电了。

图 8出现 ERR_CONNECTION_REFUSED 时，优先确认 dsh.cmd web 是否仍在运行。

重新打开 PowerShell，运行 dsh.cmd web，再刷新页面。启动服务的终端窗口需要保持开启。

如果 PowerShell 拒绝执行 npm.ps1，就使用 npm.cmd 和 npx.cmd。如果遇到 Windows EPERM，再检查 .dsh 配置目录权限、文件占用和安全软件。

十一、我对它的真实判断

DeepSeek Harness 目前仍是开发者预览产品。官方已经提醒，后续可能出现不兼容更新。它也没有官方 Windows 桌面安装包，当前主要通过本机 Web UI 使用。

所以我不会让它刚装好就接管核心店铺，更不会直接拿真实广告权限做实验。

我更愿意把它当成一个正在成形的运营工作台。先让它读脱敏文件，按固定规则输出证据，再由人审核。

写到这里，我突然想到传统手工作坊走向流水线的那个变化。真正改变生产方式的，从来不只是多了一台机器，而是人们开始重新拆解工序，规定输入和输出，把老师傅脑子里的经验变成别人也能照着执行的流程。

Agent 工作台大概也在做同一件事。我们今天看见的是模型、插件和几个设置页。再往深处看，它逼着团队回答一些过去一直含糊的问题。什么叫一个值得否定的搜索词，什么样的 Listing 修改算有证据，库存风险达到什么程度必须升级处理。

很多朋友担心 Agent 会不会替代运营。我自己的感受是，眼下更值得担心的，是团队的方法一直没有被写下来。

一个老运营离职，广告判断、选词逻辑和复盘习惯也跟着走了。Harness 这类系统真正想做的，是把这些散落在脑子里的经验，变成可重复、可检查、可交接的流程。

当然，流程化也有代价。写规则很烦，维护数据很烦，第一次跑出来的结果也未必惊艳。说实话，我们离真正稳定的自动化还差得远。可我宁愿面对一个能被看见、能被修正的笨流程，也不愿继续依赖那些只有某个人「凭感觉就知道」的黑箱经验。

DeepSeek Harness 现在还早。它可能会改接口，会换交互，会让今天的教程过几个月需要重写。但方向已经露出来了。模型不再只是回答问题，它开始被放进有边界、有工具、有记录的工作环境里。

对于亚马逊团队，这不是多了一个会写标题的助手。更像是我们终于有机会，把每天重复发生的判断，做成一套会留下痕迹的系统。

今天先建一个测试文件夹，放入一份脱敏搜索词报告，跑出一张不执行修改的审核清单。

先把这一件小事做稳。

这比收藏十篇教程有用得多。