DeepSeek Harness 配置实战：通用设置与 Agent 预设调优指南

1. 内容整体设计与思路拆解

1.1 为什么说 Harness 的核心是“设置”而不是“模型”

很多人刚接触 DeepSeek Harness 时，第一个反应是去折腾模型下载、API Key 配置这些重活，我最初也是这么干的。但实际用下来才发现，真正决定这个工具好不好用的，反而是那些看起来不起眼的通用设置和 Agent 预设。

打个比方，模型相当于发动机，排量再大，没有一套顺手的变速箱和方向盘，你也开不出赛车的感觉。DeepSeek Harness 里的通用设置就是这个“变速箱”，Agent 预设就是“方向盘”。发动机决定你有多少潜力，但设置和预设决定你能发挥出多少。

这个项目本身是一套围绕 DeepSeek 大模型打造的本地化工具链，支持桌面端和命令行两种形态，核心目标是把模型调用、上下文管理、工具链编排、多 Agent 协作这些能力打包成一个开箱即用的工作台。它不是单纯的聊天客户端，更像是一个“模型调度中枢”——你可以同时挂载多个模型服务，按场景切换不同的 Agent 预设，让模型以不同身份、不同策略去完成不同类型的任务。

对于刚入门的人来说，最容易踩的坑就是把精力全花在“怎么把模型跑起来”上，忽略了真正需要花时间理解的是“跑起来之后怎么用”。我见过太多人装好之后，对着默认界面问我“这东西能干嘛”，其实答案就在 Agent 预设里。把预设配好了，Harness 才能真正从“一个能聊天的终端”变成“一个能干活的工作台”。

所以这篇内容，我不会再讲怎么下载、怎么装、怎么配 API Key，上一篇文章已经覆盖了这些基础内容。这篇的重点是两件事：一是把通用设置里那些你平时不会注意、但关键时刻能救命的参数讲透；二是把 Agent 预设的分类逻辑、配置思路和真实使用场景拆开揉碎，让你看完就能直接上手配置自己的 Agent，而不是停留在默认预设里打转。

1.2 这篇文章适合谁读

先给读者画个像。

如果你是刚把 DeepSeek Harness 装好、还在默认界面上到处点的小白，这篇文章能帮你建立一套“设置思维”——你不需要记所有参数，只需要知道每个设置解决什么问题、什么时候需要去动它。这会让你少走很多弯路。

如果你已经用了一段时间，觉得 Harness 总差点意思，输出不稳定、上下文不够用、工具调用经常出错，那这篇文章更对味。因为我接下来要讲的大部分内容，都是针对这类“用得动但不顺手”的问题去展开的。通用设置里的很多参数，默认值不是不可以，而是不够好——你需要根据自己的使用场景去调。

如果你是想用 Harness 做团队协作、做自动化流程、做多 Agent 协作的进阶用户，Agent 预设这部分是你绝对不能跳过的内容。怎么把不同角色、不同任务类型固化成一键调用的预设，怎么让多个 Agent 并行工作不打架，这些我都有实际踩坑后的经验，会一并分享。

简单说，这篇文章适合所有已经装上 DeepSeek Harness、但还没找到“正确打开方式”的人。我已经替你们把该试的、该踩的、该坑的都过了一遍，你们直接看我踩完坑之后留下的总结就好。

2. 通用设置详解：每一个参数背后的逻辑

2.1 模型接入的三种方式，别只会用默认 OpenAI 兼容接口

DeepSeek Harness 的通用设置里，第一块是模型接入。这里藏着一个不少新手忽略的事实：它支持三种接入方式，分别是本地模型服务、云端 API、以及自定义兼容接口。

很多人装完默认配置，顺着界面指引配了一个 OpenAI 兼容地址，就以为万事大吉了。但实际使用中，你会发现不同场景对模型接入方式的要求完全不同。

先说本地模型服务。如果你用的是本地部署的 Ollama、vLLM 或者 llama.cpp 起的一个服务，Harness 可以直接挂到 localhost 的端口上。这种方式的好处是数据不出本机，延迟低，配合文档问答、代码分析这类隐私敏感任务非常合适。我第一次在 Harness 里接本地模型时，第一反应是“会不会很麻烦”，结果发现就是填一个 base URL 的事，关键是你要搞清楚自己起的服务监听在哪个端口、模型名准确叫啥。

