如果有这样一个 agent 框架,大家怎么选择?

最近 agent 相关开发的时候遇到个问题,然后想到的。想和各位讨论下。 现在很多 agent sdk ,核心好像基本都是: agent loop + ReAct + tools + 一些 harness 工程 memory / rag / provider 这些无关的先不讨论 我最近的感觉是,普通...
如果有这样一个 agent 框架,大家怎么选择?
如果有这样一个 agent 框架,大家怎么选择?

最近 agent 相关开发的时候遇到个问题,然后想到的。想和各位讨论下。

现在很多 agent sdk ,核心好像基本都是:

agent loop + ReAct + tools + 一些 harness 工程

memory / rag / provider 这些无关的先不讨论

我最近的感觉是,普通 agent loop 在开放场景里表现不够好

比如你给它一堆工具:

web search
web fetch
tools
mcp
skill
内部 api

然后让它做一个稍微开放点的任务,比如:

帮我调研某个 xxx 适不适合 xxx ,顺便看下 xxx/xxx/xxx ,最后给建议。

这种任务普通 ReAct loop 能跑,但不够精,research 智能体会有很多额外逻辑,比如拆分/循环/证据/跳出判断等等,这种用现有的 agent 框架当然也能写,但是我设想的不太一样

我是想,复杂 agent 是不是不应该只是一个完全自由的 loop 。 之前是:

agent loop + ReAct + 其他? = 一个能跑起来的 agent

我想的是一种:

状态机 loop + 一个图和门控的 template(下面有伪代码定义,全都写在一个地方) + 节点内部自由 agent + 其他? = 某领域专家 agent

所以应该定义在一起,便于复用和阅读。 下面的举例都是伪代码,大概像这样写,主要看意思:

const graph = Graph.template("research_agent", {...options}, graph => {
  graph
    .node("plan", PlanNode)
    .node("research", ResearchAgentNode)
    .node("verify", VerifyNode)
    .node("final", FinalNode)
    .node("ask_user", AskUserNode)

  graph.edge("research", "verify", edge =>
    edge
      .must(Gate.hasEnoughEvidence())
      .must("has_enough_sources", ctx => {
        const sources = ctx.state.sources

        return sources.length >= 3
          ? ctx.pass({
              code: "ENOUGH_SOURCES",
              data: { count: sources.length },
            })
          : ctx.block({
              code: "NOT_ENOUGH_SOURCES",
              data: { count: sources.length },
            })
      })
      .must("has_claims", ctx => {
        const output = ctx.fromOutput()

        return output.claims?.length
          ? ctx.pass({ code: "HAS_CLAIMS" })
          : ctx.block({ code: "NO_CLAIMS" })
      })
      .recoverTo("research")
      .audit()
  )

  graph.edge("verify", "final", edge =>
    edge
      .must("claims_are_grounded", ctx => {
        const unsupported = ctx.state.claims.filter(
          claim => claim.sourceRefs.length === 0
        )

        return unsupported.length === 0
          ? ctx.pass({ code: "ALL_CLAIMS_GROUNDED" })
          : ctx.block({
              code: "UNSUPPORTED_CLAIMS",
              data: { unsupported },
            })
      })
      .recoverTo("research")
      .audit()
  )
})

解释:

.node()	     定义节点,内部是自由的 agent 或普通函数执行都可能
.edge()	     定义边
.when()      判断这条边适不适用
.must()      代码硬门控或预定义方法门控,判断这条边能不能走
.recoverTo() 门控没过后去哪
.fallback()  没有候选路径时去哪
.audit()     记录这次为什么走 / 为什么没走

LangGraph 当然也能写,addConditionalEdges 里写一堆代码逻辑,然后还有其他 harness/门控/helper 的逻辑散落在各处。 我这种设想的写法,抽象层级更高,定义集中,专家模板能力容易复用。

对比我这种设想的写法,和 langgraph ,或者其他有类似功能的 agent 框架,各位程序员会更喜欢哪一种?(毕竟 langgraph 都有人觉得太重了,我这种会不会觉得更重更过度抽象?)

来源: V2EX - 技术查看原文