开发框架与 MCP 工具生态

什么时候需要开发框架

无代码平台适合标准场景，但当你需要精细控制每一步逻辑、复杂的多步编排，或把智能体深度嵌入自有产品时，就该转向代码框架。产品经理不需要写代码，但要知道框架的分工——这决定你和工程师讨论时用的是哪套词汇、画的哪张图。

三大框架的分工

框架	定位	产品视角
LangChain	最流行的 LLM 应用开发库，组件生态庞大	生态最大、组件最多，构建单智能体应用的默认起点
LangGraph	LangChain 系的图式编排框架，显式管理状态与流程	复杂多步工作流的生产环境首选，可控性与可调试性更强
CrewAI	多智能体框架，以角色和任务定义协作	快速搭建「多个角色协作的团队」，适合角色分工明确的场景

选型直觉：单智能体的复杂流程用 LangGraph；多角色协作的原型用 CrewAI；两者都建立在 LangChain 生态之上。 近年的趋势是，生产环境更偏爱 LangGraph 这类显式状态图——可控性比「自动涌现的智能」更受欢迎。

MCP：工具接入的「USB-C」

MCP（Model Context Protocol） 是 Anthropic 于 2024 年推出的开放协议，用于标准化模型与外部工具的连接方式。在它之前，每接一个工具（数据库、文件系统、第三方 API）都要写一份定制集成；有了 MCP，工具方实现一次，所有支持协议的模型和应用都能直接使用——所以它常被比作「AI 的 USB-C 接口」。

到 2025-2026 年，MCP 已成为行业事实标准，主流模型与应用广泛支持，并形成了围绕它的工具生态。

这对产品经理意味着三件事：

• 接入成本骤降：你的产品要连的企业系统，可能已有现成的 MCP 服务器可直接复用；
• 工具变资产：为自家产品写的 MCP 工具，能被任何支持协议的客户端使用，相当于多了一条分发渠道；
• 架构决策：新项目的工具层应默认按 MCP 设计，而不是为每个集成单独开发维护。

产品经理如何参与工具集设计

工程师实现工具，但决定「有哪些工具、每个工具管什么」是产品问题。协作方式：

1. 从任务反推工具：列出智能体要完成的核心任务，对每个任务问「它需要哪些操作与信息」，汇总成工具清单；
2. 控制粒度：工具太少（一个工具干十件事）模型难以正确调用，太多太碎则调用链冗长。经验粒度是「一个工具 = 一个用户可理解的业务动作」；
3. 写好工具描述：工具名称与参数说明是模型决策的依据，值得像打磨产品文案一样对待——这件事产品经理可以直接上手；
4. 设计权限与确认：哪些工具可以自动执行，哪些必须用户确认（如发邮件、改数据）？这是产品与安全共同的决策。

产品决策提示：把工具集当成产品的「功能清单」来管理：有版本、有优先级、有下线流程。工具描述措辞的改动，对调用准确率的影响可能超过换模型——改文案的成本远低于改代码，优化优先在这里迭代。

本节要点

• 无代码够用就不上框架；需要精细控制、复杂编排或深度嵌入时，再转向代码框架。
• LangGraph 以显式状态图换取可控性，是复杂工作流的生产环境首选；CrewAI 适合多角色协作原型；两者都基于 LangChain 生态。
• MCP 是 Anthropic 2024 年推出的工具接入开放协议，已成行业事实标准，把「一次集成」变成「处处可用」。
• 工具集设计是产品决策：从任务反推清单、控制粒度、打磨描述、设计确认机制。
• 工具描述是性价比最高的优化点：先改文案，再动代码。