云端 API 是最大众的选择。DeepSeek 官方 API、或者第三方托管的兼容服务都可以直接接入。这里有个我踩过的坑：很多人会把“模型名称”和“API 里的 model 参数”混为一谈。你在 Harness 界面里填的模型名，必须和你实际调用的模型标识完全一致，差一个字符都会报错。比如你想调用 deepseek-chat，就老老实实填 deepseek-chat，别自以为聪明地填成 deepseek-chat-v3 或者什么别名，API 不认识。

自定义兼容接口则是给喜欢折腾的人准备的。你可以把任意一个符合 OpenAI 协议的服务地址填进去，哪怕是公司内网的一个网关，只要你给它配上相应的模型名和鉴权信息，Harness 就能把它当一个标准模型源来用。我实际测试下来，只要是 OpenAI 兼容协议，基本都能正常识别，这大大扩展了 Harness 的适用范围。

2.2 上下文窗口设置：为什么你总是觉得模型“记性不好”

通用设置里最容易被忽略、但影响最直接的参数，就是上下文窗口设置。

默认情况下，Harness 可能会按模型自身的窗口大小去设置。但实际用下来你会发现，“模型支持 64K 上下文”不等于“Harness 会把这 64K 全给你用上”。这里的核心逻辑是：Harness 需要在模型上下文窗口的基础上，预留一部分空间给系统提示词、工具调用返回结果和 Agent 内部状态记录。如果你把上下文窗口顶到最大值，模型在处理长对话或复杂任务时，很可能因为空间不足而被迫截断关键信息。

我自己的经验是，如果模型的窗口是 32K，我会在 Harness 里把上下文限制设为 24K 左右，留出 8K 的空间作为缓冲。这样既不会浪费模型能力，又不会因为工具调用或长文本返回导致“爆窗”报错。

还有一点很多人不知道：上下文窗口设置不只是针对对话历史的，它会直接影响 Agent 的工具调用能力。当某一次函数调用的返回结果特别长时，Harness 会在当前上下文剩余空间里临时保存这个返回结果供模型分析。如果你把窗口设得太满，这一步就会出现“返回结果被截断”的情况，而模型往往不会明确告诉你它没看全，只会给出一个莫名其妙的错误答案。我遇到过好几次模型“睁眼说瞎话”，排查半天才发现是上下文空间被挤爆了。

建议新手第一件事就是把上下文设置里的“预留空间”看懂，把它当做一个逻辑上的安全边界。不用精确计算每一轮对话消耗多少，只要别让模型一上来就顶着天花板跑就行。

2.3 并发与请求超时：批量任务卡死的真正原因

另一个被很多人忽视的通用设置，是并发数和请求超时时间。

Harness 在处理批量任务、多 Agent 并行工作、或者一次处理多个文件时，会同时向模型服务发起多个请求。默认并发数通常比较保守，可能是 1 到 2，这时候如果你的任务是“让模型分析 20 个文件”，你就会看到任务一个一个慢慢跑，耗时特别长。很多人以为这是模型速度慢，其实只是并发没调上去。

把并发数调高是有收益的，但也要小心。如果你用的是本地模型服务，并发数一高，显存不够就会出现 OOM 或者推理速度大幅下降——这时候并发反而拖慢整体速度。我用 4090 跑本地模型的经验是，并发数在 2 到 4 之间比较合理；用云端 API 的话可以调高一些，但要注意 API 服务商那边的速率限制。

请求超时设置则是另一个“隐形杀手”。默认超时时间可能只有 60 秒，但你让模型生成一篇长文章、分析一份大规模代码库、或者做一个复杂推理时，一次请求很可能超过一分钟。超时时间设得太短，任务会频繁失败，而且失败原因在日志里往往就是一行冷冰冰的 timeout，完全看不出问题在哪。

我之前吃过一次大亏：让 Harness 生成一个几千行的代码文件，跑了三分钟，结果在 60 秒超时的时候直接断了，我还以为是我代码写得有问题，反复调了好几次才发现是超时时间的事。现在我的习惯是，凡是涉及长文本生成的任务，超时时间直接拉到 300 秒；如果任务特别重，甚至会临时调整到 600 秒。反正超时时间只是个保护机制，不是越大越好，但要让它在合理的范围内兜住你的实际任务。

