乐于分享
好东西不私藏

AI Coding Agent:MCP、Skill 与上下文工程

AI Coding Agent:MCP、Skill 与上下文工程

AI Coding Agent 的三驾马车:MCP、Skill 与上下文工程

很多人第一次接触 AI Coding Agent,会把精力放在选模型上——用 Opus 还是 Sonnet,GPT-4o 还是 Claude。但工程实践告诉我们,模型选择对最终效果的影响,远没有工具设计、上下文管理和 Skill 系统来得大。

这篇文章聚焦三个关键词:AI Coding Agent、MCP、Skill。不讲概念,讲工程决策——为什么这样设计,不这样设计会出什么问题,以及数据说话。

AI Coding Agent 三驾马车:Agent Loop 是骨架,MCP 是肌肉,Skill 是神经系统

01

AI Coding Agent 到底在跑什么

Agent Loop 的核心逻辑抽象后不到 20 行:

const messages: MessageParam[] = [{ role: "user", content: userInput }];while(true) {  const response = await client.messages.create({    model: "claude-opus-4-6",    max_tokens: 8096,    tools: toolDefinitions,    messages,  });  if(response.stop_reason === "tool_use") {    const toolResults = await Promise.all(      response.content        .filter((b) => b.type === "tool_use")        .map(async (b) => ({          type: "tool_result" as const,          tool_use_id: b.id,          content: await executeTool(b.name, b.input),        }))    );    messages.push({ role: "assistant", content: response.content });    messages.push({ role: "user", content: toolResults });  } else {    return response.content.find((b) => b.type === "text")?.text ?? "";  }}

感知 → 决策 → 行动 → 反馈,四个阶段不断循环,直到模型返回纯文本为止。

这个循环本身相当稳定。从最小实现扩展到支持子 Agent、上下文压缩和 Skills 加载,主循环基本没有变化。新能力通常只通过三种方式接入:扩展工具集和 handler、调整系统提示结构、把状态外化到文件或数据库。

核心循环逻辑和工具调用逻辑要分开,不应该让循环体本身变成一个巨大的状态机。模型负责推理,外部系统负责状态和边界,一旦这个分工确定下来,核心循环就很少需要频繁调整了。

OpenAI 的 Codex 团队用这个模式做到了什么?3 个工程师 5 个月写了百万行代码,将近 1500 个 PR,是传统开发速度的 10 倍。速度背后不是模型有多强,而是几个工程决策做对了:约束编码化而非文档化、Agent 端到端自主完成任务、可观测性栈按任务临时创建。

02

工具设计的三代演进

MCP(Model Context Protocol)是 Anthropic 提出的工具通信标准协议,解决的是 Agent 和外部工具之间的接口问题。但协议本身只是基础,工具设计的质量才是决定 Agent 能不能用好工具的关键。

工具设计三代演进:从 API 封装到 ACI,再到 Advanced Tool Use

工具设计经历了三代

第一代,API 封装:每个 API Endpoint 对应一个工具,粒度过细。Agent 往往需要协调多个工具才能完成一个目标,比如更新一篇语雀文章,要先 get_post,再 update_content,再 update_title,三步才能做完一件事。

第二代,ACI(Agent-Computer Interface):工具应对应 Agent 的目标,而不是底层 API 操作。直接给一个 update_yuque_post(post_id, title, content_markdown),一次把目标动作说完整。

第三代,Advanced Tool Use:在工具设计之上,进一步优化工具的发现、调用和描述方式:

好工具和差工具的区别

差的工具设计:参数模糊,出错只返回字符串,Agent 不知道怎么修正。

// 差:参数模糊,错误不可修正const tool = {  name: "update_yuque_post",  input_schema: {    properties: {      post_id: { type: "string" },      content: { type: "string" },    },  },};// 出错时return"Error: update failed";

好的工具设计:参数描述直接约束格式,错误结构化给出修正建议:

const updateTool = betaZodTool({  name: "update_yuque_post",  description: "更新语雀文章内容,不适合创建新文章",  inputSchema: z.object({    post_id: z.string().describe("语雀文章 ID,纯数字字符串,如 '12345678'"),    title: z.string().optional().describe("文章标题,不改时可省略"),    content_markdown: z.string().describe("Markdown 格式正文"),  }),  run: async (input) => {    const post = await getPost(input.post_id);    if(!post) thrownew ToolError("文章 ID 不存在", {      error_code: "POST_NOT_FOUND",      suggestion: "请先调用 list_yuque_posts 获取有效的 post_id",    });    return await updatePost(input.post_id, input.title, input.content_markdown);  },});

