---
URL: "/zh-CN/blog/2026-05/AI-Agent.html"
LLMS_URL: "/zh-CN/blog/2026-05/AI-Agent.md"
lastUpdated: true
commentabled: true
recommended: true
title: "生产级 AI Agent 构建指南"
description: "MCP、CLI 与 Skills 的正确使用姿势"
date:

pageClass: "blog-page-class"
cover: "/covers/ai.svg"
---

---
lastUpdated: true
commentabled: true
recommended: true
title: 生产级 AI Agent 构建指南
description: MCP、CLI 与 Skills 的正确使用姿势
date: 2026-05-13 09:45:00 
pageClass: blog-page-class
cover: /covers/ai.svg
---

本文介绍了生产级 AI Agent 构建指南，利用 Skills 提供领域知识、MCP 提供安全集成、CLI 提供高效执行。

## 从 Demo 到生产环境 ##

2024 年，我们在搭 Demo。

2025 年，我们在写 Coding Agent。

2026 年，我们开始把那些具备通用知识能力的智能体投入实际应用中。

Anthropic 的 David Soria Parra 透露，*Model Context Protocol（MCP）*月下载量已达 1.1 亿次 —— 增长速度甚至超过当年的 React。

但当我们把 Agent 扩展到复杂企业工作流时，一个关键认知浮现了：连接性不是单一维度的。

如果有人告诉你，Computer Use、MCP 或 CLI 中有一个能解决所有连接问题，那他就是个骗子。顶级 Agent 不做选择，它们同时使用整个连接性协议栈。

这篇文章手把手带你掌握 2026 年的连接性协议栈：Skills、MCP 和 CLI。

## 理解三层连接性协议栈 ##

在写代码前，先搞清楚三个不同层级的 Agent 连接方式。

### Skills（领域知识） ###

可复用的过程化指令，以 Markdown 文件形式教会模型如何使用工具，跨客户端可移植，通常在 `.claude/skills/` 目录或远程仓库中加载。

### CLI / Computer Use（本地执行） ###

类 Unix 风格的连接方式。高度可组合，Token 效率极高（每次响应约 200 tokens），充分利用模型在 `git`、`gh`、`curl` 等工具上的预训练知识。安装方式是通过包管理器安装标准二进制文件。

### MCP（连接性技术） ###

集成协议层、语义丰富、平台无关以及企业级特性：OAuth、治理策略、审计跟踪。MCP Server 通过代码定义 tools、resources 和 prompts（如 `server.py` 或 `server.ts`），通过 JSON-RPC 2.0 over HTTP 或 SSE 通信。

## 用 MCP 执行任务 ##

当你需要丰富的语义、授权机制和平台无关性时，MCP 是最佳选择。它提供模式优先（schema-first）的确定性工具选择。

不过，这也有代价。朴素的实现会把所有工具 schema 一股脑加载到上下文中，返回的是完整的、带类型的 JSON 对象。程序解析友好，但 Token 开销不小。

给 Server 作者的建议：

> 始终使用描述性函数名、参数名，并给参数加上描述注释。LLM 在明确知道预期时，会更快、更准确的调用工具。

```python
from typing import Annotated
from datetime import date
from enum import Enum

class Category(str, Enum):
    TRAVEL = "travel"
    MEALS = "meals"
    OFFICE = "office"

def submit_expense(
    amount: Annotated[float, "The expense amount in USD"],
    date: Annotated[date, "Date of the expense in YYYY-MM-DD format"],
    category: Annotated[Category, "The expense category"]
) -> str:
    """Submits a new expense report for approval."""
    pass
```

## 用 CLI 执行任务 ##

当工具已经在模型的预训练数据中（比如 GitHub CLI 或 Git），CLI 的执行效率极高。模型可以用管道和重定向组合命令，并在出错的时候快速迭代。

与返回庞大的 JSON 不同，模型可以用 `jq` 精确过滤所需数据，返回更为紧凑的响应。

## 核心优化：渐进式发现 ##

这是 Agent 框架必须做的最重要优化。

不要把所有工具一次性加载到上下文窗口中，而是*延迟加载*，等模型实际需要时才加载。

通过提供 `tool_search` 能力，模型可以动态查找工具，这种模式可以将上下文使用量降低 5 倍。