2.4 日志与调试选项：出问题时的第一逃生通道

通用设置里还有一块值得单独拿出来说的，是日志等级和调试选项。

很多人可能从来不碰这个设置，直到出了神秘问题——模型偶尔返回乱码、工具调用时好时坏、某个 Agent 莫名其妙就罢工了——才开始抓瞎。这时候如果你把日志等级调到 debug 模式，Harness 会记录下每一次请求的完整内容、模型返回的原始响应、工具调用的参数和返回结果。这些信息是排查问题的最重要依据。

我自己的习惯是：日常使用保持在 info 级别，避免日志文件膨胀；一旦开始测试一个新的 Agent 预设或者接入一个新的模型服务，就先切到 debug 模式跑几轮，确认没问题再切回来。这样做的好处是，出了问题你能立刻从日志里看到是请求参数没拼对，还是模型返回了非预期格式，还是工具调用链路挂了——而不是像无头苍蝇一样瞎猜。

还有一个很多人不知道的小技巧：Harness 的调试选项里通常能看到每次请求的 token 消耗明细。这个信息特别有用，你会发现某些任务明明看着不大，token 消耗却高得吓人，然后顺着日志去查，往往是某个工具把一份超长的文档重复传了好几次。这种“隐性 token 消耗”在关掉调试的情况下完全无感，但月底看账单的时候会肉疼。

3. Agent 预设详解：把你的使用场景固化下来

3.1 什么是 Agent 预设，为什么它如此重要

先把概念捋清楚：Agent 预设，就是一组预先配置好的提示词、工具集、模型参数和行为策略的组合。它相当于给 Harness 里的“数字员工”写下了一份岗位说明书。

没有预设的时候，你每次和 Harness 对话，都要把任务背景、角色要求、工具使用规则说一遍。比如我想让它当我的代码审查员，我得在每次对话开头写一大段“你现在是一个资深代码审查员，请从安全性、可维护性、性能三个方面审查以下代码，输出格式要包括问题等级、问题描述、修改建议”。虽然有用，但每次都这么写，时间成本很高，而且每次都写不完全一样，模型的行为也会飘。

有了预设之后，这些内容被固化下来。我只需要选一个叫“代码审查员”的预设，Harness 就会自动把所有提示词、工具配置、输出格式要求加载好。更关键的是，预设可以绑定专属工具——代码审查员预设可以自动关联代码读取工具、代码搜索工具，而不是让你手动去挂载。

我个人的理解是，Agent 预设本质上是一种“身份+能力+行为规范”的三合一封装。身份决定模型以什么角色思考，能力决定它调用哪些工具，行为规范决定它以什么格式、什么节奏输出。这三个要素缺了一个，Agent 的表现都会差一个档次。

3.2 预设的分类：任务型、角色型、流程型

根据我长时间折腾的经验，Harness 里的 Agent 预设大致可以分成三类：任务型、角色型和流程型。理解这三种类型的区别，会直接帮助你配置出适合自己的预设。

任务型预设是为某个具体任务服务的。比如“代码漏洞扫描”、“合同关键条款提取”、“论文摘要生成”。这类预设的特点是目标清晰、工具固定、输出格式明确。配置时的关键是把你对输出结果的期望写得足够具体，让模型知道你不需要自由发挥，你只需要它按格式办事。我的经验是，任务型预设里的提示词要“窄而不浅”——范围要窄，但每一条要求都写到骨头里。

角色型预设更关注思维方式和表达风格。比如“资深产品经理”、“法律顾问”、“数学老师”。这类预设适合用于日常咨询和头脑风暴，不用绑定太多工具，但要在提示词里把角色的知识结构、思考路径、语言习惯都描述清楚。比如我在配“法律顾问”预设时，会明确要求模型先做法律风险归类，再逐条分析，最后给出合规建议，而不是一股脑把所有想法倒出来。

流程型预设则是把多个步骤串成一个工作流。比如“从需求到接口文档”，这个预设可能会要求模型先拆解需求，再设计数据结构，然后生成接口文档，最后输出示例调用代码。流程型预设的价值在于它能让模型按顺序完成逻辑链，而不是跳步或遗漏关键环节。这种预设配置起来最难，因为你得把流程的先后依赖关系在提示词里交代清楚，模型才能顺着你的脚本走。

