CrewAI官方给出的框架结构如下图所示。

在Crew中，Agent可以理解为具有特定职责的团队成员，Task表示需要完成的具体任务，Process规定Agent和任务的执行方式，Crew则将这些Agent和任务组织起来，共同完成最终目标。

例如，要完成一份行业研究报告，可以创建研究Agent、写作Agent和审核Agent。研究Agent负责查找和整理资料，写作Agent根据研究结果形成报告，审核Agent负责检查报告中的问题。不同Agent承担不同职责，并通过任务之间的衔接共同完成整个工作。

Flow可以按照预定的流程组织任务执行，并支持条件判断、循环和状态管理等能力。Crew和Flow也可以组合使用，例如使用Flow控制整体业务流程，在其中某个复杂步骤中调用Crew，由多个Agent协作完成任务。

CrewAI的特点是通过角色、任务和团队来组织多Agent协作，整体设计比较接近现实中的团队分工。比较适合角色和任务边界清晰的多Agent应用，例如研究、内容生成、数据分析和审核等场景。

LangGraph框架

LangGraph由LangChain团队在2024年推出，是一个用于构建和管理长时间运行、有状态Agent的底层编排框架。与直接使用预构建Agent不同，LangGraph允许开发者显式定义Agent的执行结构，特别适合包含状态、分支、循环和人工介入等复杂流程的Agent。

LangGraph既可以构建执行路径相对明确的Workflow，也可以构建由大模型动态决定下一步操作的Agent。Workflow可以预先定义任务的执行路径，并通过顺序、并行、路由、循环等方式组织不同步骤；Agent可以根据当前状态和工具返回结果动态决定下一步操作。实际应用中，Workflow和Agent也可以结合使用，由Workflow确定整体流程，Agent负责其中需要动态决策的环节。

LangGraph支持的Workflow和Agent模式如下图所示。

为了实现这些不同的执行方式，LangGraph使用图来描述任务的执行过程，其中三个基本概念是State、Node和Edge。State用于保存任务执行过程中需要共享的信息；Node表示一个具体的处理步骤，例如调用大模型、检索知识或者执行工具；Edge连接不同节点，并决定任务下一步进入哪个节点。

例如，一个知识问答Agent可以先分析用户问题，再检索知识、生成答案并检查结果。如果答案检查不通过，可以通过条件分支重新进入检索节点；如果检查通过，则进入最终输出节点。在整个过程中，用户问题、检索结果、中间答案等信息都可以保存在State中，并在不同节点之间共享。

这种设计与完全依靠大模型决定下一步操作不同。LangGraph允许预先规定任务的大体执行结构，在需要判断的节点中使用大模型进行决策。这样既保留了Agent根据实际情况动态判断的能力，也能够对关键执行路径进行控制。

除了图结构和状态管理，LangGraph还提供Durable Execution、Human-in-the-loop等能力。长时间运行的任务可以保存执行状态，并在中断后继续；在重要操作前，也可以暂停Agent，等待人工检查或修改状态后再继续运行。因此，官方将LangGraph定位为面向长时间运行、有状态Agent的低层编排框架。

LangGraph能够对状态和执行路径进行较细粒度的控制，但也需要开发者进行更多流程设计。对于简单的工具调用Agent，没有必要一开始就构建复杂的图。LangGraph官方也建议，如果刚开始学习Agent或者需要更高层的Agent抽象，可以先从LangChain的Agent开始。

MS-Agent框架

MS-Agent是魔搭社区开源的轻量级Agent开发框架，主要面向需要自主探索和多步骤执行的任务，提供模型调用、工具接入和多Agent协作等能力，可以用于构建深度研究、文档分析和代码生成等应用。

MS-Agent的基础组件是LLMAgent，负责组织大模型对话和工具调用。开发者可以通过配置文件指定模型、提示词和工具。接收用户任务后，LLMAgent将任务与可用工具提供给大模型，由模型判断下一步操作。如果需要调用工具，框架执行相应操作，再将结果交给模型继续处理，直到模型生成不再包含工具调用的回复，或者达到设定的最大运行轮数。

