4 篇博文 含有标签「MCP」

很多人第一次使用 Claude Code 或 Codex 时，会把效果差异归结为“提示词写得好不好”。这当然重要，但只解释了很小一部分。

一个真正能持续工作的 AI Agent，不只是在读取一句 Prompt。它还会接收系统规则、项目规范、历史消息、代码与文档、Skill、MCP 工具描述、工具执行结果、长期记忆、子 Agent 汇总以及运行环境状态。随着任务推进，这些信息还会被检索、缓存、裁剪、压缩、持久化和重新装配。

因此，今天更准确的问题已经不是：

“我应该怎样写一句更神奇的提示词？”

而是：

“在 Agent 每一次决策前，应该让模型看到哪些信息，允许它调用哪些能力，怎样保留状态，又怎样证明任务真的完成？”

这就是从 **Prompt Engineering（提示词工程）**走向 **Context Engineering（上下文工程）**的关键变化。

本文基于截至 2026 年 9 月 4 日的 Claude 与 Codex 官方资料，建立一套不依赖具体产品界面的通用模型，并重点回答五个问题：

1. Prompt、Context、Cache、Memory、Skill、MCP 到底有什么区别？
2. Claude Code 与 Codex 如何组织项目上下文？
3. 一个 AI Agent 从接收任务到完成验证，内部经历了什么流程？
4. 多 Agent 为什么有时更强，又为什么经常更贵、更乱？
5. 怎样写一份真正适合 Agent 执行的任务提示？

过去的浏览器 Agent 想在网站上完成任务，通常需要截图、识别按钮、滚动页面、填写输入框，再猜测下一步该点哪里。它能工作，却像让一个只拿到监控画面的机器人操作控制台：页面布局一改、按钮被遮挡、文案稍有歧义，整条任务链就可能失败。

WebMCP 提出了另一种思路：网站主动把自身能力声明为结构化工具，由浏览器在页面和 Agent 之间完成发现、权限检查、调用与结果传递。

Agent 不再只看到“一个蓝色按钮”，而是能看到一份接近函数契约的描述：

{
  "name": "book_appointment",
  "description": "预约一个仍有空位的咨询时段。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string", "format": "date" },
      "slot": { "type": "string" }
    },
    "required": ["date", "slot"]
  }
}

这不是要消灭图形界面，而是让同一个 Web 应用同时拥有两种可用界面：

• 人类使用视觉 UI；
• Agent 使用工具名、自然语言描述和 JSON Schema；
• 两者共享同一标签页、登录状态、应用状态和可见结果。

这也是 OpenAI 发起 WebMCP Challenge 的核心命题：构建一个在人与 Agent 共同使用时会变得明显更好的 Web 应用。

2026 年 8 月 19 日，OpenAI 将 Codex 更清晰地定义为一个可供开发者构建产品的 开放 Agent Harness。这句话容易被误读成“Codex 模型开源了”，实际开放的是模型周围的运行时与集成面：会话、Agent Loop、工具执行、沙箱、审批、事件流、CLI、SDK 与 App Server。

用一句话概括：

模型决定下一步做什么，Harness 决定它能看到什么、可以怎样做、需要谁批准，以及整个过程如何被恢复和观察。

这篇文章会回答三个问题：

1. openai/codex 到底开放了什么，没开放什么；
2. 面对庞大的 Rust 工作区，应当怎样学习 Agent Harness 的原理；
3. 如何选择 codex exec、Codex SDK 或 App Server，构建自己的应用。

2026 年 7 月 28 日发布的 Model Context Protocol 最新规范 不是一次普通增量更新。它移除了协议级会话和初始化握手，把版本与能力协商移到每一个请求，用 MRTR 重构服务器向客户端索取信息的方式，并将长任务移出核心协议。

如果把早期 MCP 看成“为桌面 AI 应用连接本地工具的会话协议”，那么这次修订更像是“可穿过网关、负载均衡器和无状态计算平台的 Agent 基础设施协议”。