QVeris
接入我正在用的 AI

竞品对比与选型

面向 AI Agent 的最佳 Toolhouse 替代方案

筛选 Toolhouse 方案，并核对工具发现、鉴权与执行职责。

查找 AI Agent 工具运行对比评估 Prompt

发布日期： · QVeris团队制作

本文目录
评估工作流中的金融研究场景；图片仅作场景示意，不代表产品界面或基准测试。

TL;DR：只替换真正需要替换的层

直接结论

如果要替换业务团队使用的数字员工，可优先评估 Unify、Lindy 与 Relevance AI；如果团队自己维护代码和状态，可评估 LangGraph + LangSmith Deployment 与 Mastra；如果只替换 Tools、MCP、认证和外部能力访问，而保留现有编排，则比较 Composio、Arcade、Pipedream Connect 与 QVeris。不要把九个产品放进同一排行榜，因为它们替换的是 Toolhouse 的不同部分。

整套 Worker

平台负责触发器、工作流、业务上下文、执行动作和用户操作界面。

Agent Runtime

团队拥有 Agent 代码，平台提供持久执行、状态、队列、API 与部署。

Tools + MCP

保留现有 Runtime，只替换能力发现、认证、Tool 执行或集成基础设施。

混合架构

用 Runtime 管理状态和审批，再接入一个能力供应商处理外部动作与数据。

2026 年的 Toolhouse：先建立公平基线

Toolhouse 不能只被描述成 Tool 市场。其当前文档将产品定位为 Agent Backend-as-a-Service：既可以用代码定义 Agent 并发布为 API，也覆盖 AI Worker、定时任务、异步运行、运行上下文、RAG、Memory、代码执行、浏览器使用、公共与自定义 MCP、经过审核的 Tool Store、评估、Prompt 优化和可观测性。

层Toolhouse 基线替代方案需要证明
WorkerWorker、定时任务、面向业务的自动化非开发者能操作、暂停、检查并恢复任务。
Runtime代码定义 Agent、API 发布、流式与异步运行、Run ID状态可跨重试、部署、超时和人工暂停保持。
能力Tool Store、MCP、RAG、Memory、Browser、代码执行认证、Schema、错误、输出限制与副作用都可明确控制。
控制面日志、评估、Prompt 优化和用量控制运营人员可从请求追踪到模型与 Tool 证据。

这很重要：一个 Tools 产品可能是优秀组件，但仍不是完整的 Toolhouse 替代品。正确问题不是“集成是否更多”，而是“哪些 Toolhouse 职责被迁移、哪些保留、缺口由谁负责”。

前置步骤：画清替换边界

盘点当前契约

列出 Worker、Agent 定义、Prompt、Schedule、Run ID、Memory、RAG、Tool、MCP、Secret、审批、Callback 与 Dashboard。

标记事实来源

即使由 Agent 写入，CRM、工单、身份、计费与审计系统仍必须保持权威。

选择目标层

先选择整套 Worker、Runtime 或能力层。混合方案也可以，但每个边界都要有负责人和接口。

冻结成功与回滚标准

提前定义可接受完成、安全限制、成本上限、恢复时间，以及切回旧系统的条件。

谁适合看这份指南，谁应该暂时保留现状

现在适合评估替代方案

团队已有明确生产任务，需要不同运营方式、更强代码控制或用户级认证，或希望降低平台耦合。

暂时保留 Toolhouse

现有 Worker 已满足 SLA，团队同时使用多个平台能力，且迁移收益不足以覆盖重新验证和运维成本。

迁移并不自动等于优化。如果替代方案需要用五个服务重新搭建 Schedule、Memory、Tool Auth、Audit Log 与 Deployment，必须把工程与事故响应负担计入决策。

评估方法：比较结果，不比较截图

指标权重测量方式
验收通过率结果正确、证据齐全、目标系统状态正确
安全与权限越权读取、危险写入、绕过审批、Secret 暴露
Runtime 持久性超时、重复事件、Worker 重启与人工暂停后的恢复
Tool 与互操作性MCP/SDK/API、认证模型、Schema 质量、自定义 Tool
可观测性与评估Run Trace、Tool 证据、版本、失败原因与导出
可移植性与运维导出、部署选择、回滚时间与值班责任
每个验收任务成本总成本除以验收通过而非仅尝试的 Run

