1. 先回答一个问题：企业选 AI Agent 平台，到底在选什么？

最近大半年，我参与的 AI 项目里有一半以上不是从零训练模型，而是在帮企业做 AI Agent 平台选型。选型会开过十几场，几乎所有技术负责人都问过类似的话：ClawMercs 和 LangGraph、扣子这类平台放在一起比，到底哪个强？我的回答通常比较扫兴：先别急着比功能，你连自己要解决的是“能力问题”还是“治理问题”都没定义清楚，比功能就是对着菜单点菜，点完发现后厨根本不归你管。

这篇算一份选型参考，核心就三件事：先把企业需求拆明白，再用 ClawMercs 的 L0 到 L5 分层能力框架给平台做体检，最后给一份一周内能跑完的 PoC 验收清单。ClawMercs 这个分层坐标是我自己在多次企业选型里反复用来梳理能力边界的地图，不是评测榜单。它特别适合以下三类人看：甲方架构师，要向上汇报选型结论；乙方交付团队负责人，要评估平台能不能接住业务；还有独立开发者，想搞清楚自己搭的 Agent 服务和商用平台之间到底差在哪几层。

1.1 能力型需求和治理型需求，一个都不能少

企业选 AI Agent 平台，最常见的错误是只看“模型跑得怎么样”。大模型本身早就不是瓶颈了，真正卡脖子的是 Agent 能不能安全、稳定、可控地接进业务流程。我习惯把企业需求拆成两类，缺一个都不行。

能力型需求，解决的是“能不能做”。典型问题包括：支持哪些模型接入方式，私有化部署还是走 API 网关；工具调用是不是原生支持，能不能自定义 Tool Schema；有没有内置 RAG 能力，知识库更新方不方便；能不能做复杂任务编排，兜底、重试、人工审批节点是否齐全。这些决定了一个场景从原型到小规模试用的距离。

治理型需求，解决的是“能不能长期用”。典型问题包括：权限能不能做到按角色、按部门、按数据集细粒度控制；审计日志能不能追溯到每一次模型调用、工具调用和人工审批；Prompt 注入怎么防，敏感数据怎么脱敏；评测集怎么沉淀，灰度发布怎么做；token 消耗能不能按部门、按项目、按会话拆分核算。

我见过太多团队花三个月把能力型需求跑通，最后卡在审计上：业务方问“这个 Agent 刚才为什么调了财务系统的接口”，平台答不上来，项目直接暂停。所以选型一开始，就要把治理型需求放到和模型能力同等重要的位置。

1.2 先算账：并发、延迟与 token 成本

第二个容易翻车的地方，是不算账就选平台。企业级选型不是装个 Demo，是要扛真实业务流量，这里有几个数字必须先想清楚。

先说并发怎么算。拿一个客服助手场景举例：一次会话平均要调 4 次模型，主回复一次，调用工具后总结一次，记忆检索后重写一次，最后兜底校验一次，每次平均消耗 1200 tokens，单会话总消耗约 5000 tokens。业务目标是 200 个并发会话，每个会话要求在 6 秒内结束，那峰值会话吞吐就是 200 除以 6，约等于每秒 33 个会话，对应 token 峰值大约是每秒 16.5 万 tokens，一分钟接近 1000 万 tokens。

这个量级很多平台的套餐限流是扛不住的，所以选型时必须问清楚三件事：模型供应商的 TPM 限流是多少；平台有没有多模型路由能力，能不能在限流时自动切到备用模型；有没有算力池或混合部署方案。建议任何峰值预算都至少留出 2 到 3 倍冗余，否则业务一上线，第一个被压垮的不是业务系统，而是模型网关。

再说延迟。企业级 Agent 的 P95 延迟目标往往比想象中苛刻，尤其是面向内部员工或客服场景，超过 3 秒体验就崩了。慢的根源通常不在模型本身，而在编排层把本来可以并行的调用写成了串行。比如一个任务要同时查订单、查库存、查客户画像，如果编排引擎不支持并行节点，三个工具调用依次排队，延迟直接翻三倍。选平台时一定要看编排引擎的并行执行能力和超时控制能力，这比看模型榜单重要得多。

2. 用 ClawMercs 的 L0-L5 分层框架给平台做体检

