先把题目改写正确

“为什么我们不做 LangChain” 这个提法很容易抓眼球，但从技术上说，它一开始就把问题问歪了。

如果你把今天的 agent 栈拆开看，就会发现至少有四层不同问题混在一起被讨论。第一层是 agent framework，负责把模型、工具、agent loop 和 middleware 抽成开发者能上手的接口。第二层是 agent runtime，负责长任务、状态、持久化、恢复、人机协同和部署。第三层是 harness，也就是更偏产品化、开箱即用、带预置工具和上下文工程能力的一层。第四层则是能力发现与统一执行层，解决的不是 agent 怎么跑，而是 agent 在运行中怎么找到外部能力、怎么统一调度、怎么处理调用质量和成本。

LangChain 官方文档现在把前三层已经拆得很清楚了：LangChain 是 framework，LangGraph 是 runtime，Deep Agents 是 harness。QVeris 官方文档则把自己定义成 tool search + tool execution layer for LLM agents。这不是措辞差异，而是产品边界的直接说明。

所以真正值得问的问题是：“QVeris 和 LangChain 分别卡在哪一层，它们之间到底是替代关系，还是拼装关系？”

flowchart TB
  A["应用 / 垂直 Agent"] --> B["Harness<br/>Deep Agents / Claude Agent SDK"]
  B --> C["Framework / Runtime<br/>LangChain / LangGraph"]
  C --> D["Capability Router<br/>QVeris 这类能力发现与统一执行层"]
  D --> E["具体工具 / API / 数据源 / 内部系统"]

我之所以认为这一步必须先讲清楚，是因为一旦层次混掉，后面的争论几乎一定会滑向口号。一边在批评“你只是预定义 workflow”，另一边在回答“我有 durable execution”。双方说的可能都是真的，但说的不是同一个对象。

QVeris 现在公开交付的，本质上是一层能力路由器

QVeris 当前公开文档写得很直接。它不是把自己描述成一个完整 agent runtime，而是写成了一个给 LLM agents 用的工具搜索和工具执行层。它让 agent 做两件事：先用自然语言搜索实时可用的工具，再对选中的工具做统一执行。无论是通过 MCP、Python SDK 还是 REST API，核心动作都没有变。

从接口设计看，它的基本单元也很像一个能力路由器，而不是一个 workflow engine。POST /search 会返回 search_id 和工具列表，列表里带 tool_id、参数 schema、示例等信息；POST /tools/execute 则根据 tool_id 和参数发起调用。官方还建议模型在选择工具时参考 weighted_success_rate 和 avg_execution_time，这说明 QVeris 不只是做“能不能调”，还试图把“调哪个更靠谱”一起产品化。

import requests

api_key = "YOUR_API_KEY"
headers = {"Authorization": f"Bearer {api_key}"}

search = requests.post(
    "https://qveris.ai/api/v1/search",
    headers=headers,
    json={"query": "weather forecast API", "limit": 10},
    timeout=30,
).json()

tool = search["tools"][0]

result = requests.post(
    f"https://qveris.ai/api/v1/tools/execute?tool_id={tool['tool_id']}",
    headers=headers,
    json={
        "search_id": search["search_id"],
        "parameters": {"city": "London", "units": "metric"},
        "max_response_size": 20480,
    },
    timeout=30,
).json()

这层能力有真实价值，而且不是小价值。

在很多原型团队和开放任务里，最贵的事情不一定是 prompt，也不一定是 workflow，而是外部能力接入。你要接天气、财报、地图、CRM、翻译、可视化、社交平台、搜索引擎和一堆垂直 SaaS，每个 API 的认证、参数、限流、返回格式和失败语义都不同。QVeris 的吸引力，恰恰在于它想把这堆异构接入成本压缩成“描述能力 -> 拿到候选 -> 统一调用”的单一接口。

它的商业模式也强化了这一点。QVeris 公开定价不是按“对话轮数”收钱，而是按工具执行计费，复杂工具可能消耗 2 到 5 次 call。这很像一个 capability brokerage，而不像一个纯框架项目。框架更像开发者基建，路由层更像一层可计费的交易与执行网络。

如果一定要给 QVeris 一个更技术化的定位，我会更倾向于叫它 capability router、tool brokerage layer，或者 agent-facing capability exchange。这些词都不如“搜索工具”直白，但更接近它现在公开交付的真实形状。

今天的 LangChain，已经不是 2023 年那个只会写 Chains 的 LangChain

