27. 接 MCP / 外部服务

先接只读服务

MCP 很适合扩展 Agent 能力。

但终局实战第一版，建议只接只读服务。

例如：

内部文档查询
只读数据库查询
项目资料索引

不要一开始接写操作。

接入前先验证

先在 DeerFlow 外部验证 MCP server：

能启动
工具列表正确
调用一个工具能返回结果
错误信息清楚

这一步能省很多排错时间。

接入配置

配置以官方 config.example.yaml 为准。

重点看：

server 名称
transport
command / args
env
认证方式

不要把密钥写进文档或仓库。

放进任务流

MCP 不应该替代所有搜索。

更稳的方式是：

公开搜索找背景
MCP 查询内部或特定资料
最终报告区分不同来源

这一篇你要记住

MCP 接入的价值是让 Agent 能访问外部系统。

但权限越大，风险越大。先只读，再扩展。

什么时候值得接 MCP

不是所有外部能力都要 MCP。

如果只是一次性脚本，用普通工具可能更简单。

MCP 更适合这些情况：

多个 Agent 都要用
工具需要独立部署
外部系统本来就有 MCP server
需要统一协议管理工具

接入后怎么降级

MCP server 可能不可用。

研究型 Agent 应该有降级路径：

MCP 可用：使用外部资料
MCP 不可用：只用公开搜索，并在报告里说明限制

这样任务不会因为一个外部服务挂掉就完全失败。

安全提醒

只读不等于无风险。

内部资料被读取后也可能进入报告，所以要确认哪些内容可以被输出。

实践：动手检查

为一个候选只读 MCP 服务写最小接入卡片：启动与工具验证方式、config.example.yaml 中需对照的配置项、允许输出的资料范围、服务不可用时的降级路径。先不扩大权限。

完成标准

• 目标工具确实是只读；
• command / args、env、认证需求都有出处；
• 报告能区分公开搜索与 MCP 来源；
• 降级方案明确为继续公开搜索并说明限制。

多走一步（可选）

实际停用该 MCP 服务跑一次小任务，检查降级报告是否仍能生成。