企业官网建设流程全解析

1. 为什么 Agent 的提示词，比聊天场景"重"得多

大多数人第一次接触提示词，都是从聊天开始的：让 ChatGPT 写个朋友圈文案，让它总结一篇文章，话说不清楚就换个说法再来一次。到了 AI Agent 这边，事情完全变了。Agent 是一个"会自己干活"的程序：你给它一个目标，它自己决定调哪些工具、按什么顺序、怎么处理中间结果。而这个"程序"唯一的存在形式，就是提示词。换句话说，提示词就是 Agent 的源代码。

聊天场景里，提示词只影响一次输出；Agent 场景里，提示词影响的是一个循环。这个循环大致长这样：模型理解任务 → 决定要用哪个工具 → 输出调用请求 → 系统执行工具 → 把结果喂回给模型 → 模型再决定下一步。如此反复，直到任务完成。每一轮都在消耗上下文，每一轮的决策都依赖之前的信息。提示词在这个循环里干的活，不只是"把任务说清楚"，还包括"告诉模型怎么决策、怎么纠错、怎么终止"。

打一个不太严谨但很好懂的比方：跟聊天模型说话，像跟一个聪明但没经验的实习生交代一件事；跟 Agent 说话，像给新人写岗位说明书和工作流程——他不仅要听懂"做什么"，还要知道"什么情况走什么流程""出错了怎么办""做完怎么汇报"。

这也是为什么很多人在"会用大模型"之后，栽在 Agent 开发上：他们以为提示词就是"把话说好听点"，结果搭出来的 Agent 要么跑偏，要么在一件事上反复横跳，要么自己编造工具结果。问题几乎都出在提示词层。这篇是系列的第二期，就围绕"怎么让大模型真正听懂你说话"展开，重点挑那些能立刻用到 Agent 开发里的东西讲，后面第三期开始碰 RAG 和多工具编排时，你会发现今天这些内容全是地基。

1.1 提示词工程不是"讨好模型"，而是"设计决策逻辑"

我见过很多新手有个误解，觉得提示词就是"求"模型干活，语气越客气越好。其实模型没有情绪，提示词工程的本质是控制信息空间：你放进上下文里的每一句话，都在影响模型对任务的概率判断。

在 Agent 里，这个判断直接决定行动。比如同样是"查一下这个公司最近有没有融资"这条任务，如果你不告诉模型"只能使用 search_web 工具，查不到就换关键词再试一次"，它可能会：

• 直接用训练记忆里的过期信息回答你；
• 调用了工具但看不懂返回结果，然后自己编一个结论；
• 查一次没有结果就放弃，也不告诉你。

这些都不是模型"笨"，是你在提示词里没有定义决策规则。所以提示词工程在 Agent 场景下，本质上是给模型写一套可执行的决策逻辑。这个观念不转过来，后面写再多技巧都是花架子。

2. 提示词背后的机制：上下文窗口、注意力与顺序效应

在给技巧清单之前，我想先补一层底层知识。很多人写提示词是"凭手感"——感觉对了就发，不对就改。手感当然重要，但如果你知道模型内部是怎么处理这些文字的，调试速度会快很多。

模型每次推理时，能看到的全部信息就是我们拼进上下文窗口的那一串 token。它不知道你是谁，不知道这个任务从哪来，不知道你之前改过多少版，它唯一的输入就是这串文字。所以提示词工程的本质，可以概括成一句话：在有限的上下文里，用最有利于模型分配注意力的方式组织信息。

2.1 中间遗忘：越长越容易漏，重点要放头尾

实测下来，模型对上下文开头和结尾的内容最敏感，对中间部分相对麻木。你写系统提示词的时候，如果把"最重要的约束"藏在第三段、第五句，它可能真的会漏。我自己的习惯是：最重要的规则放最前面，第二重要的放最后面，中间放补充说明。