统一测试任务：用一个任务暴露真实缺口

每日客户风险简报 + 审批后 CRM 动作

每天 08:00 读取内部知识与 CRM 变化，检索获准的外部背景，排序高风险客户，生成带引用的建议，请求人工审批，只写入一次 CRM，通知 Slack，并保存可重放的证据包。

第一层：整套 Worker 平台替代方案

适合评估“AI 同事”式工作：跨业务上下文、渠道与周期任务。需验证审批语义、开发扩展、导出和确定性恢复。

适合重视 Trigger/Action 自动化和易用工作流编排的团队。需验证长任务状态、重复事件、自定义集成深度与诊断能力。

适合配置 AI Workforce 和多 Agent 业务流程。需验证交接契约、每个 Agent 的权限、共享状态归属和故障隔离。

优先适用重点验证优势不要默认
Teammate 体验与跨渠道工作业务便利等于 Runtime 可移植
快速搭建 Trigger 到 Action 的流程所有长任务故障都能准确恢复一次
多 Agent Workforce 编排更多 Agent 必然提高验收率

第二层：开发者拥有的 Agent Runtime

适合需要持久执行、Persistence、Human-in-the-loop、Thread、Run、Streaming、Queue 与定时任务的长时间有状态图。需验证图版本演进、状态迁移、Trace 保留与运维责任。

适合 TypeScript 团队，在一个开发框架中组合 Agent、Tool、Memory、MCP、Workflow、暂停/恢复、Trace 与可部署 API。需验证所选部署中的生产托管、队列、租户与回滚。

Runtime 决策规则

如果显式状态图、中断、重放与生态集成最重要，可优先验证 LangGraph；如果 TypeScript 原生框架与统一 Workflow/Agent 开发体验最重要，可优先验证 Mastra。两者都需要另外确定 Tool、认证、模型、存储和生产运维。

第三层：Tools、MCP 与能力层替代方案

适合需要广泛预认证 Toolkit、每用户 Session、托管 OAuth、Trigger、MCP 与 Agent Workbench 的团队。需验证租户隔离、Scope、Tool 选择质量与响应处理。

适合以每用户授权、Tool 级权限、安全 Token 注入、MCP Gateway、治理与动作审计为核心的问题。需验证策略集成及授权/重试体验。

适合在自己的应用或 Agent 中嵌入托管认证、预构建 Tool、MCP、API Proxy 与集成。需验证服务端安全、终端用户映射、限流和事件语义。

适合现有 Agent 按意图发现能力，检查参数、成功率、延迟和价格，再通过 REST、SDK、CLI 或 MCP 调用。QVeris 是能力路由层，不替代 Runtime、Memory、Schedule 或审批。

候选核心能力仍需自行负责
Toolkit、用户 Session、认证、Trigger、WorkbenchAgent 策略、流程状态、验收评估
授权、动作 Runtime、MCP 治理业务流程、Memory、Planning、Schedule
嵌入式集成、托管认证、Tool、ProxyAgent Runtime、产品 UX、审批策略
Discover → Inspect → Call 能力路由Runtime、身份策略、Memory、Scheduler、写入审批

可移植架构可以避免下一次锁定

Trigger Adapter

把 Schedule、Webhook、Chat 和 API 事件转换成统一、带版本的请求包。

Runtime Contract

把状态转换、Checkpoint、Approval、Retry、Cancel 与 Deadline 持久化，不藏在 Prompt 文本里。

Capability Adapter

跨供应商标准化 Tool Schema、Identity、Idempotency、Error、Citation、Cost 与原始证据。

策略与审批服务

独立于模型意图判断权限与不可逆副作用。

证据与评估存储

保存引用、Hash、版本、决策与评估结果，同时删减不必要的敏感 Payload。

代码：定义供应商无关的 Agent Manifest

比较结果前，先标准化证据

不要只根据最终文字评分。应保存请求、解析后的身份、能力版本、参数、来源时间、原始响应 Hash、转换过程、验证结果、审批与副作用回执。

