8.0
热点
AI SCORE
编程提效2026-08-20 01:25
MCP + Plugins：连接工具到构建开发工作流
dev.to · AI#MCP#Agent#工作流
Editor brief · 编辑速览
AI 编程工具强大的关键不在于连接更多工具，而在于将工具以正确权限、正确上下文连接到正确工作流；MCP 是实现这一目标的标准连接层。
你的 AI 编程助手变得强大，不是因为你连接了更多工具。
变得强大，是因为这些工具被连接到正确的工作流上、拥有正确的权限、并且有足够的上下文来做出有用的决策。
这个区别很重要，因为 AI 正在从生成代码走向与代码仓库、数据库、文档、API、CI 系统以及其他开发基础设施进行交互。
这正是 MCP 和 Agent 插件真正有用武之地的地方。
但这里有个问题：开发者很容易把集成变成一份购物清单。
GitHub、数据库、浏览器、Slack、文档、又一个 MCP 服务器、又一个插件。
更多的连接看起来可能很酷，但实际上会让整个系统更难控制。
目标不应该是最大的连通性，而应该是有用的连通性。
Model Context Protocol（MCP）为 AI 应用与外部工具和数据的交互提供了一种标准化的方式。
一个 MCP 服务器可以暴露诸如代码仓库访问、文档检索、数据库操作、API 或其他开发工具之类的能力。
一个重要的区分是：
模型负责推理，工具负责执行操作。
AI 应用不需要把五个不同系统的信息复制到 prompt 中，而是可以通过定义的接口与这些系统进行交互。
这使得工具使用更加结构化和可复用。
但 MCP 本身并不能神奇地创建一个智能开发者 Agent。
围绕这些工具的工作流仍然至关重要。
MCP 和插件不应该被等同对待。
MCP 主要是用于将 AI 应用与各种能力连接起来的协议。
插件可以打包更广泛的能力或工作流，可能将技能、指令和基于 MCP 的工具组合成更容易分发和复用的东西。
思考一下这样的开发者任务：
「"调查为什么生产环境部署失败了。"」
这很少是一个单一工具的操作。
Agent 可能需要代码仓库信息、CI 状态、日志、最近的提交、变更的文件、文档和 issue 历史。
有用的能力来自于把这些片段组合成工作流。
这可能是最大的思维转变。
不要问：
「"有哪些 MCP 服务器可用？"」
而要问：
「"我要改进哪个开发者工作流？"」
例如：
CI 失败调查
GitHub → 失败的工作流 → 日志 → 最近的提交 → 变更的文件 → 项目上下文
数据库调查
数据库 → schema → 相关表 → 查询 → 结果分析
文档感知开发
代码仓库 → 官方文档 → API 参考 → 实现 → 测试
变更追溯
Git → issues → pull requests → CI → changelog → release
现在每个集成都有存在的理由。
「"为什么我最新的 CI 流水线失败了？"」
一个基础的 AI 工作流可能会让你粘贴错误信息。
一个已连接的工作流可以检查失败的运行、识别失败的 job、获取相关日志、检查最新的提交、审查变更的文件，并将失败与现有测试结构进行对比。
然后 Agent 可以解释可能的根本原因，并提出最小的安全修复方案。
如果需要修改，不应该仅仅因为它有代码仓库的访问权限就自动修改生产代码。
它应该提出修改方案、展示影响、运行适当的验证，并在操作会产生有意义的后果时请求批准。
自动化不等于无限制的自主权。
有一种常见的假设：给你的 Agent 越多工具，它就越好。
这不一定正确。
如果一个 Agent 可以访问 30 个工具，但某个特定任务只需要 3 个，那么剩余的能力就会增加决策复杂度并可能引入无关的上下文。
这还存在一个安全问题。
一个读取文档的工具与可以修改基础设施或执行破坏性数据库操作的工具有着本质区别。
因此生产系统应该：
一个成熟的开发者平台最终可能支持数十种集成。
开发者不应该在每个任务中手动管理所有这些集成。
相反，平台可以根据工作流激活能力。
例如：
调查 CI 问题 → 激活 Git、issue、CI 和文档相关的能力
调查数据库问题 → 激活数据库相关的能力
处理 pull request → 激活相关的 Git、CI 和文档能力
这创建了一个更清晰的架构：
意图 → 工作流 → 所需能力 → 上下文 → 操作 → 验证
这比以下方式有用得多：
用户 → 一个巨大的工具箱 → 希望 Agent 选对
在连接一个新的 MCP 服务器或插件之前，问自己：
不要问：
「"我的 AI Agent 可以访问这个吗？"」
更好的问题是：
「"对于这个工作流，在这个权限级别下，我的 AI Agent 应该访问这个吗？"」
MCP 和插件之所以有趣，是因为它们将 AI 开发系统从孤立的聊天界面中解放出来。
下一代开发者工具将越来越多地结合：
模型 + 上下文 + 工具 + 记忆 + 验证 + 人类控制
MCP 可以提供重要的连接层。
插件可以使能力更容易打包和复用。
但两者都不能自动创建一个可靠的 AI 开发者。
真正的工程难点在于围绕它们设计工作流。
连接更少的能力。
给它们明确的职责。
控制它们的权限。
验证它们的输出。
衡量它们是否真正减少了开发者的工作量。
真正的问题不再是 AI 能否使用你的工具。
如果你的 AI 编程助手明天可以访问你开发栈中的每一个工具，你会信任它自主使用哪项能力——而哪一项你仍然会要求它必须先请求许可？