这条经验对 Agent 尤其重要。因为 Agent 的上下文会随着工具调用不断变长：第一轮的工具返回、第二轮的结果、第三轮的日志……全都在拼接。如果一个关键约束写在系统提示词的第一段，它距离模型"当前正在处理"的 token 可能已经隔了几千字。这时候要保证模型还记得它，有两个办法：一是把关键约束在用户请求里再强调一次，二是用格式标记（比如 XML 标签）把它跟其他内容隔离出来。

2.2 上下文工程：别让提示词背锅

最近"上下文工程"这个词很火，我觉得它比"提示词工程"更准确。提示词只是模型能看到的信息的一部分，RAG 检索结果、工具返回的日志、历史对话记录，全都会进上下文。上下文里垃圾太多，提示词写得再好也救不回来。

我踩过一个大坑：某个 Agent 需要读取数据库查询结果，工具返回了一段很长的 JSON，里面有个字段叫status表示数据状态。系统提示词里明明写了"仅使用 status=active 的数据"，但模型经常忽略。排查到最后发现，工具返回的 JSON 里字段名跟接口文档不一致，有的叫status，有的叫state，模型看花了眼。后来我在工具描述里明确写了返回结构示例，问题才解决。

所以调提示词之前，先检查上下文里有什么。很多"提示词不生效"的问题，其实是信息在上下文里已经烂掉了——格式混乱、重复冗余、关键字段被淹没。先把上下文理顺，再回头调提示词。

3. 系统提示词的四根支柱：角色、规则、格式、边界

Agent 开发的标配是 system prompt（系统提示词）。它相当于是给 Agent 立规矩的那份文档。我每次写系统提示词，都会按四个支柱自查：角色、规则、格式、边界。缺哪一个，后面都会出奇怪的问题。

3.1 角色定义：决定模型的"行为基线"

角色不是"扮演"，是在给模型一个行为基线。同样是遇到一个模糊任务，"你是一名严谨的数据分析师"和"你是一名随性的创意写手"，接下来的处理方式会明显不同。角色写清楚了，很多规则可以少写——因为模型会自动往那个角色的行为方式上靠。

例如下面这个片段：

你是一名资深行业研究员，擅长收集信息、交叉验证数据， 并输出有明确出处、观点独立的行业综述。

这比单纯写"你必须严谨、必须有出处"要有效得多，因为它同时启用了模型对"资深行业研究员"这个群体的先验认知。

3.2 行为规则：把"要怎么做"写成可执行的条目

规则部分要具体，不能只喊口号。我见过很多人写"请务必准确"，这句话模型看了等于没看。正确的写法是说清楚在什么情况下做什么事：

行为规则： 1. 在回答任何事实性问题之前，先判断是否需要使用搜索工具获取最新信息； 2. 如果搜索工具返回结果为空，尝试更换更短的关键词重试一次； 3. 每次使用工具后，先观察返回结果，再决定是否继续； 4. 如果连续两次工具调用都没有获得有效结果，向用户说明原因并建议其他方案； 5. 不要编造工具返回中不存在的数据。

注意这里每条规则都带了一个"触发条件"和"动作"。模型本质上在做模式匹配，你给的条件越清晰，它匹配得越准。

3.3 输出格式与边界禁区：减少解释空间

格式部分，直接给模板。比如"所有输出必须以 Markdown 格式呈现，结论部分列在最前面，每个结论下方注明信息来源"。边界部分要写"不能做什么"——模型本质上是接着你的话往下说，你不拦着，它就会顺着发挥。

我之前在系统提示词里写过一句"不要猜测用户没有明说的意图"，效果出奇地好。以前这个 Agent 经常会自作主张加一堆用户没要求的东西，加了这条之后收敛了很多。因为人脑和模型都一样：你告诉它"不要做什么"，它就会在下一次推理时主动检查自己有没有越界。

4. 用户请求的写法：把模糊愿望变成可执行任务