每个候选方案都要执行的验证清单

功能

触发、来源选择、结构化输出、引用、目标写入、通知和完成状态正确。

持久性

测试慢 Tool 重试、重复事件、Worker 重启、等待审批、取消与恢复，且不得重复写入。

安全

撤销 Scope、跨租户、Prompt Injection、请求禁止动作，并检查日志是否泄露 Secret。

运维

定位失败 Run、解释原因、从 Checkpoint 重放、导出证据、轮换 Secret 并回滚版本。

安全、成本与延迟控制

风险最低控制上线证据
越权动作每用户身份、最小权限、策略检查、不可逆写入审批拒绝动作测试与不可变审批回执
重复副作用Idempotency Key、写入账本、动作前 Checkpoint重复 Webhook 与重试后仍只有一次写入
成本失控每 Run 预算、Tool Call 上限、Token 上限、Circuit Breaker超预算后安全停止并报告部分结果
长尾延迟Deadline、有限重试、供应商超时、异步 Callback分步骤 P95/P99 与超时恢复
Secret 暴露服务端 Vault、Token 隔离、Payload 脱敏、模型不可见凭证日志扫描、轮换测试、Token 撤销行为

比较每个验收通过任务的成本

迁移方案：先迁契约，再迁流量

导出并分类

记录 Agent 代码、Prompt、Tool 配置、MCP、RAG、Memory 规则、Schedule、API 契约、Run Context、Log、Eval 与 Secret 引用；不要把原始 Secret 复制进迁移文件。

建立兼容 Adapter

把旧触发器和 API 请求转换成可移植请求包，并把新供应商响应标准化为证据 Schema。

只读重放历史

在无副作用模式下运行冻结样本，对比验收率、引用、步骤延迟、Tool 错误与成本。

影子运行线上流量

让候选方案观察线上请求但禁止写入；启用动作前分析所有分歧。

金丝雀写入

只对少量租户启用一个低风险动作，并配置审批、幂等与自动 Kill Switch。

切换并保留回滚

按工作负载逐步迁移，不一次性全切；新系统通过稳定窗口前，旧路径保持可读和可回切。

金丝雀与回滚门槛

门槛示例上线目标自动响应
验收通过率相比基线下降不超过 2 个百分点停止扩量；新 Run 切回基线
危险写入立即禁用写入能力
重复写入打开断路器；核对写入账本
P95 时限连续三天满足任务 SLA缩小流量或切换慢能力
证据完整度证据缺失时阻止后续审批

常见失败模式与修复

比较不同架构层

Tool 目录在集成数量上胜出，Runtime 在状态上胜出。修复：先定义替换边界，只对范围内职责评分。

Demo 成功、生产失败

理想 Demo 忽略授权撤销、重复事件、人工延迟和部分写入。修复：在统一任务中主动注入这些故障。

把 Prompt 当状态库

重启会丢失审批和已完成步骤。修复：显式持久化状态，并在每个副作用前 Checkpoint。

重试导致重复写入

超时掩盖了下游已成功动作。修复：使用稳定 Idempotency Key，并与写入账本核对。

把认证只当登录页面

Agent 获得过宽 Token 或错误租户上下文。修复：每请求绑定身份、最小 Scope、Token 不进入模型上下文。

只看尝试成本

低单次成本隐藏了重试、审核和被拒结果。修复：把全部运维成本计入每个验收任务成本。

QVeris 实现模式：只替换能力路由

当 Agent Runtime 已存在，缺少的是发现与执行外部能力时，QVeris 更合适。文档中的循环是 Discover → Inspect → Call：按意图搜索，检查候选能力的参数与运行信号，再执行所选能力并返回结构化结果；可通过 REST、Python、TypeScript、CLI 与 MCP 接入。

必须明确的边界

在这个模式中，QVeris 不会变成事实来源、工作流状态机、Scheduler、Memory Store 或审批权威；这些职责仍属于现有 Runtime 与业务系统。

Toolhouse 替代方案常见问题

最佳 Toolhouse 替代方案是什么？

