Hermes + DeepSeek Harness：多Agent协作从理论到落地

之前在做 Agent 项目的过程中，一直有一个问题困扰我：单个 Agent 能写代码、能查资料，但真正放到业务里，总会遇到“上下文被撑爆”“改一个需求导致全线返工”“两个 Agent 互相覆盖文件”这类尴尬情况。网上关于多 Agent 协作的讨论很多，但真正能落地的实测教程却不多，更少有人解释清楚背后的 Harness（执行容器/调度框架）到底是怎么把多个 Agent 组织起来的。

这篇文章围绕“Hermes + DeepSeek Harness”这个组合来做一次实操向的实测拆解。我会先讲清楚 Agent、Harness、模型这几个概念分别承担什么角色，再带大家从零实现一个可运行的多 Agent 协作 Harness，让它完成“需求拆解 → 代码生成 → 代码审查”的完整闭环。整个过程会包含完整代码、运行结果和常见报错排查，适合已经会用 Python、想深入 Agent 工程化的开发者，也适合刚接触多 Agent 设计、需要一份系统资料的新手。

1. 背景与核心概念

1.1 多 Agent 协作为什么是个难题

很多人第一次接触 AI Agent 时，会觉得“多个 Agent 一起干活”就是把几个 ChatBot 放在同一个群里，让它们互相讨论。真实工程里远没有这么简单。一个 Agent 是一个“能感知环境、做决策、执行动作”的程序单元，它背后至少包含三个部分：模型调用能力、工具调用能力、任务状态管理能力。当多个 Agent 同时存在时，它们之间需要共享哪些信息？以谁的意见为准？一个 Agent 执行失败，其他 Agent 是继续还是等待？这些问题不解决，多 Agent 系统就是一个杂乱无章的“群聊现场”。

多 Agent 协作真正的难点不是“能不能调用”，而是“能不能可靠地编排”。比如常见的“需求分析 Agent + 编码 Agent + 测试 Agent”流水线，需求 Agent 输出的结论是自然语言，编码 Agent 如何把它转换成严格的结构化任务？编码 Agent 写完代码，测试 Agent 如何知道代码在哪个目录？这些依赖关系需要一套显式的调度机制来维护，而不是靠模型自己“临场发挥”。这也是 Harness 类框架存在的根本原因：把 Agent 的执行过程从“自由对话”变成“可控流程”。

1.2 什么是 Agent Harness

Harness 这个词在 Agent 工程里有两层含义。从广义上讲，Harness 是“承载 Agent 运行的环境”，包括模型访问、工具注册、上下文管理、任务队列、错误处理等基础能力。从狭义上讲，Harness 是“Agent 执行循环”的实现体，它负责接收一个高层目标，然后循环执行“让模型推理 → 模型请求调用某个工具 → 执行工具 → 把结果交回给模型 → 模型继续推理”这个过程，直到完成任务。

可以把它类比成流水线中的传送带。每个 Agent 是工位上的工人，负责具体工序；Harness 是传送带和控制系统，决定工件什么时候送到哪个工位、工序之间如何衔接。没有 Harness，Agent 之间只能靠提示词约定；有了 Harness，Agent 之间的通信、工具权限、执行顺序才能被程序化控制。

在实际场景中，Harness 通常还会承担“多 Agent 调度器”的功能。它手里维护一张 Agent 注册表，里面记录了每个 Agent 的职责描述、可用工具和模型配置。调度器根据目标任务选择合适的一个或多个 Agent，并把上下文按需传递给它们。

1.3 Hermes 与 DeepSeek 在 Agent 工程中的定位

从本次实测的角度来看，Hermes 与 DeepSeek 分别代表了两类不同的角色。