如果说系统提示词是"岗位说明书"，用户请求（user prompt）就是每次下发的"具体任务单"。大多数人在这里犯的错，是把请求写得跟平时跟人说话一样：随意、省略背景、用一个词概括目标。模型不是不能理解模糊的话，但理解成本高了，发挥就不稳定，尤其在 Agent 里，用户请求会被拿去跟系统提示词里的规则一起推理，模糊的请求会导致模型在工具选择上随机游走。

4.1 任务表达五要素

我习惯把一条合格的用户请求拆成五个要素，写完后逐项检查：

• 目标：最终要得到什么产物。
• 背景：模型需要知道的上下文信息。
• 约束：必须遵守的硬性条件。
• 格式：输出长什么样，用什么结构。
• 参考：有没有示例可供参照。

拿"整理会议纪要"来说，大多数人写的是"帮我把会议纪要整理一下"。这句话目标不明确、背景缺失、格式没有，模型只能猜。稍微好一点的版本是这样：

你是项目助理。请把下面的会议记录整理成结构化纪要： 1) 决议事项（含责任人）； 2) 待办清单（含截止时间）； 3) 风险项（含提出人）。 格式用 Markdown 表格，如果原文中没有提到责任人或截止时间， 请标注"未提及"，不要自行补充。

这个版本的每个字段都对应了五要素里的某一项。目标是将记录"变成结构化纪要"，背景是原始记录本身，约束是"未提及就标注，不自行补充"，格式是三类标题加表格。模型拿到的不是一道开放题，而是一道填空题。

4.2 让模型做选择，而不是做猜测

在 Agent 场景里，用户请求还承担着一个功能：帮助模型判断"该不该用工具、用哪个工具"。这个判断越省力越好。比如你问"明天北京天气怎么样"，模型不一定知道要去调天气工具；但如果用户请求里明确写了"请使用 weather 工具查询"，模型基本就不会犯迷糊了。

当然，不是每次用户都会写得这么规范。所以实际项目里，我会在系统提示词里加一句"当用户请求中缺少必要信息且不明确时，先向用户确认，而不是自行假设"。这句话能挡住大量无效的工具调用。

5. Agent 专属层：工具描述、ReAct 与自我纠错

到了 Agent 开发，提示词的结构比聊天场景复杂一截，多了几层很少在普通提示词教程里见到的东西。这些层决定了一个 Agent 能不能真正"干活"。

5.1 工具描述也是提示词

很多新手没意识到：模型选择工具，靠的也是提示词。你在注册工具时写的那段功能描述，就是模型的决策依据。写得太笼统，模型会在多个工具之间犹豫；写得太啰嗦，模型更容易在误判时还觉得自己有理。

写给工具的描述，我的模板是这样的：动词开头，说明适用场景，说清楚每个输入参数的含义，最后给一个典型调用例子。

search_web(query: str)： 当用户需要获取最新信息、查询外部网页内容、验证时效性数据时使用。 query 必须是搜索关键词，建议控制在 10 个字以内。 示例：search_web("2026年大模型发展趋势")

这段描述虽然短，但它告诉模型三件事：什么场景用它、参数是什么、怎么用。我之前遇到过模型把一个完整的句子整个塞进query，导致搜索效果极差，后来在描述里加了"建议控制在 10 个字以内"就解决了。这就是提示词的力量。

5.2 ReAct 循环怎么写进提示词

Agent 的推理模式里，最经典的就是 ReAct——推理（Reasoning）加行动（Acting）循环。这个模式不一定非要靠框架实现，写在提示词里同样有效。系统提示词里可以明确要求模型按固定结构输出：

每次需要执行动作时，请按以下格式输出： thought: 分析当前任务还需要什么信息 action: 要调用的工具名称 action_input: 工具入参，使用 JSON 格式 调用结果返回后，请先观察再决定下一步。任务完成时输出 final_answer。

把 ReAct 循环写进提示词，本质上是在给模型"搭脚手架"，强制它把决策过程外显出来。外显的决策有一个额外好处：我们能看到它为什么做错了。工具选择错了、参数错了、判断错了，全都在 thought 里暴露无遗，排查起来非常省力。

5.3 自我纠错指令：Agent 的"异常处理"