LLMAgent的基本运行流程如下图所示。Agent完成配置初始化和消息准备后，在模型调用与工具执行之间循环，并在需要时压缩上下文。图中的cb表示回调，开发者可以在相应环节加入日志记录或其他自定义处理。

工具接入是MS-Agent的重要能力。框架提供文件读写、代码执行和任务拆分等内置工具，也支持通过MCP（Model Context Protocol，模型上下文协议）接入外部工具。开发者可以复用已有的MCP服务，或者编写自定义工具，使Agent能够访问任务所需的数据和外部系统。

对于需要多个步骤配合的任务，MS-Agent支持通过工作流组合不同Agent。其中，LLMAgent负责需要大模型判断和生成的环节，CodeAgent负责按照代码执行的确定性操作。开发者可以将资料分析、数据处理和结果生成组织成一个工作流，并通过配置文件规定各个步骤的执行关系。

例如，MS-Agent项目中的Code Genesis提供了多Agent协作完成代码生成的示例，将过程分为设计与编码、检查与优化两部分。架构Agent负责设计，任务拆分工具将工作分配给多个编程Agent；进入优化阶段后，再根据构建或人工检查的反馈拆分修改任务，由编程Agent继续处理。

Agent SDK

除了使用Agent开发框架，一些模型厂商也以SDK（Software Development Kit，软件开发工具包）的形式提供Agent开发能力，将模型调用、工具调用和任务执行等能力封装成接口、类和组件，帮助开发者在自己的应用中创建和运行Agent。Agent框架和Agent SDK都可以用于构建Agent，两者提供的能力存在一定交叉，只是在组织方式和关注重点上有所不同。下面介绍两个具有代表性的Agent SDK。

OpenAI Agents SDK

OpenAI于2025年推出了OpenAI Agents SDK，它强调使用较少的核心抽象构建Agent应用。以Agent作为基本执行单元，围绕Agent提供工具调用、任务转交、运行约束和执行追踪等能力。Tools用于查询数据、执行代码、调用API或操作其他外部系统；Handoffs允许当前Agent将任务转交给另一个更加适合处理该任务的Agent；Guardrails负责检查Agent的输入、输出以及部分工具调用；Tracing则记录Agent执行过程中发生的模型生成、工具调用、任务转交和Guardrail等事件。

OpenAI Agents SDK还提供Agent Visualization，可以将Agent以及它连接的其他Agent、Tools和MCP Server生成图结构。其中Agent之间的有向连接可以表示Handoff，工具和Agent之间的连接则表示工具调用。

例如，在客服系统中，可以设置一个入口Agent负责识别用户问题，再设置订单Agent、退款Agent和FAQ Agent处理不同类型的业务。当用户咨询退款问题时，入口Agent可以通过Handoff将任务转交给退款Agent；退款Agent再根据需要调用订单查询、退款申请等工具完成任务。Handoff尤其适合这种由不同专业Agent分别处理不同任务的场景。

Guardrails和Tracing考虑了Agent实际运行中的约束和观察问题。Guardrails可以在Agent输入、最终输出以及自定义函数工具执行前后进行检查；Tracing则记录一次Agent运行中的模型生成、工具调用、Handoff和Guardrail等事件，帮助开发者了解Agent经过了哪些步骤以及问题出现在哪里。

OpenAI Agents SDK的特点是核心概念相对集中。开发者可以先从单个Agent和Tools开始，再逐渐加入多Agent协作、Guardrails和Tracing等能力。与LangGraph相比，两者的设计重点有所不同：LangGraph更加突出状态和工作流的细粒度控制；OpenAI Agents SDK则围绕Agent提供工具调用、任务转交、运行约束和执行追踪等常用能力。

Claude Agent SDK

Claude Agent SDK是Anthropic推出的Agent开发SDK，原名为Claude Code SDK，后来更名为Claude Agent SDK。它将Claude Code中的Agent能力开放给开发者，使开发者可以在自己的应用中构建能够使用工具、访问运行环境并持续执行任务的Agent。

