【智能体开发新范式】一文掌握MCP，构建你的“AI工具链”知识体系！

关注

原创最新推荐文章于 2026-03-28 03:44:33 发布 639 阅读 AI 写同款· GEO 优化 ›

AI Agent新范式：FastGPT+MCP协议实现工具增强型智能体构建核心价值 MCP协议：统一AI模型与外部系统交互标准，支持OpenAI等主流厂商 FastGPT升级：v4.9.6+版本支持MCP服务提供与工具调用，实现外部能力扩展生态整合：通过mcp-proxy聚合开源MCP组件，构建AI应用生态闭环协议兼容性：支持SSE实时通信与多协议（stdio/sse/http）灵活扩展：通过配置文件动态接入新服务（如添加GitHub API）错误隔离：工具级异常处理与工作流容错设计阅读详情

随着模型能力不断增强，AI Agent 正在从“单轮对话助手”向“能够连续运行数小时甚至数天的自主系统”进化。然而，工程实践一再证明：让一个 Agent 在长时任务中持续、稳定地推进，远比想象困难。上下文窗口有限、会话之间没有记忆、反复返工、误判进度等问题，会让一个复杂项目在数轮执行后彻底失控。

就在昨天，Anthropic 发布了一套非常重要的工程方案，专门针对这些挑战而设计：基于“Initializer Agent + Coding Agent”的双 Agent 架构。
它的意义在于，它不是通过更大的模型、更长的上下文来对抗问题，而是通过一种工程化的工作流设计，确保 Agent 即使在“失忆”的多窗口条件下，也能像人类工程师一样一步步推进任务。

一、为什么单 Agent 架构无法胜任长时任务？

要理解双 Agent 架构的价值，必须先理解单 Agent 为什么会失败。

一个长时任务，例如构建一个完整的 web 应用，往往涉及几十到数百个功能、多个模块、持续的调试与验证。而当前的模型虽然强大，但每一轮仍然必须在有限的上下文中工作。这意味着，每一次执行都是一次“记忆重置”。模型需要在短时间内重新理解项目、评估状态，并决定下一步行动。

在这种情况下，单 Agent 容易出现两类典型问题：

第一类问题是试图“一口气完成所有事情”。模型看到用户需求后，会选择实施一个非常激进的策略：直接开始大规模编码，直到上下文耗尽为止。但这种策略的后果是，它只能写出“半截代码”，不仅未完成、也未记录、没有测试，下一轮 Agent 接手时完全无法判断当前项目进展，从而花大量时间摸索现场。
第二类问题则刚好相反：模型在看到部分成果后，误以为项目已经完成。由于缺乏清晰的目标列表与结构化任务定义，模型可能在看到一些 UI、一些 API 或一些响应后，得出“功能齐全”的误解，进而直接终止任务。这种“过早宣布完成”的情况非常常见。

也就是说，Anthropic认为，当前AI Agent无法长时间稳定运行的核心问题不在模型能力，而在缺乏一种能够跨上下文继承任务逻辑的结构化工作方式。

为此，Anthropic提出了双Agent架构。

二、双 Agent 架构：让 Agent 真正“像一个工程团队工作”

Anthropic 的解决方案非常工程化：不是让一个 Agent 解决所有事情，而是将长时任务拆分为两种角色——一个负责奠基，一个负责迭代。

这个方法和此前大家逆向Claude Code非常相似：

其核心思想：

Claude Code 的核心逻辑建立在一个单一的主循环之上。所有历史消息都被维护在一个扁平的消息列表中，而不是层层嵌套的多代理对话树。

具体这方面也可以参考此前DataLearnerAI的博客：Claude Code 的独特体验：Claude Code 为什么这么好用？从设计细节看下一代 LLM Agent 的范式

这次是Anthropic官方解密这个双Agent价格，即Initializer Agent和Coding Agent。

Initializer Agent：一次性奠定整个项目的工程基础

Initializer Agent 的职责集中在第一次运行，它更像是一位“首席架构师”。
它不会立即进入编码，而是根据用户给出的高层需求，将项目转换为一个可长期维护的工程结构。

