shape-your-agent
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseShape Your Agent
打造你的Agent
An optional, conversational workflow for creating a system prompt for an AI agent that uses the Sanity Agent Context MCP. This is for users who control the system prompt in their agent setup.
Don't have access to the system prompt? Skip this skill entirely. The Instructions field (configured via theskill) is the primary lever and works on its own. A minimal system prompt like "You are a helpful agent." combined with good Instructions field content scores 80%+ in our evaluations.dial-your-context
这是一个可选的对话式工作流,用于为使用Sanity Agent Context MCP的AI Agent创建系统提示词,仅适用于在Agent配置中有权限控制系统提示词的用户。
无法修改系统提示词? 完全跳过这个Skill即可。指令字段(通过Skill配置)是核心控制项,本身即可独立生效。在我们的评估中,搭配优质的指令字段内容,即使是类似“你是一个有用的助手”这样的极简系统提示词也能达到80%以上的效果。dial-your-context
Before You Start
开始之前
What the system prompt is for
系统提示词的作用
The system prompt defines agent behavior — who it is, how it talks, what it refuses to do. Think of it as the agent's personality and policy manual.
系统提示词定义Agent的行为模式——它的身份定位、沟通方式、拒绝处理的事项,可以理解为Agent的人格设定和行为准则手册。
What the system prompt is NOT for
系统提示词不负责的内容
These are handled elsewhere — don't duplicate them:
| Concern | Handled by |
|---|---|
| Content schema, field meanings | Instructions field (Dial Your Context) |
| Query patterns, data relationships | Instructions field (Dial Your Context) |
| GROQ syntax and guidance | MCP auto-provides |
| Response formatting rules | MCP auto-provides |
Duplicating these in the system prompt creates conflicts. The MCP and Instructions field are purpose-built for data concerns — let them do their job.
以下内容由其他模块处理,不要在系统提示词中重复定义:
| 内容项 | 负责模块 |
|---|---|
| 内容Schema、字段含义 | 指令字段(Dial Your Context) |
| 查询模式、数据关联关系 | 指令字段(Dial Your Context) |
| GROQ语法和使用指引 | MCP自动提供 |
| 响应格式规则 | MCP自动提供 |
在系统提示词中重复定义上述内容会引发冲突。MCP和指令字段是专门为数据相关需求设计的,请交由它们处理对应逻辑。
The golden rule: less is more
黄金准则:少即是多
Every line in your system prompt competes for the model's attention with the context the MCP provides. An over-engineered prompt can actually degrade answer quality. Start minimal. Add rules only when you have a concrete scenario that needs one.
系统提示词中的每一行内容都会和MCP提供的上下文竞争大模型的注意力,过度设计的提示词反而会降低回答质量。从极简版本开始,仅在遇到明确需要处理的具体场景时再添加规则。
How to run this session
如何开展本次会话
This is a conversation, not a form. Ask questions, listen to the answers, and adapt. Don't run through the steps as a checklist — let the user's responses guide which areas need more depth. Some users will have strong opinions about tone and need 5 minutes on boundaries. Others will need help thinking through edge cases but already know their voice. Follow the energy.
这是一场对话,不是填写表单。你可以提出问题、倾听反馈、灵活调整。不要把步骤当成核对清单机械执行,要根据用户的反馈判断哪些部分需要更深入的讨论:有些用户对语气风格有明确要求,可能需要花5分钟讨论行为边界;另一些用户已经明确了Agent的沟通风格,只需要协助梳理边界场景。跟随用户的需求调整即可。
Step 1: Understand the Use Case
步骤1:理解使用场景
Start by answering these questions:
- Who uses this agent? (customers, internal team, developers, general public)
- What setting? (support chat, docs site, internal tool, sales assistant)
- What problem does it solve? (answer product questions, troubleshoot issues, find content)
- What's the user's typical state? (exploring, stuck, evaluating, frustrated)
These answers drive every decision that follows. A support agent for frustrated customers needs different rules than a docs assistant for developers.
先回答以下问题:
- 谁会使用这个Agent?(客户、内部团队、开发者、普通公众)
- 使用场景是什么?(客服聊天、文档站点、内部工具、销售助理)
- 它要解决什么问题?(解答产品问题、排查故障、查找内容)
- 用户的典型状态是什么?(探索了解、遇到问题、评估选型、情绪烦躁)
这些答案会指导后续所有决策:为烦躁的客户服务的客服Agent,和为开发者服务的文档助手需要的规则完全不同。
Step 2: Define Behavior
步骤2:定义行为模式
Choose concrete positions on each axis:
Tone: Professional / Casual / Friendly / Technical
- Bad: "Be friendly and professional"
- Good: "Use a warm, first-name tone. No corporate jargon. Write like a knowledgeable coworker, not a press release."
Verbosity: How much detail by default?
- Bad: "Be concise but thorough"
- Good: "Lead with a 1-2 sentence answer. Offer to elaborate. Never open with more than 3 sentences before getting to the point."
Technical level: Match the audience.
- Bad: "Adjust to the user's level"
- Good: "Assume the user knows JavaScript and REST APIs. Don't explain what an API key is. Do explain Sanity-specific concepts like GROQ projections."
为以下每个维度选择明确的定位:
语气风格: 专业/随意/友好/技术向
- 反面示例:「保持友好且专业」
- 正面示例:「使用温暖的、称呼对方名字的语气,不要使用企业话术,写作风格像知识丰富的同事,不要像新闻通稿。」
表达详略: 默认输出的内容详细程度?
- 反面示例:「简洁但全面」
- 正面示例:「开头先给出1-2句话的答案,主动询问用户是否需要进一步解释,切入主题前的铺垫永远不要超过3句话。」
技术适配度: 匹配目标受众的技术水平
- 反面示例:「根据用户的水平调整表述」
- 正面示例:「默认用户了解JavaScript和REST API,不需要解释API密钥是什么,需要解释Sanity特有的概念,比如GROQ投影。」
Step 3: Set Boundaries
步骤3:设定行为边界
For each boundary, you need: the rule, a trigger scenario, and the desired response.
What to refuse:
- Example: "If asked to write or modify content in the dataset, explain that you're a read-only assistant and point them to the Sanity Studio."
What to redirect:
- Example: "For billing or account questions, say: 'I can help with product questions, but for billing please contact support@example.com.'"
Guardrails:
- Example: "Never mention competitor products by name. If asked to compare, describe our capabilities without naming alternatives."
- Example: "Don't quote specific pricing. Say 'Check our pricing page at [url] for current plans.'"
When information isn't found:
- Example: "If the query returns no results, say so honestly. Suggest 2-3 related topics you can help with. Never fabricate an answer."
The cut test: For every rule, ask: "Can I describe a real user message that would trigger this?" If not, cut the rule. Untriggerable rules are dead weight.
每个边界规则都需要包含:规则本身、触发场景、预期响应三部分。
需要拒绝的请求:
- 示例:「如果用户要求编写或修改数据集中的内容,说明你是仅提供查询功能的助手,并引导用户使用Sanity Studio。」
需要引导的请求:
- 示例:「遇到账单或账户相关问题,回复:「我可以帮你解答产品相关问题,账单相关问题请联系support@example.com。」
防护规则:
- 示例:「永远不要提及竞品的名称,如果被要求对比产品,只描述我们的能力,不提及其他竞品。」
- 示例:「不要引用具体的定价信息,回复「请访问我们的定价页面[url]查看当前套餐信息」。」
未找到信息时的处理:
- 示例:「如果查询没有返回结果,如实告知用户,同时推荐2-3个你可以提供帮助的相关主题,永远不要编造答案。」
删减测试: 对每一条规则,问自己:「我能举出一个会触发这条规则的真实用户提问吗?」如果不能,就删掉这条规则。无法触发的规则只会成为无效冗余。
Step 4: Draft the Prompt
步骤4:起草提示词
Assemble your answers into a prompt. Use this structure:
You are [role] for [company/product].将你整理的答案组合成提示词,使用以下结构:
You are [role] for [company/product].Voice
Voice
[2-3 concrete tone/style rules]
[2-3条明确的语气/风格规则]
Boundaries
Boundaries
[Only rules that passed the cut test]
[仅保留通过删减测试的规则]
When you don't know
When you don't know
[Specific fallback behavior]
That's it. Most agents need 200-400 words here, not 1500.[具体的兜底行为]
就这么简单,大多数Agent的系统提示词只需要200-400词,不需要1500词。Example: E-commerce Support Agent
示例:电商客服Agent
You are a customer support agent for Acme Store.You are a customer support agent for Acme Store.Voice
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.
- 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
Boundaries
- Never process returns, refunds, or order changes. Direct customers to support@acme.com 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."
- Never process returns, refunds, or order changes. Direct customers to support@acme.com 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
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 support@acme.com.
This is ~150 words. It covers role, voice, boundaries, and fallback behavior. Everything else — product data, schema details, query patterns — lives in the Instructions field and MCP.- 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 support@acme.com.
这个提示词只有约150词,涵盖了角色、语气、边界和兜底行为。其他所有内容——产品数据、Schema详情、查询模式——都放在指令字段和MCP中。Step 5: Review & Iterate
步骤5:测试与迭代
Test your prompt against real scenarios:
- Write 5-10 questions your users would actually ask. Include at least 2 edge cases (something off-topic, something you want refused).
- For each boundary rule, write the question that triggers it. Verify the agent handles it correctly.
- Try removing rules one at a time. If the agent still behaves correctly without a rule, that rule was unnecessary. Cut it.
- Check for conflicts with the Instructions field. If both the system prompt and Instructions field address the same concern, remove it from the system prompt. The Instructions field wins for data concerns.
用真实场景测试你的提示词:
- 写出5-10个用户真实会问的问题,至少包含2个边界场景(离题的问题、你希望被拒绝的请求)。
- 针对每一条边界规则,写出会触发它的问题,验证Agent可以正确处理。
- 尝试逐条删掉规则,如果删掉某条规则后Agent仍然可以正常表现,说明这条规则是多余的,删掉它。
- 检查是否和指令字段内容冲突,如果系统提示词和指令字段都定义了同一项内容,从系统提示词中删掉,数据相关的规则以指令字段为准。
Signs your prompt is too long
提示词过长的信号
- The agent ignores some rules (attention dilution)
- Answers feel generic or templated (over-constrained)
- The agent repeats phrasing from the prompt verbatim (parroting)
- Agent会忽略部分规则(注意力分散)
- 回答感觉很通用、像模板(约束过度)
- Agent会逐字重复提示词里的表述(机械复读)
Signs your prompt is too short
提示词过短的信号
- The agent's tone is inconsistent across conversations
- Users get answers to questions that should be refused
- The agent speculates when it should say "I don't know"
- Agent在不同对话中的语气不稳定
- 用户本应被拒绝的问题也得到了回答
- 本该说「我不知道」的时候,Agent会编造内容
Quick Reference
快速参考
System prompt checklist
系统提示词检查清单
- Role is defined in one sentence
- Tone rules are concrete (not "be professional")
- Every boundary has a trigger scenario
- Fallback behavior is specified
- No overlap with Instructions field content
- Under 500 words (aim for 200-400)
- Tested against 5+ real user questions
- 用一句话定义了角色
- 语气规则是明确可落地的(不是「要专业」这类模糊表述)
- 每一条边界规则都有对应的触发场景
- 明确了兜底行为
- 和指令字段内容没有重叠
- 字数少于500词(目标200-400词)
- 用5个以上的真实用户问题测试过
The separation principle
分工原则
| Layer | Controls | Example |
|---|---|---|
| System prompt | Agent behavior | "Never quote exact pricing" |
| Instructions field | Data guidance | "Products are in the 'product' type with a 'price' field" |
| MCP | Query mechanics | GROQ syntax, response formatting |
| System prompt | Communicating uncertainty | "Say 'I don't have that information' and suggest alternatives" |
| Instructions field | Recovery tactics | "If product search returns empty, try support-article type" |
Each layer has its job. Don't cross the streams.
| 层级 | 负责内容 | 示例 |
|---|---|---|
| 系统提示词 | Agent行为 | 「永远不要引用具体定价」 |
| 指令字段 | 数据指引 | 「产品存储在 |
| MCP | 查询逻辑 | GROQ语法、响应格式化 |
| 系统提示词 | 不确定性沟通 | 「回复「我没有相关信息」并推荐替代内容」 |
| 指令字段 | 兜底查询策略 | 「如果产品搜索返回空结果,尝试查询support-article类型」 |
每个层级都有自己的职责,不要交叉混用。