先来说一个很多同学都会遇到的场景你辛辛苦苦写好了一个 Agent它能调用搜索、能读文档、能写代码看起来功能很完整。可一旦把业务复杂度提上来比如同时要处理需求解析、代码生成、自动测试、结果汇总你会发现单个 Agent 根本忙不过来要么上下文越塞越满要么任务一多就开始“精神分裂”。这时候“多 Agent 协同”就成了绕不开的话题。但多 Agent 不是把几个 Agent 拼在一起那么简单。Agent 之间怎么通信、任务怎么拆、上下文怎么隔离、工具怎么共享、技能怎么扩展这些都需要一个统一的执行框架来管。这个框架就是本文要讲的 Agent Harness。本文会从零开始拆解 Agent Harness 的底层原理讲清楚它和 Agent 到底是什么关系然后带大家手写一个轻量级的多 Agent 协同 Harness最后演示如何开发一份可复用的 Skill。无论你是刚接触 AI Agent 的新手还是已经在做 Agent 工程化的后端开发者这篇文章都能给你一套可以落地的方法论和代码。1. 背景与核心概念在深入代码之前先把几个最容易混淆的概念讲清楚。很多文章把 Agent、Harness、Skill、Tool 混在一起说结果读者越看越迷糊。这里我尽量用通俗的方式解释。1.1 Harness 是什么Harness 本身的英文含义是“马具”引申为“驾驭、控制、利用”。在 Agent 工程里Agent Harness 指的是承载、调度、约束 Agent 的一套运行时框架。你可以把 Harness 理解成 Agent 的“运行容器”或“操作系统”。单个 Agent 是应用层Harness 是支撑它运行的基础设施。它负责接收用户请求解析目标。创建和管理多个 Agent 实例。完成 Agent 之间的消息传递。控制 Agent 的启动、暂停、停止。注入工具调用能力。记录运行轨迹和日志。换句话说Harness 解决的不是“单个 Agent 能不能回答问题”而是“多个 Agent 如何有序协作完成任务”的问题。1.2 Harness 和 Agent 的区别我用一张表来对比两者的定位维度AgentAgent Harness本质智能体具备规划和执行能力运行时框架负责调度和管理职责拆解任务、调用工具、生成结果生命周期管理、消息路由、上下文管理类比演员舞台解决的问题单点智能协同编排是否被用户感知不直接感知作为基础设施存在简单说Agent 是大脑Harness 是骨架和神经系统。没有 Harness多个 Agent 就是一大堆“大脑”在乱撞。1.3 为什么需要 Agent Harness在实际项目中Agent 不是孤立运行的。比如一个企业级的知识库问答系统可能需要同时协调检索 Agent、摘要 Agent、安全审查 Agent、应答 Agent。如果没有 Harness这套系统会面临几个问题第一上下文无法隔离。多个 Agent 共享一套提示词和记忆很容易互相污染。第二任务没有闭环。Agent 之间缺少明确的反馈机制任务挂起或失败后没有人重试和补偿。第三工具权限不可控。任何 Agent 都能调用任何工具安全事故概率显著上升。第四无法观测。出了问题连日志都没法按链路串起来。Agent Harness 把这些公共能力下沉到框架层业务代码只需要关心 Agent 本身的逻辑。2. 多 Agent 协同架构拆解理解了概念之后我们来看多 Agent 协同的整体架构。这是很多做 Agent 平台的团队会反复讨论的部分。2.1 单体 Agent 的瓶颈一个 Agent 做所有事情在简单场景下没问题。但业务复杂后单体 Agent 会出现几个典型瓶颈上下文迅速膨胀模型容易忽略关键信息。工具列表越来越长调用时误选率上升。安全和审核逻辑与业务逻辑耦合难以维护。某个环节升级整个 Agent 都要重新验证。因此我们需要将 Agent 按职责拆分再用 Harness 粘合起来。2.2 多 Agent 协作模式目前业界常见的多 Agent 协作模式有三种第一种是主从模式Supervisor Pattern。一个主控 Agent 负责任务分解和结果汇合多个子 Agent 负责具体执行。这种模式适合任务边界清晰的场景比如先规划再写代码再测试。第二种是流水线模式Pipeline Pattern。任务按固定阶段传递每个 Agent 只处理一个阶段。适合流程固定的业务比如“需求分析 - 代码生成 - 检查 - 发布”。第三种是组网模式Mesh Pattern。多个 Agent 可以互相调用动态协商。这种模式灵活性最高但实现复杂容易陷入无限循环。从工程落地角度主从模式最稳流水线模式最容易理解组网模式适合探索型项目。2.3 Harness 在协同架构中的位置完整的多 Agent 系统从下往上大致是这样模型层LLM - Agent 层Planner / Executor / Reviewer - Harness 层调度、上下文、工具、事件 - 工具层Tool / Skill - 应用层业务入口、APIHarness 在最核心的位置。它在 Agent 之上屏蔽 LLM 调用的复杂性在工具之下统一管理工具的注册和执行。2.4 核心组件一览一个完整的企业级 Agent Harness 至少包含以下组件Harness Engine核心引擎负责 Agent 实例创建、任务编排。Event Bus事件总线负责消息分发和订阅。Context Manager上下文管理器负责会话级和任务级的上下文隔离。Tool Registry工具注册中心统一管理外部工具。Skill Loader技能加载器负责加载和解析 Skill。Executor执行器负责和 LLM 交互解析模型输出。Observer观测器负责日志、追踪、指标采集。这些组件加起来构成了一个可以扩展、可以观测、可以治理的 Agent 运行底座。3. Agent Harness 底层原理这一节进入重点。很多人只知道 Harness 是框架却不知道它内部到底做了什么。这里我把底层原理拆成五个关键机制来讲。3.1 Agent 生命周期管理Harness 管理 Agent 的完整生命周期通常包括初始化加载 Agent 配置、注入系统提示词。待命等待任务分配。运行中正在执行用户的子任务。阻塞等待其他 Agent 返回结果或等待用户输入。结束任务完成释放资源。这个生命周期和 Java 线程池非常像。Harness 本质上就是一个可以调度 Agent 实例的资源管理器。企业级 Harness 还需要考虑并发控制、超时回收、优雅下线等问题。3.2 消息传递与事件总线多 Agent 协作的核心是消息传递。市面上的 Harness 实现方式很多但底层无非两种直接调用Agent A 知道 Agent B 的地址直接发消息简单但不解耦。事件驱动Agent 之间不直接通信通过事件总线发布和订阅消息。事件驱动是主流方案。它让每一个 Agent 都变成独立的生产者/消费者新增 Agent 不需要修改既有代码。事件总线中通常包含事件类型、事件体、事件来源、目标 Agent 等字段。实现上Python 可以用 asyncio.QueueJava 可以用 Spring 的 ApplicationEvent 或者消息中间件。复杂场景下还会引入 RabbitMQ、Kafka 做分布式事件分发。3.3 上下文管理这是 Harness 和普通任务队列最核心的区别。普通消息队列只传数据不管状态。Agent Harness 必须管上下文否则模型拿不到足够的背景信息就无法产出高质量结果。企业级 Harness 的上下文管理通常分三层全局上下文用户输入、业务常量、租户信息。会话上下文当前会话的对话历史。任务上下文当前 Agent 正在执行的子任务信息。上下文管理还涉及一个关键的工程问题上下文膨胀。当 Agent 之间的消息越来越多context 会迅速膨胀甚至超出模型窗口。常用的策略有摘要压缩、滑动窗口、关键信息提取。3.4 工具与 Skill 注册机制Harness 的另一个核心机制是工具注册。Agent 本身不能直接调用外部系统它只能通过 Harness 注入的工具函数来操作世界。工具注册一般包含以下几个元数据工具名称工具描述模型用来判断何时调用输入参数结构JSON Schema执行函数实现权限等级Skill 则是在工具之上的一层封装。一个 Skill 可以包含多步操作、提示词片段、子工具调用。比如“Spring Boot 开发规范”这个 Skill可能内置了 Controller 生成、Service 模板、配置校验等多个工具。3.5 可观测性设计生产环境跑 Agent最怕的是“黑盒”。Harness 在设计阶段就要考虑可观测性通常需要在每次 Agent 推理前记录输入 token、调用时间、模型名称在推理后记录输出内容、耗时、工具调用序列。特别建议给每一次完整的任务分配一个 trace_id像链路追踪一样贯穿所有 Agent。出现问题的时候通过 trace_id 就能快速拉出整条调用链定位是哪一步出了问题。4. 完整实战手写一个轻量级多 Agent Harness前面讲的都是理论接下来进入实操。我们用一个最小实现来演示 Harness 的核心逻辑。我选择 Python 3.10 asyncio 实现因为 asyncio 对事件循环和任务调度支持很好代码量少且容易理解。整个项目的目标是实现一个主从模式的多 Agent 协同 Harness包含一个 Planner Agent、两个 Executor Agent并通过事件总线通信。4.1 项目结构light-harness/ ├── harness/ │ ├── __init__.py │ ├── event_bus.py │ ├── context.py │ ├── agent.py │ ├── harness.py │ └── tools.py ├── skills/ │ └── code_skill.py ├── main.py └── requirements.txt这个结构涵盖了事件总线、上下文、Agent 抽象、Harness 核心、工具注册和 Skill 加载。4.2 核心代码实现首先是事件总线。这里用 asyncio.Queue 实现一个简单的发布订阅模型# file: harness/event_bus.py import asyncio from typing import Dict, List, Any class Event: 事件对象承载消息传递数据。 def __init__(self, event_type: str, source: str, target: str, payload: Any): self.event_type event_type self.source source self.target target self.payload payload class EventBus: 基于 asyncio.Queue 的简易事件总线。 def __init__(self): self._subscribers: Dict[str, List[asyncio.Queue]] {} self._queue asyncio.Queue() def subscribe(self, event_type: str) - asyncio.Queue: 订阅指定类型的事件返回一个专属队列。 queue asyncio.Queue() self._subscribers.setdefault(event_type, []).append(queue) return queue async def publish(self, event: Event): 发布事件投递给所有订阅者。 for queue in self._subscribers.get(event.event_type, []): await queue.put(event) async def start(self): 启动事件循环。 while True: event await self._queue.get() await self.publish(event)接着是上下文管理器# file: harness/context.py from typing import Dict, Any, List class ContextManager: 管理全局上下文和任务上下文。 def __init__(self): self._global_context: Dict[str, Any] {} self._task_contexts: Dict[str, Any] {} def set_global(self, key: str, value: Any): self._global_context[key] value def get_global(self, key: str): return self._global_context.get(key) def create_task_context(self, task_id: str, data: Dict[str, Any]): self._task_contexts[task_id] { data: data, history: [], } def append_history(self, task_id: str, message: str): self._task_contexts[task_id][history].append(message) def get_task_context(self, task_id: str) - Dict[str, Any]: return self._task_contexts.get(task_id, {})然后是 Agent 的抽象基类# file: harness/agent.py import asyncio from abc import ABC, abstractmethod from typing import Any from .event_bus import EventBus, Event class BaseAgent(ABC): Agent 基类所有具体 Agent 都继承它。 def __init__(self, name: str, event_bus: EventBus): self.name name self.event_bus event_bus self.running False async def send(self, event_type: str, target: str, payload: Any): 向其他 Agent 发送事件。 event Event( event_typeevent_type, sourceself.name, targettarget, payloadpayload, ) await self.event_bus.publish(event) abstractmethod async def run(self): Agent 主循环通常在这里订阅并处理事件。 pass接着是工具注册表Harness 中所有工具都统一登记在这里# file: harness/tools.py from typing import Callable, Dict, Any class ToolRegistry: 工具注册中心。 def __init__(self): self._tools: Dict[str, Callable] {} def register(self, name: str, fn: Callable, description: str ): self._tools[name] fn print(f[tool] 注册工具: {name}, 描述: {description}) def call(self, name: str, **kwargs): tool self._tools.get(name) if tool is None: raise ValueError(ftool {name} 不存在) return tool(**kwargs)最后是 Harness 核心它负责初始化事件总线、启动 Agent# file: harness/harness.py import asyncio from typing import List, Any from .event_bus import EventBus from .context import ContextManager from .tools import ToolRegistry from .agent import BaseAgent class AgentHarness: 轻量级 Agent Harness。 def __init__(self): self.event_bus EventBus() self.context ContextManager() self.tools ToolRegistry() self.agents: List[BaseAgent] [] def register_agent(self, agent: BaseAgent): self.agents.append(agent) print(f[harness] 注册 Agent: {agent.name}) async def start(self): 启动所有 Agent。 tasks [asyncio.create_task(agent.run()) for agent in self.agents] await asyncio.gather(*tasks) async def submit(self, task: str): 向 Harness 提交一个任务。 task_id ftask-{len(self.context._task_contexts) 1} self.context.create_task_context(task_id, {task: task}) await self.event_bus.publish(Event( event_typetask.submitted, sourceharness, targetplanner, payload{task_id: task_id, task: task}, )) return task_id4.3 编写具体 Agent我们先写一个 Planner Agent负责把任务拆成多个子任务# file: main.py (片段1 - Planner Agent) from harness.agent import BaseAgent from harness.event_bus import EventBus from typing import Any class PlannerAgent(BaseAgent): def __init__(self, event_bus: EventBus): super().__init__(planner, event_bus) self._queue None async def run(self): self._queue self.event_bus.subscribe(task.submitted) print([planner] 启动等待任务...) while True: event await self._queue.get() task event.payload[task] task_id event.payload[task_id] print(f[planner] 收到任务: {task}) # 演示把任务拆成两个子任务 sub_tasks [ 编写业务逻辑, 编写单元测试, ] for i, sub in enumerate(sub_tasks): await self.send( subtask.assigned, executor, { task_id: task_id, sub_task_index: i, sub_task: sub, }, )再写 Executor Agent负责执行具体的子任务# file: main.py (片段2 - Executor Agent) from harness.agent import BaseAgent from harness.event_bus import EventBus from typing import Any class ExecutorAgent(BaseAgent): def __init__(self, event_bus: EventBus, group: str default): super().__init__(fexecutor-{group}, event_bus) self.group group self._queue None async def run(self): self._queue self.event_bus.subscribe(subtask.assigned) print(f[executor-{self.group}] 启动等待子任务...) while True: event await self._queue.get() task_id event.payload[task_id] sub_task event.payload[sub_task] index event.payload[sub_task_index] print(f[executor-{self.group}] 开始执行子任务 {index}: {sub_task}) # 模拟执行耗时 await asyncio.sleep(1) # 这里可以调用工具 result f已完成 {sub_task} print(f[executor-{self.group}] {result}) # 回传结果 await self.send( task.result, harness, { task_id: task_id, index: index, result: result, }, )4.4 编写主程序并运行最后是主入口。我们初始化 Harness创建一个 Planner 和两个 Executor然后提交一个模拟任务# file: main.py import asyncio from harness.harness import AgentHarness from harness.event_bus import EventBus async def main(): # 创建 Harness harness AgentHarness() # 注册工具 harness.tools.register( nameecho, fnlambda msg: f[echo] {msg}, description回显消息, ) # 创建并注册 Agent planner PlannerAgent(harness.event_bus) executor1 ExecutorAgent(harness.event_bus, groupA) executor2 ExecutorAgent(harness.event_bus, groupB) harness.register_agent(planner) harness.register_agent(executor1) harness.register_agent(executor2) # 启动 Harness harness_task asyncio.create_task(harness.start()) # 模拟用户提交任务 await harness.submit(开发一个用户注册模块) # 让事件循环跑一会儿 await asyncio.sleep(5) harness_task.cancel() if __name__ __main__: asyncio.run(main())4.5 运行与验证在当前目录执行python main.py预期输出大致如下[tool] 注册工具: echo, 描述: 回显消息 [harness] 注册 Agent: planner [harness] 注册 Agent: executor-A [harness] 注册 Agent: executor-B [planner] 启动等待任务... [executor-A] 启动等待子任务... [executor-B] 启动等待子任务... [planner] 收到任务: 开发一个用户注册模块 [executor-A] 开始执行子任务 0: 编写业务逻辑 [executor-B] 开始执行子任务 1: 编写单元测试 [executor-A] 已完成 编写业务逻辑 [executor-B] 已完成 编写单元测试到这里一个最小可运行的多 Agent Harness 已经成型了。它虽然简单但包含了事件总线、Agent 生命周期管理、上下文管理、工具注册这几个最核心的设计。后续你可以按同样的思路往里面加入 LLM 调用、错误重试、超时处理、分布式消息队列等能力。5. Skill 开发实战有了 Harness 的基础我们再来看 Skill 开发。Skill 是 Harness 框架中非常重要的扩展点。最近社区里“skill 开发指南”“Java 开发可以安装的 skill 推荐”这类话题热度很高确实Skill 写得好不好直接决定了 Agent 的上限。5.1 Skill 与 Tool 的区别很多同学分不清 Skill 和 Tool。这里我做一个简单区分维度ToolSkill单位单个函数一组能力或流程复杂度低中到高是否包含提示词不包含通常包含是否组合其他工具不可以可以示例发送 HTTP 请求“代码审查”技能Tool 是原子能力Skill 是对原子能力的组织。同一个 Skill 内部可以调用多个 Tool并且可以包含面向模型的指令模板。5.2 SKILL.md 的通用结构目前社区比较流行的是用 Markdown 文件描述 Skill文件名统一约定为SKILL.md。一个典型的 SKILL.md 长这样--- name: spring-boot-standards description: 生成符合企业规范的 Spring Boot 代码 version: 1.0.0 author: your-team --- # Spring Boot 开发规范 ## 适用场景 当用户需要生成 Controller、Service、Mapper 或完整 CRUD 代码时使用。 ## 核心指令 1. Controller 层只做参数校验和路由转发。 2. Service 层负责业务逻辑事务注解 Transactional 必须显式声明。 3. 所有接口返回统一响应体 ResultT。 4. 不允许在 Controller 中直接操作数据库。 5. 每个方法必须编写单元测试。 ## 工具调用 - 需要生成项目骨架时调用 get_gradle_build_path。 - 需要查找历史代码时调用 search_codebase。 ## 示例 输入生成用户模块的 Controller 输出参考以下模板 ... ## 边界 - 不处理前端代码。 - 不生成数据库迁移脚本。这个结构有几个关键点YAML 格式的 Front Matter给 Harness 提供技能元数据包括名称、描述、版本。适用场景让模型判断什么时候该加载这个 Skill。核心指令这是 Skill 最重要的部分是模型行为约束。工具调用声明这个 Skill 依赖哪些 ToolHarness 据此注入。示例给模型 few-shot 示例提高稳定性。边界明确什么情况下不要使用避免技能被滥用。5.3 实战写一个“Java 后端开发规范” Skill结合热词里大家比较关心的话题我来演示一个面向 Java / Spring Boot 开发场景的 Skill。它解决的是“团队规范没法落地”的问题。假设你的 Harness 已经接入了代码仓库工具这个 Skill 可以指导 Agent 生成符合团队规范的代码。实际落地时建议把 SKILL.md 放在项目根目录的.harness/skills/文件夹下.harness/skills/ ├── spring-boot-standards/ │ └── SKILL.md哈ness 启动时会自动扫描并加载这个目录。加载后Agent 在面对“帮我写一个用户模块的 Controller”这类请求时就会自动套用团队规范。5.4 Skill 的调试与测试Skill 开发和代码开发一样需要调试。我常用的调试方式有三种第一种是单测法。准备一组标准输入对比输出是否符合团队规范。比如输入“用户 CRUD”检查生成的 Controller 是否符合统一返回体和参数校验规范。第二种是对比法。正反各测一次先测没有 Skill 的 Agent 输出再测有 Skill 的 Agent 输出量化差异。这能直观地看出 Skill 是否真的产生了约束效果。第三种是回归法。每次修改 Skill 后把历史测试用例重新跑一遍防止“修了 A 场景坏了 B 场景”。5.5 Skill 开发的工程建议在 Cursor、Claude Code 等工具中开发 Skill 时我建议注意几个点第一做小做专。不要写一个“万能 Java Skill”要拆成spring-boot-controller、spring-boot-service、mybatis-mapper等多个 Skill让模型按需命中。第二描述词要精确。Skill 的描述description会直接影响模型是否命中该 Skill尽量包含触发场景和排除场景。第三版本要可回溯。企业级内部 Skill 会有多个版本建议在目录中保留 changelog并且在 Front Matter 中维护版本号。6. 常见问题与排查思路多 Agent 系统和普通后端服务不一样出了问题往往不是“报错”而是“结果不对”。这里整理几个高频问题方便大家排查。6.1 Agent 没有按照预期调用工具问题现象常见原因解决思路Agent 直接给出结果没有调用注册工具工具描述不够明确模型不知道何时调用优化工具描述明确触发条件和参数含义Agent 调用了错误的工具工具之间功能重叠描述区分度不够调整工具命名和描述必要时合并工具相同输入多次结果不一致模型输出有随机性设置温度参数增加 few-shot 示例约束6.2 多 Agent 之间出现循环调用这是多 Agent 系统最常见也最难排查的问题。现象是两个 Agent 互相发消息任务永远不结束。产生原因通常是Agent 的停止条件不明确或者事件过滤规则太宽。解决方案很简单在 Harness 层增加最大消息轮次限制超过阈值直接终止任务并告警。6.3 上下文过长导致关键信息丢失当任务链路很长多个 Agent 的消息不断累积后context 很容易超限。此时模型会“忘记”最开始的用户目标。解决思路有两个一是使用摘要压缩把历史消息压缩成摘要后再继续二是窗口截断只保留最近的若干轮消息。企业级项目里通常会用摘要 关键信息提取的组合方案。6.4 Skill 没有被触发问题现象常见原因解决思路明明配了 SKILL.mdAgent 却不用description 没有覆盖用户的实际表达调整 description增加同义触发词Skill 内容加载了但不生效指令和模型能力不匹配检查 Skill 指令是否具体可执行多个 Skill 匹配冲突多个技能 description 重叠细化场景边界优先级排布7. 工程化最佳实践最后这部分我总结一下在多 Agent Harness 落地过程中我认为最重要的工程建议。7.1 从单体 Agent 开始迁移不要一上来就设计复杂的多 Agent 拓扑。先跑通单体 Agent等到确实出现上下文过载、工具冲突、职责混乱时再把功能拆成多个 Agent。多 Agent 和分布式系统一样是有额外成本的。7.2 给每个 Agent 明确的边界Agent 也需要“职责单一”。如果一个 Agent 既要写代码又要做测试还要看日志它的行为会非常不稳定。每个 Agent 在系统提示词和 Skill 指令里都要明确“你负责什么、你不负责什么、遇到边界情况怎么办”。7.3 配置和提示词都走版本管理Agent 的系统提示词、Skill 文件、Harness 配置都应该像代码一样放进 Git 仓库管理。上线前要能 diff出问题要能回滚。7.4 日志必须有 trace_id从用户请求进入 Harness 的那一刻就要生成 trace_id贯穿整个链路。这一步一开始不做等出了问题再补成本会非常高。7.5 权限控制不能省工具注册中心要有权限等级。比如“发送邮件”“删除文件”这类高危工具应该只允许指定 Agent 调用并在调用时记录完整参数和调用人。Harness 的权限模型决定了这套系统能不能安全地接入生产环境。7.6 要有降级和熔断LLM 调用可能失败、超时工具可能不可用。Harness 需要给每个 Agent 设置超时时间并准备降级策略。比如调用外部搜索失败时可以降级为本地知识库检索。8. 总结与学习路线到这里我们已经走完了 Agent Harness 从原理到实战的完整闭环。你可以回顾一下自己是否已经能回答以下几个问题Harness 和 Agent 的本质区别是什么多 Agent 协同的常见模式有哪些主从模式为什么最适合工程落地Harness 的核心组件包括哪几部分事件总线在其中扮演什么角色如何手写一个最小可用的多 Agent HarnessSkill 和 Tool 的区别是什么一份合格的 SKILL.md 应该包含哪些结构多 Agent 系统出了循环调用、上下文丢失等问题应该往哪个方向排查如果这些问题你都能脱口而出那么你对 Agent 工程化的理解已经超过了很多只停留在提示词层面的开发者。下一步的学习路线我建议这样安排先回去把文中的轻量级 Harness 自己敲一遍然后尝试接入一个大模型 API让 Planner 真正通过模型来拆解任务而不是写死拆分逻辑。接着可以尝试接入真实工具比如文件读写、代码搜索、HTTP 请求。当你发现本地单机的 Harness 不够用时再去研究分布式消息队列、Agent 集群、状态持久化这些更深入的话题。以后看开源 Agent 项目时也可以带着 Harness 的视角去读源码多留意它的上下文管理、事件总线和工具注册是怎么实现的。抓住这三条主线再复杂的 Agent 框架也能快速看透。希望这篇教程对你的 Agent 工程化之路有帮助如果觉得内容实用欢迎收藏备用也欢迎在评论区交流你遇到的 Harness 设计问题。 手写多Agent协同Harness：核心原理与Skill开发实战
先来说一个很多同学都会遇到的场景你辛辛苦苦写好了一个 Agent它能调用搜索、能读文档、能写代码看起来功能很完整。可一旦把业务复杂度提上来比如同时要处理需求解析、代码生成、自动测试、结果汇总你会发现单个 Agent 根本忙不过来要么上下文越塞越满要么任务一多就开始“精神分裂”。这时候“多 Agent 协同”就成了绕不开的话题。但多 Agent 不是把几个 Agent 拼在一起那么简单。Agent 之间怎么通信、任务怎么拆、上下文怎么隔离、工具怎么共享、技能怎么扩展这些都需要一个统一的执行框架来管。这个框架就是本文要讲的 Agent Harness。本文会从零开始拆解 Agent Harness 的底层原理讲清楚它和 Agent 到底是什么关系然后带大家手写一个轻量级的多 Agent 协同 Harness最后演示如何开发一份可复用的 Skill。无论你是刚接触 AI Agent 的新手还是已经在做 Agent 工程化的后端开发者这篇文章都能给你一套可以落地的方法论和代码。1. 背景与核心概念在深入代码之前先把几个最容易混淆的概念讲清楚。很多文章把 Agent、Harness、Skill、Tool 混在一起说结果读者越看越迷糊。这里我尽量用通俗的方式解释。1.1 Harness 是什么Harness 本身的英文含义是“马具”引申为“驾驭、控制、利用”。在 Agent 工程里Agent Harness 指的是承载、调度、约束 Agent 的一套运行时框架。你可以把 Harness 理解成 Agent 的“运行容器”或“操作系统”。单个 Agent 是应用层Harness 是支撑它运行的基础设施。它负责接收用户请求解析目标。创建和管理多个 Agent 实例。完成 Agent 之间的消息传递。控制 Agent 的启动、暂停、停止。注入工具调用能力。记录运行轨迹和日志。换句话说Harness 解决的不是“单个 Agent 能不能回答问题”而是“多个 Agent 如何有序协作完成任务”的问题。1.2 Harness 和 Agent 的区别我用一张表来对比两者的定位维度AgentAgent Harness本质智能体具备规划和执行能力运行时框架负责调度和管理职责拆解任务、调用工具、生成结果生命周期管理、消息路由、上下文管理类比演员舞台解决的问题单点智能协同编排是否被用户感知不直接感知作为基础设施存在简单说Agent 是大脑Harness 是骨架和神经系统。没有 Harness多个 Agent 就是一大堆“大脑”在乱撞。1.3 为什么需要 Agent Harness在实际项目中Agent 不是孤立运行的。比如一个企业级的知识库问答系统可能需要同时协调检索 Agent、摘要 Agent、安全审查 Agent、应答 Agent。如果没有 Harness这套系统会面临几个问题第一上下文无法隔离。多个 Agent 共享一套提示词和记忆很容易互相污染。第二任务没有闭环。Agent 之间缺少明确的反馈机制任务挂起或失败后没有人重试和补偿。第三工具权限不可控。任何 Agent 都能调用任何工具安全事故概率显著上升。第四无法观测。出了问题连日志都没法按链路串起来。Agent Harness 把这些公共能力下沉到框架层业务代码只需要关心 Agent 本身的逻辑。2. 多 Agent 协同架构拆解理解了概念之后我们来看多 Agent 协同的整体架构。这是很多做 Agent 平台的团队会反复讨论的部分。2.1 单体 Agent 的瓶颈一个 Agent 做所有事情在简单场景下没问题。但业务复杂后单体 Agent 会出现几个典型瓶颈上下文迅速膨胀模型容易忽略关键信息。工具列表越来越长调用时误选率上升。安全和审核逻辑与业务逻辑耦合难以维护。某个环节升级整个 Agent 都要重新验证。因此我们需要将 Agent 按职责拆分再用 Harness 粘合起来。2.2 多 Agent 协作模式目前业界常见的多 Agent 协作模式有三种第一种是主从模式Supervisor Pattern。一个主控 Agent 负责任务分解和结果汇合多个子 Agent 负责具体执行。这种模式适合任务边界清晰的场景比如先规划再写代码再测试。第二种是流水线模式Pipeline Pattern。任务按固定阶段传递每个 Agent 只处理一个阶段。适合流程固定的业务比如“需求分析 - 代码生成 - 检查 - 发布”。第三种是组网模式Mesh Pattern。多个 Agent 可以互相调用动态协商。这种模式灵活性最高但实现复杂容易陷入无限循环。从工程落地角度主从模式最稳流水线模式最容易理解组网模式适合探索型项目。2.3 Harness 在协同架构中的位置完整的多 Agent 系统从下往上大致是这样模型层LLM - Agent 层Planner / Executor / Reviewer - Harness 层调度、上下文、工具、事件 - 工具层Tool / Skill - 应用层业务入口、APIHarness 在最核心的位置。它在 Agent 之上屏蔽 LLM 调用的复杂性在工具之下统一管理工具的注册和执行。2.4 核心组件一览一个完整的企业级 Agent Harness 至少包含以下组件Harness Engine核心引擎负责 Agent 实例创建、任务编排。Event Bus事件总线负责消息分发和订阅。Context Manager上下文管理器负责会话级和任务级的上下文隔离。Tool Registry工具注册中心统一管理外部工具。Skill Loader技能加载器负责加载和解析 Skill。Executor执行器负责和 LLM 交互解析模型输出。Observer观测器负责日志、追踪、指标采集。这些组件加起来构成了一个可以扩展、可以观测、可以治理的 Agent 运行底座。3. Agent Harness 底层原理这一节进入重点。很多人只知道 Harness 是框架却不知道它内部到底做了什么。这里我把底层原理拆成五个关键机制来讲。3.1 Agent 生命周期管理Harness 管理 Agent 的完整生命周期通常包括初始化加载 Agent 配置、注入系统提示词。待命等待任务分配。运行中正在执行用户的子任务。阻塞等待其他 Agent 返回结果或等待用户输入。结束任务完成释放资源。这个生命周期和 Java 线程池非常像。Harness 本质上就是一个可以调度 Agent 实例的资源管理器。企业级 Harness 还需要考虑并发控制、超时回收、优雅下线等问题。3.2 消息传递与事件总线多 Agent 协作的核心是消息传递。市面上的 Harness 实现方式很多但底层无非两种直接调用Agent A 知道 Agent B 的地址直接发消息简单但不解耦。事件驱动Agent 之间不直接通信通过事件总线发布和订阅消息。事件驱动是主流方案。它让每一个 Agent 都变成独立的生产者/消费者新增 Agent 不需要修改既有代码。事件总线中通常包含事件类型、事件体、事件来源、目标 Agent 等字段。实现上Python 可以用 asyncio.QueueJava 可以用 Spring 的 ApplicationEvent 或者消息中间件。复杂场景下还会引入 RabbitMQ、Kafka 做分布式事件分发。3.3 上下文管理这是 Harness 和普通任务队列最核心的区别。普通消息队列只传数据不管状态。Agent Harness 必须管上下文否则模型拿不到足够的背景信息就无法产出高质量结果。企业级 Harness 的上下文管理通常分三层全局上下文用户输入、业务常量、租户信息。会话上下文当前会话的对话历史。任务上下文当前 Agent 正在执行的子任务信息。上下文管理还涉及一个关键的工程问题上下文膨胀。当 Agent 之间的消息越来越多context 会迅速膨胀甚至超出模型窗口。常用的策略有摘要压缩、滑动窗口、关键信息提取。3.4 工具与 Skill 注册机制Harness 的另一个核心机制是工具注册。Agent 本身不能直接调用外部系统它只能通过 Harness 注入的工具函数来操作世界。工具注册一般包含以下几个元数据工具名称工具描述模型用来判断何时调用输入参数结构JSON Schema执行函数实现权限等级Skill 则是在工具之上的一层封装。一个 Skill 可以包含多步操作、提示词片段、子工具调用。比如“Spring Boot 开发规范”这个 Skill可能内置了 Controller 生成、Service 模板、配置校验等多个工具。3.5 可观测性设计生产环境跑 Agent最怕的是“黑盒”。Harness 在设计阶段就要考虑可观测性通常需要在每次 Agent 推理前记录输入 token、调用时间、模型名称在推理后记录输出内容、耗时、工具调用序列。特别建议给每一次完整的任务分配一个 trace_id像链路追踪一样贯穿所有 Agent。出现问题的时候通过 trace_id 就能快速拉出整条调用链定位是哪一步出了问题。4. 完整实战手写一个轻量级多 Agent Harness前面讲的都是理论接下来进入实操。我们用一个最小实现来演示 Harness 的核心逻辑。我选择 Python 3.10 asyncio 实现因为 asyncio 对事件循环和任务调度支持很好代码量少且容易理解。整个项目的目标是实现一个主从模式的多 Agent 协同 Harness包含一个 Planner Agent、两个 Executor Agent并通过事件总线通信。4.1 项目结构light-harness/ ├── harness/ │ ├── __init__.py │ ├── event_bus.py │ ├── context.py │ ├── agent.py │ ├── harness.py │ └── tools.py ├── skills/ │ └── code_skill.py ├── main.py └── requirements.txt这个结构涵盖了事件总线、上下文、Agent 抽象、Harness 核心、工具注册和 Skill 加载。4.2 核心代码实现首先是事件总线。这里用 asyncio.Queue 实现一个简单的发布订阅模型# file: harness/event_bus.py import asyncio from typing import Dict, List, Any class Event: 事件对象承载消息传递数据。 def __init__(self, event_type: str, source: str, target: str, payload: Any): self.event_type event_type self.source source self.target target self.payload payload class EventBus: 基于 asyncio.Queue 的简易事件总线。 def __init__(self): self._subscribers: Dict[str, List[asyncio.Queue]] {} self._queue asyncio.Queue() def subscribe(self, event_type: str) - asyncio.Queue: 订阅指定类型的事件返回一个专属队列。 queue asyncio.Queue() self._subscribers.setdefault(event_type, []).append(queue) return queue async def publish(self, event: Event): 发布事件投递给所有订阅者。 for queue in self._subscribers.get(event.event_type, []): await queue.put(event) async def start(self): 启动事件循环。 while True: event await self._queue.get() await self.publish(event)接着是上下文管理器# file: harness/context.py from typing import Dict, Any, List class ContextManager: 管理全局上下文和任务上下文。 def __init__(self): self._global_context: Dict[str, Any] {} self._task_contexts: Dict[str, Any] {} def set_global(self, key: str, value: Any): self._global_context[key] value def get_global(self, key: str): return self._global_context.get(key) def create_task_context(self, task_id: str, data: Dict[str, Any]): self._task_contexts[task_id] { data: data, history: [], } def append_history(self, task_id: str, message: str): self._task_contexts[task_id][history].append(message) def get_task_context(self, task_id: str) - Dict[str, Any]: return self._task_contexts.get(task_id, {})然后是 Agent 的抽象基类# file: harness/agent.py import asyncio from abc import ABC, abstractmethod from typing import Any from .event_bus import EventBus, Event class BaseAgent(ABC): Agent 基类所有具体 Agent 都继承它。 def __init__(self, name: str, event_bus: EventBus): self.name name self.event_bus event_bus self.running False async def send(self, event_type: str, target: str, payload: Any): 向其他 Agent 发送事件。 event Event( event_typeevent_type, sourceself.name, targettarget, payloadpayload, ) await self.event_bus.publish(event) abstractmethod async def run(self): Agent 主循环通常在这里订阅并处理事件。 pass接着是工具注册表Harness 中所有工具都统一登记在这里# file: harness/tools.py from typing import Callable, Dict, Any class ToolRegistry: 工具注册中心。 def __init__(self): self._tools: Dict[str, Callable] {} def register(self, name: str, fn: Callable, description: str ): self._tools[name] fn print(f[tool] 注册工具: {name}, 描述: {description}) def call(self, name: str, **kwargs): tool self._tools.get(name) if tool is None: raise ValueError(ftool {name} 不存在) return tool(**kwargs)最后是 Harness 核心它负责初始化事件总线、启动 Agent# file: harness/harness.py import asyncio from typing import List, Any from .event_bus import EventBus from .context import ContextManager from .tools import ToolRegistry from .agent import BaseAgent class AgentHarness: 轻量级 Agent Harness。 def __init__(self): self.event_bus EventBus() self.context ContextManager() self.tools ToolRegistry() self.agents: List[BaseAgent] [] def register_agent(self, agent: BaseAgent): self.agents.append(agent) print(f[harness] 注册 Agent: {agent.name}) async def start(self): 启动所有 Agent。 tasks [asyncio.create_task(agent.run()) for agent in self.agents] await asyncio.gather(*tasks) async def submit(self, task: str): 向 Harness 提交一个任务。 task_id ftask-{len(self.context._task_contexts) 1} self.context.create_task_context(task_id, {task: task}) await self.event_bus.publish(Event( event_typetask.submitted, sourceharness, targetplanner, payload{task_id: task_id, task: task}, )) return task_id4.3 编写具体 Agent我们先写一个 Planner Agent负责把任务拆成多个子任务# file: main.py (片段1 - Planner Agent) from harness.agent import BaseAgent from harness.event_bus import EventBus from typing import Any class PlannerAgent(BaseAgent): def __init__(self, event_bus: EventBus): super().__init__(planner, event_bus) self._queue None async def run(self): self._queue self.event_bus.subscribe(task.submitted) print([planner] 启动等待任务...) while True: event await self._queue.get() task event.payload[task] task_id event.payload[task_id] print(f[planner] 收到任务: {task}) # 演示把任务拆成两个子任务 sub_tasks [ 编写业务逻辑, 编写单元测试, ] for i, sub in enumerate(sub_tasks): await self.send( subtask.assigned, executor, { task_id: task_id, sub_task_index: i, sub_task: sub, }, )再写 Executor Agent负责执行具体的子任务# file: main.py (片段2 - Executor Agent) from harness.agent import BaseAgent from harness.event_bus import EventBus from typing import Any class ExecutorAgent(BaseAgent): def __init__(self, event_bus: EventBus, group: str default): super().__init__(fexecutor-{group}, event_bus) self.group group self._queue None async def run(self): self._queue self.event_bus.subscribe(subtask.assigned) print(f[executor-{self.group}] 启动等待子任务...) while True: event await self._queue.get() task_id event.payload[task_id] sub_task event.payload[sub_task] index event.payload[sub_task_index] print(f[executor-{self.group}] 开始执行子任务 {index}: {sub_task}) # 模拟执行耗时 await asyncio.sleep(1) # 这里可以调用工具 result f已完成 {sub_task} print(f[executor-{self.group}] {result}) # 回传结果 await self.send( task.result, harness, { task_id: task_id, index: index, result: result, }, )4.4 编写主程序并运行最后是主入口。我们初始化 Harness创建一个 Planner 和两个 Executor然后提交一个模拟任务# file: main.py import asyncio from harness.harness import AgentHarness from harness.event_bus import EventBus async def main(): # 创建 Harness harness AgentHarness() # 注册工具 harness.tools.register( nameecho, fnlambda msg: f[echo] {msg}, description回显消息, ) # 创建并注册 Agent planner PlannerAgent(harness.event_bus) executor1 ExecutorAgent(harness.event_bus, groupA) executor2 ExecutorAgent(harness.event_bus, groupB) harness.register_agent(planner) harness.register_agent(executor1) harness.register_agent(executor2) # 启动 Harness harness_task asyncio.create_task(harness.start()) # 模拟用户提交任务 await harness.submit(开发一个用户注册模块) # 让事件循环跑一会儿 await asyncio.sleep(5) harness_task.cancel() if __name__ __main__: asyncio.run(main())4.5 运行与验证在当前目录执行python main.py预期输出大致如下[tool] 注册工具: echo, 描述: 回显消息 [harness] 注册 Agent: planner [harness] 注册 Agent: executor-A [harness] 注册 Agent: executor-B [planner] 启动等待任务... [executor-A] 启动等待子任务... [executor-B] 启动等待子任务... [planner] 收到任务: 开发一个用户注册模块 [executor-A] 开始执行子任务 0: 编写业务逻辑 [executor-B] 开始执行子任务 1: 编写单元测试 [executor-A] 已完成 编写业务逻辑 [executor-B] 已完成 编写单元测试到这里一个最小可运行的多 Agent Harness 已经成型了。它虽然简单但包含了事件总线、Agent 生命周期管理、上下文管理、工具注册这几个最核心的设计。后续你可以按同样的思路往里面加入 LLM 调用、错误重试、超时处理、分布式消息队列等能力。5. Skill 开发实战有了 Harness 的基础我们再来看 Skill 开发。Skill 是 Harness 框架中非常重要的扩展点。最近社区里“skill 开发指南”“Java 开发可以安装的 skill 推荐”这类话题热度很高确实Skill 写得好不好直接决定了 Agent 的上限。5.1 Skill 与 Tool 的区别很多同学分不清 Skill 和 Tool。这里我做一个简单区分维度ToolSkill单位单个函数一组能力或流程复杂度低中到高是否包含提示词不包含通常包含是否组合其他工具不可以可以示例发送 HTTP 请求“代码审查”技能Tool 是原子能力Skill 是对原子能力的组织。同一个 Skill 内部可以调用多个 Tool并且可以包含面向模型的指令模板。5.2 SKILL.md 的通用结构目前社区比较流行的是用 Markdown 文件描述 Skill文件名统一约定为SKILL.md。一个典型的 SKILL.md 长这样--- name: spring-boot-standards description: 生成符合企业规范的 Spring Boot 代码 version: 1.0.0 author: your-team --- # Spring Boot 开发规范 ## 适用场景 当用户需要生成 Controller、Service、Mapper 或完整 CRUD 代码时使用。 ## 核心指令 1. Controller 层只做参数校验和路由转发。 2. Service 层负责业务逻辑事务注解 Transactional 必须显式声明。 3. 所有接口返回统一响应体 ResultT。 4. 不允许在 Controller 中直接操作数据库。 5. 每个方法必须编写单元测试。 ## 工具调用 - 需要生成项目骨架时调用 get_gradle_build_path。 - 需要查找历史代码时调用 search_codebase。 ## 示例 输入生成用户模块的 Controller 输出参考以下模板 ... ## 边界 - 不处理前端代码。 - 不生成数据库迁移脚本。这个结构有几个关键点YAML 格式的 Front Matter给 Harness 提供技能元数据包括名称、描述、版本。适用场景让模型判断什么时候该加载这个 Skill。核心指令这是 Skill 最重要的部分是模型行为约束。工具调用声明这个 Skill 依赖哪些 ToolHarness 据此注入。示例给模型 few-shot 示例提高稳定性。边界明确什么情况下不要使用避免技能被滥用。5.3 实战写一个“Java 后端开发规范” Skill结合热词里大家比较关心的话题我来演示一个面向 Java / Spring Boot 开发场景的 Skill。它解决的是“团队规范没法落地”的问题。假设你的 Harness 已经接入了代码仓库工具这个 Skill 可以指导 Agent 生成符合团队规范的代码。实际落地时建议把 SKILL.md 放在项目根目录的.harness/skills/文件夹下.harness/skills/ ├── spring-boot-standards/ │ └── SKILL.md哈ness 启动时会自动扫描并加载这个目录。加载后Agent 在面对“帮我写一个用户模块的 Controller”这类请求时就会自动套用团队规范。5.4 Skill 的调试与测试Skill 开发和代码开发一样需要调试。我常用的调试方式有三种第一种是单测法。准备一组标准输入对比输出是否符合团队规范。比如输入“用户 CRUD”检查生成的 Controller 是否符合统一返回体和参数校验规范。第二种是对比法。正反各测一次先测没有 Skill 的 Agent 输出再测有 Skill 的 Agent 输出量化差异。这能直观地看出 Skill 是否真的产生了约束效果。第三种是回归法。每次修改 Skill 后把历史测试用例重新跑一遍防止“修了 A 场景坏了 B 场景”。5.5 Skill 开发的工程建议在 Cursor、Claude Code 等工具中开发 Skill 时我建议注意几个点第一做小做专。不要写一个“万能 Java Skill”要拆成spring-boot-controller、spring-boot-service、mybatis-mapper等多个 Skill让模型按需命中。第二描述词要精确。Skill 的描述description会直接影响模型是否命中该 Skill尽量包含触发场景和排除场景。第三版本要可回溯。企业级内部 Skill 会有多个版本建议在目录中保留 changelog并且在 Front Matter 中维护版本号。6. 常见问题与排查思路多 Agent 系统和普通后端服务不一样出了问题往往不是“报错”而是“结果不对”。这里整理几个高频问题方便大家排查。6.1 Agent 没有按照预期调用工具问题现象常见原因解决思路Agent 直接给出结果没有调用注册工具工具描述不够明确模型不知道何时调用优化工具描述明确触发条件和参数含义Agent 调用了错误的工具工具之间功能重叠描述区分度不够调整工具命名和描述必要时合并工具相同输入多次结果不一致模型输出有随机性设置温度参数增加 few-shot 示例约束6.2 多 Agent 之间出现循环调用这是多 Agent 系统最常见也最难排查的问题。现象是两个 Agent 互相发消息任务永远不结束。产生原因通常是Agent 的停止条件不明确或者事件过滤规则太宽。解决方案很简单在 Harness 层增加最大消息轮次限制超过阈值直接终止任务并告警。6.3 上下文过长导致关键信息丢失当任务链路很长多个 Agent 的消息不断累积后context 很容易超限。此时模型会“忘记”最开始的用户目标。解决思路有两个一是使用摘要压缩把历史消息压缩成摘要后再继续二是窗口截断只保留最近的若干轮消息。企业级项目里通常会用摘要 关键信息提取的组合方案。6.4 Skill 没有被触发问题现象常见原因解决思路明明配了 SKILL.mdAgent 却不用description 没有覆盖用户的实际表达调整 description增加同义触发词Skill 内容加载了但不生效指令和模型能力不匹配检查 Skill 指令是否具体可执行多个 Skill 匹配冲突多个技能 description 重叠细化场景边界优先级排布7. 工程化最佳实践最后这部分我总结一下在多 Agent Harness 落地过程中我认为最重要的工程建议。7.1 从单体 Agent 开始迁移不要一上来就设计复杂的多 Agent 拓扑。先跑通单体 Agent等到确实出现上下文过载、工具冲突、职责混乱时再把功能拆成多个 Agent。多 Agent 和分布式系统一样是有额外成本的。7.2 给每个 Agent 明确的边界Agent 也需要“职责单一”。如果一个 Agent 既要写代码又要做测试还要看日志它的行为会非常不稳定。每个 Agent 在系统提示词和 Skill 指令里都要明确“你负责什么、你不负责什么、遇到边界情况怎么办”。7.3 配置和提示词都走版本管理Agent 的系统提示词、Skill 文件、Harness 配置都应该像代码一样放进 Git 仓库管理。上线前要能 diff出问题要能回滚。7.4 日志必须有 trace_id从用户请求进入 Harness 的那一刻就要生成 trace_id贯穿整个链路。这一步一开始不做等出了问题再补成本会非常高。7.5 权限控制不能省工具注册中心要有权限等级。比如“发送邮件”“删除文件”这类高危工具应该只允许指定 Agent 调用并在调用时记录完整参数和调用人。Harness 的权限模型决定了这套系统能不能安全地接入生产环境。7.6 要有降级和熔断LLM 调用可能失败、超时工具可能不可用。Harness 需要给每个 Agent 设置超时时间并准备降级策略。比如调用外部搜索失败时可以降级为本地知识库检索。8. 总结与学习路线到这里我们已经走完了 Agent Harness 从原理到实战的完整闭环。你可以回顾一下自己是否已经能回答以下几个问题Harness 和 Agent 的本质区别是什么多 Agent 协同的常见模式有哪些主从模式为什么最适合工程落地Harness 的核心组件包括哪几部分事件总线在其中扮演什么角色如何手写一个最小可用的多 Agent HarnessSkill 和 Tool 的区别是什么一份合格的 SKILL.md 应该包含哪些结构多 Agent 系统出了循环调用、上下文丢失等问题应该往哪个方向排查如果这些问题你都能脱口而出那么你对 Agent 工程化的理解已经超过了很多只停留在提示词层面的开发者。下一步的学习路线我建议这样安排先回去把文中的轻量级 Harness 自己敲一遍然后尝试接入一个大模型 API让 Planner 真正通过模型来拆解任务而不是写死拆分逻辑。接着可以尝试接入真实工具比如文件读写、代码搜索、HTTP 请求。当你发现本地单机的 Harness 不够用时再去研究分布式消息队列、Agent 集群、状态持久化这些更深入的话题。以后看开源 Agent 项目时也可以带着 Harness 的视角去读源码多留意它的上下文管理、事件总线和工具注册是怎么实现的。抓住这三条主线再复杂的 Agent 框架也能快速看透。希望这篇教程对你的 Agent 工程化之路有帮助如果觉得内容实用欢迎收藏备用也欢迎在评论区交流你遇到的 Harness 设计问题。