没有通用替代品。整套数字员工选择 Worker 平台；团队自己维护 Agent 代码和状态选择 Runtime；只需要 Tools、MCP 与托管认证则选择能力层。

Toolhouse 只是 Tool 市场吗？

不是。Toolhouse 当前同时覆盖代码定义 Agent、API 部署、Worker、Schedule、Streaming、Memory、RAG、代码执行、Browser、Tool Store、MCP、评估与可观测性。

哪些方案可能替换完整 Toolhouse 后端？

Unify、Lindy、Relevance AI 可作为业务自动化候选；LangGraph + LangSmith Deployment 与 Mastra 可作为代码驱动 Runtime 候选。每个方案仍需基于具体任务试点。

哪些方案只替换 Toolhouse Tools 或 MCP？

Composio、Arcade、Pipedream Connect 与 QVeris 属于能力层候选，可改善集成、用户授权、Tool 执行或能力路由，但不会自动替代 Schedule、Memory、流程状态或 Agent API。

应该如何比较 Toolhouse 替代方案？

使用相同输入、模型预算、审批策略、超时、重试规则与预期输出运行同一任务，比较验收率、危险副作用、恢复、证据质量、延迟与每个验收任务成本。

可以不重写 Agent 就迁移吗？

有时可以。如果 Agent 已拥有 Prompt、状态与编排，只替换能力层可渐进进行；完整 Worker 或 Runtime 迁移通常要重新映射 Schedule、Memory、Run ID、审批、可观测性与部署契约。

最重要的安全控制是什么？

应使用每用户身份、最小权限、Secret 隔离、不可逆动作明确审批、Idempotency Key、出站控制、Payload 脱敏、不可变审计事件和经过测试的 Kill Switch。

QVeris 适合放在哪一层？

QVeris 是能力路由层，帮助 Agent 通过 REST、SDK、CLI 或 MCP 发现、检查与调用外部能力。除非另行替换，否则保留现有 Runtime、Memory、Scheduler、审批服务和事实来源。

官方资料与核验说明

最终决策规则

选择能够通过统一任务、保留证据、控制副作用、满足回滚窗口，并降低总运维负担的最小替换范围。只缺能力访问就保留 Runtime；Runtime 所有权有问题才更换 Runtime；业务需要开箱即用的操作者时，才评估整套 Worker。

查看 QVeris 能力层查看 Agent Gateway 架构
本文目录
展示市场数据、图表或财务报告的金融研究工作场景
评估工作流中的金融研究场景；图片仅作场景示意，不代表产品界面或基准测试。

概要：只替换真正需要替换的层

直接结论

如果要替换业务团队使用的数字员工，可优先评估 Unify、Lindy 与 Relevance AI；如果团队自己维护代码和状态，可评估 LangGraph + LangSmith Deployment 与 Mastra；如果只替换 Tools、MCP、认证和外部能力访问，而保留现有编排，则比较 Composio、Arcade、Pipedream Connect 与 QVeris。不要把九个产品放进同一排行榜，因为它们替换的是 Toolhouse 的不同部分。

整套 Worker

平台负责触发器、工作流、业务上下文、执行动作和用户操作界面。

Agent Runtime

团队拥有 Agent 代码，平台提供持久执行、状态、队列、API 与部署。

Tools + MCP

保留现有 Runtime，只替换能力发现、认证、Tool 执行或集成基础设施。

混合架构

用 Runtime 管理状态和审批，再接入一个能力供应商处理外部动作与数据。

2026 年的 Toolhouse：先建立公平基线

Toolhouse 不能只被描述成 Tool 市场。其当前文档将产品定位为 Agent Backend-as-a-Service：既可以用代码定义 Agent 并发布为 API，也覆盖 AI Worker、定时任务、异步运行、运行上下文、RAG、Memory、代码执行、浏览器使用、公共与自定义 MCP、经过审核的 Tool Store、评估、Prompt 优化和可观测性。

层Toolhouse 基线替代方案需要证明
WorkerWorker、定时任务、面向业务的自动化非开发者能操作、暂停、检查并恢复任务。
Runtime代码定义 Agent、API 发布、流式与异步运行、Run ID状态可跨重试、部署、超时和人工暂停保持。
能力Tool Store、MCP、RAG、Memory、Browser、代码执行认证、Schema、错误、输出限制与副作用都可明确控制。
控制面日志、评估、Prompt 优化和用量控制运营人员可从请求追踪到模型与 Tool 证据。