Spring AI 的实现显示，在 28 个工具的场景下，OpenAI、Anthropic 和 Gemini 模型都能实现 34-64% 的 Token 削减。Cursor 的 A/B 测试表明，在使用 MCP 工具的会话中，总 Token 消耗减少了 46.9%。

## 进阶优化：程序化工具调用（Code Mode） ##

如果想让模型编排多个工具，不要强迫它做顺序工具调用 —— 每次调用都依赖推理延迟。

改用 Code Mode：给模型提供 REPL 环境（如 V8 isolate 或 Python 沙箱），让它写一个脚本把工具组合在一起。

```typescript
// 程序化工具调用（Code Mode）
// 模型只需写一次脚本，而非多次 LLM 轮次：
const issue = await mcp.call_tool('linear_get_issue', { id: 'ENG-5121' })
const prs = await mcp.call_tool('github_list_prs', { repo: 'frontend' })

// 使用结构化输出强制类型
const expectedType = z
  .object({
    title: z.string(),
    status: z.string(),
  })
  .passthrough()
const typedIssue = await extract('claude-haiku-4-5', expectedType, issue)
```

## 为 Agent 设计（而非为人类设计） ##

作为 Server 作者，不要再把 REST API 一对一映射到 MCP Server 上。要从 Agent 的角度重新设计。

三个核心原则：

- 为 Agent 设计工具 —— 要有清晰的意图，就像为人类设计界面一样。
- 拥抱 Code Mode —— 暴露执行环境（如 Cloudflare MCP），让模型编排复杂工作流。
- 交付 MCP App —— 利用 MCP 的丰富语义，直接交付 UI 资源（HTML + JS + CSS），从而让服务器在客户端自行渲染界面。

## MCP 2026 路线图 ##

MCP 生态系统正在快速演进，以应对企业级需求。

三大方向：

- 核心改进：Google 提出的无状态传输协议将使 MCP Server 更容易部署到 Kubernetes 和 Cloud Run。TypeScript 和 Python SDK v2.0 即将发布。

- 无处不在的集成：跨应用访问将支持通过公司身份提供商的单点登录（SSO）。Server 发现将通过 `.well-known/mcp-server-card/server.json` 自动完成。

- 边界拓展：Skills over MCP 将允许 Server 通过 `skills/list` 和 `skills/get` 端点，随工具一起交付领域知识。
需要根据具体情境和需求来决定是使用 MCP、CLI 还是 Skills，以下是整个流程的概要。

## 总结 ##

2026 年 Agent 连接性演进证明：没有银弹。MCP 和 CLI 之争是个伪命题，生产级 Agent 需要多层次的精细方法。

MCP 饱受批评的几点（Token 开销、认证缺口、Server 质量） —— 是真实但可解决的工程挑战，而非生存威胁。生态系统已经在自我修正：渐进式发现和 Code Mode 大幅降低了 Token 膨胀和延迟。

更重要的是，在企业环境中放弃 MCP 会引入更糟糕的问题：认证碎片化、零审计跟踪、供应商锁定。MCP 提供的"连接性技术"对于大规模治理和安全至关重要。

未来的 Agent 将无缝融合三种能力：Skills 的领域知识、MCP 的安全连接、CLI 的 Token 高效执行，好的 Agent 会利用全部能力。

> AI 编码工作流：迈向 2026 的实战指南

2025 年，AI 编码助手对大量开发者来说已经从“玩具”变成了“生产工具”。但是，要真正把它用好，并不是“丢给模型一个愿望就能出成品”，而是需要一套有章可循的工程化工作流。

本文介绍了经过验证的 LLM 编码工作流：如何计划、编码、测试与协作，把 LLM 当作一名强大的配对程序员，而不是全自动的“猜代码机器”。

## 先写清规格，再生成代码 ##

很多人用 LLM 写代码的常见误区是：一上来就让模型写一大坨代码，而不是先讲清楚要做什么。

正确的做法是：

- 把第一步完全用在“和 AI 一起梳理规格”上，而不是写实现；
- 让模型反问自己：逐步澄清需求、约束、边界条件和边缘场景；
- 最终产出一份 `spec.md`，里面包括：需求、架构决策、数据模型、依赖、测试策略等。

> 做一个“15 分钟瀑布开发”：在真正写代码前，用极短时间完成一个结构化规划过程，让后续编码变得顺滑。

有了这样的规格，后面再让 LLM 参与写代码，双方都清楚“到底要造什么东西” —— 这比模糊的“帮我写个 X 功能”效果好太多。