3.3 从零配置一个 Agent 预设：以“代码审查员”为例

说了这么多概念，接下来给一个完整的实操案例。我以自己实际上在用的“代码审查员”预设为例，一步步拆解配置过程。

第一步是明确这个预设的目标和工作边界。我的代码审查员预设，目标是审查一个项目目录下的代码文件，输出安全、性能、可维护性三个维度的审查结果。工作边界就是“只看代码，不写代码”，模型的职责是发现问题，不是替你修问题。

第二步是撰写角色和任务描述。我的做法是先在预设的 system 提示词里写清楚角色的资历和审查原则：比如“你是一名有 10 年经验的资深代码审查员，擅长发现安全隐患、性能瓶颈和设计缺陷。你的审查原则是：优先报告影响线上稳定性的问题，其次是有潜在安全风险的问题，最后才是代码风格和可维护性建议。”

第三步是配置模型参数。代码审查这个任务对温度要求很低，我一般把 temperature 设为 0.1 到 0.2，让输出尽量确定、可复现。最大 token 数根据代码量来调，审查单个文件用 2000，审查整个项目就用 8000，避免输出到一半空间不够。

第四步是绑定工具。代码审查员至少需要两个工具：文件读取工具和代码搜索工具。文件读取工具负责读取指定代码文件，代码搜索工具负责在项目里查找相关的函数定义和引用关系。没有这两个工具，模型就只能靠你复制粘贴代码进来，体验完全不是一个层次。

第五步是设置输出格式。我要求代码审查员的输出严格按照下面这个模板来：

文件路径： 问题等级：严重 / 建议 问题描述： 触发场景： 修改建议：

这个模板看着简单，但它能极大提升输出的可用性。模型不再是泛泛地说“这个函数写得不够好”，而是会精确地指出文件哪一行有问题、在什么场景下会触发、应该怎么改。

配置完成后，我会先拿一个自己很熟悉的项目去测试，看看模型的审查结果是否真的对应到具体的问题。如果发现有说得不到位的地方，就回去微调提示词——这个过程迭代多了之后，预设会越来越精准。

3.4 预设的迭代思维：没有一次到位的预设

我要特别强调一个观点：Agent 预设不是一个一次配好就永久使用的东西，它需要持续迭代。

我最初配的“代码审查员”预设，输出结果说实话不太满意，模型经常给出一些模板化的、放之四海而皆准的建议，比如“注意输入验证”这种废话。后来我调整了策略，在预设里加入了“必须引用具体的函数名和行号，禁止给出没有代码依据的泛泛建议”这条硬性要求。加了之后，输出质量立刻上了一个台阶。

同样的道理也适用于其他预设。写“产品经理”预设时，一开始你可以把角色描述写得宽泛些，先用起来，观察模型哪些回答让你觉得“聪明”，哪些回答让你觉得“跑偏”。然后针对性地在预设里补充规则——比如“在给出方案前，先说明用户场景和痛点”、“每个功能建议必须包含优先级和实现成本评估”。这些规则都是你和模型多次交互之后总结出来的“定制需求”，不是从网上抄来的模板能比的。

所以我建议每个 Harness 用户都养成一个习惯：每次用完一个预设，如果觉得某次输出好于预期或者差于预期，顺手打开预设编辑界面，把触发优秀输出的条件固化下来，把触发垃圾输出的条件排除掉。这种迭代不需要很长时间，一两次就能让预设产生质变。我自己现在用的大部分预设，都是经历了好几轮迭代后的版本，和最初的版本相比，效果差距非常大。

4. 实操过程与核心环节实现

4.1 环境准备：确保你的 Harness 处于可调优状态

开始实操之前，先确认你的 Harness 环境是完好的。我这套配置在 Windows 11 桌面端和 Ubuntu 22.04 服务器端都跑过，实际操作上没有本质区别，只是路径和启动方式有一点差异。

先检查几个基础项。第一，Harness 版本不要太旧，很多设置项和预设功能是后续版本才加的，版本太老你会在界面里找不到对应的选项。第二，确认至少有一个可用的模型服务接入，无论是本地模型还是云端 API，因为接下来做预设测试时需要真实调用模型。第三，把日志等级先切到 debug，方便观察运行过程。这三个基础项搞定了，后面的操作才有效果，运行情况一目了然。

