我原本以为 MCP 发展到 2026 年，主要矛盾会是“大家到底接不接这个协议”。现在看，这个阶段已经过去了。真正值得个人开发者关心的，不是再多接几个 MCP server，而是：当工具调用开始跨进程、跨服务、跨账号以后，状态放在哪里，权限怎么收口，失败怎么恢复。
这不是一个很性感的话题，但它决定了 MCP 能不能从演示项目变成可维护的生产组件。
我为什么还会继续关注 MCP
从公开资料看，MCP 的 2026 路线已经不再只围绕“让模型连接工具”。官方路线图把传输可扩展性、Agent 通信、治理成熟度和企业可用性放到了更靠前的位置；近期发布候选版本里也出现了 stateless core、Tasks、MCP Apps、授权加固和弃用策略这些关键词。我的判断是：MCP 正在从“插件协议”往“AI 应用运行时边界”移动。
对个人开发者来说，这个变化有两层价值。第一，你不用为每个 AI 客户端重复写一套工具接入层。第二，如果你做的是面向开发者的小工具，MCP 可能成为一个低成本分发接口。但这两个价值都建立在一个前提上：你的 server 不只是 demo，而是能处理状态、权限和异常。
stateless 听起来轻，实际是在把复杂度挪位置
很多人喜欢 stateless，因为它天然适合 HTTP、负载均衡和普通云基础设施。但工程上要诚实一点：无状态核心不等于系统没有状态，只是状态不再偷偷藏在长连接和内存 session 里。
一个现实的 MCP server，如果要调用 GitHub、Linear、Notion、数据库或者内部 API，至少会遇到这些状态：
- 用户授权状态；
- 工具调用的中间结果；
- 长任务的执行进度；
- 分页游标和缓存；
- 失败后是否可以重试；
- 模型上一次拿到的上下文是否仍然有效。
这些东西不会因为协议核心变得 stateless 就消失。它们会进入 Redis、Postgres、对象存储、队列，或者显式 state handle。个人开发者如果只是写一个本地脚本式 server，当然可以先不管。但只要你准备让别人登录使用，就必须回答“状态过期了怎么办”。
GET /mcp/context?cursor=ctx_01H... Authorization: Bearer user_token # 服务端需要判断： # 1. cursor 是否存在 # 2. cursor 是否属于当前用户 # 3. cursor 是否过期 # 4. cursor 对应的权限是否已经被撤销
这里最容易犯的错，是把 cursor 当成普通分页参数。对 Agent 来说，cursor 往往就是“下一步行动的依据”。如果这个依据被其他用户复用，或者在权限撤销后继续有效，问题就不是 bug，而是安全边界被打穿。
授权不是登录按钮，而是工具边界
MCP 授权文档已经把 OAuth 相关机制放到了更正式的位置。我的理解是，MCP server 越来越像一个受保护资源服务器，而不是“本地暴露几个函数”。这对个人开发者是好事，也是门槛。
好处是，一旦授权模型稳定，AI 客户端、工具 server、第三方服务之间可以形成更清楚的责任边界。门槛是，你不能再随便把一个万能 token 塞进环境变量，然后让模型随意调用。
# 不建议的方式 GITHUB_TOKEN=ghp_xxx npm run mcp-server # 更稳妥的方向 - 按用户授权 - 按工具声明 scope - 高风险操作二次确认 - token 可撤销、可轮换 - 审计每次 tool call
我现在更倾向于把 MCP tool 分成三类：只读工具、低风险写工具、高风险写工具。只读工具可以自动调用；低风险写工具可以在明确任务内调用；高风险写工具必须要求用户确认，比如删除数据、发邮件、合并 PR、改账单配置。
Tasks 的价值不是“跑更久”，而是让失败有地方停
长任务是 Agent 产品绕不开的问题。模型可以规划十几步，但后端任务不应该绑死在一次请求里。Tasks 这类机制真正有价值的地方，不是让任务跑得更久，而是让任务可以被查询、取消、恢复和审计。
如果我是个人开发者，会先实现一个非常保守的任务模型：
tasks - id - user_id - tool_name - input_hash - status: queued | running | waiting_for_approval | failed | done - result_ref - error_message - created_at - updated_at
这个表不复杂，但能解决很多“Agent 看起来很聪明，系统实际不可控”的问题。失败不是直接丢给模型猜，而是留在任务记录里。用户可以看到卡在哪里，开发者也能复盘到底是权限失败、外部 API 限流，还是模型传错参数。
个人开发者不要急着做平台，先做一个窄 server
MCP 容易诱惑人做“通用工具平台”。我的建议相反：个人开发者先做一个非常窄的 server，只服务一个高频场景。比如：
- 把自己产品的用户反馈暴露给 AI IDE；
- 把内部日志查询包装成只读工具；
- 把部署状态、错误聚合、工单系统连接起来；
- 给自己的 SaaS 做一个面向开发者的 MCP 接口。
先不要追求“工具很多”。工具越多，权限矩阵越复杂，模型越容易选错工具，用户也越难判断它到底做了什么。
我现在的判断
MCP 仍然值得关注，但关注点应该从“怎么接入”转到“怎么治理”。协议热度会继续波动，真正能留下来的，是那些把权限、状态、审计、失败恢复做扎实的工具 server。
如果我是个人开发者，我会用半天时间验证三件事：第一，能不能把一个只读业务 API 包成 MCP tool；第二，能不能为每次 tool call 记录用户、参数和结果；第三，能不能在 token 失效、接口限流、任务中断时给出可恢复状态。做不完这三件事，就先别把它包装成面向外部用户的产品。
资料依据：Model Context Protocol 官方 2026 Roadmap、MCP Authorization 文档、2026 Release Candidate 公开说明。这里还需要后续补充一组真实 server 的部署配置和调用日志，否则文章仍然偏工程判断。