dial-your-context

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dial Your Context

定制你的上下文

Help a user create the Instructions field content for the Sanity Context MCP server. The goal is a concise set of pure deltas — only information the agent can't figure out from the auto-generated schema.

帮助用户为Sanity Context MCP服务器创建Instructions字段内容。目标是生成一组简洁的纯增量信息——仅包含Agent无法从自动生成的schema中推断出的信息。

What you're building

你要构建的内容

The Sanity Context MCP server already provides the agent with:

A compressed schema of all document types and fields
A GROQ query tutorial (~194 lines)
Response style guidance
Tool descriptions for GROQ queries, semantic search, etc.

The Instructions field you're crafting gets injected as a

## Custom instructions

section between

## Response style

and

## Tools

in the MCP's instructions blob. It should contain only what the schema doesn't make obvious:

Counter-intuitive field names (e.g.,
```
body
```
is actually a slug,
```
hero
```
is a reference to
```
mediaAsset
```
)
Second-order reference chains the schema doesn't connect (e.g., "to find products with Dolby Atmos, chain
```
product → productFeature
```
and match on the feature's
```
id
```
field — the schema shows each hop but not the full path")
Data quality issues the schema can't reveal (e.g., "the
```
product
```
type has a
```
features
```
array but it's always empty — use
```
support-product
```
instead")
Required filters the agent must always apply (locale, draft status, etc.)
Known data gaps confirmed by the user (e.g., "the
```
subtitle
```
field is unused — ignore it")
Query patterns for common use cases that aren't obvious from the schema
Fallback strategies when primary approaches fail

Never duplicate what the schema already communicates clearly.

Sanity Context MCP服务器已为Agent提供以下内容：

所有文档类型和字段的压缩schema
GROQ查询教程（约194行）
响应风格指引
GROQ查询、语义搜索等工具的说明

你编写的Instructions字段会作为

## Custom instructions

部分注入到MCP指令blob中的

## Response style

和

## Tools

之间。它应仅包含schema无法明确体现的内容：

违反直觉的字段名称（例如
```
body
```
实际是slug，
```
hero
```
是对
```
mediaAsset
```
的引用）
schema未关联的二阶引用链（例如“要找到支持Dolby Atmos的产品，需关联
```
product → productFeature
```
并匹配功能的
```
id
```
字段——schema仅显示每个环节，但未展示完整路径”）
schema无法揭示的数据质量问题（例如“
```
product
```
类型有
```
features
```
数组，但始终为空——请改用
```
support-product
```
”）
Agent必须始终应用的必填过滤器（区域设置、草稿状态等）
用户确认的已知数据缺口（例如“
```
subtitle
```
字段未被使用——忽略它”）
schema无法体现的常见用例查询模式
主方法失败时的 fallback 策略

切勿重复schema已清晰传达的内容。

Prerequisites

前置条件

You need one of these to run this session:

Path A — Write access (recommended): A Sanity write token or the general Sanity MCP (OAuth). This lets you create a draft context doc, write instructions + filter to it during the session, and promote it to production when done. Production is never touched until you're ready.

Path B — URL params only: Use

?instructions=

and

?groqFilter=

URL query params on the MCP endpoint to test everything. At the end, provide the final content for the user to enter manually in Sanity Studio. Works with both base and document URLs.

Both paths are safe — neither modifies the production agent during the session.

运行此会话需要满足以下条件之一：

**路径A——写入权限（推荐）：**Sanity写入令牌或通用Sanity MCP（OAuth）。这允许你创建草稿上下文文档，在会话期间向其中写入指令和过滤器，并在完成后将其推广到生产环境。在准备就绪前，绝不会触及生产环境。

**路径B——仅使用URL参数：**在MCP端点上使用

?instructions=

和

?groqFilter=

URL查询参数进行测试。会话结束时，提供最终内容供用户手动输入到Sanity Studio中。适用于基础URL和文档URL。

两种路径均安全——会话期间均不会修改生产环境中的Agent。

Critical rules

关键规则

Pure deltas only. If the schema makes it obvious, don't put it in Instructions.
Never generalize from small samples. Querying 3 docs and concluding "field X is always null" is the #1 failure mode. Every claim must be verified with the user before inclusion.
The user knows their data. Schema dialogue beats data exploration. Present the schema, ask questions, listen.
Verify every claim with evidence. For each line in the draft Instructions, show the query + result that supports it. The user confirms or corrects.
Keep it concise and factual. The compaction step (summarizing findings into Instructions) is where information gets lost or distorted. No creative interpretation. Short declarative sentences.

仅保留纯增量信息。如果schema已明确体现，请勿放入Instructions中。
切勿从小样本中归纳结论。查询3个文档就断定“字段X始终为null”是最常见的失败模式。每条声明都必须经用户验证后才能纳入。
用户最了解自己的数据。与用户就schema进行对话胜过盲目探索数据。展示schema、提出问题、倾听用户反馈。
每条声明都需有证据验证。对于草稿Instructions中的每一行，都要展示支持它的查询及结果。由用户确认或纠正。
保持简洁且基于事实。压缩步骤（将发现总结为Instructions）是信息丢失或失真的高发环节。请勿进行创造性解读。使用简短的陈述性句子。

Workflow

工作流程

Step 1: Connect & Clean Slate

步骤1：连接并初始化

Goal: Establish MCP access, set up a safe working environment.

Connect to the user's Sanity Context MCP server. Get the project ID and dataset from the user if not already known. The slug is only needed if they have an existing Sanity Context document.

Set up your working environment:

Path A (write access): Create a new draft context doc by copying the existing one (if any) to a new slug like

tuning-draft

. All exploration and iteration happens against this draft — the production agent is untouched.

Path B (no write access): Use URL query params throughout the session:

```
?instructions=""
```
— forces a blank slate (ignores existing instructions)
```
?groqFilter=<expression>
```
— applies a filter without writing to the context doc

Check if the context document already has instructions content:

If yes, present the existing instructions to the user verbatim
Ask: "Do you want to keep any of this, or start fresh?"
Let the user decide — don't assume existing instructions are wrong
If they have existing instructions from a previous session, you'll verify and refine each finding rather than starting from scratch

Verify you can query the dataset by running a simple GROQ query like

*[0..2]._type

to confirm access.

Output: Confirmed MCP access, safe working environment established (draft doc or URL params), any existing instructions surfaced to user.

**目标：**建立MCP访问权限，设置安全的工作环境。

连接到用户的Sanity Context MCP服务器。如果尚未知晓，向用户获取项目ID和数据集。仅当用户已有Sanity Context文档时才需要slug。

设置工作环境：

**路径A（写入权限）：**通过复制现有文档（如有）创建新的草稿上下文文档，使用

tuning-draft

之类的新slug。所有探索和迭代都针对此草稿进行——生产环境的Agent不会受到影响。

**路径B（无写入权限）：**会话全程使用URL查询参数：

```
?instructions=""
```
——强制初始化空白状态（忽略现有指令）
```
?groqFilter=<expression>
```
——应用过滤器而无需写入上下文文档

检查上下文文档是否已有指令内容：

如果有，将现有指令原样展示给用户
询问：“你想要保留其中的部分内容，还是重新开始？”
由用户决定——不要假设现有指令有误
如果用户有来自之前会话的现有指令，你需要验证并优化每条发现，而非从头开始

通过运行简单的GROQ查询（如

*[0..2]._type

）确认可访问数据集。

**输出：**确认MCP访问权限，建立安全工作环境（草稿文档或URL参数），向用户展示所有现有指令。

Step 2: Schema Dialogue

步骤2：Schema对话

Goal: Understand the dataset through conversation, not just exploration.

Retrieve the schema (the MCP provides this). Present the document types to the user in a clear list:

Here are the document types in your dataset:
article
(14 fields)
author
(8 fields)
category
(5 fields)
...
Which of these are the ones your agent will need to work with?

This is a conversation, not a monologue. Ask the user:

Which types matter? "Which of these will your agent need to query? Any types here that are internal/system types the agent should ignore?"
What's misleading? "Any field names that don't mean what they sound like? Fields that are unused or deprecated?"
What are the relationships? "How do these types connect? For example, do articles reference authors? How — direct reference, array of references, something else?"
Any required filters? "Does the agent need to always filter by locale, published status, or any other field?"
What's the primary content language? If i18n is involved, clarify the pattern.

Suggest a filter. The MCP supports a

groqFilter

— a full GROQ expression that scopes which documents the agent can access. This is high-leverage — it reduces noise significantly and prevents the agent from querying irrelevant types.

The filter is a GROQ expression string, not just a type list. This means you can carve out exactly the document set you want:

Simple type filter:

_type in ["product", "support-article", "productFeature"]

Exclude drafts:

!(_id in path("drafts.**")) && _type in ["product", "article"]

Locale filter:

_type in ["product", "article"] && lang == "en-us"

Complex:

_type in ["product", "article"] && !(_id in path("drafts.**")) && defined(title)

Based on the conversation, propose a filter:

Based on what you've told me, I'd suggest this filter:
_type in ["article", "author", "category", "tag"]
This means the agent won't see
siteSettings
,
redirect
,
migration
, etc. Does that sound right?

Apply the filter immediately. Once the user agrees:

Path A (write access): Write the
```
groqFilter
```
field to the draft context doc
Path B (URL params): Add
```
?groqFilter=<expression>
```
to all subsequent MCP calls

All exploration from this point forward should use the agreed filter.

Output: A shared understanding of which types matter, known quirks, relationships, and an active filter. There's no point exploring types the production agent won't see.

**目标：**通过对话而非仅靠探索来理解数据集。

获取schema（由MCP提供）。以清晰列表的形式向用户展示文档类型：

以下是你的数据集中的文档类型：
article
（14个字段）
author
（8个字段）
category
（5个字段）
...
你的Agent需要处理其中哪些类型？

这是一场对话，而非独白。向用户询问：

哪些类型至关重要？“你的Agent需要查询哪些类型？这里面有没有Agent应忽略的内部/系统类型？”
哪些内容具有误导性？“有没有字段名称与其实际含义不符？有没有未使用或已弃用的字段？”
类型之间的关系是什么？“这些类型如何关联？例如，文章是否引用作者？是直接引用、引用数组还是其他方式？”
是否有必填过滤器？“Agent是否需要始终按区域设置、发布状态或其他字段进行过滤？”
**主要内容语言是什么？**如果涉及国际化，明确具体模式。

建议过滤器。MCP支持

groqFilter

——一个完整的GROQ表达式，用于限定Agent可访问的文档范围。这能大幅减少干扰，防止Agent查询无关类型，效果显著。

过滤器是GROQ表达式字符串，而非简单的类型列表。这意味着你可以精确筛选所需的文档集：

简单类型过滤器：

_type in ["product", "support-article", "productFeature"]

排除草稿：

!(_id in path("drafts.**")) && _type in ["product", "article"]

区域设置过滤器：

_type in ["product", "article"] && lang == "en-us"

复杂过滤器：

_type in ["product", "article"] && !(_id in path("drafts.**")) && defined(title)

基于对话内容，提出过滤器建议：

根据你告知的信息，我建议使用以下过滤器：
_type in ["article", "author", "category", "tag"]
这意味着Agent不会看到
siteSettings
、
redirect
、
migration
等类型。这样可以吗？

立即应用过滤器。用户同意后：

**路径A（写入权限）：**将
```
groqFilter
```
字段写入草稿上下文文档
**路径B（URL参数）：**在后续所有MCP调用中添加
```
?groqFilter=<expression>
```

此后的所有探索都应使用已确认的过滤器。

**输出：**达成关于关键类型、已知特殊情况、类型关系的共识，并启用过滤器。探索生产环境Agent不会访问的类型毫无意义。

Step 3: Expected Questions

步骤3：预期问题收集

Goal: Get concrete examples of what the production agent will be asked.

Ask the user:

What questions will people ask the agent that uses this context? Give me 5-20 examples — the more realistic, the better.

Examples might be:

"Which speakers support Dolby Atmos?"
"How do I fix WiFi connection issues?"
"What's the return policy for refurbished products?"
"Compare the features of product X and product Y"

These questions drive the exploration in Step 4. They tell you what query patterns actually matter.

For simple datasets, 5 questions is fine. For complex ones, push for 15-20.

Output: A numbered list of expected questions.

**目标：**获取使用此上下文的生产环境Agent会收到的具体问题示例。

向用户询问：

使用此上下文的Agent会收到哪些问题？请提供5-20个示例——越真实越好。

示例可能包括：

“哪些扬声器支持Dolby Atmos？”
“如何解决WiFi连接问题？”
“翻新产品的退货政策是什么？”
“比较产品X和产品Y的功能”

这些问题将驱动步骤4的探索，告诉你哪些查询模式才是真正重要的。

对于简单数据集，5个问题即可。对于复杂数据集，建议收集15-20个问题。

**输出：**编号列出的预期问题。

Step 4: Explore & Verify

步骤4：探索与验证

Goal: Answer each expected question using the MCP, track what works and what doesn't.

Steps 4–6 are iterative, not sequential. Verify findings with the user as you go. Don't explore 15 questions, draft everything, then discover half your claims don't hold up.

Work through the expected questions one by one (or in logical groups). For each question:

Write a GROQ query to answer it
Run the query via the MCP
Note the result — did it work? Was the data what you expected?
Track findings in a running list:
- ✅ Worked as expected (no instruction needed)
- ⚠️ Worked but required non-obvious pattern (instruction needed)
- ❌ Failed or returned unexpected results (investigate, then verify with user)

Critical: Do not assume. If a query returns empty results or unexpected data:

Do NOT conclude "this field is always empty" from a small sample
Instead, ask the user immediately — don't batch null-field findings: "When I query for X, I get Y. Is that expected? Is the data actually there?"
The user confirms or explains the discrepancy

Track your findings in a simple table:

# Question Query Result Finding

"Recent articles"

#	Question	Query	Result	Finding
1	"Recent articles"	`*[_type == "article"] \| order(publishedAt desc)[0..4]`	✅ 5 results	Works with schema alone
2	"Articles by author"	`*[_type == "article" && references(authorId)]`	⚠️ Empty	Authors linked via `contributors[].person` , not direct ref
3	"Published only"	`*[_type == "article" && status == "published"]`	❌ No `status` field	User confirms: use `!(_id in path("drafts.**"))` instead

*[_type == "article"] | order(publishedAt desc)[0..4]

✅ 5 results

Works with schema alone

"Articles by author"

*[_type == "article" && references(authorId)]

⚠️ Empty

Authors linked via

contributors[].person

, not direct ref

"Published only"

*[_type == "article" && status == "published"]

❌ No

status

field

User confirms: use

!(_id in path("drafts.**"))

instead

Adapt to scale:

Simple dataset (3-5 types, 5 questions): This step might take 10 minutes
Complex dataset (50 types, 20 questions): Group related questions, explore systematically, but still verify each finding

Output: A findings table with verified results for each expected question.

**目标：**使用MCP回答每个预期问题，记录有效和无效的情况。

步骤4–6是迭代过程，而非顺序执行。边探索边与用户验证发现。不要先探索15个问题、起草所有内容，然后才发现一半的声明不成立。

逐个（或按逻辑分组）处理预期问题。对于每个问题：

编写GROQ查询以回答问题
通过MCP运行查询
记录结果——是否有效？数据是否符合预期？
跟踪发现，形成动态列表：
- ✅ 符合预期（无需添加指令）
- ⚠️ 有效但需使用非直观模式（需添加指令）
- ❌ 失败或返回意外结果（调查后与用户验证）

关键：切勿假设。如果查询返回空结果或意外数据：

切勿从小样本中得出“此字段始终为空”的结论
应立即询问用户——不要批量处理空字段发现：“当我查询X时，得到了Y。这符合预期吗？数据实际存在吗？”
由用户确认或解释差异

使用简单表格跟踪发现：

#	问题	查询	结果	发现
1	“最新文章”	`*[_type == "article"] \| order(publishedAt desc)[0..4]`	✅ 返回5条结果	仅使用schema即可实现
2	“按作者查找文章”	`*[_type == "article" && references(authorId)]`	⚠️ 返回空结果	作者通过 `contributors[].person` 关联，而非直接引用
3	“仅显示已发布内容”	`*[_type == "article" && status == "published"]`	❌ 无 `status` 字段	用户确认：改用 `!(_id in path("drafts.**"))`

根据规模调整方式：

简单数据集（3-5种类型，5个问题）：此步骤可能耗时10分钟
复杂数据集（50种类型，20个问题）：将相关问题分组，系统地进行探索，但仍需验证每条发现

**输出：**包含每个预期问题验证结果的发现表格。

Step 5: Draft Instructions

步骤5：起草指令

Goal: Distill findings into concise, factual Instructions content.

Review the findings table from Step 4. Include only items marked ⚠️ or ❌ — things that required non-obvious patterns or failed with the obvious approach.

Write the Instructions as short, declarative statements organized by category:

markdown

undefined

**目标：**将发现提炼为简洁、基于事实的Instructions内容。

回顾步骤4的发现表格。仅包含标记为⚠️或❌的内容——即需要非直观模式才能实现，或使用直观方法失败的情况。

按类别将指令编写为简短的陈述性语句：

markdown

undefined

Rules

规则

Always filter drafts: use
```
!(_id in path("drafts.**"))
```
— there is no
```
status
```
field
Always include
```
[_lang == "en"]
```
for localized content unless user specifies otherwise

始终过滤草稿：使用
```
!(_id in path("drafts.**"))
```
——不存在
```
status
```
字段
除非用户指定，否则本地化内容始终包含
```
[_lang == "en"]
```

Schema notes

Schema说明

```
contributors
```
on
```
article
```
is an array of objects with a
```
person
```
reference to
```
author
```
— not a direct author reference
```
hero
```
on
```
article
```
is a reference to
```
mediaAsset
```
, not an image field
```
body
```
on
```
page
```
is a Portable Text array, not a string — use
```
pt::text(body)
```
for plain text search

```
article
```
的
```
contributors
```
是包含
```
person
```
引用（指向
```
author
```
）的对象数组——并非直接的作者引用
```
article
```
的
```
hero
```
是对
```
mediaAsset
```
的引用，而非图片字段
```
page
```
的
```
body
```
是Portable Text数组，而非字符串——使用
```
pt::text(body)
```
进行纯文本搜索

Query patterns

查询模式

Articles by author:

*[_type == "article" && contributors[].person._ref == $authorId]

Published articles by date:

*[_type == "article" && !(_id in path("drafts.**"))] | order(publishedAt desc)

按作者查找文章：

*[_type == "article" && contributors[].person._ref == $authorId]

按日期查找已发布文章：

*[_type == "article" && !(_id in path("drafts.**"))] | order(publishedAt desc)

Known limitations

已知限制

```
subtitle
```
field on
```
article
```
is unused — ignore it
```
relatedArticles
```
is manually curated and often empty for older content


**Keep it tight.** Each line should pass this test: "Would an agent with the schema alone get this wrong?" If you're unsure, test it — try answering 2-3 questions with `?instructions=""` and see what the model gets wrong on its own. That's your empirical baseline for what actually needs to be here. If no, cut it.

**Do not include:**

- General GROQ syntax (the tutorial covers this)
- Field lists or type descriptions (the schema covers this)
- Response formatting guidance (the response style section covers this)
- Anything the agent would figure out on its own

**Output:** A draft Instructions block, typically 10-40 lines depending on dataset complexity.

```
article
```
的
```
subtitle
```
字段未被使用——忽略它
```
relatedArticles
```
为手动维护，旧内容通常为空


**保持精简**。每一行都应通过以下测试：“仅拥有schema的Agent会在此处出错吗？”如果不确定，进行测试——使用`?instructions=""`尝试回答2-3个问题，看看模型自行处理时会在哪里出错。这是判断实际需要添加内容的实证基准。如果不会出错，就删除该行。

**请勿包含：**

- 通用GROQ语法（教程已涵盖）
- 字段列表或类型描述（schema已涵盖）
- 响应格式指引（响应风格部分已涵盖）
- Agent可自行推断的任何内容

**输出：**草稿Instructions块，根据数据集复杂度通常为10-40行。

Step 6: Verify Claims

步骤6：验证声明

Goal: Ensure every line in the draft is backed by evidence.

Go through the draft Instructions line by line. For each claim, show the user:

The claim: e.g., "contributors on article is an array of objects with a person reference"
The evidence: The GROQ query and result that demonstrates it
Ask for confirmation: "Is this accurate? Anything to add or correct?"

Example:

Claim: "Always filter drafts using
!(_id in path("drafts.**"))
— there is no status field"
Evidence:
*[_type == "article" && defined(status)][0..2]
→ 0 results.
*[_type == "article" && _id in path("drafts.**")][0..2]
→ 3 draft documents found.
Is this correct?

If the user corrects a claim, update the draft immediately.

If the user adds new information ("oh, and you should also know that..."), add it to the draft and verify it the same way.

Output: A verified Instructions block where every claim has been confirmed by the user.

**目标：**确保草稿中的每一行都有证据支持。

逐行检查草稿Instructions。对于每条声明，向用户展示：

**声明内容：**例如“article的contributors是包含person引用的对象数组”
**证据：**演示该声明的GROQ查询及结果
请求确认：“这是否准确？有没有需要补充或纠正的内容？”

示例：

声明：“始终使用
!(_id in path("drafts.**"))
过滤草稿——不存在status字段”
证据：
*[_type == "article" && defined(status)][0..2]
→ 返回0条结果。
*[_type == "article" && _id in path("drafts.**")][0..2]
→ 找到3份草稿文档。
这是否正确？

如果用户纠正了声明，立即更新草稿。

如果用户添加了新信息（“哦，你还应该知道……”），将其添加到草稿中并以相同方式验证。

**输出：**经过验证的Instructions块，其中每条声明都已得到用户确认。

Step 7: Deploy

步骤7：部署

Goal: Get the Instructions and filter into production safely.

Present the final Instructions content and filter to the user for one last review:

Here's the final configuration:

Filter (GROQ expression):
_type in ["article", "author", "category", "tag"]
Instructions: [final instructions block]

Ready to deploy?

Path A (write access):

Write the
```
instructions
```
and
```
groqFilter
```
fields to the draft context doc
Verify by querying the draft MCP endpoint — confirm the instructions appear in
```
## Custom instructions
```
Promote to production: Either update the production context doc's
```
instructions
```
and
```
groqFilter
```
fields to match, or update the production agent's MCP URL to point to the new slug
Verify the production endpoint serves the correct instructions

Path B (no write access):

Provide the final MCP URL with all params baked in:

https://api.sanity.io/vX/context/mcp/{project}/{dataset}/{slug}?instructions=<URL-encoded>&groqFilter=<URL-encoded>

Also provide the raw content separately for the user to paste into their Sanity Context document in Sanity Studio:
- Instructions field: [final instructions block]
- Filter field: [GROQ expression]
- Location: Sanity Studio → Sanity Context document → Instructions / Filter fields

After deployment, verify: Query the production MCP endpoint and confirm the instructions and filter are active.

Output: Instructions and filter live in production, verified working.

**目标：**将Instructions和过滤器安全部署到生产环境。

向用户展示最终的Instructions内容和过滤器，进行最后一次审核：

以下是最终配置：

过滤器（GROQ表达式）：
_type in ["article", "author", "category", "tag"]
Instructions： [最终指令块]

是否准备部署？

路径A（写入权限）：

将
```
instructions
```
和
```
groqFilter
```
字段写入草稿上下文文档
通过查询草稿MCP端点进行验证——确认指令出现在
```
## Custom instructions
```
中
**推广到生产环境：**要么更新生产环境上下文文档的
```
instructions
```
和
```
groqFilter
```
字段使其与草稿一致，要么更新生产环境Agent的MCP URL指向新slug
验证生产环境端点提供正确的指令

路径B（无写入权限）：

提供包含所有参数的最终MCP URL：

https://api.sanity.io/vX/context/mcp/{project}/{dataset}/{slug}?instructions=<URL编码内容>&groqFilter=<URL编码内容>

同时提供原始内容，供用户粘贴到Sanity Studio中的Sanity Context文档：
- Instructions字段：[最终指令块]
- 过滤器字段：[GROQ表达式]
- 位置：Sanity Studio → Sanity Context文档 → Instructions / Filter字段

**部署后验证：**查询生产环境MCP端点，确认指令和过滤器已生效。

**输出：**Instructions和过滤器已在生产环境中生效，并验证可用。

Adaptation guidelines

适配指南

This workflow scales to any dataset size:

Small dataset (3-5 types, 5 questions):

Step 2 might be a 2-minute conversation
Step 4 might find zero non-obvious patterns
Final Instructions might be 5 lines or even empty (which is fine — it means the schema is self-explanatory)

Large dataset (50+ types, 20 questions):

Step 2 needs more structure — group types by domain area
Step 3 is critical — without good questions, you'll explore aimlessly
Step 4 should group related questions to avoid redundant exploration
Final Instructions might be 30-40 lines with multiple sections

The filter matters more for large datasets. A 50-type dataset where the agent only needs 8 types benefits enormously from a filter.

此工作流程可适配任何规模的数据集：

小型数据集（3-5种类型，5个问题）：

步骤2可能只需2分钟对话
步骤4可能未发现任何非直观模式
最终Instructions可能只有5行，甚至为空（这是好事——说明schema自解释性强）

大型数据集（50+种类型，20个问题）：

步骤2需要更结构化的方式——按领域对类型进行分组
步骤3至关重要——没有合适的问题，探索会漫无目的
步骤4应将相关问题分组，避免重复探索
最终Instructions可能有30-40行，包含多个章节

过滤器对大型数据集更重要。对于包含50种类型但Agent仅需处理8种的数据集，过滤器能带来极大收益。

Anti-patterns to avoid

需避免的反模式

Don't explore without the user. Running 50 queries silently and presenting a wall of findings is overwhelming and error-prone. Explore interactively.
Don't assume from samples. "I checked 3 articles and none had a subtitle" ≠ "subtitle is unused." Ask the user.
Don't duplicate the schema. "The article type has fields: title, body, author, publishedAt..." — the agent already knows this.
Don't write prose. Instructions should be scannable bullet points, not paragraphs.
Don't over-engineer. If the dataset is simple and the schema is clear, the Instructions might be 3 lines. That's a success, not a failure.
Don't skip verification. Every claim needs evidence + user confirmation. This is the quality gate.

不要脱离用户自行探索。静默运行50次查询并向用户展示大量发现会让用户不知所措且容易出错。应进行交互式探索。
不要从样本中假设结论。“我检查了3篇文章，都没有subtitle”≠“subtitle未被使用”。应询问用户。
不要重复schema内容。“article类型包含以下字段：title、body、author、publishedAt……”——Agent已知晓这些信息。
不要编写冗长 prose。指令应是易于扫描的项目符号，而非段落。
不要过度设计。如果数据集简单且schema清晰，Instructions可能只有3行。这是成功，而非失败。
不要跳过验证。每条声明都需要证据+用户确认。这是质量把关环节。

Session state tracking

会话状态跟踪

Throughout the session, maintain a mental model of:

- [ ] MCP access verified
- [ ] Working environment set up (draft context doc or URL params)
- [ ] Existing instructions reviewed (if any)
- [ ] Schema discussed with user
- [ ] Filter agreed and applied
- [ ] Expected questions collected
- [ ] Questions explored and findings tracked
- [ ] Draft instructions written
- [ ] Each claim verified with evidence
- [ ] Instructions deployed to production
- [ ] Production deployment verified

This checklist is your progress tracker. Share it with the user periodically so they know where you are in the process.

在会话全程，需维持以下心理模型：

- [ ] 已验证MCP访问权限
- [ ] 已设置工作环境（草稿上下文文档或URL参数）
- [ ] 已审核现有指令（如有）
- [ ] 已与用户讨论schema
- [ ] 已确认并应用过滤器
- [ ] 已收集预期问题
- [ ] 已探索问题并跟踪发现
- [ ] 已起草指令
- [ ] 每条声明都已通过证据验证
- [ ] 已将指令部署到生产环境
- [ ] 已验证生产环境部署

此检查表是你的进度跟踪器。定期与用户分享，让他们了解当前所处的流程阶段。