企业官网建设流程全解析

前阵子和一位做Agent应用的开发者聊天，他说了句让我印象很深的话：以前写提示词，像是在教一个聪明人答题；现在写提示词，像是在给一个执行力极强的实习生写工作手册——一句话没说清楚，他就敢自己发挥。这句话基本就是Agentic AI提示工程和传统提示工程的分水岭。过去两年，提示工程的核心在于训练模型“答得对”，而进入Agentic AI阶段后，提示工程的核心变成了让模型“做得稳”。当AI应用架构师把应用从“用户提问—模型回答”升级成“模型规划—调用工具—执行任务—自我纠错”的Agent形态时，提示词就不再是一段描述需求的文字，而是整套行为的操作系统。

这篇文章想把Agentic AI提示工程掰开揉碎聊清楚：它和传统提示词到底差在哪，Agent提示系统有哪些设计原则，从零搭一套可用的Agent提示方案要经过哪些步骤，上线后哪些坑几乎人人都会踩。内容主要面向AI应用架构师，也适合正在转型做Agent应用的后端工程师、提示词工程师。我尽量少堆概念，多讲我在项目里实际拆过的方案和踩过的坑。

1. 为什么说Agentic AI提示工程是AI应用架构师的新基本功

1.1 Agent根本不是“大号聊天框”

很多人第一次接触Agent，会觉得它无非就是“带工具的聊天机器人”，提示词写长一点、把工具说明贴进去就完事了。这个理解会让人在后面付出惨痛代价。

Agentic AI和传统对话应用的本质区别在于：传统应用里，模型是“答题者”，用户给一个问句，模型给一个答案，上下文靠历史消息硬堆；而Agent应用里，模型是“执行者”，它要自己判断该做什么、该调用哪个工具、返回结果是否合理、要不要继续换一种方式重试，整个过程是多步、循环、有副作用的。

我常用一个类比：传统提示词是给一位门卫写岗位说明，你只需要告诉他“看到谁该放行、看到谁该拦下”；Agent提示工程则是给一位项目经理写授权书，你不仅要告诉他项目目标是什么，还要告诉他优先级、资源边界、哪些决策必须请示、哪些情况可以直接收工，甚至还要给他一套“做错之后怎么补救”的SOP。门卫只需要判断，项目经理需要规划、决策、执行、纠偏，两者的复杂度完全不在一个量级。

举个例子，一个订机票的Agent，它不能只“生成一段订票建议”，而是要依次完成：查询可用航班、比对价格和时间、推荐最优方案、调用预订接口、向乘客确认行程、处理订票失败后的候补策略。中间任何一步出错，后面都会连锁跑偏。假如提示词里没有写清楚“查询结果为空时怎么办”，模型很可能编造一个航班号然后继续下单——这种幻觉在传统问答里只是答错题，在Agent应用里就是真实事故。

1.2 传统提示词的三个天花板

我在团队里带过不少自称“会写提示词”的同学，他们写的Prompt单看质量并不差，策略清晰、用词严谨，但一接到Agent场景就集体失灵。原因不是他们不会写提示词，而是传统提示词的三个结构性短板被Agent场景放大了。

第一个短板是单轮思维。传统Prompt的默认假设是一问一答，模型不需要考虑“我上一步做了什么，下一步该做什么”，上下文里塞再多的历史对话，模型仍然是在“接话”，而不是在“推进任务”。Agent要求模型具备任务状态感，它得知道当前做到哪一步、还剩几步、哪些前置条件没满足，这些单靠扩张上下文是补不出来的，必须在提示结构层面设计出来。

第二个短板是只说不做。传统Prompt再长，模型的输出边界仍然停留在文本。它不会真的去查数据库、不会发请求、不会改配置。Agent的提示系统必须让模型学会“借助外部工具落地动作”，而工具的选取、参数的填充、返回值的解读，每一个环节都会有全新的错误形式。我见过很多Prompt写得天花乱坠，但工具描述写得像天书，模型根本不是不会选工具，而是看不懂每个工具到底是干什么的。