QVeris 那篇文章里最容易让技术读者起疑的一点，是它把 LangChain 主要描述成了“预定义 Chain + 有限工具集”的体系。这个说法如果放在 2023 年初期，我会觉得大体成立；但如果放到 2026 年，它已经不足以描述今天的 LangChain 栈。

LangChain 官方现在把自家产品线直接拆成了三层。LangChain 本身是 framework，负责抽象模型、工具、agent loop 和 middleware；LangGraph 是 runtime，负责长任务、状态、持久化、streaming、human-in-the-loop 和低层 orchestration；Deep Agents 则是更有主见的一层 harness，带 planning、subagents、filesystem 和 context management，针对的是更复杂、更长时间、更非确定性的任务。

这意味着一个重要事实：LangChain 团队自己早就承认“agent = chain 的延长线”这个理解不够用了。否则他们没必要把 runtime 和 harness 单独拉出来，更没必要把 LangGraph 定位成一个低层 orchestration framework 和 runtime，并明确写上 durable execution、persistence、HITL 和 long-running stateful agents。

更关键的是，今天的 LangChain 也已经不是“只能预定义工具”。在官方 Agents 文档里，它明确区分了 static tools 和 dynamic tools。动态工具部分写得很清楚：当工具是在运行时发现或创建的，例如从 MCP server 加载、基于用户数据生成，或者从 remote registry 获取时，需要在 runtime 动态注册这些工具，并在 tool call 阶段动态处理执行。这和“只能提前把 3 个工具写死在列表里”已经不是一回事。

from langchain.agents import create_agent
from langchain.agents.middleware import AgentMiddleware


class DynamicToolMiddleware(AgentMiddleware):
    def wrap_model_call(self, request, handler):
        dynamic_tools = load_tools_from_registry()
        return handler(request.override(tools=[*request.tools, *dynamic_tools]))

    def wrap_tool_call(self, request, handler):
        return dispatch_dynamic_tool(request)


agent = create_agent(
    model="gpt-4.1",
    tools=[],
    middleware=[DynamicToolMiddleware()],
)

所以如果今天还把 LangChain 讲成“你先写死一串 step，再给它几个固定工具”，那更像是在批评一个历史版本，而不是在批评今天这个系统。

这不意味着 QVeris 的判断就失效了。恰恰相反，它最值得保留的判断是：工作流很多时候是动态 loop，不是静态链条。问题在于，LangChain 生态也已经沿着这个方向演化了，而且演化得比“LangChain 只是 Chains”这个印象要远得多。

动态工具发现，不等于完整的 agent runtime

这一点是我觉得整场讨论里最应该被单独拉出来讲的。

动态工具发现解决的是 capability plane 的问题，也就是当 agent 突然需要一个新能力时，怎么找到、评估并调用它。runtime 解决的则是 control plane 的问题，也就是这个 agent 循环怎么持续、状态怎么保存、失败如何恢复、人工如何介入、过程如何观测、长任务如何部署。两者都重要，但它们不是同一层技术。

LangGraph 的 durable execution 文档把 runtime 要处理的事情写得很明白。一个 workflow 会在关键点保存进度，之后可以在中断、失败甚至隔很久之后，从原地恢复。这种机制之所以对 agent 重要，不是因为它听起来高级，而是因为真正的 agent 一旦进入生产，失败就不是异常，而是常态。网络会抖，LLM 会超时，工具会挂，人工会插队，权限会变，长任务会中断。没有 runtime，这些故障只会在每次重试时把上下文和成本一起打爆。

同样的逻辑也出现在 Anthropic 和 OpenAI 的公开方法论里。OpenAI 的实践指南明确建议从 single-agent 开始，把复杂度留在工具、指令和 guardrails 上，而不是一开始就堆一个高度自治、结构复杂的系统。Anthropic 则一方面强调最有效的系统往往来自简单、可组合的模式，另一方面又在自家多 agent 研究系统里写得很诚实：开放式研究任务天然动态、难以预设路径，但 multi-agent 也会快速烧 token，而且协调、评测和可靠性难题会立刻上来。

这组观点组合在一起，形成了一个很朴素的工程判断：动态能力发现是必要条件，但它远远不是充分条件。

你可以把 QVeris 接进一个 agent，让它在运行中发现天气 API、财报 API、竞品情报 API；但只要这个 agent 本身没有状态管理、上下文压缩、失败恢复、审批门、验证回路和 trace，它仍然更像一个临时会调用外部工具的循环，而不是一个真正可持续运行的生产系统。

