Agent慢不是模型问题：DeepSeek Harness减少提问次数优化实战

先说结论：Agent 慢，先别急着把锅甩给模型。多数时候模型推理本身并不慢，真正让任务卡住、超时、烧 token 的，是应用层的“提问次数”太多。同样一个任务，模型只生成一次文本，和模型需要按“规划 → 工具A → 工具B → 总结 → 输出”来回调用五轮，端到端耗时差一个数量级。

DeepSeek Harness 这个名字，正好把问题点透了。Harness 在工程里是“套具/编排层”的意思，放在大模型场景下，它就是一层专门控制 Agent 和模型对话频率的优化中间层。核心思路不复杂：减少无效提问、缓存工具结果、合并独立子任务、压低上下文重复传输。这篇文章会先把“慢到底慢在哪”拆开，再给出一套可落地的测量方法、优化实现和验证流程。

如果你正在做大模型应用开发，或者发现自己的 Agent“能跑但很慢”，这篇文章可以直接收藏。下面内容不涉及训练，不依赖特殊硬件，重点是可复现的工程手段和排查清单。

1. 核心结论与能力速览

这张表是全文的路线图。后面的章节会围绕“提问次数”展开，不讨论改模型、不讨论调显卡。

2. 慢在哪：三个“问得太多”

2.1 步骤拆得太碎

很多 Agent 框架默认把任务拆成一串小步骤：先让模型理解问题，再让模型决定调用哪个工具，工具返回结果后又让模型分析，分析完又让模型决定下一步。看起来逻辑清晰，但实际上每一步都在调用大模型。

举例：一个“查天气并推荐穿衣”的任务，常规流程可能是这样：

1. 模型读取天气工具说明，输出需要调用天气工具。
2. 系统调用天气工具，拿到天气数据。
3. 模型读取天气数据，输出穿衣建议。

这里已经调用了两次大模型。如果任务有 10 个工具步骤，就可能产生 10 次以上模型调用。每次调用都有网络延迟、排队时间、推理时间和上下文拼接时间。哪怕模型单次响应只需要 1 秒，10 次串行调用后，模型时间本身就占了 10 秒，还没算工具执行时间。

更隐蔽的是，框架每轮都会把“全部历史记录”再次发送给模型。同一段系统提示词、同一段工具定义、前面所有轮次的输出结果，都会重复出现在下一次请求里。调用次数一多，Token 消耗和网络传输量也线性上涨。

2.2 上下文重复传输

DeepSeek 这类模型的推理引擎通常很快，但 Agent 的每次请求都是把“完整上下文”重新算一遍。假设一套系统提示词加工具 schema 有 2000 token，历史对话有 3000 token，那么一次请求至少传输 5000 token；如果一轮任务调用了 8 次模型，光重复传输就是 40000 token。

对比之下，单次生成只传输一次上下文。所以这里有个很反直觉的结论：模型推理单位成本不高，但“来回问”会让成本放大几倍。

2.3 独立任务串行跑

另一个常见问题是并发设计。多个互相独立的子任务，本来可以同时发送给模型，却被 Agent 框架设计成了串行调用。比如：

code复制子任务A完成 -> 返回结果
子任务B等A结束后才开始 -> 返回结果
子任务C等B结束后才开始 -> 返回结果

这只是编码习惯问题，不是模型瓶颈。只要把 A、B、C 放进并发池，总耗时就从三者之和变成三者最大耗时。

3. 先测量，再优化：建立 Agent 调用观测

不测量就优化，很容易做无用功。先把每次 LLM 调用的耗时、Token、轮次记录下来，再决定要不要减少提问次数。

3.1 需要采集的三类指标

3.2 一个最小采集类

建议在代码里加一层薄薄的观测封装。以下代码是示例，不是某个具体框架的 SDK，路径和字段需要按实际环境调整。

python复制import time
from dataclasses import dataclass

@dataclass
class CallRecord:
    round_id: int
    model_time: float
    total_time: float
    prompt_tokens: int
    completion_tokens: int
    error: str | None = None


