如果有这样一个 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 编排对结果影响更大，编排只能优化确定的步骤

[imdoge]

@rogerer
这恰恰是和 workflow 不同的思想的设计，可能我前面没表达的清楚
workflow：比较固定的路径
agent loop + ReAct 太自由，全靠 llm 智商，目前在开放任务表现一般，而且有些私域或者内部流程是有固定限制和流程的，模型再聪明也需要门控
我这种设想的思想就是在 langgraph 上再高一层的抽象，不仅是语法糖写法的不同（边代表的更多，协议优先等）
和 gpt-5.5 pro/5.5 heavy 讨论中，有几句总结我觉得很适合表现这种预想的设计：
“Runtime 内核做薄，任务协议做厚，Graph 模板做稀疏，节点内部 agent 保持自由”

它不是 agent loop 那种纯自由的，也不是 workflow 那种固定的，是在一定的图/状态机/门控/harness 等工程限制下的自由，大概就是“限制在一定的流动范围和门控限制下，但是某些节点内它是自由的，可以随便 agent loop 的工具调用的自由的”

举个例子：一个 research 任务，你用普通的 agent sdk 比如就拿 cc/codex 去做它可能调 web search 工具查几轮网站，有时发现点什么还会进一步 web fetch 仔细看，然后开始总结
实际的高级 research 智能体：拆分任务、定证据标准、维护 evidence/gap 、来源校验、补证据、判断能不能 final 等等，这样才能达到更强的效果

@mwVYYA6
以后模型会不会智能到我上面举例的 research 任务不编排也能自己这样做不清楚，毕竟有的 harness 工程就是应该模型越智能越少的，目前测试下来就是很开放的专业的工作，让它自由 agent loop 效果一般。
但是有的不是模型变聪明就消失的：私域知识/行业组织规范/权限边界/安全策略/质量门槛/恢复策略，我觉得不能指望你贴一串 prompt 告诉它就能遵守，有的还是代码硬门控的（除非真的 AGI 了）？