更准确的对比方式，是把 QVeris 放到 LangChain 栈的旁边，而不是上面

如果按技术分层去看，两者更像是正交关系。

LangChain 关心的是：开发者怎样更快搭一个 agent，怎样组织 agent loop、middleware、model abstraction 和 tool abstraction。LangGraph 关心的是：这个 agent 如何长时间、带状态、可恢复地跑下去。Deep Agents、Claude Agent SDK 这类 harness 关心的是：如何给 agent 提供更现成的 planning、subagents、filesystem、context compaction 和执行外壳。

QVeris 关心的则是另一件事：当 agent 在运行中突然缺某种能力时，能不能不用提前写死接入逻辑，而是实时发现候选工具，并用统一方式调起来。

这两类系统可以互补，而且在很多场景里应该互补。

假设你在做一个投资研究 agent。它首先需要一个 runtime 或 harness，因为它要长时间跑，需要保存状态、阶段性汇报、失败后恢复，还要在高风险节点上等人工确认。与此同时，它也可能需要一个 capability router，因为研究过程中冒出来的数据源和工具需求并不完全可预设，今天要查 SEC 文件，明天要查 GitHub 仓库，后天要接一个冷门市场数据库。这个时候，LangGraph 和 QVeris 处理的是同一个系统里的不同问题。

真正会冲突的场景，反而没有宣传里说得那么多。冲突通常发生在两种情况。第一种，是能力路由层开始往上做 orchestration、planning、HITL、memory 和 durable execution，这时它会直接撞上 runtime 和 harness。第二种，是 framework/runtime 开始往下把 tool registry、remote MCP、dynamic tool loading 和统一执行做得越来越厚，这时能力路由层会被压缩出一部分空间。

从今天的公开资料看，我更倾向于认为行业正朝第二种方向加速，但第一种也在发生。

业界几条最值得重视的判断，其实正在慢慢收敛

如果把近一年几家最重要玩家的公开表达放在一起，会发现大家没有想象中分裂。

Simon Willison 把 agent 压缩成了一句非常好用的话：models using tools in a loop。这句话的价值不在于定义漂亮，而在于它把神秘化的部分拿掉了。Agent 的本质不是某种新物种，而是模型、工具、环境反馈和停止条件构成的循环。

Anthropic 在《Building effective agents》里强调，最成功的实现往往不是复杂框架，而是简单、可组合的模式。这不是在否定 runtime，而是在提醒工程团队：不要一上来就用复杂结构掩盖基本功缺失。工具设计、上下文组织、验证方式和失败恢复，通常比“多几个 agent 角色”更决定成败。

OpenAI 的观点也很像。它建议从 single-agent 系统起步，通过逐步增加工具来扩展能力，再根据任务复杂度决定是否升级成 multi-agent。这和很多创业公司喜欢讲的“先上 fully autonomous system”正好反过来。OpenAI 不是否认自主性，而是在提醒一个更现实的顺序：先把 loop 跑稳，再考虑把控制面做复杂。

Anthropic 在多 agent research system 文章里又补了另一半现实。对于广度优先、并行探索、路径开放的研究任务，多 agent 确实比 single-agent 更强，而且内部评测提升明显；但它也坦率写出代价，multi-agent 会显著增加 token 开销，很多需要强共享上下文或高度依赖协作的任务并不适合直接多 agent 化，尤其编码任务目前就没有研究任务那样天然并行。

Claude Agent SDK 那篇文章则把 agent loop 说得非常工程化：gather context -> take action -> verify work -> repeat。这几乎和很多 coding agent、research agent 的现实工作模式完全一致。它还补了一个很关键的观察：文件夹和文件结构本身就是一种 context engineering。这句话很重要，因为它再次说明，真正的 agent 能力从来不只在模型里，也在外部工作环境里。

把这些判断放在一起，你会得到一个比“谁比谁更懂 agent”更有用的结论：

• 动态 loop 是对的。
• 工具发现很重要，但不是全部。
• runtime、harness、context engineering、verification 和 human gate 一样重要。
• multi-agent 不是默认高级形态，而是带成本和评测难题的结构化选择。

我对 QVeris 的客观判断：方向成立，但边界还没有被市场完全锁死

