Agent + MCP + Skills：从演示走向生产的完整架构 – 探索与交流 Know Hub 的无限可能

Agent、MCP 和 Skills 不是三个互相竞争的产品，而是三个不同层次。Agent 负责决策，Skill 负责方法，MCP 负责连接真实能力。把三者放对位置，系统才可能从演示走向生产。

一、完整架构

用户目标
   ↓
身份认证与会话
   ↓
Agent Runtime
├── Instructions：目标和边界
├── Skills：操作流程与专业知识
├── Guardrails：输入、输出和工具校验
├── Memory：任务状态与必要上下文
└── Tracing：决策、调用、耗时和成本
   ↓
Tool / MCP Gateway
├── 只读查询工具
├── 需要审批的写工具
└── 被禁止的高危能力
   ↓
数据库、文档、代码仓库、工单、部署平台

二、三者各自负责什么

Agent：理解目标，选择下一步，组合结果，决定继续还是结束。
Skill：提供稳定的执行顺序、检查点、输出模板和风险规则。
MCP：把外部数据与动作暴露为标准化工具和资源。

一个部署 Agent 可以激活“发布前检查 Skill”，再通过 MCP 读取构建状态、查询容器、提交部署请求。是否批准生产发布，则由权限策略和人工确认决定。

三、先做确定性工作流，再放开自主决策

生产系统不应该从“给 Agent 所有工具并让它自由发挥”开始。建议分四级上线：

只读建议：读取数据并生成建议，不执行写操作。
受控执行：每个写操作都需要用户批准。
有限自治：白名单内低风险动作可自动执行，高风险动作仍审批。
闭环自动化：仅在评测、监控、回滚和责任边界成熟后启用。

四、权限要按工具拆，不要按 Agent 一把梭

同一个 Agent 可以同时拥有不同风险等级的工具：

list_containers：只读，可自动调用。
restart_service：限定测试环境，可记录后执行。
deploy_production：必须显示版本、环境、变更摘要并人工批准。
delete_volume：默认不提供；紧急场景走独立人工流程。

权限控制必须由服务端强制执行，不能只在提示词里写“请勿删除”。提示词是行为引导，不是安全边界。

五、完成标准必须机器可验证

“已经部署好了”不是可靠结果。更好的完成定义包括：

目标版本与镜像摘要一致。
健康检查连续通过。
公开 URL 返回预期状态码。
最近日志没有新增错误。
核心读写路径通过冒烟测试。
回滚版本和执行入口已经记录。

六、可观测性要回答五个问题

用户提出了什么目标？
Agent 为什么选择这个工具？
工具实际接收了哪些脱敏参数？
调用结果、耗时和成本是多少？
最终结果是否通过验收？

不要把访问令牌、Cookie、完整用户数据写入 Trace。观测系统本身也必须有保留期限、访问控制和脱敏策略。

七、最小可执行项目：部署诊断 Agent

选择一个单一结果：定位“容器运行但页面打不开”。
制作诊断 Skill，固定状态、日志、容器内、宿主机、反代、域名的检查顺序。
通过 MCP 只暴露状态读取、日志读取和连通性测试。
禁止任意 Shell；所有参数使用结构化 Schema 和白名单。
用 20 个历史故障案例做离线评测。
先只输出诊断报告，稳定后再增加“经批准重启测试服务”。

八、上线验收表

[ ] 任务范围和拒绝边界明确
[ ] 工具使用最小权限和结构化参数
[ ] 写操作有审批，高危工具默认不存在
[ ] Skill 包含验证、异常和回滚步骤
[ ] MCP 服务验证身份、资源归属和授权范围
[ ] 设置最大轮次、超时、预算和并发限制
[ ] Trace 可复盘且敏感字段已脱敏
[ ] 真实评测集覆盖成功、失败和攻击输入
[ ] 人工接管入口真实可用
[ ] 每次版本升级都有回归测试

官方资料

系列入口：AI Agent 从聊天到执行 · MCP 一次讲清 · Agent Skills 实战