第三个短板是缺乏闭环。传统Prompt答错了就答错了，用户多问一句，模型换个说法再答一遍，没有任何自我修正的压力。Agent不一样，工具返回错误、业务校验不过、任务执行超时，这些反馈都必须能回到模型侧，让模型意识到“刚才那条路走不通，我换一种策略”。如果提示系统里没有设计这种反馈回路，模型就会带着错误的中间结果一路狂奔，最后给你一个逻辑自洽但完全错误的答案。

1.3 急着学Prompt技巧前，先认清这三类人的不同任务

我观察到，不同角色对Agentic AI提示工程的需求是完全不同的，搞清楚自己属于哪一类，学习路径才不会跑偏。

第一类是AI应用架构师。这类人最需要的是“提示系统”而不是“提示技巧”。他们要设计System Prompt、工具描述框架、上下文管理策略、失败兜底机制，甚至要把提示词当成软件模块去管理版本、做回归测试。对他们来说，提示工程已经变成了一种架构设计工作，核心命题是：怎么让大模型驱动的系统在无人值守时依然稳得住。

第二类是正在做Agent应用的后端或全栈工程师。他们的痛点通常是“模型调用我接了，工具我也注册了，可是Agent总在奇怪的地方卡住”。这类人需要的是可复用的排查方法，比如工具描述怎么写、输出怎么校验、循环怎么打断。我给团队定的要求是：遇到Agent行为异常，先不要怀疑模型笨，而是按“提示描述歧义→工具返回缺失→上下文污染→缺少终止条件”这个顺序去查，大概率一查一个准。

第三类是提示词工程师。他们原有的“单条Prompt优化”能力依然有用，但必须补上一个新维度：多轮状态设计。Agent场景下最考验功力的不是辞藻，而是你能不能设计出“模型随时知道自己在干什么、该干什么、干不动了怎么办”的提示结构。这部分人转型做Agent提示，优势是有扎实的语言敏感度，劣势是容易停留在“把提示写美”的老路上，必须刻意训练工程思维。

2. 设计Agent提示系统前，请先想清楚这五个问题

2.1 你写的是提示词，还是一整套提示系统

很多Agent项目死在第一步：产品经理甩过来一句话，你的Prompt呢？然后就看着你一个人趴在键盘上憋一段长文本。真正在做Agent应用时，我从来不会先写最终的那段Prompt，而是先画一张“行为地图”。

行为地图要回答五个问题：这个Agent的边界在哪里？它从哪个入口接收任务？第一步做什么？遇到异常找谁？干完怎么收尾？回答完这五个问题，你才会意识到，Agent根本不需要“一段提示词”，它需要的是“一整套提示系统”。这套系统至少包含：System Prompt（身份与边界）、工具描述集（能力清单）、历史消息策略（短期记忆与长期记忆）、输出校验规则（防止不合格结果）、失败反馈回路（错误如何回到模型）、兜底策略（放弃时怎么办）。

我把这套系统画成一张表放在项目文档首页，每个模块都有对应的提示词片段或代码逻辑。这样做的最大好处是：当Agent行为出问题时，你可以像查日志一样定位是哪个模块出了问题，而不是面对一整段Prompt无从下手。一个反直觉的经验是：把Agent的提示拆得越碎，模型反而表现越稳。因为每个模块的职责单一，模型不会在几百行的长文本里迷失重点。

2.2 System Prompt三段式框架：身份、任务、边界

我看了大量网上流传的System Prompt，普遍问题是“什么都想写，什么都没写透”。总结下来，真正有效的System Prompt只需要三段式结构，这三段的优先级从高到低不可颠倒。

第一段是身份。告诉模型“你是谁、你在哪个系统里、你服务谁”。身份不是用来卖人设的，而是用来设定立场和能力范围。比如“你是企业IT服务台的自动处理助手，负责处理员工提交的运维工单，不负责解答财务报销问题”。这句话看着简单，但它直接决定了模型面对超范围请求时的第一反应：是礼貌拒绝还是强行回答。

第二段是任务。任务不能只写目标，必须写执行流程。我会在System Prompt里用编号列出标准作业顺序：“收到请求后，先判断是否属于工单范围→属于则提取关键字段→调用工单创建工具→根据返回结果输出工单号→工单异常时转交人工”。每一条都对应一个明确的模型行为，模型在真实运行时就有了“照章办事”的依据，而不是凭语义猜下一步。写任务段落时，我有个铁律：每个动词都必须能对应到一个具体动作或一次工具调用，凡是表达模糊的词语全部删掉。