调试 Agent 时应先检查工具定义,大多数工具选择错误的原因出在描述不准确,不在模型能力。

MCP 工具的 token 成本

仅 5 个 MCP 服务器就可能带来约 55,000 tokens 的工具定义开销,相当于在 200K 上下文里还没开始对话就用掉了近三成。工具一旦过多,模型对单个工具的注意力也会被稀释。

Cursor 做过一个 A/B 测试:把工具描述同步到文件夹,Agent 默认只看到工具名,需要时再查询具体定义,调用 MCP 工具的任务总 token 消耗减少了 46.9%。这个思路和 Skills 延迟加载是同一套逻辑。

03

Skill:上下文工程的核心模式

Skill 是上下文工程里非常有效的一种模式,核心思路是:系统提示只保留索引,完整知识按需加载。

const systemPrompt = `可用 Skills:- deploy: 部署到生产环境的完整流程- code-review: 代码审查检查清单- git-workflow: 分支策略和 PR 规范`;async function executeLoadSkill(name: string): Promise<string> {  return fs.readFile(`./skills/${name}.md`, "utf-8");}

为什么要按需加载

上下文分层管理的核心问题是:信息密度不对。偶尔用的东西每次都加载进来,稳定的规则和动态的状态混在一起,模型能看到的内容越来越多,但真正有用的部分越来越难被注意到。这类现象通常被叫作 Context Rot。

上下文分层管理:按信息的使用频率和稳定性分层,每层只放自己该放的东西

解决方式是按信息的使用频率和稳定性分层:

Skills 延迟加载还有一个隐藏好处:保护Prompt Caching 命中率。

LLM 推理时,如果当前请求的输入前缀和之前某次请求完全一致,这部分 KV 就不需要重新计算,直接从缓存读取。命中的前提是精确前缀匹配,任何一个 token 不同都会破坏匹配。

按需注入的 Skill 内容不破坏系统提示前缀,而是追加在稳定前缀之后。接了很多 MCP 工具的 Agent 如果工具集频繁变动,缓存命中就会不断失效。稳定的大系统提示,比频繁变动的小提示实际成本更低,因为写入成本只付一次,后续每次调用读取的折扣可以达到 90%。

Skill 描述符怎么写

左:反例对 Skill 路由准确率的影响;右:文件系统接口方案的 Token 节省效果

Skill 描述要足够短,避免常驻上下文持续涨 token,也要足够像路由条件而不是功能介绍。

printf("hello # 低效(约 45 tokens)description: |  This skill handles the complete deployment process to production.  It covers environment checks, rollback procedures, and post-deploy  verification. Use this before deploying any code to production.# 高效(约 9 tokens)description: Use when deploying to production or rolling back.world!");

更关键的是反例。没有反例时准确率从基准 73% 掉到 53%,加上反例后升到 85%,响应时间还降了 18.1%。反例不是可选项,是 Skill 描述能不能起作用的关键。

最直接的写法是 Use when / Don't use when 再补几条反例:

# git-workflowdescription: Use when creating branches, PRs, or following commit conventions.  Don't use when: just running git status/log, or when the task is about  code review content(use code-review skill instead).

系统提示里也要把调用规则写明确:每次回复前先扫描 available_skills,有明确匹配时再读取对应 SKILL.md,多个匹配时优先选最具体的那个,没有匹配就不读取,一次只加载一个。

Skills 和 MCP 的选择

Skills 和 MCP 在上下文成本上的特征并不相同。很多 MCP 会把完整结果直接返回给模型,更容易迅速吃掉上下文预算。CLI + 单句描述的 Skill 更接近模型熟悉的调用方式,在大多数可过滤、可拼接的数据读取任务里也更简洁。

当然 MCP 也有明确适用场景,例如 Playwright 这类需要维护状态的任务,或者需要实时数据的工具调用。

04

三者如何协作

AI Coding Agent、MCP 和 Skill 不是三个独立的概念,而是同一个工程问题的三个层面:

Agent Loop决定控制流——感知、决策、行动、反馈如何循环,状态如何外化,任务如何跨 session 续跑。

MCP 工具决定能力边界——Agent 能做什么,工具设计是否面向 Agent 目标,错误是否可修正,token 成本是否可控。

