TrueFoundry 是一个云无关、Kubernetes 原生的企业级 AI 平台，包含两个可独立采用的产品，二者共享部分实体与约定。使用前需先确认用户询问的是哪个产品，再路由到相应部分。
一、AI Engineering（又称 TrueFoundry Deployment） 用途：在客户自有的 Kubernetes 集群上部署与运行各类工作负载。 主要能力：部署 Services、Async Services、Jobs、Notebooks、SSH Servers、Workflows、Helm charts 和 Volumes；管理 ML Repos、Model Registry、制品、训练与微调。 实体层级：Cluster → Workspace → Application，RBAC 在集群和工作区级别强制执行。 参考文件（位于 ai-engineering/references/）覆盖：从 git 仓库或本地代码部署、从预构建镜像部署、Helm chart 部署、模型部署（HuggingFace、模型目录、NIM（vLLM、SGLang 等）或经典 ML）、Notebook/RStudio/SSH Server 部署、各部署路径共享规则、自动扩缩容与 scale-to-0 及成本优化、网络（端点、粘性会话、SSL/自定义域名、连通性）、密钥、发布策略（金丝雀、蓝绿）、模型服务原理、集群接入、构建日志等。
二、AI Gateway 用途：作为 LLM 提供商、MCP 服务器和智能体之前的代理层。 主要能力：治理、访问控制、速率/预算限制、护栏、可观测性、缓存、提示词管理和虚拟模型。 实体：Models、Virtual Models、MCP Servers、Virtual MCP Servers、Guardrail Integrations。Models/Virtual Models/Guardrails 以 model_id（格式 {accountName}/{integrationName}）标识；MCP Servers（含 Virtual）以租户内唯一的名称标识。 策略：Rate Limiting、Budget Limiting、Guardrails Config、Load Balancing（已弃用，改用 Virtual Models）。
三、全局操作原则 不凭记忆作答：平台 API、schema、支持的模型变化快，且客户租户状态唯一且实时，需先通过工具获取当前状态；文档未确认的内容应明确说明。回答前始终调用 search_docs；不详细解释功能，而是链接到规范文档页；不主动提供最佳实践或提示。 apply_manifest 是所有实体（Gateway 与 AI Engineering）的写入路径，与所有创建/更新/删除工具一样经过用户审批流程。只读工具可从沙箱调用。禁止在终端运行 tfy apply。从源码部署是例外：构建针对平台无法访问的本地克隆，使用 build_source: local 和 tfy deploy；预构建镜像和 Helm charts 走 apply_manifest。 禁止展示占位符 URL（包括 {gatewayBaseURL}、{controlPlaneUrl} 等模板标记），需调用相应工具（get_me 获取 controlPlaneUrl，list_gateway_installations 获取 gateway base URL）并替换为实际值。
四、清单工具 validate_manifest 与 apply_manifest 输入相同：清单包裹在顶层 manifest 键下，即 {"manifest": {<the manifest>}}。始终先验证再应用，二者不可并行调用，需等待 valid: true。delete_manifest 需在 body 中同时提供 type 和 name。参考文件中的 YAML 需转换为 JSON 后再调用。失败时：validate_manifest 失败则读错误、修复、重新验证；apply_manifest 出错则向用户展示错误；持续或不明错误时阅读 references/support-tickets.md 并提供提交工单选项，不得静默重试或放弃。
五、文档工具 search_docs 用于查找相关文档页；get_section_content 用于从已知文档 URL 提取特定信息。
六、歧义引用解析 “My/I/Mine”指当前用户而非租户，调用 get_me 解析身份后按用户 subject slug 过滤。实体名称常被缩写、拼错或部分匹配，需先在系统中查找再假设不存在。Gateway 语境下“Application/App/Use-Case”通常指 Virtual Account（或较少见的 x-tfy-metadata 键）。API Key/Token 需同时呈现两种类型并推荐 VAT：Personal Access Token（PAT，绑定用户，用于开发/测试）与 Virtual Account Token（VAT，绑定非人类身份，用于生产/CI/CD，推荐）。Caching 需区分 Gateway Caching（网关级策略，语义+精确匹配）与 Provider Caching（提供商侧提示词缓存）。
七、常见概念 Integrations 通过 Provider Accounts 连接外部服务（AWS、GCP、Azure、GitHub 等）。FQN 不可猜测或手动构造：租户 FQN 为租户名（来自 get_me 的 tenantName），其余先列出实体再使用响应中的 fqn 字段。Secrets 存于 Secret Groups，以 FQN 引用：tfy-secret://<owner>:<secret-group>:<secret-key>，平台运行时解析。存在两个不同的 base URL：controlPlaneUrl（来自 get_me，用于构造平台链接）与 Gateway base URL（来自 list_gateway_installations，用于所有 Gateway API 交互），均不可猜测或硬编码。
八、Gateway 写入工作流 调用 get_me 获取身份与 controlPlaneUrl；调用 get_manifest_json_schema 获取实体实际 schema；用 ask_user_question 收集必需输入；需要时先获取现有状态（网关配置需先 get_gateway_config 并合并规则，Budget Limiting V2 例外，每条规则独立，用 list_gateway_budgets 读取）；按 schema 严格构造 JSON 清单，每个网关配置清单必须包含顶层 name 字段（不在 schema 中但 apply_manifest 需要）；先 validate_manifest 再 apply_manifest（幂等，同名更新而非重复创建；用户要求“创建”时须用新唯一名称）；用 controlPlaneUrl 展示相关页面链接。
九、协作者 支持协作者的实体（models、virtual models、guardrails、MCP servers）必须设置：以 get_me 当前用户为 manager，添加 team:everyone 为 access。每个协作者含 role_id 与 subject（user:<email> 或 team:<team-name>）。role_id 按实体类型查表：Provider Accounts/Models、Virtual Models、Guardrail Config Groups 的 manager 为 provider-account-manager、access 为 provider-account-access；MCP Servers 的 manager 为 mcp-server-manager、access 为 mcp-server-user。这些 role_id 是静态平台常量，无需调用 list 工具查询。
十、创建后链接与可观测性 apply_manifest 成功后展示相关页面（如模型提供商账户 /llm-gateway/models?provider={providerName}、虚拟模型 /llm-gateway/virtual-models、MCP 服务器 /llm-gateway/mcp-servers、速率限制 /llm-gateway/settings?configTab=rate-limiting、预算规则 V2 /llm-gateway/settings?configTab=budget-limiting-v2、护栏配置组 /guardrails/registry、团队 /access-management?tab=teams 等）。追踪与指标深链可追加 ?filters=<url-encoded-json>，JSON 格式为 {"rules":[{"field":"<fieldName>","value":"<value>","operator":"<op>"}]}，常用字段有 traceId、userEmail、modelName、teamName，操作符有 IN、STRING_CONTAINS。基础路径为 {controlPlaneUrl}/monitoring/request-traces 与 {controlPlaneUrl}/monitoring/metrics?monitorTab=metrics&viewBy=modelName。
十一、回答 Gateway 问题前的检查清单 是否先阅读了实体的参考文件；是否对概念性问题调用 search_docs；是否先按名称查找实体；是否分析查询数据后再下结论；答案是否引用观察/数据；是否调用 list_gateway_installations/get_me 并替换所有 URL 中的真实值（无占位符）；无法回答时是否阅读 references/support-tickets.md 并遵循而非建议外部联系。
十二、适用场景与限制 适用场景：企业 AI 平台相关的问答与操作，包括在自有 Kubernetes 上部署与运行 AI 工作负载、管理模型与制品、以及为 LLM/MCP/智能体提供网关治理、访问控制、限额、护栏与可观测性。 限制：平台变化快，不可凭记忆作答，需实时通过工具获取状态；写入操作需用户审批；部分功能（如 Load Balancing）已弃用；具体收费、价格、平台支持范围等资料未提供。