之前在做 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 HarnessHarness 这个词在 Agent 工程里有两层含义。从广义上讲Harness 是“承载 Agent 运行的环境”包括模型访问、工具注册、上下文管理、任务队列、错误处理等基础能力。从狭义上讲Harness 是“Agent 执行循环”的实现体它负责接收一个高层目标然后循环执行“让模型推理 → 模型请求调用某个工具 → 执行工具 → 把结果交回给模型 → 模型继续推理”这个过程直到完成任务。可以把它类比成流水线中的传送带。每个 Agent 是工位上的工人负责具体工序Harness 是传送带和控制系统决定工件什么时候送到哪个工位、工序之间如何衔接。没有 HarnessAgent 之间只能靠提示词约定有了 HarnessAgent 之间的通信、工具权限、执行顺序才能被程序化控制。在实际场景中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 三个概念混为一谈。这里用一个表格来区分概念核心作用类比典型形态Agent一个能自主决策和执行动作的单元流水线中的工人独立的类、服务、进程HarnessAgent 运行时的执行容器和调度框架传送带 控制台调度器、运行时、框架核心Workflow一组任务和它们之间的执行顺序工位顺序表DAG、流程图、状态机用一句话概括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 框架的核心都是下面这个循环系统提示词 用户输入拼接成上下文。模型返回推理结果可能包含一个工具调用请求。Harness 解析工具调用请求执行对应函数。把函数结果以 system 消息的形式追加到上下文。再次调用模型让模型基于工具结果继续推理。重复直到模型认为任务完成。这个过程看起来很直接但有几个工程细节决定了系统的稳定性工具调用请求必须是结构化格式比如 JSON不能依赖模型输出的自然语言描述工具执行必须有超时控制否则一个卡死的工具会拖住整个 Agent上下文必须做长度管理否则多轮工具调用后 Token 会迅速膨胀。在本文的多 Agent 设计中每个 Agent 的核心不是“调用工具”而是“调用另一个模型处理后的产物”。也就是说前一 Agent 的输出会成为后一 Agent 的输入这本质上也是一种工具调用只不过工具变成了另一个 Agent 的执行结果。3.2 协作模式对比多 Agent 之间的协作并不只有“流水线”这一种模式。常见的还有以下几种协作模式发起方式适用场景优点缺点流水线模式上一 Agent 输出传给下一 Agent需求→编码→测试流程清晰、易控制不适合需要反复讨论的问题群聊模式多个 Agent 自由发言头脑风暴、方案评审信息充分容易发散、成本高路由模式调度器按任务类型分发给对应 Agent客服、工单分类灵活、扩展性好路由准确性依赖模型主从模式一个主 Agent 分解任务给从 Agent大型复杂任务主 Agent 控制全局主 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_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com) )调用时可以指定模型名称比如 deepseek-chat。生产环境中不要把 API Key 硬编码到代码里建议统一从环境变量或配置中心读取。后续代码中我们所有 Agent 都通过这个 client 与大模型通信。4. 完整实战搭建一个三 Agent 协作 Harness4.1 创建项目环境首先创建虚拟环境并安装依赖。mkdir hermes-deepseek-harness cd hermes-deepseek-harness python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate然后创建 requirements.txtopenai1.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt在项目根目录创建 .env 文件DEEPSEEK_API_KEYsk-your-deepseek-api-key DEEPSEEK_BASE_URLhttps://api.deepseek.com HARNESS_MODELdeepseek-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_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.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( modelmodel, messagesmessages, temperature0.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.py4.6 预期输出与验证由于大模型的输出具有一定随机性无法保证每次完全一致但整体流程应当符合下面的趋势需求分析 Agent 会输出类似下面的 JSON{ task_name: CSV 数值列平均值计算函数, task_description: 实现一个函数读取指定 CSV 文件中的全部数值列计算每列平均值遇到空值则跳过。, acceptance_criteria: [ 能正确处理存在空值的 CSV, 返回值是各数值列平均值的字典, 非数值列不参与计算 ], suggested_files: [ csv_average.py, test_csv_average.py ] }编码 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, encodingutf-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注意这段代码是模型生成的示例不是人工指定的标准答案。实际运行中以模型输出为准。代码审查 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 服务不稳定。请求上下文中包含过多历史输出导致模型处理时间过长。使用了不支持长文本的模型但上下文已接近上限。排查思路先单独调用 llm_client.chat 发送一条简单消息确认 API 基础连通性。查看当前传入 Agent 的消息列表长度打印最后一个 system prompt 的字符数。为每个 Agent 增加超时时间建议设置为 60 到 120 秒。如果多次超时考虑检查 API 余额和账号状态。避免方法在 Harness 层为每个 Agent 设置超时和重试机制。示例可以这样改造 harness.py 中的调度循环import concurrent.futures # 在 AgentHarness.run 中为每个 Agent 添加超时控制 def run_with_timeout(agent, user_input, context_summary, timeout90): with concurrent.futures.ThreadPoolExecutor(max_workers1) as executor: future executor.submit(agent[run], user_input, context_summary) try: return future.result(timeouttimeout) 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..., timeout30.0, max_retries3 ) def chat_with_retry(messages, modeldeepseek-chat, retries3): for attempt in range(retries): try: response client.chat.completions.create(modelmodel, messagesmessages) 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 调度的实战经验。
之前在做 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 HarnessHarness 这个词在 Agent 工程里有两层含义。从广义上讲Harness 是“承载 Agent 运行的环境”包括模型访问、工具注册、上下文管理、任务队列、错误处理等基础能力。从狭义上讲Harness 是“Agent 执行循环”的实现体它负责接收一个高层目标然后循环执行“让模型推理 → 模型请求调用某个工具 → 执行工具 → 把结果交回给模型 → 模型继续推理”这个过程直到完成任务。可以把它类比成流水线中的传送带。每个 Agent 是工位上的工人负责具体工序Harness 是传送带和控制系统决定工件什么时候送到哪个工位、工序之间如何衔接。没有 HarnessAgent 之间只能靠提示词约定有了 HarnessAgent 之间的通信、工具权限、执行顺序才能被程序化控制。在实际场景中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 三个概念混为一谈。这里用一个表格来区分概念核心作用类比典型形态Agent一个能自主决策和执行动作的单元流水线中的工人独立的类、服务、进程HarnessAgent 运行时的执行容器和调度框架传送带 控制台调度器、运行时、框架核心Workflow一组任务和它们之间的执行顺序工位顺序表DAG、流程图、状态机用一句话概括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 框架的核心都是下面这个循环系统提示词 用户输入拼接成上下文。模型返回推理结果可能包含一个工具调用请求。Harness 解析工具调用请求执行对应函数。把函数结果以 system 消息的形式追加到上下文。再次调用模型让模型基于工具结果继续推理。重复直到模型认为任务完成。这个过程看起来很直接但有几个工程细节决定了系统的稳定性工具调用请求必须是结构化格式比如 JSON不能依赖模型输出的自然语言描述工具执行必须有超时控制否则一个卡死的工具会拖住整个 Agent上下文必须做长度管理否则多轮工具调用后 Token 会迅速膨胀。在本文的多 Agent 设计中每个 Agent 的核心不是“调用工具”而是“调用另一个模型处理后的产物”。也就是说前一 Agent 的输出会成为后一 Agent 的输入这本质上也是一种工具调用只不过工具变成了另一个 Agent 的执行结果。3.2 协作模式对比多 Agent 之间的协作并不只有“流水线”这一种模式。常见的还有以下几种协作模式发起方式适用场景优点缺点流水线模式上一 Agent 输出传给下一 Agent需求→编码→测试流程清晰、易控制不适合需要反复讨论的问题群聊模式多个 Agent 自由发言头脑风暴、方案评审信息充分容易发散、成本高路由模式调度器按任务类型分发给对应 Agent客服、工单分类灵活、扩展性好路由准确性依赖模型主从模式一个主 Agent 分解任务给从 Agent大型复杂任务主 Agent 控制全局主 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_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com) )调用时可以指定模型名称比如 deepseek-chat。生产环境中不要把 API Key 硬编码到代码里建议统一从环境变量或配置中心读取。后续代码中我们所有 Agent 都通过这个 client 与大模型通信。4. 完整实战搭建一个三 Agent 协作 Harness4.1 创建项目环境首先创建虚拟环境并安装依赖。mkdir hermes-deepseek-harness cd hermes-deepseek-harness python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate然后创建 requirements.txtopenai1.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt在项目根目录创建 .env 文件DEEPSEEK_API_KEYsk-your-deepseek-api-key DEEPSEEK_BASE_URLhttps://api.deepseek.com HARNESS_MODELdeepseek-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_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.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( modelmodel, messagesmessages, temperature0.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.py4.6 预期输出与验证由于大模型的输出具有一定随机性无法保证每次完全一致但整体流程应当符合下面的趋势需求分析 Agent 会输出类似下面的 JSON{ task_name: CSV 数值列平均值计算函数, task_description: 实现一个函数读取指定 CSV 文件中的全部数值列计算每列平均值遇到空值则跳过。, acceptance_criteria: [ 能正确处理存在空值的 CSV, 返回值是各数值列平均值的字典, 非数值列不参与计算 ], suggested_files: [ csv_average.py, test_csv_average.py ] }编码 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, encodingutf-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注意这段代码是模型生成的示例不是人工指定的标准答案。实际运行中以模型输出为准。代码审查 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 服务不稳定。请求上下文中包含过多历史输出导致模型处理时间过长。使用了不支持长文本的模型但上下文已接近上限。排查思路先单独调用 llm_client.chat 发送一条简单消息确认 API 基础连通性。查看当前传入 Agent 的消息列表长度打印最后一个 system prompt 的字符数。为每个 Agent 增加超时时间建议设置为 60 到 120 秒。如果多次超时考虑检查 API 余额和账号状态。避免方法在 Harness 层为每个 Agent 设置超时和重试机制。示例可以这样改造 harness.py 中的调度循环import concurrent.futures # 在 AgentHarness.run 中为每个 Agent 添加超时控制 def run_with_timeout(agent, user_input, context_summary, timeout90): with concurrent.futures.ThreadPoolExecutor(max_workers1) as executor: future executor.submit(agent[run], user_input, context_summary) try: return future.result(timeouttimeout) 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..., timeout30.0, max_retries3 ) def chat_with_retry(messages, modeldeepseek-chat, retries3): for attempt in range(retries): try: response client.chat.completions.create(modelmodel, messagesmessages) 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 调度的实战经验。
