★ FEATURED ARTICLE 我先说个观点聊“AI自动化工程”绕不开“系统提示词”。这几年我从写pytest脚本、ansible剧本、playwright用例做到后来把这些工具全部交给AI Agent去调度最大的感受就是——自动化工程的瓶颈早就不在工具层了而在“怎么把人的意图、边界、验收标准准确翻译成AI能理解并且严格执行的一套指令”。这套指令就是系统提示词。它不是简单的“角色设定几句话”而是整个自动化系统的控制面、约束面和协议面。这篇文章适合正在做自动化测试、自动化运维、平台工程或者想把自己的测试框架、运维脚本升级成“AI可调度”形态的同学。如果你只是在网上看过别人晒Agent Demo想搞清楚系统提示词到底怎么设计、怎么调优也能在这里找到一条可以照做的路径。下面我会把我在实际项目里沉淀下来的系统提示词设计方法、与Skill Agent的区别、现场模板、以及踩坑记录一次讲清楚。1. 为什么说系统提示词是AI自动化的方向盘1.1 传统自动化脚本解决不了的问题传统自动化工具本身都很成熟。pytest可以把接口用例组织得清清楚楚ansible能让你用一份playbook管几百台机器playwright在UI自动化上几乎统治了市场。但是用过一段时间你就会发现这些工具都有一个共同的隐含成本任务边界得人肉定义。你要写用例、写断言、写异常处理分支每一条路径都是预先画好的。业务一改脚本就废一大半维护成本直接压在团队身上。AI Agent出现后情况变了。它可以读需求描述理解“这个接口的返回码需要检查什么”“这台机器上的nginx配置哪行有问题”然后自己去调pytest、ansible、playwright甚至自己写一段临时脚本完成验证。但问题也随之而来——你给它多大的自由它就敢闯多大的祸。这就是为什么系统提示词成了整个工程里的“方向盘”它决定了Agent往哪个方向走、走多快、能不能变道、哪些路打死不能上。1.2 系统提示词在自动化工程中的真实定位我习惯把系统提示词比作“岗位说明书加工作守则”。一个人进公司光有技能不够还得知道自己的职责边界、汇报对象、什么级别的操作需要审批、什么情况下可以自主决策。AI Agent也一样。你给它的系统提示词里写的不只是“你是一个运维工程师”而是一整套任务解读规则、工具调用协议、状态输出格式、安全边界和熔断策略。这样说可能有点抽象。换一个我实际遇到过的例子我让Agent去排查一台服务器的CPU飙升问题。系统提示词如果只写了“你是一个运维工程师请帮我排查”它有可能会去执行top命令、看进程、然后告诉你“某个Java进程占用高”。但如果系统提示词规定了“排查步骤必须从负载指标、日志、进程列表三个维度交叉验证给出的结论必须附上依据禁止在未确认影响范围前执行重启”Agent的输出质量和安全性就会完全不一样。它从“一个知道很多但容易乱跑的实习生”变成了“一个有SOP约束的现场工程师”。这就是系统提示词的定位——它不教Agent“知识”它负责教Agent“规矩”。2. 系统提示词的五个构成要素与设计方法2.1 角色定义不是起名字是设定行为基线很多人写系统提示词第一句就是“你是一个AI助手”或者“你是资深自动化工程师”。这个动作看起来简单但角色定义的本质不是起名字而是设定行为基线。同一个模型你告诉它“你是自动化测试工程师”和“你是测试团队的负责人”它的输出风格、决策倾向、回话粒度都会有差异。在我设计的自动化工程系统提示词里角色定义通常包含三层内容身份定位、职责范围、汇报风格。身份定位是“你是一名资深自动化测试工程师精通pytest、playwright和接口测试”职责范围是“你只负责测试策略制定、用例生成与执行不负责代码修复”汇报风格是“每次任务结束以结构化摘要汇报结果不要长篇大论”。这三层分别约束了Agent的专业域、行动权和输出形态。不要小看“职责范围”这句话。AI模型默认情况下会“能帮就帮”你不划清边界它就会在测试失败时顺手去改业务代码或者把排查日志时看到的内网IP、密钥信息写进报告里。职责边界是系统提示词里的第一道安全阀。2.2 上下文注入把项目知识写进去而不是让Agent猜系统提示词的第二个要素是任务上下文。在自动化工程场景里上下文至少包含被测系统或目标环境的技术栈信息Java还是Python、用的什么框架、已有的工具链pytest版本、ansible的inventory路径、playwright的浏览器配置、关键路径或命名约定比如日志文件放在哪个目录、接口测试的公共host怎么配、以及历史任务中沉淀下来的“已知坑”。上下文注入有一个很关键的技巧要写“规则”不要写“百科”。你不需要告诉Agent“pytest是一个测试框架”你需要告诉它“在本项目中pytest只用于接口自动化UI自动化统一走playwright两者的用例目录分别是test_api/和test_ui/”。系统提示词的容量是有限的注入的知识越接近“项目约束”Agent的决策就越精准越不会在无关方向上浪费时间。2.3 工具接口描述告诉Agent它手里有什么牌AI自动化工程的核心是“Agent调度工具链”。系统提示词里必须有一块内容专门描述工具接口。我强烈建议把工具描述写成“何时调用核心参数返回结果格式”的三段式而不是简单列一个工具清单。举例来说工具名称run_pytest何时调用当任务涉及接口自动化测试执行、回归验证、用例筛选时调用核心参数test_path用例路径、mark标签筛选、record是否生成报告返回结果exit_code、passed、failed、error_log这样写的好处是Agent在规划任务时会自己去匹配“当前子任务该用哪个工具”而不是凭模型记忆瞎猜。很多Agent执行乱、工具调错根因就是系统提示词里的接口描述太模糊只写了“你可以使用pytest”但没写清楚pytest在本项目里是跑的哪套环境、哪个目录、哪份配置。2.4 输出协议让Agent的每一步都可解析、可追踪自动化工程系统提示词和普通聊天提示词最大的区别就是它后面往往接着编排系统、CI流水线、或者人工审批流程。所以Agent的输出必须遵守某种协议否则下游没法自动处理。我在系统提示词里会明确要求Agent在关键节点输出两种内容结构化状态和自然语言摘要。结构化状态用固定格式比如“TASK_IDxxx, STATUSRUNNING, CURRENT_STEP检查接口响应码”自然语言摘要则在任务结束时输出给人类查看。这个设计让各个环节都能从Agent的日志中拿到机器可读的信息同时保留人工可读的汇报内容。输出协议还需要配套一个“不确定性表达规则”。我会在系统提示词里写“当信息不足、工具返回异常、或者发现多个可能原因时必须清晰列出不确定点禁止用模糊推测替代事实描述。”这一条非常管用。它能让Agent在遇到模糊情况时主动暴露问题而不是编一个看起来很合理的答案。自动化工程里最贵的就是“看起来正常的错误结论”。2.5 约束与熔断没有边界的自动化就是事故现场系统提示词里最不能省的部分是约束和熔断策略。约束是“什么不能做”熔断是“什么情况下停止执行并上报”。我见过太多Agent在CI里反复失败重试、在生产环境乱跑命令、或者在遇到预期之外的报错时“自己发挥”搞出一套临时方案。这些问题的解法都不在模型侧而在系统提示词的约束侧。我常用的约束条款有这么几条禁止在生产环境执行无备份前提的变更操作工具执行失败时最多自动重试2次超过后必须上报涉及删除、重启、修改配置等危险操作必须输出操作预览并等待确认监控到资源占用异常、测试大面积失败或者日志中出现敏感信息时立即暂停任务并汇报。熔断策略我会专门写成一段“异常处置协议”核心思想是Agent的默认倾向是“完成任务”系统提示词的默认倾向必须是“保证不坏事”。两者平衡自动化系统才不会翻车。3. 系统提示词工程和Skill Agent到底有什么区别3.1 从一份提示词到一个Agent技能体系网上讨论“提示词工程Prompt Engineering”和“Skill Agent技能智能体”区别的内容很多很多人问。以我的实践经验来看两者不是递进关系而是两个不同层面的设计对象。系统提示词是Agent的“宪法”它定义了Agent整体的立场、行为基线、通用输出协议。Skill则是“专业能力包”它封装了某一个领域内的专项操作步骤、工具调用模板、注意事项和常见坑。一个Agent可以拥有多个Skill比如“pytest用例生成Skill”“ansible日志采集Skill”“playwright回归执行Skill”但它们都运行在同一个系统提示词底下。系统提示词管全局与共识Skill管局部与专项。3.2 为什么我建议把两者拆着设计拆开设计最大的好处是解耦与复用。如果所有规则都塞进一段系统提示词里改一个Skill的细节就得动整个Prompt风险很大。拆开后系统提示词保持稳定只维护全局规则具体的工具使用细节、特定场景的SOP不断往Skill里沉淀。我现在的方案是系统提示词全篇控制在800到1200字Skill单篇控制在300到600字Agent启动时按需加载。这样既保证了全局约束不被稀释也让专项能力可以持续迭代。下面这张表是我在设计Agent时常用来跟团队对齐认知的对比直接复制过去用就行对比维度系统提示词工程Skill Agent作用范围全局立场、安全边界、输出协议专项任务、领域步骤、工具模板复用粒度一个Agent对应一份核心提示词一个Agent可挂多个Skill更新频率低频稳定优先高频随业务场景演进调试方法修改后全局回归观察单点验证后灰度使用典型失效模式约束被后续对话稀释Skill内容与全局规则冲突在我做过的项目里最常见的系统性事故都不是模型不够聪明而是“Skill教了Agent怎么做事系统提示词却忘了教它什么不能做”。所以我的设计顺序永远是先搭全局约束再加专项技能。4. 一套可落地的AI自动化工程系统提示词模板4.1 模板全文可直接复制改下面这套模板我在多个自动化项目里改过、压过、验证过。你可以把它当成一个起点按自己的工具链和业务场景调整。它面向的是“既要做自动化测试又要做环境健康巡检、CI失败事件响应”的综合自动化工程Agent场景。你是本组织的AI自动化工程Agent负责自动化测试执行、环境巡检、CI失败事件响应与自动化脚本生成维护。 ## 职责范围 1. 你只负责自动化工程相关任务包括测试用例规划与执行、测试报告整理、环境指标巡检、CI失败初步定位。 2. 你不修改被测业务代码不直接变更生产配置所有涉及变更的操作必须先输出变更预览并等待最终确认。 3. 你在执行前必须拆分任务步骤并在状态输出中注明当前步骤。 ## 工具与调用规则 1. 你拥有以下工具run_pytest、run_playwright、run_ansible、read_logs、make_report。 2. 工具调用原则按任务类型选择工具不跨类使用调用前检查目标路径与参数工具返回非预期结果时以返回的实际结果为准。 3. 工具执行失败后允许在原有参数上微调重试1次再次失败停止该步骤并报告失败原因禁止绕过程序自行猜测执行。 ## 任务执行协议 1. 收到任务后先输出任务理解与执行计划计划内包含步骤编号、预期结果、涉及的工具。 2. 每一步执行后输出当前状态TASK_ID, STATUS, CURRENT_STEP, RESULT_SUMMARY。 3. 最终输出包含执行结论、关键数据、失败或风险点、建议后续动作。 4. 遇到信息不足或多种可能原因时明确列出不确定点禁止编造结论。 ## 安全与熔断规则 1. 禁止执行删除类命令除非收到明确的逐项删除确认。 2. 禁止对生产环境运行变更类操作除非变更预览已经人工确认。 3. 发现敏感信息密钥、内网地址、个人数据时在报告中打码展示并单独标注告警。 4. 测试大面积失败、环境指标严重异常、工具连续报错时立即暂停任务并输出告警摘要。4.2 为什么每个区块我这么写职责范围部分的三条解决的核心问题是“多管闲事”。模型天然乐意帮忙你若不声明“不修改业务代码、不做变更”它会在测试失败后顺手给你生成一段代码补丁或者在环境巡检时把一台机器重启了。职责范围写得越具体Agent的行为越克制。工具与调用规则部分重点在“重新执行/重试”的边界。一开始我没写重试条款实测中Agent遇到一次偶发网络超时就会反复调同一个接口几十次白白消耗时间和资源。加了“最多重试1次再次失败必须停止上报”之后这个现象基本绝迹。重试条款的本质是把“不撞南墙不回头”变成“撞一次就回头汇报”。任务执行协议部分是配套我前面说的输出协议来的。它的作用是让Agent不仅“做完事”还“每一步都留痕迹”。我接入CI系统调试过很多次发现只要Agent按协议输出了TASK_ID和STATUS下游的自动化流水线就能精确判断该等待、该跳过还是该告警完全不需要人工盯日志。安全与熔断规则部分我需要多说一句别觉得“我的Agent只是跑测试不会有危险”。我有一次让Agent排查测试环境数据库连接变慢的问题它居然打算去停掉一个数据库节点做验证幸亏系统提示词里写了“测试环境也不允许执行变更类操作除非预览已确认”。Agent的“动手能力”超出你的想象安全规则必须前置。4.3 模板调参经验五个关键调试维度把模板写完只是第一步真实落地还要调试。我一般按五个维度来验收任务理解度随机给10个不同领域的任务看Agent输出的执行计划是否准确对应任务类型如果跑偏多半是职责范围描述有歧义。工具选择准确度故意给一个“UI页面回归”任务看它是否调用playwright而不是pytest。选错说明工具调用规则描述不够场景化。失败处理合规度构造一个必失败的场景观察它是否遵守重试上限、是否乱改策略、是否如实上报。这里是系统提示词可靠性的核心测试点。输出可解析率用一个固定的结构化解析器去解析Agent的每一步输出如果解析失败率高说明输出协议写得不够紧需要给出更严格的格式示范。安全边界触发率设计几个越权操作指令比如“把服务器上日志文件删掉”“跳过确认直接改配置”看Agent是否拒绝或请求确认。触发率必须做到100%。我建议你按这个清单做一个验收表格每次修改系统提示词之后都回归一遍。这比你凭感觉测试要稳定得多也方便团队协作时对齐改动标准。5. 常见失败场景与排查技巧实录5.1 死循环式重试Agent卡在同一个步骤反复执行这个场景我遇到过太多次了。Agent在调用pytest执行接口用例时因为某个用例依赖的测试数据没准备好导致断言必失败。Agent的默认倾向是“试错并继续”于是它会一直重建数据、重跑用例、再失败直到把任务预算耗尽。排查时我的做法是在系统提示词里明确设置“失败原因分类逻辑”。要求Agent在工具执行失败后先做一个简短归类是环境问题、数据问题、脚本问题、还是断言逻辑问题。不同的类别对应不同的处置环境问题重试一次后上报数据问题可以尝试按已知流程准备数据脚本问题和断言逻辑问题必须停止并汇报给人类。这个分类逻辑大大减少了Agent的自旋时间。归根结底系统提示词要给Agent一套“失败时该怎么办”的决策树而不是简单说“失败了就重试”。5.2 上下文污染聊着聊着Agent忘了最开始的边界约束多轮对话是上下文稀释的高危场景。Agent在对话前半段表现得规规矩矩但在连续处理三四个任务之后可能就忘了自己“不修改业务代码”的边界开始主动给业务代码提建议甚至动手改。这不是模型故意犯错而是长上下文下远端的指令权重被后续内容覆盖了。有效的解法有两个。第一个是“关键规则周期性重注入”——在系统提示词里约定Agent每完成一个任务、进入下一个任务之前必须先复述一遍安全规则关键词比如“不修改业务代码、不执行未确认变更、失败两次即上报”。强制复述会激活模型对早期指令的注意力。第二个是“单任务隔离”——不要让Agent在同一个会话里跨任务长时间运行任务切换时重置上下文只保留必要的历史摘要。这两种方法实测都能显著降低上下文污染导致的越界行为。5.3 对话式直给输出导致下游解析失败很多系统提示词模板里写了“以JSON格式输出”但Agent就是会偶尔输出成Markdown代码块、夹杂解释性文字或者JSON里有注释。下游解析器一遇到这种输出就直接报错。我看过团队调试这种问题到凌晨两三点最后发现不是模型坏了是输出协议样例给得不够死。规矩是系统提示词中只要涉及输出格式除了写“必须输出JSON”还要给一个简短样例并且写明“只输出JSON对象本身不包含代码块标记不包含额外解释”。Agent对“格式样例”的遵循度远高于对“格式描述”的遵循度。另外我建议在编排层加一道“格式兜底”比如让Agent先输出再解析解析失败时把原内容送回Agent让它在保持内容不变的前提下只修正格式。这相当于给格式问题加了一个轻量级的自动修复回路。5.4 Agent编造“看起来很合理的执行结果”这是自动化工程系统提示词最需要防线的地方。Agent在调用工具时如果返回信息缺失、日志不全它有可能基于上下文推断出一个“合理结果”并在报告里写“测试全部通过”或者“服务状态正常”。这种结论一般很难触发人的警惕心因为它太像人写的总结了。我在系统提示词里专门加了一条“当工具未返回明确的通过标志时禁止直接使用‘通过/正常/成功’等结论性词汇必须输出UNKNOWN状态并附上已获取的证据片段。所有结论必须对应到一条具体的工具返回数据。”这条规则执行之后Agent输出里的模糊措辞明显减少。我也建议在人工复核时重点看报告里有没有“UNKNOWN”这个状态——它是Agent在不确定性面前选择老实交代的标志也是整个自动化系统可靠性的金丝雀。5.5 提示词版本变更导致Agent行为漂移最后分享一个管理层面的坑系统提示词改坏了Agent行为“悄悄变样”。有时候你只是觉得某个描述不够准确微调了两个字结果Agent在后续所有任务中的行为方式都跟预期对不上了。这就是系统提示词的“高敏感性”——它对措辞的敏感程度远超你写传统配置文件的直觉。我的建议是把系统提示词当代码一样管理。每次修改提交都跑一遍4.3里的五维验收清单发布前先让Agent处理一组固定的历史任务对比行为变化发现问题立刻回滚到上一版。这个流程不复杂但能把“提示词越改越乱、Agent越用越怪”这个大坑系统性地避掉。系统提示词不是写一次就完事的文档它是持续维护的工程资产。6. 我在实际项目里的几点体会这套系统提示词设计方法是我在好几个自动化工程里迭代出来的。第一次做完系统提示词时我误以为“给Agent一份清晰的说明”就够了后来被Agent的“自作主张”教育了无数次才慢慢把角色边界、输出协议、失败决策树这些概念一点点补进去。我个人最大的体会是AI自动化工程里的系统提示词本质上是在写一份“给AI的SOP 给人类的审计日志接口”。它的评价标准不是“看起来像不像专家”而是“Agent能不能在不确定的情况下仍然安全、可预测、可追踪地行动”。你可以允许Agent自主拆解步骤但你必须让它留下决策依据你可以授权Agent调用工具但你必须教会它失败时怎么停下。约束和信任的平衡点就是这套系统的性能上限。最后再分享一个实用小技巧把系统提示词里的“禁止项”数量控制在五个以内。太多了Agent记不住边界太多反而会在正常任务执行时畏手畏脚。你要做的不是列尽所有危险场景而是把最大风险场景的处置规则写透。剩下的靠编排层的权限管控和人工审批兜底比你在提示词里堆几百条禁忌要有效得多。
阅读完成 · 觉得有帮助？
