🚀 AI产品经理

AIPM 要掌握的 Agent 技术架构与 MCP 协议


AI Agent MCP协议 技术架构

在 2025 年的今天，“智能体 (Agent)” 已经成为了 AI 领域的绝对热词。从 Manus 到 Devin，似乎一切软件都在 Agent 化。但作为一名产品经理，我不能止步于市场营销层面的概念，我们需要具备打开”黑盒”的能力，看清里面的齿轮是如何转动的。

当我们在 Coze、Dify 里搭建一个 Bot，或者直接调用 GPT-4o API 时，我们到底在构建什么？是 一条确定的链（Chain），还是 一个自主的循环（Loop）？是 封闭的系统，还是 开放的生态（MCP）？我将从技术架构视角，深度拆解 AI Agent 的运作机理（ReAct 模式、Function Calling），并重点探讨最新的 MCP 协议，使自己可以 在”确定性”与”智能性”之间做出正确的技术选型。

一、架构抉择：Chain (工作流) vs. Agent (智能体)

在产品落地中，很多被包装成”Agent”的产品，本质上其实只是”Workflow”。理清两者的架构差异，是 PM 做决策的第一步。 Chain vs Agent 架构

Chain / Workflow：确定性的管道

  • 架构逻辑： Start -> Step A -> Step B -> Step C -> End。这是一个 有向无环图。
  • 运作模式： 就像火车的轨道。系统严格按照 PM 编排好的 SOP（标准作业程序）执行。无论用户输入什么，流程的结构永远不变。
  • PM 视角：
    • 优点： 成本极低、响应极快、结果 100%可控。
    • 缺点： 缺乏”举一反三”的能力，遇到预设之外的情况会直接报错。
    • 适用场景： 容错率低、标准化程度高的 B 端业务。例如我的 “雷电模拟器活动搭建平台”，其本质就是一个高度自动化的 Workflow，不需要 AI 发挥”创意”，只需要它精准执行。

Agent：概率性的循环

  • 架构逻辑： Perceive（感知） -> Think（思考） -> Act（行动） -> Observe（观察） -> Loop（循环）。

  • 运作模式： 就像出租车司机。你只给目的地，路线由司机根据路况实时决定。这通常基于 ReAct (Reasoning + Acting) 架构。LLM 会不断自问：“我现在知道什么？我还缺什么信息？我该调用什么工具？“直到它认为任务完成。

  • PM 视角：

    • 优点： 极其灵活，能解决复杂的、多步骤的模糊问题。
    • 缺点： 成本不可控（可能陷入死循环）、耗时长、存在”幻觉”风险。
    • 适用场景： 开放性问题。例如我的 “小红书爆款研究智能体”，因为不同博主的笔记风格迥异，固定的流程无法处理，必须让 Agent 自主决定是先分析标题，还是先分析封面。 Agent 循环架构

二、核心技术基石：Function Calling 与”手脚”

大模型（LLM）本身只是一个”缸中之脑”，它存储了海量知识，但无法联网，也无法操作数据库。要实现 Agent，必须给它装上”手脚”。这就是 Function Calling (工具调用) 的意义。 MCP 协议架构

它是如何工作的？

不要把 Function Calling 想象成魔法。它的本质是 JSON 格式的结构化输出。

  1. 用户提问： “帮我查一下明天北京的天气。”
  2. Prompt 注入： 系统会偷偷告诉 LLM：“你现在拥有一个叫 get_weather(city, date) 的工具。”
  3. LLM 思考 (Routing)： LLM 分析语义，不直接回答问题，而是输出一个 JSON：{ "function": "get_weather", "params": { "city": "Beijing", "date": "tomorrow" } }。
  4. 系统执行： 后端代码拦截这个 JSON，去运行真正的 API，拿到数据。
  5. 生成回答： LLM 拿到数据后，将其转化为自然语言反馈给用户。

PM 的关键决策点：上下文窗口 (Context Window)

很多新手 PM 喜欢给 Agent 挂载几十个工具。但这会导致灾难。LLM 的上下文窗口是有限的。如果你塞入过多的工具定义，不仅会消耗大量 Token，还会导致 LLM “注意力分散”，选错工具的概率呈指数级上升。

AIPM 的心法： Less is More。 给 Agent 的工具越少、定义越清晰，它的表现就越稳定。

三、前沿趋势：MCP协议

在 2024-2025 年，AIPM 必须关注的一个颠覆性趋势是 MCP 协议。这是由 Anthropic 提出的标准，旨在成为 AI 应用的”USB 接口”。 混合架构策略

解决了什么痛点？

在 MCP 出现之前，如果我们要让 Cursor 读取本地代码，或者让 Claude 读取飞书文档，开发者需要为每一个模型、每一个数据源单独写连接器（Connector）。这导致了严重的数据孤岛。

MCP 的架构逻辑

MCP 建立了一个标准化的 Client-Host-Server 架构：

  • MCP Hosts (AI客户端)： 如 Claude Desktop, Cursor, 或企业内部的 AI 中台。
  • MCP Servers (数据源)： 如 Google Drive, Slack, GitHub, 或本地的 SQLite 数据库。

对 AIPM 的战略意义

这意味着，企业内的 AI 落地将不再受限于”昂贵的定制化开发”。作为 PM，我们可以利用 MCP 协议，以极低的成本将企业内部的私有数据（知识库、CRM）标准化地链接给各种 AI 模型。

例如，在设计 B 端 AI 助理时，只要企业的 CRM 系统支持 MCP 标准，我们的 Agent 就能即插即用，直接读取客户数据，而无需开发复杂的 API 中间件。

四、商业与架构的权衡：token消耗与体验

技术架构的选择，最终必须服务于商业目标。在 workflow 和 Agent 之间做选择，本质上是在算一笔账。 实战混合架构

隐形成本：Token成本核算

  • Workflow： 成本是线性的。一步消耗多少 Token 是可预算的。
  • Agent： 成本是指数级的。一个复杂的 ReAct Loop，LLM 可能会进行 10 次以上的”自言自语”和工具调用。
    • PM 警示： 如果你的商业模式是”按月订阅”但成本却是”按量计费”，Agent 架构可能会直接击穿你的利润模型。这也解释了为什么我在 AIGC 网站中将要引入 Credit（点数制） —— 这是平衡 Agent 成本波动的最佳商业手段。

用户体验：延迟的挑战

Agent 的每一次 Loop 都是一次网络请求。处理一个复杂任务可能需要 30 秒甚至更久。用户能忍受吗？

AIPM 的设计策略：

  • 流式输出： 必须让用户看到字是一个个蹦出来的，而不是转圈圈。
  • 透明化思考： 展示 Agent 的”思考过程”（如：“正在搜索数据库…”、“正在分析数据…”），这不仅能缓解等待焦虑，还能增加用户对结果的信任感。

我的实战结论：混合架构

在构建”小红书智能体”时，我没有盲目追求”全自动 Agent”。我采用了 “Coze Workflow 为主 + Agent 节点为辅” 的混合架构：

  • 对于数据抓取、清洗这类标准化步骤，使用 Workflow（低成本、快）。
  • 对于”爆款原因分析”这类需要灵感的步骤，嵌入一个 Agent 节点（高智能）。

这就是 AIPM 的价值所在：在技术理想与商业现实之间，找到那个完美的平衡点。