MCP
最近我一直在思考一个问题：传统 SaaS 到底应该怎么转向 AI？ 一开始很容易想到的方向是：给原来的系统加一个 AI 助手。 比如在页面右下角放一个聊天框，让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值，但我现在越来越觉得，这只是比较表层的一种转型。 真正的变化，可能不是“在 SaaS 里面加 AI”，而是 SaaS 本身的能力形态发生变化。 过去的 SaaS，核心是给人使用。 人登录系统，看页面、点按钮、筛选数据、导出报表、判断问题，然后再去做决策。数据库是给 Web 页面供数的，后端 API 是给前端页面服务的，整个产品的中心是“人如何操作软件”。 但 AI 时代，尤其是 Agent 逐渐发展之后，
MCP
理解 MCP、JSON-RPC、Streamable HTTP 的过程中，有一个很自然的联想： 这不就是固定一个 POST 接口，然后传入不同 JSON，根据请求体里的字段返回不同响应吗？ 这个直觉是对的。 尤其是当 MCP 走 Streamable HTTP 的时候，表面上看确实很像： POST /mcp 然后请求体里传： { "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "search", "arguments"
MCP
做 MCP 相关项目时，经常会遇到几个词： MCP JSON-RPC Transport stdio SSE Streamable HTTP 这些词经常一起出现，如果不把层次拆开，很容易混在一起。 这篇文章尝试从工程开发的角度，把它们之间的关系梳理清楚。重点不是翻译标准文档，而是建立一套比较稳定的理解模型。 一、先分清三层：MCP、JSON-RPC、Transport 可以先记住这句话： MCP 负责：Agent 能调用什么能力 JSON-RPC 负责：调用消息长什么样 Transport 负责：消息怎么传过去 也就是： MCP = 协议语义层 JSON-RPC = 消息格式层 Transport = 传输层 更直观一点： MCP： 我要调用工具、读取资源、获取 prompt JSON-RPC： method 是什么，
MCP
Agent 的工作方式 我们以为 MCP 服务只是查数据的管道，拆开一看，发现服务端已经把分析结论都算好了。这个发现改变了我对 Agent 架构的理解。 起因：一次对 MCP 服务的逆向探索 最近在研究 MCP（Model Context Protocol）的实际应用，我选了一个真实的商业 MCP 服务 —— 某电商卖家流量分析平台作为研究对象。该服务提供了 27 个工具，覆盖关键词分析、流量运营、广告洞察等领域。 最初的预期很简单：MCP 服务就是一个数据接口，Agent（LLM）调用它拿到原始数据，然后自己分析、得出结论、给用户建议。 实际拆开一看，完全不是这么回事。 第一个发现：返回数据里藏着完整的分析结论 我写了一个 Python 脚本，绕过所有 AI 客户端，直接用
MCP
一次从"会用"到"理解原理"再到"能优化"的完整探索记录。 本文记录了我通过实际动手连接一个远程 MCP 服务（SIF —— 亚马逊卖家流量分析平台），一步步深入理解 MCP 协议机制、LLM 上下文管理、注意力资源分配、以及工具编排优化方案的全过程。 一、起点：连上一个真实的 MCP 服务 什么是 MCP？ MCP（Model Context Protocol）是 Anthropic 主导设计的一个开放协议，目的是标准化 AI 应用与外部工具/数据源之间的通信方式。你可以把它理解为"AI 世界的 USB 接口"
MCP
https://github.com/jlowin/fastmcp 这篇文章是我学习 FastMCP 的一次系统整理：从 MCP 到 FastMCP 的组件设计，再到 Provider、Transform、Context、任务与部署方式。目标是把零散笔记变成一条能走通的理解路径。 1. 我先把 MCP 讲清楚：它解决的到底是什么问题？ 很多时候 AI “会想”，但它不会“做”。 * 想查数据库 * 想调用内部 API * 想发邮件或写文件 如果没有一套标准的协议，AI 客户端（Claude、Cursor 等）就很难稳定、安全、可扩展地调用你提供的能力。 MCP（Model Context Protocol）就是这套标准协议： * 客户端用统一的方式发起调用请求 * 服务器用统一的方式暴露工具、资源和提示词
陕公网安备61011302002223号