DeepSeek 在这里是“推理底座”。DeepSeek 提供了兼容 OpenAI 格式的模型 API，它的 deepseek-chat 和 deepseek-reasoner 模型在中文场景下的代码生成、逻辑推理和指令理解能力都比较稳定。在多 Agent 系统中，把 DeepSeek API 接入 Harness 的成本很低，因为社区里大部分 Agent 框架都支持 OpenAI 兼容接口，而 DeepSeek 的接口结构和 OpenAI 基本一致，只需要改 base_url 和 model 名称。

Hermes 在这里更多是“Agent 角色模型”的代称。开源社区中 Hermes 这个名字通常指 Nous Research 发布的系列微调模型，这类模型经过指令微调和工具调用增强，特别适合被放到 Agent 工作流里扮演某个固定角色。你可以把整体理解成：DeepSeek 负责“想”，Hermes 负责“做”，而 Harness 负责“调度”。当然，Hermes 和 DeepSeek 都可以既做推理又做执行，具体怎么分工取决于你的实际部署方式。

需要说明的是，当前社区中关于“Hermes Agent”“DeepSeek Harness”的讨论很多，不同教程指向的具体项目可能并不完全相同。本文的实测重点不依赖某个封闭的商业软件，而是围绕 Agent Harness 的通用设计思路展开。你可以用它来理解任何 Harness 类工具，也可以直接把代码改造成自己的多 Agent 调度系统。

1.4 Agent、Harness、Workflow 三者区别

在阅读大量 Agent 相关文章时，最常见的问题就是把 Agent、Harness、Workflow 三个概念混为一谈。这里用一个表格来区分：

用一句话概括：Workflow 描述“要做哪些步骤”，Harness 决定“这些步骤由谁来执行、怎么执行”，Agent 负责“执行某个具体步骤”。这篇实测里的代码主要落在 Harness 层，也就是实现一个轻量级调度器，把多个 Agent 挂到同一套执行环境中。

2. 环境准备与整体架构

2.1 硬件与软件环境

本次实测是一个偏工程化的 Demo，不依赖重型分布式环境。推荐环境如下：

操作系统：Windows 10/11、macOS 或 Linux 均可 Python 版本：3.10 及以上 依赖库：openai、python-dotenv、typing 模型接入：DeepSeek API（需提前申请 API Key）

如果你希望把 Hermes 模型也接入进来，可以用支持 OpenAI 兼容接口的本地推理服务（比如 vLLM、Ollama）或者远程模型网关。版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

2.2 架构设计

为了让“多个 Agent 真的能一起干活”这个命题有可验证性，我设计了一条经典的“三 Agent 流水线”：

用户输入需求 ↓ [需求分析 Agent] ---- 产出结构化任务书（JSON） ↓ [编码 Agent] ---- 根据任务书生成代码文件 ↓ [代码审查 Agent] ---- 检查代码问题并返回审查意见 ↓ Harness 汇总结果，输出最终报告

在这个架构中，Harness 调度器不直接处理业务逻辑，它只做三件事：维护上下文、调用 Agent、收集结果。每个 Agent 做的事也很单一：需求分析 Agent 负责把用户输入转成结构化任务，编码 Agent 负责写代码，审查 Agent 负责挑毛病。这种“单一职责 + 显式传递”的设计，是避免多 Agent 系统陷入混乱的关键。

2.3 项目结构

整个实验项目采用下面的目录结构：

hermes-deepseek-harness/ ├── .env # 存放 API Key ├── requirements.txt # 依赖清单 ├── main.py # 入口文件，启动整个流程 ├── harness.py # Harness 调度器核心 ├── agents.py # 三个 Agent 的角色定义 └── llm_client.py # 统一的大模型调用客户端

这个结构足够简单，又能把“调度器”和“Agent”分清楚。后面每一部分代码都会给出完整版本。

3. 核心原理拆解：多个 Agent 如何被“调度”到一起

3.1 工具调用循环

在写 Harness 之前，先理解单 Agent 的工具调用循环。绝大多数 Agent 框架的核心都是下面这个循环：