## 把工作拆成小块、迭代推进 ##

LLM 在处理*小而清晰的任务*时效果最好，在“一次性写完整个应用”时往往会失控。

正确的做法是：

- 把整体需求拆分成一系列小的步骤或 ticket；
- 每次只让模型完成一个步骤：
  - 例如：“现在按照计划里的 Step 1，实现这段逻辑”；
- 每个步骤完成后，先本地或在 CI 里验证，再进入下一步。

很多开发者都踩过这个坑：一次性让 LLM 生成整套应用，最后得到的结果就像“10 个人各写了一块、从来没对齐过”的代码，风格不一致、重复严重、缺乏整体结构。

*小步迭代 + 每步验收*，既更稳，也更容易在中途纠偏。

## 给足上下文与约束，让模型“有据可依” ##

LLM 不是读心术，它只擅长在给定上下文里做推理与补全。如果只给很少的信息，就要求它做复杂修改，通常会得到“听起来像是对的，但其实不太对”的答案。

更靠谱的做法是：

- 明确告诉模型：
  - 要修改/参考的具体文件或代码片段；
  - 相关模块的约束与不变量（不能破坏的前提）；
  - 项目里已有的实现示例（“照这个风格来”）；

- 对于冷门库、新 API，直接把 README 或官方文档贴进上下文；
- 在 prompt 里给出反例与禁区：哪些解法太慢、不可用，应该避免。

有些工具（如 gitingest、repo2txt 等）可以帮助把重要代码部分“打包成文本”，让模型一次性读入。原则很简单：

> 不要让模型在“信息严重不全”的情况下瞎猜。如果有个 bug 需要理解 4 个模块才能修，那就把这 4 个模块的关键部分都给它看。

## 有意识的选择合适的模型，并敢于“换一位搭档” ##

不同 LLM 有不同的“性格”和擅长领域：

- 有的在解释代码、写文档方面特别强；
- 有的在重构大代码库、更改 API 接口时更稳；
- 有的交互体验顺滑，很懂你的意图。

正确的做法是：

- 对于重要任务，不要死守一个模型；
- 当一个模型频繁“卡壳”或产出质量一般时，可以把同一个 prompt 复制到另一个模型里试试；
- 在条件允许时尽量使用最新一代的高质量模型，因为在复杂任务上的差距会被无限放大。

“多模型配合”的典型用法是：

- 用模型 A 生成代码；
- 再请模型 B 做审查：“帮我找找这段实现里可能的问题或可改进的地方”。

这种“AI 审 AI”的方式，在实践中确实能抓出一些单一模型容易忽略的细节问题。

## 把 AI 编码融入整个开发生命周期 ##

AI 不只是在“写代码那一下”有用，而是可以贯穿整个软件开发生命周期（SDLC）：

- 在命令行里用 AI Agent（如 Claude Code、Gemini CLI 等）直接对项目操作：读文件、改代码、跑测试、分步修复问题；
- 用云端 Agent（如 GitHub Copilot Agent 等），让它在云端克隆仓库、跑测试、开 PR；
- 在 IDE 里，让 Copilot 帮你：

  - 写样板代码；
  - 做批量重构；
  - 生成和完善测试用例；
  - 总结复杂模块的行为。

正确的做法是：

- 让 Agent 去执行具体任务（写代码、跑测试、提 PR）；
- 但自己始终作为“总指挥”：

  - 提供计划与上下文；
  - 审查每一个关键步骤；
  - 决定是否采纳修改。

## 保持“Human-in-the-loop”：验证、测试与审查一个都不能少 ##

无论模型看起来多自信，*责任都在你自己*。

正确的做法是：

- 把 LLM 当成一个特别聪明、但很容易犯错的初级工程师。

因此：

- 不要盲信任何一段 AI 生成的代码；
- 至少要做到：

  - 自己过一遍逻辑，理解每个关键分支；
  - 跑单元测试/集成测试，验证行为是否符合预期；
  - 对重要改动进行认真的 code review（可以同时用人和另一个模型来审）。

如果缺乏测试，Agent 也会被“蒙在鼓里”，很难分辨自己有没有破坏已有逻辑；相反，完备的测试集是 AI 的“安全网”。

## 频繁提交，善用版本控制当作“安全网” ##

当 AI 可以在很短时间内生成大量代码时，细致的版本控制习惯比以往任何时候都重要：