与前面介绍的Agent开发工具相比，Claude Agent SDK的一个突出特点是更加关注Agent对实际运行环境的访问和操作。除了调用外部工具，它还提供文件读取、文件修改和命令执行等内置能力，使Agent能够直接处理文件、运行程序和执行命令，并可以通过MCP连接更多外部工具和数据。此外，它提供权限控制、Hooks和Subagents等机制，通过权限控制限制Agent能够执行的操作；Hooks可以在工具调用等关键阶段加入自定义处理逻辑；Subagents可以将部分任务交给独立的子Agent处理。

在运行过程中，Agent会根据当前任务和上下文判断下一步操作，例如读取文件、修改代码或执行命令。工具执行后的结果会重新返回给Agent，Agent再根据新的信息继续判断，直到任务完成。Claude Agent SDK负责组织这一执行过程，并在其中处理工具调用、权限检查和上下文传递等工作。

例如，在软件开发任务中，可以让Agent读取项目代码，根据用户需求修改文件，然后执行测试。如果测试失败，Agent可以读取错误信息并继续修改，直到完成任务。在这一过程中，大模型负责理解任务和决定下一步操作，Claude Agent SDK则负责提供文件系统、终端和工具等运行能力，并对权限和任务执行过程进行管理。

Claude Agent SDK比较适合需要访问文件和运行环境、连续调用工具并执行多步骤任务的Agent应用，尤其适合软件开发和自动化任务等场景。

在实际的Agent开发中，运行环境、上下文管理、权限控制、任务状态和执行反馈等能力越来越受到重视。如何围绕大模型组织这些能力，并对任务执行过程进行管理和控制，已经成为Agent系统设计中的重要问题，Harness关注的正是这些问题。

Harness

Harness是什么

大模型能力不断提升后，Agent面临的问题逐渐从“模型能不能完成某项任务”转向“模型能不能持续、可靠地完成实际任务”。在一次简单的问答中，大模型只需要根据输入生成结果；但在软件开发、数据分析、业务自动化等复杂任务中，Agent可能需要连续工作较长时间，在多个步骤之间保存进度，调用不同工具，并根据实际执行结果不断调整后续操作。此时，仅依靠模型自身的推理能力并不能保证任务最终正确完成。

例如，一个代码Agent可能能够正确理解“修改某个功能”的需求，也能够生成质量较高的代码，但在实际执行过程中仍可能出现各种问题：没有阅读项目规范就开始修改代码、同时修改过多文件、遗漏必要步骤、执行过程中丢失前面的任务进度，或者代码尚未通过测试就认为任务已经完成。这些问题并不完全来自模型本身的能力，而与模型所处的工作环境以及任务执行方式有关。

Harness就是围绕大模型建立的一套工作环境和运行机制，用于规定模型能够获得哪些信息、可以执行哪些操作、如何保存任务状态、如何判断任务是否完成，以及出现问题后如何继续处理。通过这些机制，可以将模型一次次独立的推理和操作组织成一个受到约束、能够持续运行并可以验证结果的任务执行过程。

Harness的重点并不是进一步增强大模型本身的知识或推理能力，而是让模型已有的能力能够更加可靠地作用于实际任务。模型仍然负责理解任务、分析问题和决定下一步操作；Harness则负责为模型建立完成任务所需要的工作条件，并对整个执行过程施加约束和反馈。

从运行过程来看，Harness使Agent形成一个持续的闭环：Agent根据当前任务和状态进行判断，执行相应操作，再从运行环境中获得新的结果；这些结果经过记录、检查和反馈后重新成为下一步决策的依据。如果结果不满足要求，Agent继续修改和执行；只有达到预先规定的完成条件后，任务才真正结束。

Harness与简单的Prompt或工具调用存在明显区别。Prompt主要通过指令告诉模型任务目标和行为要求，工具使模型能够执行具体操作，而Harness进一步关注这些指令和工具如何在整个任务执行过程中被组织和管理。它需要让Agent知道从哪里开始、当前进行到哪里、哪些操作可以执行、结果如何验证、什么时候可以结束，以及任务中断后如何继续。对于需要长时间运行和多步骤执行的Agent，这些机制直接影响任务能否稳定完成。

