客服主管提的需求通常长这样：Agent 要能查订单、改收货地址、判断退换货规则，改地址前得有个人点确认。工具怎么接、平台选哪家、上线三个月后拿什么证明它值——这三件事比模型选型更容易卡住项目。
MCP 标准化了“接工具”，但只标准化了一半
MCP（Model Context Protocol）由 Anthropic 在 2024 年 11 月开源。它定义了一种 Server：把外部能力（数据库查询、工单系统、文件系统）暴露成 Tools、Resources、Prompts 三类原语，Agent 侧作为 Client 调用。
工程上省事的地方有两个：
- 工具描述和实现分开了。同一个 MCP Server，挂到百炼、扣子还是自建 Agent 框架上都能用，不必为每个平台重写一遍适配代码。
- 传输层收敛了。2025-03-26 那版规范引入 Streamable HTTP，取代早期的 HTTP+SSE 双端点写法，远程 Server 只剩一个入口，反向代理和鉴权好配很多。
- 鉴权边界。规范里对 OAuth 有定义，但“这个 Server 能读多少数据”要你在服务端自己收口。把一个带全库读权限的数据库连接交给 Agent，等于把权限问题推迟到出事那天。
- 写操作的责任。工具能改数据，就得有人对改动负责。常见做法是两段式：Agent 生成变更预览，人确认后由后端服务执行，Agent 不直接持有写权限。
- 成本。一次对话触发五六个工具调用，token 消耗和延迟都不是线性增长。
落地顺序建议：先接只读工具，跑两周看调用日志，再考虑写操作。
平台对比：四家的形态差异
| 平台 | 交付形态 | 运行时谁维护 | MCP / 插件 | 更适合谁 |
|---|---|---|---|---|
| 阿里云百炼 | 公有云 SaaS | 阿里云 | 提供 MCP 服务接入与自定义插件，模型调用走云账号计费 | 已在阿里云上的企业，模型、数据、账单想放一处 |
| 腾讯云智能体开发平台（ADP） | 公有云，部分产品可私有化 | 腾讯云或客户 | 工作流、知识库、插件体系；私有化方案需与商务确认 | 有等保、数据不出内网要求的客户 |
| 扣子 Coze | SaaS 为主；开源版 Coze Studio 可自托管（Apache 2.0，2025 年 7 月开源） | 字节或客户 | 插件生态规模大，发布渠道多 | 快速验证想法、做面向 C 端的 Bot |
| Dify | 开源可自托管，另有云版 | 客户或 Dify | 工作流加插件市场，社区版自己运维 | 数据要自己控、有运维人力的小团队 |
- 平台之间的差距，一半在编排界面，一半在周边。你已经在阿里云，百炼的权限、日志、账单和现有云账号是一套；换平台意味着重新接一遍。
- 扣子和 Dify 的开源版本解决了“能不能自己部署”，没解决“谁来跟着升级”。自托管意味着安全补丁、模型切换、依赖冲突都归你。
- Dify 的开源许可基于 Apache 2.0，附加了多租户 SaaS 和保留 logo 的限制，做对外售卖的产品前先把 LICENSE 读一遍。
- 没有一家在四个场景上都强，选型前先把场景定死。
四个场景：哪些能交出去，哪些必须留人
客服
能自动：订单和物流查询、退换货规则判定、工单分类打标、常见问题首轮答复、地址修改的预览生成。 必须留人：赔付金额、投诉升级、涉及账号安全的操作。 指标：一次解决率、转人工率、平均处理时长；护栏指标是错误工单率、回答里引用不存在的条款的比例。 坑：把知识库当成唯一手段。客服问题里能靠文档回答的通常不到一半，剩下要靠工具查真实数据。
销售
能自动：线索去重与打分、公开信息补全、首次触达的邮件或消息草稿、CRM 字段回填、会议纪要转成跟进项。 必须留人：折扣审批、合同条款、交付时间承诺。 指标：有效线索率、线索到 SQL 的转化率、首次响应时长。 坑：把“发出去了多少封”当成果。回复率不涨，量越大越像骚扰。
研发
能自动：代码库问答（这个函数在哪、谁改的）、issue 归类去重、PR 初审（命名、测试覆盖、明显错误）、CI 失败日志归类。 必须留人：合并决策、架构改动、生产变更。 指标：PR 首次评审等待时间、CI 失败平均定位时间、issue 重复率。 坑：让 Agent 直接提交代码而不走人工评审。一次事故就能把试点关掉。
法律
能自动：合同条款抽取、与标准模板的差异比对、法规和判例检索、合同要素表生成。 必须留人：出具法律意见、对外承诺、签字。 指标：条款抽取召回率先于准确率、单份合同初审工时、人工复核发现的漏项比例。 坑：把检索结果当结论。检索给的是候选材料，判断责任在律师。
ROI：把“节省工时”拆成能验收的数字
财务不认“效率提升明显”。给一个能算的式子：
净收益 =（节省工时 × 人力小时成本 × 采纳率）+ 增量毛利 − 模型与平台费用 − 集成一次性成本 − 维护人力
四个变量里，采纳率最容易被漏掉，也最容易让测算翻车。Agent 给出 1000 条建议，员工实际用了 200 条，节省就是 20%，不是 100%。上线前先测采纳率，两周的真实使用数据就够。
各场景的北极星指标和护栏指标：
| 场景 | 北极星指标 | 护栏指标 | 观测周期 |
|---|---|---|---|
| 客服 | 一次解决率 | 错误工单率、转人工率 | 周 |
| 销售 | 线索到 SQL 转化率 | 客户投诉率、退订率 | 双周 |
| 研发 | PR 首次评审等待时间 | 回滚次数、线上缺陷数 | 双周 |
| 法律 | 单份合同初审工时 | 漏项率、复核返工率 | 月 |
项目被关停的六个常见原因
- 只有检索，没有工具调用。用户问“我的订单到哪了”，Agent 引用了一段物流政策文档。这类项目上线即死。
- 权限一刀切。要么给全库读权限，要么什么都不给，中间没有按表、按字段、按行的分级。
- 改 prompt 靠感觉。没有评测集，A 场景好了、B 场景坏了看不出来。50 条真实问题起步就够。
- 知识库当垃圾桶。三年前的制度文件全传进去，检索出来的答案比不回答更麻烦。
- 试点铺太开。一次上四个部门，出问题时没人说得清是哪一环。
- 只算模型费。集成、数据清洗、值班维护的人力通常比模型调用费高。
选型清单
- 写下前三个高频任务，每个标明输入、输出、触发频率
- 列出需要写操作的动作，指定审批人和回滚方式
- 确认工具接入方式：平台插件市场挂载，还是自建 MCP Server
- 确认数据边界：能不能出内网、能不能出境、日志留多久
- 准备 50 条真实问答做评测集
- 定北极星指标和至少一个护栏指标
- 定成本上限和超限后的降级策略
- 灰度范围控制在一个小组、两周
今天能做完的一件事
打开工单系统或 CRM，导出最近一周的记录，按任务类型分组计数。排前三的类型，就是 Agent 该接的第一个位置。做完你手里就有一份比任何行业报告都贴自己业务的选型依据。
文中产品功能、开源许可与计费会变，动手前请以各家官网文档和仓库里的 LICENSE 文件为准。本文没有给出具体价格，国内平台调价频繁，写死的数字几周后就会过期。