这很重要：一个 Tools 产品可能是优秀组件，但仍不是完整的 Toolhouse 替代品。正确问题不是“集成是否更多”，而是“哪些 Toolhouse 职责被迁移、哪些保留、缺口由谁负责”。

前置步骤：画清替换边界

盘点当前契约

列出 Worker、Agent 定义、Prompt、Schedule、Run ID、Memory、RAG、Tool、MCP、Secret、审批、Callback 与 Dashboard。

标记事实来源

即使由 Agent 写入，CRM、工单、身份、计费与审计系统仍必须保持权威。

选择目标层

先选择整套 Worker、Runtime 或能力层。混合方案也可以，但每个边界都要有负责人和接口。

冻结成功与回滚标准

提前定义可接受完成、安全限制、成本上限、恢复时间，以及切回旧系统的条件。

谁适合看这份指南，谁应该暂时保留现状

现在适合评估替代方案

团队已有明确生产任务，需要不同运营方式、更强代码控制或用户级认证，或希望降低平台耦合。

暂时保留 Toolhouse

现有 Worker 已满足 SLA，团队同时使用多个平台能力，且迁移收益不足以覆盖重新验证和运维成本。

迁移并不自动等于优化。如果替代方案需要用五个服务重新搭建 Schedule、Memory、Tool Auth、Audit Log 与 Deployment，必须把工程与事故响应负担计入决策。

评估方法：比较结果，不比较截图

指标权重测量方式
验收通过率25%结果正确、证据齐全、目标系统状态正确
安全与权限20%越权读取、危险写入、绕过审批、Secret 暴露
Runtime 持久性15%超时、重复事件、Worker 重启与人工暂停后的恢复
Tool 与互操作性15%MCP/SDK/API、认证模型、Schema 质量、自定义 Tool
可观测性与评估10%Run Trace、Tool 证据、版本、失败原因与导出
可移植性与运维10%导出、部署选择、回滚时间与值班责任
每个验收任务成本5%总成本除以验收通过而非仅尝试的 Run

统一测试任务：用一个任务暴露真实缺口

每日客户风险简报 + 审批后 CRM 动作

每天 08:00 读取内部知识与 CRM 变化，检索获准的外部背景，排序高风险客户，生成带引用的建议，请求人工审批，只写入一次 CRM，通知 Slack，并保存可重放的证据包。

YAML · portable workload contract
workload: customer_risk_brief_v1
trigger:
  schedule: "0 8 * * 1-5"
identity:
  actor: "risk-agent"
  tenant: "acme"
inputs:
  crm_window_hours: 24
  knowledge_snapshot: "kb-2026-07-30"
controls:
  read_scopes: ["crm.read", "kb.read", "external.research"]
  write_scopes: ["crm.note.create", "slack.message.send"]
  approval_required: ["crm.note.create"]
  idempotency_key: "tenant + account + business_date"
  max_runtime_seconds: 300
acceptance:
  citations_required: true
  duplicate_writes: 0
  unsupported_claims: 0
  replay_bundle_required: true

第一层：整套 Worker 平台替代方案

Unify

适合评估“AI 同事”式工作：跨业务上下文、渠道与周期任务。需验证审批语义、开发扩展、导出和确定性恢复。

Lindy

适合重视 Trigger/Action 自动化和易用工作流编排的团队。需验证长任务状态、重复事件、自定义集成深度与诊断能力。

Relevance AI

适合配置 AI Workforce 和多 Agent 业务流程。需验证交接契约、每个 Agent 的权限、共享状态归属和故障隔离。

优先适用重点验证优势不要默认
UnifyTeammate 体验与跨渠道工作业务便利等于 Runtime 可移植
Lindy快速搭建 Trigger 到 Action 的流程所有长任务故障都能准确恢复一次
Relevance AI多 Agent Workforce 编排更多 Agent 必然提高验收率

第二层：开发者拥有的 Agent Runtime

