企业官网建设流程全解析

1. 从一堆热词说起：这四个概念到底在解决什么问题

最近半年，只要你在做 AI 应用相关的事情，几乎不可能绕开四个词：MCP、Skill、Agent、Prompt。我自己的浏览器收藏夹里，关于这几个词的教程、源码、讨论帖已经堆了上百条，从“mcp是什么”这种入门问题，到“codex无法找到mcp”“invalid prompt”这类具体报错，几乎覆盖了从零到踩坑的全过程。很多人第一次接触这四个概念时，会觉得它们是一层套一层的玄学名词，其实不是。它们各自解决的是完全不同层面的问题，只是恰好被同一个技术浪潮推到了台前。

先把最朴素的定义摆出来，后面所有内容都围绕这四条线展开：

• Prompt：你给模型的输入指令，是人和模型之间最直接的沟通方式。
• Agent：一个能自己决定“下一步做什么”的执行体，它会把任务拆解、调用工具、观察结果、再决定下一步。
• Skill：封装好的、可复用的能力单元，通常对应一个具体动作或一类知识，Agent 可以按需加载。
• MCP：一套让模型或 Agent 与外部工具、数据源对接的协议层，解决的是“怎么把能力接进来”的标准化问题。

这四个东西不是替代关系，而是分层协作关系。我习惯用一个类比：Prompt 是你对助理说的话，Agent 是那个助理本人，Skill 是助理掌握的某项技能（比如做表格、查资料），MCP 则是助理桌上的电话线和插座，让它能真正联系到外部世界。缺了任何一层，整套系统要么跑不起来，要么跑得很别扭。

这篇文章适合三类人看：第一类是刚接触 AI 应用开发、被这些名词绕晕的初学者；第二类是已经在写 Prompt、搭 Agent，但总觉得“接工具很麻烦”的实践者；第三类是想搞清楚这套体系边界在哪、该怎么选型的技术负责人。我会尽量把每个概念拆到能直接上手操作的程度，同时把我在实际项目里踩过的坑、验证过的参数和配置都摊开讲。

提示：本文涉及的所有工具、协议、配置均为通用技术实践，不涉及任何特定平台或敏感场景，读者可放心参考。

2. Prompt：最容易被低估，也最容易翻车的一层

2.1 Prompt 的本质不是“提问”，而是“约束”

很多人把 Prompt 理解成“问模型一个问题”，这是最大的误解。真正在生产环境里跑的 Prompt，核心作用不是提问，而是约束输出空间。你告诉模型“做什么”只是第一步，更重要的是告诉它“不做什么”“按什么格式做”“遇到不确定时怎么办”。

我举个实际例子。早期我做数据清洗时，写过一个很朴素的 Prompt：“请把下面这段文本里的日期提取出来。”结果模型有时候返回“2024年3月”，有时候返回“2024-03”，有时候干脆返回一句“这段文本包含一个日期”。后来我改成：

从以下文本中提取所有日期，按 YYYY-MM-DD 格式输出。 如果日期不完整（如只有年月），缺失部分用 00 补齐。 如果没有任何日期，输出空字符串。 只输出结果，不要解释。 文本：{{input}}

同样的模型，输出稳定性立刻上了一个台阶。这就是 Prompt 工程的核心：把模糊的自然语言需求，翻译成模型能稳定执行的规则。

2.2 Prompt 的四个关键参数，你必须心里有数

在实际调用模型时，除了 Prompt 文本本身，还有几个参数直接决定输出质量。我整理了一张表，这些是我在多个项目里反复验证过的经验值：

这里重点说temperature。很多人调不好 Prompt，其实是 temperature 设错了。你要模型做分类、抽取、判断，temperature 必须压到接近 0，否则它会“发挥”。你要模型写文案、起名字，temperature 太低反而死板。我见过一个团队做意图识别，temperature 设了 0.8，结果同一个问题每次分类都不一样，排查了两天才发现是参数问题。

2.3 那些让人抓狂的 Prompt 报错，到底怎么回事

热词里出现了“invalid prompt: your prompt was flagged as potentially violating our usage p”和“prompt闪退”，这两个我都遇到过。前者通常是触发了内容安全策略，后者多半是输入长度超限或格式异常。

invalid prompt 的常见原因：

• 输入里包含了被判定为敏感或违规的内容片段
• Prompt 模板拼接时变量为空，导致语义异常
• 特殊字符、控制字符混入，破坏了请求结构

prompt 闪退的常见原因：

• 输入 token 数超过模型上下文窗口
• 流式输出时前端处理不当
• 并发请求过高导致连接被重置