Harness的主要组成

Harness并没有统一的实现方式，不同Agent系统会根据任务类型提供不同的运行机制。从Agent实际运行需要解决的问题来看，可以将Harness归纳为五个相互配合的部分：指令与上下文、工具、运行环境、状态与任务连续性、验证与反馈。

（1）指令与上下文

指令与上下文决定Agent在当前任务中“知道什么”以及“应该遵循什么”。

指令不仅包括用户当前输入的任务，还包括系统提示词、项目规则、代码规范、业务约束、任务边界以及完成条件等内容。例如，编程Agent可以通过AGENTS.md、CLAUDE.md或项目文档了解目录结构、开发规范、测试方法以及禁止修改的区域。

上下文指在执行过程中提供给模型的有效信息，包括用户需求、历史操作、文件内容、工具执行结果以及当前任务状态等。由于模型上下文窗口有限，Harness通常还需要对上下文进行选择、压缩和重新组织，使模型能够获得当前任务真正需要的信息，而不是简单地不断追加全部历史内容。

对于复杂任务，可以采用分层指令和渐进式上下文加载。例如，先让Agent读取项目整体说明，在进入某个模块后再加载该模块的局部规则；当任务执行时间较长、上下文不断增加时，则可以压缩早期过程，只保留关键结论、任务状态和后续仍然需要使用的信息。通过这些机制，可以在有限的上下文窗口中持续为Agent提供有效信息，并通过指令约束Agent的任务范围和行为边界。

（2）工具

大模型本身主要负责理解、推理和生成决策，要真正读取外部信息或执行具体操作，还需要通过工具完成。因此，工具决定了Agent能够实际执行哪些动作。

对于编程Agent，常见工具包括文件读取、文件修改、代码搜索、Shell命令执行、Git操作和测试工具；对于企业Agent，则可能包括数据库查询、知识库检索、浏览器、业务API以及通过MCP接入的外部系统。

Harness在这一层不只是维护一个工具列表，还需要处理工具描述、参数组织、调用路由、执行结果返回以及异常处理。例如，大模型决定“运行项目测试”之后，Harness需要调用相应工具，在指定环境中执行测试命令，再将标准输出、错误信息和退出状态整理后返回给模型，使Agent能够根据执行结果决定下一步操作。

工具调用需要配合相应的安全与权限控制。某些工具只能读取文件，某些工具允许修改内容；涉及删除文件、访问网络、执行系统命令或操作生产系统时，还可以根据风险等级进行限制，必要时要求人工确认。Hooks等机制也可以插入工具调用前后，用于检查参数、记录执行过程或阻止不符合规则的操作。

在支持Subagent的系统中，主Agent还可以将部分任务交给专门的Subagent处理。例如，将代码搜索、测试分析或资料整理等相对独立的工作分配给不同Subagent，再汇总它们返回的结果。这样可以扩展单个Agent的任务处理能力，并减少复杂任务集中在一个执行上下文中的压力。

（3）运行环境

工具回答的是“Agent能够做什么”，运行环境则决定这些操作“在哪里发生”。

对于编程Agent，运行环境可能是本地项目目录、容器、虚拟机、云端Sandbox或者独立的Git Worktree。Agent读取和修改文件、执行Shell命令、安装依赖以及运行测试，都需要依托具体的运行环境。

Harness需要对运行环境进行准备和管理，如初始化代码仓库、安装依赖、设置环境变量、启动必要服务，以及检查当前环境是否满足任务执行条件。对于长时间运行的任务，还需要避免环境在执行过程中出现依赖缺失、服务异常或资源状态不一致等问题。

环境隔离也是运行环境管理的重要内容。如果多个Agent或多个任务同时处理同一个项目，直接操作同一个工作目录可能产生文件覆盖和状态冲突。可以为不同任务建立独立的Sandbox、容器或Worktree，使不同任务在相对隔离的空间中运行。即使某个任务执行失败，也可以降低对其他任务和宿主环境的影响。