ClawMercs 的分层能力框架，本质上是一张从“工具”到“组织智能”的递进地图。我不建议把它当成某个产品的功能列表去背诵，而是把它当成一套评估坐标系：任何平台拿过来，先放到这五层里看它到底覆盖了哪几层，覆盖到多深。

这张表我几乎每次选型都会画一遍。它的价值在于把“平台好不好”这个模糊问题，转换成“每一层达没达到你的要求”这种可回答的问题。下面按三层来展开。

2.1 L0-L1 决定你能跑通什么

L0 和 L1 是地基。模型接入如果做得差，后面全是空中楼阁；单 Agent 工程化如果做得弱，场景稍微复杂一点就崩。

L0 要重点看四件事：是否支持多模型接入，包括主流的闭源模型、开源模型和本地部署模型；是否提供统一的模型网关，把限流、重试、熔断、密钥管理都收口；是否支持 Token 计量的细粒度拆分，至少能看到每个会话消耗了多少输入、多少输出；是否支持私有化或专有网络部署，满足数据合规要求。

L1 要重点看五件事：上下文管理，包括窗口截断、摘要压缩和关键信息保留策略；工具调用，是否原生支持 Function Calling，Tool Schema 是手动定义还是平台自动生成；记忆能力，短期记忆、长期记忆、向量记忆分别怎么存，能不能按业务隔离；RAG 链路，知识库切片、召回、重排是不是开箱即用，还是需要自己搭；稳定性和可观测性，单 Agent 在连续运行 1000 次任务后，失败率是多少，日志能不能还原每一次决策路径。

我见过不少平台在 L0 做得漂亮，模型随便切，但 L1 的记忆和工具调用是短板。典型症状是：Agent 跑单个任务还行，一旦上下文超过窗口，就开始“失忆”，反复问用户已经给过的信息。选型时别光看演示，要让对方当场跑一个长上下文场景。

2.2 L2-L3 决定你能跑多复杂

L2 编排层解决的是“多步骤任务怎么组织”。一个企业级任务通常是这样的：先解析用户意图，再判断需要调哪些工具，并行拉取数据，中间可能要人工确认，最后生成结论并归档。这背后不是一个 Agent 调用，而是一个有分支、有并行、有兜底的状态机。

选型时要看编排引擎支持哪些节点类型，顺序、并行、分支、循环、人工审批；失败重试和超时策略是否可配置；人机协同节点是否完善，能不能在关键环节插入人工审批；编排实例有没有版本管理，线上跑的是 v3，能不能随时回滚到 v2。另外强烈建议关注编排的可观测性，每个节点开始时间、结束时间、输入输出、token 消耗是否都有 trace。没有 trace 的编排层，出问题只能靠猜。

L3 多智能体协作解决的是“多个 Agent 怎么分工”。常见模式有三种：编排者-工作者模式，一个主 Agent 拆解任务，分发给多个专业 Agent；管道模式，任务按顺序流经多个 Agent，每个只处理一段；共享黑板模式，多个 Agent 通过共享上下文协作。没有银弹，模式要跟业务场景匹配。

这里有一个重要提醒：多 Agent 不是越多越好。很多团队觉得 Agent 数量多显得平台能力强，结果搞了十几个 Agent，上下文互相污染，token 消耗暴涨，问题定位困难。我见过一个项目，从 3 个 Agent 扩到 12 个，业务准确率反而降了 8 个百分点。选型时重点问清楚平台有没有提供上下文隔离、并发限制和 Agent 间通信的审计能力，这比支持多少个 Agent 同时在线更重要。

2.3 L4-L5 决定你能跑多久

L4 和 L5 决定了这个平台能不能在你企业里活过一年。L4 治理层解决安全、合规、成本问题，L5 组织智能层解决资产沉淀和规模扩展问题。这两个层级是企业和个人开发者的最大分水岭，我在下面第 4 节单独展开。

3. 从 L0 到 L3：决定技术下限的工程层

很多团队以为选型就是填对比表格，其实真正决定平台能不能落地的，是工程细节。这一节把 L0 到 L3 的实操要点逐层拆开，给出我在选型和落地中验证过的做法。

3.1 L0 接入层：模型网关、多路由与 Token 计量

