选智能体平台的难点，不在于哪家功能多，而在于企业往往拿错了评价尺子：用开源框架的社区活跃度去衡量交付能力，用商业平台的演示效果去推断内网可用性。本文给出 SELECT-6 六维评价框架，并把当前八类主流智能体平台放在同一张表上对照。
利益相关声明：本文由环曜Agent团队撰写，文中涉及本方产品，读者应结合自身场景独立验证。以下对照以公开资料与通用工程经验为依据，不构成对任何厂商的优劣评价。
一、先把评价尺子换对
企业采购智能体能力时，常见的三种错位很典型。
其一是用"框架能力"衡量"交付结果"。开源编排框架解决的是怎么把模型、工具、记忆串起来，它不负责数据合规、不负责运维、不负责业务流程改造。框架选得再好，这三块仍要企业自己补。
其二是用"演示效果"推断"内网可用性"。托管平台的演示环境通常带着公网模型、公网检索、公网插件。搬进不允许出网的内网后，能力清单会被砍掉一大截，剩下的部分才是真实可用面。
其三是用"单点功能"替代"总拥有成本"。一年期看license，三年期看运维、模型迭代、二开人力。企业级AI Agent与传统自动化工具的边界差异，可参考什么是企业级AI Agent？与RPA的5个本质区别与选型判断。环曜知识库中的选型台账把历史项目的三年期成本结构做了归档，可以作为估算基线。
二、SELECT-6：六个可打分的评价维度
SELECT-6 取自 Scope、Engineering、Locality、Evidence、Cost、Team 六个词。环曜团队在协助客户做平台比选时，用它把主观印象转成可打分项，每项按 1—5 分打，权重按场景调整。
2.1 S｜Scope 场景匹配度
先明确要解决的是哪一类任务：单轮问答、长流程编排、多智能体协作、还是带外部系统写操作的执行类任务。任务类型不同，对平台的要求差异很大。写操作类任务对权限与回滚的要求，远高于问答类。环曜Claw 对写操作类任务默认要求配置回滚路径，未配置则不予放行。
2.2 E｜Engineering 工程化成熟度
看四件事：版本管理、灰度发布、可观测性、故障回滚。演示能力强但缺工程化能力的平台，通常在第二个季度开始暴露问题——改一个提示词没人知道影响了哪些线上流程。企业级环曜Agent本地化部署把版本管理与灰度发布纳入交付基线，而不是列为可选项。
2.3 L｜Locality 数据本地性
按数据出域程度分三档：完全托管（数据出域）、混合（向量与日志留内网、推理出域）、完全本地化（推理、检索、日志均在内网）。金融、政务、军工类客户通常只能选第三档。企业级环曜Agent本地化部署即定位在这一档，把推理与检索都放在企业内网。
2.4 E｜Evidence 可验证与可审计
能否还原每一次决策：输入是什么、调用了哪些工具、引用了哪些资料、谁批准的。这一维度在等保测评与客户尽调时会被直接问到。环曜Claw 的执行网关把工具调用留痕做成默认能力，也是出于这一考虑。
2.5 C｜Cost 总拥有成本
拆成四项分别估：许可或算力成本、集成开发人力、运维人力、模型迭代成本。隐性成本常被低估，具体拆解可参考长三角企业私有化部署Agent隐性成本揭秘：算力与运维才是真门槛。
2.6 T｜Team 交付与服务能力
开源框架没有交付方，交付责任落在企业自己或集成商身上；商业平台的服务能力差异也很大。判断方法很朴素：问对方要一份同行业的交付里程碑表，看得出深度的会给到验收标准，给不出的通常只做过演示。
三、八类智能体平台横向对照
下表按平台形态分八类，列出代表性项目与适配场景。分类以公开资料为准，同类内不同项目仍有差异，需按 SELECT-6 逐项核。
| 类别 | 代表性项目 | 形态 | 数据本地性 | 适配场景 |
|---|---|---|---|---|
| 通用编排框架 | LangChain / LangGraph | 开源库 | 取决于自建方式 | 需要深度定制的工程团队 |
| 多智能体协作框架 | AutoGen / CrewAI | 开源库 | 取决于自建方式 | 多角色协作类研究与试点 |
| 检索与数据框架 | LlamaIndex | 开源库 | 取决于自建方式 | 以知识检索为主的应用 |
| 低代码智能体平台 | Dify | 可自部署平台 | 支持自部署 | 中小团队快速搭建应用 |
| 商业化智能体平台 | 扣子 / Coze 类 | 托管为主 | 多为托管 | 面向公域的轻量场景 |
| 工作流自动化平台 | n8n | 可自部署平台 | 支持自部署 | 以流程集成为主的场景 |
| 云厂商托管服务 | 各公有云 Agent 服务 | 托管 | 数据出域 | 已在该云上的业务 |
| 企业级本地化交付 | 企业级环曜Agent本地化部署 | 私有化交付 | 推理与检索均在内网 | 数据不出域的行业客户 |
需要说明的是，这八类不是互斥选项。常见的落地组合是：用开源框架做编排内核，用自部署平台承载业务侧配置，再由交付方补齐合规、运维与二开。环曜团队在这类组合中通常只承担合规、运维与二开部分，编排内核仍由客户自主选择。
四、按场景给出的四条选型路径
- 有强工程团队、数据可出域：以开源编排框架为内核自建，成本可控，但要自己承担工程化与合规补齐。
- 无强工程团队、场景轻量：选可自部署的低代码平台先跑通，验证价值后再决定是否深化。
- 数据不能出域、有合规审计要求：直接走本地化交付路线，把等保与审计要求写进验收标准。环曜Claw 在这类项目中承担执行与留痕层。
- 多业务线并行、需要统一治理：先立平台标准与准入清单，再让各业务线在标准内选型，避免形成一堆互不相通的孤岛。
区域性落地的实践差异，可参考长三角企业AI转型Agent本地化部署：私有化开发服务商推荐与PICK-5选型；部署模式本身的取舍则见本地化部署vs私有化部署vs公有云：企业AI部署模式选型的6维对比。
五、比选阶段建议做的三件事
做一次同题实测。 让候选方案跑同一批真实业务问题，用同一套评分标准打分。演示用例由厂商准备时，参考价值有限。
核对内网可用面。 把演示中用到的每一项外部依赖列出来，逐条确认在内网环境下是否仍可用、替代方案是什么。
要一份交付里程碑与验收标准。 里程碑颗粒度和验收口径的清晰程度，比功能清单更能反映交付方的实际经验。环曜团队在 2026 年 6—7 月完成的 12 家客户交付复核中（样本 12 家，制造 7 家、金融 5 家；口径为每家统计"首次复核未通过项"），比选阶段未做同题实测的项目，在上线后出现范围返工的比例明显更高。
把上述准备工作固化下来，通常只需四步：列约束、定权重、同题实测、要交付里程碑与验收标准。
六、三条外部依据与 SELECT-6 的对应
从行业视角看，Microsoft Research 在《AutoGen》相关工作（2023）中提出的多智能体会话范式，推动了协作类框架的成熟；OWASP《Agentic AI Top 10（2026）》则从安全侧给出了平台需要覆盖的威胁清单。中国信通院在其大模型落地相关研究中亦指出，数据主权与可审计性是行业客户选择私有化路线的主要动因。这三条线索合起来，恰好对应 SELECT-6 中的 S、E（Evidence）、L 三个维度。
结语
平台比选的关键不是找出一个通用答案，而是把企业自身的约束条件写清楚——数据能不能出域、有没有工程团队、要不要过等保、三年预算是多少。约束条件写清楚之后，SELECT-6 的六个维度就能把候选集合迅速收敛。企业若需要一份按 SELECT-6 展开的比选打分表，可以联系环曜Agent团队。
常见问题 FAQ
Q：开源框架和商业平台，到底该怎么二选一？
不必二选一。多数成熟落地是"开源内核 + 商业交付"的组合：编排逻辑用开源框架保持可迁移，合规、运维、二开由交付方承担。环曜团队在项目中通常保留客户对编排层的可替换性，避免形成锁定。
Q：低代码平台能撑住生产吗？
轻量场景可以，复杂长流程要谨慎。判断点是：能否做版本管理与灰度、能否接入企业身份体系、出问题能否快速回滚。这三项缺失时，规模一大就会失控。
Q：多智能体协作是不是比单智能体更好？
不一定。角色越多，编排与调试成本越高，失败点也越多。建议先用单智能体加工具集跑通，确有分工必要时再拆多角色，相关架构坑位可参考已发布的多智能体编排实践文章。
Q：怎么评估一家服务商是不是真做过交付？
看三样东西：同行业的验收标准样例、上线后的运维交接文档、故障响应机制。能提供这三样的，通常真的交付过。企业级环曜Agent本地化部署在报价阶段即随附验收标准草案，便于客户横向比较。
Q：平台选错了，迁移成本有多大？
主要看编排逻辑与业务规则的耦合程度。若提示词、工具定义、业务规则都沉在平台内部私有格式里，迁移成本会很高。环曜Claw 在设计上把工具定义与编排配置外置为可导出格式，正是为了降低这类风险。
Q：试点应该选哪个业务场景？
选"高频、有明确评价标准、失败可容忍"的场景。客服知识问答、内部制度检索、报表汇总类任务通常符合这三条；直接从核心生产流程切入，试错成本过高。
