MCP
定义
Model Context Protocol（MCP）是一个开放标准协议，旨在为 AI 模型提供安全、标准化的方式来访问外部数据源和工具。MCP 的核小理念是建⽴ AI 模型与外部世界之间的桥梁，让 AI 能够获取实时数据、执行复杂操作，从而突破传统 AI 应用的局限性。
MCP 协议定义了一套标准化的通信规范，包括消息格式、认证机制、错误处理、资源管理等核小组件。通过这套协议，AI 模型可以与各种外部服务进行安全、可靠的交互，包括数据库查询、API 调用、文件操作、实时数据获取等。从技术架构⻆度来看，MCP 采用了客户端-服务器模式，其中 AI 模型或 AI 应用作为客⼾端，外部数据源和工具作为服务端。协议基于 JSON-RPC 标准，⽀持 HTTP、WebSocket 等多种传输方式，确保了良好的兼容性和扩展性。
功能
案例：智能客服系统的开发，需要集成订单查询、库存检查、用户信息获取、⽀付处理等功能。
开发时间：从 6 个月缩短到 2 周
代码量：从 10 万行减少到 5 千行
维护成本：降低 80% 以上
扩展难度：从架构重设计变为配置添加
错误率：减少 90 %以上的集成错误
MCP之前的开发流程
传统的开发流程极其复杂：
- 开发团队需要为每个外部系统单独开发集成接⼝。订单系统可能使用 REST API，库存系统可能使用 GraphQL，用户系统可能使用 SOAP，⽀付系统⼜有自⼰的 SDK。每个系统都有不同的认证方式、数据格式、错误处理机制。
- AI 模型⽆法直接访问这些系统，需要开发大量的中间层代码。开发人员必须编写数据转换逻辑、错误处理代码、重试机制、缓存策略等。这些代码往往占据了整个项⽬ 70% 以上的工作量。
- 系统的维护和扩展极其困难。当外部系统升级或API变更时，需要修改大量的集成代码。添加新的数据源需要重新设计整个架构，开发周期⻓达数月。
- 安全性和可靠性难以保证。每个集成点都是潜在的安全⻛险，错误处理不一致导致系统稳定性差。开发团队需要投⼊大量精⼒处理各种边界情况和异常场景。
MCP之后的开发流程
有了MCP协议，同样的智能客服系统开发变得简单高效：
- 所有外部系统都通过标准的MCP协议暴露服务。订单系统、库存系统、用户系统、⽀付系统都实现了统一的 MCP 接⼝，提供标准化的数据访问和操作能⼒。
- AI 模型可以直接通过 MCP 协议访问这些服务。不需要编写复杂的集成代码，只需要配置 MCP 连接参数，AI 就能够自动发现和使用各种服务能⼒。
- 统的扩展变得极其简单。添加新的数据源只需要部署相应的 MCP 服务，AI 模型会自动识别和集成新的能⼒。整个过程可能只需要⼏小时而不是⼏个月。
- 安全性和可靠性得到了根本保障。MCP 协议内置了完整的安全机制、错误处理、重试策略等，开发人员不需要重复实现这些基础功能。
核心组件
MCP 服务是实现了MCP协议规范的服务端应用，它将特定的数据源、工具或能⼒封装成标准化的接⼝，供AI模型调用。MCP 服务本质上是一个协议适配器，它将各种异构的系统和资源转换为 AI 模型可以理解和使用的统一接⼝。
从架构⻆度来看，MCP服务通常包含以下核小组件：
- 协议处理层负责实现 MCP 协议的通信规范，包括消息解析、会话管理、错误处理等。这一层确保了与 AI 客户端的标准化通信。
- 能⼒抽象层将底层的具体功能抽象为标准化的能⼒接⼝。例如，将数据库查询抽象为”数据检索”能⼒，将API调用抽象为”服务调用”能⼒。
- 资源管理层负责管理底层资源的连接、缓存、⽣命周期等。这包括数据库连接池、API限流、缓存策略等。
- 安全控制层实现认证、授权、审计等安全功能，确保只有授权的AI客⼾端能够访问相应的资源和能⼒。
上述是开发者利用MCP服务可以实现的应用场景。
Agent
模型层面
模型本质
大模型的本质是基于深度学习技术的超大规模统计概率模型。从底层机制来看，它是一个复杂的概率预测引擎，核心任务是根据给定的上下文，在海量参数构建的高维向量空间中，计算并预测下一个词（Token）出现的概率分布。
通过在数以万亿计的互联网文本、书籍和代码上进行预训练，大模型利用转换器（Transformer）架构捕捉到了语言的深层结构、语义逻辑和人类知识的统计规律。从哲学和信息论的角度来看，大模型的进化过程实际上是对人类文明知识的一种极高效率的压缩与表征。当模型的参数规模和训练数据达到一定临界点时，它展现出了所谓的涌现能力，即在处理复杂任务时表现出类人的逻辑推理、多轮对话和跨领域创作能力。
简而言之，大模型不仅是代码和数据的堆叠，它是一面映射人类智慧的数字镜像，通过概率统计的方式实现了从数据存储到通用智能的范式转移。
如果再说的更简单一些，其实一个大语言模型，本质上就是你硬盘上的两个文件。
**第一个文件：**参数文件（parameters）。里面存的是模型训练完之后所有权重，就是那个神经网络学到的所有知识。以 Meta 发布的 Llama 2 70B 为例——700 亿个参数，每个参数占2个字节（float16），总共140GB。
**第二个文件：**运行代码（run file）。可以是 Python、C、或者任何编程语言写的。这段代码做的事情就是加载那些参数，跑一个神经网络的前向传播。
模型压缩
大模型训练本质上是人类文明知识一种高倍率有损压缩过程。以 Llama 2 70B 为例，其核心逻辑可归纳为以下几点：
-
极高的压缩率：通过海量算力（如数千块 GPU）和预训练过程，大模型能将约 10TB 的原始互联网文本压缩成仅 140GB 的参数文件，压缩比约为 100 倍。
-
统计学意义的概括：这种压缩不同于 ZIP 等无损压缩，它并不逐字记忆原文，而是通过统计规律捕捉数据的大致模样。这一特性完美解释了**幻觉（Hallucination）**的成因——即模型在丢失细节后，根据概率进行的逻辑脑补”。
-
核心现象的解释：
- Token 窗口：由于参数存储是压缩后的知识而非原始数据，模型处理特定任务时仍需将原件放入上下文窗口。
- 规模定律：参数规模越大，意味着存储知识的容器越大，压缩损失随之减小，模型能力因而增强。
-
行业门槛与价值：预训练过程极其昂贵（如顶级模型成本可达数亿美金），因此开源模型（如 Meta 的 Llama 系列）的意义在于为下游应用免去了高昂的初次压缩成本。
模型微调
大模型的进化核心在于从互联网文档生成器向通用型智能助手的华丽转身。
在预训练阶段，模型通过处理海量互联网文本获得了广博的知识储备，但此时的它仅具备续写文本的本能，往往会机械地模拟网页内容（如用问题回答问题），在实际应用中缺乏实用性。
为了突破这一局限，微调（Fine-tuning）技术应运而生。微调的本质并非改变底层训练算法，而是将训练数据源从杂乱的互联网文本替换为由人工精心编写、高质量的问答对。其核心逻辑在于通过约十万条级别的精选样本，让模型在保留预训练阶段习得的万亿级知识储备的基础上，学习如何像一个专业、有礼貌且具备工具属性的助手一样进行交流。
正如 Andrej Karpathy 所指出的，预训练负责知识的积累，而微调则专注于对齐（Alignment），即将模型的输出行为模式调整到符合人类预期和助手角色的轨道上。这种模式的转变在本质上与使用系统提示词（System Prompt）设定角色异曲同工，都是在通过改变行为模式而非注入新知识来提升模型的交互价值。
因此，尽管微调能显著改善对话体验，但由于其不涉及新知识的灌输，在面对需要极高准确度或实时信息的任务时，模型仍需依赖检索增强生成（RAG）技术来动态补充外部权威信息。
模型反馈
RLHF（基于人类反馈的强化学习）是大模型从能用跨越到好用的关键分水岭。如果说微调是教会模型模仿助手的说话格式，那么 RLHF 则是通过奖励模型将人类的情感、价值观和复杂偏好量化，引导大模型在复杂的语义边界中进行自我优化。
它本质上是人类意志对概率空间的二次雕琢，使得模型不仅能听懂指令，更能理解隐藏在文字背后的政治正确、道德底线与情感温度。
模型内核
在大模型的终极演进中，它正从单一的工具属性蜕变为数字世界的元内核，即一种全新的大模型操作系统。
在这种范式下，LLM 扮演着类似于中央处理器（CPU）的角色，负责核心的逻辑推理与任务调度；而 RAG（检索增强生成）与超长上下文技术则构成了其动态内存与外部持久化存储系统，解决了模型静态知识的局限性；工具调用（Tool Calling）与 API 联动则充当了输入输出设备的驱动程序，赋予了模型感知并干预现实物理世界的能力。
这种架构彻底颠覆了传统软件开发的底层逻辑：传统的指令式代码正在被高度抽象、具备语义理解力的自然语言（Prompt）所取代，复杂的预设程序被动态生成的、具备自适应能力的智能流（Workflow）所覆盖。这不仅是技术架构的迁移，更是交互权力的深层重构——计算机不再是冰冷地等待特定指令的机械盒子，而是进化为能够理解人类意图、自主协调数字化资源并闭环执行复杂任务的智能主体，成为了未来一切数字化生产力与交互行为的核心驱动引擎。
应用层面
什么是 Agent
简单来说，AI Agent（智能体）就是一个有大脑、有手脚、有记忆的数字员工。
如果说普通的大模型只是一个能聊天、写文章的对话框，那么 Agent 就是一个能自主帮办成事的行动者。它的核心逻辑由三部分组成：
- 大脑（思考与规划）：利用大模型的推理能力，把复杂的目标拆解成一步步具体的计划。
- 记忆（短期与长期）：不仅记得当下的对话，还能通过 RAG（检索增强生成）像翻阅文档一样调用海量知识。
- 手脚（工具调用）：不再只是动嘴皮子，而是能自主去查搜索、调代码、发邮件或操作软件。
本质区别在于： 传统大模型是你问我答，而 Agent 是给你目标，我去完成。它是大模型从实验室玩具走向现实生产力的终极形态。
任务拆解
任务分解是 Agent 展现主观能动性的第一步，它标志着大模型从被动的文本生成转向主动的逻辑构建。
深层次来看，这不仅是简单的步骤拆解，而是一种复杂的思维工程——模型需要将人类含糊的目标（Objective）转化为确定性的执行路径（Path）。
通过思维链（CoT）或思维树（ToT）等技术，Agent 能够在内部进行多轮模拟与推演，预判执行过程中可能出现的障碍，并具备在任务中途进行自我监控与实时纠偏的能力。这种从 Next Token 向 Next Step 的进化，使得模型能够处理长链路、非确定性的复杂任务，真正具备了解决现实问题的策略思考力。
工具调用
如果说大模型是缸中之脑，那么工具调用（Tool Use）就是它伸向物理世界的数字化肢体，实现了从语义空间到 API 世界的精准闭环。
深度思考这一模块可以发现，工具调用本质上是模型在处理文本规律与遵循工业标准之间找到的平衡点。Agent 不再仅仅是输出一段关于如何发送邮件的文字，而是通过理解 API 文档、构造标准化参数，将高维的语义意图精确降维成确定性的代码或请求。
这种能力让 Agent 能够调动搜索、绘图、计算或自动化脚本，从而在处理垂直行业任务时，将大模型的创造力与传统软件的稳定性结合起来，实现了智能驱动、结果导向的数字化协作新范式。
能力实现
能力实现的最终闭环在于将长短期记忆、规划能力与外部工具融为一体，构建出一种具备自适应进化特征的数字生命。与传统自动化软件预设的 If-Then 逻辑不同，Agent 的能力实现是动态生成的，它能够根据环境反馈（环境感知）实时调整行为路径。
这种能力的落地，意味着生产力中心正在从人操作工具向人管理智能体转移。当 Agent 能够自主反思任务结果、通过 RAG 积累行业经验并实现任务闭环时，它就不再是一个辅助插件，而是一个具备职能属性的数字员工。它不仅改变了交付的结果，更重塑了人类处理信息的深度与广度，成为未来一切智能数字化交互的核心入口。
执行模式
ReAct 模式
ReAct：思考-行动交替的动态规划执行。
这种模式下智能体每一步都是先推理，再行动的模式。智能体循环执行：先思考当前状态与目标，生成下一步的想法（Thought，比如调用哪个工具）；根据想法执行操作（Action，通常是调用工具）；获得操作反馈并纳入下一轮思考（Observation），如此循环直到任务完成。
这种边思考、边行动的交替循环，使模型能够一步步探索任务，不断校正方向。
Plan-and-Execute 模式
Plan-and-Execute：先规划后调整。
Plan-and-Execute模式要求智能体在行动之前，先生成一个较完整的计划。也就是将任务拆解成子任务清单，然后逐一执行。
- 规划阶段（Planning）：分析任务目标，将其拆分为更小的步骤，形成一个有序的执行计划。规划可以由LLM根据任务要求输出一个步骤列表（Step 1-N），也可以结合工具或模板约束来确保计划的结构更完整。
- 执行阶段（Execution）：按照计划顺序逐个执行各个步骤，并处理每步的结果。在执行过程中，智能体可以根据实际执行情况动态调整计划（Refine），比如某一步如果结果不如预期，则可以修改后续步骤或重新规划。
模式的实现可以借助工作流自行实现，部分框架也会提供封装的工具。
长任务运行
内容引入
之前 Anthropic 分享一篇文章为：Effective harnesses for long-running agents，翻译下标题也就是适用于长期运行代理的有效工具。
核心挑战
随着 AI 代理能力的提升，开发者越来越多地要求他们承担需要数小时甚至数天工作的复杂任务。然而，让 Agent 在多个上下文窗口中保持一致进展仍是一个悬而未决的问题。
长期运行的 Agent 的核心挑战是他们必须在离散的会话中工作，而每次新会话开始时都不记得之前发生的事情。想象一个由轮班工程师组成的软件项目，每个新工程师到岗时都不记得上一班发生了什么。由于上下文窗口有限，且大多数复杂项目无法在单一窗口内完成，Agent 需要一种方式来弥合编码会话之间的间隙。
我们的目标是了解，对于这类通常需要人类团队耗时数月才能完成的项目，我们究竟能把智能体驱动编码的前沿推进多远。
存在局限
如今的 Agent 在执行专注的小任务时表现不错，但在复杂项目上却显得缓慢。自然而然的下一步，是并行运行多个 Agent，但要搞清楚如何协调它们却并不容易。
我们最初的直觉是，事先规划会过于僵化。推进一个大型项目的路径往往并不明确，合理的工作拆分在一开始也并不清晰。于是我们从动态协调入手，让 Agent 根据其他 Agent 此刻正在做的事情来决定自己的下一步。
这也是我们在传统的软件开发和当前的 AI Coding 时代说要去追随的方向，期望 Agent 可以完全像软件工程中实现，像实际业务开发场景中的 Team 一样，去把控整个项目的流程及发展。
探索尝试
我们最初的方法是让所有 Agent 具有同等地位，并通过一个共享文件自行协同。每个 Agent 会检查其他 Agent 在做什么、认领一个任务并更新自己的状态。为防止两个 Agent 抢占同一项任务，我们使用了锁机制。
这一方案在一些有趣的方面失败了：
- Agent 会持有锁太久，或者干脆忘记释放锁。即使锁机制正常工作，它也会成为瓶颈。二十个 Agent 的速度会下降到相当于两三个 Agent 的有效吞吐量，大部分时间都花在等待上。
- Agent 系统非常脆弱，Agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁，或者在完全没有获取锁的情况下更新协调文件。
我们尝试用乐观并发控制来替代锁。Agent 可以自由读取状态，但如果自上次读取后状态已经发生变化，则写入会失败。这种方式更简单、也更健壮，但更深层的问题依然存在。
在没有层级结构的情况下，Agent 变得非常规避风险。它们会回避困难任务，转而做一些小而安全的修改。没有任何一个 Agent 承担起解决难题或端到端实现的责任。结果就是工作长时间在空转，却没有实质性进展。
解决方案
规划执行
我们的下一个尝试是将不同角色拆分开来。不再使用每个 Agent 都什么都做的扁平结构，而是搭建了一条职责清晰的流水线。
- 规划者（Planners） 持续探索代码库并创建任务。他们可以针对特定区域派生子规划者，使规划过程本身也可以并行且递归地展开。
- 执行者（Workers） 领取任务并专注于把任务完成到底。他们不会与其他执行者协调，也不关心整体大局，只是全力处理自己被分配的任务，完成后再提交变更。
在每个周期结束时，会有一个评审 Agent 判断是否继续，然后下一轮迭代会从干净的初始状态重新开始。这样基本解决了我们的协同问题，并且让我们可以扩展到非常大的项目，而不会让任何单个 Agent 陷入视野过于狭窄的状态。
多级记忆架构
在长程任务中，Agent 面临的最大挑战并非计算能力的不足，而是信息的遗忘与碎片化。为了模拟人类工程师在大型项目中的思维状态，我们需要构建一套冷热分离的记忆分层系统：
- 热记忆（感知层）： 利用当前主流模型（如 GPT-5.2）不断扩大的上下文窗口（Context Window），存储当前正在处理的代码文件、实时的编译错误以及最近三次的决策逻辑。这保证了 Agent 在执行具体子任务时具备极高的“瞬时专注力”。
- 冷记忆（知识库层）： 引入基于知识图谱（Knowledge Graph）增强的 RAG 系统。不同于简单的向量检索，冷记忆会存储项目的全局架构、编码规范及历史决策记录。当 Agent 进入新模块时，系统会自动挂载相关的架构知识，防止其做出与全局设计冲突的修改。
- 状态检查点（持久化层）： 引入类似于 Git 的快照回滚机制。长任务每达成一个阶段性目标（如通过单元测试），系统自动记录当前的环境状态。一旦后续执行发生逻辑坍塌或陷入死循环，Agent 可以直接从上一个健康检查点恢复，而不是盲目地在错误的路径上继续消耗 Token。
自动化验证层
随着运行时间的拉长，Agent 极易产生累积性误差，即所谓的幻觉漂移——最初的一个微小误解，可能在数小时后演变成对核心代码的毁灭性破坏。因此，验证驱动必须成为长任务 Agent 的核心底座：
- 测试驱动开发（TDD for Agents）： 在执行者（Worker）开始编写逻辑代码之前，强制其先根据规划者（Planner）的要求编写单元测试。只有当代码在隔离沙箱中通过了所有自建测试及既有回归测试时，才允许进入代码评审环节。
- 静态分析监考官： 集成外部静态分析工具（如 Linter、类型检查器、复杂度监测工具）。这些工具不依赖大模型的概率推断，而是提供确定性的反馈。如果代码不符合项目的类型规范或复杂度超标，任务将被强制打回，从而在源头上杜绝了低质量代码的堆积。
- 评审反馈循环： 在每个周期结束时，由专门的评审 Agent 负责挑刺。它不参与代码编写，而是站在审计者的角度评估：本次修改是否解决了原问题？是否引入了新的隐患？这种角色隔离机制能有效打破 Agent 的自证偏见。
资源调度与模型路由
运行长达数天的 AI 代理任务，其 Token 消耗和计算成本是开发者必须面对的现实问题。模型路由策略是实现大规模工程落地的经济基础：
- 任务复杂度匹配： 并不是所有任务都需要顶级的 GPT-5.2 或 Opus 4.5。对于简单的文档生成、模板代码填充或琐碎的 Bug 修复，系统应自动路由给响应速度更快、成本更低的轻量级模型。只有在涉及底层重构、算法优化或多模块冲突协调时，才激活高推理能力的顶级模型。
- 算力动态分配： 在规划阶段，系统分配更多算力用于模拟多种路径的风险评估；在执行阶段，则通过并行化降低周转时间。通过这种重规划、轻执行的算力分配模式，可以显著提升系统的整体吞吐量，使二十个 Agent 协同不再因为竞争锁而变成两三个 Agent 的效率。
- 经济性熔断： 建立基于成本的健康监测机制。如果某个子任务在多次尝试后仍未取得进展，或者 Token 消耗异常激增，系统将触发熔断，转而寻求人类专家的干预。
这种人机协作的最后防线，确保了系统在长程运行中的安全可控。
思考收获
在运行时间极长的任务中，模型选择至关重要。我们发现，GPT-5.2 系列在长时间自主工作方面要优秀得多：更能遵循指令、保持专注、避免偏离，并且在实现上更加精确和完整。
Opus 4.5 往往会更早结束、在方便的时候走捷径，更快地把控制权交还给用户。不同模型在不同角色上各有所长。即便 GPT-5.1-codex 是专门为编码训练的，GPT-5.2 依然是更好的规划者。现在我们会针对每个角色选择最适合的模型，而不是依赖单一通用模型。
**许多改进来自减法而不是加法。**一开始我们为质量控制和冲突解决设计了一个集成者角色，但后来发现，它制造的瓶颈多于解决的问题。各个 Worker 本身就已经有能力处理彼此之间的冲突。
| 维度 | 关键实践 |
|---|---|
| 组织架构 | 弃用扁平化，采用“规划者-执行者-评审者”等级制。 |
| 一致性控制 | 严禁使用全局锁，采用乐观锁或独立分支并行开发。 |
| 质量保证 | 强制 TDD，所有 Worker 必须交付通过测试的代码。 |
| 模型选择 | 推理选 GPT-5.2，执行选 GPT-5.1-Codex，验证选轻量级模型。 |
| 鲁棒性 | 必须具备状态快照与任务重试逻辑。 |
最好的系统往往比你想的更简单。起初我们尝试借鉴分布式计算和组织设计中的系统模型，但并不是所有这些方法都适用于 Agent。合适的结构化程度其实介于两端之间。结构太少，Agent 会互相冲突、重复劳动、不断偏离；结构太多，则会让系统变得脆弱。
系统中有相当大一部分行为，很大程度上取决于我们如何为这些 Agent 设计提示。要让它们良好协作、避免异常行为，并在长时间内保持专注，我们做了大量实验。运行框架和模型本身固然重要，但提示词更重要。