生产级 AI Agent 构建指南

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

从 Demo 到生产环境

2024 年，我们在搭 Demo。

2025 年，我们在写 Coding Agent。

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

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

但当我们把 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 在明确知道预期时，会更快、更准确的调用工具。

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 或 沙箱），让它写一个脚本把工具组合在一起。

// 程序化工具调用（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 作者，不要再把 API 一对一映射到 MCP Server 上。要从 Agent 的角度重新设计。

三个核心原则：

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

MCP 2026 路线图

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

三大方向：

• 核心改进：Google 提出的无状态传输协议将使 MCP Server 更容易部署到 和 Cloud Run。 和 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 真正成为生产力放大器，而不是风险源。