1. 系统提示词 + 用户输入拼接成上下文。
2. 模型返回推理结果，可能包含一个工具调用请求。
3. Harness 解析工具调用请求，执行对应函数。
4. 把函数结果以 system 消息的形式追加到上下文。
5. 再次调用模型，让模型基于工具结果继续推理。
6. 重复，直到模型认为任务完成。

这个过程看起来很直接，但有几个工程细节决定了系统的稳定性：工具调用请求必须是结构化格式（比如 JSON），不能依赖模型输出的自然语言描述；工具执行必须有超时控制，否则一个卡死的工具会拖住整个 Agent；上下文必须做长度管理，否则多轮工具调用后 Token 会迅速膨胀。

在本文的多 Agent 设计中，每个 Agent 的核心不是“调用工具”，而是“调用另一个模型处理后的产物”。也就是说，前一 Agent 的输出会成为后一 Agent 的输入，这本质上也是一种工具调用，只不过工具变成了另一个 Agent 的执行结果。

3.2 协作模式对比

多 Agent 之间的协作并不只有“流水线”这一种模式。常见的还有以下几种：

本次实战采用的是第一种“流水线模式”，原因很直接：可验证性强，每个阶段都有明确产物，出了问题能快速定位到具体 Agent。等熟悉了这套模式，再去扩展路由模式或者群聊模式会容易得多。

3.3 DeepSeek API 接入方式

DeepSeek 的接口兼容 OpenAI 协议，这意味着我们不需要额外引入 DeepSeek 专用 SDK，直接使用 openai 库，把 base_url 指向 DeepSeek 的接口地址即可。这在实际接入时有很大优势：代码可以保持通用，未来切换其他 OpenAI 兼容服务时不需要重写客户端。

核心代码如下：

# 文件路径：llm_client.py from openai import OpenAI import os def create_llm_client(): return OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com") )

调用时可以指定模型名称，比如 deepseek-chat。生产环境中不要把 API Key 硬编码到代码里，建议统一从环境变量或配置中心读取。后续代码中，我们所有 Agent 都通过这个 client 与大模型通信。

4. 完整实战：搭建一个三 Agent 协作 Harness

4.1 创建项目环境

首先创建虚拟环境并安装依赖。

mkdir hermes-deepseek-harness cd hermes-deepseek-harness python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate

然后创建 requirements.txt：

openai>=1.0.0 python-dotenv>=1.0.0

安装依赖：

pip install -r requirements.txt

在项目根目录创建 .env 文件：

DEEPSEEK_API_KEY=sk-your-deepseek-api-key DEEPSEEK_BASE_URL=https://api.deepseek.com HARNESS_MODEL=deepseek-chat

说明：DEEPSEEK_API_KEY 需要替换成你在 DeepSeek 开放平台申请到的真实 Key。不要把 Key 提交到 Git 仓库中。

4.2 编写统一的 LLM 客户端

为了让后续每个 Agent 都能调用大模型，并且方便统一处理超时和异常，先封装一个“对话补全”函数。它会调用 DeepSeek API，并自动把拆分好的消息列表发过去。

# 文件路径：llm_client.py import os from typing import List, Dict from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com") ) HARNESS_MODEL = os.getenv("HARNESS_MODEL", "deepseek-chat") def chat(messages: List[Dict[str, str]], model: str = HARNESS_MODEL) -> str: """发送消息列表，返回模型回复文本。""" response = client.chat.completions.create( model=model, messages=messages, temperature=0.3, ) return response.choices[0].message.content.strip()

这里把 temperature 设置为 0.3，是希望 Agent 在多步骤协作时输出更稳定。如果是创意生成类任务，可以适当调高。注意：DeepSeek 官方对不同模型有各自的参数兼容范围，如果实际调用报参数不支持，需要按当前模型文档调整。

4.3 实现 Harness 核心调度器

接下来是整篇文章最关键的部分：Harness 调度器。它需要做到：

• 接收用户输入。
• 按顺序调用三个 Agent。
• 保存每个 Agent 的输出到上下文列表。
• 最后汇总成总报告。

