Agents、Skills 还是 MCP？如何编排 AI 栈而不制造新瓶颈
讨论的重点不是'用哪一个'，而是如何把三个抽象层结合起来，在工程运营中确保安全、治理与规模化。
Fabiano Brito
CEO & Founder
每当 AI 生态出现新公告，工程与产品负责人就会面对同一个架构问题：“要自动化我们的流程，应该用 Agents、Skills 还是 Model Context Protocol（MCP）？“。成熟的回答不是选一个，而是把这三层都用起来——每一层承担明确不同的职责。
从零散 prompt 的混乱到分层架构
不久之前，市场处在两个极端：要么团队对所有事都用自主 agents（预算爆表），要么忽视抽象，只会粘贴超长指令。今天这些组件终于模块化地拼起来——每一层回答一个不同的问题。
📘 Skills
可复用的步骤化指令（清单、code review 范式），让 AI 用 你 的方式工作。
- 归属
- 团队仓库
- 边际成本
- ~零
- 风险
- 缺评审会漂移
🔌 MCP
开放协议，让模型访问外部数据，无需把凭证暴露在 prompt 里——身份验证封装在服务端。
- 归属
- 独立 MCP 服务
- 边际成本
- 低
- 风险
- Token 权限过大
🧠 Agents
编排者，在逻辑循环中思考，决定调用哪个 Skill、查询哪个 MCP 服务、何时把任务委派给另一个 agent。
- 归属
- Vertex AI / ADK
- 边际成本
- 高
- 风险
- 死循环 + 成本失控
落地的三条黄金法则
只有把这三条当作流水线的硬卡点（而不是建议），Skills、MCP 和 Agents 才能像生产级基础设施一样运转：
MCP 连接必须始终使用 scoped tokens。只读工单的服务不该有写权限；查询 CRM 的服务不该看见薪资。
任何凭证都不能写在 SKILL.md 里。Skills 描述步骤；身份验证封装在对应的 MCP 服务里。
当 agent 写代码时，CI/CD 流水线就是抗算法幻觉的最后一道防线。测试不绿，绝不合并。
编排中的风险与摩擦
如果一个 agent 传给另一个 agent 的内容缺乏可追溯性，软件供应链就会出现漏洞。把每一次 MCP 调用、每一次加载的 Skill、每一次 agent 之间的交接都记录下来——审计 AI 与审计财务并无二致。
安全地扩张：A-MAD 方法
A-MAD（AI-Managed Agile Development） 方法论缓解运营瓶颈。在我们部署在 Google Cloud 上的流水线里，流程使用集成于 Vertex AI 的 Agent 框架：Skills 编码客户的特殊性，工具集成走 MCP，QA 与开发 agent 在严格治理下对话。层层独立、责任清晰、成本可控。
你的流水线是被编排的，还是被临时拼出来的？
我们带来 A-MAD 框架，对你当前栈做诊断，并提供把 Skills、MCP 和 Agents 拆开的路径，无需推倒重来。