L0 的落点是模型网关。企业通常不会只接一家模型，因为要留后手。今天 A 模型效果好，明天 B 模型价格降了怎么办；A 供应商限流了怎么办。所以网关至少要具备三个能力：统一 API 格式，业务层不需要感知底层模型切换；路由策略，按成本、按延迟、按场景自动选择模型；熔断和降级，某个模型连续报错时自动切到备用模型。

Token 计量是 L0 最容易被忽略的部分。我见过不少企业上线一个月后拿到账单直接懵了，费用比预估高了三倍，但完全拆不出来是哪个部门、哪个场景花的。选型时必须明确平台能不能按会话拆分 token 消耗，能不能按项目、部门、应用打标签。不要相信“后台能看到 token 总量”这种说法，总量没有拆分价值。

另外，模型接入不等于模型调优。企业里很多 Agent 效果差，根本不是模型选得不对，而是 Prompt 模板和 Tool Schema 写得粗糙。平台如果能提供 Prompt 版本管理和 Tool Schema 校验，会省掉大量线上排障时间。

3.2 L1 单 Agent：上下文、工具调用、记忆与 RAG

单 Agent 是企业的基本作战单元，它的工程化水平直接决定场景能否跑通。上下文管理是第一个坎。窗口有限，但业务上下文可能无限，常见的处理策略是：最近几轮完整保留，更早的内容做摘要压缩，关键信息抽成结构化字段长期保存。好的平台应该把这些策略做成可配置项，而不是让开发者自己在 Prompt 里手工拼。

工具调用是第二个坎。企业系统大多不是 OpenAI 兼容的 API，而是内部 RPC、HTTP 接口、数据库操作。平台至少要支持自定义 Tool 注册，能定义入参出参的 JSON Schema，最好还能生成自动校验和 Mock 测试。这里要问清楚一个问题：Tool 调用失败后，Agent 是会自己反思并换个方式重试，还是直接抛错给用户？前者需要平台提供错误回传和重试机制，这是单 Agent 成熟度的重要指标。

记忆和 RAG 经常混在一起讲，其实是两回事。记忆解决的是“跨会话记住用户偏好”，RAG 解决的是“从知识库检索事实”。选型时分别问：短期记忆存在 Redis 还是内存，长期记忆存向量库还是关系库，记忆能不能按用户、按租户隔离；RAG 的切片粒度可不可调，召回阈值怎么设，有没有重排序环节。很多平台把 RAG 做成一个黑盒，上传文档就能问答，但企业知识库往往有大量表格、扫描件、复杂排版，黑盒 RAG 的效果非常不可控。宁可平台功能朴素一点，也要保证链路可配置、中间结果可查看。

3.3 L2 编排层：Flow 不是流程图，是状态机

L2 是企业级 Agent 和玩具级 Demo 拉开差距的第一道分界线。很多可视化搭建平台都把编排做成了“连线画流程图”，看起来非常直观，但一上生产就露馅：分支条件复杂以后，画布根本维护不了；没有版本管理，改一个节点全流程都要跟着回归；并行节点经常被忽略，延迟直接翻倍。

我的建议是，把编排层当成状态机来理解，而不是流程图。每个节点都应该有明确的输入、输出、超时、重试和错误处理策略。选型时重点看三点：第一，支不支持并行执行，一个任务能不能同时调多个工具或多个子 Agent；第二，支不支持人工审批节点，审批动作能不能留痕，审批超时了怎么处理；第三，编排实例能不能被观测，每个节点从开始到结束的完整 trace 是否可查。

如果你用 Java 技术栈，Spring AI 这类生态可以让编排层和现有系统平滑集成；如果团队对性能和资源占用比较敏感，Rust 生态里写 Agent 服务也是值得盯的方向。但说实话，对于大部分企业，选平台时更应该关注编排引擎本身的质量，而不是自己从头造轮子。LanGraph 这类编排框架很灵活，灵活性意味着你要自己维护状态存储、并发控制、重试策略，这些工作在企业级场景里很快会变成运维负担。

3.4 L3 多 Agent：别让 Agent 数量成为新的技术债

多 Agent 是企业 AI 平台最容易被过度设计的一层。业务方觉得“我有十个场景，所以要十个 Agent”，这是典型的误区。十个 Agent 不是能力，是十份要维护的上下文，是十个要审计的决策链路，是十处可能互相污染的共享记忆。