先看代码：

# 文件路径：harness.py from typing import List, Dict class AgentHarness: def __init__(self, agents: List[Dict]): """ agents 参数是一个列表，每个元素包含： { "name": "agent 名称", "run": callable, # 接收 context，返回输出文本 "description": "agent 职责描述" } """ self.agents = agents self.context_summary: List[str] = [] def run(self, user_input: str) -> Dict[str, str]: """ 按照 Agent 注册顺序依次执行。 前一个 Agent 的输出会作为上下文的一部分传给后一个 Agent。 """ current_input = user_input results = {} for agent in self.agents: print(f"========== 正在运行 Agent：{agent['name']} ==========") output = agent["run"](current_input, self.context_summary) results[agent["name"]] = output self.context_summary.append(f"[{agent['name']} 输出]\n{output}") current_input = output return results

这个调度器虽然短，但已经包含了多 Agent 协作的核心思想：每个 Agent 看到的是“原始输入 + 之前所有 Agent 的输出”，从而保持上下文延续性。它的缺陷也很明显——没有做并发、没有做任务中断恢复。在实际生产环境中，你要根据需求为每一个 Agent 增加超时、重试、日志跟踪等能力。

4.4 定义三个 Agent

下面定义三个角色 Agent。这里的“Agent”并不是一个复杂的独立进程，而是“一个带有固定系统提示词的模型调用函数”。这种轻量 Agent 适合实验验证，也容易理解。

先创建 agents.py 文件：

# 文件路径：agents.py import json from llm_client import chat # ---------- Agent 1：需求分析 Agent ---------- REQUIREMENT_SYSTEM_PROMPT = """ 你是一个资深的需求分析专家。你的任务是把用户模糊的需求整理成一份结构化任务书。 任务书必须使用 JSON 格式输出，包含以下字段： - task_name: 任务名称 - task_description: 任务描述 - acceptance_criteria: 验收标准（数组） - suggested_files: 建议创建的文件列表（数组） 不要输出 JSON 之外的任何解释。 """ def requirement_agent(user_input: str, context_summary: list) -> str: messages = [ {"role": "system", "content": REQUIREMENT_SYSTEM_PROMPT}, {"role": "user", "content": f"原始需求：{user_input}"} ] # 把前面 Agent 的输出也放进去，保证上下文完整性 for ctx in context_summary: messages.append({"role": "assistant", "content": ctx}) return chat(messages) # ---------- Agent 2：编码 Agent ---------- CODING_SYSTEM_PROMPT = """ 你是一个高级 Python 工程师。你需要根据需求分析 Agent 输出的结构化任务书，编写可直接运行的代码。 要求： 1. 代码以 Markdown 代码块形式输出。 2. 代码必须完整，不能写伪代码。 3. 需要解释关键设计时，可以在代码块前后用简短中文说明。 """ def coding_agent(user_input: str, context_summary: list) -> str: messages = [ {"role": "system", "content": CODING_SYSTEM_PROMPT}, {"role": "user", "content": f"当前任务说明：{user_input}"} ] for ctx in context_summary: messages.append({"role": "assistant", "content": ctx}) return chat(messages) # ---------- Agent 3：代码审查 Agent ---------- REVIEW_SYSTEM_PROMPT = """ 你是一名代码审查专家。请认真检查代码中是否存在以下问题： - 语法错误 - 潜在空指针或异常 - 格式化问题 - 边界条件缺失 - 安全隐患 输出审查报告，包含： 1. 总体结论（通过/不通过） 2. 发现的问题列表 3. 修改建议 """ def review_agent(user_input: str, context_summary: list) -> str: messages = [ {"role": "system", "content": REVIEW_SYSTEM_PROMPT}, {"role": "user", "content": f"待审查代码：\n{user_input}"} ] for ctx in context_summary: messages.append({"role": "assistant", "content": ctx}) return chat(messages)