4.2 通用设置调优完整流程

我从零开始，展示一套完整的通用设置调优流程，你可以边看边照做。

第一步，打开通用设置面板。进入设置项后，先找到模型接入区。如果你用的是云端 API，检查一下 base URL 和模型名是否准确。举个例子，DeepSeek 官方 API 的 base URL 一般是https://api.deepseek.com，模型名填deepseek-chat或deepseek-reasoner，取决于你要用普通对话模型还是推理模型。这里很多人会把deepseek-reasoner当成一个单独的助手来用，其实它就是一个偏重推理能力的模型标识，在 Harness 里直接挂那边就行。

如果你和我一样在自己电脑上跑 Ollama，base URL 就是http://localhost:11434/v1，模型名填你本地拉取的模型标签，比如qwen2.5-coder:14b或llama3.1:8b。

第二步，设置上下文窗口。我的建议基准是：本地模型按模型标签对应的上下文长度打个七到八折；云端 API 按服务方给出的最大上下文减掉 8000 token 左右的余量。这个余量不是随便拍的，我在长期使用中观察到，Harness 在涉及工具调用的任务里，平均需要预留 4000 到 8000 token 的空间才比较稳妥。

第三步，调整并发和超时。先说一下我的操作逻辑：如果你日常任务是对话问答，并发数保持默认的 1 或 2 即可，不需要为了“看起来快”而调高，因为你同时开两个窗口聊天的场景其实不多。如果你经常做批处理或文档分析，就把并发调到 3 或 4。这里我特别提醒一下：并发数不要贪心，我用云端 API 时试过调成 8，结果 API 服务端直接开始限流，报错反而比之前更频繁。超时时间统一设为 300 秒即可，重任务临时往上调，日常用这个值完全够。

第四步，保存设置并重启会话。这一步很多人会漏掉。Harness 的某些设置项，修改后需要新建一个会话才能完全生效，尤其是在同一个会话里改上下文窗口或并发数，很容易出现“改了跟没改一样”的感觉。我的习惯是改完设置后，首先新建一个测试会话，跑一个简单的问答确认连接正常，再跑一个工具调用类任务确认上下文和并发没出问题。

4.3 创建第一个 Agent 预设：手把手操作指南

接下来是 Agent 预设的创建流程。我会走得细一些，因为我发现很多人卡住的不是概念，而是具体界面上不知道先点哪里。

打开预设管理面板后，点击新建预设。第一个要填的是预设名称，我建议直接用能表达功能的名字，比如“代码审查员”“需求分析师”“API文档生成器”。别用什么“预设001”这种名字，等你的预设列表超过五个，你就会发现命名规范有多重要。

然后填写 System Prompt。这个字段是预设的灵魂，承载的是前文说的角色描述和任务规则。我的建议是不要用一段话把所有内容写进去，而是用结构化分行的方式，让模型更容易理解优先级。

以我前面提到的“代码审查员”为例，System Prompt 我实际填的内容大致是：

你是一名拥有十年开发经验和三年安全审计经验的资深代码审查员。 你的任务：审查用户提供的源代码或项目目录，发现问题并输出报告。 审查维度： 1. 安全性：重点关注注入风险、敏感信息泄露、权限绕过等问题。 2. 性能：重点关注循环内的高开销操作、不必要的序列化、内存泄漏风险。 3. 可维护性：重点关注命名规范、函数复杂度、模块间耦合度。 规则： - 每个问题必须包含对应文件名和行号。 - 禁止输出没有任何代码依据的泛泛建议。 - 如果代码中没有某类问题，请明确说明"未发现xxx问题"，不要为了凑数而输出幻想问题。 输出格式严格遵循下方的格式模板。

这段提示词就是我说的“宽度窄，深度深”，给模型划定了边界，同时也把行为规范写到很具体，不会让模型自由发挥。

接下来是工具配置。不同的预设应该绑定不同的工具，这里的原则是够用就行，别一股脑全挂上。代码审查员绑定“代码搜索”和“文件读取”两个工具就足够了。如果你挂了太多工具，模型反而会困惑，甚至出现该用的工具没调、不该用的工具胡乱调的情况。

再往下是模型参数。代码审查员预设的温度我设为 0.2，最大输出 token 数设为 4000，上下文窗口沿用通用设置里的值。如果你配的是创意写作类预设，温度可以调到 0.7 到 0.9；但代码审查、数据提取、逻辑推理这类任务，温度低就是王道，越低越稳定。

