惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
L
LangChain Blog
WordPress大学
WordPress大学
MyScale Blog
MyScale Blog
The Cloudflare Blog
J
Java Code Geeks
Google DeepMind News
Google DeepMind News
Recent Announcements
Recent Announcements
Microsoft Azure Blog
Microsoft Azure Blog
Y
Y Combinator Blog
有赞技术团队
有赞技术团队
Last Week in AI
Last Week in AI
酷 壳 – CoolShell
酷 壳 – CoolShell
Martin Fowler
Martin Fowler
小众软件
小众软件
量子位
月光博客
月光博客
P
Proofpoint News Feed
IT之家
IT之家
腾讯CDC
博客园 - 三生石上(FineUI控件)
博客园 - 司徒正美
雷峰网
雷峰网
V
Visual Studio Blog

程序员

V2EX 看到讨论"跨域"的帖子,那个她好像回来了 codex 今天真的是不稳定呀。 火山方舟 Coding Plan 慎买 刚问了大家 openclaw 和 hermes 在什么机器上面玩,求推荐一个机器 GPT-image-2 生成 AI 图片防伪有感 codex pro 5 小时限制已经严重缩水 逆天 Antigravity 动态 JSON 序列化对强类型语言很难吗? 自建了 GPT Coding Plan,遇到了定价问题,请教大家 大家都是在什么设备上玩 openclaw 以及 hermes 的呀? 软考还有一个月就考试了,你们学习了吗? 大伙用 AI 会考虑在 user scope 的 CLAUDE.md/AGENTS.md 里交代 AI 说中文吗 我发现程序员这个群体很大部分其实挺抠的 最近使用 cc 总会莫名其妙的返工, codex 不会 目前体验最好的远程 vibe 工具 想知道大佬们抓包遇到 ssl pinning 都是咋优雅的 解决的? 工业软件的大佬们是怎么 vibe coding 的 最近 chrome 是不是有 bug 啊,一搜索就卡住 分布式异步系统在 vibe coding 下的困境 PHP Native AOT 编译器,支持将 PHP 代码编译为可执行文件,运算性能提高 150 倍 没想到 2026 年,还要浪费大量时间在跨域问题上 DeepSeek V4 这周会出吗? 中转站正式试营 欢迎试用 不掺不假 小米 mimo 升级 v2.5,并且重置了额度 Jenkins, SCM 轮询完全不工作是啥问题啊 赛博斗蛐蛐, AI 模型的简单对比(白嫖版) 使用中转站要擦亮眼睛!不说别的,倍率计算 充值好乱。 买了火山的 Coding Plan 测试得出计费模式 给我的 AI 生成了简历和状态卡, 大家帮忙看下 Ta 能找到啥样的
如果有这样一个 agent 框架,大家怎么选择?
imdoge · 2026-05-10 · via 程序员

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