1、怎样组织提示词，才能让要求更清楚？
大模型训练阶段的数据中包含有大量的结构化内容，因此他对结构化输入展现了显著的敏感性。
1.1 用Markdown标题划分内容
这在保证可读性的同时也提供了轻量级的结构，适合组织层次化的指令和信息。#、##这类标题会让人一眼看出层次结构，可读性好，也便于检查哪些规则出现问题。
1.2 用标签区分规则、背景与待处理数据
以XML标签为例，标签的使用同样遵循层次化原则，况且其标签名本身就携带语义信息（比如 <working_directory> 能立即告诉模型这是工作目录信息 ）他的好处就是语义精确，模型处理起来更准确，负责机器可解析的精确语义。
两者配合使用示例
2、从规则堆砌到流程驱动
如果给模型一个包含上千行零散规则的提示词，同时也没有优先级区分，那么模型在多条规则同时适用的时候该如何抉择呢，在已有规则未覆盖的情况下又该如何处理？
针对以上问题，流程驱动的提示词就是一个很好的解决方法，他给模型提供了清晰地执行标准。
流程化的设计能让模型在任何时候都能清晰自己处在哪个阶段 、当前步骤的目标是什么 、完成后该进入哪个步骤。就算遇到异常情况，模型也能根据当前所处的阶段确定处理方式，就省去了完整遍历所有规则的开销。
3、怎么把模糊要求变成明确的业务规则？
进行生产级Agent系统开发时，最关键的环节就是业务规则的细化 ，同时这也是最容易被忽略的地方。此处需要产品经理的深度参与，产品经理必须将决策规则明确到可执行的程度，模糊的规则会让Agent行为极其不稳定。
这么做的原理就是：大语言模型优势在于遵循复杂指令和从上下文中提取信息，但不应该在业务规则制定上被赋予太多的自由裁决权。
4、什么时候需要Few-shot示例？
当期望模型的输出难以用规则精确描述 （比如某种特定的风格、结构化报告的格式、回复语气的分寸）直接使用两至三个优质输入-输出示例会比堆砌冗长的文字定义来的实在。模型会借助上下文学习能力从示例中临时学习这些模式，但是同样的，对于模型本身就擅长、规则又容易说清楚的任务，示例只会额外增加token的消耗。
（1）示例放在哪里
可以放在系统提示词 中，示例作为静态前缀（往期文章有说明）的部分，对所有的请求生效。也可以伪造一组user/assistant消息（消息列表）放在首轮对话中，适合于按照会话类型选用不同示例集的场景。
（2）示例对 KV Cache 前缀稳定性的影响
无论将示例放在哪个位置，示例都要处于上下文靠前的区域，一旦确定好就要保证字节级稳定。通常为每类任务准备固定的示例集，而不是按照请求动态检索（每次都改写前缀，缓存会持续失效）最相关的示例。
两三个精心选择的能覆盖边界情况的示例即可，太多的示例会占用上下文的空间，还会稀释模型对规则本身的注意力。
5、系统提示词和工具定义怎样配合？
系统提示词说明整体工作要求，工具定义说明具体工具怎么使用。工具定义的质量直接决定了Agent使用工具的准确性，近期以来，工具定义本身也逐渐向渐进式披露演进 ，具体表现是静态前缀里只保留工具的名称和简述 ，完整的schema在模型按需请求后追加到上下文末尾，成为轨迹的一部分。值得注意的是，追加到末尾只发生在工具被发现的那一轮，不是说每轮都被重新搬运到最新的末尾，此后这个schema块就固定在轨迹的原位置，后续的多轮新消息追加在他后面，他自身就成为了普通的历史信息。