分类： MCP与Agent

AI Agent 工作流最容易被做成一个“什么都能干”的大框架。听起来很强，实际跑起来经常不稳定：目标不清楚、工具乱调、失败后继续编、关键步骤没人确认。

一个真正能用的 Agent，通常不是万能的，而是把一个具体流程做得很稳。

先选一个边界清楚的任务

适合做Agent	整理客服工单、生成周报、检查文章SEO、整理评论选题。
不适合一开始做	帮我运营整个网站、自动发布所有内容、自动处理付款。

一个资源站工作流例子

1. 读取社区评论和搜索词。
2. 归类用户问题：工具推荐、下载报错、提示词、教程。
3. 生成选题候选和关键词。
4. 检查已有文章是否覆盖。
5. 输出待写文章清单。
6. 由人确认后再生成草稿或更新内容。

工作流里必须有状态

• 已读取哪些资料。
• 调用过哪些工具。
• 当前结果是否通过检查。
• 哪些问题需要人工确认。

工具权限要分层

低风险	读取、查询、总结、生成草稿。
中风险	修改内容、上传素材、刷新缓存。
高风险	删除、付款、批量发布、改核心配置。

Agent 不是越自动越好，而是每一步都能解释、能检查、能接管。

先把一个小流程跑稳，再增加工具和分支。这样做出来的工作流没那么炫，但更像能长期用的系统。

把流程写成可检查状态

比如你要让 Agent 从 100 条社区评论里找选题，不要只写“帮我分析评论”。可以拆成：

1. 读取最近 100 条评论，标记来源和时间。
2. 聚类成 5 类问题：工具推荐、下载报错、提示词、教程、付费资源。
3. 对照已有文章，标出已经覆盖和没有覆盖的部分。
4. 输出 10 个选题候选，每个带核心关键词和用户原话。
5. 人工确认 3 个，再进入写作流程。

状态字段也要清楚：source_checked、needs_human_review、draft_ready、published。没有状态，Agent 很容易跑着跑着就不知道自己做到哪一步。

如果你的 Agent 需要连接外部工具，可以先补 MCP入门；配置服务端时再看 MCP Server配置。

配置 MCP Server 时，不要一开始就想着做一个完整平台。先跑通一个最小服务：客户端能连上，能看到一个工具，传入参数后能拿到返回结果。这个闭环通了，再谈鉴权、日志、部署和复杂工具。

最小验收标准

• 客户端能识别这个 Server。
• 工具名称和描述能正常显示。
• 参数 Schema 写得清楚，缺参数时能报错。
• 调用工具后能返回稳定 JSON 或文本结果。
• 日志里能看到谁在什么时候调用了什么工具。

一个最小工具长什么样

下面是示意写法，重点不是框架名字，而是工具名、参数和返回值要清楚。

from fastmcp import FastMCP

mcp = FastMCP("content-helper")

@mcp.tool
def get_article(id: int) -> dict:
    """Read one article by ID."""
    return {
        "id": id,
        "title": "示例文章",
        "status": "publish"
    }

if __name__ == "__main__":
    mcp.run()

工具名不要写成 do_action 这种模糊名字。模型看到 get_article、update_article_seo、upload_media_from_url，才更容易正确调用。

Schema要写给模型看

不清楚	do_action(data)
更清楚	update_article_title(id, title)
不清楚	run(task)
更清楚	refresh_article_cache(article_id)

参数名、类型、是否必填、错误返回，都要写清楚。MCP 工具不是给人猜的，是给模型调用的。

密钥不要写死

API Key、数据库密码、后台 Token 不要写在代码里。用环境变量或密钥管理，并限制每个工具能访问的范围。

GUAQI_MCP_TOKEN=xxxx
DATABASE_URL=postgres://...
CMS_API_BASE=https://example.com/api

读取文章、查询列表、获取配置，这类工具风险较低；删除内容、批量发布、付款、改生产配置，这类动作必须谨慎，最好加人工确认、日志和回滚方案。

先做只读工具，再做写入工具。能安全读到数据，是配置成功的第一步。

部署前再补这些东西

• 日志：记录工具名、参数摘要、调用结果和错误。
• 鉴权：不同用户或客户端能调用哪些工具。
• 限流：避免模型循环调用或误触发高成本接口。
• 错误处理：参数错、权限错、上游接口错时要返回可读信息。
• 回滚：写入内容、刷新缓存、批量更新前要能恢复。

如果你做的是内容网站，MCP 可以先从三类工具开始：读取文章、更新 SEO、刷新缓存。别一上来就做批量发布和删除。小闭环跑稳以后，再把它扩成真正能长期用的运营助手。

如果你还没分清 MCP 里的 Client、Server 和 Tool，可以先看 MCP入门；做成完整工作流时，可以继续看 AI Agent工作流。

很多人第一次看 MCP，直接被配置文件、Server、Client、Tool、Transport 这些词劝退。其实入门时不用先抄一大段配置，先理解它解决的问题就够了。

MCP，全称 Model Context Protocol。你可以把它理解成一种标准连接方式：让 AI 应用用统一方式连接外部工具、数据源和工作流。

先把三个角色分清

Client	你正在使用的 AI 应用，比如聊天工具、代码助手、桌面客户端。
Server	负责提供工具、资源和提示模板的一端。
Tool	AI 可以调用的具体动作，比如读取文件、查询文章、上传图片。
Resource	AI 可以读取的上下文资料，比如文件、文档、数据记录。

为什么不要一上来做写入

读取文章、查询列表、获取配置，这类工具风险较低；删除内容、批量发布、付款、改生产配置，这类动作风险高。MCP 让 AI 能做事，也意味着权限要设计清楚。

入门顺序：先只读，再写入；先一个工具，再一组流程。

一个内容站的入门例子

第一步	做 get_article，只允许读取文章。
第二步	做 update_article_seo，只允许更新标题、描述、关键词。
第三步	做 refresh_article_cache，更新后刷新前台缓存。
第四步	加日志、确认和失败处理。

什么时候你真的需要MCP

如果你只是偶尔让 AI 回答问题，未必需要 MCP。可如果你想让 AI 读取本地文件、查数据库、调用接口、管理内容、操作内部系统，MCP 就有价值。

新手可以从一个只读工具开始。确认客户端能看到工具、参数能传对、返回结果稳定，再考虑写入和自动化。这样慢一点，但不容易出事故。

理解 MCP 基础以后，可以继续看 MCP Server配置；如果你关心 Agent 工作流，可以读 AI Agent工作流。