Provisioning 会读取你现有的材料，并将其转化为引擎配置。最影响结果的一个决定，就是你在请求的 sources 数组里放了什么——因为最终返回的引擎质量，只会和你提供的来源一样好。
每个条目都属于两种类型之一。link 来源是平台替你抓取并爬取的 URL；content 来源则是你直接传入的原始文本或 markdown。两者可以在同一个请求中混合使用，总数最多十个来源。本页会说明这两种类型、平台分别如何处理它们，以及怎样挑选来源，产出真正有用的配置，而不是一个几乎空白的结果。sources 字段本身位于创建请求中——完整 payload 和 202 响应请参见 创建 provisioning 作业。
两种来源类型#
每个来源都是一个对象，包含 type 和 payload。其中 type 决定平台如何读取 payload。
| 类型 | 内容 | 适合在这种情况下使用 |
|---|---|---|
link | 待爬取的 URL | 当上下文已经在网上时——比如你的品牌页面、公开文档、已发布的风格指南或术语表页面。 |
content | 原始文本或 markdown | 当上下文只存在于你的脑海里或私有文档中时——比如术语清单、语气规则、产品命名规范，以及翻译时该做和不该做的事项。 |
{
"sources": [
{ "type": "link", "payload": "https://acme.com/brand-guidelines" },
{ "type": "link", "payload": "https://acme.com/docs/style-guide" },
{
"type": "content",
"payload": "Brand name 'Acme' is never translated. Use formal tone in German (Sie-form). Product names: AcmeFlow, AcmeSync, AcmeVault - always keep in English."
}
]
}同一个数组里放两个链接和一个内容块。链接指向已经包含所需上下文的页面；内容块则承载那些没有公开写出来的规则。两者都会进入同一个提取步骤。
平台会如何处理这两种来源#
两种类型只在一个环节上不同——如何把文本交到 AI 代理面前——之后流程就一致了。
link 来源会先被抓取并转换成 markdown，再进入分析。平台会并行爬取链接来源，所以十个 URL 并不意味着十次串行往返——而是同时读取，再统一作为文本交给代理。你只需要提供 URL；抓取以及从 HTML 精简为 markdown 的工作由平台完成，这样代理读到的是正文，而不是页面标记。
content 来源则会跳过这一步。你发送的文本会按原样直接传给 AI 代理。没有爬取，没有转换，你的文字和代理之间没有任何中间环节——这也是为什么内容来源是表达已知规则最精确的方式。
从这里开始，两种来源都会变成同一种输入：代理会读取全部内容，并提取品牌语气、术语表条目和指令。它会从这些文本中产出什么，以及返回的摘要包含什么，是另一个话题——请参见 AI 会提取什么。
链接会爬到多深？
link 来源会在代理分析前先被抓取并转换成 markdown。至于爬虫是否会继续跟进你提供的 URL 之外的链接，以及会跟进到多深，这里并没有说明。如果你需要分析一组明确的页面，最稳妥的做法是把每一页分别列成独立的 link 来源，而不是依赖单个 URL 自行扩散。
选择真正有信号的来源#
这一步决定 provisioning 值不值得跑。提取结果的上限就是输入质量，而这里的问题往往很隐蔽：即使来源很弱，作业照样会完成，照样会创建引擎——只是得到的可能是一个几乎空白的引擎。你通常要等到后面发现翻译忽略了那些你以为已经被捕捉到的约定，才会意识到问题。完成通知也会像平常一样送达——参见 Webhook 投递——所以系统不会主动替你标出这个缺口。
提供有价值的来源
提取配置的质量，取决于输入的质量。链接来源应指向包含有效上下文的页面——品牌指南、风格指南、产品文档、术语表。原始内容来源则应包含明确的术语、语气指引或翻译规则。泛泛而谈的营销页面或登录界面，通常提不出多少有用配置。
这个提示背后的规律是：代理提取的是明确写出来的内容，不是暗含的意思。一个写着“我们使用友好、直接的德语语气，使用 Sie，绝不使用 Du”的页面，可以产出品牌语气；一个列出“workspace → Arbeitsbereich”的术语表页面，可以产出术语表条目。相反，一个虽然很好地体现了语气、却没有明确写出任何规则的精致落地页，几乎提不出什么内容，因为页面上没有可直接抽取的规则。拿不准时，优先选择把规则明确说出来的来源——很多时候，这会是你自己写成一句话的 content 内容块，而不是一个你希望代理自行推断的页面。
单个薄弱来源不会拖垮整个作业#
当你一次提交多个来源时，一个很自然的问题是：如果某个 URL 失效，或某个内容块信息太少，整个请求会不会失败？不会。每个来源都会被独立读取，单项失败会被记录，但不会导致整体失败——失效链接或无法读取的内容块会被跳过，代理会基于它成功读到的内容继续工作。只有在所有来源都无法读取、完全没有内容可供分析时，整个作业才会失败。这些结果的具体形式——成功时记录的单项失败，以及所有内容都无法读取时返回的失败 payload——请参见 AI 会提取什么 和 Webhook 投递。
所以，你可以先把一组候选来源都列出来，而不必提前核查每一个 URL：强来源会贡献结果，弱来源会自然掉队，而你只需要查看输出摘要，就能知道最终实际纳入了什么。先把你已有的内容指给它——再看看它返回了什么。