LangGraph + LangSmith Deployment

适合需要持久执行、Persistence、Human-in-the-loop、Thread、Run、Streaming、Queue 与定时任务的长时间有状态图。需验证图版本演进、状态迁移、Trace 保留与运维责任。

Mastra

适合 TypeScript 团队，在一个开发框架中组合 Agent、Tool、Memory、MCP、Workflow、暂停/恢复、Trace 与可部署 API。需验证所选部署中的生产托管、队列、租户与回滚。

Runtime 决策规则

如果显式状态图、中断、重放与生态集成最重要，可优先验证 LangGraph；如果 TypeScript 原生框架与统一 Workflow/Agent 开发体验最重要，可优先验证 Mastra。两者都需要另外确定 Tool、认证、模型、存储和生产运维。

第三层：Tools、MCP 与能力层替代方案

Composio

适合需要广泛预认证 Toolkit、每用户 Session、托管 OAuth、Trigger、MCP 与 Agent Workbench 的团队。需验证租户隔离、Scope、Tool 选择质量与响应处理。

Arcade

适合以每用户授权、Tool 级权限、安全 Token 注入、MCP Gateway、治理与动作审计为核心的问题。需验证策略集成及授权/重试体验。

Pipedream Connect

适合在自己的应用或 Agent 中嵌入托管认证、预构建 Tool、MCP、API Proxy 与集成。需验证服务端安全、终端用户映射、限流和事件语义。

QVeris

适合现有 Agent 按意图发现能力，检查参数、成功率、延迟和价格，再通过 REST、SDK、CLI 或 MCP 调用。QVeris 是能力路由层，不替代 Runtime、Memory、Schedule 或审批。

候选核心能力仍需自行负责
ComposioToolkit、用户 Session、认证、Trigger、WorkbenchAgent 策略、流程状态、验收评估
Arcade授权、动作 Runtime、MCP 治理业务流程、Memory、Planning、Schedule
Pipedream Connect嵌入式集成、托管认证、Tool、ProxyAgent Runtime、产品 UX、审批策略
QVerisDiscover → Inspect → Call 能力路由Runtime、身份策略、Memory、Scheduler、写入审批

可移植架构可以避免下一次锁定

Trigger Adapter

把 Schedule、Webhook、Chat 和 API 事件转换成统一、带版本的请求包。

Runtime Contract

把状态转换、Checkpoint、Approval、Retry、Cancel 与 Deadline 持久化，不藏在 Prompt 文本里。

Capability Adapter

跨供应商标准化 Tool Schema、Identity、Idempotency、Error、Citation、Cost 与原始证据。

策略与审批服务

独立于模型意图判断权限与不可逆副作用。

证据与评估存储

保存引用、Hash、版本、决策与评估结果，同时删减不必要的敏感 Payload。

代码：定义供应商无关的 Agent Manifest

TypeScript · internal agent contract
type AgentManifest = {
  id: string;
  version: string;
  trigger: { type: "schedule" | "event" | "api"; expression?: string };
  runtime: {
    deadlineSeconds: number;
    maxAttempts: number;
    checkpoint: "each_step" | "before_side_effect";
  };
  capabilities: Array<{
    intent: string;
    mode: "read" | "write";
    scopes: string[];
    approval: "never" | "always" | "policy";
  }>;
  acceptance: {
    schema: string;
    citationsRequired: boolean;
    maxCostUsd: number;
  };
};

const riskBrief: AgentManifest = {
  id: "customer-risk-brief",
  version: "1.3.0",
  trigger: { type: "schedule", expression: "0 8 * * 1-5" },
  runtime: { deadlineSeconds: 300, maxAttempts: 3, checkpoint: "before_side_effect" },
  capabilities: [
    { intent: "read CRM changes", mode: "read", scopes: ["crm.read"], approval: "never" },
    { intent: "create CRM note", mode: "write", scopes: ["crm.note.create"], approval: "always" }
  ],
  acceptance: { schema: "risk-brief-v1", citationsRequired: true, maxCostUsd: 0.75 }
};

比较结果前，先标准化证据