最后保存预设，然后在会话入口选择这个预设，跑一个真实的代码文件试试效果。如果效果不达预期，回到编辑界面微调 System Prompt，而不是放弃——每个好用的预设都值得你这么折腾。

4.4 预设的导出与复用：团队协作的隐藏功能

除了创建和使用预设，预设的导出和复用也是一个被很多人忽略的实用功能。尤其是你在多台电脑上使用 DeepSeek Harness，或者想把自己的配置分享给同事时，这个功能能省下大把时间。

在预设管理面板里，通常会有一个导出或复制配置的选项。导出的内容一般是一个 JSON 或 Markdown 格式的文本，里面包含了预设的名称、System Prompt、绑定的工具列表、模型参数等完整配置。你只需要把这个配置文件复制到另一台机器，再通过导入功能加载，就能拥有完全一致的预设。

我自己在团队协作场景里用过一次，效果非常好。当时我们团队有一个固定的“需求拆解”预设，是反复调了很多轮才调顺的，我直接导出配置发到群里，其他同事导入之后就能用出相同的效果。这比让他们自己重新摸索省了不知道多少时间。

不过这里有个注意点：预设导出的是配置，但不包含你本地的文件或对话记录。换到另一台新机器上，如果相应的工具或本地模型没有配置好，预设可能无法正常工作。所以导入之后，先确认工具和模型接入是否到位，再开始正式使用。

4.5 多 Agent 协作配置：一次并行工作的尝试

当单个预设已经用顺了之后，下一个值得探索的方向是让多个 Agent 协作。Harness 支持在一个工作区里同时运行多个预设，这个我以前以为是加分项，用过之后觉得已经接近刚需了。

我实际做过的一个案例是“竞品分析报告生成”。我的做法是创建三个预设：一个负责信息收集，一个负责产品功能对比，一个负责最终报告整合。信息收集 Agent 先基于你给定的关键词抓取或检索信息，把整理好的碎片文本送给产品对比 Agent；产品对比 Agent 基于收到的内容，逐维度的输出差异分析；最后的报告整合 Agent 再把这些分析按照固定模板组织成一份完整报告。

这里的协作关键点是每个预设的输出格式必须足够结构化，因为前一个 Agent 的输出是后一个 Agent 的输入。如果第一个 Agent 输出的只是大段散文，第二个 Agent 要从中提取结构化信息会很吃力，而且容易遗漏。所以我在配多 Agent 流程时，会给每个参与协作的预设都加上“输出格式必须为 Markdown 列表/表格”之类的硬性要求。

我第一次跑这个流程时，中间就出了问题——信息收集 Agent 输出里塞了很多无关内容，导致对比 Agent 的分析很散。后来我调整了信息收集预设的输出规则，要求它只输出“功能名称、适用对象、核心特点、局限性”四个字段的信息，其他内容一律不要。改完之后，整条流程一下就顺畅了。

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

5.1 问题速查表：先对照这里再动手

这里整理了一份我高频遇到、也高频被群友问到的 Harness 配置问题速查表。你在实际使用中如果遇到类似的报错，可以先对照排查，再考虑深入调试。

这张表不是万能的，但覆盖了绝大部分入门和进阶过程的拦路虎。如果你遇到的问题不在这张表里，那就去打开 debug 日志，通常能从底层找到线索。

5.2 排查实操：一次断流问题的完整复盘

分享一个我印象深刻的问题排查过程，整个过程可以帮助你建立一种“问题定位思路”。

有一次我做一批文档分析，Harness 突然在跑第 7 个文件时报错，提示内容很模糊，只说“请求失败”。我没有急着重新点一次，而是先打开了 debug 日志，看看这次失败到底发生在哪个环节。

从日志里我发现了两个关键信息。第一，第 7 个文件本身特别长，读取后已经把当前会话的上下文空间占了大半。第二，请求失败的原因是模型返回了一个超长的分析结果，而这个结果加上上下文已有的内容，超出了模型的最大输出限制。

定位到这个原因后，我做了两件事：一是把这个任务的上下文窗口整体扩大，二是把这个会话拆成两个子会话，让模型分批处理。重新跑完之后，问题没有再出现。

