很多人第一次接触 Agent 开发时，容易把重点放在模型能力上：模型够不够强、参数够不够大、回答够不够聪明。但真正开始做应用后会发现，Agent 能不能稳定完成任务，很大程度取决于提示词工程。
提示词不是简单地“问一句话”，而是给 Agent 写一份清晰的工作说明书。一个好的提示词，应该告诉它目标是什么、上下文是什么、可以使用哪些工具、遇到问题如何判断、输出结果应该长什么样，以及哪些事情不能做。
在普通聊天场景里，我们可以随意提问。但在 Agent 场景里，模型往往要连续执行多个步骤，比如读取资料、分析问题、调用工具、生成结果、检查错误。这个过程越复杂，提示词就越需要结构化。否则 Agent 很容易出现跑偏、遗漏步骤、输出格式不稳定等问题。
做提示词工程，第一步是明确任务目标。比如不要只写“帮我分析服务器问题”，而应该写清楚：“请根据日志判断服务异常原因，优先排查 CPU、内存、磁盘、网络和应用报错，并给出可执行的处理建议。”目标越明确，Agent 的行动空间越清晰。
第二步是补充上下文。Agent 并不知道你的业务背景，也不知道你更关心什么。如果你希望它站在运维视角分析，就要说明；如果你希望它面向非技术读者解释，也要说明。上下文不是越多越好，而是要提供对判断有帮助的信息。
第三步是设定边界。Agent 很适合辅助分析和执行，但不能让它无限发挥。比如在涉及生产环境时，可以要求它“先给出风险判断，不直接执行破坏性操作”；在生成内容时，可以要求它“不写广告口吻，不夸大效果，不虚构数据”。这些约束能显著降低不可靠输出。
第四步是规定输出格式。很多 Agent 应用需要把模型结果交给后续流程处理，如果输出格式不稳定，就会影响系统集成。可以要求它按照“问题摘要、原因分析、处理建议、风险提示”的结构输出，也可以要求它返回 JSON、Markdown 表格或固定字段。格式越稳定，Agent 越容易被产品化。
还有一个容易被忽略的点：提示词要让 Agent 学会“先判断，再行动”。比如当信息不足时，不要强行给结论，而是列出缺失信息；当存在多个可能原因时，要说明优先级；当操作有风险时，要先提醒风险。这类规则能让 Agent 更像一个可靠助手，而不是一个只会快速回答的聊天机器人。
在实际开发中，提示词通常不是一次写完的，而是不断迭代出来的。你可以先写一个基础版本，然后用真实案例测试，看它是否遗漏步骤、是否误解任务、是否输出不稳定。每发现一个问题，就把规则补充进提示词里。这个过程类似调试代码，只不过调试对象从程序逻辑变成了模型行为。
一个实用的提示词结构可以包含六部分：角色、目标、背景、工具、约束、输出格式。角色决定 Agent 的视角，目标决定它要完成什么，背景提供判断依据，工具说明它能做什么，约束控制风险，输出格式保证结果可用。
比如做一个云服务器运维 Agent，可以这样设计：你是一名云服务器运维助手，负责分析用户提供的监控数据和日志；请先判断异常类型，再给出排查顺序；不要直接建议重启或删除数据，除非已经说明风险；输出包含现象、可能原因、验证方法和处理建议。这样的提示词，比一句“帮我看看服务器怎么了”可靠得多。
提示词工程的核心，不是追求神奇的句式，而是把任务说清楚，把边界定清楚，把结果规范清楚。它更像产品设计、流程设计和风险控制的结合。
Agent 开发真正难的地方，也不只是让模型回答正确，而是让它在复杂任务中持续稳定地做正确的事。提示词工程就是这个稳定性的起点。写好提示词，Agent 才能从“能回答问题”走向“能完成任务”。