我的处理习惯是：在 Prompt 进入模型之前，先做一层预处理校验——检查长度、过滤控制字符、对变量做非空判断。这一步看起来简单，但能挡掉八成以上的低级报错。

2.4 Prompt 工程不是写作文，是写规格书

我特别想纠正一个观念：Prompt 写得好不好，不取决于它读起来多优美，而取决于它是否像一份规格书。好的 Prompt 应该包含：角色定义、任务描述、输入说明、输出格式、边界条件、异常处理。这六项齐了，模型的表现基本可控。

角色：你是一名数据标注员。 任务：判断以下评论的情感倾向。 输入：一段中文评论。 输出：只输出 正面 / 负面 / 中性 三个词之一。 边界：如果评论无明确情感，输出 中性。 异常：如果输入为空，输出 未知。 评论：{{comment}}

这种结构化的写法，比“请帮我分析一下这段话的情感”要稳定得多。你可以把它理解成：Prompt 是给模型看的接口文档。

3. Agent：从“一问一答”到“自己干活”

3.1 Agent 和普通调用的本质区别

普通调用模型，是“你问一句，它答一句”，流程完全由你控制。Agent 不一样，它有一个循环：思考、行动、观察、再思考。这个循环让它能处理那些“一步说不清”的任务。

比如你让普通模型“帮我查一下北京今天天气并写一句出行建议”，它只能基于训练数据瞎猜。但 Agent 可以：先调用天气查询工具拿到真实数据，再根据数据生成建议。这个“先调工具、再生成”的过程，就是 Agent 的核心价值。

热词里有个“harness和agent区别”，这个问题问得很好。Harness 通常指测试或评估框架，它负责给 Agent 提供输入、记录输出、打分；Agent 是被测或被运行的对象本身。两者是“测试台”和“被测物”的关系，不要混为一谈。

3.2 Agent 的四种常见架构，选错了会很痛苦

我在实际项目里用过至少四种 Agent 架构，各有适用场景：

我的建议是：新手从 ReAct 入手，它最直观，调试也最容易。等你发现 ReAct 在复杂任务上开始“绕圈”时，再考虑 Plan-and-Execute。Multi-Agent 看起来很酷，但如果没有明确的角色边界，很容易变成“一群 Agent 互相甩锅”。

3.3 Agent 的安全边界，比能力更重要

热词里“agent安全”出现频率很高，这不是杞人忧天。Agent 能调用工具、能执行动作，意味着它一旦出错，后果比“答错一句话”严重得多。

我给自己定的几条铁律：

• 工具权限最小化：Agent 能调用的工具，只给完成任务必需的那些
• 危险操作二次确认：删除、写入、发送类操作，必须有人工确认环节
• 执行日志全记录：每一步思考、每一次工具调用都要留痕，方便回溯
• 设置最大循环次数：防止 Agent 陷入死循环烧 token

注意：Agent 的“自主性”和“可控性”是一对矛盾。我的经验是，宁可牺牲一点自主性，也要保证可控性，尤其是在生产环境。

3.4 从零搭一个最小 Agent 的关键步骤

很多人问“ai agent搭建”从哪开始。我给一个最小可运行的思路，不依赖任何特定框架：

1. 定义工具集：先想清楚 Agent 需要哪些能力，每个能力写成一个函数
2. 写系统 Prompt：告诉 Agent 它的角色、可用工具、输出格式
3. 实现循环：调用模型 → 解析输出 → 如果是工具调用就执行 → 把结果塞回上下文 → 再调用模型
4. 设置终止条件：任务完成、达到最大轮次、或出现错误时退出
5. 加日志：每一步都打印出来，方便调试

这个循环看起来简单，但真正跑起来你会发现，解析模型输出是最容易出问题的一环。模型有时候返回 JSON，有时候返回带解释的文字，有时候格式还差一点。我的做法是在 Prompt 里强制要求 JSON 输出，并在解析失败时做一次重试。

4. Skill：把能力封装成“即插即用”的模块

4.1 Skill 到底封装了什么

Skill 这个词在不同语境下含义不太一样。在 Agent 体系里，Skill 通常指一个封装好的、可复用的能力单元，它可能是一段 Prompt 模板、一个工具调用逻辑、或者一套处理流程。热词里的“skill编码193”“skill编码247”“skill脚本”“codex skill”说的都是这类东西。

我理解 Skill 的核心价值是解耦。没有 Skill 的时候，所有逻辑都堆在 Agent 的主循环里，越写越乱。有了 Skill，你可以把“查天气”“做表格”“写摘要”各自封装起来，Agent 需要哪个就加载哪个。

4.2 Skill 的三种封装粒度

根据我的实践，Skill 可以按三种粒度来封装：