这里有个设计细节值得注意：每个 Agent 的系统提示词非常明确，特别是需求分析 Agent，我要求它必须输出 JSON。多 Agent 系统最怕的就是“上下文污染”，如果需求分析 Agent 输出了一段详细描述，编码 Agent 又把它扩大成更多描述，最终就可能彻底偏离原始需求。所以每个 Agent 的提示词里都强调了“只输出你职责范围内的内容”。

4.5 运行完整流程

最后一步，编写入口 main.py：

# 文件路径：main.py from harness import AgentHarness from agents import requirement_agent, coding_agent, review_agent def main(): # 注册三个 Agent，执行顺序就是列表顺序 harness = AgentHarness([ { "name": "需求分析Agent", "run": requirement_agent, "description": "把用户需求转成结构化任务书" }, { "name": "编码Agent", "run": coding_agent, "description": "根据任务书生成 Python 代码" }, { "name": "代码审查Agent", "run": review_agent, "description": "审查代码并给出修改建议" } ]) user_input = "请写一个 Python 函数，读取 CSV 文件，返回其中所有数值列的平均值，并在遇到空值时跳过。" results = harness.run(user_input) print("\n================= 最终结果 =================") for agent_name, output in results.items(): print(f"\n--- {agent_name} ---") print(output) if __name__ == "__main__": main()

运行命令：

python main.py

4.6 预期输出与验证

由于大模型的输出具有一定随机性，无法保证每次完全一致，但整体流程应当符合下面的趋势：

1. 需求分析 Agent 会输出类似下面的 JSON：

{ "task_name": "CSV 数值列平均值计算函数", "task_description": "实现一个函数，读取指定 CSV 文件中的全部数值列，计算每列平均值，遇到空值则跳过。", "acceptance_criteria": [ "能正确处理存在空值的 CSV", "返回值是各数值列平均值的字典", "非数值列不参与计算" ], "suggested_files": [ "csv_average.py", "test_csv_average.py" ] }

2. 编码 Agent 会基于上面的 JSON 生成完整 Python 代码，可能包括 pandas 或 csv 模块实现。这一步可能输出类似下面的代码：

import csv from typing import Dict def csv_average_by_numeric_columns(file_path: str) -> Dict[str, float]: result = {} with open(file_path, newline='', encoding='utf-8') as f: reader = csv.DictReader(f) column_values = {} for row in reader: for key, value in row.items(): if value == '' or value is None: continue try: num = float(value) except ValueError: continue column_values.setdefault(key, []).append(num) for key, values in column_values.items(): result[key] = sum(values) / len(values) if values else 0.0 return result

注意：这段代码是模型生成的示例，不是人工指定的标准答案。实际运行中以模型输出为准。

3. 代码审查 Agent 会输出审查报告，指出代码中需要改进的地方，比如建议增加文件不存在时的异常处理，或者建议用 pandas 提高性能。

整个流程跑通后，你会看到控制台按顺序输出三个 Agent 的结果。这就是一个最简单的“多 Agent 协作闭环”。

5. 常见问题与排查思路

在实际运行多 Agent 系统时，出现报错比出现顺利结果更常见。下面整理几个高频问题。

5.1 Agent 执行超时

错误现象：Agent 长时间没有响应，最终报错，提示类似：

The agent execution provider did not respond in time. This may indicate the model is overloaded or the API request is stuck.

可能原因：

• 大模型 API 服务端响应慢。
• 本地网络到 API 服务不稳定。
• 请求上下文中包含过多历史输出，导致模型处理时间过长。
• 使用了不支持长文本的模型，但上下文已接近上限。

排查思路：

1. 先单独调用 llm_client.chat 发送一条简单消息，确认 API 基础连通性。
2. 查看当前传入 Agent 的消息列表长度，打印最后一个 system prompt 的字符数。
3. 为每个 Agent 增加超时时间，建议设置为 60 到 120 秒。
4. 如果多次超时，考虑检查 API 余额和账号状态。