JSON · accepted execution envelope
{
  "run_id": "run_01K...",
  "manifest_version": "1.3.0",
  "provider": "candidate-a",
  "status": "awaiting_approval",
  "identity": { "tenant": "acme", "actor": "risk-agent" },
  "steps": [
    {
      "name": "external_research",
      "capability_id": "provider.capability.version",
      "request_hash": "sha256:...",
      "source_time": "2026-07-30T23:58:00Z",
      "latency_ms": 842,
      "cost_usd": 0.014,
      "evidence_refs": ["ev_201", "ev_202"]
    }
  ],
  "pending_action": {
    "type": "crm.note.create",
    "idempotency_key": "acme:account-42:2026-07-31",
    "approval_id": "apr_88"
  },
  "validation": {
    "schema": "pass",
    "citations": "pass",
    "policy": "pass"
  }
}

不要只根据最终文字评分。应保存请求、解析后的身份、能力版本、参数、来源时间、原始响应 Hash、转换过程、验证结果、审批与副作用回执。

每个候选方案都要执行的验证清单

功能

触发、来源选择、结构化输出、引用、目标写入、通知和完成状态正确。

持久性

测试慢 Tool 重试、重复事件、Worker 重启、等待审批、取消与恢复，且不得重复写入。

安全

撤销 Scope、跨租户、Prompt Injection、请求禁止动作，并检查日志是否泄露 Secret。

运维

定位失败 Run、解释原因、从 Checkpoint 重放、导出证据、轮换 Secret 并回滚版本。

安全、成本与延迟控制

风险最低控制上线证据
越权动作每用户身份、最小权限、策略检查、不可逆写入审批拒绝动作测试与不可变审批回执
重复副作用Idempotency Key、写入账本、动作前 Checkpoint重复 Webhook 与重试后仍只有一次写入
成本失控每 Run 预算、Tool Call 上限、Token 上限、Circuit Breaker超预算后安全停止并报告部分结果
长尾延迟Deadline、有限重试、供应商超时、异步 Callback分步骤 P95/P99 与超时恢复
Secret 暴露服务端 Vault、Token 隔离、Payload 脱敏、模型不可见凭证日志扫描、轮换测试、Token 撤销行为

比较每个验收通过任务的成本

Formula · normalized unit economics
all_in_cost =
  platform_fee
  + model_cost
  + tool_or_capability_cost
  + storage_and_network
  + engineering_operations
  + human_review
  + failure_recovery

cost_per_accepted_task =
  all_in_cost / accepted_tasks

accepted_tasks =
  completed_tasks
  - unsafe_or_incorrect_tasks
  - tasks_missing_required_evidence

迁移方案：先迁契约，再迁流量

导出并分类

记录 Agent 代码、Prompt、Tool 配置、MCP、RAG、Memory 规则、Schedule、API 契约、Run Context、Log、Eval 与 Secret 引用；不要把原始 Secret 复制进迁移文件。

建立兼容 Adapter

把旧触发器和 API 请求转换成可移植请求包，并把新供应商响应标准化为证据 Schema。

只读重放历史

在无副作用模式下运行冻结样本，对比验收率、引用、步骤延迟、Tool 错误与成本。

影子运行线上流量

让候选方案观察线上请求但禁止写入；启用动作前分析所有分歧。

金丝雀写入

只对少量租户启用一个低风险动作，并配置审批、幂等与自动 Kill Switch。

切换并保留回滚

按工作负载逐步迁移，不一次性全切；新系统通过稳定窗口前，旧路径保持可读和可回切。

金丝雀与回滚门槛

门槛示例上线目标自动响应
验收通过率相比基线下降不超过 2 个百分点停止扩量；新 Run 切回基线
危险写入0立即禁用写入能力
重复写入0打开断路器；核对写入账本
P95 时限连续三天满足任务 SLA缩小流量或切换慢能力
证据完整度100%证据缺失时阻止后续审批

常见失败模式与修复

比较不同架构层

Tool 目录在集成数量上胜出，Runtime 在状态上胜出。修复：先定义替换边界，只对范围内职责评分。

Demo 成功、生产失败

理想 Demo 忽略授权撤销、重复事件、人工延迟和部分写入。修复：在统一任务中主动注入这些故障。