我的经验是，先从最少的 Agent 数开始跑。一个场景能不能用单 Agent 解决，绝不引入第二个。只有当任务确实需要不同角色、不同知识域、不同权限边界时，才考虑拆分。比如一个客服场景，普通咨询和投诉处理需要的权限不同，知识库也不同，拆成两个 Agent 是合理的；但如果是“帮我查订单状态”这种任务，拆成三个 Agent 就是纯折腾。

多 Agent 协作选型时要问清楚：协作模式是编排者-工作者、管道式还是共享黑板式，平台默认支持哪种；上下文隔离怎么做，A Agent 的错误会不会污染 B Agent 的后续决策；资源隔离怎么做，某个 Agent 死循环了，会不会拖垮整个平台；跨 Agent 的审计怎么做，一次完整任务横跨了三个 Agent，能不能通过一个 trace ID 拉出全链路。

4. 从 L4 到 L5：企业级和 Demo 级的分水岭

前面三层的讨论，很多做 AI 平台的团队都能听懂。但从 L4 开始，话题会迅速变得冷清。因为讲模型能力、讲编排框架的人很多，能讲清楚权限模型、审计追溯、评测迭代、成本治理的人很少。而企业恰恰是为这四件事付钱的。

4.1 L4 治理层：权限、审计、评测、灰度、成本治理

权限是 L4 的第一道门。企业级 Agent 不只是一个聊天机器人，它会调用业务系统，这意味着权限失控的后果是灾难性的。选型时必须确认平台是否支持细粒度的 RBAC 或 ABAC，至少做到三层：谁能访问这个 Agent，谁能调用这个 Agent 的某个工具，谁能修改这个 Agent 的 Prompt 和配置。

审计日志是第二道门，也是最容易被供应商含糊其辞的模块。我的建议是选型时直接抛出六个问题：模型的每一次输入输出有没有记录；每一次工具调用的请求参数和返回结果有没有记录；每一次人类审批动作有没有记录；每一次 Prompt 或知识库变更有没有记录；这些日志能不能按 trace ID 串联；日志保留多久，能不能导出。任何一条答不上来的，都要小心。

评测和灰度是 L4 最容易在选型阶段被跳过、上线阶段被暴击的部分。企业上线 Agent 不能靠“感觉效果不错”，必须有评测集。我的做法是：每个场景准备至少 50 条离线评测样本，包括 35 条典型业务、10 条边界情况、5 条对抗样本，比如用户故意诱导 Agent 越权，或输入带有恶意指令的文本。离线评测通过后，再做线上影子模式或白名单灰度，只有 10% 流量跑新版本，跑一周对比准确率、延迟、token 消耗和用户投诉率，全部达标再全量。

成本治理是一个反直觉的话题。很多企业选型时盯着单价，上线后却被账单吓到。Agent 场景的 token 消耗和传统聊天完全不同：一次任务要多次调模型，每次都要带上下文，token 是成倍膨胀的。平台必须提供预算告警、单会话 token 上限、按部门拆分账单这些能力。没有成本治理的 Agent 平台，规模越大亏得越多。

4.2 L5 组织智能层：Agent 网络与组织级资产沉淀

L5 是 ClawMercs 分层框架里最有“未来感”的一层，也是最容易被画饼的一层。我的理解很务实：L5 解决的是组织级资产能不能复用的问题。企业今天做了一个客服 Agent，沉淀下来的工具调用、知识库切片、Prompt 模板、评测集，明天做另一个业务的 Agent 时能不能直接复用？这才是组织智能的含义，不是玄学，是资产复用率。

L5 落到选型层面有三个具体指标：能不能沉淀工具资产，一个 Agent 里定义的 Tool 可以被另一个 Agent 引用，而不是各自重新写一遍；能不能沉淀知识资产，知识库按业务域管理，多个 Agent 安全共享，并且有清晰的权限边界；能不能沉淀评测资产，上一轮积累的评测集可以自动回归到新版本，防止改 A 场景弄坏了 B 场景。

今年几家云厂商发布的 AI Agent 白皮书，核心口径出奇一致：从模型能力转向工程治理能力。这其实印证了同一件事——当一个技术从探索期进入落地期，大家关注的焦点就会从“能做到什么”变成“能不能稳定、安全、可控地做到”。L5 不是让你现在就实现全公司 Agent 大联合，而是要求平台具备向上演进的架构能力。如果平台连工具资产复用都做不到，L5 就是空谈。