这包括三项关键内容：

第一，生成一个“可操作的需求体系”。
Initializer 不会让模型自己猜哪些功能是必要的，而是将用户需求分解为一份详尽的 JSON 结构的功能清单。每项功能都有描述、步骤和验收条件，并全部标记为“未完成”。这使得 Coding Agent 在未来的所有会话中都能明确自己的目标，不会误判进度，也不会跳过必要环节。

第二，创建状态记录机制。
Initializer 会写入一个 progress 文件，记录项目结构、重要说明和之后用于交接的上下文。它同时建立 git 仓库，让每个迭代都能被提交、恢复和追踪。状态记录机制使得未来的 Agent 不必猜测，而是能够基于事实继续推进工作。

第三，提供一个标准化的启动脚本。
Initializer 还会生成一个 init.sh，用于启动开发服务器并进行基础测试。这使得后续所有会话都能迅速验证当前环境是否健康，从而降低“接手时发现项目已坏”的风险。

这样，一个干净、结构化且可持续继承的工程现场就奠定完成了。

Coding Agent：每一轮只做一件事，但把它做好

在完成初始化之后，项目的推进交给 Coding Agent。它的工作方式不再是“尽可能写更多代码”，而是“每一轮修改都要增量、可靠、可验证”。

Coding Agent 的启动流程非常像工程师上班的第一小时：
它会先检查当前目录结构，阅读 git 记录，查看 progress 文件，运行 init.sh，并进行一次基本的端到端测试。它不是为了完成新功能，而是为了确认“现场是否正常”，避免在未知状态下开始工作。

接下来，Coding Agent 会从功能清单中选择一个未完成的功能，阅读它的验收步骤，然后进入真正的实现。
关键在于：

它每一轮只做一件事情。

且在编码完成后，它必须自行完成端到端测试，例如使用 Puppeteer 驱动浏览器，像真正用户那样操作应用：打开页面、点击按钮、输入内容、观察结果。
功能通过后，它会将 "passes": true 写回 JSON 清单，并提交一次 git commit，同时更新 progress 文件，让下一轮 Agent 一眼就能理解变化。

这种节奏虽然缓慢，但极其可靠。
它将“无人监督的长时任务”转换为“每轮可验证的开发迭代”，从而大幅提升任务的稳定性。

三、双 Agent 如何解决长时任务中的结构性难题？

这套方案之所以有效，是因为它从工程结构层面解决了单 Agent 无法克服的问题。

在这里，我们是稍微总结一下：

难题	单 Agent 的表现	双 Agent 的行为
缺乏任务目标体系	容易误判已完成	功能清单定义完整需求空间
无法继承状态	每轮重头理解项目	progress + git 确保上下文可读
容易写到一半崩溃	爆上下文，留下烂尾	Coding Agent 每轮只做一项功能
缺乏真实测试	代码可运行≠功能完整	自动化 e2e 测试确保真实性能
环境可能已损坏	下一轮无法判断为何损坏	init.sh 的统一自检流程使问题可见

本质上，这是第一次有人把“软件工程的工作流”正式编码进 Agent 架构中。

四、未来的方向：从双 Agent 到“Agent 工程团队”

Anthropic 的实现，是一个重要基点，但远没有结束。
他们提到，下一步可能会着手将这些角色进一步拆分为：

测试 Agent
QA Agent
代码清理 Agent
文档 Agent
性能 Agent

从而形成真正意义上的“Agent 工程团队”。
这种趋势值得高度关注，因为它可能改写未来的软件开发方式。

这次的Anthropic推出的方案不是模型能力的提升，而是工程方法论的突破。结合此前Claude Skills等，Anthropic正在试图用工程方法来解决实际问题。不过也有人批评说，Anthropic无非是把实际过程遇到的问题写出来，甚至是之前用MCP创造问题，现在再来解决。

不过，可能本来AI Agent的发展就不是一帆风顺，会有各种问题，所以即使是这样的前沿企业可能也有很多坑要来回踩。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述