第三段是边界。这一段的地位被我放得极高，因为Agent最大的风险不是“不干活”，而是“乱干活”。边界要写清三件事：绝对不能做的事（如不可逆操作必须二次确认）、必须请示的情况（如涉及金额、权限升级）、何时强制终止（如达到最大重试次数）。边界描述的标准是可以逐条判定，比如“当用户明确要求删除数据时，必须回复无法自动执行并转人工”，没有灰色地带。

下面是我在项目里用过的一版简化模板，你可以直接拿来改造：

# 身份 你是[角色]，运行在[系统名称]中，服务对象是[用户群体]。 你的能力范围是[列举能力]。不在范围内的请求，直接拒绝并说明原因。 # 任务 当收到用户请求时，严格按照以下顺序执行： 1. 判断请求是否合法、参数是否完整； 2. 若需要调用工具，选择最合适的工具并填写参数； 3. 读取工具返回结果，判断是否符合预期； 4. 若结果异常，最多重试N次，每次重试前分析失败原因； 5. 输出最终结果，格式为[具体要求]。 # 边界 - 禁止[具体不可逆动作]，除非用户明确二次确认； - 当出现[情况A]或[情况B]时，立即停止执行并转交人工； - 不要编造工具返回值。工具报错时，如实报告错误内容； - 当用户说“停止”或达到最大尝试次数时，立即终止。

2.3 让Agent“会用工具”的提示策略：描述语义是核心资产

Agent和工具之间的交互，本质上是一个“模型读描述、选工具、填参数、读结果”的过程。工具列表在模型眼里就是一排“商品说明”，你的描述写得好不好，直接决定它选得准不准。我在项目里总结出的工具描述四条经验，已经成了团队内部的标准。

第一条，工具名称用“动词+对象”的格式。比如search_employee_info比get_info清晰得多，create_leave_request比do_task好。模型在十几个工具里做选择时，名称就是最高权重的信息，命名含糊等于给模型埋雷。

第二条，描述里必须写“什么时候用”和“什么时候不用”。这条是最容易被忽略的。比如一个查询年假余额的工具，描述不能只写“查询年假余额”，要写“当用户询问可休假天数、年假余额、剩余假期时使用；当用户询问请假审批流程时，不要使用此工具，应调用leave_approval_status”。正反两个方向的约束，能把误调用率压下去一大截。实测下来，加了“不要使用场景”之后，工具选择准确率能提升将近十个百分点。

第三条，参数描述要带格式示例和边界说明。模型填参数也会犯错，常见的是把日期格式写错、把ID类型搞混。我在每个参数的description里都会追加“格式示例”和“注意边界”，比如“amount：数字，单位元，支持两位小数，例如298.50；注意不接受负数”。这些小注释不占多少token，却能把参数校验错误率降下一大截。

第四条，为容易混淆的工具配Few-shot示例。工具数量一多，模型不可避免会出现“A工具能解决但选了B工具”的情况。我的办法是在System Prompt里单独放一个“工具选择示例”小节，用两到三个完整例子展示“用户请求→应当选择的工具→填入的参数”，让模型模仿这个决策链路。这个做法比我反复在工具描述里加形容词有效得多。

2.4 上下文和记忆：不给Agent吃“营养过剩”的垃圾

Agent执行过程中，每一轮工具调用都会产生大量中间结果，这些东西如果全部堆进历史消息，很快会撑爆上下文窗口，而且会把模型的注意力带偏。我见过一个真实案例：某Agent在执行到第四步时突然“忘了”最初的任务要求，原因就是中间日志太多，重要信息被淹没。

我的做法是把上下文分成三层。第一层是任务上下文，也就是用户最初的目标、关键参数、约束条件，这一层始终放在消息列表的最前面，并且每次更新时保持精简。第二层是执行上下文，也就是已经完成的步骤和工具调用结果，这部分要做结构化压缩，比如只保留“调用了某工具、返回是否成功、结果摘要”，而不是把原始JSON全量塞回去。第三层是临时上下文，比如中间的错误日志、调试信息，这类内容用完即弃，不进入下一轮。

