QVeris vs Portkey
Capability Routing Above the Model GatewayQVeris 与 Portkey：模型网关之上的能力路由
Portkey controls and observes traffic to model providers. QVeris helps an agent discover, inspect, and call the external capability that completes a real-world task. They belong in one stack when both inference and action need governed evidence.
Portkey 控制并观测发往模型供应商的流量；QVeris 帮助智能体发现、检查并调用完成现实任务所需的外部能力。当推理与行动都需要受治理证据时，两者应位于同一技术栈中。
TL;DR
Use its gateway layer for provider credentials, configs, routing, retries, fallbacks, caching, limits, guardrails, and inference observability.
Use Discover → Inspect → Call to find external APIs, tools, data, and services, examine contracts and signals, then execute a verified capability.
A good model response is not an executed business action; a callable API does not choose or govern the model that reasoned about the task.
Carry one workflow trace from model decision to capability search, contract inspection, invocation, billing, and final result.
用网关层管理供应商凭证、配置、路由、重试、回退、缓存、限额、护栏与推理可观测性。
通过 Discover → Inspect → 调用找到外部 API、工具、数据与服务，检查契约和信号，再执行已验证能力。
高质量模型回答不等于已执行的业务动作；可调用 API 也不会选择或治理完成推理的模型。
用同一工作流调用链连接模型决策、能力搜索、契约检查、调用、计费与最终结果。
The boundary is model decision versus real-world action边界在于模型决策与现实行动
Portkey is an AI gateway and control suite. Its official product surface covers universal model access, gateway configs, retries, fallbacks, load balancing, caching, limits, guardrails, logs, traces, analytics, prompts, and administration.
Portkey 是 AI 网关与控制套件。其官方产品面覆盖统一模型访问、网关配置、重试、回退、负载均衡、缓存、限额、护栏、日志、追踪、分析、提示词与管理。
QVeris is a capability routing network. Its workflow starts with natural-language intent, returns ranked capabilities, exposes schemas and signals for inspection, and calls the selected API or tool with execution evidence. That is downstream of model inference.
QVeris 是能力路由网络。其工作流从自然语言意图开始，返回排序后的能力，展示结构定义与信号供检查，再调用所选 API 或工具并留下执行证据；这一层位于模型推理之后。
QVeris vs Portkey side by sideQVeris 与 Portkey 并排比较
| Decision surface决策面 | QVeris | Portkey |
|---|---|---|
| Primary object主要对象 | External capability: API, tool, service, or live data外部能力：API、工具、服务或实时数据 | Model request, provider, route, and policy模型请求、供应商、路由与策略 |
| Core flow核心流程 | Discover → Inspect → Call发现 → 检查 → 调用 | Authenticate → route → guard → observe认证 → 路由 → 护栏 → 观测 |
| Decision signals决策信号 | Capability match, schema, success, latency, region, cost and policy能力匹配、结构定义、成功率、延迟、区域、成本与策略 | Provider/model availability, price, latency, config, budget and guardrail供应商/模型可用性、价格、延迟、配置、预算与护栏 |
| Evidence IDs证据 ID | Search, execution, session and downstream resultSearch、Execution、会话与下游结果 | Request, trace, config, model, provider, usage and guardrail result请求、调用链、Config、模型、供应商、用量与护栏结果 |
| Typical owner典型负责人 | Agent platform and workflow engineering智能体平台与工作流工程 | AI platform, security and model infrastructureAI 平台、安全与模型基础设施 |
| Failure question故障问题 | Why did the agent choose or fail to execute this capability?智能体为什么选择或未能执行该能力？ | Why did this model request route, fail, retry, or cost this amount?模型请求为何这样路由、失败、重试或产生该成本？ |
Use both when the agent must reason and act智能体既要推理又要行动时同时使用
Standardize model provider access, traffic behavior, safety checks, budgets, and runtime evidence across applications.
Let agents find appropriate real-world capabilities, inspect contracts and operational signals, and call them under a controlled execution record.
Portkey owns the model route; QVeris owns capability selection. Do not let two systems independently retry the same downstream action.
跨应用统一模型供应商访问、流量行为、安全检查、预算与运行证据。
让智能体找到合适的现实能力、检查契约和运行信号，并在受控执行记录下调用。
Portkey 负责模型路由，QVeris 负责能力选择；不要让两个系统独立重试同一个下游动作。
A clean two-layer production architecture清晰的双层生产架构
Send the user task through Portkey to the selected model, preserve its trace and policy context, then pass the agent intent into QVeris Discover. Inspect the candidate contract, cost and reliability signals before Call. Append search_id, execution_id, schema version, result, latency and billed amount to the same workflow envelope.
先让用户任务通过 Portkey 到达所选模型并保留调用链与策略上下文，再把智能体意图交给 QVeris Discover。在调用前检查候选能力的契约、成本和可靠性信号，并把 search_id、execution_id、结构定义版本、结果、延迟和计费金额写入同一工作流封装。
Architecture rule: model retries may be automatic; side-effecting capability calls require explicit idempotency and action-level retry policy.
架构规则：模型重试可以自动化；有副作用的能力调用必须具备显式幂等性和动作级重试策略。
An end-to-end stack proof端到端技术栈验证
- Replay representative model prompts, tool plans, structured outputs, capability searches, inspections, and calls.
- Force provider failure, model timeout, empty capability search, schema mismatch, downstream 429, and partial action failure.
- Verify one trace explains model selection, capability ranking, policy decisions, retries, usage, cost, and final business result.
- Require idempotency keys, approval boundaries, credential isolation, and rollback evidence for side-effecting calls.
- Reconcile Portkey model usage with QVeris execution billing and the downstream provider receipt.
- 回放代表性的模型提示、工具计划、结构化输出、能力搜索、检查与调用。
- 强制触发供应商故障、模型超时、能力搜索为空、结构定义不匹配、下游 429 与部分动作失败。
- 验证单一调用链能解释模型选择、能力排序、策略决策、重试、用量、成本与最终业务结果。
- 对有副作用的调用要求幂等键、审批边界、凭证隔离与回滚证据。
- 核对 Portkey 模型用量、QVeris 执行计费与下游供应商回执。
Integrate through a neutral workflow envelope通过中立工作流封装集成
Do not make either vendor's request object the system of record. Define your own task ID, trace ID, actor, tenant, policy version, model evidence, capability evidence, approval state, budget, result, and audit timestamps. Add Portkey and QVeris adapters behind that contract, then canary by workflow.
不要把任一供应商的请求对象当作系统记录。定义自己的 Task ID、调用链 ID、Actor、租户、策略版本、模型证据、能力证据、审批状态、预算、结果和审计时间戳；在该契约后接入 Portkey 与 QVeris 适配器，再按工作流灰度。
QVeris is the action layer, not another model gatewayQVeris 是行动层，不是另一个模型网关
The combined design is deliberate: Portkey makes model traffic reliable and governed; QVeris makes external capability selection and invocation inspectable. Use shared trace context, but keep separate policy scopes and retry semantics.
组合设计应是有意为之：Portkey 让模型流量可靠且受治理，QVeris 让外部能力选择与调用可检查。二者共享调用链上下文，但策略范围与重试语义应保持分离。
FAQ
No. It discovers, inspects, and calls external capabilities such as APIs, tools, services, and live data. A model gateway governs inference traffic.
Yes. Keep model selection in the gateway and capability selection in QVeris, then propagate trace, session, policy, and cost evidence across both.
Implement the bottleneck that blocks production, but define the shared evidence envelope before either layer becomes hard to replace.
Model route, provider, policy version, usage, QVeris search and execution IDs, chosen capability, schema version, estimated cost, result, and errors.
不是。QVeris 负责发现、检查并调用 API、工具、服务和实时数据等外部能力；模型网关负责治理推理流量。
可以。模型选择留在网关，能力选择交给 QVeris，并在两层之间传递调用链、会话、策略与成本证据。
先解决阻塞生产的瓶颈，但应在任一层难以替换之前定义共享证据封装。
模型路由、供应商、策略版本、用量、QVeris Search/Execution ID、所选能力、结构定义版本、预估成本、结果与错误。