• 原子级：一个具体动作，比如“调用某个 API 获取数据”
• 组合级：多个原子动作的组合，比如“获取数据+清洗+格式化”
• 领域级：一整套领域知识，比如“GIS 空间分析”相关的所有操作

粒度选择的原则是：高内聚、低耦合。一个 Skill 只做一件事，做完整。如果发现一个 Skill 里塞了五六个不相关的功能，那就是粒度太粗了。

4.3 Skill 的注册与加载机制

Skill 要能被 Agent 用起来，需要一个注册和加载机制。常见做法是维护一个 Skill 清单，每个 Skill 包含：名称、描述、参数定义、执行入口。Agent 在规划时，先看清单里有哪些 Skill 可用，再决定调用哪个。

{ "name": "extract_dates", "description": "从文本中提取所有日期，返回标准格式", "parameters": { "text": "待处理的文本" }, "entry": "skills.extract_dates.run" }

这个清单的作用，相当于给 Agent 一本“能力目录”。描述写得越清楚，Agent 选错 Skill 的概率就越低。我踩过的坑是：描述写得太简略，Agent 经常把“提取日期”和“提取时间”搞混。后来我把描述写详细，加上示例，准确率明显提升。

4.4 去 AI 味的 Skill：一个被低估的实用技巧

热词里有个“去ai味的skill”，这个很有意思。所谓“AI 味”，通常指模型输出里那些过于工整、过于客套、缺乏个性的表达。要消除它，可以在 Skill 层面做文章：封装一个“风格改写”Skill，专门把 AI 生成的文本改得更自然。

我的做法是：先让模型生成初稿，再用一个独立的 Skill 做“去 AI 味”处理，Prompt 里明确要求“去掉‘总之’‘综上所述’这类套话，加入口语化表达，允许不完美的句式”。实测下来，效果比在生成阶段直接要求要好，因为两个阶段的目标更聚焦。

5. MCP：让工具接入不再“各接各的”

5.1 MCP 解决的是标准化问题

在没有 MCP 之前，每接一个工具，就要写一套适配代码。接十个工具，就有十套不同的对接逻辑，维护成本极高。MCP 的出现，本质上是把“工具接入”这件事标准化了。它定义了一套协议，工具方按协议暴露能力，Agent 方按协议调用能力，双方不用再为每个工具单独写胶水代码。

热词里“mcp是什么”问得最多，我的回答是：MCP 是模型和外部世界之间的标准接口层。你可以把它类比成 USB 接口——以前每个设备都有自己的插头，现在统一成 USB，插上就能用。

5.2 MCP 的核心概念：Server 和 Client

MCP 体系里有两个关键角色：

• MCP Server：暴露能力的一方，比如一个数据库、一个文件系统、一个 API 服务
• MCP Client：调用能力的一方，通常是 Agent 或模型运行时

Server 负责把能力描述清楚（有哪些工具、每个工具要什么参数），Client 负责按描述去调用。这个分工让能力的提供方和使用方彻底解耦。

5.3 接入 MCP 的实操流程

以接入一个文件系统 MCP Server 为例，大致流程是：

1. 获取 Server：找到或自己实现一个符合 MCP 协议的 Server
2. 配置连接：在 Client 端配置 Server 的启动命令或地址
3. 能力发现：Client 启动后，向 Server 请求可用工具列表
4. 调用测试：选一个工具做调用测试，确认链路通畅
5. 集成到 Agent：把 MCP 工具纳入 Agent 的工具集

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"] } } }

这个配置看起来简单，但实际接入时经常遇到问题。热词里“codex无法找到mcp”“codex 接入 figma mcp 怎么授权”都是这类问题。我的排查顺序是：先确认 Server 能独立启动，再确认 Client 配置路径正确，最后确认权限和网络没有拦截。

5.4 MCP 的常见坑与排查表

热词里“使用mcp工具流式输出内容到文件”是个典型场景。流式输出的好处是能实时看到进度，但坑在于：如果 Client 对分块数据的处理不当，容易出现内容截断或乱序。我的做法是先在内存里拼完整，再统一写文件，避免边收边写导致的问题。

6. 四层协作：一个完整的数据分析场景拆解

6.1 场景设定：自动生成周报

假设我们要做一个“自动生成数据分析周报”的系统。这个任务涉及：读取数据、计算指标、生成文字、输出报告。我们看看四层怎么协作。

Prompt 层：定义每个环节的输出格式。比如指标计算环节，要求输出标准 JSON；文字生成环节，要求符合周报语气。

Skill 层：封装“读取数据”“计算同比环比”“生成摘要”三个 Skill，每个 Skill 独立可测。

Agent 层：负责编排。它先调用读取数据 Skill，再调用计算 Skill，最后调用生成 Skill，中间根据结果决定是否需要重试。

