用 LangGraph 和 MCP 做工具型 Agent：先把边界想清楚

今天在 CSDN 搜 MCP AI Agent LangGraph Tool Calling，搜索结果里有一篇很像开发者会点开的文章：

• 《100 行代码搞一个带 MCP 工具的 AI Agent：LangGraph + DeepSeek V4 实战》：https://blog.csdn.net/weixin_50937681/article/details/160959875

这篇文章显示的作者是“自律懒人”，日期是 2026-05-10。正文页这次仍然被 CSDN 的 403 Forbidden / WAF 拦住，所以我没有读到原文内容，也不会复述它的实现细节。

但这个标题本身给了一个不错的选题信号：大家已经不只是在问“Agent 是什么”，而是在问“怎么用一小段代码，把模型、工具和执行流程接起来”。如果要把这个方向真正落地，我会先看三件事：LangGraph 管状态，MCP 管工具边界，Agent 管循环。

LangGraph 适合处理“下一步怎么走”

LangGraph 官方文档把它描述为一个面向长期运行、有状态 Agent 的底层编排框架和运行时。它关注的不是帮你写一个更漂亮的 prompt，而是让一个多步骤流程能被表达、执行、恢复和观察。

官方文档：https://docs.langchain.com/oss/python/langgraph/overview

这点很关键。简单问答通常是一来一回：用户输入，模型回答，结束。工具型 Agent 不一样，它可能要经历这些步骤：

1. 理解用户目标。
2. 判断是否需要调用工具。
3. 生成工具参数。
4. 执行工具。
5. 读取工具结果。
6. 决定继续调用、改路线，还是结束。

如果这些步骤都塞在一段临时脚本里，刚开始会很快，但后面很难排错。你不知道模型为什么调用了这个工具，也不知道失败后它应该重试、停止还是换工具。

用图来表达流程，价值不在“看起来高级”，而在把状态和转移条件摆到台面上。一个节点负责模型判断，一个节点负责工具调用，一个节点负责结果整理，再加上明确的结束条件，Agent 才不容易变成无限循环的黑盒。

MCP 适合处理“工具怎么暴露给模型”

MCP 官方文档把它定义为连接 AI 应用和外部系统的开源标准。它让 AI 应用可以连接数据源、工具和工作流，比如本地文件、数据库、搜索工具、计算器或特定提示流程。

官方文档：https://modelcontextprotocol.io/docs/getting-started/intro

放到工具型 Agent 里，MCP 的价值不是“多一个协议名”，而是把工具边界标准化。

比如一个 Agent 要读文件、查数据库、跑脚本、调用浏览器。每个工具如果都用临时函数接进去，很快会遇到几个问题：

• 工具描述不统一，模型不知道什么时候该用哪个。
• 参数格式不稳定，失败时很难自动修正。
• 权限边界模糊，读操作和写操作混在一起。
• 工具结果只适合人看，不适合模型继续处理。

MCP 不能自动解决所有工程问题，但它至少逼你把工具能力说清楚：这个工具叫什么，能做什么，要什么输入，返回什么输出，有哪些风险。对 Agent 来说，这比“我这里有个函数你试试看”靠谱得多。

最小可用 Agent，不是代码越短越好

“100 行代码”很适合做入门标题，但真正值得关心的不是行数，而是边界有没有写清楚。

一个最小可用的工具型 Agent，我会按这个结构拆：

用户目标
  ↓
状态初始化
  ↓
模型判断：是否需要工具
  ↓
工具调用：通过 MCP 暴露的工具执行
  ↓
观察结果：把工具输出写回状态
  ↓
继续 / 结束 / 人工确认

这套结构里，每一层都要有明确职责。

LangGraph 负责让流程有状态、有节点、有转移条件。MCP 负责让工具以稳定、可描述的方式暴露出来。模型负责根据当前状态做判断，但不应该拥有无限制的自由。

如果没有这些边界，Agent 很容易出现几类问题：

• 工具调用成功了，但其实调用错了场景。
• 工具返回一大段日志，模型抓不到关键结果。
• 网络失败后反复重试，浪费额度和时间。
• 写文件、发请求、提交代码这类动作没有确认。
• 调试时只能看到最终答案，看不到中间状态。

这些问题不是多写几句 prompt 就能稳定解决的。它们需要流程设计。

真正该优先设计的是失败路径

很多 Agent demo 只展示成功路径：用户问一句，模型调工具，工具返回结果，模型总结。看起来很顺。

但日常使用里，失败路径更重要：

• 工具不存在怎么办？
• 参数缺字段怎么办？
• 工具超时怎么办？
• 结果为空怎么办？
• 调用到了高风险工具怎么办？
• 用户目标本身不清楚怎么办？

如果用 LangGraph 这类框架做编排，最好不要只画“成功后进入下一步”。更实用的是把失败分支也写出来：哪些错误可以自动重试，哪些错误要换工具，哪些错误必须停下来问人。

这也是 MCP 工具描述要认真写的原因。工具不只是给模型“能力”，也是给模型“限制”。一个好的工具说明应该告诉 Agent：什么时候用它，什么时候不要用它，失败时返回什么，哪些操作需要确认。

我会这样开始一个小项目

如果我要做一个最小的 LangGraph + MCP 工具型 Agent，不会一上来追求通用助手，而是选一个窄场景。

比如：给个人博客做发布前检查。

它可以有几个工具：

• 读取 Markdown frontmatter。
• 检查标题和 description 是否像真人写的。
• 检查来源链接是否存在。
• 运行 format、lint、build。
• 生成一份发布前报告。

这里面大多数工具都是低风险读操作或本地验证。真正涉及发布、提交、推送的动作，要单独放到确认节点，不能让 Agent 自己一路点到底。

这样的场景小，但很适合验证 Agent 架构：状态明确，工具明确，成功和失败都容易判断。等这个流程稳定了，再扩展到更复杂的浏览器搜索、内容改写或跨系统自动化。

结论：Agent 的工程味会越来越重

从 CSDN 最近几天的搜索结果看，LangGraph、MCP、Tool Calling、RAG、Multi-Agent 这些词正在被放到同一个工程问题里讨论：怎么让模型不只是回答，而是能可靠地做事。

我的判断是，下一阶段真正有用的文章不会只是解释概念，而是回答这些问题：

• 状态怎么保存？
• 工具怎么描述？
• 错误怎么恢复？
• 哪些动作必须人工确认？
• 怎么看见 Agent 中间做了什么？

LangGraph 和 MCP 正好分别落在两个关键位置：一个管流程，一个管连接。把它们放在一起时，别急着追求“多少行代码跑起来”，先把边界、失败路径和可观察性想清楚。

这会让 demo 少一点炫技，但会让真正能用的 Agent 多一点。

来源记录

• CSDN 搜索关键词：MCP AI Agent LangGraph Tool Calling
• CSDN 搜索结果线索：《100 行代码搞一个带 MCP 工具的 AI Agent：LangGraph + DeepSeek V4 实战》：https://blog.csdn.net/weixin_50937681/article/details/160959875
• CSDN 访问状态：搜索结果页可见标题、作者和日期；正文页返回 403 Forbidden / WAF，本文没有读取或复述原文内容。
• MCP 官方文档：https://modelcontextprotocol.io/docs/getting-started/intro
• LangGraph 官方文档：https://docs.langchain.com/oss/python/langgraph/overview