如果Agent任务跨度很长，还应该给模型一个“状态小结”机制：每隔若干轮，要求模型用一句话总结当前进展、已完成步骤、剩余步骤、最新风险。这个小结会替换掉前面杂乱的执行历史，既节省token，又让模型时刻有一张清晰的进度地图。很多Agent跑着跑着就“失忆”，本质上就是上下文管理没做好，而不是模型的记忆能力不行。

3. 从零搭一套Agent提示方案：核心环节实操拆解

3.1 第一步：把业务任务拆成最小可执行单元

我习惯用一个最朴素的工具来开场：一张A4纸，把某个Agent要完成的业务任务从入口到出口画成流程图。不用画得花哨，重点是拆分到每个节点都能回答两个问题：这一步是纯文本判断，还是需要调用工具？如果是调用工具，输入输出分别是什么？

用一个内部门禁系统Agent的例子。业务任务是“员工提交门禁异常工单后，Agent负责初步处理”。我拆出来的单元是：意图识别（判断是不是门禁类问题）→身份核验（从请求中提取工号并查询员工信息）→权限检查（判断该员工是否在本楼宇有访问权限）→异常诊断（查询最近门禁记录判断是否设备故障）→处理动作（调用远程重置权限工具或派发维修单）→结果反馈（告知员工处理结果或转人工）。

拆完这一步，你是不是发现，最终那段System Prompt其实就是把这六个单元连起来，外加每个单元的触发条件和异常出口而已。如果没有这一步，你写Prompt时就会特别心虚，因为你不确定模型会在哪些节点需要什么信息、会遇到什么异常。拆解完成后，我会顺手统计每个单元是调用工具还是纯对话，这个比例决定了Prompt的技术复杂度，也决定了后续测试的重点。

3.2 第二步：编写工具Schema与Few-shot示例

工具Schema是Agent提示系统里最容易被低估的部分。很多开发者写工具描述时像写代码注释，惜字如金，但模型不是编译器，它靠自然语言理解工具用途，描述必须转换成语义清晰的“用户视角”语言。

我放一个实际用过的工具定义片段，你可以对照感受一下差距：

{ "name": "query_leave_balance", "description": "查询员工的年假余额。当用户询问'我还有多少年假'、'年假剩几天'、'今年还能休几天'等类似问题时使用；如果用户询问的是请假审批进度，请改用query_leave_approval，不要调用本工具。", "parameters": { "type": "object", "properties": { "employee_id": { "type": "string", "description": "员工工号，格式如E10086，员工本人查询时无需传参，默认取当前用户" }, "year": { "type": "integer", "description": "查询的年假年度，默认是当前自然年，例如2025" } }, "required": ["employee_id"] } }

这里有个很关键的设计：employee_id默认取当前用户。一般来说，Agent系统会通过身份认证自动注入用户ID，不需要用户自己报工号，也不应该允许用户随便传别人的工号。把这个逻辑写进参数描述，能有效防止水平越权。

工具写完，我还会在System Prompt里附上三个Few-shot示例。第一个是正常场景，展示正确的工具调用链路；第二个是边界场景，展示一个看起来能调用、实际不该调用的情况，比如“员工查年假但实际想查加班调休”，模型应输出“解释并引导用户使用调休查询工具”；第三个是拒绝场景，展示用户请求超出权限范围时，模型如何礼貌拒绝并转人工。这些示例不需要多，每个工具组两到三个，模型就能在类似决策上获得足够参照。

3.3 第三步：引入“先想后做”的推理与反思机制

Agent提示系统里还有一个绕不开的模块：怎么让模型在执行途中保持清醒。如果只写“请一步一步处理”，模型确实会分步，但它不会主动评估“这一步的结果是否合理、下一步是否要继续”。所以我在Prompt里显式植入了一个推理循环，让模型每走一步都经过“状态分析-决策-行动-观察”的闭环。

这个循环的提示写法有很多变体，我目前用的是一套稳定的四段式结构：