运行环境还承担资源访问边界的控制。例如，限制Agent只能访问指定目录、只能连接特定网络、不能读取系统敏感文件，或者为不同任务配置不同的访问凭证。工具定义了Agent可以使用哪些能力，运行环境则限定这些能力实际能够作用于哪些文件、进程、网络和系统资源。

大模型的一次调用本身没有天然的长期任务状态，而复杂Agent任务可能持续几十分钟、数小时甚至跨越多个会话。如果任务信息只存在于当前上下文中，一旦上下文被压缩、进程中断或者会话重新启动，Agent就可能无法准确判断之前已经完成了哪些工作。

Harness需要维护任务状态，例如当前目标、任务拆分结果、已经完成的步骤、正在处理的步骤、修改过的文件、重要工具执行结果以及接下来需要继续处理的内容。

这些状态可以保存在内存中，也可以写入任务文件、数据库、Git历史或其他外部存储。对于长时间运行的Agent，持久化状态尤其重要。新的Agent会话可以读取此前保存的任务进度和关键结果，从上一次中断的位置继续执行，而不必重新分析整个任务。

状态管理贯穿任务的整个生命周期。任务开始时建立初始状态，执行过程中持续记录进度和关键结果，任务完成后保存最终状态；如果任务因为异常、超时或系统重启而中断，可以通过检查点等机制恢复到之前的执行位置。对于包含Subagent的复杂任务，可以记录各个子任务的完成情况、执行结果以及相互之间的依赖关系。

状态与任务连续性的重点是维护一个能够持续更新、持久化和恢复的任务执行过程，使Agent在长时间运行或跨会话执行时仍然知道任务进行到了哪里。

（5）验证与反馈

Agent执行了某个动作，并不意味着任务已经正确完成。例如，Agent成功修改了代码文件，但代码可能无法编译；生成了一份分析报告，但其中可能缺少关键数据；调用业务接口成功，也可能产生不符合业务规则的结果。因此，Harness还需要建立验证与反馈机制，对执行结果进行检查，并将检查结果重新提供给Agent。

验证方式取决于具体任务。对于软件开发任务，可以使用单元测试、Lint、类型检查、编译和端到端测试；对于业务任务，可以使用业务规则检查、结果比对或独立评估器。验证的核心是为任务完成提供可以检查的依据，而不是仅依赖模型自己判断“任务已经完成”。

反馈则将验证结果重新提供给Agent。例如，测试失败后，Harness可以将错误信息和相关日志返回给模型，Agent根据这些信息继续分析原因、修改代码并重新测试，从而形成：“执行 → 验证 → 获取反馈 → 修正 → 再验证”。这样的闭环能够让Agent根据真实执行结果不断修正前面的决策，而不是在一次操作之后直接结束任务。

Harness还可以在这一过程中加入执行控制。例如，只有测试全部通过后才允许提交代码；连续多次执行失败后停止任务或转交人工处理；涉及生产环境修改、数据删除等高风险操作时，则在真正执行之前暂停任务并要求人工审批。获得确认后继续执行，未获得确认则终止或调整操作。

这五个部分共同支撑Agent的持续运行：指令与上下文提供任务目标、规则和必要信息；工具提供实际行动能力；运行环境承载这些操作并限定资源边界；状态与任务连续性记录任务进展并支持恢复；验证与反馈检查执行结果，并推动Agent继续修正或结束任务。通过这些机制，Harness将Agent一次次独立的模型调用组织成一个能够持续执行、受到约束并可以验证结果的完整任务过程。

Harness 与Agent的关系

Agent与Harness并不是两个相互替代的概念，而是处在不同层次。在Agent运行过程中，大模型主要负责理解任务、分析当前信息并决定下一步操作；Harness则围绕Agent提供指令与上下文、工具、运行环境、状态管理以及验证反馈等支撑，使Agent的决策能够真正执行，并在执行过程中受到约束和检查。