5. 一周能跑完的 PoC 验收清单

再好的分析框架，最终都要落到“你把这个平台部署起来跑一遍”。我给企业做选型时，通常会安排一个一周的 PoC，四个阶段，每个阶段有明确的通过标准。这一节直接给清单，可以抄作业。

5.1 PoC 四阶段怎么做

第一阶段是环境搭建，控制在一天到两天。要完成平台部署或开通、模型网关接入、基础账号和权限配置。通过标准很简单：48 小时内，一个内部员工能登录平台，能打开聊天界面，能向 Agent 发起对话并拿到回复。如果这一步都磨磨蹭蹭，后面不用看了。

第二阶段是场景打通，控制在两天。选一个真实的小闭环业务场景，不要选大而全的，我的经验是选“查一个数据 + 做一次判断 + 生成一段结论”这种。要求完成至少 3 个工具接入、1 条知识库配置、1 条简单编排链路。通过标准是：场景在人工核验下准确率达到 90% 以上，这里的 90% 是业务人员核验，不是技术人员自评。

第三阶段是压测，控制在一天。并发目标按 1.1 节算好的数字来压，至少跑到 100 个并发会话。观察三个指标：P95 延迟是否在目标范围内，token 消耗是否和预估一致，模型网关有没有触发限流或熔断。通过标准是：P95 延迟达标，且没有出现级联故障，也就是一个模型限流不会拖垮整个 Agent。

第四阶段是治理验证，控制在一天。验证 RBAC 权限是否生效，测试一个低权限账号能否越权调用工具；验证审计日志是否完整，跑几个任务后能否按 trace ID 拉出全部链路；验证预算告警是否可用，设置一个低预算阈值，观察触发情况。通过标准是：权限不越权、日志可回溯、告警可触发。

我把验收项整理成一张表，方便直接拿去和供应商对线：

5.2 最容易做废的三件事

PoC 做废通常不是因为技术不行，而是因为三个错误。第一个错误是选场景太复杂。PoC 的目的是验证平台能力，不是验证业务方案，场景越简单越好，只要能把工具调用、RAG、编排、审计这几个关键点都覆盖到就行。第二个错误是只让技术人员参与验收。准确率必须由业务人员评判，否则技术人员觉得效果不错，业务方一句“这不是我要的”就全盘推翻。第三个错误是只看功能不看运维。PoC 期间就要逼供应商演示日志查询、故障恢复、版本回滚，这些在演示时没人看，上线后天天要看。

6. 选型中的高频问题与我的实际处理办法

写到这里，基本都是方法论。最后这一节聊点更实际的，把我在选型一线被反复问到的问题挑几个，给出我的处理办法。这些问题没有标准答案，但有相对靠谱的解法。

6.1 高频问题速查表

6.2 关于自研、开源与商业平台的一点看法

ClawMercs 这类按分层组织能力的平台，和扣子这类可视化搭建平台、LangGraph 这类开源编排框架，并不是零和竞争。我见过最好的组合是：用可视化平台快速验证业务场景，确认有价值后再迁到更开放的架构上，最后把核心能力沉淀成内部平台。开源框架适合有工程能力的团队，商业平台适合想快速上线的团队，自研只适合组织规模已经大到外部平台满足不了特殊需求的团队。

扣子这类可视化搭建平台适合原型和轻业务，这是它的优势。但企业级落地时，可视化编排的缺陷会暴露出来：版本管理弱、代码评审没法做、审计完整性不够。反过来，全代码方案又会让业务团队完全无法参与。所以选型的核心不是“哪个更高级”，而是“哪个和你团队的工程能力、业务节奏匹配”。

我个人的体会是，选 AI Agent 平台，最贵的不是模型 token，而是团队对失败的定义。如果团队能接受“先小范围跑起来，错了再迭代”，一个八十分的平台也能跑出九十分的效果；如果团队追求“一次到位”，再好的平台也会被过度设计拖垮。ClawMercs 分层框架最大的价值，不是帮你判断哪个平台最先进，而是让甲方、乙方、业务方能在同一个坐标系里把问题吵清楚。选型不是做榜单，是给未来两三年买一张能力边界，边界画得越清楚，后面的路越好走。