MCP 层：负责对接数据源。数据库、文件系统、API 都通过 MCP Server 暴露，Agent 不用关心底层是什么。

6.2 为什么这样分层，而不是写一个大脚本

有人会问：这么简单的任务，写个脚本不就完了？为什么要搞四层？我的回答是：脚本能跑一次，但跑不了一百次。数据源会变、格式会变、需求会变。分层之后，每一层的变化都被隔离：换数据源只改 MCP，换输出格式只改 Prompt，换流程只改 Agent。这就是分层的价值。

6.3 各层的调试顺序

我的调试顺序永远是自下而上：

1. 先单独测 MCP Server，确认能拿到数据
2. 再单独测每个 Skill，确认输入输出正确
3. 然后测 Agent 的编排逻辑，看流程是否走通
4. 最后调 Prompt，优化输出质量

这个顺序的好处是，出问题时能快速定位是哪一层的锅。如果一上来就测整个系统，报错信息往往是“任务失败”，根本不知道哪里出了问题。

7. 常见问题速查与避坑经验

7.1 关于 Prompt 的高频问题

问题：模型不按格式输出怎么办？先检查 Prompt 里有没有明确的格式示例。没有示例时，模型会“自由发挥”。加上示例后，如果还不稳定，把 temperature 降到 0.2 以下。

问题：Prompt 太长导致效果下降？这是正常现象。我的经验是，把不相关的信息移出 Prompt，用 Skill 或工具调用来补充上下文，而不是全塞进 Prompt。

7.2 关于 Agent 的高频问题

问题：Agent 一直循环不退出？设置最大轮次限制，并在 Prompt 里明确“如果连续两次没有进展，就输出当前结果并结束”。

问题：Agent 选错工具？优化工具描述，加上使用场景和反例。描述里写清楚“什么时候用”和“什么时候不用”。

7.3 关于 Skill 和 MCP 的高频问题

问题：Skill 太多，Agent 选不过来？做分组，或者引入一个“路由 Skill”，先判断任务类型，再加载对应组的 Skill。

问题：MCP Server 不稳定？加超时和重试机制。我的配置是超时 30 秒，重试 2 次，重试间隔 1 秒。

7.4 我的三条核心避坑经验

第一，不要过早追求自动化。先把单步跑通，再串成流程。我见过太多人一上来就搭全自动 Agent，结果每个环节都不稳，最后推倒重来。

第二，日志比什么都重要。Agent 的每一步思考、每一次工具调用、每一个中间结果，都要记下来。出问题时，日志是唯一的线索。

第三，给模型留退路。Prompt 里永远要写“如果无法完成，输出什么”。没有退路的系统，遇到边界情况就会崩。

8. 选型建议：什么场景用什么方案

不是所有任务都需要 Agent，也不是所有工具接入都需要 MCP。我按复杂度给一个选型参考：

这个表的核心逻辑是：能用简单方案解决的，不要上复杂方案。Agent 和 MCP 是强大的工具，但强大意味着更多的调试成本和更高的出错概率。我自己的原则是，先问“这个任务真的需要自主决策吗”，如果答案是否定的，就用固定流程。

9. 我在这套体系里踩过的真实坑

说几个具体的。有一次我做一个数据提取 Agent，工具描述写得太笼统，Agent 在“提取金额”和“提取数量”之间反复横跳，一个简单任务跑了十几轮。后来我把描述改成“提取金额：只提取带货币符号的数字；提取数量：只提取带单位‘个/件/箱’的数字”，问题立刻解决。这让我意识到，工具描述的质量，直接决定 Agent 的智商。

还有一次接 MCP，Server 本地能跑，Client 就是连不上。排查了半天，发现是启动命令里的路径带了空格，没加引号。这种低级问题，往往最耗时间。从那以后，我养成了一个习惯：所有配置里的路径，一律加引号。

Prompt 方面，我踩过最大的坑是“想当然”。我以为模型能理解“最近的数据”，结果它把三年前的也算进去了。后来我在 Prompt 里明确定义“最近指最近 7 天”，才解决。模型不会读心，你省掉的每一个字，都可能变成它犯的错。

Skill 方面，我一开始把所有逻辑塞进一个大 Skill，结果改一处影响一片。后来拆成小 Skill，每个只做一件事，维护成本反而降低了。这印证了那句话：好的架构不是设计出来的，是拆出来的。

这套体系还在快速演进，新的协议、新的框架、新的最佳实践不断出现。但底层逻辑是稳定的：Prompt 管沟通，Agent 管决策，Skill 管复用，MCP 管连接。把这四层的关系理清楚，无论工具怎么变，你都能快速上手。