二者之间是一种“决策与执行支撑”的关系。Agent根据当前任务和已有信息判断下一步应该做什么，Harness负责提供完成这一操作所需的工具和环境，并记录执行过程中产生的状态和结果。执行完成后，Harness还可以通过测试、规则检查等方式验证结果，再将反馈提供给Agent。Agent根据新的状态和反馈继续判断下一步操作，如此循环，直到满足任务完成条件。

例如，一个编程Agent判断需要修改login.py并运行测试。其中，分析代码并决定如何修改主要依赖大模型的理解和推理能力；而login.py是否允许修改、从哪里读取文件、通过什么工具修改、测试命令在哪个Sandbox中执行、修改进度如何保存、测试结果如何检查，以及失败后如何继续执行，则需要Harness提供相应的运行机制。测试失败后，错误信息会重新提供给Agent，Agent据此分析原因并决定下一步修改方案。

Harness的完善程度会影响Agent能够处理的任务类型。简单的Harness可能只提供少量工具和基本的调用机制，适合完成步骤较少的任务；更加完善的Harness则可以进一步提供上下文管理、环境隔离、任务状态持久化、权限控制、自动验证、失败恢复和人工审批等机制，使Agent能够持续执行更长、更复杂的任务。即使使用相同的大模型，不同Harness提供的运行条件不同，Agent在复杂任务中的执行能力和稳定性也可能存在明显差异。

Harness与Agent框架之间存在一定的交集，都会涉及工具调用、上下文管理、状态管理和任务执行控制等能力，但二者的关注重点不同。Agent框架更偏向于提供Agent构建和任务组织所需的开发能力，如Agent定义、工具调用、状态管理、工作流编排和多Agent协作等；Harness更关注围绕Agent运行建立的支撑和控制机制，例如如何组织上下文、如何提供工具和运行环境、如何保持任务连续，以及如何验证执行结果。随着Agent框架和Agent SDK不断发展，一些Harness能力也逐渐被集成到框架或SDK内部，因此二者在具体实现上并不存在绝对的功能边界。

从整体上看，可以将三者的关系概括为：大模型提供智能，Agent组织决策，Harness保障执行。

随着Agent执行任务复杂度的提升，Harness的作用会更加明显。

DeepSeek Harness

下面以DeepSeek Harness为例，进一步了解Harness在实际Agent系统中的组织方式。

DeepSeek Harness是DeepSeek在2026年推出的开源Agent Harness，其特点是通过插件化架构组织模型运行所需要的工具、Skills、会话、沙箱和任务执行等能力，为Agent提供可扩展的运行支撑。

DeepSeek将一个可运行的Agent理解为：

Agent = Model + Harness

其中，Model负责理解任务和进行决策，Harness负责组织模型完成任务所需要的工具、上下文和执行环境。

DeepSeek Harness的核心设计是“Everything is a Plugin（一切皆插件）”。模型、工具、Skills、会话、沙箱、存储、执行循环、任务调度和子Agent等能力都可以通过插件提供，并由底层的Cordis插件系统进行组织。Cordis负责插件的加载、卸载、依赖管理和生命周期管理，具体的Agent能力则由不同插件提供。开发者可以根据实际需要组合、替换或扩展不同插件。

整体插件化架构如下图所示。

例如，使用DeepSeek Harness构建一个数据分析Agent。Agent读取用户提供的数据文件，根据任务调用相应工具完成数据处理和分析，也可以使用Skills完成特定的数据分析任务。如果任务比较复杂，还可以将部分工作交给Subagent处理。模型负责判断下一步需要完成什么操作，Harness则负责提供和组织完成这些操作所需要的能力。

除了插件化设计，DeepSeek Harness还提供会话和运行过程记录等机制。模型看到的系统提示词、工具调用及其结果、Subagent调度和上下文注入等信息可以记录在会话日志中，并通过Trajectory查看。基于这些记录，还可以对任务进行恢复、分叉、检索和回放，方便开发者观察和调试Agent的执行过程。

目前DeepSeek Harness仍处于Developer Preview阶段，其核心插件和API仍在持续迭代。因此，更适合将其作为理解Harness插件化设计和工程实现的一种代表性案例，而不是将当前接口视为已经固定的开发标准。