我原本以为 MCP 发展到 2026 年，主要矛盾会是“大家到底接不接这个协议”。现在看，这个阶段已经过去了。真正值得个人开发者关心的，不是再多接几个 MCP server，而是：当工具调用开始跨进程、跨服务、跨账号以后，状态放在哪里，权限怎么收口，失败怎么恢复。 这不是一个很性感的话题，但它决定了 MCP 能不能从演示项目变成可维护的生产组件。 …
过去大家和 AI 交互，核心还是“问一句，回一段”。现在越来越多产品在往另一个方向走：不是让模型只回答你，而是让它去执行、去调用工具、去推进一个任务。这当然是个重要变化，但我对它的判断并不狂热。因为“执行”变成接口，不等于所有应用都该立刻变成 Agent 产品。为什么这是一个真实变化当工具调用、文件读取、网页搜索、远程服务和运行时开始被统一到同一条…
很多人看 Responses API，第一反应是“又多了几个内置工具”。但我现在越来越觉得，它真正有价值的地方不在功能表，而在于它把工具调用、上下文延续、多步推理放进了同一个回路里。这件事对做 Agent 的开发者很重要。因为过去最烦的不是调用某个工具本身，而是你得自己在应用层补一大堆胶水：保存中间状态、决定何时继续、把工具结果再塞回模型、处理多轮…
我最近看 A2A 相关资料时，最大的感受不是“多智能体时代来了”，而是另一种更朴素的判断：大家终于开始认真面对一个现实——当 Agent 变多之后，靠私有胶水代码把它们一个个串起来，会很快失控。 Google 在 2025 年公布 Agent2Agent Protocol，到了 2026 年又持续在开发者博客里谈 A2A 1.0、协议生态和与 A2…
去年很多人讨论 MCP，还停留在“终于有统一协议了”这个阶段。到了现在，我对它的感受已经变了：协议本身当然重要，但真正开始决定项目能不能落地的，已经不是 JSON-RPC 长什么样，而是授权怎么做、状态怎么保存、界面怎么呈现、服务器怎么治理。 这也是我为什么觉得 MCP 现在值得写深一点。因为它已经从“开发者社区里一个挺酷的协议”开始进入更现实的工…
我一开始以为 MCP 最大的问题是协议本身，后来发现不是。协议反而是这件事里最容易的一部分。真正麻烦的，是当你的工具越来越多、模型越来越会主动调用工具之后，谁来决定它能调用什么、在什么上下文里调用、出了问题怎么追。 这也是我现在看 MCP 的核心判断：它当然值得关注，但对开发者来说，真正要投入时间的不是“再接几个 server”，而是尽快把权限边界…
这两个月我越来越确定一件事：Agent 的 memory，正在从“锦上添花的功能点”变成一层真正的基础设施。很多人一提 memory，脑子里想到的还是“让机器人记住用户喜欢什么”。这当然算一种能力，但工程上更重要的，不是它会不会记住一句偏好，而是它能不能在多轮任务、跨会话协作、长周期执行里，维持一个可复用、可检索、可校正的上下文层。为什么现在这件事…
最近一波“龙虾系”产品很容易让人看花眼：OpenClaw、WorkBuddy、QClaw、EasyClaw，再加上阿里的悟空，看起来都在做“能替你干活的 AI Agent”，但它们其实并不处在同一个竞争层级。 如果你把它们当成五个完全平级的软件来比，大概率会越比越乱。因为这里面既有开源底座，也有面向个人的桌面代理产品，还有长在企业组织系统里的 AI…
很多开发者对 Agent 安全的理解，还停留在“别让模型乱说话”。这个理解已经明显落后了。真正麻烦的，不是模型说错一句话，而是它能执行命令、读不可信内容、调用外部工具、连接 MCP 服务之后，系统会出现什么级别的连锁风险。 GitHub 最近把 Agent 安全训练做成了一套 Secure Code Game，我觉得这件事比很多“安全白皮书”更值得…
2026 年如果你在看 Agent 相关资料，很容易产生一种熟悉的疲惫感：MCP、A2A、UCP、AP2、A2UI、AG-UI，缩写越来越多，讨论越来越热，但真正落到工程实践里，很多团队还是在重复写各种私有胶水层。 我对这件事的看法很直接：这些协议最值得关注的地方，不是“会不会只剩一个赢家”，而是它们开始逼开发者认真回答一个长期被糊弄过去的问题——…