Agent 跑任务一定会遇到异常情况：工具返回空、接口报错、数据格式不对。模型默认行为是"硬着头皮继续"，要么编造结果，要么换一个毫不相关的工具乱试。系统提示词里如果不写异常处理规则，这些问题会一直被当成"模型智商问题"。

我在所有 Agent 的系统提示词里都会加这么一段：

如果工具调用失败或返回结果为空，请先分析失败原因，并使用不同的关键词或参数重试一次。 连续两次失败后，停止尝试，并向用户说明以下内容： 1) 你尝试了什么操作； 2) 失败的可能原因； 3) 用户可以采取的下一步行动。 绝对不要编造工具返回中不存在的结果。

加了这段之后，Agent 的行为从"硬撑着胡说"变成了"有策略地重试并明确报错"。这跟代码里的异常处理是同一回事，只是它用自然语言实现。

5.4 系统提示词与 Skill 的边界

最近大家在讨论"系统提示词工程和 skill agent 有什么区别"，我的理解是：系统提示词是常驻规则，Agent 启动后就一直在；Skill 是一段可插拔的提示词或流程脚本，只有特定场景才加载。系统提示词是核心代码，Skill 是按需启动的插件。

实操里两者经常搭配使用：系统提示词里声明"当遇到 XX 类任务时，你需要加载对应的 Skill"，然后再在工具列表里挂一个use_skill(skill_name)工具。这样既保证了常驻规则的稳定，又不让系统提示词无限膨胀——要知道，系统提示词越长，模型对中间内容的关注就越低，这是前面说的顺序效应。

6. 一个案例的三轮迭代：行业综述 Agent 是怎么调教出来的

理论讲太多容易飘，我拿一个真实案例走一遍完整流程。任务是要写一个 Agent：用户给它一个行业关键词，它输出该行业近一年的综述报告，要求有信息量、有数据、注明来源。

6.1 第一轮：只有角色，没有流程

初始系统提示词我写得很偷懒：

你是一名行业研究员。请根据用户给出的关键词，输出一篇行业综述。

跑出来的结果是灾难：模型通篇都是"该行业近年来发展迅速""各大厂商纷纷布局"这种正确但没有用的废话，完全没有具体数据，更别提来源。最要命的是，它压根没有调用我挂好的搜索工具——因为它不知道什么时候该搜索。

问题出在提示词没有定义"信息获取路径"。模型觉得靠自己的知识就能回答，自然不会用工具。这一轮我学到的教训是：任务流程要写进提示词，不能指望模型自己想到要搜。

6.2 第二轮：补上步骤和格式

第二轮我把系统提示词改成：

你是一名资深行业研究员。请按以下步骤完成任务： 1. 先使用 search_web 搜索用户给出的行业关键词，获取最新资讯； 2. 根据搜索结果总结该行业的主要趋势、代表企业和关键数据； 3. 输出格式：先用一句话概括核心结论，再分三个小节展开； 4. 所有数据必须来自搜索结果，标出来源链接。

效果明显好转：模型会调用搜索工具了，输出结构也清晰了。但仍有一个大问题——它经常把"什么时候的数据"混着用。搜到了 2024 年的文章，也搜到了 2025 年的文章，模型不区分时效，一股脑全写进去，甚至偶尔还会自己补两句搜索里没有的"常识"来凑上下文。

6.3 第三轮：加约束、加边界、加格式要求

第三轮我做三件事：一是强调时效性，二是禁止编造，三是给出明确的评分标准（让模型自己检查输出）。

你是一名资深行业研究员，专长是撰写有数据支撑的行业综述。 工作步骤： 1. 用 search_web 搜索行业关键词，优先选择发布时间在近 6 个月内的内容； 2. 提取趋势、厂商动态、市场规模等关键信息，每条信息记录来源； 3. 如搜索到的时间跨度较大，请明确标注每个数据对应的时间点； 4. 最终输出格式： - 一句话核心结论 - 三个小节：主要趋势、代表企业动态、关键数据摘录 - 所有数据保留来源链接 硬性约束： - 只使用工具返回中实际存在的信息，不得根据记忆或推测补充数据； - 如果某个维度搜索不到可靠信息，如实说明"该维度未检索到权威来源"； - 输出前自查一遍：每个数据是否都能在工具返回中找到对应出处。

