竞品对比与选型
为什么我们没有再做一个 LangChain
厘清 LangChain and QVeris 在编排职责、工具契约与证据质量方面的职责边界。
Agent 需要的不仅是串联模型调用，还需要在运行时按任务发现和使用工具的路由网络。
我们经常收到的问题
“为什么不做一个像 LangChain 那样的 Agent 框架？”
这是个合理的问题。LangChain、CrewAI、AutoGPT 等项目已经形成了丰富的 Agent 框架生态。我们评估的是生态中仍缺少什么，而不只是哪些产品容易构建；由此选择了编排层之外的能力接入问题。
LangChain 等框架组织推理与执行流程；QVeris 侧重可发现、可检查的外部能力。两者处于不同层次。
编排框架擅长什么
首先需要明确：LangChain在自身定位上具有价值。
调用链管理
LangChain 可组织多步推理与执行链，把复杂任务拆解为按顺序执行的步骤。
提示词工程
提供系统提示词、少样本示例、输出解析器和提示词模板等抽象，支持跨模型组织调用。
Agent 编排
管理多 Agent 工作流中的协作、任务交接和结果共享，并组织监督流程。
这些都是实际需求。选择 QVeris 的原因在于需要补充能力接入层，而不是否认编排框架的价值。
仍需额外设计的工具接入问题
运行时工具发现
如果应用只在构建时配置固定工具列表，Agent 的可见能力就会受该列表限制。运行时发现需要额外接入目录、检索或协议能力；框架也可通过相应集成实现。
供应商质量信号
多个供应商提供相似接口时，需要比较可追溯的成功率、延迟与覆盖范围。此类指标应来自同一工作负载下的测量；未提供证据时不能断言某个供应商更可靠。
跨框架兼容性
框架专用工具适配器可能需要迁移或包装。应优先验证 MCP、REST 等通用接入方式能否满足各客户端需求，避免把兼容性视为天然成立。
控制上下文开销
把所有工具完整 Schema 放进模型上下文会随工具规模增加开销。可评估按需发现、工具检索和延迟加载；实际效果需在所用模型及框架版本上测试。
两层架构，各自承担不同职责
QVeris 可作为 LangChain 下方的能力接入层；具体框架兼容性仍需根据接入方式验证。
框架与基础设施：逐项对比
| 编排框架 | 能力路由网络 | |
|---|---|---|
| Example | LangChain、CrewAI、AutoGPT | QVeris |
| 核心职责 | 组织推理与步骤调用 | 发现并调用外部能力 |
| 工具接入 | 应用配置的工具与适配器 | 按需发现与检查 |
| 新增工具 | 取决于应用的接入设计 | 检查目录可用性与调用条件 |
| 供应商选择 | 由开发者或应用策略配置 | 根据可用质量信息与任务条件选型 |
| Scale | 上下文开销取决于工具加载方式 | 按需发现并检查候选能力 |
| Cross-framework | Framework-specific | 通过支持的接入方式连接框架 |
| Token 成本 | 取决于 Schema 与加载方式 | 根据实际响应测量 |
多数团队可以考虑：组合使用。由 LangChain 等框架负责流程编排，由 QVeris 补充能力发现与路由。
我们构建了什么
语义发现
Agent 用自然语言描述需求，再检查返回的候选能力及质量信息。目录规模和可调用性会变化，接入时应核实具体工具。
路由层
多个供应商提供相似能力时，比较成功率、延迟、成本与任务条件。选择效果取决于可用数据和路由策略，需要实测验证。
通用接入方式
通过 CLI、MCP Server、REST API 或 SDK 连接能力网络；应根据所用客户端与框架版本核实支持情况。
为已有框架补充能力接入
可在团队现有框架下接入 QVeris，并明确编排层与能力层各自承担的职责。