class AgentCallTracker:
    def __init__(self):
        self.records = []

    def wrap(self, round_id, fn):
        start = time.perf_counter()
        try:
            result = fn()
            model_time = time.perf_counter() - start
            usage = result.get("usage", {})
            record = CallRecord(
                round_id=round_id,
                model_time=model_time,
                total_time=model_time,
                prompt_tokens=usage.get("prompt_tokens", 0),
                completion_tokens=usage.get("completion_tokens", 0),
            )
            self.records.append(record)
            return result
        except Exception as exc:
            record = CallRecord(
                round_id=round_id,
                model_time=time.perf_counter() - start,
                total_time=time.perf_counter() - start,
                prompt_tokens=0,
                completion_tokens=0,
                error=str(exc),
            )
            self.records.append(record)
            raise

封装之后，只要所有模型调用都走 tracker.wrap(...)，跑完一轮 Agent 任务就能输出汇总报告。

python复制tracker = AgentCallTracker()
# 在业务代码中调用
tracker.wrap(1, lambda: client.chat.completions.create(...))

# 跑完后统计
total_calls = len(tracker.records)
total_prompt_tokens = sum(r.prompt_tokens for r in tracker.records)
total_time = sum(r.total_time for r in tracker.records)

print(f"LLM 调用次数: {total_calls}")
print(f"输入 Token 总量: {total_prompt_tokens}")
print(f"模型耗时总量: {total_time:.2f}s")

3.3 如何判断优化效果

跑同一个任务，分别记录“优化前”和“优化后”的数据，重点看三个数字：

• 调用次数是否下降。
• 输入 Token 总量是否下降。
• 端到端耗时是否下降。

如果调用次数降了但总耗时没降，说明新的业务流程引入了额外等待；如果 Token 降了但调用次数没降，说明重复传输问题仍然存在。这两个信号需要分开观察。

4. DeepSeek Harness 的核心机制

这里把 DeepSeek Harness 理解为一类 Agent 编排层的统称。它不需要重训练模型，也不换推理引擎，而是在“应用代码”和“模型接口”之间增加控制逻辑。核心机制可以归纳为四类。

4.1 一次规划多动作

把模型从“每步决策”中解放出来。设计提示词时，要求模型一次性输出后续可并行执行的动作列表，而不是走一步问一次。

这种方式适合动作路径相对明确的场景。比如多文档信息抽取，可以让模型先列出“抽取什么字段、调用哪个工具”，然后应用层批量执行工具。

4.2 工具结果缓存

对同一个工具、同一组参数的调用结果做缓存。Agent 在多次会话里要查询同样的数据时，应用层直接返回缓存，不让模型参与。缓存可以加在工具执行层，也可以加在模型接口层。

从工程角度看，工具结果缓存比模型输出缓存更安全，不会因为缓存“答非所问”而污染结果。

4.3 上下文压缩

每轮调用之前，用文本摘要代替完整历史。比如前三轮对话已经完成了工具调用，第四轮需要的是最终结论和关键数据，不需要再把前三轮全文重发一遍。

上下文压缩的核心原则：模型看到的上下文，必须覆盖本轮决策所需的全部信息，但不需要包含推理过程全文。

4.4 独立子任务并发

无依赖的子任务用并发池，有依赖的再用串行。多数 Agent 性能问题不是模型慢，而是任务调度写得慢。

5. 环境准备与最小部署

5.1 基础环境

以 Python 为例，建议准备：

• Python 3.9 或更高版本。
• 一个能访问 DeepSeek 开放接口的网络环境。
• 用于管理依赖的虚拟环境。

bash复制python -m venv .venv
source .venv/bin/activate  # Windows 使用 .venv\Scripts\activate
pip install openai

5.2 接入 DeepSeek API

DeepSeek 开放接口兼容 OpenAI 的调用方式。最简单的方式是直接使用 openai Python SDK，并将 base_url 指向 DeepSeek 服务地址。具体地址和模型名以 DeepSeek 官方文档为准，下面的示例给出通用接入方式。

python复制import os
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com",  # 以官方文档为准
)