在处理任务时，你必须在每轮输出前按以下格式推理： Thought: 当前任务进行到什么阶段？我手上有哪些信息？下一步的关键决策是什么？ Action: 我决定调用什么工具，或做一次什么判断？ Observation: 刚才的动作返回了什么信息？是否符合预期？如果不符合，失败原因可能是什么？ 然后根据Observation决定继续执行还是调整策略。当所有必要步骤完成且结果得到确认时，输出Final Answer。

这套模式的本质是让模型把“推理”显式化。模型在生成文本时，先想后写的概率远大于直接写，而这段Thought/Action/Observation就是给模型筑了一条“强制思考”的轨道，防止它跳跃式决策。实测中，显式说明推理结构之后，复杂任务的成功率有明显提升，因为模型不再贸然从一个状态跳到下一个状态。

反思机制我放在任务快要结束的时候。我会在System Prompt里加一条硬性要求：在输出最终结果前，必须做一次自查，检查三点：我是否真的调用了工具而不是凭记忆回答？工具返回的数据是否都体现在结论里？有没有超出用户授权的操作？这一条能拦住相当一部分“完美但错误”的答案。

3.4 第四步：建立Agent行为的质量评估基线

没有评估就上线，是Agent项目最危险的赌博。因为Agent行为是动态生成的，你无法像测普通接口一样断言输出字符串，必须建立一套多维度的评估基线。

我建议至少盯五个指标。第一是任务成功率，指端到端是否达成业务目标，这是北极星指标。第二是工具选择准确率，指Agent选择的工具和专家标注的一致比例，这个指标能单独暴露工具描述的问题。第三是无效调用率，指Agent调用了工具但参数校验失败或工具返回业务错误的次数占比，这个指标高说明理解有偏差或参数描述不清。第四是平均任务轮数，轮数太长说明Agent在低效试探，拖慢了响应也烧了token。第五是成本指标，无谓的重试、过长的上下文都是成本黑洞，所以要统计单任务平均token消耗，并设置超时熔断。

评估集怎么造？我基本不依赖公开Prompt模板，而是直接从历史真实请求里采样，覆盖正常请求、模糊请求、缺参请求、恶意越权请求四类。每种至少二十条，标注好“期望工具调用序列”和“期望最终结果”。每轮迭代后跑一遍回归，用我前面说的五维指标对比变化。这个评估集是Agent提示系统的生命线，没有它，后续任何Prompt调整都是盲改。

4. Agent上线后最容易翻车的四个场景与排查实录

4.1 场景一：Agent在工具调用里原地打转

有一次，我负责的一个工单处理Agent出现了这种情况：它不停调用查询工具，每轮都返回“工单不存在”，而它下一个动作居然是“再查询一次”，如此反复直到触发最大重试次数。从日志看，模型每一轮都在认真分析，但分析内容其实是一模一样的复读机。

排查下来，根本原因是提示系统里缺少两个关键约束：终止条件和不重试说明。System Prompt里只写了“如果查询失败则继续尝试”，没有定义“连续失败多少次必须停止并转人工”。工具描述里也没有说明“工单状态仅为关闭时返回不存在，此时应引导用户提交新工单”。模型在信息不充分的情况下，只会机械地重复同一个动作。

解法很简单：一是在System Prompt边界段加入“同一工具调用失败超过两次，禁止继续重试，必须输出失败报告并转人工”；二是丰富工具描述中的失败语义，把“返回为空”和“查询不到但应该存在”以及“查询不到且任务无效”区分开。修复后，这类死循环几乎绝迹。

4.2 场景二：上下文越滚越长，行为越来越离谱

另一个项目里，Agent本来沿着正确路径执行，但在第十五轮左右突然开始偏离任务，去回答和初始目标完全不相关的问题。查日志时发现，它的上下文里堆了大量工具返回的原始JSON，包括一些历史工单的描述文本，模型被这些无关信息“带跑”了。

这就是典型的上下文污染。长期记忆没做筛选，中间结果被无差别塞进历史。我的修复方案分三步：第一，工具返回结果入库时做字段裁剪，只保留模型决策真正需要的核心字段；第二，每隔若干轮插入一次Agent状态小结，用一段一两句话的摘要替换掉前面冗长的执行历史；第三，在System Prompt里明确“只有最近一次工具返回和状态小结属于当前有效上下文，之前的历史记录仅供参考”。这样改造后，Agent的长任务稳定性明显提升，token费用也降了将近三成。