把 Prompt 当状态库

重启会丢失审批和已完成步骤。修复：显式持久化状态，并在每个副作用前 Checkpoint。

重试导致重复写入

超时掩盖了下游已成功动作。修复：使用稳定 Idempotency Key，并与写入账本核对。

把认证只当登录页面

Agent 获得过宽 Token 或错误租户上下文。修复：每请求绑定身份、最小 Scope、Token 不进入模型上下文。

只看尝试成本

低单次成本隐藏了重试、审核和被拒结果。修复：把全部运维成本计入每个验收任务成本。

QVeris 实现模式：只替换能力路由

当 Agent Runtime 已存在，缺少的是发现与执行外部能力时，QVeris 更合适。文档中的循环是 Discover → Inspect → Call：按意图搜索，检查候选能力的参数与运行信号，再执行所选能力并返回结构化结果；可通过 REST、Python、TypeScript、CLI 与 MCP 接入。

Python · Discover → Inspect → Call
from qveris import QverisClient

async with QverisClient() as client:
    found = await client.discover(
        "retrieve current company risk signals",
        limit=5,
    )
    candidate = found.results[0]

    inspected = await client.inspect(
        [candidate.tool_id],
        search_id=found.search_id,
    )
    selected = inspected.results[0]

    result = await client.call(
        selected.tool_id,
        {"company": "Example Corp"},
        search_id=found.search_id,
    )

    assert result.success
    print(result.execution_id, result.billing)
必须明确的边界

在这个模式中，QVeris 不会变成事实来源、工作流状态机、Scheduler、Memory Store 或审批权威；这些职责仍属于现有 Runtime 与业务系统。

Toolhouse 替代方案常见问题

最佳 Toolhouse 替代方案是什么？

没有通用替代品。整套数字员工选择 Worker 平台；团队自己维护 Agent 代码和状态选择 Runtime；只需要 Tools、MCP 与托管认证则选择能力层。

Toolhouse 只是 Tool 市场吗？

不是。Toolhouse 当前同时覆盖代码定义 Agent、API 部署、Worker、Schedule、Streaming、Memory、RAG、代码执行、Browser、Tool Store、MCP、评估与可观测性。

哪些方案可能替换完整 Toolhouse 后端？

Unify、Lindy、Relevance AI 可作为业务自动化候选；LangGraph + LangSmith Deployment 与 Mastra 可作为代码驱动 Runtime 候选。每个方案仍需基于具体任务试点。

哪些方案只替换 Toolhouse Tools 或 MCP？

Composio、Arcade、Pipedream Connect 与 QVeris 属于能力层候选，可改善集成、用户授权、Tool 执行或能力路由，但不会自动替代 Schedule、Memory、流程状态或 Agent API。

应该如何比较 Toolhouse 替代方案？

使用相同输入、模型预算、审批策略、超时、重试规则与预期输出运行同一任务，比较验收率、危险副作用、恢复、证据质量、延迟与每个验收任务成本。

可以不重写 Agent 就迁移吗？

有时可以。如果 Agent 已拥有 Prompt、状态与编排，只替换能力层可渐进进行；完整 Worker 或 Runtime 迁移通常要重新映射 Schedule、Memory、Run ID、审批、可观测性与部署契约。

最重要的安全控制是什么？

应使用每用户身份、最小权限、Secret 隔离、不可逆动作明确审批、Idempotency Key、出站控制、Payload 脱敏、不可变审计事件和经过测试的 Kill Switch。

QVeris 适合放在哪一层？

QVeris 是能力路由层，帮助 Agent 通过 REST、SDK、CLI 或 MCP 发现、检查与调用外部能力。除非另行替换，否则保留现有 Runtime、Memory、Scheduler、审批服务和事实来源。

官方资料与核验说明

最终决策规则

选择能够通过统一任务、保留证据、控制副作用、满足回滚窗口，并降低总运维负担的最小替换范围。只缺能力访问就保留 Runtime；Runtime 所有权有问题才更换 Runtime；业务需要开箱即用的操作者时，才评估整套 Worker。

查看 QVeris 能力层 查看 Agent Gateway 架构