Agent提示词设计工程师

解决什么问题

把一段"效果好"的提示词直接推上生产，是常见的翻车姿势：换个输入、换个模型版本，输出就漂移了。这个技能要解决的核心问题，是提示词缺少工程化约束——没有分层结构、没有评估标准、没有针对幻觉的护栏，改一句措辞只能靠玄学复现。

它不教提示词"小技巧合集"，而是把提示词当作软件来工程化。

核心能力

分层的提示词架构：每个生产级提示词拆成四层——System 层定义角色与硬约束，Context 层注入背景数据，Task 层说明做什么、怎么做，Output 层用 JSON 等形式约定返回结构。

设计模式选型：按场景挑模式，而不是一路堆砌：

• Chain of Thought：复杂推理任务
• Few-shot：需要输出格式稳定时
• Structured output：下游要机器解析时
• Debate/Ensemble：降低幻觉风险，生成多个方案再互评择优
• Constraint injection：安全合规的红线
• Iterative refinement：最优提示词未知时，宽泛起步→测出缺口→加约束→重测

评估框架：六个维度把关，通过才上线——准确率（> 90%）、一致性（同输入跑 5 次语义相同）、鲁棒性（边界与对抗输入不崩）、安全性（红队测试下拒绝有害请求）、token 效率、格式合规（100% 可解析）。

防幻觉护栏：Source constraint 限定只依据给定上下文作答，不确定就说"不知道"；Confidence self-assessment 让模型自报置信度并说明理由；Multi-step verification 先列假设再逐条对数据核验。

多轮 Agent 行为设计：单条提示词之外，还给四种 Agent 模式——State machine（如客服：接入→诊断→解决）、Tool-use（搜索→分析→成文）、Reflection loop（起草→自审→修订）、Memory window（维护上下文记忆）。

适用边界

这套方法论针对的是文本交互的 Agent 与提示词系统，不替代模型选型、检索链路或工具调用的具体实现。它假设你能访问真实输入分布来做测试；拿不到线上流量时，评估结论的置信度有限。另外，文档中"生产提示词模板"一节留空，模板内容需按你的业务自行补齐。