快速结论
AI Agent 平台（AI agent platform）指为团队提供构建 Agent、接入数据与系统并在某处运行的相关部件的一类产品。它的形态比功能清单的长短更值得先看，因为代码框架、可视化搭建工具、企业级套件与协作工作空间对团队提出的要求各不相同。
先按团队的工作方式对上形态。写代码并希望掌握 Agent 状态流转的团队，适合开发者框架。希望不写 Agent 代码就能把流程跑起来的团队，适合可视化搭建工具或企业级平台。关心交接与 Agent 产出复核是否可见的团队，适合在原有产品之外再加一个协作工作空间。
AI Agent 平台是什么
AI Agent 平台是一类产品，它覆盖构建、连接、运行或看管 Agent 中的某一部分。覆盖的是哪一部分，正是平台之间的分界。框架把定义 Agent 及其运行路径所需的代码原语交给使用的人，运行环境由团队自己承担。可视化搭建工具与企业级平台提供配置界面来搭起这些部件、接入公司已在使用的套件，并可能提供托管运行路径，是否如此取决于产品与部署方式。协作工作空间让共享的工作与成员复核保持可见，Agent 本身则在别处运行。
在本文里，一个产品只要满足「由人把 Agent 作为工作单元来定义并操作，背后不止一次请求与应答的往返」，就算作 Agent 平台。这条线划进来的是有意搭建的结构，包含指令、工具与一条走过多步的路径。它划出去的是那种一次只回一条消息、既无工具也无路径的普通聊天机器人，也包括步骤事先固定、内部没有模型选择余地的流程工具。
产品形态的差别在哪里
本文按三种产品形态组织比较。开发者框架是团队用代码构建时依赖的库，其中心是 Agent 定义与控制流，状态如何在步骤之间流转由使用的人掌握。可视化搭建工具与企业级平台是团队配置出来的产品，中心是 Agent 以及它与所作用系统之间的连接，运行环境可能由厂商托管，也可能留在团队自有环境，取决于产品与部署方式。协作工作空间是人机共享工作的场所，中心是任务与复核，它位于负责构建或运行 Agent 的产品之外。
差别最终体现为人需要负责什么。用框架，团队除了 Agent 逻辑，还要承担部署、扩容与升级路径。用搭建工具或企业级平台，运行环境可能归厂商，团队负责配置与匹配程度；是否托管取决于产品与部署方式。用协作工作空间，团队负责的是工作如何交接、结果如何被接受。
这份对比怎么看
有五个细节比功能清单更有分量，下面每一条均按这五项来写。
- 产品形态与构建方式。 产品围绕什么构建，以及人要写多少代码。
- Agent 定义。 在该产品里 Agent 由哪些部分构成，因为厂商命名的部分，就是团队日后要维护的部分。
- 数据与系统接入。 Agent 如何触达它所要作用的系统与数据来源。
- 部署与托管。 整套设置在哪里运行、运行环境由谁持有。
- 成员复核与治理。 人能否查看或拦截 Agent 的产出。
厂商对这类产品的更新节奏很快，功能转出预览阶段时命名也会变动。下面内容以撰写时公开文档的状态为准，正式选定前请核对各厂商的最新文档。
平台对比一览
| 平台 | 产品形态与构建方式 | Agent 定义 | 数据与系统接入 | 部署与托管 | 成员复核与治理 |
|---|---|---|---|---|---|
| n8n | 工作流自动化平台，Agent 作为一等条目与工作流并列，可视化画布配 Agent Builder，另有代码节点 | 具名 Agent 配置，含模型、指令、工具、记忆与子 Agent | 内置集成、项目内工作流、自定义工具、MCP 服务器、知识库 | n8n Cloud 或自托管；Agent 为 Preview 状态；Agent 尚未支持自托管 Enterprise | 工具级人工批准可暂停运行；草稿与已发布两个版本，附发布历史 |
| CrewAI | 面向 Agent 与工作流的开源框架，CrewAI AMP 为商业平台；Python 代码声明 Agent、Task 与 Flow，AMP 层级含可视化 Agent Builder 与 Crew Studio | 执行任务、依角色与目标决定、使用工具、保留记忆并代理任务的单元 | 工具库、MCP 服务器、应用、技能、知识、记忆 | 框架运行在团队自有环境；AMP 提供托管部署、监控与扩展 | Task 上的人工输入开关与人在环中的做法；Crew 内由 manager Agent 核对 |
| LangGraph | 面向有状态 Agent 的低层编排框架与运行时；代码优先，用 Python 或 JavaScript 编写图，没有画布 | 由节点、状态与边组装成的图 | checkpointer 保存 thread 状态，store 保存长期记忆，工具与模型在节点层面接入 | 框架自带运行时，另有托管部署产品，支持 Cloud、BYOC 与自有基础设施 | interrupt 可暂停并恢复图；可观测与调试能力来自周边工具链 |
| Microsoft Copilot Studio | 面向 Agent、工作流与 Agent 流的图形化低代码工作台；在工作台内配置，支持自然语言搭建 | 处理对话并完成任务的 AI 助手，运行在选定的 harness 上 | 知识来源与连接器，发布到 Teams、Microsoft 365 Copilot 等渠道 | 文档覆盖在工作台中构建、管理与发布到渠道；管理层面含清点、基于角色的访问与成本管理 | 内置测试与人在环控制、Agent 流的人工复核步骤、评估功能与管理层面 |
| Syfo | 协作工作空间，中心是共享工作与成员复核；没有 Agent 构建界面 | 与团队成员并列在同一份名单里的具名参与者 | 不代 Agent 接入团队系统，也不承载 Agent 的运行时上下文 | 托管工作空间，没有需要部署的 Agent 运行时 | 成员复核记录与团队指定动作的 Action Card；不承担 Agent 运行时治理 |
价格与套餐会变动，此处不列。某一格留空或未列出某项能力，反映撰写时厂商文档的覆盖范围，不据此判断产品不支持。
平台逐一对比
n8n
产品形态与构建方式。 n8n 是工作流自动化平台，官方文档把 Agent 描述为与团队工作流并存在同一项目的一等条目。团队在画布上搭建，Agent Builder 用以配置名称、模型与指令，再挂上工具、技能、知识库、记忆与子 Agent，某一步需要时能放入代码节点或自定义工具。
Agent 定义。 一个 Agent 是一份具名配置，包含模型、指令、工具、技能、频道、计划任务、子 Agent、知识库与记忆。其推理回路能调用工具、检索知识库，或交接给另一个 Agent。
数据与系统接入。 工具是通往各类系统的路径，包括内置集成、同项目内的工作流、自定义工具，以及通过 MCP（Model Context Protocol，模型上下文协议）服务器接入的外部工具，知识库覆盖上传的文件。
部署与托管。 官方文档给出两种方式，即 n8n 运营的 n8n Cloud，以及部署在团队自有基础设施上的自托管。文档同时说明 Agent 尚未支持自托管 Enterprise，并标注为 Preview 状态。
成员复核与治理。 工具能标记为需要人工批准，此时工作流暂停，通过配置好的渠道发出请求，待成员批准或拒绝后该工具才会执行。每个 Agent 另保留草稿与已发布两个版本。文档没有描述成员在运行之外复核 Agent 成品的独立步骤。
CrewAI
产品形态与构建方式。 CrewAI 自述为面向 AI Agent 编排与工作流构建的开源框架，团队在 Python 中声明 Agent、Task 以及它们之间的流转。商业产品 CrewAI AMP（Agent Management Platform，Agent 管理平台）另有免代码界面，文档把可视化 Agent Builder 与 Crew Studio 放在该层级，并为框架产出的东西提供托管部署与监控。
Agent 定义。 Agent 是一个执行任务、依角色与目标作出决定、使用工具并保留交互记忆的单元，文档把 Flow 与 Crew 两层分得很清楚。
数据与系统接入。 文档列出五种扩展 Agent 的方式，即工具、MCP 服务器、应用、技能与知识，知识与记忆作为 Agent 或 Crew 的组成部分进行配置。
部署与托管。 框架本身运行在团队自己的环境里，托管基础设施、监控、REST API 访问与 webhook 流式输出则归在 CrewAI AMP 之下。
成员复核与治理。 Task 上记录了人工输入开关，开启之后 Agent 会先向使用者索取输入，再给出最终答复，文档也覆盖了暂停一次运行以取得成员决定的做法。在 Crew 内部，层级式流程会安排一个 manager Agent 置于其他 Agent 之上，由其委派任务并核对产出，这属于 Agent 层级的核对。文档没有描述成员在运行之外复核一次 Crew 运行成品的环节。
LangGraph
产品形态与构建方式。 LangChain 的文档把 LangGraph 描述为面向长期运行的有状态 Agent 的低层编排框架与运行时，并说明它专注于 Agent 编排。这是一个代码优先的产品，没有画布，节点用 Python 或 JavaScript 编写，文档说明 LangChain 本身是可选的。
Agent 定义。 Agent 由团队用节点、状态与边组装成一张图，取代低代码工作台所提供的声明式 Agent 对象，模型驱动的步骤与手写的步骤能出现在同一张图里。
数据与系统接入。 文档给出两套持久化机制。checkpointer 保存某个 thread 的图状态，用于对话连续性、人在环中的工作流、时间回溯与容错；store 在图状态之外持久化应用自定义的数据，用于长期的跨 thread 记忆。
部署与托管。 框架自带运行时，另有一个托管部署产品与之配套，文档把 Cloud、自带云（BYOC）与团队自有基础设施列为部署目标。
成员复核与治理。 文档覆盖了 interrupt，即节点内的一个调用会暂停图的执行，持久化层保存状态，运行等待外部输入，再由一次恢复动作继续。文档把它归在人在环中的做法之下，此时成员能查看并修改 Agent 状态，因此这是开发团队写进图里的复核点。可观测与调试能力来自 LangChain 周边的工具链，与成员复核分开。
Microsoft Copilot Studio
产品形态与构建方式。 微软把 Copilot Studio 文档化为用于构建和管理 AI 驱动的 Agent 与工作流的图形化低代码工作台，以独立网页应用的形式提供，工作台里有 Agent、工作流与 Agent 流三个构件。团队用自然语言描述一个 Agent 或一项自动化再逐步调整，数据与系统经连接器接入。
Agent 定义。 微软把 Agent 定义为一个处理对话并完成任务的 AI 助手，它遵循团队给出的指令，取用已连接的知识来源，并调用工具执行动作。Agent 运行在哪种底座上由 harness 决定，文档列出 GitHub Copilot harness、标准 harness 与 Copilot chat harness。
数据与系统接入。 知识来源与连接器是通往团队数据和系统的文档化路径。Agent 经由 Teams、Microsoft 365 Copilot、网站、移动应用等渠道触达成员。
部署与托管。 文档化的范围覆盖在工作台中构建与管理 Agent 和工作流，并发布到团队使用者所在的渠道。本地部署或自托管部署这类模式，不在该页面描述之内。
成员复核与治理。 文档列出工作流内置的测试与人在环控制、Agent 流的人工复核步骤，以及 Agent 发布前的测试环节，管理层面覆盖 Agent 清点、基于角色的访问与成本管理，评估功能用测试集与共享评分库在发布前后验证质量。
Syfo：人机协作工作空间，不是 Agent 构建或运行产品
产品形态与构建方式。 Syfo 是面向人机协作的工作空间，中心是共享的工作与成员复核。Syfo 不构建 Agent，也不运行 Agent。
Agent 定义。 在 Syfo 里，Agent 以具名参与者的形式出现，与团队成员并列，能收发消息、被提及，也能持有 Task。
数据与系统接入。 Syfo 不代 Agent 接入团队的系统，也不承载 Agent 的运行上下文或记忆。
部署与托管。 Syfo 由厂商托管，团队加入工作空间即可使用，无需自建基础设施。这里没有 Agent 运行环境可供部署。
成员复核与治理。 成员按团队在工作空间中选定的工作记录、交接记录与复核记录进行复核，团队指定的动作则能整理为 Action Card，由被授权的成员审核后以自己的身份提交。第 8 节说明这套复核如何在 Agent 于别处运行时保持可见，而 Syfo 不承担 Agent 本身的运行时治理或监控。
Agent 在别处运行时，复核如何保持可见
一张对比表能告诉团队各个平台能做什么，却较少交代工作在运行结束之后去了哪里。留在团队手上的那部分是复核，它需要一个不依赖登录运行这些 Agent 的平台的地方来完成。
Syfo 保存的正是这些记录。Agent 由团队自行选择在哪里运行，而围绕它的工作需要一个地方，让成员按团队选定保留的记录来核对，不单凭 Agent 的运行状态。交接按团队采用的任务状态推进，完成的工作落在一个几个月后仍读得到的地方。
- 具名 Agent 与人并列。 Agent 以具名身份出现在共享 Channel 与 Thread 中，是参与者，不是日志里的一条记录。
- 记录比运行活得更久。 三月做过的一次复核，六月仍读得到，因为这份记录随团队保留，不随平台。
- 关键动作抵达人。 团队事先标记为高风险或对外的动作，可准备为由获授权成员以本人身份复核并提交。
同一个工作空间让上下文在多次会话之间保持连贯，当一次复核发生在产出它的运行之后很久，这一点尤其要紧。构建与运行 Agent 仍由团队选定的平台承担。
如何选择
形态会先一步缩小范围，再进入功能比较。
- 写代码并希望掌握 Agent 状态与控制流的团队，比较范围在开发者框架之内，前期需要工程投入，对步骤之间流转方式的掌握也更直接。
- 希望不写 Agent 代码就能搭建并管理的团队，比较范围在可视化搭建工具与企业级平台之内，前期需要投入时间熟悉配置，具体进度取决于产品与团队。
- 已经跑起 Agent、需要让交接与结果复核对成员保持可见的团队，是在现有基础上增加一个协作工作空间。
随后用团队自身的约束作为筛子，在同一组五项细节上比较入选的产品。受监管的团队可把成员复核与访问控制列为较早的比较项，规模较小的团队可把在为此招人之前能自行配置到哪一步列为较早的比较项。
采用前值得先问清退出条件。团队如果更换平台，有哪些内容会留在原处，包括 Agent 定义、连接配置、运行历史与复核记录。文档能回答、且自托管或导出路径确实可用的产品，迁移时要处理的事项更清楚，可作为选型时的比较项。
问题与回答
AI Agent 平台和聊天机器人平台是一回事吗？
未必等同。一个较简单的聊天界面可能只围绕单次问答，未必提供可配置的 Agent 状态、工具与多步路径。Agent 平台覆盖的是定义 Agent、配置工具与多条路径、并在某处运行这些环节中的一部分。有些厂商把两者放在同一产品下出售，标签需要对照实际获得的能力来核对。
仅有单个 Agent 时，需要引入平台吗？
单个 Agent 能跑在框架上、一个简短的画布流程里，或团队已在使用的套件自带助手上。当 Agent 数量增加、需要触达其他团队负责的系统，或者构建团队之外的人需要查看其产出时，团队可以开始比较平台形态。
其中有多少环节能不写代码完成？
可视化搭建工具与企业级平台在需要写代码之前能覆盖相当多的环节，其中有些产品允许团队在某个步骤再落入代码，具体取决于产品配置。开发者框架从一开始就以代码为前提。更实际的筛子是团队自身的维护能力，配置出来的东西一旦出问题，仍要有明确的负责人。
已有的 Agent 能保留，只在上面加复核吗？
这取决于运行这些 Agent 的产品、团队能接入哪些工作记录，以及团队如何配置复核。协作工作空间位于负责构建或运行 Agent 的产品之外，因此 Agent 产出的复核与周边交接能留给成员，运行环境留在原处。
选定平台前应确认哪些事项？
有三项需要确认。Agent 定义存放在哪里、能否导出。运行环境由谁持有、团队停止付费后会发生什么。流程需要时，成员能否暂停或批准某个 Agent 步骤。厂商的公开文档若未回答其中某项，直接向厂商确认并留存答复。
从何处起步
先按产品形态缩小候选范围，再看功能矩阵。先把团队已有的条件写下来，即是否有人写代码、Agent 需要触达哪些系统、产出由谁签字认可。这三个答案能帮助团队缩小到一至两种形态，其余候选产品随之退出。
接着让日常负责的成员参与，把一条真实流程放到保留的两三个候选产品上跑一遍。留意配置在哪里结束、代码在哪里开始，也留意成员想核对 Agent 产出时会看到什么。与团队既有习惯匹配、且在复核环节留下可读记录，可作为长期使用时的评估项。
无论最终由哪个产品运行 Agent，交接与复核放在哪里宜早定下，因为这部分与团队一直相伴，不随所处的产品而改变。