resp = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "user", "content": "用一句话介绍 Agent 性能优化"},
    ],
    temperature=0.2,
)

print(resp.choices[0].message.content)
print(resp.usage)

注意：api_key 建议通过环境变量注入，不要直接写进仓库。

5.3 Harness 最小实现

下面是一个极简的 Harness 示例，用于演示“缓存 + 并发”两个核心机制。它不代表某个官方包，只是工程思路的可运行版本。

python复制import hashlib
import json
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com",
)


class SimpleHarness:
    def __init__(self, client):
        self.client = client
        self.tool_cache = {}

    def query(self, messages):
        resp = self.client.chat.completions.create(
            model="deepseek-chat",
            messages=messages,
            temperature=0.2,
        )
        return resp.choices[0].message.content

    def tool(self, name, kwargs):
        key = hashlib.md5(
            f"{name}:{json.dumps(kwargs, sort_keys=True)}".encode()
        ).hexdigest()
        if key in self.tool_cache:
            return self.tool_cache[key]
        # 实际项目里这里调用真实工具，例如数据库查询、文件读取、搜索接口
        result = f"tool:{name} with {json.dumps(kwargs)}"
        self.tool_cache[key] = result
        return result

    def run_parallel(self, tasks):
        with ThreadPoolExecutor(max_workers=4) as pool:
            futures = [pool.submit(self.query, task) for task in tasks]
            return [future.result() for future in futures]

调用方式：

python复制harness = SimpleHarness(client)

# 工具结果第一次调用会写入缓存
result_a = harness.tool("weather", {"city": "上海"})
# 第二次调用直接命中缓存
result_b = harness.tool("weather", {"city": "上海"})

print(result_a)
print(result_a == result_b)  # True

真正的生产环境会复杂很多，但核心判断标准是一样的：有状态的结果优先缓存，无依赖的请求优先并行。

6. 功能测试与效果验证

6.1 测试目标

验证三个点：

1. Harness 是否正确缓存重复工具调用。
2. 并发任务是否减少总耗时。
3. 上下文压缩是否让 Token 总量下降。

6.2 未优化的串行调用

用一小段同步代码模拟“一个任务循环调用 10 次模型”的情况。

python复制def run_serial(task_count=10):
    results = []
    for i in range(task_count):
        resp = client.chat.completions.create(
            model="deepseek-chat",
            messages=[
                {"role": "user", "content": f"任务 {i}: 一句话说明结果"}
            ],
            temperature=0.2,
        )
        results.append(resp.choices[0].message.content)
    return results

这段代码的耗时大概率等于 10 次模型调用的耗时之和。如果网络有波动，又会被放大。

6.3 优化后的并发调用

把 10 个独立任务放到线程池里。

python复制from concurrent.futures import ThreadPoolExecutor, as_completed

def run_parallel(task_count=10):
    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = [
            executor.submit(
                client.chat.completions.create,
                model="deepseek-chat",
                messages=[
                    {"role": "user", "content": f"任务 {i}: 一句话说明结果"}
                ],
                temperature=0.2,
            )
            for i in range(task_count)
        ]
        return [f.result().choices[0].message.content for f in as_completed(futures)]

在接口并发允许的前提下，端到端耗时会明显低于串行版本。需要注意：并发数不是越高越好，要遵守模型服务方的限流规则。

6.4 一个直观的计算演示

假设某个 Agent 任务需要调用 8 次模型，平均每次输入 5000 token，模型平均每次响应 1.5 秒：

这里的数字只是计算演示，实际以你的任务复杂度为准，但趋势是确定的：减少调用次数和减少重复上下文，比“换一个更快的模型”更直接。

7. 接口 API 与批量任务

7.1 API 调用规范

Agent 最终要落到接口调用。统一格式放在配置里，便于批量替换模型、切换不同的服务地址。

python复制import os
from openai import OpenAI

LLM_CONFIG = {
    "base_url": os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com"),
    "api_key": os.getenv("DEEPSEEK_API_KEY"),
    "model": "deepseek-chat",
}

