shape-your-agent

塑造你的 Agent

一种可选的对话式工作流，用于为使用 Sanity Context MCP 服务的 AI Agent 创建系统提示词。适用于在 Agent 设置中能够控制系统提示词的用户。

无法访问系统提示词？ 完全跳过此技能即可。Instructions 字段（通过 dial-your-context 技能配置）是主要调节手段，单独使用也能奏效。在我们的评估中，简洁的系统提示词（例如“你是一个乐于助人的 Agent。”）配合内容完善的 Instructions 字段，得分可达 80% 以上。

开始之前

系统提示词的用途

系统提示词定义 Agent 的行为——它是谁、如何交流、拒绝做什么。可以把它看作 Agent 的个性说明和行为准则。

系统提示词不负责什么

以下内容由其他部分处理——不要重复编写：

关注点	由以下部分处理
内容架构、字段含义	Instructions 字段（Dial Your Context）
查询模式、数据关系	Instructions 字段（Dial Your Context）
GROQ 语法与指导	MCP 自动提供

在系统提示词中重复编写这些内容会造成冲突。MCP 和 Instructions 字段专为数据相关事项设计——让它们各司其职。

黄金法则：少即是多

系统提示词中的每一行都在与 MCP 提供的上下文争夺模型的注意力。过度设计的提示词实际上会降低回答质量。从精简开始。只有在遇到需要明确规则的具体场景时，才添加规则。

---

如何进行本次交流

这是一次对话，不是一份表格。提出问题，倾听回答，并灵活调整。不要把步骤当作清单逐项执行——根据用户的回答判断哪些方面需要深入探讨。有些用户对语气有明确看法，可能需要花 5 分钟讨论边界。另一些用户则需要帮助梳理边缘情况，但已经清楚自己想要的表达风格。顺着交流节奏进行。

---

步骤 1：了解使用场景

先回答以下问题：

1. 谁会使用这个 Agent？（客户、内部团队、开发者、公众）
2. 使用场景是什么？（支持聊天、文档网站、内部工具、销售助手）
3. 它要解决什么问题？（回答产品问题、排查问题、查找内容）
4. 用户通常处于什么状态？（探索中、遇到障碍、评估中、感到沮丧）

这些答案将影响后续的每一项决策。面向沮丧客户的支持 Agent，需要的规则与面向开发者的文档助手不同。

步骤 2：定义行为

在每个维度上做出明确选择：

语气： 专业 / 随意 / 友好 / 技术性

• 不佳：“友好而专业”
• 良好：“语气亲切，称呼用户的名字。不要使用企业套话。像一位知识渊博的同事那样写，而不是像新闻稿。”

详略程度： 默认提供多少细节？

• 不佳：“简洁但全面”
• 良好：“先用 1-2 句话回答。主动询问是否需要展开说明。切入重点前，开头绝不超过 3 句话。”

技术水平： 与受众相匹配。

• 不佳：“根据用户的水平调整”
• 良好：“假设用户了解 JavaScript 和 REST API。不要解释什么是 API 密钥。要解释 GROQ 投影等 Sanity 特有的概念。”

格式： MCP 不会告诉 Agent 如何排版，因此这项工作由系统提示词负责。

• 不佳：“把回复排版得整洁”
• 良好：“使用简短段落。只有在比较三个或更多项目时才使用项目符号列表。每次提及产品时，都链接到对应的源页面。”

步骤 3：设定边界

对于每条边界，你都需要：规则、触发场景和期望的回应。

拒绝什么：

• 示例：“如果有人要求你在数据集中撰写或修改内容，请说明你是只读助手，并引导他们联系内容管理员。”

将什么转交给他人：

• 示例：“对于账单或账户问题，请说：‘我可以帮你解答产品问题，但账单相关问题请联系 [email protected]。’”

护栏：

• 示例：“绝不提及竞争产品的名称。如果有人要求比较，请在不提及其他产品的情况下描述我们的能力。”
• 示例：“不要引用具体价格。请说：‘如需了解当前套餐，请查看我们的定价页面 [url]。’”

未找到信息时：

• 示例：“如果查询没有返回结果，请如实说明。建议 2～3 个你可以帮忙解答的相关主题。绝不编造答案。”

删减测试： 对每条规则，都要问：“我能否描述一条真实的用户消息来触发这条规则？” 如果不能，就删掉这条规则。无法触发的规则只会徒增负担。

步骤 4：起草提示词

将你的回答整理成提示词。使用以下结构：

You are [role] for [company/product].

## Voice
[2-3 concrete tone/style rules]

## Boundaries
[Only rules that passed the cut test]

## When you don't know
[Specific fallback behavior]

就这样。大多数 Agent 在这里需要 200～400 个词，而不是 1,500 个。

示例：电商支持 Agent

You are a customer support agent for Acme Store.

## Voice
- Warm and conversational. Use the customer's first name if provided.
- Keep answers short — lead with the answer, then explain if needed.
- No marketing language. Don't upsell or promote products unprompted.

## Boundaries
- Never process returns, refunds, or order changes. Direct customers to [email protected] for order issues.
- Don't quote exact shipping times. Say "typically 3-5 business days" and link to the shipping policy page.
- If asked about competitor products, focus on what Acme offers without comparisons.
- Don't share internal inventory numbers. Say whether something is "in stock" or "currently unavailable."

## When you don't know
- Say "I don't have that information" directly. Don't hedge or speculate.
- Suggest related topics you can help with.
- For urgent issues, direct to live support at [email protected].

这段约 150 个词。它涵盖了角色、语气、边界和备用处理方式。其他内容——产品数据、架构细节、查询模式——则放在 Instructions 字段和 MCP 中。

步骤 5：审查并迭代

使用真实场景测试你的提示词：

1. 编写 5～10 个用户实际会提出的问题。 至少包含 2 个边缘情况（偏离主题的问题，以及你希望拒绝的问题）。
2. 为每条边界规则编写一个会触发它的问题。验证 Agent 能否正确处理。
3. 逐条尝试移除规则。 如果移除某条规则后 Agent 的表现依然正确，那这条规则就是多余的。删掉它。
4. 检查是否与 Instructions 字段冲突。 如果系统提示词和 Instructions 字段都涉及同一问题，请从系统提示词中删除相关内容。涉及数据的问题以 Instructions 字段为准。

提示词过长的迹象

• Agent 忽略部分规则（注意力被稀释）
• 回答显得泛泛或像套话（限制过多）
• Agent 原样重复提示词中的措辞（鹦鹉学舌）

提示词过短的迹象

• Agent 在不同对话中的语气不一致
• 用户得到了本应拒绝回答的问题的答案
• 本该说“我不知道”时，Agent 却开始猜测

---

快速参考

系统提示词检查清单

• 用一句话定义角色
• 语气规则具体明确（而不是“保持专业”）
• 每条边界都包含触发场景
• 明确规定备用处理方式
• 与 Instructions 字段内容不重叠
• 少于 500 个词（目标为 200～400 个）
• 使用 5 个以上真实用户问题进行测试

分层原则

层级	控制内容	示例
System prompt	Agent 行为	“绝不引用确切价格”
Instructions field	数据说明	“price 以美分存储；换算成美元时除以 100”
MCP	查询机制	GROQ 语法、工具用法
System prompt	表达不确定性	“说‘我没有这方面的信息’，并建议其他选择”
Instructions field	恢复策略	“如果产品搜索没有结果，请尝试搜索支持文章类型”

每一层都有自己的职责。不要混为一谈。