shape-your-agent

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Shape 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 the
dial-your-context
skill) 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.
这是一个可选的对话式工作流,用于为使用Sanity Agent Context MCP的AI Agent创建系统提示词,仅适用于在Agent配置中有权限控制系统提示词的用户。
无法修改系统提示词? 完全跳过这个Skill即可。指令字段(通过
dial-your-context
Skill配置)是核心控制项,本身即可独立生效。在我们的评估中,搭配优质的指令字段内容,即使是类似“你是一个有用的助手”这样的极简系统提示词也能达到80%以上的效果。

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:
ConcernHandled by
Content schema, field meaningsInstructions field (Dial Your Context)
Query patterns, data relationshipsInstructions field (Dial Your Context)
GROQ syntax and guidanceMCP auto-provides
Response formatting rulesMCP 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:
  1. Who uses this agent? (customers, internal team, developers, general public)
  2. What setting? (support chat, docs site, internal tool, sales assistant)
  3. What problem does it solve? (answer product questions, troubleshoot issues, find content)
  4. 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.
先回答以下问题:
  1. 谁会使用这个Agent?(客户、内部团队、开发者、普通公众)
  2. 使用场景是什么?(客服聊天、文档站点、内部工具、销售助理)
  3. 它要解决什么问题?(解答产品问题、排查故障、查找内容)
  4. 用户的典型状态是什么?(探索了解、遇到问题、评估选型、情绪烦躁)
这些答案会指导后续所有决策:为烦躁的客户服务的客服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:
  1. Write 5-10 questions your users would actually ask. Include at least 2 edge cases (something off-topic, something you want refused).
  2. For each boundary rule, write the question that triggers it. Verify the agent handles it correctly.
  3. Try removing rules one at a time. If the agent still behaves correctly without a rule, that rule was unnecessary. Cut it.
  4. 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.
用真实场景测试你的提示词:
  1. 写出5-10个用户真实会问的问题,至少包含2个边界场景(离题的问题、你希望被拒绝的请求)。
  2. 针对每一条边界规则,写出会触发它的问题,验证Agent可以正确处理。
  3. 尝试逐条删掉规则,如果删掉某条规则后Agent仍然可以正常表现,说明这条规则是多余的,删掉它。
  4. 检查是否和指令字段内容冲突,如果系统提示词和指令字段都定义了同一项内容,从系统提示词中删掉,数据相关的规则以指令字段为准。

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

分工原则

LayerControlsExample
System promptAgent behavior"Never quote exact pricing"
Instructions fieldData guidance"Products are in the 'product' type with a 'price' field"
MCPQuery mechanicsGROQ syntax, response formatting
System promptCommunicating uncertainty"Say 'I don't have that information' and suggest alternatives"
Instructions fieldRecovery tactics"If product search returns empty, try support-article type"
Each layer has its job. Don't cross the streams.
层级负责内容示例
系统提示词Agent行为「永远不要引用具体定价」
指令字段数据指引「产品存储在
product
类型中,包含
price
字段」
MCP查询逻辑GROQ语法、响应格式化
系统提示词不确定性沟通「回复「我没有相关信息」并推荐替代内容」
指令字段兜底查询策略「如果产品搜索返回空结果,尝试查询support-article类型」
每个层级都有自己的职责,不要交叉混用。