client = OpenAI(
    api_key=LLM_CONFIG["api_key"],
    base_url=LLM_CONFIG["base_url"],
)

7.2 批量任务队列

批量任务建议用队列实现，避免一次性把所有请求塞进线程池。生产环境可以引入消息队列，本地验证用 concurrent.futures 就够了。

python复制from concurrent.futures import ThreadPoolExecutor, as_completed


def batch_run(items, worker=5):
    with ThreadPoolExecutor(max_workers=worker) as executor:
        futures = {
            executor.submit(_process_one, item): item for item in items
        }
        results = {}
        for future in as_completed(futures):
            item = futures[future]
            try:
                results[item["id"]] = future.result()
            except Exception as exc:
                results[item["id"]] = {"error": str(exc)}
        return results


def _process_one(item):
    prompt = item["prompt"]
    resp = client.chat.completions.create(
        model=LLM_CONFIG["model"],
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2,
    )
    return resp.choices[0].message.content

7.3 失败重试策略

批量任务一定会遇到超时、限流、网络抖动。建议把每个任务包装成“可重试”单元，并设置重试上限。

python复制import time


def retry_call(fn, retries=3, delay=1.0):
    last_error = None
    for attempt in range(retries):
        try:
            return fn()
        except Exception as exc:
            last_error = exc
            time.sleep(delay * (attempt + 1))
    raise last_error

重试之后，超时的任务可以进入死信队列，方便后续人工处理。

8. 资源占用与性能观察

8.1 重点观察对象

8.2 Token 与内存

API 服务场景里，显存不是第一约束，Token 才是。系统提示词、工具 schema、历史记录越长，请求体越大，接口延迟越高。如果发现每次请求都在重复发送同样的长上下文，优先做缓存或摘要。

8.3 什么时候需要本地推理

如果为了数据隐私、离线处理或成本，需要本地部署 DeepSeek 系列模型，那优化目标会多一个“显存占用”。本地部署时，上下文越长，KV Cache 占用越高，显存压力越大。本文的“减少提问次数 + 上下文压缩”策略同样生效，因为请求变短意味着更低的显存峰值和更小的 KV Cache。

需要注意的是，本地部署的硬件要求与模型参数量强相关，不同模型的量化版本、上下文长度、批处理大小都会影响显存占用，实际效果需要以本机测试为准。

9. 常见问题与排查方法

10. 最佳实践与合规提醒

10.1 工程实践建议

• 先把“调用次数、Token、耗时”三个指标埋好，再谈优化。
• 第一次运行，先让一个完整任务跑通，记录基线数据。
• 小规模验证缓存和并发，避免一上来就重构整条链路。
• 批量任务必须加日志和失败重试，否则一次限流会让整个队列卡死。
• 上下文压缩要区分“关键数据”和“过程文本”，关键数据优先保留。
• 发布前做回归测试，不能只追求速度而丢掉输出质量。

10.2 合规与数据安全边界

本文介绍的优化方式涉及大量文本传输。如果业务数据包含个人信息、商业机密或其他敏感内容，调用外部模型接口前必须完成脱敏、加密和授权评估。不要在未确认授权的情况下，把版权内容、人脸信息、声音样本、私有文档直接送入模型服务。

涉及工具调用时，工具权限要最小化。Agent 能调用的接口范围越小，越不容易触发越权操作。任何批量处理流程都要保留审计日志，便于追查问题。

最后

Agent 慢这个问题，优化空间往往比想象中大。先不要急着找更快的模型，先数一数自己的流程里到底调用了多少次模型、每次请求带了多少冗余上下文。这套思路放到 DeepSeek Harness 这类编排层上也适用：少问一次，胜过模型快千分之一秒。

建议你拿一个实际任务做对比实验，记录优化前后的调用次数和端到端耗时。别把“减少提问”做成一句话口号，而是要真正落到缓存、并发、压缩和合理的任务拆分上。后续还可以继续做语义缓存、自动上下文摘要、监控面板接入、批量任务死信队列，这些都能让 Agent 从“能跑”走向“稳定高效地跑”。