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

[imdoge]

最近 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 都有人觉得太重了，我这种会不会觉得更重更过度抽象？）

[imdoge]

有的设想的 api/属性方法举的例子没体现，比如.on()监听和 hook ，.use()应用中间件或其他，.priority()优先度等很多，但核心是全定义在一处，形成类似称为 graph harness 的模板? 然后这种模板 + 之前的 loop + tools ，就从一个普通 agent 变成了专家 agent? 比 langgraph 写的更集中更复用，抽象层级更高

[bwnjnOEI]

claude 或 gpt 怎么说

[yuanqi]

我设计的时候就是渐近式披露工具和 skill ，agent 可以自己判断加载详细的工具介绍，类似任务收敛吧，不至于一直毫无目的地 loop

[crytis]

不是有 pi 吗

[metalvest]

要不就让普通 ReAct loop 先根据任务，判断复杂度要不要写一个图和门控的 template 然后简单任务直接跑，复杂任务按你这种设想跑，你这个伪代码做 oneshot 例子

[extrem]

这个时代语法糖级别的特性已经不那么吸引人了，程序员友好越来越像个伪命题，你所说的程序员的大部分工作已经交由 ai 处理，而 ai 只需要明确指引说明即可并不需要友好

[imdoge]

@extrem
但是形成模板后复用和换专家模型很方便，这种语法糖的写法设想是使用 research 模板 graph harness 加普通的 agent loop 和工具等就是研究报告专家 agent ，然后底子不变，换个模板可能就是营销 agent/资料搜集 agent/数据处理 agent 等等。传统写法即使 ai 来做也费事改很多地方而且可能漏
@bwnjnOEI
ai 比较喜欢附和，问它们有一定价值但不非常大，就是想问下真人程序员

@crytis
@yuanqi
不太一样，不是一个意思或者设计思路不一样

@metalvest
前面设想是可以有路由判断走简单还是专家模式，或者上面伪代码写法可以 fallback 到基础简单模式就类比 langgraph 等，需要时再高抽象

[alphaply]

langgraph 好实现的，我之前也实践过 router ，同一个 graph 里面有两种 agent 节点共享上下文。当然，我个人觉得与其这样工程化，不如在等个几个月几个年，等 llm 表现与定价达到了真实能落地了再说吧。现在都是卖给程序员自产自销的多一些。

[rogerer]

这种 graph 可能并不会提升准确率，因为对于开放任务，一个很大的难点就是无法用一个 workflow 去通用地描述解决问题需要的路径，模型必须得走一步看一步。

[mwVYYA6]

模型本身比 agent 编排对结果影响更大，编排只能优化确定的步骤