避免方法：在 Harness 层为每个 Agent 设置超时和重试机制。示例可以这样改造 harness.py 中的调度循环：

import concurrent.futures # 在 AgentHarness.run 中，为每个 Agent 添加超时控制 def run_with_timeout(agent, user_input, context_summary, timeout=90): with concurrent.futures.ThreadPoolExecutor(max_workers=1) as executor: future = executor.submit(agent["run"], user_input, context_summary) try: return future.result(timeout=timeout) except concurrent.futures.TimeoutError: return f"[Agent {agent['name']} 执行超时]"

注意：这只是超时兜底，线程池中的模型请求并不会真正被取消。更严格的做法是把超时控制下沉到 HTTP 层，openai 客户端支持 timeout 参数，可以在创建 client 时指定。

5.2 上下文过长导致报错

错误现象：程序运行一段时间后，API 返回类似“context length exceeded”的错误。

原因：每个 Agent 都往 context_summary 里追加了完整输出，导致后续 Agent 的消息列表越来越长。在真实场景中，需求分析 Agent 的输出、编码 Agent 的代码、审查 Agent 的报告会全部打包传给下一轮，Token 消耗迅速上升。

解决方案：

• 只传递当前 Agent 需要的“上游摘要”，而不是所有历史输出。
• 用文本截断：当下文超过一定长度时，只保留开头和结尾。
• 用更结构化的上下文对象替换字符串列表，按字段存放各 Agent 输出。

建议做法是让 Harness 维护一个字典，而不是一个无限增长的字符串列表：

self.context = { "requirement": "", "code": "", "review": "" }

这样每个 Agent 只取自己需要的字段，避免上下文膨胀。

5.3 后一个 Agent 偏离原始需求

错误现象：编码 Agent 没有严格按照需求分析 Agent 的 JSON 输出写代码，而是自己“脑补”了功能。

根本原因：Agent 的上下文里同时存在“原始用户输入”和“上游 Agent 输出”，模型可能优先关注了原始输入中模糊的描述，忽略了上游结构化的任务书。

解决思路：

• 在编码 Agent 的提示词中明确写明“只依据任务书中的 task_description 和 acceptance_criteria 进行编码，不参考原始需求文本”。
• 在上游 Agent 输出的 JSON 中增加字段，例如 generated_code 占位，强制后续 Agent 读取 JSON 中的某个字段。
• 从技术上减少自由裁量权，把 Agent 的输出解析为结构化对象后再传给下游。

5.4 API 限流与成本控制

错误现象：短时间内大量调用时遇到 429 或请求失败。

处理方式：

• 在 Harness 中增加简单的指数退避重试。
• 控制 Agent 的轮次数量，设置最大执行轮数。
• 为每个 Agent 设置不同的模型档位，比如需求分析用便宜的模型，编码和审查用更强模型。
• 实时监控 Token 使用量，防止某个 Agent 因为上下文膨胀产生超高费用。

一个简单的退避重试代码片段：

import time from openai import OpenAI client = OpenAI( api_key="...", base_url="...", timeout=30.0, max_retries=3 ) def chat_with_retry(messages, model="deepseek-chat", retries=3): for attempt in range(retries): try: response = client.chat.completions.create(model=model, messages=messages) return response.choices[0].message.content.strip() except Exception as e: if attempt == retries - 1: raise e time.sleep(2 ** attempt)

这里把 openai 客户端的 max_retries 和 timeout 都显式设置出来，避免因默认值不适合生产环境而出现长时间卡住。

6. 最佳实践与工程建议

6.1 明确每个 Agent 的边界

多 Agent 系统失控，通常不是因为单个 Agent 能力不行，而是因为职责边界不清晰。建议实现以下规则：

• 每个 Agent 只能修改自己命名空间下的文件或数据。
• 每个 Agent 的输入和输出都尽可能结构化，避免纯自然语言传递关键信息。
• Agent 之间不直接通信，所有消息都经过 Harness 中转，方便留痕和回滚。