- 小步提交、频繁提交，把 git commit 当作“存档点”；
- 每完成一个小任务、通过一次测试，就做一笔干净的提交；
- 大胆尝试 AI 建议的重构，但一旦发现跑偏，就回滚到上一个稳定点。

这样做有几个现实好处：

- 出现奇怪问题时，可以通过 commit 历史快速定位是哪个改动引入的；
- 也方便把 git diff 贴给 LLM，让它基于差异做分析和修复建议；
- 对 AI 来说，一个结构清晰的提交历史本身就是极佳的上下文素材。

对于更复杂的场景，可以使用分支或 worktree，把不同功能或不同 Agent 的实验隔离开。这样即使某个方向失败，直接丢弃对应分支即可，不会污染主线。

## 用规则与示例“调教” AI 搭档 ##

你完全可以，也应该，把 AI 当作一位需要入职培训的新同事：

- 为它准备 CLAUDE.md、GEMINI.md 之类的“团队守则”文件：

  - 代码风格、缩进规则；
  - 不允许使用的 API 或模式；
  - 偏好的架构风格（函数式 / OOP 等）；

- 在每次会话开始时，把这些规则喂给模型；
- 在提示词中明确要求：

  - “不确定时先提问，不要编造”；
  - “修 bug 时用注释简要说明修改原因”。

在具体任务里，多给模型“这个仓库里已经有的好例子”：

- 先贴一段你认为写得很好的函数；
- 再说“请用类似风格实现另一个功能”。

LLM 非常擅长模式模仿，有了高质量示例，更容易输出风格一致、容易维护的代码。

## 拥抱测试与自动化，让 AI 在“护栏”里奔跑 ##

一个 AI 友好的开发环境，往往具备这些特征：

- 完整的 CI/CD 流水线；
- 自动化测试（单测、集成测试）；
- 严格的 lint / 格式检查；
- 可以随时部署到预发环境做验收。

在这样的环境里：

- 让 AI 写完代码后开 PR，由 CI 来跑测试；
- 把失败的测试输出、lint 报错复制给 AI，让它针对性修复；
- 结合现有 code review bot，再用 AI 去回应这些评论并生成新的改动建议。

本质上形成了 高频反馈闭环：

> AI 写代码 → 自动化检查发现问题 → 把结果喂回给 AI → AI 修复 → 你做最终判断。

你不再需要亲自做所有机械劳动，但仍然牢牢掌握“是否可以合并/上线”的决策权。

## 持续学习：AI 放大的是“已有的好习惯” ##

重要结论是：

- 对有扎实工程基本功的人来说，AI 会成倍放大生产力；
- 对缺乏基础的人来说，AI 可能放大的是混乱和幻觉。

当你：

- 已经习惯写规格文档、做设计评审；
- 已经依赖测试与 CI 来保证质量；
- 已经有良好的架构和 code review 文化；

那么把 LLM 引入工作流，往往会让这些实践更高效、更易落地。

相反，如果这些基础都没有，就急于把“写代码”外包给 AI，往往会陷入一种类似“达克效应”（Dunning–Kruger）的状态：

- 感觉自己交付了不少东西；
- 但系统的可维护性、可扩展性和质量经不起时间考验。

因此，与其担心 AI 会不会让你“退化”，不如把每一次与 AI 协作当成学习机会：

- 让它解释某段实现背后的思路；
- 让它列出不同技术方案的 trade-off；
- 通过 debug 它犯下的错误，加深自己对系统与语言细节的理解。

长远来看，“优秀开发者 + AI” 的组合远强于任何一方单独存在。

## 小结：AI 不是导演，而是被你指挥的超级助手 ##

> 这是“AI 增强的软件工程（AI-augmented engineering）”，而不是“AI 全自动的软件工程”。

所有传统软件工程的好习惯 —— 写规格、做设计评审、写测试、用版本控制、保持代码风格一致 —— 不仅依然重要，而且在 AI 参与后变得更加关键。

AI 能做的是：

- 极大减少样板代码和重复劳动；
- 帮助你更快探索方案与原型；
- 在自动化测试和工具的护栏内，高速迭代。

但最终：

- 你 仍然是对代码质量、架构和长期可维护性负责的人；
- 你 要决定何时采纳 AI 的建议、何时推翻重来；
- 你 要持续提升自己的工程判断力，让 AI 真正成为生产力放大器，而不是风险源。