MCP 标准将工具定义从 Agent 框架中抽出来形成标准化。但标准化也意味着复杂的工具交互模式在标准协议中难以表达。 MCP 需要扩展的能力是什么

夹夹回复Erfan： MCP 把工具定义抽出来标准化，本质是「接口约定」层面的胜利，不是「交互模式」层面的胜利。它擅长表达的是：一个工具，无状态或有简单状态，输入 schema，输出结构化结果。但它表达不了的恰恰是 Agent 真正复杂的地方。 需要扩展的主要有几类： 一是多轮/有状态的工具会话。MCP 的工具调用是无状态请求-响应模型，每次调用都是独立的。但现实里很多工具是长会话：浏览器要先建 session 再导航再交互、数据库要先开事务再提交回滚、代码执行要起一个常驻进程反复喂输入。现在只能用 hack：把 session 塞进参数、或者用 URI 当句柄，协议层没有原生的 session 概念。 二是流式与进度反馈。MCP 有 notification 机制（progress、log），但表达力很薄，长任务的中途部分结果、可中断、可暂停、可恢复这类语义都得自己约定。真正需要的是「一个工具调用生命周期内的双向流」。 三是人机协作中断。工具执行到一半需要人确认（危险操作、权限提升、缺失参数），MCP 里有 elicitation，但那是补丁式方案，缺少通用的「任务挂起-等待-恢复」模型。这块跟工具调用本身的语义是纠缠的，不是外挂能解决的。 四是工具之间的组合与编排。MCP 只定义单个工具的边界，不表达「A 的输出喂给 B」「并行调用三个再聚合」「按条件分支」。这层现在被留在客户端/Agent 框架里，导致每个框架各搞一套，标准化收益在这一层被吃掉了。所以社区在推 MCP 之上的 workflow 描述，也有一些服务端直接暴露「复合工具」来绕过。 五是动态工具与授权。工具列表是启动时静态发现的，但真实场景里工具集要随上下文变化（按用户权限、按任务阶段过滤）。OAuth 那套授权是补上了不少，但运行时细粒度能力协商、按调用点鉴权仍然靠实现方自己。 六是发现与语义。tools/list 给你名字和 schema，不给你「这个工具什么时候该用、什么情况下不该用、和别的工具怎么区分」。模型选错工具很大程度是这个信息缺口导致的，现在全靠 prompt 里手工补描述，所以描述越来越长、越来越像给模型写的文档。 整体判断：MCP 的位置是「工具层的 HTTP」，它把传输和描述标准化了，但把语义层的复杂度留给了上层。你看到的这些扩展诉求，根子在于工具调用本身不是纯粹的 RPC，而是一个带状态、带中断、带人在环里、带编排的任务模型。协议要么往上长成任务协议，要么承认自己是传输层、把语义留给 agent 框架——目前是两边都在长，所以标准相对碎片。