如果只看方向，我认为 QVeris 做的是一条成立的线。随着 agent 从固定工具箱走向开放环境，能力发现和统一执行会成为一个独立问题，而且这个问题不是 LangChain 式 framework 自动就能吃掉的。谁能把外部工具世界做成更像“对 agent 可搜索、可比较、可统一调用的能力网络”，谁就有机会占到 agent 栈里一个真实层位。

但如果只看今天能公开核验到的产品边界，我也不觉得它已经证明自己会成为下一代 agent runtime。相反，公开资料恰恰说明它现在更像一个能力接入层，而不是 runtime。原文里提到的 QVerisFlow 更像 roadmap，因为截至 2026 年 3 月 25 日，我没有在官方站点和文档搜索里找到它的正式产品文档。

这件事不是挑刺，而是做技术判断时必须区分的两种状态：已经交付的能力，和未来想要进入的层位。

如果 QVeris 继续把自己做成一个开放的 capability router，它要面对的核心问题会是：

• 工具质量信号能不能长期可靠，而不是只看成功率和延迟。
• 私有工具、企业内部系统和权限治理能不能做深，而不是只覆盖公开 API。
• 统一执行能不能不仅统一“调用形式”，还统一错误语义、计费语义和 fallback 语义。
• 当 OpenAI、Anthropic、LangChain、云厂商都在加强 MCP、remote registry 和 tool execution 时，它的独特价值还能不能继续放大。

如果 QVeris 选择往上走，去做 orchestration 和 long-running workflows，它又会进入另一个更难的战场，因为那一层已经坐满了非常强的玩家：LangGraph、OpenAI Agents 相关栈、Claude Agent SDK、各类 durable execution 引擎、云厂商自带 agent runtime。

所以它真正的战略难点不是“要不要做 LangChain”，而是“要不要继续做深能力路由层，还是跨层上攻 runtime”。这是两个完全不同的公司路径。

更可能出现的未来，不是替代，而是重新拼装

我现在更相信的终局，不是某个单一框架吃掉整条 agent 栈，而是栈继续拆层，然后再重新发生默认组合。

比较可能稳定下来的组合，大致会长成这样：

• 模型平台负责 reasoning、tool calling protocol、内建工具和基础安全边界。
• runtime 负责状态、恢复、HITL、streaming、部署和 observability。
• harness 负责更有主见的 planning、subagents、filesystem、context compaction 和开箱即用体验。
• capability router 负责工具发现、质量排序、统一执行、计费与 fallback。
• 业务层负责领域知识、目标定义、审批策略、验收和组织流程。

这意味着很多“框架对框架”的争论，最后都会变成“默认组合对默认组合”的竞争。不是 QVeris 单挑 LangChain，也不是 LangChain 单挑 OpenAI，而是某一组组件先把开发者体验、生产稳定性和外部能力接入同时做顺，谁就更有机会成为默认栈。

在这个视角下，QVeris 的正确参照物未必只是 LangChain，也可能包括未来更成熟的 MCP registry、云厂商工具市场、模型厂商自己的 remote tool layer。它的对手不一定长得像 framework，可能长得像协议、市场或者更底层的 execution network。

而 LangChain 这边也一样。LangChain 不是靠“chain 这个词”继续往前走，它继续存在的前提，是 LangChain、LangGraph 和 Deep Agents 这套分层能持续对应现实需求：一层给上手速度，一层给生产 runtime，一层给更自主的长任务 harness。如果这套分层继续成立，它和 QVeris 更像可组装关系，而不是你死我活的零和替代。

最后压缩成六个判断

如果只留最短版本，我会把这篇文章压成下面六句。

• QVeris 现在公开交付的是能力发现与统一执行层，不是完整 agent runtime。
• 今天的 LangChain 已经不是“只会写 Chains”，而是 framework、runtime、harness 明确分层的一套栈。
• “动态工具发现”这个判断是对的，但它只回答了 agent 栈里的一部分问题。
• 真正可持续运行的 agent 还需要 runtime、context engineering、verification、human gate 和 observability。
• 未来最可能的格局不是一个框架通吃，而是多层组件重新拼装成默认组合。
• 如果 QVeris 想建立长期护城河，它必须证明自己不只是“能找到很多工具”，而是“能更稳定、更安全、更经济地把能力网络交给 agent 使用”。

如果要给一句最直接的结论，我会写成这样：QVeris 不是“另一个 LangChain”，它更像在补 Agent 栈里长期被低估的能力路由层；而 LangChain、LangGraph 和各类 harness 则在回答另一个同样重要的问题，Agent 到底怎样才能长时间、带状态、可恢复地跑下去。