这次排查给我最大的启发是：Harness 里的很多故障，表面上看是“模型不行”，实际上是“配置没给够”。如果你把日志打开认真看一遍，大多数问题都会变得清楚得多。

5.3 为什么你的工具调用总“不听话”

工具调用不听话，是一个几乎每个人都会遇到的问题：你可以看到 Harness 已经识别到需要调用工具，但调用的参数总是不对，或者该调工具的时候不调，不该调的时候乱调。

这个问题的根源，往往不在工具本身，而在预设有问题。当你同时给一个 Agent 挂了很多工具，模型反而会产生“选择困难”。有一次我为了测试方便，给一个简单的问答预设挂了四个工具，结果它连“今天是星期几”这种问题都要去调用一下日历工具，纯粹是傻掉的节奏。

解决方法是把工具集瘦身，只给模型必要的少数工具。每加一个工具，模型就多一个“注意力分叉的概率”。把工具数量控制到 2 到 3 个，你会惊喜地发现工具调用的准确率大幅提升。

另外还有一个很有用的技巧：在 System Prompt 里显式说明“什么情况下必须调用某个工具”。比如，你不想让模型在没有代码文件输入时调用文件读取工具，就在预设里写明“仅当用户提供代码文件路径时才能调用文件读取工具”。这种显式的触发条件比让模型自己去猜要靠谱得多。

5.4 预设输出不稳定的实战调优法

最后分享一个关于输出稳定性的技巧，这个方法对我来说非常有效，所以放在最后单独讲。

很多人配置好预设后，发现同样的问题，每次拿到的答案都不一样，有的好有的差。这是模型本身概率采样带来的结果，无法完全消除，但可以通过参数设置大幅降低波动。

我调稳定性的三板斧：

第一，把 temperature 调低。对于大多数任务，0.1 到 0.3 是比较稳的区域，除非你真的需要创造性输出，才往 0.8 以上调。

第二，在 System Prompt 里加一句：“请根据已有的信息和规则逐步推理，不要跳跃，不要臆测缺失信息。”这句话能很有效地减少模型“编造”的输出，让它的思维更收敛。

第三，固定输出模板。模板的作用不是限制模型，而是给模型的输出建立统一的结构。模板固定了，输出结构就稳定，即使细节有偏差，整体可用性也在线。

这套调优方法我推荐给所有觉得 Harness 输出“飘”的朋友。你要是试过还觉得飘，那大概率不是配置问题，而是当前模型本身在这个领域的能力就到那个程度了，可能需要换一个更强的模型或者拆解任务重新设计预设。别在同一套配置上死磕，合适的预设和模型配合才最重要。

6. 最后再分享一个实用小技巧

6.1 给你的预设添加故障自检机制

前面讲了这么多，最后分享一个小技巧：在新用的 Agent 预设里加一段“故障自检提示词”。这段提示词很短，但实际效果很好。

我在每个关键预设的 System Prompt 末尾都会加上一句话：“如果你发现获取的信息不足，无法完成上述任务，请在回答开头明确说明缺少哪些信息，而不要直接猜测回答。”

理由很简单，模型最怕的是在信息不足时强行脑补答案。你让它承认“我没法判断”，比让它编一个像模像样的答案要难得多。但只要你在预设里明确允许它说“不知道”，它给出的回答质量往往会高很多。

我实测下来，加了这句话之后，预设的输出从“每次都给你一个看似完整的啰嗦答案”变为“大部分时候高质量完成，信息不足时快速向你追问”。这种变化在代码审查、报告生成这类长任务上特别明显，因为长任务的信息不足会导致整个输出方向跑偏，与其让模型硬跑到底再纠错，不如让它一开始就向你确认。

这个习惯我建议你保持下去，它能让你的预设配置思维提升一个维度，把“让模型给出答案”变成“让模型在明确的前提下给出可靠的答案”，在复杂场景下真的可以救一次任务。

以上这些就是我折腾 DeepSeek Harness 一段时间后，在通用设置和 Agent 预设上积累下来的全部核心经验。配置这个东西，没有绝对正确的答案，只有适合自己的答案。关键是在了解每个设置与参数背后的逻辑之后，结合自己的使用场景去验证、去调整。希望这篇文章能给刚接触或正在受困于 Harness 配置的你一些实际帮助。