4.3 场景三：Agent自作主张做了越权操作

这类问题最吓人。某次测试中，用户只是问“查询某同事是否在通讯录里”，Agent居然在用户没有明确授权的情况下，调用了一个“发送通知”工具，试图给该同事发一条系统消息。幸运的是当时还在灰度测试阶段，没有造成实际影响。

越权行为的根源，一是工具描述写得太宽泛，让模型误以为“这个工具可以被任何查询场景顺带使用”；二是System Prompt的边界段里没有明确“发送通知、修改数据、删除数据”属于高权限动作，必须二次确认。我把工具描述里与发送、修改、删除相关的动词全部加了“必须获得用户明确授权”的前置条件，并在System Prompt中新增一条硬规则：任何产生外部副作用的工具调用，都需要独立的用户确认步骤，不能在推理过程中隐含触发。自那以后，监控里再也没出现一次未授权副作用调用。

4.4 Agent故障排查速查表与三条兜底原则

为了减少排查时试错时间，我整理了一张速查表，每次Agent行为异常，团队都先按这张表定位：

三条兜底原则是：任何任务必须有终止条件；任何有副作用的动作必须有确认环节；任何连续异常都必须有降级到人工的通道。把这三条写进系统，Agent的“胆子”就会被牢牢关在笼子里。

5. 进阶方向：让Agent提示系统更稳更省钱的几条经验

5.1 提示词版本管理与回归测试

Agent提示系统上线后，改动是必然的，但很多团队把Prompt当“一次性文案”直接改到线上，出了事再回滚。这种粗放做法在Agent场景下风险极高，因为一次提示措辞的微调可能不影响普通对话，却会连锁改变工具调用行为。

我现在的做法是把所有Prompt文本按模块存进Git仓库，每次改动都有diff记录，commit message写清楚原因和预期影响。同时维护一套自动化回归脚本，每次改动后跑一遍前面提到的评估集，如果任务成功率或工具选择准确率下降超过一个百分点，就必须重新调整。这个流程一开始会有些繁琐，但对Agent项目来说，Prompt就是核心代码，不纳入工程化管理是没法长期迭代的。

5.2 多Agent协作场景下的提示职责拆分

复杂业务很少靠单个Agent全流程包干，我最近在做的系统里就有路由Agent、执行Agent和审计Agent三个角色。多Agent场景下，提示工程的重点从“写执行步骤”变成了“写协作协议”。

路由Agent的System Prompt最核心的职责是分类和分派，它不需要掌握具体业务工具的细节，只需要识别请求类型并决定交给哪个下游Agent。执行Agent的System Prompt要写清楚自己的专业边界，超出边界的请求必须回退给路由Agent，不能硬答。审计Agent最特殊，它的System Prompt里全是“检查什么、记录什么、什么情况下必须告警”，它的输出不面向用户，只面向日志和监控系统。三个Agent之间还会约定一种内部消息格式，用纯文本的“请求方→目标方→意图→关键参数”结构传递信息，比让Agent自由对话要可控得多。

5.3 个人体会：提示工程的本质是给不确定性上保险

做Agent提示这行快两年，我最大的体会是：Agentic AI提示工程，本质上不是“把提示词写得更华丽”，而是“把不可控的行为空间压缩到可控范围”。模型本身有不确定性，同样一句提示不同轮次可能产生不同结果，架构师能做的，就是用结构化的提示系统、严格的边界规则、完善的事后校验，把这种不确定性圈起来，让系统在绝大多数情况下稳定可用。

我也踩过不少次坑。早先总想着让Prompt“聪明一点”，给模型更大的自由去规划，结果Agent自由过了头，做了很多我没想到的事。后来学乖了，每条Prompt都先问自己一句：如果这是一个真实实习生，我给它的指令够不够明确？它遇到异常知道该问谁吗？它会不会误解我的意图去干别的？这几次自问，往往就能筛掉大半问题。

如果你也正在做Agent应用，我的建议是少看那些“惊艳”的Prompt炫技，多花时间在工具描述、边界设计、上下文治理和回归评估上。Agentic AI提示工程的功夫，大多花在提示词之外。