AI Agent 爆发前夜：从 MCP 到智能协作，下一代应用的技术栈全景
2025年3月，Manus的邀请码在二手交易平台被炒到上千元。那时围观者把注意力放在“通用Agent”的演示视频上。同一时期，另一条线也在推进：Anthropic在2024年11月开源了MCP协议，2025年4月Google发布A2A协议。到2026年初，主流应用框架基本上都把MCP当默认接口，“Agent调用工具”这件事从各写各的，变成了一个标准动作。
1. 爆发不是突然发生的：几个能核验的节点
爆发之前有铺垫。列几个关键节点：
- 2024年11月，Anthropic开源MCP（Model Context Protocol），把“模型怎么安全地调用外部工具和数据”定义成一套公开协议。
- 2025年2月，OpenAI发布Deep Research，用户给一个研究主题，Agent会自动搜网页、读文档、整理报告，执行时长达到分钟级。
- 2025年3月，Manus出圈。它验证了一件事：Agent可以把多步骤任务拆给不同工具，并在浏览器里操作完成。虽然当时的完成率还不稳定，但产品形态足够直观。
- 2025年4月，Google发布A2A（Agent2Agent）协议，目标是让不同厂商的Agent可以互相发现、通信、交接任务。
- 2025年下半年，几家头部模型厂商把上下文窗口推到百万级，加上函数调用（function calling）的稳定，Agent才敢处理“多工具、多步骤”的真实任务。
这个“重构”有个直接结果：以前每个Agent框架都自己定义工具调用格式，写一次Agent，换框架就要重接一次。MCP出现后，工具层被标准化了。
2. MCP解决“模型连工具”，A2A解决“Agent连Agent”
MCP的分工可以这样理解：模型是电脑，工具是USB设备，MCP就是USB-C接口。Host是客户端的宿主程序（比如Claude Desktop、IDE），Client负责在Host里管理连接，Server把具体工具（查订单、搜文档、操作数据库）包成一个可被模型按名字调用的函数。
一个极简的MCP server（用Python的FastMCP库）长这样：
from fastmcp import FastMCP
mcp = FastMCP('order-tool')
@mcp.tool()
def get_order_status(order_id: str) -> str:
# 这里改成实际业务系统的查询逻辑
return f'order {order_id}: shipped'
if __name__ == '__main__':
mcp.run(transport='stdio')
这段代码跑起来后，一个支持MCP的客户端就能通过自然语言“查一下订单888的状态”去调用它。关键是：这个工具一次接入，LangChain能用，Claude能用，后续换框架也能用。
MCP解决的是“Agent和工具之间”的通信。A2A解决的是“Agent和Agent之间”的通信。真实业务里，一个报价Agent算完价格，要把结果交给合同Agent去生成文件、再交给审批Agent走流程。A2A定义了agent card（描述自己能干什么）、task（一次任务的启停和状态）、message（消息格式）。如果MCP像USB-C，A2A更像“邮件协议+工作流接口”。
实战中的分工：
- 和数据库、外部API、文件系统打交道：用MCP server包装，按照读操作/写操作分开暴露。
- 跨系统、跨Agent的协作：用A2A定义能力发现和任务交接。
- 两者不冲突，通常A2A内部的单个Agent自己也通过MCP调用工具。
3. 三个框架选型：LangChain、Semantic Kernel、百度千帆
到2026年，Agent框架不再是新东西，选型反而回到老问题：团队技术栈、部署环境、运维方式。
| 维度 | LangChain | Semantic Kernel | 百度千帆AgentBuilder |
|---|---|---|---|
| 开发方 | LangChain AI | 微软 | 百度智能云 |
| 主要语言 | Python / JS | Python / .NET(C#) / Java | 图形化编排 + API |
| 开源情况 | MIT开源 | MIT开源 | 云服务，非开源 |
| 生态 | 社区案例多，网上能搜到大量踩坑记录 | 微软技术栈对接方便，企业治理功能完整 | 国内合规、中文场景处理有优势 |
| 适用 | 快速原型、复杂编排、需要灵活自定义的团队 | 微软系企业、.NET团队、要长期运维的内部系统 | 百度云生态、需要低代码交付、国内部署 |
| 计费 | 框架免费，LangSmith云服务有免费额度 | 框架免费，Azure相关服务单独计费 | 控制台有免费额度，超出按token计费 |
4. 真实能落地的三个场景
4.1 编程：让Agent直接改仓库
场景：接手一个没人维护的Python服务，要新增一个退款查询接口。按老方法，先读半小时代码，再改路由、写SQL、补文档。用Claude Code这类工具（2025年2月发布）的操作路径是：把仓库路径交给它，说明要新增的接口，再给一条约束“只允许修改payment和order相关文件”。
Agent会自动搜索路由注册位置、读建表语句、实现接口并尝试运行测试。它会给出改动文件列表，这时候人工检查的重点不是代码风格，而是它有没有顺手改了其他模块——我发现它偶尔会把不相关的import也“帮忙”整理一下。所以实际工作流是：Agent写代码，人负责review diff。
4.2 客服：先接只读，再加写操作
场景：一个客服团队每天要处理大量重复咨询，查订单、查物流、改地址。如果一开始就让Agent直接操作工单系统，风控关过不去。
落地的正确顺序：
- 把高频问答（退换货规则、运费政策）放到RAG知识库，Agent先回答“信息型”问题。
- 把订单查询、物流查询做成MCP server，只暴露只读接口。
- 涉及改地址、退款这类写操作，Agent只能填好表单，由人工确认后提交。
- 每周抽检回答质量和转人工率。
4.3 经营分析：让Agent按语义层查数
场景：销售总监问“华东区2月销售额环比”，但报表系统里数据散在订单表、退款表、区域表，口径还特别多。Agent不能自己去猜“销售额”的定义，否则今天和财务口径对不上。
做法是先建一个语义层：把“销售额”映射为“线上支付成功订单金额，不含退款”，把“华东区”映射为区域维度表的对应值，把“环比”映射成日期维度计算规则。Agent的任务是：解析意图，在语义层选指标和维度，生成SQL，返回图表。
这一步的关键在业务口径：把口径从人脑子里搬到代码里，Agent才不会自由发挥。口径不沉淀，Agent越灵活，出错越隐蔽。
5. 落地路线图：五个边界控制
模型能力只是一半，工程边界的控制决定最终效果。
- 规划：让Agent一次只负责一个大阶段。长任务拆成步骤列表，每完成一步汇报，避免它在第3步跑偏时，前两步已经造成了不可逆修改。
- 记忆：不是所有对话都要存。只有“用户明确表达的偏好”和“任务产生的关键结果”才写入向量库或KV存储，并设置过期策略。对话原文保留在审计日志里。
- 工具调用：工具数量超过10个时，模型选错工具的概率会明显上升。工具名用动词，描述里写清楚参数、返回值和错误场景，能返回结构化JSON就不要返回大段文本。
- 安全管控：在Agent与业务系统之间加一层网关。网关只放行白名单API，写操作默认拦下，所有调用全量记日志。Agent权限遵循最小化原则，不用管理员账号跑。
- 成本：Agent任务的token消耗通常是单轮对话的几十倍。控制办法是缓存重复查询、先用小模型做意图路由、限制工具失败后的重试次数。
明天可以动手的第一步
别从大规划开始，从一个小工具开始。任意选一个“规则清楚、不需要决策”的查询动作（查订单状态、查磁盘占用、查会议排期），用FastMCP写出一个server，然后在Claude Desktop或Cherry Studio里加载，用自然语言问一遍。确认单个工具可靠后，再考虑接第二个、加审计、加审批。
一个工具接得稳，比十个工具接得全重要。
免责声明：文中提到的产品、公司和协议均来自公开信息，示例代码仅用于说明技术原理，实际部署前请以对应官方文档的最新版本为准。