在代码层面，可以在 Agent 注册表中增加 max_output_length 字段，限制单个 Agent 的输出长度。这样可以防止某个 Agent 输出一篇超长文档，拖垮整个上下文。

6.2 重视 Token 成本核算

多 Agent 系统比单 Agent 调用要消耗更多 Token。原因很简单：同一份上下文会被多个 Agent 重复消费。建议：

• 为每个 Agent 单独设计精简的 system prompt，不要复用整套上下文。
• 对长文本型产物做摘要，再传给下游。
• 使用结构化上下文对象，按需传递字段。
• 记录每次运行的 Token 消耗，形成基线，再逐步优化。

6.3 增加人工确认节点

在需求分析 Agent 输出结构化任务书之后、编码 Agent 开始写代码之前，建议增加一个“人类确认”节点。这个节点可以很简单：控制台打印任务书，等待用户输入 y 或 n。这样做的好处是，在需求频繁变更的场景中，可以避免 Agent 沿着错误方向执行多步。

多 Agent 系统的目标不是完全无人化，而是把人类从重复劳动中解放出来。关键决策点保留人工审批，是工程上比较稳妥的做法。

6.4 安全与权限控制

Agent 一旦接入文件系统、Shell 命令或外部 API，就相当于拥有了一定操作权限。以下几点需要特别注意：

• 最小权限原则：编码 Agent 只需要项目目录写入权限，就不给它系统级 Shell 权限。
• 敏感信息隔离：API Key、数据库账号、内部域名不要出现在提示词中。
• 输出内容检查：如果 Agent 执行代码，必须先在沙箱环境运行，不要直接在生产环境执行。
• 操作留痕：所有 Agent 的工具调用都要写入日志，方便审计。

涉及删除、覆盖文件的 Agent 操作，必须添加二次确认机制。例如，Agent 删除文件前需要检查文件是否被其他 Agent 引用。

6.5 做好日志与可观测性

多个 Agent 协作时，“这个过程发生了什么”比“最终结果是什么”更重要。建议在每个 Agent 执行前后记录：

• 输入摘要长度。
• 输出摘要长度。
• 执行耗时。
• 模型名称。
• 异常信息。

可以把这些信息输出为 JSON Lines 格式，方便后续接入日志平台或做回放分析。没有可观测性的多 Agent 系统，排错时只能靠猜。

7. 从 Demo 到生产：我的几点真实感受

经过这次 Hermes + DeepSeek Harness 方向的实测，我最明显的感受是：多个 Agent 确实能一起干活，但能不能干得好，不取决于模型本身的聪明程度，而取决于 Harness 对信息的控制精度。我见过不少团队一上来就搭建很复杂的 Agent 网络，结果大部分时间都花在调试“哪个 Agent 把上下文带偏了”上，而不是真正完成任务。

如果让我给一个务实的路线，我会建议按这样的顺序推进：先做好单 Agent 的工具调用闭环，再实现两个 Agent 的流水线协作，最后再扩展成多 Agent 网络。每一步都要有明确的验收标准。比如第一个阶段验收标准是“能稳定调用工具并处理结果”，第二个阶段是“需求分析 Agent 的输出能严格约束编码 Agent 的行为”。在没有跑通这些基础能力之前，引入再多的 Agent 只会让系统变得更脆弱。

下一步你可以继续探索方向包括：把当前串行调度改成基于任务依赖图的并行调度、引入 Agent 之间的消息队列、接入外部知识库让 Agent 具备检索能力、以及使用更强的推理模型负责主调度。多 Agent 的工程化是一个实践性很强的领域，光看文章收获有限，建议你照着本文的代码跑一遍，再改造成自己的业务需求，过程中遇到的问题一定会比想象中更具体、也更有价值。

如果这篇文章对你有帮助，可以收藏备用，后续我会继续分享更多 Agent 工程化和多 Agent 调度的实战经验。