Skill系统决定上下文质量——哪些知识常驻,哪些按需加载,如何防止 Context Rot,如何保护缓存命中率。

三者的关系可以用一句话概括:Agent Loop是骨架,MCP是肌肉,Skill是神经系统。骨架决定能不能动,肌肉决定能做什么,神经系统决定做得准不准、稳不稳。

一个常见的反模式是:系统提示越来越长,工具越加越多,然后发现 Agent 开始选错工具、忽略规则、在第 20 轮对话后决策质量明显下滑。这不是模型的问题,是工程约束没立住。

修法很简单:约定留在系统提示,领域知识移到 Skills;合并重叠工具,明确命名空间;监控 token 占用,超阈值自动触发记忆整合。

05

一个可运行的最小架构

把上面的原则落到代码里,一个最小可运行的 AI Coding Agent 架构大概是这样:

classAgentLoop {  constructor(    private provider: LLMProvider,    private tools: ToolRegistry,      // MCP 工具注册表    private skills: SkillLoader,      // Skill 按需加载器    private memory: MemoryManager,    // 跨会话记忆  ) {}  asyncrun(userInput: string, session: Session){    // 1. 构建分层上下文    const systemPrompt = await this.buildLayeredContext(session);    // 2. 主循环    const messages = [{ role: "user", content: userInput }];    for (let i = 0; i < MAX_ITER; i++) {      const resp = await this.provider.chat(messages, this.tools.definitions());      if (resp.hasToolCalls) {        for (const call of resp.toolCalls) {          // 3. Skill 触发时按需加载          if (call.name === "load_skill") {            const skillContent = await this.skills.load(call.args.name);            messages.push(toolResult(call.id, skillContent));          } else {            const result = await this.tools.execute(call.name, call.args);            messages.push(toolResult(call.id, result));          }        }      } else {        // 4. 记忆整合(token 超阈值时触发)        await this.memory.maybeConsolidate(session, messages);        return resp.content;      }    }  }  privateasyncbuildLayeredContext(session: Session): Promise<string> {    return [      await readFile("SOUL.md"),           // 常驻层:身份和约束      await this.memory.load(session),      // 记忆层:跨会话事实      this.skills.buildIndex(),             // Skills 索引(描述符,不含全文)      buildRuntimeContext(session),         // 运行时:时间、渠道、用户信息    ].join("\n\n");  }}

这个架构的关键设计决策:

  • 系统提示按层构建,Skills 只注入索引,不注入全文

  • 工具注册表和 Skill 加载器分离,MCP 工具走 tools.execute,Skill 走 skills.load

  • 记忆整合在每轮结束后检查,不是在上下文满了才处理

  • 主循环不感知渠道(Telegram、CLI、IDE),渠道适配在外层

06

划重点

  1. Agent Loop 的核心循环很稳定,新能力通过工具扩展、提示结构调整和状态外化接入,不要让循环体本身变成状态机。

  2. MCP 工具设计要面向 Agent 目标,不是面向底层 API。参数描述直接约束格式,错误结构化给出修正建议,每个工具附带真实调用示例。

  3. 工具数量要克制。5 个 MCP 服务器约 55,000 tokens,动态工具发现可以把上下文保留率提升到 95%。

  4. Skill 系统的核心是延迟加载:系统提示只保留索引,完整知识触发时注入。Skill 描述符要写路由条件,不是功能介绍,反例是关键。

  5. 没有反例时 Skill 路由准确率从 73% 掉到 53%,加上反例后升到 85%,响应时间还降了 18.1%。

  6. 稳定的大系统提示比频繁变动的小提示实际成本更低,Prompt Caching 写入成本只付一次,后续折扣可达 90%。

  7. 调试 Agent 时先检查工具定义,再检查 Skill 描述,最后才怀疑模型能力。大多数工具选择错误出在描述不准确。

如果你在用 AI Coding Agent 遇到了工具选错、上下文膨胀或者 Skill 路由失准的问题,欢迎交流。

---END---

Prompt与Skill:AI时代的两种生存法则

TDD与SDD在 Vibe Coding 时代的融合实践

Harness框架应用老代码仓库改造

GitHub Copilot、Claude Code、Kiro这些AI编辑器帮你实现vibe coding

Agent Skills:AI 智能体的"技能插槽"如何重塑软件开发范式

相关学习资料