企业选AI Agent平台这件事，最近半年我被问到的频率明显高了起来。有意思的是，问的人分两类：一类是技术负责人，上来就问"你们用的哪个框架、支不支持多Agent协作"；另一类是业务线的负责人，问的是"这东西能不能真的替我把那堆重复活儿干掉"。这两类问题背后其实是同一个焦虑——市面上的AI Agent平台太多了，从开源框架到商业SaaS，从"拖拉拽就能搭"到"必须写代码"，选错了不只是浪费预算，更麻烦的是团队会在错误的方向上耗掉三到六个月，等发现不对劲的时候，业务侧的耐心已经磨没了。
我自己经历过一次选型翻车。当时被一个演示效果极好的平台吸引，POC阶段跑通了两个场景，团队很兴奋，结果一上生产就发现并发一高就排队、工具调用链路一长就丢上下文、想接内部系统还得改平台源码。那次之后我总结出一个教训：选AI Agent平台，不能只看它"能做什么"，要看它的能力是怎么分层的，以及每一层的边界在哪里。这也是我想借ClawMercs这个分层思路来聊的核心——把平台能力拆成协议层、编排层、工具层去看，很多选型时的纠结会瞬间清晰。
这篇内容适合三类人：正在做AI Agent平台选型的技术决策者、准备从零搭建Agent应用的开发者、以及想搞清楚"AI Agent到底怎么落地"的业务负责人。我会尽量少讲概念、多讲判断依据，把每一层该看什么、容易踩什么坑讲透。
1. 选型之前先想清楚：你要的到底是"平台"还是"能力"
很多人选型第一步就错了——拿着需求清单去对比平台功能列表，勾勾选选，最后选了个功能最全的。但功能全不等于适合你，因为AI Agent这个领域，"功能全"往往意味着"每一层都做得不深"。
1.1 先分清三种截然不同的需求
我把企业侧对AI Agent的需求粗略分成三类，你先对号入座：
- 第一类：单点自动化。比如让Agent自动处理客服工单分类、自动从合同里抽取关键字段、自动生成周报。这类需求的特点是流程相对固定、工具调用少、对编排能力要求低。你甚至不需要一个"平台"，一个框架加几个API就够了。
- 第二类：多步骤业务流程。比如"收到询盘→查库存→生成报价→发邮件→录入CRM"这种跨系统的链路。这类需求的核心难点在编排——步骤之间的依赖、失败重试、人工介入点、状态持久化。
- 第三类：多Agent协作。比如一个Agent负责调研、一个负责写作、一个负责审核，彼此传递任务。这类需求对协议层的要求最高，因为Agent之间怎么通信、怎么协商、怎么避免死循环，是真正的技术难点。
提示：大部分企业实际处在第一类和第二类之间，但选型时容易被第三类的演示效果带偏，买了个重型平台结果只用到了皮毛。
1.2 "平台"和"框架"的本质区别
这里必须澄清一个常见混淆。框架（比如LangChain、LangGraph这类）给你的是积木，你得自己搭；平台给你的是搭好的房子，你拎包入住但改造空间有限。
判断标准很简单：如果你的团队有稳定的工程能力，且业务逻辑会频繁变化，选框架更灵活；如果你的团队工程资源紧张，且业务场景相对标准，选平台更省事。最怕的是团队没工程能力却选了框架，最后搭到一半发现维护不动；或者业务变化极快却选了封闭平台，改一个流程要求爷爷告奶奶。
1.3 一个反直觉的判断：先看"退出成本"
我现在的选型习惯是，先不看平台能做什么，先看如果我要换掉它，成本有多高。具体看三件事：
| 退出成本维度 | 低风险信号 | 高风险信号 |
|---|---|---|
| 数据可迁移性 | Agent配置、Prompt、知识库可导出为标准格式 | 只能存在平台内，导出即失效 |
| 工具接入方式 | 通过标准协议（如HTTP、OpenAPI）接入 | 必须用平台私有SDK，深度耦合 |
| 编排逻辑归属 | 编排逻辑在你自己的代码/配置里 | 编排逻辑锁死在平台的可视化编辑器里 |
这个视角能帮你过滤掉一大批"演示很美、迁移很痛"的平台。我见过太多团队被一个漂亮的拖拽界面吸引，半年后想加一个自定义逻辑，发现平台根本不支持，只能推倒重来。
2. 协议层：Agent之间怎么"说话"，决定了系统的天花板
协议层是三层里最容易被忽视、但长期影响最大的一层。它解决的是一个根本问题：当系统里有多个Agent、多个工具、多个外部服务时，它们之间用什么规则交换信息。
2.1 协议层到底在管什么
你可以把协议层理解成"Agent世界的交通规则"。它规定了：
- 消息格式：Agent之间传递的任务、上下文、结果用什么结构表达
- 调用约定：一个Agent怎么请求另一个Agent或工具，怎么拿到返回
- 状态传递：多步骤执行时，上下文怎么在步骤间流转而不丢失
- 错误语义：调用失败、超时、拒绝时，各方怎么理解和处理
举个生活化的类比：协议层就像公司内部的"公文格式规范"。如果每个部门都用自己的格式写公文，跨部门协作就会一团乱。协议层的作用就是让所有Agent说同一种"普通话"。
2.2 为什么协议层决定了天花板
这里有个关键判断：协议层的能力上限，决定了你整个Agent系统能复杂到什么程度。
如果你的协议层只支持简单的"请求-响应"，那你最多做单点自动化；如果支持流式传递、支持多轮协商、支持任务分解与合并，你才能做多Agent协作。很多平台在演示时展示的多Agent协作，其实是硬编码的固定流程，一旦业务逻辑变化就崩，根本原因就是协议层不支持动态协商。
2.3 选型时怎么考察协议层
我一般会问平台方几个具体问题，答案能快速暴露协议层的真实水平：
- Agent之间的通信是同步还是异步？同步简单但容易阻塞，异步灵活但复杂度高。生产环境通常需要异步。
- 上下文窗口怎么管理？多步骤执行时上下文会膨胀，平台是自动压缩、滑动窗口还是让你自己管？
- 支不支持人工介入（Human-in-the-loop）？关键决策点能不能暂停等人工确认？这是企业场景的刚需。
- 失败重试和幂等性怎么保证？一个步骤失败了，重试会不会导致重复下单、重复发邮件？
注意：如果平台方对这几个问题回答含糊，或者只会说"我们支持"，但拿不出具体的机制说明，基本可以判断协议层是薄弱的。
2.4 协议层的常见坑
我踩过最深的一个坑是上下文丢失。当时做一个多步骤的报销审批Agent，前面几步都正常，到第五步突然发现前面收集的信息没了。排查半天才明白，平台的协议层在步骤间传递上下文时有个隐式的长度限制，超了就静默截断。这种坑在演示阶段根本发现不了，因为演示的流程都很短。
另一个坑是错误语义不统一。工具A超时返回的是异常，工具B超时返回的是空结果，Agent拿到这两种返回后行为不一致，导致整个流程时好时坏。好的协议层应该统一错误语义，让上层编排逻辑不用为每个工具写特殊处理。
3. 编排层：把"能干活"变成"干得对、干得稳"
如果说协议层是交通规则，编排层就是"调度中心"。它决定了一个任务怎么被拆解、按什么顺序执行、遇到问题怎么办。这是三层里和业务逻辑贴得最近的一层，也是选型时最该花时间考察的一层。
3.1 编排层的三种典型形态
市面上的编排层大致分三种，各有适用场景：
- 可视化编排：拖拽节点、连线成流程。优点是上手快、业务人员也能改；缺点是复杂逻辑表达困难，版本管理混乱，调试痛苦。
- 代码编排：用代码定义流程（比如用状态机、用图结构）。优点是灵活、可测试、可版本控制；缺点是有门槛，业务人员改不动。
- 混合编排：核心流程用代码，可变部分用配置。这是我认为最务实的选择，但要求平台设计得好。
我的经验是：流程步骤少于10步、变化不频繁的，可视化够用；超过10步或者逻辑有分支循环的，一定要选代码编排或混合编排。我见过用可视化编排硬扛复杂审批流的团队，最后画出来的流程图跟蜘蛛网一样，没人敢改。
3.2 编排层必须考察的五个能力
这部分是干货，建议直接拿去当选型checklist：
| 能力 | 为什么重要 | 怎么验证 |
|---|---|---|
| 状态持久化 | 流程执行到一半服务重启，状态不能丢 | 问清楚状态存哪、重启后能否恢复 |
| 条件分支与循环 | 真实业务几乎都有分支和循环 | 让平台方现场演示一个带循环的场景 |
| 并行执行 | 多个独立步骤并行能大幅提速 | 问清楚并行度怎么控制、结果怎么合并 |
| 超时与重试策略 | 外部调用不稳定是常态 | 问清楚重试次数、退避策略能否配置 |
| 可观测性 | 出问题要能快速定位 | 看有没有执行链路追踪、每步的输入输出日志 |
3.3 并发：被严重低估的选型指标
"AI Agent怎么扛并发"是最近被搜得很多的问题，说明大家开始从POC走向生产了。并发这件事在编排层的体现是：同一个Agent流程，能不能同时处理多个请求而不互相干扰。
这里有个容易忽略的点：Agent流程往往包含LLM调用，而LLM调用是慢的（几秒到几十秒）。如果编排层是同步阻塞的，10个并发请求就会排队，第10个用户要等前面9个跑完。生产环境这不可接受。
考察并发能力，我会问：
- 单个流程实例之间是否隔离？A用户的上下文会不会串到B用户？
- LLM调用是阻塞还是异步？支不支持流式返回？
- 有没有限流和排队机制？高峰期怎么保护后端？
提示：并发能力在演示阶段几乎看不出来，因为演示都是单请求。一定要在POC阶段做压力测试，用真实并发量去压。
3.4 编排层的调试体验
这一点很少有人提，但实际影响巨大。Agent流程出问题时，你需要知道：是哪一步错了、当时的输入是什么、LLM返回了什么、为什么走了这个分支。
好的编排层应该提供完整的执行轨迹：每一步的输入、输出、耗时、决策依据都能看到。差的编排层只给你一个"执行失败"，然后你只能靠加日志一点点猜。我在选型时会把"调试体验"的权重放得很高，因为它直接决定了你后续的维护成本。
4. 工具层：Agent的"手脚"好不好用，决定落地成败
工具层是Agent真正"下地干活"的地方。协议层和编排层再优雅，如果工具层接不上你内部的系统，一切都是空谈。这一层最接地气，也最容易在选型时被低估。
4.1 工具层的核心问题：怎么把内部系统"喂"给Agent
企业内部的系统五花八门：有标准的REST API，有老掉牙的SOAP接口，有只能通过数据库访问的，还有压根没有API只能靠界面操作的。工具层要解决的就是把这些系统统一封装成Agent能调用的工具。
考察工具层，核心看两点：接入的便捷性和接入后的可维护性。
接入便捷性方面，好的平台应该支持：
- 通过OpenAPI/Swagger文档自动生成工具定义
- 支持自定义函数注册
- 对没有API的系统，提供某种桥接方案
可维护性方面，要看工具定义能不能版本管理、能不能做权限控制、能不能监控每个工具的调用情况。
4.2 工具调用的可靠性设计
工具调用失败是常态，不是异常。网络抖动、对方服务重启、参数格式不对，都会导致失败。工具层必须内建可靠性设计：
- 参数校验：调用前校验参数，避免把错误参数发给后端
- 超时控制：每个工具调用都要有超时，不能让一个慢工具拖垮整个流程
- 重试与降级：可重试的错误自动重试，不可重试的走降级逻辑
- 幂等保证：对于有副作用的操作（下单、发消息），要保证重试不会重复执行
我踩过一个坑：一个发通知的工具没有做幂等，重试机制触发后用户收到了三条一样的通知，被投诉了。后来在工具层加了幂等键才解决。这类问题在选型时就要问清楚平台有没有内建支持，别指望自己后期补。
4.3 工具的安全边界
工具层直接接触内部系统，安全边界必须清晰：
- 权限最小化：每个Agent只能调用它需要的工具，不能全都能调
- 敏感操作二次确认：删除、支付、对外发送这类操作，要有确认机制
- 审计日志：谁在什么时候调用了什么工具、传了什么参数，都要留痕
注意：安全这块在POC阶段经常被跳过，但生产环境是硬要求。选型时如果平台在权限和审计上很薄弱，后期补起来会非常痛苦。
4.4 工具层的扩展性
业务会变，工具也会变。今天接了5个工具，明天可能要接20个。工具层的扩展性体现在：
- 新增工具是否需要改平台代码？理想情况是配置化接入
- 工具多了之后怎么组织？有没有分类、标签、搜索
- 工具之间的依赖怎么管理？
我建议选型时直接问平台方："如果我要接入一个你们没见过的内部系统，需要几步、要不要写代码、要不要改你们的东西？"这个问题的答案基本能反映工具层的真实扩展性。
5. 三层怎么配合：一个真实的选型决策过程
前面把三层拆开讲了，但实际选型时三层是联动的。我用一个真实场景串一下，你会更清楚怎么综合判断。
5.1 场景：智能客服工单处理
需求是这样的：客户发来工单→Agent理解意图→查知识库→如果需要查订单就调订单系统→生成回复→复杂问题转人工。
拆到三层看：
- 协议层：需要支持人工介入（转人工），需要上下文在"理解→查询→生成"之间传递
- 编排层：有条件分支（要不要查订单）、有外部调用（订单系统）、需要状态持久化（工单处理可能跨小时）
- 工具层：要接知识库、订单系统、工单系统，订单查询要幂等
5.2 三层能力不匹配会怎样
假设你选了个协议层薄弱但工具层丰富的平台，会发生什么？
- 转人工时上下文丢失，人工客服看不到Agent已经收集的信息
- 多轮对话时上下文管理混乱，Agent反复问同样的问题
- 工具虽然多，但因为编排层不支持条件分支，只能做线性流程
反过来，如果协议层和编排层强但工具层弱：
- 流程设计得很优雅，但接不上订单系统，只能做纯问答
- 每个工具都要自己写适配代码，开发成本高
结论是：三层要均衡，任何一层明显短板都会拖垮整体。选型时不要被某一层的亮点迷惑，要看最短的那块板。
5.3 一个实用的评估打分表
我把上面的考察点整理成一个打分表，选型时可以直接用：
| 层级 | 考察项 | 权重 | 评分(1-5) |
|---|---|---|---|
| 协议层 | 上下文管理机制 | 高 | |
| 协议层 | 人工介入支持 | 高 | |
| 协议层 | 错误语义统一 | 中 | |
| 编排层 | 状态持久化 | 高 | |
| 编排层 | 并发与隔离 | 高 | |
| 编排层 | 调试可观测性 | 高 | |
| 编排层 | 条件分支与循环 | 中 | |
| 工具层 | 接入便捷性 | 高 | |
| 工具层 | 调用可靠性 | 高 | |
| 工具层 | 权限与审计 | 高 | |
| 工具层 | 扩展性 | 中 |
打分之后不要简单加总，而是看有没有任何一项是1分。如果有，基本可以排除，因为短板效应在Agent系统里特别明显。
6. 选型之后：落地阶段最容易翻车的几件事
选完平台只是开始，落地才是真正的考验。这部分分享几个我在落地阶段踩过的坑，都是选型时想不到、但一定会遇到的。
6.1 Prompt和配置的版本管理
Agent的行为很大程度上由Prompt和配置决定。上线后你会发现，改一个Prompt可能让整个流程行为大变。如果没有版本管理，出了问题根本回不去。
我的做法是：把Prompt和Agent配置当成代码来管，进Git、走评审、可回滚。选型时要确认平台支不支持配置的导入导出和版本对比，不支持的话后期会很痛苦。
6.2 从POC到生产的鸿沟
POC阶段跑通一个场景，和生产环境稳定运行，中间隔着巨大的鸿沟。POC关注"能不能跑通"，生产关注"跑得稳不稳、快不快、出问题能不能查"。
我建议在POC阶段就引入生产级的考量：用真实数据量、真实并发、真实异常场景去测。别等到上线才发现问题，那时候改造成本高得多。
6.3 团队能力的匹配
最后一点，也是最容易被忽略的：平台再强，团队用不起来也白搭。选型时要诚实评估团队的能力：
- 团队有没有人能读懂平台的编排逻辑？
- 出问题时有没有人能排查？
- 业务变化时有没有人能快速改？
如果团队工程能力弱，就选开箱即用程度高的平台，别贪图灵活性；如果团队强，就选扩展性好的，别被"简单易用"限制住。
6.4 一个关于"够用就好"的体会
我最后想说的是，AI Agent平台选型没有"最好"，只有"最合适"。我见过团队为了追求技术先进性选了个重型平台，结果80%的功能用不上，反而增加了维护负担。也见过团队用最简单的方案解决了实际问题，跑得很稳。
判断标准应该是：这个平台能不能用合理的成本，稳定地解决我当前和可预见未来的问题。超出这个范围的"能力"，很多时候是负担而不是优势。ClawMercs这套分层思路的价值，不在于告诉你哪个平台好，而在于给你一个拆解问题的框架——把复杂的选择拆成协议层、编排层、工具层三个可判断的问题，选型就从"凭感觉"变成了"有依据"。
我在实际使用中的一个体会是，选型讨论最容易跑偏的地方，是大家争论"哪个平台更强"，但真正该争论的是"我们的问题到底在哪一层"。把这个问题想清楚，答案往往自己就浮出来了。