这版跑出来的结果终于能用了：结构完整，每个数据后面都挂着来源，而且会主动标注"该维度未检索到权威来源"，而不是硬编一个数字。这个案例最值得记的不是最后一版的内容，而是每一轮修改背后的思路：先解决有没有的问题，再解决好不好的问题，最后解决稳不稳的问题。

7. 调试提示词的正确打开方式：测试集、陷阱题与常见失败模式

提示词写完不是终点，它需要像代码一样被测试、被迭代。很多人调提示词是"改一版，跑一次，看感觉",这种方式的随机性太强。我建议从第一天就开始建测试集，哪怕很小。

7.1 建立最小测试集，防止"改好一个、改坏三个"

测试集就是一组有代表性的测试任务，不用多，五到十条就够。关键是覆盖面：要包含正常任务、边缘任务、易错任务。每次修改提示词，把整个测试集跑一遍，看哪些用例通过、哪些用例回归失败。比如我的行业综述测试集里就有一条"用完全不存在的行业名去搜索"，专用来检验 Agent 在搜索失败时的处理是否符合预期。

没有测试集，你很容易陷入一种循环：专门调好了刚才那个失败的 case，却发现之前能跑通的 case 全挂了。有测试集，才能在"修 bug"和"防回归"之间找到平衡。

7.2 陷阱题的价值：鹈鹕骑自行车这类测试为什么流行

最近社区里流行那种"鹈鹕骑自行车"的提示词测试——让模型生成一张鹈鹕骑自行车的图。这个梗能火是有原因的：任务看起来特别简单，但模型经常漏掉"骑自行车"这个核心动作，转而生成一只站在地上的鹈鹕，或者一只喙长得像自行车的鹈鹕。

这类陷阱题在 Agent 调试里很有价值。故意构造"任务简单但带一个不能漏的核心约束"的用例，能立刻检验模型是不是真的在严格执行你的指令。比如我给搜索类 Agent 建过一条陷阱题："直接调用 search_web 搜索'天气'两个字，不要做任何补充解读。"模型如果自作聪明地加上"北京天气"去搜，就说明它对指令的执行是有损耗的。这时候我不去责怪模型，而是去优化提示词里的约束表达。

7.3 常见失败模式与对应修法

我把 Agent 提示词最常见的失败模式整理成了一张表，方便排查：

7.4 排查链路：从复现到二分定位

如果 Agent 行为不对，我的排查顺序一般是：先复现，再二分，后修改。具体来说：

1. 用最小复现用例跑一遍，确认是"必现"还是"偶现"。偶现问题大概率是上下文污染或随机性，提示词只能缓解，不指望根治。
2. 区分是"没听懂"还是"听懂了没做到"。看模型的 thought 输出：如果它根本没有提到相关约束，那就是信息没有被注意；如果提到了但动作不对，那是推理问题，修法完全不同。
3. 做二分法：把系统提示词砍掉一半,看问题是否消失。如果消失，说明问题藏在被砍掉的那一半里；如果还在，说明是另一半的锅。这样比从头读一遍提示词猜要快得多。

调试提示词的过程中，我最大的体会是：大多数问题都不是"模型蠢"，而是"信息没放对位置"或"约束没写透"。模型其实挺实在的，你给它什么游戏规则，它就怎么玩游戏。你规则写得不清晰，它就会表现得像在乱来。

这个系列的后续内容会在多工具编排和 RAG 上继续展开，但你在动手之前，我建议先把提示词调试的基本功练扎实——建一个测试集、写几版系统提示词、体会一下每次改动带来的行为变化。这套手感，会是你后面所有 Agent 项目的隐形底座。